From nobody Tue Mar 3 01:33: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 DAE901A1B12 for ; Tue, 3 Mar 2015 01:33:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ahDcfeGkcEfI for ; Tue, 3 Mar 2015 01:33:23 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 034491A1B0D for ; Tue, 3 Mar 2015 01:33:22 -0800 (PST) Received: from [192.168.131.140] ([80.92.121.102]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MdXSC-1Y7jLg3gNw-00POcf for ; Tue, 03 Mar 2015 10:33:21 +0100 Message-ID: <54F57FDE.9010109@gmx.net> Date: Tue, 03 Mar 2015 10:33:18 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Ace@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="4sc1BbIwplSXbxtCfKwXUFvWCCNs9fvxX" X-Provags-ID: V03:K0:nwOaPOofRVArk+S4Arq9J7tfjZPW5PTCdl64np67QgGBoAAsa9y uicxvZf6zNt072gA7YSk0tdznyiCBzbb8HLV41GcqVsgLhZgWtPMeL5h2U2owaNBDa2vzSA cQJrL54jSTDOHRHpSwRB3Mz9MamBk1ynA1G5gax3Rf0P9vNTdHUBu2Ttc4bmiEioMeu0342 RCQNjjHNfPngZY/bLuIrw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [Ace] Use Case Draft X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 09:33:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4sc1BbIwplSXbxtCfKwXUFvWCCNs9fvxX Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Use Case Draft Authors, I read through the latest version of the document and I noticed a few things. a) In http://www.ietf.org/mail-archive/web/ace/current/msg00901.html I suggested to add another scenario to the home automation use case. I don't think it has been added (at least I couldn't see it). Did you miss it or did it not find enough interest? b) I am not convinced about the use case in Section 2.6 "Sports & Entertainment". To me it reads more like a multi-user operating system feature rather than something we develop. I am also not sure it "sells" well as a use case since it is functionality users wouldn't expect to experience today. If you give your 400 EUR watch to your friend are you really worried about your 4 training runs that are stored on that watch? Today, the person who has the watch can see the data on it and change (some) settings. What you cannot do (today) is to see your "training plan" since that wouldn't be stored on the watch anyway. I am not sure what a useful use case for this type of sports equipment actually is (in context of ACE). c) The 'owner' terminology still confuses me. There is the implicit assumption that the owner can configure policies and then there are non-owners that cannot. I don't think that ownership has anything to do with policy configuration. d) Here is a question for my own personal interest. I would like to understand the container use case better and I believe the slides presented at various IETF meetings showed the use case a bit better (at least the involved parties). Is there anywhere (e.g., papers) a description about the actual 'user experience' (by user I mean the experience the different parties have). For example, the supermarket chain will have to receive information about the containers it can track at some point in time. I assume they will have to have an "account" with some company (whom?) to actually query the data while the containers are in transit. Someone will have to configure the policies for each of the involved parties at some authorization server. Who is that party? Ciao Hannes --4sc1BbIwplSXbxtCfKwXUFvWCCNs9fvxX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU9X/eAAoJEGhJURNOOiAtJyoH/jmO85a697p1vDU5M5crD/as 877GlNxCazyAOKiSlwhEeF/AxAfaOjE73l7JHpY7GTf2N9oco9DOT8hfwDGBp0nA kbgxu8/hY1J697MnqcVPPg1tGIM1d6XcHR7aMnPy97GBENfoE5J8hpBJPvCPpzxX isRdg4dTYDjUhBU8sZr6E3eLcSZlyZ6Hatktvrmf1wF/CGVlKZdPCiLxIxoh4UuL DTkeF44lADjNNtsTPloqdOXztsxPHRYWAi4Jy8hmFRENjAMGLWEXW0y2+vdcZ1IX i6DL/Qi7Gvc9sxbJ27xji/+GIGOKxwmywwadC+dlRH296AapraAvlIuO0ymTdGg= =u+cQ -----END PGP SIGNATURE----- --4sc1BbIwplSXbxtCfKwXUFvWCCNs9fvxX-- From nobody Tue Mar 3 02:40: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 020D11A008B for ; Tue, 3 Mar 2015 02:40:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_SE=0.35, 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 8dGqso2_KXtz for ; Tue, 3 Mar 2015 02:40:53 -0800 (PST) Received: from outbox.sics.se (outbox.sics.se [193.10.64.137]) by ietfa.amsl.com (Postfix) with ESMTP id 187F81A1B53 for ; Tue, 3 Mar 2015 02:40:53 -0800 (PST) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [192.36.171.201]) by outbox.sics.se (Postfix) with ESMTPS id 70E6B13A for ; Tue, 3 Mar 2015 11:40:51 +0100 (CET) Received: from norm.sics.se (norm.sics.se [193.10.64.192]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id t23AepC0030352 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 3 Mar 2015 11:40:51 +0100 Received: from [192.168.0.108] (unknown [85.235.11.178]) by norm.sics.se (Postfix) with ESMTPSA id E78A52C5 for ; Tue, 3 Mar 2015 11:40:50 +0100 (CET) Message-ID: <54F58FB1.9030407@sics.se> Date: Tue, 03 Mar 2015 11:40:49 +0100 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: ace@ietf.org References: <54F57FDE.9010109@gmx.net> In-Reply-To: <54F57FDE.9010109@gmx.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000500060507000606020008" X-Bayes-Prob: 0.5 (Score 0, tokens from: outbound, outbound-sics-se:default, sics-se:default, base:default, @@RPTN) X-p0f-Info: os=Linux 2.2.x-3.x, link=Ethernet or modem X-CanIt-Geo: =?UTF-8?Q?ip=3D85.235.11.178; _country=3DSE; _region=3DSk=C3=A5ne; _city=3DLund; _latitude=3D55.7028; _longitude=3D13.1927; _http://maps.google.com/maps=3Fq=3D55.7028,13.1927&z=3D6?= X-CanItPRO-Stream: outbound-sics-se:outbound (inherits from outbound-sics-se:default, sics-se:default, base:default) X-Canit-Stats-ID: 09NWWEPB9 - 2a262b6b0846 - 20150303 X-Antispam-Training-Forget: https://canit.sunet.se/canit/b.php?i=09NWWEPB9&m=2a262b6b0846&t=20150303&c=f X-Antispam-Training-Nonspam: https://canit.sunet.se/canit/b.php?i=09NWWEPB9&m=2a262b6b0846&t=20150303&c=n X-Antispam-Training-Spam: https://canit.sunet.se/canit/b.php?i=09NWWEPB9&m=2a262b6b0846&t=20150303&c=s X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 85.235.11.178 is neither permitted nor denied by domain ludwig@sics.se) receiver=e-mailfilter01.sunet.se; client-ip=85.235.11.178; envelope-from=; helo=norm.sics.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: Subject: Re: [Ace] Use Case Draft X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 10:40:57 -0000 This is a cryptographically signed message in MIME format. --------------ms000500060507000606020008 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 03/03/2015 10:33 AM, Hannes Tschofenig wrote: > Hi Use Case Draft Authors, > > I read through the latest version of the document and I noticed a few > things. > > a) In http://www.ietf.org/mail-archive/web/ace/current/msg00901.html I > suggested to add another scenario to the home automation use case. I > don't think it has been added (at least I couldn't see it). Did you mis= s > it or did it not find enough interest? > We (the editors) discussed it in comparison to the current 'remote=20 authorization grant' scenario. Obviously including both scenarios would=20 not be useful, since they are too similar, therefore we have to weigh=20 them against each other. The main difference between the currently included scenario and your=20 proposal is that the latter uses proximity based technologies to=20 transfer the authorization information, while in the former the=20 authorization information is transferred over the Internet. We felt that removing the Internet aspect form this scenario would be a=20 bit like removing the "Internet" from the "Internet of Things". Personally I don't have a big issue with replacing the current scenario=20 with the one you propose (there is already plenty of Internet in the=20 other scenarios), but I think Steffi feels a bit stronger about this. > b) I am not convinced about the use case in Section 2.6 "Sports & > Entertainment". To me it reads more like a multi-user operating system > feature rather than something we develop. I am also not sure it "sells"= > well as a use case since it is functionality users wouldn't expect to > experience today. If you give your 400 EUR watch to your friend are you= > really worried about your 4 training runs that are stored on that watch= ? > Today, the person who has the watch can see the data on it and change > (some) settings. What you cannot do (today) is to see your "training > plan" since that wouldn't be stored on the watch anyway. > > I am not sure what a useful use case for this type of sports equipment > actually is (in context of ACE). > Our aim with this use case was to introduce some scenario with lower=20 security requirements, but were privacy issues still makes security=20 "nice to have". As we can expect this type of devices to become more ubiquitous, more=20 and more privacy relevant information will be gathered, which might be=20 innocuous on its own, but allow to generate profiles of the user when=20 combined. Apparently the use case doesn't make this case convincingly, do you=20 suggest we update it or would you advocate removing it? > c) The 'owner' terminology still confuses me. There is the implicit > assumption that the owner can configure policies and then there are > non-owners that cannot. I don't think that ownership has anything to do= > with policy configuration. > The terminology has been subject of some controversy between the=20 authors. The main issue, as I see it, is that specific terminology might = favor specific solutions. As you suggested earlier, some additional reviews of the document could=20 be helpful to give us new perspectives. > d) Here is a question for my own personal interest. I would like to > understand the container use case better and I believe the slides > presented at various IETF meetings showed the use case a bit better (at= > least the involved parties). Is there anywhere (e.g., papers) a > description about the actual 'user experience' (by user I mean the > experience the different parties have). For example, the supermarket > chain will have to receive information about the containers it can trac= k > at some point in time. I assume they will have to have an "account" wit= h > some company (whom?) to actually query the data while the containers ar= e > in transit. Someone will have to configure the policies for each of the= > involved parties at some authorization server. Who is that party? > I think this would be best answered by Steffi. /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 --------------ms000500060507000606020008 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVDCC BhgwggUAoAMCAQICAwyGmDANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTE1MDEwODA4MzkwNloXDTE2MDEwOTIyNDEzMFowODEXMBUGA1UE AwwObHVkd2lnQHNpY3Muc2UxHTAbBgkqhkiG9w0BCQEWDmx1ZHdpZ0BzaWNzLnNlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxUHisC6rgXFsBHHBGo8ulz/cLX3gX5Ufhcwo rp+7djzMMuKPM1KOHq0bjWhmFe8ly8CzWdk2NS600t7IEBQWJiHLsdc12UqmNswQUpD7oqkR 1nRGT6leAHYTWapkR+nczZ2NxD+H7u4ZWVIZg0DFiTqtY8ghYHHYYy8BBoc/jHG78X4+JJAg s5XOa0gVl7W38vDvVpo14xhWEBGjzPk9WxWirqAF66PF+JEu2JD9LzFbpEq829SRXJMFB9wp oQNlH0UQ01/2sWCIBxPpHuEjxEF/V3Z/F2VsNTy4zvYrd+/MYO3w30F+bWQNZsMHEkTW1pEh iz7rQPWTBXoO8Fv0wQIDAQABo4IC1DCCAtAwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTqvKspqEm0E4R1sgsABYKk 6xDJqDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZBgNVHREEEjAQgQ5sdWR3 aWdAc2ljcy5zZTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcC AjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0 aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5 aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQEFBQADggEBAGXwFsbSfv4mMWqIk64CoxuR6ozo7J37igca7d9tpKIzVIp6xp7Zt+a+J9X3 1r4zgMRFnZJWQ5hy82W/fVDeG9i3NGMM6p7DNUrGjTbVHd11BQtbUOG9MSlyWKQbmt3Q1ElC f4SRLAQot5SPryLR2FTxQuFkMOrcDzVxNxnMgatOM2fAO8KS0H+wX+I7gC3pEnbg/eMqNgU+ Ktbc2y9naDNmLNLN65s8TT9xZyoQEn9S1oU8Xnh596OMu49Eccws8Ny+vAGESIHG4bqhMSjj rmDilL1Wj9nQahmBnID5oZD5g9s9KyqxiZIGNnowYYOpCrSeITZ1b7wg50dC8ySojnYwggY0 MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEw MjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0d Lep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiU fsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5Dp IpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuC YKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/ MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0j BBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzAB hhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nm c2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9 eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukD FUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyi kfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8Cnykh ExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b 970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCD z+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqA SfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNb BIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBth HSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+ UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAwyGmDAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTAzMDMxMDQwNDlaMCMGCSqGSIb3DQEJBDEW BBQHGVLjQ56BwprZ9Z54A6Y3QxTvxjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDDIaYMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJKoZIhvcNAQEBBQAE ggEAs473rVNSBOikOtYlBTZGf77rIf3L3Sod6L3ek5zOmbKL07zTUA+URyirlnia+F2LeF/o ot6rfIXTac7t6CkwYdAtZ0BKLlHVeA2HAjKH3XzNj0UHksuNtaStHgR9gOR0sxdHto9A86RT ikg9Yf3mLHpi5BN+EIN3s33WHL91u8Ph4Qhpfpm/Qk1ggu19A5FfEzX+tbNPXrufCEjBQBFP iaCbm6gIs0DRK0LqF3InbjVLYKGWbOih8bsFX1UTRdtSRAno9ls5Ust3g+WIMdD5Uzjhq0tD YMmiSdw4LnmhxQqJeqaO26gx3Z8nE6LvIZoTwC2rqKVimxKZ0ir7S/VhpgAAAAAAAA== --------------ms000500060507000606020008-- From nobody Tue Mar 3 04:29: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 186051A1F02 for ; Tue, 3 Mar 2015 04:29:22 -0800 (PST) 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 uVyWLsDgoQ8f for ; Tue, 3 Mar 2015 04:29:19 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B1041A00F7 for ; Tue, 3 Mar 2015 04:29:19 -0800 (PST) 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 t23CTEOY019172; Tue, 3 Mar 2015 13:29:14 +0100 (CET) Received: from [IPv6:2001:638:708:30da:48f:ac42:7179:61f8] (unknown [IPv6:2001:638:708:30da:48f:ac42:7179:61f8]) (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 3kxHhV6m53z94mZ; Tue, 3 Mar 2015 13:29:14 +0100 (CET) Message-ID: <54F5A915.4010103@tzi.de> Date: Tue, 03 Mar 2015 13:29:09 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ludwig Seitz , "Ace@ietf.org" , Hannes Tschofenig References: <54F57FDE.9010109@gmx.net> <54F58FB1.9030407@sics.se> In-Reply-To: <54F58FB1.9030407@sics.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ace] Use Case Draft X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 12:29:22 -0000 Hi Hannes and Ludwig, On 03/03/2015 11:40 AM, Ludwig Seitz wrote: > On 03/03/2015 10:33 AM, Hannes Tschofenig wrote: >> Hi Use Case Draft Authors, >> >> I read through the latest version of the document and I noticed a few >> things. >> >> a) In http://www.ietf.org/mail-archive/web/ace/current/msg00901.html I >> suggested to add another scenario to the home automation use case. I >> don't think it has been added (at least I couldn't see it). Did you miss >> it or did it not find enough interest? >> > > We (the editors) discussed it in comparison to the current 'remote > authorization grant' scenario. Obviously including both scenarios would > not be useful, since they are too similar, therefore we have to weigh > them against each other. > > The main difference between the currently included scenario and your > proposal is that the latter uses proximity based technologies to > transfer the authorization information, while in the former the > authorization information is transferred over the Internet. > We felt that removing the Internet aspect form this scenario would be a > bit like removing the "Internet" from the "Internet of Things". I would like to add that we changed the scenario as a response to your suggestions and removed the part where Jane's parents download an application that lets them communicate with Jane's door lock. You stated in your e-mail that the scenario requires a messaging infrastructure to exist and hopefully removing that part already helps things. If it is important to you, I guess we can use both scenarios and state that the remote scenario is the more sophisticated one? > > Personally I don't have a big issue with replacing the current scenario > with the one you propose (there is already plenty of Internet in the > other scenarios), but I think Steffi feels a bit stronger about this. > >> b) I am not convinced about the use case in Section 2.6 "Sports & >> Entertainment". To me it reads more like a multi-user operating system >> feature rather than something we develop. I am also not sure it "sells" >> well as a use case since it is functionality users wouldn't expect to >> experience today. If you give your 400 EUR watch to your friend are you >> really worried about your 4 training runs that are stored on that watch? >> Today, the person who has the watch can see the data on it and change >> (some) settings. What you cannot do (today) is to see your "training >> plan" since that wouldn't be stored on the watch anyway. >> >> I am not sure what a useful use case for this type of sports equipment >> actually is (in context of ACE). I think it is interesting to consider. We already see a lot of "smart" sports equipment. The more health related or otherwise personal data is collected by these devices the more important it will be to protect them. Moreover, as Ludwig says, consolidating data of many different devices will reveal even more about a person. Even if you are not that concerned that the person you give your watch to reads your personal data (even if it costs only 80 EUR), you might not want everyone else to also be able to do so. In this case implicit authorization (an authenticated person can see everything on the device) may be sufficient. The interesting aspects about this use case are that users want to grant access dynamically when needed with little effort. Moreover, since the shoes do not have a display, configuring authorization might be a bit more difficult than for e.g. a smartphone. Somehow the shoes need to know that they are allowed to talk to the watch. For the user experience it would be helpful to have a solution that is able to automatically authorize devices of a certain person. If I trust my best friend with my data I would appreciate it if her devices are authorized automatically and I don't have to authorize every single one of it manually. >> > > Our aim with this use case was to introduce some scenario with lower > security requirements, but were privacy issues still makes security > "nice to have". > > As we can expect this type of devices to become more ubiquitous, more > and more privacy relevant information will be gathered, which might be > innocuous on its own, but allow to generate profiles of the user when > combined. > > Apparently the use case doesn't make this case convincingly, do you > suggest we update it or would you advocate removing it? > > >> c) The 'owner' terminology still confuses me. There is the implicit >> assumption that the owner can configure policies and then there are >> non-owners that cannot. I don't think that ownership has anything to do >> with policy configuration. Yes, owner might not be the best of terms. Maybe the term "principal" would be better for the person that is in charge of a device / endpoint / resource. As far as I understood it the controversy Ludwig mentions is about whether the problems of client owners are in scope or not and not that the term "principal" in itself is offending. >> > > The terminology has been subject of some controversy between the > authors. The main issue, as I see it, is that specific terminology might > favor specific solutions. > > As you suggested earlier, some additional reviews of the document could > be helpful to give us new perspectives. > > >> d) Here is a question for my own personal interest. I would like to >> understand the container use case better and I believe the slides >> presented at various IETF meetings showed the use case a bit better (at >> least the involved parties). Is there anywhere (e.g., papers) a >> description about the actual 'user experience' (by user I mean the >> experience the different parties have). For example, the supermarket >> chain will have to receive information about the containers it can track >> at some point in time. I assume they will have to have an "account" with >> some company (whom?) to actually query the data while the containers are >> in transit. Someone will have to configure the policies for each of the >> involved parties at some authorization server. Who is that party? >> There are several aspects to this scenario. I guess you want to know how the fruit vendor keeps track of the state of the goods? As far as I know it, the data of the banana sensors can be queried remotely while the bananas are on the ship. Since the sensors belong to the fruit vendor and the fruit vendor requests the current state of the goods, I guess it is safe to assume that the fruit vendor is the one that will control the access policies in this particular conversation. For the communication between the banana sensors and the ventilation system in the containers a local connection is used (which makes sense since a server in the Internet might not always be reachable during the shipment). Container monitoring is still in an early stage and as far as I know, there is no solution yet for authorization. From a security point of view, both the container owner and the fruit vendor will have to make sure that their devices only send data to and receive data from authorized devices. Does that answer your question? Maybe the paper that is referenced in the draft ("Communication techniques and challenges for wireless food quality monitoring") helps? Best regards, Steffi From nobody Tue Mar 3 05:07: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 DC1A51A6FFE for ; Tue, 3 Mar 2015 05:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 zK5r7dl1BV1u for ; Tue, 3 Mar 2015 05:07:03 -0800 (PST) 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 1698C1A6FFA for ; Tue, 3 Mar 2015 05:07:03 -0800 (PST) Received: from [192.168.131.140] ([80.92.121.102]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M7CRe-1XWxHe1TtO-00x7Kz for ; Tue, 03 Mar 2015 14:07:00 +0100 Message-ID: <54F5B1F2.6050205@gmx.net> Date: Tue, 03 Mar 2015 14:06:58 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Ace@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PcD8EhoEU61ELjkimEHPEWrqIUG7b0les" X-Provags-ID: V03:K0:racRx5p5HKt3gs12iMNMD/u3YTQUOX0tLpcDr0kJn/dQGZYMcVD RUYAk3syHA7T6dJgQkt00Yy3m+G8tiKmUTZ1r5bibVnUF2ClfpBk7nQGWtuHFnyq2sXnZM7 0/QOhFDFXHjs8lvgbVrPO4hFiC+NmGhnNvQIf8i1XgkO4s6fYZHZlMnyeDm2M+fE/QdJrpH dQ6sZ08kWSBPQmIjYAC0g== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [Ace] U1.2 in Use Case Document 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, 03 Mar 2015 13:07:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PcD8EhoEU61ELjkimEHPEWrqIUG7b0les Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, let me try to see whether I understand the issue that's currently under discussion. It seems that the debate focuses on this requirement from the 'Container monitoring' use case: " o U1.2 Principals want to grant different access rights for different resources on an endpoint. " The question that surfaced here is whether 'principal' is the right term or not. The document defines principal as "A subject who is either a resource owner or a client owner or both." Here is a slightly modified example using a door lock scenario that may help us see through this case. Imagine a family with a kid: Alice, Bob and their young child Eve. Alice and Bob bought one of these Internet connected door locks and now want to configure it. They want to configure it in such a way that all three can enter their house just using their smart phone (and a specially loaded app). Whether the authorization server is included in the door lock itself or is part of some other home appliance does not really matter for the moment. In any case, Alice and Bob configure the door lock in such a way that Eve is granted access. Alice and Bob are the owner of the resource (=3Ddoor lock) but even if they do not 'own' the door lock (but have rather rented it) does not really matter. The authorization server does not necessarily need to know that this access control policy is about "Eve". All it cares is that there is an entry in the access control list that points to some credential on some device. That credential happens to point to app on the smart phone Eve is using. Now, the question is how Eve, who is the client owner, fits into that picture. She would use her phone (=3Dclient) to request access to the doo= r but she would not be involved in provisioning the access control policy at the authorization server. Did I correctly understood this issue? Ciao Hannes --PcD8EhoEU61ELjkimEHPEWrqIUG7b0les Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU9bHyAAoJEGhJURNOOiAtdzUH/iZc8GkjQrhiZKswqC00MKiM 2pqvoL3X+zq8L7+273iHPUiyEN6KYLMUUX4+nVP7jH/r1VARKHbfcDety/lAmC4w h0UvE6Palt+OqS2P+SBfPgTEXIsNOdHmzhzhwqlIkxhJeHnzKWS3zeCjHO9KRiEU vQaGepuNvcR85MAIApmYNkN8YLh/q5JO3TdwXwmYCe4mMh6jvzMv5bbeVrWJ7goA QzcDTEwrBQMZ4T0kbmT5WSCTYkszNdxrDvQKAgPwrKcKsQpYvze2VffoUHIchOLT +nbhtKuK6/o1dFXUJlI1pu2SJva8K8GwdebeXolfowIzq2XoV0m+1VXwe3J4x5E= =JpvI -----END PGP SIGNATURE----- --PcD8EhoEU61ELjkimEHPEWrqIUG7b0les-- From nobody Tue Mar 3 05:12: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 CAB9D1A6FF7 for ; Tue, 3 Mar 2015 05:12:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 yoDCAWWpVu76 for ; Tue, 3 Mar 2015 05:12:03 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7B7D1A6F7C for ; Tue, 3 Mar 2015 05:12:02 -0800 (PST) Received: from [192.168.131.140] ([80.92.121.102]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LiTrM-1XuYr41Hki-00cgKK; Tue, 03 Mar 2015 14:11:58 +0100 Message-ID: <54F5B31C.4060506@gmx.net> Date: Tue, 03 Mar 2015 14:11:56 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ludwig Seitz , ace@ietf.org References: <54F57FDE.9010109@gmx.net> <54F58FB1.9030407@sics.se> In-Reply-To: <54F58FB1.9030407@sics.se> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qePsU5nApQOXC5QhBTIlhEPl7UJRJLoA2" X-Provags-ID: V03:K0:tgXaVtCz1rK/6sFQtdWBn3UINA6lxMTOSUdzmaaZElVOy6IVBkT YJvHmv04VYWwub0a1uu2n3O7nNEOWbu/XXMAFnZktzzEoON7WCXnf0cW+pXCycOsre56PCH 8iqpD+IiuLSW7kpYC+cFkUrllsFuwYF1F4N1EKYNVEnppxf0o2G9O7GXdOrsKPH0BgMjrcP Wi1heZaggt7sqYqdXt4Wg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [Ace] Use Case Draft X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 13:12:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qePsU5nApQOXC5QhBTIlhEPl7UJRJLoA2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Ludwig, thanks for the quick response. On 03/03/2015 11:40 AM, Ludwig Seitz wrote: > On 03/03/2015 10:33 AM, Hannes Tschofenig wrote: >> Hi Use Case Draft Authors, >> >> I read through the latest version of the document and I noticed a few >> things. >> >> a) In http://www.ietf.org/mail-archive/web/ace/current/msg00901.html I= >> suggested to add another scenario to the home automation use case. I >> don't think it has been added (at least I couldn't see it). Did you mi= ss >> it or did it not find enough interest? >> >=20 > We (the editors) discussed it in comparison to the current 'remote > authorization grant' scenario. Obviously including both scenarios would= > not be useful, since they are too similar, therefore we have to weigh > them against each other. >=20 > The main difference between the currently included scenario and your > proposal is that the latter uses proximity based technologies to > transfer the authorization information, while in the former the > authorization information is transferred over the Internet. > We felt that removing the Internet aspect form this scenario would be a= > bit like removing the "Internet" from the "Internet of Things". >=20 > Personally I don't have a big issue with replacing the current scenario= > with the one you propose (there is already plenty of Internet in the > other scenarios), but I think Steffi feels a bit stronger about this. >=20 I actually never intended to replace the existing scenario but rather to enhance the existing scenario. I thought that the off-line delegation could be interesting. The rest of the scenario may still involve the Internet. Maybe it is only slightly different than the current scenario and therefore not worth listing it as an extra scenario. >> b) I am not convinced about the use case in Section 2.6 "Sports & >> Entertainment". To me it reads more like a multi-user operating system= >> feature rather than something we develop. I am also not sure it "sells= " >> well as a use case since it is functionality users wouldn't expect to >> experience today. If you give your 400 EUR watch to your friend are yo= u >> really worried about your 4 training runs that are stored on that watc= h? >> Today, the person who has the watch can see the data on it and change >> (some) settings. What you cannot do (today) is to see your "training >> plan" since that wouldn't be stored on the watch anyway. >> >> I am not sure what a useful use case for this type of sports equipment= >> actually is (in context of ACE). >> >=20 > Our aim with this use case was to introduce some scenario with lower > security requirements, but were privacy issues still makes security > "nice to have". >=20 > As we can expect this type of devices to become more ubiquitous, more > and more privacy relevant information will be gathered, which might be > innocuous on its own, but allow to generate profiles of the user when > combined. >=20 > Apparently the use case doesn't make this case convincingly, do you > suggest we update it or would you advocate removing it? Good question. I was not able to come up with a useful alternative. I will keep thinking about it and maybe someone else in the group has a suggestion that fits into the wearable category. >=20 >=20 >> c) The 'owner' terminology still confuses me. There is the implicit >> assumption that the owner can configure policies and then there are >> non-owners that cannot. I don't think that ownership has anything to d= o >> with policy configuration. >> >=20 > The terminology has been subject of some controversy between the > authors. The main issue, as I see it, is that specific terminology migh= t > favor specific solutions. >=20 > As you suggested earlier, some additional reviews of the document could= > be helpful to give us new perspectives. Let's see what the other folks in the group think. >=20 >=20 >> d) Here is a question for my own personal interest. I would like to >> understand the container use case better and I believe the slides >> presented at various IETF meetings showed the use case a bit better (a= t >> least the involved parties). Is there anywhere (e.g., papers) a >> description about the actual 'user experience' (by user I mean the >> experience the different parties have). For example, the supermarket >> chain will have to receive information about the containers it can tra= ck >> at some point in time. I assume they will have to have an "account" wi= th >> some company (whom?) to actually query the data while the containers a= re >> in transit. Someone will have to configure the policies for each of th= e >> involved parties at some authorization server. Who is that party? >> > I think this would be best answered by Steffi. Thanks. Ciao Hannes >=20 >=20 > /Ludwig >=20 >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --qePsU5nApQOXC5QhBTIlhEPl7UJRJLoA2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU9bMcAAoJEGhJURNOOiAtxfIH/iLUko3eP52bCkF6GdqiYqZy 8HA8sq25DCFemZpN3vRrVH9P+ehlM+a+Yeh1dCHuKQH9zXCum9FnrmHvtFXrGToW meGAChDOaMvOyIqQMsYLP0pr0q/Izf79mE54dBYC6jh7jSiGXBdVjWsTA3FvwiNY WeRBL330baG+6qcmdNpf2WgwmyokxBVZSUZ1C7JjLf9X6vynLwniUwGmzEx5wa0l bS9m5ScNZF6DHvKuN9fk2OgMvifQ4/zL7ZsA6aEq54EbtIZYe4etNRd0q8knTein LeQ95kNtVPAhyVSKJ37728vA3cERKY/y0r93AYJeUyNyl5XCXjLXB+8wEwMsQyw= =oZDW -----END PGP SIGNATURE----- --qePsU5nApQOXC5QhBTIlhEPl7UJRJLoA2-- From nobody Tue Mar 3 05:29: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 B67D01A700E for ; Tue, 3 Mar 2015 05:29:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Z5L6H1MPDvC2 for ; Tue, 3 Mar 2015 05:29:40 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C04941A6FF8 for ; Tue, 3 Mar 2015 05:29:39 -0800 (PST) Received: from [192.168.131.140] ([80.92.121.102]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MKIEQ-1YSEOU1bd8-001eIO; Tue, 03 Mar 2015 14:29:36 +0100 Message-ID: <54F5B73E.3040703@gmx.net> Date: Tue, 03 Mar 2015 14:29:34 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Stefanie Gerdes , Ludwig Seitz , "Ace@ietf.org" References: <54F57FDE.9010109@gmx.net> <54F58FB1.9030407@sics.se> <54F5A915.4010103@tzi.de> In-Reply-To: <54F5A915.4010103@tzi.de> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="S38TamDkorqMEp0s0feF8Nncc5AAfaiGt" X-Provags-ID: V03:K0:PA5Zq1dnczl4jj/ZtmUN74u6mJLna2t6aAjNV3ZC3TdjAtIt29m ve5eq9gknXEiDzYmo6ARyqX2uPWMNVeg5SelCS58p5wq2KUoDRrhJqX5JJ//T05ijjecXeG xkasMQcigYohr1vUeUFW5BUQZyZ7sB8AYRHmxlnyC5PEM79hyBNCCxdKuN0MdNBIjf1Ixt/ DiWdSF/HOmMwa7JK4yq5w== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [Ace] Use Case Draft X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 13:29:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --S38TamDkorqMEp0s0feF8Nncc5AAfaiGt Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Steffi, also thanks to you for the quick response. On 03/03/2015 01:29 PM, Stefanie Gerdes wrote: > Hi Hannes and Ludwig, >=20 > On 03/03/2015 11:40 AM, Ludwig Seitz wrote: >> On 03/03/2015 10:33 AM, Hannes Tschofenig wrote: >>> Hi Use Case Draft Authors, >>> >>> I read through the latest version of the document and I noticed a few= >>> things. >>> >>> a) In http://www.ietf.org/mail-archive/web/ace/current/msg00901.html = I >>> suggested to add another scenario to the home automation use case. I >>> don't think it has been added (at least I couldn't see it). Did you m= iss >>> it or did it not find enough interest? >>> >> >> We (the editors) discussed it in comparison to the current 'remote >> authorization grant' scenario. Obviously including both scenarios woul= d >> not be useful, since they are too similar, therefore we have to weigh >> them against each other. >> >> The main difference between the currently included scenario and your >> proposal is that the latter uses proximity based technologies to >> transfer the authorization information, while in the former the >> authorization information is transferred over the Internet. >> We felt that removing the Internet aspect form this scenario would be = a >> bit like removing the "Internet" from the "Internet of Things". >=20 > I would like to add that we changed the scenario as a response to your > suggestions and removed the part where Jane's parents download an > application that lets them communicate with Jane's door lock. You state= d > in your e-mail that the scenario requires a messaging infrastructure to= > exist and hopefully removing that part already helps things. >=20 > If it is important to you, I guess we can use both scenarios and state > that the remote scenario is the more sophisticated one? The current version is certainly more sophisticated than the scenario I proposed since it requires more players to interact. The different "transport" of the authorization credentials using short range radio vs. the Internet might not be sufficient to turn it into a new scenario. I don't know whether the delegation aspect where one party acts as a local authorization server adds much more value. >=20 >> >> Personally I don't have a big issue with replacing the current scenari= o >> with the one you propose (there is already plenty of Internet in the >> other scenarios), but I think Steffi feels a bit stronger about this. >> >>> b) I am not convinced about the use case in Section 2.6 "Sports & >>> Entertainment". To me it reads more like a multi-user operating syste= m >>> feature rather than something we develop. I am also not sure it "sell= s" >>> well as a use case since it is functionality users wouldn't expect to= >>> experience today. If you give your 400 EUR watch to your friend are y= ou >>> really worried about your 4 training runs that are stored on that wat= ch? >>> Today, the person who has the watch can see the data on it and change= >>> (some) settings. What you cannot do (today) is to see your "training >>> plan" since that wouldn't be stored on the watch anyway. >>> >>> I am not sure what a useful use case for this type of sports equipmen= t >>> actually is (in context of ACE). >=20 > I think it is interesting to consider. We already see a lot of "smart" > sports equipment. The more health related or otherwise personal data is= > collected by these devices the more important it will be to protect > them. Moreover, as Ludwig says, consolidating data of many different > devices will reveal even more about a person. >=20 > Even if you are not that concerned that the person you give your watch > to reads your personal data (even if it costs only 80 EUR), you might > not want everyone else to also be able to do so. In this case implicit > authorization (an authenticated person can see everything on the device= ) > may be sufficient. >=20 > The interesting aspects about this use case are that users want to gran= t > access dynamically when needed with little effort. Moreover, since the > shoes do not have a display, configuring authorization might be a bit > more difficult than for e.g. a smartphone. Somehow the shoes need to > know that they are allowed to talk to the watch. >=20 > For the user experience it would be helpful to have a solution that is > able to automatically authorize devices of a certain person. If I trust= > my best friend with my data I would appreciate it if her devices are > authorized automatically and I don't have to authorize every single one= > of it manually. I get the idea. Will think about some potential alternatives that are easier to "sell". >=20 >>> >> >> Our aim with this use case was to introduce some scenario with lower >> security requirements, but were privacy issues still makes security >> "nice to have". >> >> As we can expect this type of devices to become more ubiquitous, more >> and more privacy relevant information will be gathered, which might be= >> innocuous on its own, but allow to generate profiles of the user when= >> combined. >> >> Apparently the use case doesn't make this case convincingly, do you >> suggest we update it or would you advocate removing it? >> >> >>> c) The 'owner' terminology still confuses me. There is the implicit >>> assumption that the owner can configure policies and then there are >>> non-owners that cannot. I don't think that ownership has anything to = do >>> with policy configuration. >=20 > Yes, owner might not be the best of terms. Maybe the term "principal" > would be better for the person that is in charge of a device / endpoint= > / resource. As far as I understood it the controversy Ludwig mentions i= s > about whether the problems of client owners are in scope or not and not= > that the term "principal" in itself is offending. In GEOPRIV we called the party that configures the authorization policies the "Rule Maker". You probably don't like that term too much but it focuses on the aspect that is most important, namely who create the authorization policies. >=20 >>> >> >> The terminology has been subject of some controversy between the >> authors. The main issue, as I see it, is that specific terminology mig= ht >> favor specific solutions. >> >> As you suggested earlier, some additional reviews of the document coul= d >> be helpful to give us new perspectives. >> >> >>> d) Here is a question for my own personal interest. I would like to >>> understand the container use case better and I believe the slides >>> presented at various IETF meetings showed the use case a bit better (= at >>> least the involved parties). Is there anywhere (e.g., papers) a >>> description about the actual 'user experience' (by user I mean the >>> experience the different parties have). For example, the supermarket >>> chain will have to receive information about the containers it can tr= ack >>> at some point in time. I assume they will have to have an "account" w= ith >>> some company (whom?) to actually query the data while the containers = are >>> in transit. Someone will have to configure the policies for each of t= he >>> involved parties at some authorization server. Who is that party? >>> >=20 > There are several aspects to this scenario. I guess you want to know ho= w > the fruit vendor keeps track of the state of the goods? As far as I kno= w > it, the data of the banana sensors can be queried remotely while the > bananas are on the ship. Since the sensors belong to the fruit vendor > and the fruit vendor requests the current state of the goods, I guess i= t > is safe to assume that the fruit vendor is the one that will control th= e > access policies in this particular conversation. >=20 > For the communication between the banana sensors and the ventilation > system in the containers a local connection is used (which makes sense > since a server in the Internet might not always be reachable during the= > shipment). Container monitoring is still in an early stage and as far a= s > I know, there is no solution yet for authorization. From a security > point of view, both the container owner and the fruit vendor will have > to make sure that their devices only send data to and receive data from= > authorized devices. =46rom a monitoring point of view I guess the fruit vendor will configure= access to the data of the fruits as well as the containers rather than having those monitored by different parties. While the fruit vendor may not need to own the containers they will probably be rented. I see the communication internally within the container as a separate problem, more like a "how to configure a small wireless adhoc network". I could even imagine that the (temperature/humidity) sensors are not with the bananas themselves but rather with the container. >=20 > Does that answer your question? Maybe the paper that is referenced in > the draft ("Communication techniques and challenges for wireless food > quality monitoring") helps? I should probably look at that again. Ciao Hannes >=20 > Best regards, > Steffi >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --S38TamDkorqMEp0s0feF8Nncc5AAfaiGt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU9bc+AAoJEGhJURNOOiAtSeIH/2DO9asEMuV3WaMM58sQaGbk mR5iR0KFKCOGnXVvkJ0xJs4fb45rmMVD7F3X9xYKei8L5QIhlk02CEs6//PQuSHm t41Tc0nSq+X9P7PUR6dvzVI2UA/8SXLiXQ1+Qt1X7eFfDWUxqm+6s5i3KSejKCau EObN8bV9Pvwdvj1dPUYjg9fa+d1B1K06bx3YK36e/LG8RQOwCV8uswQmYJ9pXaXh aDxR1s99wILriqk6RDpOoN5OFdHKEy+wTvq2UUK51JGuy6acubKqD9gjJ6tlKU3q KH4mXMPB5dsSAcCyVefm2RmAc3F287/MpfSoNPxB6RUV1KFwSIjxgeothCFRl9M= =DjS4 -----END PGP SIGNATURE----- --S38TamDkorqMEp0s0feF8Nncc5AAfaiGt-- From nobody Tue Mar 3 09:03: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 057D31AC3DF for ; Tue, 3 Mar 2015 09:03:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 H3C7neLwrMdC for ; Tue, 3 Mar 2015 09:03:06 -0800 (PST) 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 D38BD1AC3E1 for ; Tue, 3 Mar 2015 09:03:02 -0800 (PST) X-AuditID: c1b4fb2d-f79aa6d00000359d-bb-54f5e9446d36 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 5E.18.13725.449E5F45; Tue, 3 Mar 2015 18:03:01 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.70]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0210.002; Tue, 3 Mar 2015 18:03:00 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Hannes Tschofenig , "Ace@ietf.org" Thread-Topic: [Ace] U1.2 in Use Case Document Thread-Index: AQHQVbL1RkiN6OYzzEyLTf3fE9ZKCp0K/GYA Date: Tue, 3 Mar 2015 17:03:00 +0000 Message-ID: References: <54F5B1F2.6050205@gmx.net> In-Reply-To: <54F5B1F2.6050205@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.17] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGfG3Rtf15dcQg+OtvBbfv/UwWyzdeY/V gclj8ab9bB5LlvxkCmCK4rJJSc3JLEst0rdL4Mr4eW02e8Esj4qt97cyNjCuceti5OSQEDCR mDylhQ3CFpO4cG89kM3FISRwhFHi6pZbjBDOIkaJ7csvM4JUsQm4SDxoeMQEYosIBEkcuLsA LC4soCOx9e8OIJsDKK4rcX29F0SJkcTBv7uYQWwWARWJI92X2UFsXgELib87J7KA2EICahLH +k+A1XAKqEt8Wf0JLM4IdND3U2vAVjELiEvcejKfCeJQAYkle84zQ9iiEi8f/2MFsUUF9CRW Xm9iAzlBQkBRYnm/HIjJLKApsX6XPoRpLfHlZDrEQEWJKd0PoY4RlDg58wnLBEbxWUh2zUJo noXQPAtJ8ywkzQsYWVcxihanFhfnphsZ66UWZSYXF+fn6eWllmxiBEbZwS2/dXcwrn7teIhR gINRiYd3g/LXECHWxLLiytxDjNIcLErivHbGh0KEBNITS1KzU1MLUovii0pzUosPMTJxcEo1 MOpzflc2ydRf1SO9kLNglc6SS4umvfXW4b0bEDHZssLUZ1vb5M22U9cusO6qP1rS1v2D/8Aj v6SUugnBqw+V/L0wVUlsnc8NV5VfQTuuNwe7+8/WnJru3DLv+t8LV/KUbMLcfDeclVc79n72 niWnK9kcHud/PfVU+2XaMvErdpOSUlx7A+qiLyuxFGckGmoxFxUnAgBMqHHNkwIAAA== Archived-At: Subject: Re: [Ace] U1.2 in Use Case Document 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, 03 Mar 2015 17:03:11 -0000 SGkgSGFubmVzLA0KDQpPbiAyMDE1LTAzLTAzIDE0OjA2LCAiSGFubmVzIFRzY2hvZmVuaWciIDxo YW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PiB3cm90ZToNCg0KPkhpIGFsbCwNCj4NCj5sZXQgbWUg dHJ5IHRvIHNlZSB3aGV0aGVyIEkgdW5kZXJzdGFuZCB0aGUgaXNzdWUgdGhhdCdzIGN1cnJlbnRs eSB1bmRlcg0KPmRpc2N1c3Npb24uDQo+DQo+SXQgc2VlbXMgdGhhdCB0aGUgZGViYXRlIGZvY3Vz ZXMgb24gdGhpcyByZXF1aXJlbWVudCBmcm9tIHRoZSAnQ29udGFpbmVyDQo+bW9uaXRvcmluZycg dXNlIGNhc2U6DQo+DQo+Ig0KPiAgIG8gIFUxLjIgUHJpbmNpcGFscyB3YW50IHRvIGdyYW50IGRp ZmZlcmVudCBhY2Nlc3MgcmlnaHRzIGZvcg0KPiAgICAgIGRpZmZlcmVudCByZXNvdXJjZXMgb24g YW4gZW5kcG9pbnQuDQo+Ig0KDQpBY3R1YWxseSwgd2UgYXJlIG5vdCBkZWJhdGluZyB0aGlzIFUx LjIgcmVxdWlyZW1lbnQuIFN0ZWZmaSBtYWRlIGEgbmV3IHNldA0Kb2YgcmVxdWlyZW1lbnRzLCBz ZWUNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9hY2UvY3VycmVudC9tc2cw MDk4Mi5odG1sDQoNClRoZSBkZWJhdGUgZm9jdXNlZCBvbiB0aGlzIHJlcXVpcmVtZW50IHByb3Bv c2VkIGJ5IFN0ZWZmaToNCg0KIlUxLjFhIFByaW5jaXBhbHMgc3VjaCBhcyB0aGUgZnJ1aXQgdmVu ZG9yLCB0aGUgdHJhbnNsb2FkaW5nIHBlcnNvbm5lbCBvcg0KdGhlIGNvbnRhaW5lciBvd25lcnMg d2FudCB0byBkZWZpbmUgYXV0aG9yaXphdGlvbnMgZm9yIHRoZWlyIHJlc291cmNlcw0KYW5kIGVu ZHBvaW50cy4iDQoNCihJIGluc2VydCDigJxh4oCdLCDigJxi4oCdLCDigJxj4oCdIGV0Yy4gdG8g ZGlzdGluZ3Vpc2ggdGhlIGRpZmZlcmVudCB2ZXJzaW9ucyBvZg0KcmVxdWlyZW1lbnRzKQ0KDQoN ClRoZW4gU3RlZmZpIHByb3Bvc2VkIHRvIHNwbGl0IFUxLjFhIGluIHRoZXNlIHJlcXVpcmVtZW50 czoNCg0KKGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9hY2UvY3VycmVudC9t c2cwMDk5Mi5odG1sKQ0KDQoNCuKAnFUxLjFiOiBSZXNvdXJjZSBPd25lcnMgd2FudCB0byBncmFu dCBkaWZmZXJlbnQgYWNjZXNzIHJpZ2h0cyBmb3IgdGhlaXINCnJlc291cmNlcyB0byBkaWZmZXJl bnQgcGFydGllcy4NCg0KVTEuMmI6IENsaWVudCBPd25lcnMgd2FudCB0byBkZWZpbmUgZm9yIHRo ZWlyIGNsaWVudHMgaWYgYW5kIGhvdyB0aGV5IGFyZQ0KYWxsb3dlZCB0byBhY2Nlc3MgcmVzb3Vy Y2VzIGhvc3RlZCBvbiBhIFJlc291cmNlIFNlcnZlci4iDQoNCg0KUmVmZXJyaW5nIHRvIHRoZSBV MS4xYSwgSSBwcm9wb3NlZCB0byBjbGFyaWZ5IHdoYXQgVTEuMWIgbWVhbnMgaW4gdGVybXMgb2YN CnRoZSBhY3RvcnMgYW5kIHJlc291cmNlcyBvZiB0aGUgdXNlIGNhc2U6DQooaHR0cDovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2FjZS9jdXJyZW50L21zZzAxMDAwLmh0bWwpDQoNCuKA nFUxLjFjOiBSZXNvdXJjZSBPd25lcnMsIHN1Y2ggYXMgZnJ1aXQgdmVuZG9ycyBhbmQgY29udGFp bmVyIG93bmVycywgd2FudA0KdG8NCmdyYW50IGRpZmZlcmVudCBhY2Nlc3MgcmlnaHRzIHRvIGRp ZmZlcmVudCBwYXJ0aWVzIGZvciB0aGVpciByZXNwZWN0aXZlDQpyZXNvdXJjZXMsIHN1Y2ggYXMg dGVtcGVyYXR1cmVzIGFuZCBmYW4gc2V0dGluZ3MuIg0KDQoNClRoaXMgd2FzIG5vdCBhZ3JlZWQs IHNlZSBkaXNjdXNzaW9uIGFib3V0IHJlc291cmNlIGFuZCBjbGllbnQgYmVsb3cuDQoNCldpdGgg cmVnYXJkcyB0byBVMS4yYiwgSSByZXF1ZXN0ZWQgdGhhdCB0aGlzIGFic3RyYWN0IHN0YXRlbWVu dCBzaG91bGQgYmUNCmV4ZW1wbGlmaWVkIHdpdGggYWN0b3JzIGFuZCBjbGllbnQgZGV2aWNlcyBm cm9tIHRoaXMgdXNlIGNhc2UgdG8gYWxsb3cNCmV2ZXJ5b25lIHRvIGZvcm0gYW4gb3BpbmlvbiBp ZiB0aGlzIGlzIGEgcmVsZXZhbnQgYWNjZXNzIGNvbnRyb2wgcHJvYmxlbQ0KaW4gdGhlIHNjb3Bl IG9mIEFDRSBvciBub3QuIElmIHRoYXQgY2Fu4oCZdCBiZSBtYWRlLCB0aGVuIEkgdGhpbmsgdGhp cw0KcmVxdWlyZW1lbnQgaXMgbGVzcyByZWxldmFudCBmb3IgdGhpcyB1c2UgY2FzZSBhbmQgY29u c2lkZXIgbGVhdmUgaXQgb3V0Lg0KDQpOT1RFOiBJ4oCZbSBub3Qgc2F5aW5nIFUxLjJiIGlzIG5v dCBhIHBvc3NpYmxlIHNlY3VyaXR5IGNvbmNlcm4uIEnigJltDQpxdWVzdGlvbmluZyB0aGF0IGl0 IGlzIGFuIGFjY2VzcyBjb250cm9sIHByb2JsZW0gYW5hbG9nb3VzIHRvIFUxLjFiLiBUaGUNCm9y aWdpbmFsIHJlcXVpcmVtZW50IGZvcm11bGF0aW9uIFUxLjEgKGluIHRoZSBkcmFmdCkgYW5kIFUx LjFhIGJsdXJzIHRoZQ0KZGlzdGluY3Rpb24gYmV0d2VlbiByZXNvdXJjZSBhbmQgY2xpZW50IGFu ZCBnaXZlcyB0aGUgaW1wcmVzc2lvbiB0aGF0DQp0aGVyZSBpcyBhbiBhbmFsb2dvdXMgY2xpZW50 IGFjY2VzcyBjb250cm9sIHByb2JsZW0sIGJ1dCBJIGRvbuKAmXQgc2VlIGFueQ0KZXZpZGVuY2Ug b2YgdGhhdCBmcm9tIHRoZSB1c2UgY2FzZXMuIEFuZCB0aGUgY3VycmVudCB0ZXJtaW5vbG9neSBp cyBtYWtpbmcNCnRoZSBkaXN0aW5jdGlvbiBkaWZmaWN1bHQuDQoNCk5vdyB3ZSBtYWtlIHRoZSBz YW1lIGV4ZXJjaXNlIGluIHlvdXIgZXhhbXBsZSBiZWxvdy4NCg0KPg0KPlRoZSBxdWVzdGlvbiB0 aGF0IHN1cmZhY2VkIGhlcmUgaXMgd2hldGhlciAncHJpbmNpcGFsJyBpcyB0aGUgcmlnaHQgdGVy bQ0KPm9yIG5vdC4gVGhlIGRvY3VtZW50IGRlZmluZXMgcHJpbmNpcGFsIGFzICJBIHN1YmplY3Qg d2hvIGlzIGVpdGhlciBhDQo+cmVzb3VyY2Ugb3duZXIgb3IgYSBjbGllbnQgb3duZXIgb3IgYm90 aC4iDQo+DQo+SGVyZSBpcyBhIHNsaWdodGx5IG1vZGlmaWVkIGV4YW1wbGUgdXNpbmcgYSBkb29y IGxvY2sgc2NlbmFyaW8gdGhhdCBtYXkNCj5oZWxwIHVzIHNlZSB0aHJvdWdoIHRoaXMgY2FzZS4g SW1hZ2luZSBhIGZhbWlseSB3aXRoIGEga2lkOiBBbGljZSwgQm9iDQo+YW5kIHRoZWlyIHlvdW5n IGNoaWxkIEV2ZS4NCj4NCj5BbGljZSBhbmQgQm9iIGJvdWdodCBvbmUgb2YgdGhlc2UgSW50ZXJu ZXQgY29ubmVjdGVkIGRvb3IgbG9ja3MgYW5kIG5vdw0KPndhbnQgdG8gY29uZmlndXJlIGl0LiBU aGV5IHdhbnQgdG8gY29uZmlndXJlIGl0IGluIHN1Y2ggYSB3YXkgdGhhdCBhbGwNCj50aHJlZSBj YW4gZW50ZXIgdGhlaXIgaG91c2UganVzdCB1c2luZyB0aGVpciBzbWFydCBwaG9uZSAoYW5kIGEN Cj5zcGVjaWFsbHkgbG9hZGVkIGFwcCkuDQo+DQo+V2hldGhlciB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgaXMgaW5jbHVkZWQgaW4gdGhlIGRvb3IgbG9jayBpdHNlbGYgb3INCj5pcyBwYXJ0IG9m IHNvbWUgb3RoZXIgaG9tZSBhcHBsaWFuY2UgZG9lcyBub3QgcmVhbGx5IG1hdHRlciBmb3IgdGhl DQo+bW9tZW50LiBJbiBhbnkgY2FzZSwgQWxpY2UgYW5kIEJvYiBjb25maWd1cmUgdGhlIGRvb3Ig bG9jayBpbiBzdWNoIGEgd2F5DQo+dGhhdCBFdmUgaXMgZ3JhbnRlZCBhY2Nlc3MuIEFsaWNlIGFu ZCBCb2IgYXJlIHRoZSBvd25lciBvZiB0aGUgcmVzb3VyY2UNCj4oPWRvb3IgbG9jaykgYnV0IGV2 ZW4gaWYgdGhleSBkbyBub3QgJ293bicgdGhlIGRvb3IgbG9jayAoYnV0IGhhdmUNCj5yYXRoZXIg cmVudGVkIGl0KSBkb2VzIG5vdCByZWFsbHkgbWF0dGVyLg0KDQpJIGFncmVlIGFib3V0IOKAnG93 bmVyc2hpcOKAnSwgYnV0IGxldOKAmXMga2VlcCB0aGUgdGVybWlub2xvZ3kgaW4gdGhpcyBleGFt cGxlLg0KDQo+DQo+VGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGRvZXMgbm90IG5lY2Vzc2FyaWx5 IG5lZWQgdG8ga25vdyB0aGF0IHRoaXMNCj5hY2Nlc3MgY29udHJvbCBwb2xpY3kgaXMgYWJvdXQg IkV2ZSIuIEFsbCBpdCBjYXJlcyBpcyB0aGF0IHRoZXJlIGlzIGFuDQo+ZW50cnkgaW4gdGhlIGFj Y2VzcyBjb250cm9sIGxpc3QgdGhhdCBwb2ludHMgdG8gc29tZSBjcmVkZW50aWFsIG9uIHNvbWUN Cj5kZXZpY2UuIFRoYXQgY3JlZGVudGlhbCBoYXBwZW5zIHRvIHBvaW50IHRvIGFwcCBvbiB0aGUg c21hcnQgcGhvbmUgRXZlDQo+aXMgdXNpbmcuDQo+DQo+Tm93LCB0aGUgcXVlc3Rpb24gaXMgaG93 IEV2ZSwgd2hvIGlzIHRoZSBjbGllbnQgb3duZXIsIGZpdHMgaW50byB0aGF0DQo+cGljdHVyZS4g U2hlIHdvdWxkIHVzZSBoZXIgcGhvbmUgKD1jbGllbnQpIHRvIHJlcXVlc3QgYWNjZXNzIHRvIHRo ZSBkb29yDQo+YnV0IHNoZSB3b3VsZCBub3QgYmUgaW52b2x2ZWQgaW4gcHJvdmlzaW9uaW5nIHRo ZSBhY2Nlc3MgY29udHJvbCBwb2xpY3kNCj5hdCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuDQo+ DQo+RGlkIEkgY29ycmVjdGx5IHVuZGVyc3Rvb2QgdGhpcyBpc3N1ZT8NCg0KSSB0aGluayB5b3Ug YXJlIGNvcnJlY3QgaW4gdGhhdCB0aGUgZGlzY3Vzc2lvbiBpcyBob3cgdGhlIGNsaWVudCBvd25l cg0KZml0cyBpbnRvIHRoZSBwaWN0dXJlLg0KDQpXaGV0aGVyIHRoZSBwaG9uZSBpcyBpbnZvbHZl ZCBvciBub3QgaW4gdHJhbnNwb3J0aW5nIGFjY2VzcyBjb250cm9sIHBvbGljeQ0Kb3Igb3RoZXIg YXV0aG9yaXphdGlvbiBpbmZvcm1hdGlvbiB0byB0aGUgcmVzb3VyY2Ugc2VydmVyIGlzIG5vdCB0 aGUgaXNzdWUuDQoNCk9uZSBpc3N1ZSB3ZSBoYXZlIGlzIGlmIHRoZSBkb29yIGxvY2sgY2FuIGJl IGNhbGxlZCDigJxSZXNvdXJjZeKAnSBvciBpZiBpdCBpcw0KY29tcGxldGVseSBhcmJpdHJhcnkg d2hpY2ggaXMg4oCcUmVzb3VyY2UiIGFuZCB3aGljaCBpcyDigJxDbGllbnTigJ0uIChJ4oCZbSBp bg0KZmF2b3VyIG9mIHRoZSBmb3JtZXIuKQ0KDQpPbmUgdGhpbmcgd2UgZG8gYWdyZWUgYWJvdXQg aXMgdGhhdCB0aGUgdGVuYW50cywgQWxpY2UgYW5kIEJvYiwgc2hvdWxkIGJlDQphYmxlIHRvIHNl dCBhY2Nlc3MgcG9saWNpZXMgZm9yIHRoZSBsb2NrLiBJIHRoaW5rIHRoaXMgaXMgdGhlIGFuYWxv Z3VlIG9mDQpVMS4xYi9jLiBCdXQgc2luY2Ugd2UgY2Fu4oCZdCBhZ3JlZWQgd2hldGhlciB0aGUg bG9jayBpcyDigJxSZXNvdXJjZSIgb3IgY2FuDQphbHRlcm5hdGl2ZWx5IGJlIOKAnENsaWVudCIs IEkgY2Fu4oCZdCB1c2UgdGhlIHRlcm0g4oCcUmVzb3VyY2UgT3duZXLigJ0uICBOb3IgY2FuDQp3 ZSB1c2UgdGhlIHRlcm0g4oCcQ2xpZW50IE93bmVy4oCdLiBXaXRoIHJlZ2FyZHMgdG8gdGhpcywg SSBoYXZlIGJlZW4NCnF1ZXN0aW9uaW5nIHRoZSB1c2VmdWxuZXNzIG9mIHRoZSBjdXJyZW50IHRl cm1pbm9sb2d5IGluIHRoZSBkcmFmdCwgb3IgaG93DQppdCBpcyBhcHBsaWVkLg0KDQpNYXliZSB3 ZSBjYW4gdXNlIHRoZSBxdWFsaWZpY2F0aW9uIOKAnGxvY2stUmVzb3VyY2UiIGFuZCDigJxsb2Nr LUNsaWVudCIgdG8NCmRpc3Rpbmd1aXNoIGZyb20gb3RoZXIgcmVzb3VyY2VzIGFuZCBjbGllbnRz PyBBbmQgdGhlbiDigJxsb2NrLVJlc291cmNlDQpPd25lcuKAnSAoQWxpY2UgYW5kIEJvYikgYW5k IOKAnGxvY2stQ2xpZW50IE93bmVy4oCdIChFdmUpIHdvdWxkIGFsc28gYmUgd2VsbA0KZGVmaW5l ZD8NCg0KDQpUaGUgb3RoZXIgaXNzdWUgcmVsYXRlcyB0byB3aGF0IGlzIHRoZSBwcm9ibGVtIGZv ciBFdmUuIENvbnNpZGVyIHRoZQ0KYW5hbG9ndWUgb2YgVTEuMmIgYWJvdmUgaW4gdGhpcyBzZXR0 aW5nOg0KDQpVMS4yYjogIkV2ZSB3YW50cyB0byBkZWZpbmUgZm9yIGhlciBwaG9uZSBpZiBhbmQg aG93IGl0IGlzIGFsbG93IHRvDQpyZXF1ZXN0IHRoZSBsb2NrIHRvIGJlIG9wZW5lZC4iDQoNClRv IG1lIGl0IGlzIHF1aXRlIGNsZWFyIHRoYXQgdGhpcyBpcyBhbiBhd2t3YXJkIHdheSBvZiBmb3Jj aW5nIGFuIGFjY2Vzcw0KY29udHJvbCBwcm9ibGVtIGZvcm11bGF0aW9uIGludG8gd2hhdCBpc27i gJl0LiBXaGVuIEV2ZSB3YW50cyB0byBvcGVuIGENCmxvY2ssIHNoZSBwcmVzc2VzIGEgYnV0dG9u IGluIHRoZSBhcHAsIHRoZXJlYnkgYXV0aG9yaXplcyB0aGUgcmVxdWVzdC4NClRoZXJlIGlzIG5v IG5lZWQgdG8gc29sdmUgdGhpcyB3aXRoIGFjY2VzcyBjb250cm9sIHBvbGljaWVzLCB0cmFuc3Bv cnQNCmF1dGhvcml6YXRpb24gaW5mb3JtYXRpb24sIGVuZm9yY2VtZW50IGV0Yy4gIFRoZXJlIGlz IGEgbmF0dXJhbCBhc3ltbWV0cnkNCndoaWNoIGlzIGNsZWFybHkgaWxsdXN0cmF0ZWQgaW4gdGhl IHVzZSBjYXNlcy4gV2Ugc2hvdWxkIG5vdCBoaWRlIHRoYXQNCmJlaGluZCBzdHJhbmdlIHRlcm1p bm9sb2d5IGFuZCBmb3JtdWxhdGlvbnMuDQoNCldpdGggdGhpcyBpbiBtaW5kLCB0aGUgdGVybSDi gJxwcmluY2lwYWzigJ0gd2hpY2ggaW4gYWxtb3N0IGV2ZXJ5IHVzZSBjYXNlIGluDQp0aGUgY3Vy cmVudCB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBnaXZlcyB0aGUgZmFsc2UgaW1wcmVzc2lvbiB0aGF0 IHRoZXJlIGlzDQphIHN5bW1ldHJ5IGluICJjbGllbnQgb3duZXIiIGFuZCDigJxyZXNvdXJjZSBv d25lcuKAnS4gSSB0aGluayB3ZSBzaG91bGQNCnJlbW92ZSB0aGUgdGVybSDigJxwcmluY2lwYWzi gJ0sIGV4cHJlc3MgaW4gZWFjaCB1c2UgY2FzZSB3aGF0IGFyZSB0aGUgYWNjZXNzDQpjb250cm9s IHByb2JsZW1zIGluIHRlcm1zIG9mIHRoZSDigJxSZXNvdXJjZSBPd25lcnPigJ0gYW5kIChpZiBh bnkpIOKAnENsaWVudA0KT3duZXJz4oCdIGFuZCBpbiBlYWNoIGNhc2UgZXhlbXBsaWZ5IHdpdGgg dGhlIGFjdG9ycyBpbiB0aGUgdXNlIGNhc2UuDQoNCg0KUmVnYXJkcywNCkfDtnJhbg0KDQoNCg0K DQo+DQo+Q2lhbw0KPkhhbm5lcw0KPg0KDQo= From nobody Tue Mar 3 12:17: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 E60951A8776 for ; Tue, 3 Mar 2015 12:17:32 -0800 (PST) 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 X887ioiKR6KK for ; Tue, 3 Mar 2015 12:17:30 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD8981A1B9C for ; Tue, 3 Mar 2015 12:17:29 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t23KHJUm025376; Tue, 3 Mar 2015 21:17:19 +0100 (CET) Received: from [IPv6:2001:638:708:30da:48f:ac42:7179:61f8] (unknown [IPv6:2001:638:708:30da:48f:ac42:7179:61f8]) (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 3kxV4b32BQz956v; Tue, 3 Mar 2015 21:17:19 +0100 (CET) Message-ID: <54F616CF.20607@tzi.de> Date: Tue, 03 Mar 2015 21:17:19 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= , Hannes Tschofenig , "Ace@ietf.org" References: <54F5B1F2.6050205@gmx.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] U1.2 in Use Case Document 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, 03 Mar 2015 20:17:33 -0000 Hi all, On 03/03/2015 06:03 PM, Göran Selander wrote: > Hi Hannes, > > On 2015-03-03 14:06, "Hannes Tschofenig" wrote: > >> Hi all, >> >> let me try to see whether I understand the issue that's currently under >> discussion. >> >> It seems that the debate focuses on this requirement from the 'Container >> monitoring' use case: >> >> " >> o U1.2 Principals want to grant different access rights for >> different resources on an endpoint. >> " > > Actually, we are not debating this U1.2 requirement. Steffi made a new set > of requirements, see > http://www.ietf.org/mail-archive/web/ace/current/msg00982.html > > The debate focused on this requirement proposed by Steffi: > > "U1.1a Principals such as the fruit vendor, the transloading personnel or > the container owners want to define authorizations for their resources > and endpoints." > > (I insert “a”, “b”, “c” etc. to distinguish the different versions of > requirements) > > > Then Steffi proposed to split U1.1a in these requirements: > > (http://www.ietf.org/mail-archive/web/ace/current/msg00992.html) > > > “U1.1b: Resource Owners want to grant different access rights for their > resources to different parties. > > U1.2b: Client Owners want to define for their clients if and how they are > allowed to access resources hosted on a Resource Server." In fact I didn't want to split U1.1a. You, Göran, proposed in http://www.ietf.org/mail-archive/web/ace/current/msg00991.html to replace U1.1 with two "requirements" as you called them. I am not happy with this proposal but would have agreed to it if it helped things. The meaning of the original U1.1 problem is that principals in this use case want to grant different authorizations to different people / devices / resources (meaning that devices of company A get different access rights then devices of company B). It seems that it is quite difficult to find a neutral phrasing for this problem. The split now shows a completely different aspect of this problem: we can protect the client side or we can protect the server side or both. These really are solution specific and as we can see, this leads to people wanting to defend their favorite solution. Instead of: "users somehow want to grant different authorizations to different people" we are deep into a solution space discussion about whether it is more useful to protect the server or the client side, if the client side even needs protection and so on. I would like to emphasize that this is not what U1.1 is about. Maybe we can still find a better phrasing that does not indicate a specific solution. The different proposals for the phrasing of U1.1 indicate a different problem: Do we want to develop a solution that exclusively protects resources or do we also want to consider the client side? Most of us are more familiar with the protection of resources because we already know that from web scenarios. But in these scenarios we always have a user that performs authorization on the client side. For constrained environments, it is not always that simple. We might have true machine to machine (M2M) communication where a device must decide for itself whether something is authorized by its user or not. Moreover, devices might not have displays and thus it might not be possible for the user to directly interact with the device for authorization. Solving these problems is not optional. And I think it is important to be aware of these problems. A solution can decide if and how to solve them. > > > Referring to the U1.1a, I proposed to clarify what U1.1b means in terms of > the actors and resources of the use case: > (http://www.ietf.org/mail-archive/web/ace/current/msg01000.html) > > “U1.1c: Resource Owners, such as fruit vendors and container owners, want > to > grant different access rights to different parties for their respective > resources, such as temperatures and fan settings." > > > This was not agreed, see discussion about resource and client below. > > With regards to U1.2b, I requested that this abstract statement should be > exemplified with actors and client devices from this use case to allow > everyone to form an opinion if this is a relevant access control problem > in the scope of ACE or not. If that can’t be made, then I think this > requirement is less relevant for this use case and consider leave it out. Imagine a specific implementation of the container scenario where the temperature sensor is the client and the fan actuator is the server. The fruit vendor wants to make sure that the temperature sensor sends the temperature values only to authorized fan actuator resources because she doesn't want unauthorized people to gain knowledge about the state of the goods. The container owner wants to make sure that the server only accepts data from authorized clients. In this case, both the client owner and the resource owner will need to define access policies. The client owner (the fruit vendor) defines a rule that states that the client (the temperature sensor) is allowed to do a PUT on resources that belong to a specific container owner. The resource owner (the container owner) defines a rule that states that clients of a certain fruit vendor are allowed to do a PUT on their resources. If the temperature sensor is not able to decide if a resource is authorized, it cannot enforce the authorization decisions of its owner. > > NOTE: I’m not saying U1.2b is not a possible security concern. I’m > questioning that it is an access control problem analogous to U1.1b. The > original requirement formulation U1.1 (in the draft) and U1.1a blurs the > distinction between resource and client and gives the impression that > there is an analogous client access control problem, but I don’t see any > evidence of that from the use cases. And the current terminology is making > the distinction difficult. > > Now we make the same exercise in your example below. > >> >> The question that surfaced here is whether 'principal' is the right term >> or not. The document defines principal as "A subject who is either a >> resource owner or a client owner or both." >> >> Here is a slightly modified example using a door lock scenario that may >> help us see through this case. Imagine a family with a kid: Alice, Bob >> and their young child Eve. >> >> Alice and Bob bought one of these Internet connected door locks and now >> want to configure it. They want to configure it in such a way that all >> three can enter their house just using their smart phone (and a >> specially loaded app). >> >> Whether the authorization server is included in the door lock itself or >> is part of some other home appliance does not really matter for the >> moment. In any case, Alice and Bob configure the door lock in such a way >> that Eve is granted access. Alice and Bob are the owner of the resource >> (=door lock) but even if they do not 'own' the door lock (but have >> rather rented it) does not really matter. > > I agree about “ownership”, but let’s keep the terminology in this example. > >> >> The authorization server does not necessarily need to know that this >> access control policy is about "Eve". All it cares is that there is an >> entry in the access control list that points to some credential on some >> device. That credential happens to point to app on the smart phone Eve >> is using. >> >> Now, the question is how Eve, who is the client owner, fits into that >> picture. She would use her phone (=client) to request access to the door >> but she would not be involved in provisioning the access control policy >> at the authorization server. >> >> Did I correctly understood this issue? > > I think you are correct in that the discussion is how the client owner > fits into the picture. I would also think that this is the problem. Eve uses her smartphone to request access to the door and is granted access depending on Alice and Bobs authorization. Eve has no influence on their decision. In the door lock case this might not a big problem. Eve actively uses her smartphone to interact with the door lock. The phone might also display some kind of dialog where Eve can decide to access the door lock or not. If Eve doesn't use her phone but a constrained device to access, e.g. some sort of key fob, she might want to make sure that it doesn't provide her credentials to everyone who is asking. > > Whether the phone is involved or not in transporting access control policy > or other authorization information to the resource server is not the issue. > > One issue we have is if the door lock can be called “Resource” or if it is > completely arbitrary which is “Resource" and which is “Client”. (I’m in > favour of the former.) > > One thing we do agree about is that the tenants, Alice and Bob, should be > able to set access policies for the lock. I think this is the analogue of > U1.1b/c. But since we can’t agreed whether the lock is “Resource" or can > alternatively be “Client", I can’t use the term “Resource Owner”. Nor can > we use the term “Client Owner”. With regards to this, I have been > questioning the usefulness of the current terminology in the draft, or how > it is applied. In the use cases document, we are defining use cases for constrained environments. Where needed, we assume CoAP as the used protocol. In CoAP we have two endpoints, the client and the server, that are communicating with each other. The server hosts resources that can be accessed by the client. We could define that a door lock MUST be a CoAP server and that the device accessing the door lock MUST be a CoAP client or vice versa. If there is no strong evidence to do so, I would rather not restrict CoAP implementations in such a way. It seems wrong to me to say that CoAP is flexible enough to allow for all kinds of settings but unfortunately our authorization solution does not consider this flexibility which is why CoAP is less flexible if we are using authorization. > > Maybe we can use the qualification “lock-Resource" and “lock-Client" to > distinguish from other resources and clients? And then “lock-Resource > Owner” (Alice and Bob) and “lock-Client Owner” (Eve) would also be well > defined? > > > The other issue relates to what is the problem for Eve. Consider the > analogue of U1.2b above in this setting: > > U1.2b: "Eve wants to define for her phone if and how it is allow to > request the lock to be opened." > > To me it is quite clear that this is an awkward way of forcing an access > control problem formulation into what isn’t. When Eve wants to open a > lock, she presses a button in the app, thereby authorizes the request. > There is no need to solve this with access control policies, transport > authorization information, enforcement etc. There is a natural asymmetry > which is clearly illustrated in the use cases. We should not hide that > behind strange terminology and formulations. Yes, exactly, Eve is authorizing the request. And in this specific scenario implicit authorization (an authenticated device is authorized) might be good enough. Since Eve can decide what her smartphone is supposed to do, there is no need for more sophisticated authorization policies. This is different for other use cases. If you think about it, there is also no need for sophisticated authorization on the door lock side, either. It might be sufficient if a device that can be authenticated is authorized to open the door. In this case, implicit authorization is sufficient on both sides. Again this is different for other use cases. Best regards, Steffi From nobody Tue Mar 3 19:25: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 1D10E1A015F for ; Tue, 3 Mar 2015 19:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.3 X-Spam-Level: * X-Spam-Status: No, score=1.3 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FROM_DOMAIN_NOVOWEL=0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKXTEF_Wt3jB for ; Tue, 3 Mar 2015 19:25:29 -0800 (PST) Received: from mail.promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id 067381A0145 for ; Tue, 3 Mar 2015 19:25:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.promanage-inc.com (Postfix) with ESMTP id DBC8E71F5844; Tue, 3 Mar 2015 19:25:28 -0800 (PST) X-Virus-Scanned: amavisd-new at promanage-inc.com Received: from mail.promanage-inc.com ([127.0.0.1]) by localhost (greendome.promanage-inc.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHGcnxPa2xgv; Tue, 3 Mar 2015 19:25:28 -0800 (PST) Received: from [192.168.168.101] (unknown [192.168.168.101]) by mail.promanage-inc.com (Postfix) with ESMTPS id 1653571F5837; Tue, 3 Mar 2015 19:25:28 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=us-ascii From: Eve Maler In-Reply-To: <54F5B1F2.6050205@gmx.net> Date: Tue, 3 Mar 2015 19:25:27 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54F5B1F2.6050205@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] U1.2 in Use Case Document 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, 04 Mar 2015 03:25:31 -0000 It seems to me that Eve (ahem), as the owner of the client, is just = seeking access to a resource that Alice or Bob controls access to but = can't be described as an owner of anything else. There are indeed, = however, several "subjects" in this picture, that is, several identities = worth tracking and authenticating. There is an inherent (and valuable for ACE purposes) asymmetry in the = relationship between those who are in a position to grant access and = those who seek it. If the tables are turned for some other resource, = with Eve in the resource owner role and Alice in the client owner role, = that doesn't make it a two-way relationship -- it's still two one-way = relationships. FWIW, here is the terminology used in UMA on the technical and = contractual levels for all these concepts: Technical Contractual -- Individual (human) -- Non-Person Entity ("legal person" like a company) -- Subject (can be an individual or an NPE) (all of the rest are a kind of Subject...) resource owner Authorizing Party authorization server Authorization Server Operator resource server Resource Server Operator client Client Operator (e.g. Google, running Google Apps) requesting party Requesting Party -- Requesting Party Agent (e.g. an employee of a = corporate RqP) The kind of Principal meant in the use case doc, I would argue, is = exclusively the resource owner kind of principal. If you want to go back = and see definitions, UMA gets its definition of resource owner from = OAuth, which defines it as "An entity capable of granting access to a = protected resource." The client, on the other hand, is about "making = protected resource requests with the resource owner's authorization and = on the requesting party's behalf." This makes the asymmetry clear. Eve > On 3 Mar 2015, at 5:06 AM, Hannes Tschofenig = wrote: >=20 > Hi all, >=20 > let me try to see whether I understand the issue that's currently = under > discussion. >=20 > It seems that the debate focuses on this requirement from the = 'Container > monitoring' use case: >=20 > " > o U1.2 Principals want to grant different access rights for > different resources on an endpoint. > " >=20 > The question that surfaced here is whether 'principal' is the right = term > or not. The document defines principal as "A subject who is either a > resource owner or a client owner or both." >=20 > Here is a slightly modified example using a door lock scenario that = may > help us see through this case. Imagine a family with a kid: Alice, Bob > and their young child Eve. >=20 > Alice and Bob bought one of these Internet connected door locks and = now > want to configure it. They want to configure it in such a way that all > three can enter their house just using their smart phone (and a > specially loaded app). >=20 > Whether the authorization server is included in the door lock itself = or > is part of some other home appliance does not really matter for the > moment. In any case, Alice and Bob configure the door lock in such a = way > that Eve is granted access. Alice and Bob are the owner of the = resource > (=3Ddoor lock) but even if they do not 'own' the door lock (but have > rather rented it) does not really matter. >=20 > The authorization server does not necessarily need to know that this > access control policy is about "Eve". All it cares is that there is an > entry in the access control list that points to some credential on = some > device. That credential happens to point to app on the smart phone Eve > is using. >=20 > Now, the question is how Eve, who is the client owner, fits into that > picture. She would use her phone (=3Dclient) to request access to the = door > but she would not be involved in provisioning the access control = policy > at the authorization server. >=20 > Did I correctly understood this issue? >=20 > Ciao > Hannes >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl From nobody Tue Mar 3 23:56:44 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5001A0469 for ; Tue, 3 Mar 2015 23:56:43 -0800 (PST) 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 X7v76HWhof54 for ; Tue, 3 Mar 2015 23:56:41 -0800 (PST) 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 97DF31A03FF for ; Tue, 3 Mar 2015 23:56:40 -0800 (PST) X-AuditID: c1b4fb3a-f79036d000001e94-06-54f6bab690c4 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A3.6E.07828.6BAB6F45; Wed, 4 Mar 2015 08:56:38 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.70]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0210.002; Wed, 4 Mar 2015 08:56:37 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Eve Maler , Hannes Tschofenig Thread-Topic: [Ace] U1.2 in Use Case Document Thread-Index: AQHQVbL1RkiN6OYzzEyLTf3fE9ZKCp0LmY6AgABch4A= Date: Wed, 4 Mar 2015 07:56:37 +0000 Message-ID: References: <54F5B1F2.6050205@gmx.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-ID: <7F0CDA94C7678945A76E55D1996DF408@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGIsWRmVeSWpSXmKPExsUyM+Jvje62Xd9CDNZ16lh8/9bDbPHuwlJG i6U777E6MHss3rSfzWPJkp9MHvtarrIFMEdx2aSk5mSWpRbp2yVwZUxd84Ct4JdJxfa+n6wN jGeMuxg5OSQETCT+Nf5ng7DFJC7cWw9kc3EICRxhlNjQtZAdwlnEKNG5sxWsik3AReJBwyMm EFtEwE/i+KsGdhCbWUBRYvess2C2sICOxNa/Oxi7GDmAanQlrq/36mJkBzKtJCZKgxSwCKhI tJ9YwgpSwCtgIbHmijVIWEggWuLw9SZGEJtTwF5i8rxdzCA2I9Bl30+tYYLYIy5x68l8JoiL BSSW7DnPDGGLSrx8/I8VxBYV0JNYeb0J6islicYlT8BWMQtoSqzfpQ8xxlriYO96JpjTp3Q/ BDudV0BQ4uTMJywTGCVmIdk2C6F7FpLuWUi6ZyHpXsDIuopRtDi1uDg33chIL7UoM7m4OD9P Ly+1ZBMjMCIPbvlttYPx4HPHQ4wCHIxKPLwGpd9ChFgTy4orcw8xSnOwKInz2hkfChESSE8s Sc1OTS1ILYovKs1JLT7EyMTBKdXAaLojX4H7hq/I28J1+3OeTm9Rk+Fe19dyU7Yk7U/UmkVW bBNOG00OvRoWcqKBXfOYtk29YdYjttjGhGlux6R38nH7nNapvM++5vNEta/vDmzznPxjefm9 DWJHmTY33/1v9IxN4nriJ6aeDovp1mq/DwSeuOAiavxr/+pYVb+UlRbvrad2fLsWqsRSnJFo qMVcVJwIAFmpSompAgAA Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] U1.2 in Use Case Document 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, 04 Mar 2015 07:56:43 -0000 VGhhbmsgeW91IEV2ZSENCg0KVGhpcyBpcyBleGFjdGx5IHdoYXQgSSB3YW50ZWQgdG8gc2F5LCBi dXQgYXBwZWFyZW50bHkgZGlkbuKAmXQgbWFuYWdlIHRvDQpmb3JtdWxhdGUuDQoNCknigJltIGhh cHB5IHdpdGggaW1wbGVtZW50aW5nIHRoaXMgaW4gdGhlIHVzZSBjYXNlIGRyYWZ0IGFuZCBJIGV4 cGVjdCB0aGF0DQp3b3VsZCByZXNvbHZlIGFsbCBvZiBteSBjb25jZXJucy4gIEhvd2V2ZXIsIEkg ZG9u4oCZdCBzZWUgdGhlIHJlYXNvbiB0byBoYXZlDQpib3RoICJSZXNvdXJjZSBPd25lcuKAnS/i gJxBdXRob3JpemluZyBQYXJ0eSIgYW5kIOKAnFByaW5jaXBhbOKAnSBpZiB0aGV5IGFyZQ0Kc3lu b255bXMsIGJ1dCB0aGF0IGlzIGp1c3QgYSBtaW5vciBkZXRhaWwuDQoNCkJlc3QgcmVnYXJkcywN CkfDtnJhbg0KDQoNCk9uIDIwMTUtMDMtMDQgMDQ6MjUsICJFdmUgTWFsZXIiIDxldmVAeG1sZ3Jy bC5jb20+IHdyb3RlOg0KDQo+SXQgc2VlbXMgdG8gbWUgdGhhdCBFdmUgKGFoZW0pLCBhcyB0aGUg b3duZXIgb2YgdGhlIGNsaWVudCwgaXMganVzdA0KPnNlZWtpbmcgYWNjZXNzIHRvIGEgcmVzb3Vy Y2UgdGhhdCBBbGljZSBvciBCb2IgY29udHJvbHMgYWNjZXNzIHRvIGJ1dA0KPmNhbid0IGJlIGRl c2NyaWJlZCBhcyBhbiBvd25lciBvZiBhbnl0aGluZyBlbHNlLiBUaGVyZSBhcmUgaW5kZWVkLA0K Pmhvd2V2ZXIsIHNldmVyYWwgInN1YmplY3RzIiBpbiB0aGlzIHBpY3R1cmUsIHRoYXQgaXMsIHNl dmVyYWwgaWRlbnRpdGllcw0KPndvcnRoIHRyYWNraW5nIGFuZCBhdXRoZW50aWNhdGluZy4NCj4N Cj5UaGVyZSBpcyBhbiBpbmhlcmVudCAoYW5kIHZhbHVhYmxlIGZvciBBQ0UgcHVycG9zZXMpIGFz eW1tZXRyeSBpbiB0aGUNCj5yZWxhdGlvbnNoaXAgYmV0d2VlbiB0aG9zZSB3aG8gYXJlIGluIGEg cG9zaXRpb24gdG8gZ3JhbnQgYWNjZXNzIGFuZA0KPnRob3NlIHdobyBzZWVrIGl0LiBJZiB0aGUg dGFibGVzIGFyZSB0dXJuZWQgZm9yIHNvbWUgb3RoZXIgcmVzb3VyY2UsIHdpdGgNCj5FdmUgaW4g dGhlIHJlc291cmNlIG93bmVyIHJvbGUgYW5kIEFsaWNlIGluIHRoZSBjbGllbnQgb3duZXIgcm9s ZSwgdGhhdA0KPmRvZXNuJ3QgbWFrZSBpdCBhIHR3by13YXkgcmVsYXRpb25zaGlwIC0tIGl0J3Mg c3RpbGwgdHdvIG9uZS13YXkNCj5yZWxhdGlvbnNoaXBzLg0KPg0KPkZXSVcsIGhlcmUgaXMgdGhl IHRlcm1pbm9sb2d5IHVzZWQgaW4gVU1BIG9uIHRoZSB0ZWNobmljYWwgYW5kDQo+Y29udHJhY3R1 YWwgbGV2ZWxzIGZvciBhbGwgdGhlc2UgY29uY2VwdHM6DQo+DQo+VGVjaG5pY2FsICAgICAgICAg ICAgIENvbnRyYWN0dWFsDQo+DQo+LS0gICAgICAgICAgICAgICAgICAgIEluZGl2aWR1YWwgKGh1 bWFuKQ0KPi0tICAgICAgICAgICAgICAgICAgICBOb24tUGVyc29uIEVudGl0eSAoImxlZ2FsIHBl cnNvbiIgbGlrZSBhIGNvbXBhbnkpDQo+LS0gICAgICAgICAgICAgICAgICAgIFN1YmplY3QgKGNh biBiZSBhbiBpbmRpdmlkdWFsIG9yIGFuIE5QRSkNCj4gICAgICAgICAgICAgICAgICAgICAgKGFs bCBvZiB0aGUgcmVzdCBhcmUgYSBraW5kIG9mIFN1YmplY3QuLi4pDQo+cmVzb3VyY2Ugb3duZXIg ICAgICAgIEF1dGhvcml6aW5nIFBhcnR5DQo+YXV0aG9yaXphdGlvbiBzZXJ2ZXIgIEF1dGhvcml6 YXRpb24gU2VydmVyIE9wZXJhdG9yDQo+cmVzb3VyY2Ugc2VydmVyICAgICAgIFJlc291cmNlIFNl cnZlciBPcGVyYXRvcg0KPmNsaWVudCAgICAgICAgICAgICAgICBDbGllbnQgT3BlcmF0b3IgKGUu Zy4gR29vZ2xlLCBydW5uaW5nIEdvb2dsZSBBcHBzKQ0KPnJlcXVlc3RpbmcgcGFydHkgICAgICBS ZXF1ZXN0aW5nIFBhcnR5DQo+LS0gICAgICAgICAgICAgICAgICAgIFJlcXVlc3RpbmcgUGFydHkg QWdlbnQgKGUuZy4gYW4gZW1wbG95ZWUgb2YgYQ0KPmNvcnBvcmF0ZSBScVApDQo+DQo+VGhlIGtp bmQgb2YgUHJpbmNpcGFsIG1lYW50IGluIHRoZSB1c2UgY2FzZSBkb2MsIEkgd291bGQgYXJndWUs IGlzDQo+ZXhjbHVzaXZlbHkgdGhlIHJlc291cmNlIG93bmVyIGtpbmQgb2YgcHJpbmNpcGFsLiBJ ZiB5b3Ugd2FudCB0byBnbyBiYWNrDQo+YW5kIHNlZSBkZWZpbml0aW9ucywgVU1BIGdldHMgaXRz IGRlZmluaXRpb24gb2YgcmVzb3VyY2Ugb3duZXIgZnJvbQ0KPk9BdXRoLCB3aGljaCBkZWZpbmVz IGl0IGFzICJBbiBlbnRpdHkgY2FwYWJsZSBvZiBncmFudGluZyBhY2Nlc3MgdG8gYQ0KPnByb3Rl Y3RlZCByZXNvdXJjZS4iIFRoZSBjbGllbnQsIG9uIHRoZSBvdGhlciBoYW5kLCBpcyBhYm91dCAi bWFraW5nDQo+cHJvdGVjdGVkIHJlc291cmNlIHJlcXVlc3RzIHdpdGggdGhlIHJlc291cmNlIG93 bmVyJ3MgYXV0aG9yaXphdGlvbiBhbmQNCj5vbiB0aGUgcmVxdWVzdGluZyBwYXJ0eSdzIGJlaGFs Zi4iIFRoaXMgbWFrZXMgdGhlIGFzeW1tZXRyeSBjbGVhci4NCj4NCj4JRXZlDQo+DQo+PiBPbiAz IE1hciAyMDE1LCBhdCA1OjA2IEFNLCBIYW5uZXMgVHNjaG9mZW5pZw0KPj48aGFubmVzLnRzY2hv ZmVuaWdAZ214Lm5ldD4gd3JvdGU6DQo+PiANCj4+IEhpIGFsbCwNCj4+IA0KPj4gbGV0IG1lIHRy eSB0byBzZWUgd2hldGhlciBJIHVuZGVyc3RhbmQgdGhlIGlzc3VlIHRoYXQncyBjdXJyZW50bHkg dW5kZXINCj4+IGRpc2N1c3Npb24uDQo+PiANCj4+IEl0IHNlZW1zIHRoYXQgdGhlIGRlYmF0ZSBm b2N1c2VzIG9uIHRoaXMgcmVxdWlyZW1lbnQgZnJvbSB0aGUgJ0NvbnRhaW5lcg0KPj4gbW9uaXRv cmluZycgdXNlIGNhc2U6DQo+PiANCj4+ICINCj4+ICAgbyAgVTEuMiBQcmluY2lwYWxzIHdhbnQg dG8gZ3JhbnQgZGlmZmVyZW50IGFjY2VzcyByaWdodHMgZm9yDQo+PiAgICAgIGRpZmZlcmVudCBy ZXNvdXJjZXMgb24gYW4gZW5kcG9pbnQuDQo+PiAiDQo+PiANCj4+IFRoZSBxdWVzdGlvbiB0aGF0 IHN1cmZhY2VkIGhlcmUgaXMgd2hldGhlciAncHJpbmNpcGFsJyBpcyB0aGUgcmlnaHQgdGVybQ0K Pj4gb3Igbm90LiBUaGUgZG9jdW1lbnQgZGVmaW5lcyBwcmluY2lwYWwgYXMgIkEgc3ViamVjdCB3 aG8gaXMgZWl0aGVyIGENCj4+IHJlc291cmNlIG93bmVyIG9yIGEgY2xpZW50IG93bmVyIG9yIGJv dGguIg0KPj4gDQo+PiBIZXJlIGlzIGEgc2xpZ2h0bHkgbW9kaWZpZWQgZXhhbXBsZSB1c2luZyBh IGRvb3IgbG9jayBzY2VuYXJpbyB0aGF0IG1heQ0KPj4gaGVscCB1cyBzZWUgdGhyb3VnaCB0aGlz IGNhc2UuIEltYWdpbmUgYSBmYW1pbHkgd2l0aCBhIGtpZDogQWxpY2UsIEJvYg0KPj4gYW5kIHRo ZWlyIHlvdW5nIGNoaWxkIEV2ZS4NCj4+IA0KPj4gQWxpY2UgYW5kIEJvYiBib3VnaHQgb25lIG9m IHRoZXNlIEludGVybmV0IGNvbm5lY3RlZCBkb29yIGxvY2tzIGFuZCBub3cNCj4+IHdhbnQgdG8g Y29uZmlndXJlIGl0LiBUaGV5IHdhbnQgdG8gY29uZmlndXJlIGl0IGluIHN1Y2ggYSB3YXkgdGhh dCBhbGwNCj4+IHRocmVlIGNhbiBlbnRlciB0aGVpciBob3VzZSBqdXN0IHVzaW5nIHRoZWlyIHNt YXJ0IHBob25lIChhbmQgYQ0KPj4gc3BlY2lhbGx5IGxvYWRlZCBhcHApLg0KPj4gDQo+PiBXaGV0 aGVyIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpcyBpbmNsdWRlZCBpbiB0aGUgZG9vciBsb2Nr IGl0c2VsZiBvcg0KPj4gaXMgcGFydCBvZiBzb21lIG90aGVyIGhvbWUgYXBwbGlhbmNlIGRvZXMg bm90IHJlYWxseSBtYXR0ZXIgZm9yIHRoZQ0KPj4gbW9tZW50LiBJbiBhbnkgY2FzZSwgQWxpY2Ug YW5kIEJvYiBjb25maWd1cmUgdGhlIGRvb3IgbG9jayBpbiBzdWNoIGEgd2F5DQo+PiB0aGF0IEV2 ZSBpcyBncmFudGVkIGFjY2Vzcy4gQWxpY2UgYW5kIEJvYiBhcmUgdGhlIG93bmVyIG9mIHRoZSBy ZXNvdXJjZQ0KPj4gKD1kb29yIGxvY2spIGJ1dCBldmVuIGlmIHRoZXkgZG8gbm90ICdvd24nIHRo ZSBkb29yIGxvY2sgKGJ1dCBoYXZlDQo+PiByYXRoZXIgcmVudGVkIGl0KSBkb2VzIG5vdCByZWFs bHkgbWF0dGVyLg0KPj4gDQo+PiBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZG9lcyBub3QgbmVj ZXNzYXJpbHkgbmVlZCB0byBrbm93IHRoYXQgdGhpcw0KPj4gYWNjZXNzIGNvbnRyb2wgcG9saWN5 IGlzIGFib3V0ICJFdmUiLiBBbGwgaXQgY2FyZXMgaXMgdGhhdCB0aGVyZSBpcyBhbg0KPj4gZW50 cnkgaW4gdGhlIGFjY2VzcyBjb250cm9sIGxpc3QgdGhhdCBwb2ludHMgdG8gc29tZSBjcmVkZW50 aWFsIG9uIHNvbWUNCj4+IGRldmljZS4gVGhhdCBjcmVkZW50aWFsIGhhcHBlbnMgdG8gcG9pbnQg dG8gYXBwIG9uIHRoZSBzbWFydCBwaG9uZSBFdmUNCj4+IGlzIHVzaW5nLg0KPj4gDQo+PiBOb3cs IHRoZSBxdWVzdGlvbiBpcyBob3cgRXZlLCB3aG8gaXMgdGhlIGNsaWVudCBvd25lciwgZml0cyBp bnRvIHRoYXQNCj4+IHBpY3R1cmUuIFNoZSB3b3VsZCB1c2UgaGVyIHBob25lICg9Y2xpZW50KSB0 byByZXF1ZXN0IGFjY2VzcyB0byB0aGUgZG9vcg0KPj4gYnV0IHNoZSB3b3VsZCBub3QgYmUgaW52 b2x2ZWQgaW4gcHJvdmlzaW9uaW5nIHRoZSBhY2Nlc3MgY29udHJvbCBwb2xpY3kNCj4+IGF0IHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlci4NCj4+IA0KPj4gRGlkIEkgY29ycmVjdGx5IHVuZGVyc3Rv b2QgdGhpcyBpc3N1ZT8NCj4+IA0KPj4gQ2lhbw0KPj4gSGFubmVzDQo+PiANCj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBBY2UgbWFpbGluZyBs aXN0DQo+PiBBY2VAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vYWNlDQo+DQo+DQo+RXZlIE1hbGVyIHwgY2VsbCArMSA0MjUuMzQ1LjY3NTYgfCBTa3lw ZTogeG1sZ3JybCB8IFR3aXR0ZXI6IEB4bWxncnJsDQo+DQo+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj5BY2UgbWFpbGluZyBsaXN0DQo+QWNlQGlldGYu b3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UNCg0K From nobody Wed Mar 4 00:39: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 C091B1A036B for ; Wed, 4 Mar 2015 00:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, 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 AS5CapwtZe7M for ; Wed, 4 Mar 2015 00:39:19 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48E371A0100 for ; Wed, 4 Mar 2015 00:39:19 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t248dFH1026636; Wed, 4 Mar 2015 09:39:15 +0100 (CET) Message-Id: <201503040839.t248dFH1026636@mailhost.informatik.uni-bremen.de> Received: from [192.168.1.107] (p57A639C0.dip0.t-ipconnect.de [87.166.57.192]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3kxpXg13wFz95K1; Wed, 4 Mar 2015 09:39:15 +0100 (CET) Date: Wed, 04 Mar 2015 09:39:08 +0100 From: Stefanie Gerdes To: Eve Maler MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: Hannes Tschofenig , "Ace@ietf.org" Subject: Re: [Ace] U1.2 in Use Case Document 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, 04 Mar 2015 08:39:21 -0000 SGkgRXZlLAoKQW0gMDQuMDMuMjAxNSAwNDoyNSBzY2hyaWViIEV2ZSBNYWxlciA8ZXZlQHhtbGdy cmwuY29tPjoKPgo+IEl0IHNlZW1zIHRvIG1lIHRoYXQgRXZlIChhaGVtKSwgYXMgdGhlIG93bmVy IG9mIHRoZSBjbGllbnQsIGlzIGp1c3Qgc2Vla2luZyBhY2Nlc3MgdG8gYSByZXNvdXJjZSB0aGF0 IEFsaWNlIG9yIEJvYiBjb250cm9scyBhY2Nlc3MgdG8gYnV0IGNhbid0IGJlIGRlc2NyaWJlZCBh cyBhbiBvd25lciBvZiBhbnl0aGluZyBlbHNlLiBUaGVyZSBhcmUgaW5kZWVkLCBob3dldmVyLCBz ZXZlcmFsICJzdWJqZWN0cyIgaW4gdGhpcyBwaWN0dXJlLCB0aGF0IGlzLCBzZXZlcmFsIGlkZW50 aXRpZXMgd29ydGggdHJhY2tpbmcgYW5kIGF1dGhlbnRpY2F0aW5nLiAKPgo+IFRoZXJlIGlzIGFu IGluaGVyZW50IChhbmQgdmFsdWFibGUgZm9yIEFDRSBwdXJwb3NlcykgYXN5bW1ldHJ5IGluIHRo ZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aG9zZSB3aG8gYXJlIGluIGEgcG9zaXRpb24gdG8gZ3Jh bnQgYWNjZXNzIGFuZCB0aG9zZSB3aG8gc2VlayBpdC4gSWYgdGhlIHRhYmxlcyBhcmUgdHVybmVk IGZvciBzb21lIG90aGVyIHJlc291cmNlLCB3aXRoIEV2ZSBpbiB0aGUgcmVzb3VyY2Ugb3duZXIg cm9sZSBhbmQgQWxpY2UgaW4gdGhlIGNsaWVudCBvd25lciByb2xlLCB0aGF0IGRvZXNuJ3QgbWFr ZSBpdCBhIHR3by13YXkgcmVsYXRpb25zaGlwIC0tIGl0J3Mgc3RpbGwgdHdvIG9uZS13YXkgcmVs YXRpb25zaGlwcy4KCklmIHR3byBwYXJ0aWVzIGFyZSBjb21tdW5pY2F0aW5nIHdpdGggZWFjaCBv dGhlciwgZWFjaCBvZiB0aGVzZSBwYXJ0aWVzIG1heSBoYXZlIGl0cyBvd24gc2VjdXJpdHkgcG9s aWNpZXMuIElmIEV2ZSBpcyB0aGUgY2xpZW50IG93bmVyLCBzaGUgd2lsbCB3YW50IHRvIGNvbnRy b2wgd2hpY2ggZGF0YSBpcyBlbnRlcmluZyBhbmQgbGVhdmluZyBoZXIgZGV2aWNlLiBTaGUgZG9l c24ndCB3YW50IGhlciBjbGllbnQgdG8gYWNjZXB0IGRhdGEgZnJvbSB1bnRydXN0ZWQgc291cmNl cyBhbmQgc2hlIGRvZXNuJ3Qgd2FudCBoZXIgZGV2aWNlIHRvIHNlbmQgZGF0YSB0byB1bnRydXN0 ZWQgZGV2aWNlcy4gSW4gc2NlbmFyaW9zIHdoZXJlIHNoZSBpcyBwcmVzZW50IGF0IHRoZSB0aW1l IG9mIGFjY2Vzcywgc2hlIGNhbiBhdXRob3JpemUgdGhhdCBoZXIgZGV2aWNlIGFjY2Vzc2VzIGEg cmVzb3VyY2UgYnkgcHJlc3NpbmcgYSBidXR0b24gb3Igc29tZXRoaW5nIGxpa2UgdGhhdC4gSW4g c2NlbmFyaW9zIHdoZXJlIHNoZSBpcyBhYnNlbnQgKHdlIGhhdmUgYSBjb3VwbGUgb2YgdXNlIGNh c2VzIHdpdGggYWJzZW50IG93bmVycykgc2hlIG5lZWRzIG90aGVyIG1lYW5zIHRvIGtlZXAgY29u dHJvbCBvdmVyIGhlciBkZXZpY2UuIElmIHRoZSBkZXZpY2UgaXMgbm90IGFibGUgdG8gZGV0ZXJt aW5lIGlmIEV2ZSBhdXRob3JpemVkIHRoZSBhY2Nlc3MgdG8gYSBjZXJ0YWluIHJlc291cmNlLCBp dCBpcyBub3QgYWJsZSB0byBlbmZvcmNlIEV2ZSdzIHNlY3VyaXR5IHBvbGljaWVzLiBJZiBFdmUn cyBkZXZpY2UgY29tbXVuaWNhdGVzIHdpdGggdW5hdXRob3JpemVkIGRldmljZXMsIHRoZSBpbnRl Z3JpdHkgYW5kIGNvbmZpZGVudGlhbGl0eSBvZiBoZXIgZGF0YSB3aWxsIGxpa2VseSBiZSBjb21w cm9taXNlZC4KCj4KPiBGV0lXLCBoZXJlIGlzIHRoZSB0ZXJtaW5vbG9neSB1c2VkIGluIFVNQSBv biB0aGUgdGVjaG5pY2FsIGFuZCBjb250cmFjdHVhbCBsZXZlbHMgZm9yIGFsbCB0aGVzZSBjb25j ZXB0czogCj4KPiBUZWNobmljYWzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgQ29udHJhY3R1YWwg Cj4KPiAtLcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIEluZGl2aWR1YWwg KGh1bWFuKSAKPiAtLcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIE5vbi1Q ZXJzb24gRW50aXR5ICgibGVnYWwgcGVyc29uIiBsaWtlIGEgY29tcGFueSkgCj4gLS3CoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBTdWJqZWN0IChjYW4gYmUgYW4gaW5kaXZp ZHVhbCBvciBhbiBOUEUpIAo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCAoYWxsIG9mIHRoZSByZXN0IGFyZSBhIGtpbmQgb2YgU3ViamVjdC4uLikgCj4gcmVzb3Vy Y2Ugb3duZXLCoMKgwqDCoMKgwqDCoCBBdXRob3JpemluZyBQYXJ0eSAKPiBhdXRob3JpemF0aW9u IHNlcnZlcsKgIEF1dGhvcml6YXRpb24gU2VydmVyIE9wZXJhdG9yIAo+IHJlc291cmNlIHNlcnZl csKgwqDCoMKgwqDCoCBSZXNvdXJjZSBTZXJ2ZXIgT3BlcmF0b3IgCj4gY2xpZW50wqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIENsaWVudCBPcGVyYXRvciAoZS5nLiBHb29nbGUsIHJ1bm5p bmcgR29vZ2xlIEFwcHMpIAo+IHJlcXVlc3RpbmcgcGFydHnCoMKgwqDCoMKgIFJlcXVlc3Rpbmcg UGFydHkgCj4gLS3CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBSZXF1ZXN0 aW5nIFBhcnR5IEFnZW50IChlLmcuIGFuIGVtcGxveWVlIG9mIGEgY29ycG9yYXRlIFJxUCkgCj4K PiBUaGUga2luZCBvZiBQcmluY2lwYWwgbWVhbnQgaW4gdGhlIHVzZSBjYXNlIGRvYywgSSB3b3Vs ZCBhcmd1ZSwgaXMgZXhjbHVzaXZlbHkgdGhlIHJlc291cmNlIG93bmVyIGtpbmQgb2YgcHJpbmNp cGFsLiBJZiB5b3Ugd2FudCB0byBnbyBiYWNrIGFuZCBzZWUgZGVmaW5pdGlvbnMsIFVNQSBnZXRz IGl0cyBkZWZpbml0aW9uIG9mIHJlc291cmNlIG93bmVyIGZyb20gT0F1dGgsIHdoaWNoIGRlZmlu ZXMgaXQgYXMgIkFuIGVudGl0eSBjYXBhYmxlIG9mIGdyYW50aW5nIGFjY2VzcyB0byBhIHByb3Rl Y3RlZCByZXNvdXJjZS4iIFRoZSBjbGllbnQsIG9uIHRoZSBvdGhlciBoYW5kLCBpcyBhYm91dCAi bWFraW5nIHByb3RlY3RlZCByZXNvdXJjZSByZXF1ZXN0cyB3aXRoIHRoZSByZXNvdXJjZSBvd25l cidzIGF1dGhvcml6YXRpb24gYW5kIG9uIHRoZSByZXF1ZXN0aW5nIHBhcnR5J3MgYmVoYWxmLiIg VGhpcyBtYWtlcyB0aGUgYXN5bW1ldHJ5IGNsZWFyLgoKSWYgeW91IGRlZmluZSB0aGUgcmVzb3Vy Y2Ugb3duZXIgYXMgdGhlIGF1dGhvcml6aW5nIHBhcnR5IHRoZW4gY2xlYXJseSB0aGUgcmVzb3Vy Y2Ugb3duZXIgYXV0aG9yaXplcy4gSW4gdGhpcyBjYXNlIGJvdGggQWxpY2UgYW5kIEV2ZSBhcmUg cmVzb3VyY2Ugb3duZXJzIHNpbmNlIGJvdGggYXJlIGF1dGhvcml6aW5nLiBBbGljZSBpcyBhdXRo b3JpemluZyB3aG8gYWNjZXNzZXMgaGVyIGRvb3IgbG9jayBhbmQgRXZlIGF1dGhvcml6ZXMgaGVy IGNsaWVudCB0byBhY2Nlc3MgdGhlIGRvb3IgbG9jayBieSBwdXNoaW5nIGEgYnV0dG9uLgoKRm9y IHNjZW5hcmlvcyB3aXRoIGFuIGFjdGl2ZSB1c2VyIHRoYXQgY2FuIGF1dGhvcml6ZSBieSBwcmVz c2luZyBidXR0b25zIHdlIGNhbiBkZWNpZGUgdG8gbm90IGNvbnNpZGVyIHRoYXQgRXZlIGF1dGhv cml6ZXMgaGVyIGRldmljZS4gQnV0IGZvciBjb25zdHJhaW5lZCBkZXZpY2VzIHRoYXQgbWlnaHQg bm90IGhhdmUgbWVhbnMgZm9yIHVzZXIgaW50ZXJhY3Rpb24gKGUuZy4sIGRvbid0IGhhdmUgYSBk aXNwbGF5IG9yIGEgYnV0dG9uKSwgYW5kIGZvciBzY2VuYXJpb3Mgd2hlcmUgd2UgZG9uJ3QgaGF2 ZSBhbiBhY3RpdmUgdXNlciBmb3Igb3RoZXIgcmVhc29ucywgd2UgbmVlZCBtb3JlIHNvcGhpc3Rp Y2F0ZWQgYXV0aG9yaXphdGlvbi4KCkJlc3QgcmVnYXJkcwpTdGVmZmkKCj4KPiBFdmUgCj4KPiA+ IE9uIDMgTWFyIDIwMTUsIGF0IDU6MDYgQU0sIEhhbm5lcyBUc2Nob2ZlbmlnIDxoYW5uZXMudHNj aG9mZW5pZ0BnbXgubmV0PiB3cm90ZTogCj4gPiAKPiA+IEhpIGFsbCwgCj4gPiAKPiA+IGxldCBt ZSB0cnkgdG8gc2VlIHdoZXRoZXIgSSB1bmRlcnN0YW5kIHRoZSBpc3N1ZSB0aGF0J3MgY3VycmVu dGx5IHVuZGVyIAo+ID4gZGlzY3Vzc2lvbi4gCj4gPiAKPiA+IEl0IHNlZW1zIHRoYXQgdGhlIGRl YmF0ZSBmb2N1c2VzIG9uIHRoaXMgcmVxdWlyZW1lbnQgZnJvbSB0aGUgJ0NvbnRhaW5lciAKPiA+ IG1vbml0b3JpbmcnIHVzZSBjYXNlOiAKPiA+IAo+ID4gIiAKPiA+wqDCoCBvwqAgVTEuMiBQcmlu Y2lwYWxzIHdhbnQgdG8gZ3JhbnQgZGlmZmVyZW50IGFjY2VzcyByaWdodHMgZm9yIAo+ID7CoMKg wqDCoMKgIGRpZmZlcmVudCByZXNvdXJjZXMgb24gYW4gZW5kcG9pbnQuIAo+ID4gIiAKPiA+IAo+ ID4gVGhlIHF1ZXN0aW9uIHRoYXQgc3VyZmFjZWQgaGVyZSBpcyB3aGV0aGVyICdwcmluY2lwYWwn IGlzIHRoZSByaWdodCB0ZXJtIAo+ID4gb3Igbm90LiBUaGUgZG9jdW1lbnQgZGVmaW5lcyBwcmlu Y2lwYWwgYXMgIkEgc3ViamVjdCB3aG8gaXMgZWl0aGVyIGEgCj4gPiByZXNvdXJjZSBvd25lciBv ciBhIGNsaWVudCBvd25lciBvciBib3RoLiIgCj4gPiAKPiA+IEhlcmUgaXMgYSBzbGlnaHRseSBt b2RpZmllZCBleGFtcGxlIHVzaW5nIGEgZG9vciBsb2NrIHNjZW5hcmlvIHRoYXQgbWF5IAo+ID4g aGVscCB1cyBzZWUgdGhyb3VnaCB0aGlzIGNhc2UuIEltYWdpbmUgYSBmYW1pbHkgd2l0aCBhIGtp ZDogQWxpY2UsIEJvYiAKPiA+IGFuZCB0aGVpciB5b3VuZyBjaGlsZCBFdmUuIAo+ID4gCj4gPiBB bGljZSBhbmQgQm9iIGJvdWdodCBvbmUgb2YgdGhlc2UgSW50ZXJuZXQgY29ubmVjdGVkIGRvb3Ig bG9ja3MgYW5kIG5vdyAKPiA+IHdhbnQgdG8gY29uZmlndXJlIGl0LiBUaGV5IHdhbnQgdG8gY29u ZmlndXJlIGl0IGluIHN1Y2ggYSB3YXkgdGhhdCBhbGwgCj4gPiB0aHJlZSBjYW4gZW50ZXIgdGhl aXIgaG91c2UganVzdCB1c2luZyB0aGVpciBzbWFydCBwaG9uZSAoYW5kIGEgCj4gPiBzcGVjaWFs bHkgbG9hZGVkIGFwcCkuIAo+ID4gCj4gPiBXaGV0aGVyIHRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciBpcyBpbmNsdWRlZCBpbiB0aGUgZG9vciBsb2NrIGl0c2VsZiBvciAKPiA+IGlzIHBhcnQgb2Yg c29tZSBvdGhlciBob21lIGFwcGxpYW5jZSBkb2VzIG5vdCByZWFsbHkgbWF0dGVyIGZvciB0aGUg Cj4gPiBtb21lbnQuIEluIGFueSBjYXNlLCBBbGljZSBhbmQgQm9iIGNvbmZpZ3VyZSB0aGUgZG9v ciBsb2NrIGluIHN1Y2ggYSB3YXkgCj4gPiB0aGF0IEV2ZSBpcyBncmFudGVkIGFjY2Vzcy4gQWxp Y2UgYW5kIEJvYiBhcmUgdGhlIG93bmVyIG9mIHRoZSByZXNvdXJjZSAKPiA+ICg9ZG9vciBsb2Nr KSBidXQgZXZlbiBpZiB0aGV5IGRvIG5vdCAnb3duJyB0aGUgZG9vciBsb2NrIChidXQgaGF2ZSAK PiA+IHJhdGhlciByZW50ZWQgaXQpIGRvZXMgbm90IHJlYWxseSBtYXR0ZXIuIAo+ID4gCj4gPiBU aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZG9lcyBub3QgbmVjZXNzYXJpbHkgbmVlZCB0byBrbm93 IHRoYXQgdGhpcyAKPiA+IGFjY2VzcyBjb250cm9sIHBvbGljeSBpcyBhYm91dCAiRXZlIi4gQWxs IGl0IGNhcmVzIGlzIHRoYXQgdGhlcmUgaXMgYW4gCj4gPiBlbnRyeSBpbiB0aGUgYWNjZXNzIGNv bnRyb2wgbGlzdCB0aGF0IHBvaW50cyB0byBzb21lIGNyZWRlbnRpYWwgb24gc29tZSAKPiA+IGRl dmljZS4gVGhhdCBjcmVkZW50aWFsIGhhcHBlbnMgdG8gcG9pbnQgdG8gYXBwIG9uIHRoZSBzbWFy dCBwaG9uZSBFdmUgCj4gPiBpcyB1c2luZy4gCj4gPiAKPiA+IE5vdywgdGhlIHF1ZXN0aW9uIGlz IGhvdyBFdmUsIHdobyBpcyB0aGUgY2xpZW50IG93bmVyLCBmaXRzIGludG8gdGhhdCAKPiA+IHBp Y3R1cmUuIFNoZSB3b3VsZCB1c2UgaGVyIHBob25lICg9Y2xpZW50KSB0byByZXF1ZXN0IGFjY2Vz cyB0byB0aGUgZG9vciAKPiA+IGJ1dCBzaGUgd291bGQgbm90IGJlIGludm9sdmVkIGluIHByb3Zp c2lvbmluZyB0aGUgYWNjZXNzIGNvbnRyb2wgcG9saWN5IAo+ID4gYXQgdGhlIGF1dGhvcml6YXRp b24gc2VydmVyLiAKPiA+IAo+ID4gRGlkIEkgY29ycmVjdGx5IHVuZGVyc3Rvb2QgdGhpcyBpc3N1 ZT8gCj4gPiAKPiA+IENpYW8gCj4gPiBIYW5uZXMgCj4gPiAKPiA+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIAo+ID4gQWNlIG1haWxpbmcgbGlzdCAKPiA+ IEFjZUBpZXRmLm9yZyAKPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v YWNlIAo+Cj4KPiBFdmUgTWFsZXIgfCBjZWxsICsxIDQyNS4zNDUuNjc1NiB8IFNreXBlOiB4bWxn cnJsIHwgVHdpdHRlcjogQHhtbGdycmwgCj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXyAKPiBBY2UgbWFpbGluZyBsaXN0IAo+IEFjZUBpZXRmLm9yZyAK PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZSAKPgo= From nobody Wed Mar 4 00:56:42 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D366A1A1A2F for ; Wed, 4 Mar 2015 00:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 49Uhs0SRcRtD for ; Wed, 4 Mar 2015 00:56:39 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 054811A0100 for ; Wed, 4 Mar 2015 00:56:39 -0800 (PST) Received: from [192.168.131.141] ([80.92.121.102]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LfSeH-1Xj47o0abp-00p4Y8; Wed, 04 Mar 2015 09:56:37 +0100 Message-ID: <54F6C8C3.5050205@gmx.net> Date: Wed, 04 Mar 2015 09:56:35 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Stefanie Gerdes , Eve Maler References: <201503040839.t248dFH1026636@mailhost.informatik.uni-bremen.de> In-Reply-To: <201503040839.t248dFH1026636@mailhost.informatik.uni-bremen.de> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6h8cKR0Ub3NpVUs2qtTmQ9vdHmOiT2r8s" X-Provags-ID: V03:K0:j7hp6MqjmkeKAwqfZmzCaFEsXTC33MUgWjVg98CBqEOj+RfTMNM YaqfiD3HMFC7PhJKwwH+4MeCAd/Olb+A1vRi/fEvFPpYSH7thP2Ue+IXHsony6aItLbp/Mw ll77Fht7j6hHNttxgepet6Cp3qcjDpznpCbrmVoMovRrt12FFbX1fqYJhyQ9SD6ZoOJBrlA 9PZ5/FfGdmnomxpzejiVw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] U1.2 in Use Case Document 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, 04 Mar 2015 08:56:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6h8cKR0Ub3NpVUs2qtTmQ9vdHmOiT2r8s Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Steffi, only a quick comment on this selective issue (still working my way through the other issues). > If two parties are communicating with each other, each of these > parties may have its own security policies. If Eve is the client > owner, she will want to control which data is entering and leaving > her device. She doesn't want her client to accept data from untrusted > sources and she doesn't want her device to send data to untrusted > devices. In scenarios where she is present at the time of access, she > can authorize that her device accesses a resource by pressing a > button or something like that. In scenarios where she is absent (we > have a couple of use cases with absent owners) she needs other means > to keep control over her device. If the device is not able to > determine if Eve authorized the access to a certain resource, it is > not able to enforce Eve's security policies. If Eve's device > communicates with unauthorized devices, the integrity and > confidentiality of her data will likely be compromised. Looking at the way how (since applicable to this scenario) smart phones work today there would be another (independent) authorization check at the time Eve installs the app on her phone. It might asks for permissions to access the Bluetooth smart stack and maybe for some other privileges that have to do with the interaction of the app and the authorization server (since the client app will have to authenticate to the authorization server and might even use an existing identity management service for it). Of course, Eve will have to trust the app developer to a certain extend and will have to carefully evaluate the permissions it is asking for. Is this what you have in mind with 'client owners wanting to grant different access rights for different resources?"? Ciao Hannes --6h8cKR0Ub3NpVUs2qtTmQ9vdHmOiT2r8s Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU9sjDAAoJEGhJURNOOiAtbEoH/0h3Org4AD5EFvms1nKQ6pAE v9jebUA4E0NNK4o9Xm2k81I4B9fi23CItf25IoCv+qfS4gs6krGe6HtDk62wQcR9 esLZoEMrlLPs3Djk5iODDgKPiw5iBV7Exk6LPewdoHtbZXPIk5vPs5vFKjDqth0G 7FWqwpXdWpTcOJCWHlkkaKOhN2vbKjJTi/ugET4GBDjGtSSTca0RkObN3+wXAl55 ZBo+dI2VX9G3g7GPyu6fvP/ieS0aTxhlE509peg2ab7tJrQfmRjzIKUBT5Orm8rR JxjeUq6xbAN94Z9OpGYvJCqUjptrm4Irga6Yc7TuorhqxcVNSxJMgMJjmWjk6JQ= =HuSF -----END PGP SIGNATURE----- --6h8cKR0Ub3NpVUs2qtTmQ9vdHmOiT2r8s-- From nobody Wed Mar 4 01:32:36 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522301A1A90 for ; Wed, 4 Mar 2015 01:32:35 -0800 (PST) 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 Ud1ZQRoeYmke for ; Wed, 4 Mar 2015 01:32:34 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 233B81A1A59 for ; Wed, 4 Mar 2015 01:32:33 -0800 (PST) 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 t249WUiB000215; Wed, 4 Mar 2015 10:32:30 +0100 (CET) Received: from [192.168.1.109] (p57A639C0.dip0.t-ipconnect.de [87.166.57.192]) (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 3kxqk60wr1z95MX; Wed, 4 Mar 2015 10:32:30 +0100 (CET) Message-ID: <54F6D12D.8060703@tzi.de> Date: Wed, 04 Mar 2015 10:32:29 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Hannes Tschofenig , Eve Maler References: <201503040839.t248dFH1026636@mailhost.informatik.uni-bremen.de> <54F6C8C3.5050205@gmx.net> In-Reply-To: <54F6C8C3.5050205@gmx.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] U1.2 in Use Case Document 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, 04 Mar 2015 09:32:35 -0000 Hi Hannes, On 03/04/2015 09:56 AM, Hannes Tschofenig wrote: > Hi Steffi, > > only a quick comment on this selective issue (still working my way > through the other issues). > >> If two parties are communicating with each other, each of these >> parties may have its own security policies. If Eve is the client >> owner, she will want to control which data is entering and leaving >> her device. She doesn't want her client to accept data from untrusted >> sources and she doesn't want her device to send data to untrusted >> devices. In scenarios where she is present at the time of access, she >> can authorize that her device accesses a resource by pressing a >> button or something like that. In scenarios where she is absent (we >> have a couple of use cases with absent owners) she needs other means >> to keep control over her device. If the device is not able to >> determine if Eve authorized the access to a certain resource, it is >> not able to enforce Eve's security policies. If Eve's device >> communicates with unauthorized devices, the integrity and >> confidentiality of her data will likely be compromised. > > Looking at the way how (since applicable to this scenario) smart phones > work today there would be another (independent) authorization check at > the time Eve installs the app on her phone. It might asks for > permissions to access the Bluetooth smart stack and maybe for some other > privileges that have to do with the interaction of the app and the > authorization server (since the client app will have to authenticate to > the authorization server and might even use an existing identity > management service for it). > > Of course, Eve will have to trust the app developer to a certain extend > and will have to carefully evaluate the permissions it is asking for. > > Is this what you have in mind with 'client owners wanting to grant > different access rights for different resources?"? I am not that interested in smartphone security and I don't think we should work on the security of smartphone apps in ACE. What I am interested in is to find out what we need to do to enable Eve's device to act in Eve's behalf if Eve is not able to instruct the device at the time of access. A temperature sensor on a banana box in the container scenario should be able to decide if it can send its temperature values to a certain cooling unit or not. It should not send its temperature values to the transloading company. However, it can give the transloading company information about its owner (the fruit vendor) so that the transloading company knows how to handle the banana boxes. In the smartphone case, Eve could configure in the app which resources her device is allowed to access on its own (my phone may open door-locks that belong to Alice and look out for new music on devices that belong to Eric and give my training plan to my cross trainer. all other actions are not allowed). We don't need explicit authorization (configuration of a fine-grained access control) for every use case. For some use cases, it may suffice to authorize a device because it can be authenticated. But in other cases, it will be necessary to define exactly what my device is allowed to access to ensure the integrity and confidentiality of my data. Best regards, Steffi From nobody Wed Mar 4 05:51:55 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8DC21A1A00 for ; Wed, 4 Mar 2015 05:51:53 -0800 (PST) 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 IzIO0Et9ZZyj for ; Wed, 4 Mar 2015 05:51:52 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D56591A1AA6 for ; Wed, 4 Mar 2015 05:51:51 -0800 (PST) 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 t24DplE1005188; Wed, 4 Mar 2015 14:51:47 +0100 (CET) Received: from aung.tzi.org (unknown [IPv6:2001:638:708:30da:3564:655b:7d8:ff09]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3kxxTH2dXqz2l32; Wed, 4 Mar 2015 14:51:47 +0100 (CET) From: Olaf Bergmann To: Eve Maler In-Reply-To: (Eve Maler's message of "Tue, 3 Mar 2015 19:25:27 -0800") References: <54F5B1F2.6050205@gmx.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) Date: Wed, 04 Mar 2015 14:51:47 +0100 Message-ID: <871tl4j2fg.fsf@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Hannes Tschofenig , "Ace@ietf.org" Subject: Re: [Ace] U1.2 in Use Case Document 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, 04 Mar 2015 13:51:54 -0000 Eve, Eve Maler writes: > There is an inherent (and valuable for ACE purposes) asymmetry in the rel= ationship between those who are in a position to grant access and those who= seek it. If the tables are turned for some other resource, with Eve in the= resource owner role and Alice in the client owner role, that doesn't make = it a two-way relationship -- it's still two one-way relationships. There is indeed an asymmetry, but that does not mean that there is no authorization of communication at all. As Hannes said in his followup: When you install a smart phone app, you have -- as a client owner in Steffi's Terminology -- to authorize certain actions in advance. You can do this also with constrained devices, e.g. hard-coded in the firmware configuration. But then you are tied to those authorization rules. You need 1. a firmware update whenever these rules change, or 2. to update the dynamic part of the authorization policy. The current discussion is about whether or not we agree that 1 and 2 _exist_ as problems per se (independent of whether or not these must be addressed by the ACE protocol in the first place). > FWIW, here is the terminology used in UMA on the technical and contractua= l levels for all these concepts: > > Technical Contractual > > -- Individual (human) > -- Non-Person Entity ("legal person" like a company) > -- Subject (can be an individual or an NPE) > (all of the rest are a kind of Subject...) > resource owner Authorizing Party > authorization server Authorization Server Operator > resource server Resource Server Operator > client Client Operator (e.g. Google, running Google Apps) > requesting party Requesting Party > -- Requesting Party Agent (e.g. an employee of a corpo= rate RqP) > > The kind of Principal meant in the use case doc, I would argue, is exclus= ively the resource owner kind of principal. If you want to go back and see = definitions, UMA gets its definition of resource owner from OAuth, which de= fines it as "An entity capable of granting access to a protected resource."= The client, on the other hand, is about "making protected resource request= s with the resource owner's authorization and on the requesting party's beh= alf." This makes the asymmetry clear. Well, "on the requesting party's behalf" already says that the client needs to be authorized to send this request. This has been questioned several times in the past, leading even to the attempt to remove this entirely. Good to see that OAuth and UMA also think that the Requesting Party needs to authorize the client's actions. Gr=C3=BC=C3=9Fe Olaf From nobody Wed Mar 4 06:38:01 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDCC01A1AB1 for ; Wed, 4 Mar 2015 06:38:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 bLvh89M18yGC for ; Wed, 4 Mar 2015 06:37:58 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFDC71A0231 for ; Wed, 4 Mar 2015 06:37:55 -0800 (PST) Received: from [192.168.131.141] ([80.92.121.102]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MId0S-1YVMHs3glM-002DCH; Wed, 04 Mar 2015 15:37:49 +0100 Message-ID: <54F718BA.3080603@gmx.net> Date: Wed, 04 Mar 2015 15:37:46 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Stefanie Gerdes , Eve Maler References: <201503040839.t248dFH1026636@mailhost.informatik.uni-bremen.de> <54F6C8C3.5050205@gmx.net> <54F6D12D.8060703@tzi.de> In-Reply-To: <54F6D12D.8060703@tzi.de> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gnNDG83RHMV0cL7W0Kp4nl0Mt6bsNqfh3" X-Provags-ID: V03:K0:C19a6+cpQffCMT4eSwdUZ9/62pyDB6Ks06ySEuPm5e3Dqj7bI5X 7imcsReNaznz65nO8RysdXTXpMwn65BDlWS+7R+ktFQhhVajMK1dufJ/kOfylEO9emvQvy4 S876rXbC/tb0Zp09Y/9jdr3pA0Gm2UJ4cVdiGicIgPq1HZl4mq4IH4wE//mRAIB3yuli6QL f3VXOq7iTTKgiQkRYpjCQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] U1.2 in Use Case Document 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, 04 Mar 2015 14:38:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gnNDG83RHMV0cL7W0Kp4nl0Mt6bsNqfh3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Steffi, some remarks below. On 03/04/2015 10:32 AM, Stefanie Gerdes wrote: > Hi Hannes, >=20 > On 03/04/2015 09:56 AM, Hannes Tschofenig wrote: >> Hi Steffi, >> >> only a quick comment on this selective issue (still working my way >> through the other issues). >> >>> If two parties are communicating with each other, each of these >>> parties may have its own security policies. If Eve is the client >>> owner, she will want to control which data is entering and leaving >>> her device. She doesn't want her client to accept data from untrusted= >>> sources and she doesn't want her device to send data to untrusted >>> devices. In scenarios where she is present at the time of access, she= >>> can authorize that her device accesses a resource by pressing a >>> button or something like that. In scenarios where she is absent (we >>> have a couple of use cases with absent owners) she needs other means >>> to keep control over her device. If the device is not able to >>> determine if Eve authorized the access to a certain resource, it is >>> not able to enforce Eve's security policies. If Eve's device >>> communicates with unauthorized devices, the integrity and >>> confidentiality of her data will likely be compromised. >> >> Looking at the way how (since applicable to this scenario) smart phone= s >> work today there would be another (independent) authorization check at= >> the time Eve installs the app on her phone. It might asks for >> permissions to access the Bluetooth smart stack and maybe for some oth= er >> privileges that have to do with the interaction of the app and the >> authorization server (since the client app will have to authenticate t= o >> the authorization server and might even use an existing identity >> management service for it). >> >> Of course, Eve will have to trust the app developer to a certain exten= d >> and will have to carefully evaluate the permissions it is asking for. >> >> Is this what you have in mind with 'client owners wanting to grant >> different access rights for different resources?"? >=20 > I am not that interested in smartphone security and I don't think we > should work on the security of smartphone apps in ACE. The smartphone app was just the continuation of the use case to make the discussion less abstract. > What I am > interested in is to find out what we need to do to enable Eve's device > to act in Eve's behalf if Eve is not able to instruct the device at the= > time of access. I believe this sentence means a "yes" to my question. >=20 > A temperature sensor on a banana box in the container scenario should b= e > able to decide if it can send its temperature values to a certain > cooling unit or not. It should not send its temperature values to the > transloading company. However, it can give the transloading company > information about its owner (the fruit vendor) so that the transloading= > company knows how to handle the banana boxes. Most likely it would be the other way around: there would be an access control policy configured at an authorization server that allows selected parties access to the sensor readings (in our case the cooling unit would be allowed to access those sensor readings). The sensor is the resource server in our terminology and the cooling unit would be the client. The firmware on the cooling device would tell it whether it should talk to temperature sensors (rather than heart-rate monitors, for example). Most likely there is a pre-configuration step happening prior to the usage where the cooling unit is configured to only talk to the sensors in the same container rather than (maybe accidentally) to temperature sensors from other contains. Whether this information needs to 'entered' into an authorization server and then pushed to the devices, as the OMA LWM2M guys do it, or rather pulled (as OAuth would do it) is something I don't have a strong opinion about. >=20 > In the smartphone case, Eve could configure in the app which resources > her device is allowed to access on its own (my phone may open door-lock= s > that belong to Alice and look out for new music on devices that belong > to Eric and give my training plan to my cross trainer. all other action= s > are not allowed). If the app supports more than one functionality then the app may also ask for various permissions. >=20 > We don't need explicit authorization (configuration of a fine-grained > access control) for every use case. For some use cases, it may suffice > to authorize a device because it can be authenticated. But in other > cases, it will be necessary to define exactly what my device is allowed= > to access to ensure the integrity and confidentiality of my data. I agree. The actual policy is something that will depend on a variety of factors, such as use case, application functionality, operating system capabilities, etc. >=20 > Best regards, > Steffi Ciao Hannes --gnNDG83RHMV0cL7W0Kp4nl0Mt6bsNqfh3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU9xi7AAoJEGhJURNOOiAtKPkH/j8u1p/4VgmhCrj7E56l0MrA iYyoRRvlJmnaSf++FcT19SRkGONyFLAcPsD34DsiaiO0sGBmVqHTaTe5PjyOzLt8 IDqK/t+O58nGAqPTImntrqNhR1+slgv8+VHNK8XXEFfyQi5TAdv/T0dCGj6EgeCI YcurnQqkm11/LoTdxEM7JNCnq6uZqOiLIYMz9WL5Fad1bncXxnUIe8TDqiDhP3Jz I0IzYo26r0XBkR3lR5jSVHNiQVtgsehVAh5rsCchlU323kfYFPhUps9S+S5Xyl7S aVkKjjj39jJLEc5nFOaKV5H89bpm2sxgi9RWxjJEE0MNvF5xqDM4aWODvkR+KPg= =P9I0 -----END PGP SIGNATURE----- --gnNDG83RHMV0cL7W0Kp4nl0Mt6bsNqfh3-- From nobody Wed Mar 4 07:12:02 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B81031A6F05 for ; Wed, 4 Mar 2015 07:12:00 -0800 (PST) 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 NMcIVQXRHVva for ; Wed, 4 Mar 2015 07:11:58 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 575EE1A6EF9 for ; Wed, 4 Mar 2015 07:11:58 -0800 (PST) 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 t24FBsfC013467; Wed, 4 Mar 2015 16:11:54 +0100 (CET) Received: from [IPv6:2001:638:708:30da:8c0c:caa4:d73a:f70c] (unknown [IPv6:2001:638:708:30da:8c0c:caa4:d73a:f70c]) (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 3kxzFk1NgLz2kk3; Wed, 4 Mar 2015 16:11:54 +0100 (CET) Message-ID: <54F720BA.20003@tzi.de> Date: Wed, 04 Mar 2015 16:11:54 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Hannes Tschofenig , Eve Maler References: <201503040839.t248dFH1026636@mailhost.informatik.uni-bremen.de> <54F6C8C3.5050205@gmx.net> <54F6D12D.8060703@tzi.de> <54F718BA.3080603@gmx.net> In-Reply-To: <54F718BA.3080603@gmx.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] U1.2 in Use Case Document 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, 04 Mar 2015 15:12:00 -0000 Hi Hannes, On 03/04/2015 03:37 PM, Hannes Tschofenig wrote: > Hi Steffi, > > some remarks below. > > On 03/04/2015 10:32 AM, Stefanie Gerdes wrote: >> Hi Hannes, >> >> On 03/04/2015 09:56 AM, Hannes Tschofenig wrote: >>> Hi Steffi, >>> >>> only a quick comment on this selective issue (still working my way >>> through the other issues). >>> >>>> If two parties are communicating with each other, each of these >>>> parties may have its own security policies. If Eve is the client >>>> owner, she will want to control which data is entering and leaving >>>> her device. She doesn't want her client to accept data from untrusted >>>> sources and she doesn't want her device to send data to untrusted >>>> devices. In scenarios where she is present at the time of access, she >>>> can authorize that her device accesses a resource by pressing a >>>> button or something like that. In scenarios where she is absent (we >>>> have a couple of use cases with absent owners) she needs other means >>>> to keep control over her device. If the device is not able to >>>> determine if Eve authorized the access to a certain resource, it is >>>> not able to enforce Eve's security policies. If Eve's device >>>> communicates with unauthorized devices, the integrity and >>>> confidentiality of her data will likely be compromised. >>> >>> Looking at the way how (since applicable to this scenario) smart phones >>> work today there would be another (independent) authorization check at >>> the time Eve installs the app on her phone. It might asks for >>> permissions to access the Bluetooth smart stack and maybe for some other >>> privileges that have to do with the interaction of the app and the >>> authorization server (since the client app will have to authenticate to >>> the authorization server and might even use an existing identity >>> management service for it). >>> >>> Of course, Eve will have to trust the app developer to a certain extend >>> and will have to carefully evaluate the permissions it is asking for. >>> >>> Is this what you have in mind with 'client owners wanting to grant >>> different access rights for different resources?"? >> >> I am not that interested in smartphone security and I don't think we >> should work on the security of smartphone apps in ACE. > > The smartphone app was just the continuation of the use case to make the > discussion less abstract. > >> What I am >> interested in is to find out what we need to do to enable Eve's device >> to act in Eve's behalf if Eve is not able to instruct the device at the >> time of access. > I believe this sentence means a "yes" to my question. > >> >> A temperature sensor on a banana box in the container scenario should be >> able to decide if it can send its temperature values to a certain >> cooling unit or not. It should not send its temperature values to the >> transloading company. However, it can give the transloading company >> information about its owner (the fruit vendor) so that the transloading >> company knows how to handle the banana boxes. > > Most likely it would be the other way around: there would be an access > control policy configured at an authorization server that allows > selected parties access to the sensor readings (in our case the cooling > unit would be allowed to access those sensor readings). The sensor is > the resource server in our terminology and the cooling unit would be the > client. Just to get this straight: From your point of view, the authorization server is controlled by the fruit vendor who can configure access permissions for the temperature sensor. The temperature sensor is the resource server. Right? I wonder why you chose this setting? How do you determine if a device is a resource server or a client? > > The firmware on the cooling device would tell it whether it should talk > to temperature sensors (rather than heart-rate monitors, for example). > Most likely there is a pre-configuration step happening prior to the > usage where the cooling unit is configured to only talk to the sensors > in the same container rather than (maybe accidentally) to temperature > sensors from other contains. Whether this information needs to 'entered' > into an authorization server and then pushed to the devices, as the OMA > LWM2M guys do it, or rather pulled (as OAuth would do it) is something I > don't have a strong opinion about. Yes, you can configure the authorization policies for the cooling unit manually in a pre-configuration step. That would be one solution to solve the authorization problem on the client side. A more sophisticated authorization mechanism would also allow to dynamically update authorizations. This would make it possible to define that only devices of a certain fruit vendor are authorized. It will likely be difficult to determine if a sensor is in the same container or not. Best regards, Steffi > >> >> In the smartphone case, Eve could configure in the app which resources >> her device is allowed to access on its own (my phone may open door-locks >> that belong to Alice and look out for new music on devices that belong >> to Eric and give my training plan to my cross trainer. all other actions >> are not allowed). > If the app supports more than one functionality then the app may also > ask for various permissions. > >> >> We don't need explicit authorization (configuration of a fine-grained >> access control) for every use case. For some use cases, it may suffice >> to authorize a device because it can be authenticated. But in other >> cases, it will be necessary to define exactly what my device is allowed >> to access to ensure the integrity and confidentiality of my data. > > I agree. The actual policy is something that will depend on a variety of > factors, such as use case, application functionality, operating system > capabilities, etc. > >> >> Best regards, >> Steffi > > Ciao > Hannes > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > -- Stefanie Gerdes Tel: +49 421 218 63906 TZI Universitt Bremen E-Mail: gerdes@tzi.de Bibliothekstr. 1, MZH 5150 28359 Bremen, Germany From nobody Wed Mar 4 07:24:21 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3E31A6EFE for ; Wed, 4 Mar 2015 07:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ys4eHoZD7Ov3 for ; Wed, 4 Mar 2015 07:24:18 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F0621A00A2 for ; Wed, 4 Mar 2015 07:24:18 -0800 (PST) Received: from [192.168.131.141] ([80.92.121.102]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LslCb-1XVgei2egj-012HTp; Wed, 04 Mar 2015 16:24:05 +0100 Message-ID: <54F72394.4040105@gmx.net> Date: Wed, 04 Mar 2015 16:24:04 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Stefanie Gerdes , Eve Maler References: <201503040839.t248dFH1026636@mailhost.informatik.uni-bremen.de> <54F6C8C3.5050205@gmx.net> <54F6D12D.8060703@tzi.de> <54F718BA.3080603@gmx.net> <54F720BA.20003@tzi.de> In-Reply-To: <54F720BA.20003@tzi.de> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5JuG47l2tgaUG4ElJUm3awU7kMF8jf5QH" X-Provags-ID: V03:K0:CLN6rNShiTjECeFS2eV0QmwJZOBD1DyUNqU7Sx8nwnE5eQ6LBgi TEchA2EbnN+AWESaRS9dVHCHBl3an1F2TwR+fjfY10/pn7bV/JGNtVHAPiUDl8mnIrw1ssF LU9un9Pxpzr0odEnGBshUMtS9+IoLb30W113OwEu9/uIofn6ZFMlIzWEhXYtBLDiOkyYpap 9n5DT1s2a/rVNh+WOzlYg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] U1.2 in Use Case Document 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, 04 Mar 2015 15:24:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5JuG47l2tgaUG4ElJUm3awU7kMF8jf5QH Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Steffi, On 03/04/2015 04:11 PM, Stefanie Gerdes wrote: >> Most likely it would be the other way around: there would be an access= >> control policy configured at an authorization server that allows >> selected parties access to the sensor readings (in our case the coolin= g >> unit would be allowed to access those sensor readings). The sensor is >> the resource server in our terminology and the cooling unit would be t= he >> client. >=20 > Just to get this straight: From your point of view, the authorization > server is controlled by the fruit vendor who can configure access > permissions for the temperature sensor. The temperature sensor is the > resource server. Right? I wonder why you chose this setting? How do you= > determine if a device is a resource server or a client? I assume that the authorization server for the temperature sensors and the cooling unit is managed / controlled by the fruit vendor. The fruit vendor has, after all, rented the container to deliver the fruits. I determined the client vs. server depending on who initiates the communication. In either case, the sensor either needs to be configured with the address of the cooling unit to send the data to or the cooling unit queries the sensors for the current temperature and therefore needs to know what the relevant sensors in the container are. Do we want to standardize this type of configuration mechanism? I don't know. Ciao Hannes --5JuG47l2tgaUG4ElJUm3awU7kMF8jf5QH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU9yOUAAoJEGhJURNOOiAtWtAIAJ/2+p1c0qUVwEg49GJwB+X2 ymWXpeUtP8maAgyfHtMdzHSpJJOiSonp4t5U3pKUF7YfLZq8CAVFb3XFzr2z2AZu MK9pIlbV1IFoEaFe8K1oKWsIE1huJkteDv8P34mp5oVGjupQExK5BlJUQq04MCZ0 I4NZ9ec//QEPF8UzumdjI0YVlHzO9iHZCuemc9kdVu8LtDFe0DlqhTBPI3Datlvh I59AAYuC7+2ty1jGfNYEoU+neyjFJz3/CvCEoYxFeCUXdpWIrPd+T7iDnX0pdf7z 4L7Ybvmk1AkP2Zv6JPk+byjKgKazizKDVBsrU6eMy7kUm87VY9wRwmKI90rrMq4= =nfqN -----END PGP SIGNATURE----- --5JuG47l2tgaUG4ElJUm3awU7kMF8jf5QH-- From nobody Wed Mar 4 10:38: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 029241A8704 for ; Wed, 4 Mar 2015 10:38:28 -0800 (PST) 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 DJjSNc1bbYPT for ; Wed, 4 Mar 2015 10:38:26 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58F241A7020 for ; Wed, 4 Mar 2015 10:38:26 -0800 (PST) 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 t24IcMG7028088 for ; Wed, 4 Mar 2015 19:38:22 +0100 (CET) Received: from [192.168.1.109] (p57A639C0.dip0.t-ipconnect.de [87.166.57.192]) (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 3ky3qy2fCSz2lHl for ; Wed, 4 Mar 2015 19:38:22 +0100 (CET) Message-ID: <54F75101.4050008@tzi.de> Date: Wed, 04 Mar 2015 19:37:53 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Ace@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [Ace] Authorization on the client side 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, 04 Mar 2015 18:38:28 -0000 Hi all, What I get from the discussion is that we agree that there is an authorization problem on the client side. We also agree that for some authorization problems we don't need a sophisticated authorization mechanism. So maybe we can postpone further discussions about solutions and just finish the use cases draft? We can keep the authorization problem on the client side in the problem summary sections. Moreover, we can add the following to section 3.2 (Configuration of Access Permissions): "Endpoints need to be enabled to enforce the authorization policies of their principals. In some cases, authorization problems might bei solved by implicit authorization (all authenticated entities are authorized)." What do you think? Best regards Steffi -- 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 Mar 4 11:07: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 871F61ACE2A for ; Wed, 4 Mar 2015 11:07:35 -0800 (PST) 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 DL0faNjhRY_V for ; Wed, 4 Mar 2015 11:07:34 -0800 (PST) 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 36C851ACE25 for ; Wed, 4 Mar 2015 11:07:33 -0800 (PST) X-AuditID: c1b4fb2d-f79aa6d00000359d-53-54f757f3964d Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id DA.CB.13725.3F757F45; Wed, 4 Mar 2015 20:07:31 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.70]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0210.002; Wed, 4 Mar 2015 20:07:30 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Stefanie Gerdes , "Ace@ietf.org" Thread-Topic: [Ace] Authorization on the client side Thread-Index: AQHQVqpqTif+C3cGv0q2foXO5/I1WJ0Mr5aA Date: Wed, 4 Mar 2015 19:07:29 +0000 Message-ID: References: <54F75101.4050008@tzi.de> In-Reply-To: <54F75101.4050008@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: <5D2C0735832C6945AFC23F3E40A28200@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGfG3Rvdz+PcQg8blghbfv/UwW2y8eJfR gcljyZKfTB7b3n5lDmCK4rJJSc3JLEst0rdL4Mpo2b6QtWCBUMWlA5fZGhifCHYxcnBICJhI TDlr0MXICWSKSVy4t56ti5GLQ0jgCKPE8qUTmSGcRYwSq99vZAapYhNwkXjQ8IgJxBYRcJJY uu0vC8ggYQFjibY7ihBhE4npB3rYIGwjiUlb/7GD2CwCKhIPzr4Ba+UVsJBY0tDFCmILCahK TJ52DMzmFFCTaD26iAXEZgQ66PupNWD1zALiEreezGeCOFRAYsme88wQtqjEy8f/wHpFBfQk Vl5vYoOIK0msPbwd7DRmAU2J9bv0IcZYSyzddwVqpKLElO6H7BDnCEqcnPmEZQKj+Cwk22Yh dM9C0j0LSfcsJN0LGFlXMYoWpxYX56YbGeulFmUmFxfn5+nlpZZsYgRG2sEtv3V3MK5+7XiI UYCDUYmH16D0W4gQa2JZcWXuIUZpDhYlcV4740MhQgLpiSWp2ampBalF8UWlOanFhxiZODil GhiXSUyYqnDgTPbPm5rbtjz98CRuhfLFq5nPZx65qF8zKT7skOZXxSnBhvd3qaazVJ3OnFve 0el6Yld5DPexM51rJ5YmbD+/hC/w+MP6peK5gu2VbAE5HUwalqtOWyXntJRtzNJusfAy9vzh xChZeOWfgVBp1YuEjuiyxpZ15XPaXtuIsWq6yyuxFGckGmoxFxUnAgCGQpahlQIAAA== Archived-At: Subject: Re: [Ace] Authorization on the client side 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, 04 Mar 2015 19:07:35 -0000 SGkgU3RlZmZpLA0KDQpJIGRpc2FncmVlLiAgSWYgeW91IHJlY2FsbCBmcm9tDQpodHRwOi8vd3d3 LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvYWNlL2N1cnJlbnQvbXNnMDA5OTUuaHRtbA0KSSBs aXN0ZWQgYSBudW1iZXIgb2Yg4oCcYXV0aG9yaXphdGlvbiBwcm9ibGVtc+KAnSBvbiB0aGUgY2xp ZW50IHNpZGUsIG5vbmUgb2YNCndoaWNoIGlzIG9mIHRoZSBjb25jZXJuIG9mIEFDRSBJTUhPLiBU aGUgc2FtZSBhcHBsaWVzIHRoZSBwcm9ibGVtIHlvdQ0KbGlzdCwgY29ycmVzcG9uZGluZyB0byBV MS4yYiBvZg0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2FjZS9jdXJyZW50 L21zZzAxMDE5Lmh0bWwuDQoNCkp1c3QgYmVjYXVzZSBJIGhhdmVu4oCZdCBoYWQgdGltZSB0byBh bnN3ZXIgdGhpcyBtYWlsIHRocmVhZCB0b2RheSBkb2VzbuKAmXQNCm1lYW4gdGhhdCB5b3UgY2Fu IGZvcmdldCBhYm91dCBvdXIgbGFzdCBtb250aHMgb2YgZGlzY3Vzc2lvbnMuIEnigJlsbCBiZQ0K YmFjay4NCg0KDQpCZXN0IHJlZ2FyZHMsDQpHw7ZyYW4NCg0KDQoNCg0KT24gMjAxNS0wMy0wNCAx OTozNywgIlN0ZWZhbmllIEdlcmRlcyIgPGdlcmRlc0B0emkuZGU+IHdyb3RlOg0KDQo+SGkgYWxs LA0KPg0KPldoYXQgSSBnZXQgZnJvbSB0aGUgZGlzY3Vzc2lvbiBpcyB0aGF0IHdlIGFncmVlIHRo YXQgdGhlcmUgaXMgYW4NCj5hdXRob3JpemF0aW9uIHByb2JsZW0gb24gdGhlIGNsaWVudCBzaWRl LiBXZSBhbHNvIGFncmVlIHRoYXQgZm9yIHNvbWUNCj5hdXRob3JpemF0aW9uIHByb2JsZW1zIHdl IGRvbid0IG5lZWQgYSBzb3BoaXN0aWNhdGVkIGF1dGhvcml6YXRpb24NCj5tZWNoYW5pc20uDQo+ DQo+U28gbWF5YmUgd2UgY2FuIHBvc3Rwb25lIGZ1cnRoZXIgZGlzY3Vzc2lvbnMgYWJvdXQgc29s dXRpb25zIGFuZCBqdXN0DQo+ZmluaXNoIHRoZSB1c2UgY2FzZXMgZHJhZnQ/DQo+DQo+V2UgY2Fu IGtlZXAgdGhlIGF1dGhvcml6YXRpb24gcHJvYmxlbSBvbiB0aGUgY2xpZW50IHNpZGUgaW4gdGhl IHByb2JsZW0NCj5zdW1tYXJ5IHNlY3Rpb25zLiBNb3Jlb3Zlciwgd2UgY2FuIGFkZCB0aGUgZm9s bG93aW5nIHRvIHNlY3Rpb24gMy4yDQo+KENvbmZpZ3VyYXRpb24gb2YgQWNjZXNzIFBlcm1pc3Np b25zKTogIkVuZHBvaW50cyBuZWVkIHRvIGJlIGVuYWJsZWQgdG8NCj5lbmZvcmNlIHRoZSBhdXRo b3JpemF0aW9uIHBvbGljaWVzIG9mIHRoZWlyIHByaW5jaXBhbHMuIEluIHNvbWUgY2FzZXMsDQo+ YXV0aG9yaXphdGlvbiBwcm9ibGVtcyBtaWdodCBiZWkgc29sdmVkIGJ5IGltcGxpY2l0IGF1dGhv cml6YXRpb24gKGFsbA0KPmF1dGhlbnRpY2F0ZWQgZW50aXRpZXMgYXJlIGF1dGhvcml6ZWQpLiIN Cj4NCj5XaGF0IGRvIHlvdSB0aGluaz8NCj4NCj5CZXN0IHJlZ2FyZHMNCj5TdGVmZmkNCj4NCj4t LSANCj5TdGVmYW5pZSBHZXJkZXMJCQlUZWw6ICs0OSA0MjEgMjE4IDYzOTA2DQo+VFpJIFVuaXZl cnNpdMOkdCBCcmVtZW4JCUUtTWFpbDogZ2VyZGVzQHR6aS5kZQ0KPkJpYmxpb3RoZWtzdHIuIDEs IE1aSCA1MTUwDQo+MjgzNTkgQnJlbWVuLCBHZXJtYW55DQo+DQo+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5BY2UgbWFpbGluZyBsaXN0DQo+QWNlQGll dGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UNCg0K From nobody Wed Mar 4 16:42:21 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 665381A1BE5 for ; Wed, 4 Mar 2015 16:42:20 -0800 (PST) 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 mgjIKNdLqTH3 for ; Wed, 4 Mar 2015 16:42:16 -0800 (PST) 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 08DDE1A1BBB for ; Wed, 4 Mar 2015 16:42:15 -0800 (PST) X-AuditID: c1b4fb30-f79c86d000000fc0-45-54f7a6657151 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 0A.FE.04032.566A7F45; Thu, 5 Mar 2015 01:42:13 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.70]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0210.002; Thu, 5 Mar 2015 01:42:13 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Stefanie Gerdes , Hannes Tschofenig , "Ace@ietf.org" Thread-Topic: [Ace] U1.2 in Use Case Document Thread-Index: AQHQVbL1RkiN6OYzzEyLTf3fE9ZKCp0K/GYAgAAliYCAAe0ZgA== Date: Thu, 5 Mar 2015 00:42:12 +0000 Message-ID: References: <54F5B1F2.6050205@gmx.net> <54F616CF.20607@tzi.de> In-Reply-To: <54F616CF.20607@tzi.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-ID: <3816C6A1CF214A4EA876BEB874926F88@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGfG3Rjd12fcQg5WfrS2+f+thtth48S6j xdKd91gdmD0Wb9rP5rFkyU8mj21vvzIHMEdx2aSk5mSWpRbp2yVwZSzZv52t4Nx6xorDa04y NjD2rGbsYuTkkBAwkVg44w8ThC0mceHeerYuRi4OIYEjjBIL1v2BchYxSmx/dgCsik3AReJB wyMwW0SgWGLqlCdgk4QFdCS2/t0BZHMAxXUlrq/3gihxkri6/RIziM0ioCJxZsUfMJtXwELi 2eRONhBbSCBXonXmYjCbE6hm6/U2MJsR6KDvp9aArWIWEJe49WQ+1KECEkv2nGeGsEUlXj7+ xwpiiwroSay83sQGEVeSWHT7MxPIOcwCmhLrd+lDjLGWeHR5FzuErSgxpfshO8Q5ghInZz5h mcAoPgvJtlkI3bOQdM9C0j0LSfcCRtZVjKLFqcVJuelGRnqpRZnJxcX5eXp5qSWbGIExeHDL b4MdjC+fOx5iFOBgVOLhNSj9FiLEmlhWXJl7iFGag0VJnNfO+FCIkEB6YklqdmpqQWpRfFFp TmrxIUYmDk6pBsZwhUPCd4/+5Wi5M2nflakOzpe4N/MZS8u1lnawrl2Y3SjiIHCqz+AmgyfH 2eZVq5UTvi9f86HscKeG86cDNXE/1hq+dzZpje24b2rby7mnqVVS+8hN6QIPjuDQUgnZpOgQ Kybj/5MWeF5dVnD0tKOc2kJHv+/Pz/9da3UmaPbNczurjnoprlZiKc5INNRiLipOBAD+AjPX ogIAAA== Archived-At: Subject: Re: [Ace] U1.2 in Use Case Document 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, 05 Mar 2015 00:42:20 -0000 SGkgU3RlZmZpIGFuZCBhbGwsDQoNCiANClRyeWluZyB0byBjYXRjaCB1cCB3aXRoIHRoZSBtYWls cy4gSSBqdXN0IHN1bW1hcml6ZSBzb21lIGNvbW1lbnRzIG9uIHRoaXMNCm1haWwgZm9yIG5vdy4N Cg0KVGVybWlub2xvZ3kgYW5kIHByb2JsZW0gc3RhdGVtZW50DQotIC0gLQ0KQ3VycmVudCB0ZXJt aW5vbG9neSwgb3IgaG93IGl0IGlzIGFwcGxpZWQsIGlzIHVuc2F0aXNmYWN0b3J5LCBhcyBJ4oCZ dmUNCnJlLWl0ZXJhdGVkIGEgY291cGxlIG9mIHRpbWVzLiBJ4oCZdmUgcHJldmlvdXNseSBiZWVu IHdvcmtpbmcgaW4gbGFyZ2UNCnByb2plY3RzIHdoZXJlIHRlcm1pbm9sb2d5IGFuZCBwcm9ibGVt IHN0YXRlbWVudCB3YXMgdW5jbGVhciBhbmQgaXQgaXMgYW4NCmFic29sdXRlIHdhc3RlIG9mIHRp bWUuIEkgdGhpbmsgb3RoZXJzIGluIHRoaXMgZ3JvdXAgaGF2aW5nIHNpbWlsYXINCmV4cGVyaWVu Y2VzIGNhbiBjb25maXJtIHRoaXMuDQoNCg0KV2UgaGF2ZSBkaWZmZXJlbnQgb3B0aW9ucyB0byBy ZXNvbHZlIHRoaXMuDQoNCjEuIFdlIGNhbiByZW1vdmUgcm9sZSB0ZXJtaW5vbG9neSBmcm9tIHRo ZSB1c2UgY2FzZSBkcmFmdCBhbmQgZXhwcmVzcyB0aGUNCnByb2JsZW1zIGluIHRlcm1zIG9mIHRo ZSBhY3RvcnMgaW4gdGhlIHVzZSBjYXNlcy4gRS5nLiAiZnJ1aXQgdmVuZG9ycyB3YW50DQp0byBn cmFudCBkaWZmZXJlbnQgYWNjZXNzIHJpZ2h0cyB0byBkaWZmZXJlbnQgcGFydGllcyB0byBtZWFz dXJlbWVudHMgb2YNCmdvb2Rz4oCZIHRlbXBlcmF0dXJlcyIuIFRoYXQgd291bGQgc2F2ZSB0aGUg dXNlIGNhc2UgZG9jdW1lbnQsIGJ1dCBpbiB0aGlzDQpjYXNlIHdlIGRvbuKAmXQgaGF2ZSBhIGdl bmVyYWwgcHJvYmxlbSBzdGF0ZW1lbnQgaW4gdGVybXMgb2Ygcm9sZXMsIGFuZCB0aGF0DQp0aGVu IGJlY29tZXMgdGhlbiBvdXIgbmV4dCBjaGFsbGVuZ2UuDQoNCjIuIElmIHdlIGluc3RlYWQgZGVm aW5lIHJvbGVzIChSZXNvdXJjZSBTZXJ2ZXIsIENsaWVudCBldGMuKSB0aGVuIHdlIG11c3QNCmJl IGFibGUgdG8gZXhwcmVzcyB0aGUgcmVsZXZhbnQgcHJvYmxlbXMgYmFzZWQgb24gdGhlIHVzZSBj YXNlcyBpbiB0ZXJtcw0Kb2YgdGhlIHJvbGVzIGRlZmluZWQuIE90aGVyd2lzZSB0aGUgcm9sZSBk ZWZpbml0aW9ucyBhcmUgbm90IGdvb2QgZW5vdWdoLg0KRm9yIGV4YW1wbGUgIlJlc291cmNlIE93 bmVycywgc3VjaCBhcyBmcnVpdCB2ZW5kb3JzLCB3YW50cyB0byBncmFudA0KZGlmZmVyZW50IGFj Y2VzcyByaWdodHMgdG8gZGlmZmVyZW50IHBhcnRpZXMgZm9yIHRoZWlyIHJlc291cmNlcywgc3Vj aCBhcw0KdGVtcGVyYXR1cmVzIg0KDQpJZiB3ZSBjYW7igJl0IGV4cHJlc3Mgd2hhdCBhcmUgdGhl IGFzc2V0cyBhbmQgdGhlIHN0YWtlaG9sZGVycyBpbiBhIHdlbGwNCmRlZmluZWQgd2F5LCBzbyB0 aGF0IHdlIGNhbiBmb3JtdWxhdGUgdGhlIHByb2JsZW0gc3RhdGVtZW50IGluIHRlcm1zIG9mDQp0 aGVzZSwgdGhlbiB3ZSBoYXZlIGEgc2VyaW91cyBwcm9ibGVtLiBJIGFkdm9jYXRlIHRoYXQgd2Ug YWRvcHQgYW4NCmVzdGFibGlzaGVkIHRlcm1pbm9sb2d5IHN1Y2ggYXMgT0F1dGggb3IgVU1BLiBX aGF0ZXZlciBjbGllbnQgYXNwZWN0cyB3ZQ0Kd2FudCB0byBmb3JtdWxhdGUgY2FuIHN1cmVseSBi ZSBleHByZXNzZWQgaW4gYW55IG9mIHRoZXNlIHRlcm1pbm9sb2d5Lg0KDQpTb21lIGNvbnRyb2wg cXVlc3Rpb25zIG9uIGhvdyBmYXIgd2UgaGF2ZSByZWFjaGVkIGluIHRoaXMgd29yazoNCg0KLSBJ biB0aGUgY29udGFpbmVyIHVzZSBjYXNlLCBjYW4gd2UgYWdyZWUgdGhhdCB0aGUgdGVtcGVyYXR1 cmUgc2Vuc29ycyBhbmQNCmZhbiBhY3R1YXRvcnMgYXJlIHRoZSBtYWluIOKAnGl0ZW1zIG9mIGlu dGVyZXN04oCdLg0KDQotIENhbiB3ZSBkZW5vdGUgdGhlIHRlbXBlcmF0dXJlIHNlbnNvciBhbmQg ZmFuIGFjdHVhdG9ycyDigJxSZXNvdXJjZXPigJ0/DQoNCi0gQ2FuIHdlLCBhcyBFdmUgcHJvcG9z ZWQsIGFncmVlIHRvIHZpZXcgdGhlIHRlbXBlcmF0dXJlIHNlbnNvciAtIGZhbg0KYWN0dWF0b3Ig aW50ZXJhY3Rpb24gYXMgdHdvIG9uZS13YXkgcmVsYXRpb25zaGlwcywgaS5lLiB0aGVyZSBhcmUN CnRlbXBlcmF0dXJlLXJlc291cmNlcyBhbmQgdGVtcGVyYXR1cmUtY2xpZW50cywgYXMgd2VsbCBh cyBmYW4tcmVzb3VyY2VzDQphbmQgZmFuLWNsaWVudHMgKHNvbWUgb2Ygd2hpY2ggbWF5IGJlIGNv LWxvY2F0ZWQpLg0KDQooTWF5YmUgd2UgY2FuIHRoZW4gYXZvaWQgZm9ybXVsYXRpb25zIHN1Y2gg YXMgIklmIHRoZSB0ZW1wZXJhdHVyZSBzZW5zb3INCmlzIG5vdCBhYmxlIHRvIGRlY2lkZSBpZiBh IHJlc291cmNlIGlzIGF1dGhvcml6ZWTigJ0/IFNlZSBmdXJ0aGVyIGRvd24gaW4NCnRoaXMgbWFp bC4pDQoNCg0KDQpDb25zdHJhaW5lZCBjbGllbnRzDQotIC0gLQ0KT25lIHJlY3VycmluZyB0aGVt ZSBpbiB0aGlzIGRpc2N1c3Npb24gaGFzIGJlZW4gb24gY29uc3RyYWluZWQgY2xpZW50DQpkZXZp Y2VzLiAgVGhlcmUgaXMgYSBxdWVzdGlvbiBhYm91dCB3aGF0IGtpbmQgb2YgImF1dGhvcml6YXRp b24gcHJvYmxlbXPigJ0NCnRoYXQgYXJlIHJlbGV2YW50IHRvIHRoZSBjbGllbnQgZGV2aWNlLiBJ dCBpcyBtYWlubHkgcmVsYXRlZCB0byBhc3BlY3RzIG9mDQphIGNsaWVudCBkaXNjbG9zaW5nIGEg cmVxdWVzdC4gVGhlcmUgaGFzIGJlZW4gcmVwZWF0ZWQgY2xhaW1zIGFib3V0IHRoZQ0KbmVlZCBm b3Igc29waGlzdGljYXRlZCBhY2Nlc3MgY29udHJvbCBwb2xpY2llcyBvbiB0aGUgY2xpZW50IHNp ZGUsIGluIHRoZQ0Kc2Vuc2UgdGhhdCB0aGUgY2xpZW50IGFjdGlvbnMsIHN1Y2ggYXMgbWFraW5n IGEgcmVxdWVzdCwgbmVlZCB0byBiZQ0Kc3ViamVjdCB0byBhY2Nlc3MgY29udHJvbCBwb2xpY2ll cywganVzdCBiZWNhdXNlIHRoZSBkZXZpY2VzIGFyZQ0KY29uc3RyYWluZWQuIEJ1dCBub3doZXJl IGluIHRoZSB1c2UgY2FzZSBkb2N1bWVudCBpcyB0aGlzIGNsYWltDQpzdWJzdGFudGlhdGVkLCBp LmUuIHRoYXQgYSBwYXJ0aWN1bGFyIHVzZSBjYXNlIGlzIHJlcXVpcmluZyBzdWNoIGENCmZlYXR1 cmUuIFRoZXJlIGFyZSBvbmx5IGFic3RyYWN0IGZvcm11bGF0aW9ucyBhYm91dCBwcmluY2lwYWxz LCBhbmQNCmludGVycHJldGVkIGFzIHJlc291cmNlIG93bmVyIGFzIHdlbGwgYXMgY2xpZW50IG93 bmVycy4gVGhlIG1vdGl2YXRpb24gZm9yDQp0aGF0IGhhcyBiZWVuIHRoYXQgaWYgd2UgZGVzY3Jp YmUgdGhlIHVzZSBjYXNlIGluIHRvbyBtdWNoIGRldGFpbCBpdA0KYmVjb21lcyBzb2x1dGlvbiBz cGVjaWZpYy4gQW4gYWx0ZXJuYXRpdmUgZXhwbGFuYXRpb24gaXMgdGhhdCBvbmx5IGZldywgaWYN CmFueSwgb2YgdGhlIHVzZSBjYXNlcyBhY3R1YWxseSByZXF1aXJlIGNsaWVudCBzaWRlIGFjY2Vz cyBjb250cm9sIHBvbGljaWVzLg0KDQpJIHRoaW5rIHdlIHNob3VsZCBkZXRhY2ggYW55IHBvdGVu dGlhbCBhY2Nlc3MgY29udHJvbCBwb2xpY3kgcHJvYmxlbXMgb2YNCnRoZSBjbGllbnQgZnJvbSB0 aGF0IHJlbGF0ZWQgdG8gcmVzb3VyY2UgYWNjZXNzLCBiZWNhdXNlIGl0IGlzIGRpZmZlcmVudCwN Cml0IGlzIG5vdCBkb2N1bWVudGVkIHRvIGJlIHJlbGV2YW50LCBhbmQgaXQgaXMgYW4gaW5kZXBl bmRlbnQgcHJvYmxlbSB0aGF0DQptYWtlcyB0aGUgcHJvYmxlbSBmb3JtdWxhdGlvbiBjb21wbGV4 LiBGdXJ0aGVybW9yZSwgbm8gb25lIGFjdHVhbGx5IGtub3dzDQphYm91dCB0aGUgbmVlZCBhbmQg bmF0dXJlIG9mIHBvbGljaWVzIGZvciBpbiB0aGVzZSBzaXR1YXRpb25zLiBJdCBpcyBwdXJlDQpz cGVjdWxhdGlvbnMuIEkgdGhpbmsgdGhhdCBpZiBhbnl0aGluZywgc29tZSBzb3J0IG9mICJkZWNp c2lvbiBwb2xpY2llc+KAnQ0KY291bGQgcG90ZW50aWFsbHkgYmUgdXNlZnVsLiBGb3JtdWxhdGlu ZyBpdCBhcyBhY2Nlc3MgY29udHJvbCBwcm9ibGVtDQpsZWFkcyB0byB2ZXJ5IHN0cmFuZ2Ugc3Rh dGVtZW50cyBhcyBJIHNob3dlZCBhdCB0aGUgZW5kIG9mIHRoaXMgbWFpbDoNCmh0dHA6Ly93d3cu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9hY2UvY3VycmVudC9tc2cwMTAxOS5odG1sDQoNCg0K TW9yZSBsYXRlci4NCg0KQmVzdCByZWdhcmRzLA0KR8O2cmFuDQoNCg0KDQpPbiAyMDE1LTAzLTAz IDIxOjE3LCAiU3RlZmFuaWUgR2VyZGVzIiA8Z2VyZGVzQHR6aS5kZT4gd3JvdGU6DQoNCj5IaSBh bGwsDQo+DQo+T24gMDMvMDMvMjAxNSAwNjowMyBQTSwgR8O2cmFuIFNlbGFuZGVyIHdyb3RlOg0K Pj4gSGkgSGFubmVzLA0KPj4NCj4+IE9uIDIwMTUtMDMtMDMgMTQ6MDYsICJIYW5uZXMgVHNjaG9m ZW5pZyIgPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+DQo+Pndyb3RlOg0KPj4NCj4+PiBIaSBh bGwsDQo+Pj4NCj4+PiBsZXQgbWUgdHJ5IHRvIHNlZSB3aGV0aGVyIEkgdW5kZXJzdGFuZCB0aGUg aXNzdWUgdGhhdCdzIGN1cnJlbnRseSB1bmRlcg0KPj4+IGRpc2N1c3Npb24uDQo+Pj4NCj4+PiBJ dCBzZWVtcyB0aGF0IHRoZSBkZWJhdGUgZm9jdXNlcyBvbiB0aGlzIHJlcXVpcmVtZW50IGZyb20g dGhlDQo+Pj4nQ29udGFpbmVyDQo+Pj4gbW9uaXRvcmluZycgdXNlIGNhc2U6DQo+Pj4NCj4+PiAi DQo+Pj4gICAgbyAgVTEuMiBQcmluY2lwYWxzIHdhbnQgdG8gZ3JhbnQgZGlmZmVyZW50IGFjY2Vz cyByaWdodHMgZm9yDQo+Pj4gICAgICAgZGlmZmVyZW50IHJlc291cmNlcyBvbiBhbiBlbmRwb2lu dC4NCj4+PiAiDQo+Pg0KPj4gQWN0dWFsbHksIHdlIGFyZSBub3QgZGViYXRpbmcgdGhpcyBVMS4y IHJlcXVpcmVtZW50LiBTdGVmZmkgbWFkZSBhIG5ldw0KPj5zZXQNCj4+IG9mIHJlcXVpcmVtZW50 cywgc2VlDQo+PiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvYWNlL2N1cnJl bnQvbXNnMDA5ODIuaHRtbA0KPj4NCj4+IFRoZSBkZWJhdGUgZm9jdXNlZCBvbiB0aGlzIHJlcXVp cmVtZW50IHByb3Bvc2VkIGJ5IFN0ZWZmaToNCj4+DQo+PiAiVTEuMWEgUHJpbmNpcGFscyBzdWNo IGFzIHRoZSBmcnVpdCB2ZW5kb3IsIHRoZSB0cmFuc2xvYWRpbmcgcGVyc29ubmVsDQo+Pm9yDQo+ PiB0aGUgY29udGFpbmVyIG93bmVycyB3YW50IHRvIGRlZmluZSBhdXRob3JpemF0aW9ucyBmb3Ig dGhlaXIgcmVzb3VyY2VzDQo+PiBhbmQgZW5kcG9pbnRzLiINCj4+DQo+PiAoSSBpbnNlcnQg4oCc YeKAnSwg4oCcYuKAnSwg4oCcY+KAnSBldGMuIHRvIGRpc3Rpbmd1aXNoIHRoZSBkaWZmZXJlbnQg dmVyc2lvbnMgb2YNCj4+IHJlcXVpcmVtZW50cykNCj4+DQo+Pg0KPj4gVGhlbiBTdGVmZmkgcHJv cG9zZWQgdG8gc3BsaXQgVTEuMWEgaW4gdGhlc2UgcmVxdWlyZW1lbnRzOg0KPj4NCj4+IChodHRw Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvYWNlL2N1cnJlbnQvbXNnMDA5OTIuaHRt bCkNCj4+DQo+Pg0KPj4g4oCcVTEuMWI6IFJlc291cmNlIE93bmVycyB3YW50IHRvIGdyYW50IGRp ZmZlcmVudCBhY2Nlc3MgcmlnaHRzIGZvciB0aGVpcg0KPj4gcmVzb3VyY2VzIHRvIGRpZmZlcmVu dCBwYXJ0aWVzLg0KPj4NCj4+IFUxLjJiOiBDbGllbnQgT3duZXJzIHdhbnQgdG8gZGVmaW5lIGZv ciB0aGVpciBjbGllbnRzIGlmIGFuZCBob3cgdGhleQ0KPj5hcmUNCj4+IGFsbG93ZWQgdG8gYWNj ZXNzIHJlc291cmNlcyBob3N0ZWQgb24gYSBSZXNvdXJjZSBTZXJ2ZXIuIg0KPg0KPkluIGZhY3Qg SSBkaWRuJ3Qgd2FudCB0byBzcGxpdCBVMS4xYS4gWW91LCBHw7ZyYW4sIHByb3Bvc2VkIGluDQo+ aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2FjZS9jdXJyZW50L21zZzAwOTkx Lmh0bWwgdG8NCj5yZXBsYWNlIFUxLjEgd2l0aCB0d28gInJlcXVpcmVtZW50cyIgYXMgeW91IGNh bGxlZCB0aGVtLiBJIGFtIG5vdCBoYXBweQ0KPndpdGggdGhpcyBwcm9wb3NhbCBidXQgd291bGQg aGF2ZSBhZ3JlZWQgdG8gaXQgaWYgaXQgaGVscGVkIHRoaW5ncy4NCj4NCj5UaGUgbWVhbmluZyBv ZiB0aGUgb3JpZ2luYWwgVTEuMSBwcm9ibGVtIGlzIHRoYXQgcHJpbmNpcGFscyBpbiB0aGlzIHVz ZQ0KPmNhc2Ugd2FudCB0byBncmFudCBkaWZmZXJlbnQgYXV0aG9yaXphdGlvbnMgdG8gZGlmZmVy ZW50IHBlb3BsZSAvDQo+ZGV2aWNlcyAvIHJlc291cmNlcyAobWVhbmluZyB0aGF0IGRldmljZXMg b2YgY29tcGFueSBBIGdldCBkaWZmZXJlbnQNCj5hY2Nlc3MgcmlnaHRzIHRoZW4gZGV2aWNlcyBv ZiBjb21wYW55IEIpLiBJdCBzZWVtcyB0aGF0IGl0IGlzIHF1aXRlDQo+ZGlmZmljdWx0IHRvIGZp bmQgYSBuZXV0cmFsIHBocmFzaW5nIGZvciB0aGlzIHByb2JsZW0uDQo+DQo+VGhlIHNwbGl0IG5v dyBzaG93cyBhIGNvbXBsZXRlbHkgZGlmZmVyZW50IGFzcGVjdCBvZiB0aGlzIHByb2JsZW06IHdl DQo+Y2FuIHByb3RlY3QgdGhlIGNsaWVudCBzaWRlIG9yIHdlIGNhbiBwcm90ZWN0IHRoZSBzZXJ2 ZXIgc2lkZSBvciBib3RoLg0KPlRoZXNlIHJlYWxseSBhcmUgc29sdXRpb24gc3BlY2lmaWMgYW5k IGFzIHdlIGNhbiBzZWUsIHRoaXMgbGVhZHMgdG8NCj5wZW9wbGUgd2FudGluZyB0byBkZWZlbmQg dGhlaXIgZmF2b3JpdGUgc29sdXRpb24uIEluc3RlYWQgb2Y6ICJ1c2Vycw0KPnNvbWVob3cgd2Fu dCB0byBncmFudCBkaWZmZXJlbnQgYXV0aG9yaXphdGlvbnMgdG8gZGlmZmVyZW50IHBlb3BsZSIg d2UNCj5hcmUgZGVlcCBpbnRvIGEgc29sdXRpb24gc3BhY2UgZGlzY3Vzc2lvbiBhYm91dCB3aGV0 aGVyIGl0IGlzIG1vcmUNCj51c2VmdWwgdG8gcHJvdGVjdCB0aGUgc2VydmVyIG9yIHRoZSBjbGll bnQgc2lkZSwgaWYgdGhlIGNsaWVudCBzaWRlIGV2ZW4NCj5uZWVkcyBwcm90ZWN0aW9uIGFuZCBz byBvbi4gSSB3b3VsZCBsaWtlIHRvIGVtcGhhc2l6ZSB0aGF0IHRoaXMgaXMgbm90DQo+d2hhdCBV MS4xIGlzIGFib3V0LiBNYXliZSB3ZSBjYW4gc3RpbGwgZmluZCBhIGJldHRlciBwaHJhc2luZyB0 aGF0IGRvZXMNCj5ub3QgaW5kaWNhdGUgYSBzcGVjaWZpYyBzb2x1dGlvbi4NCj4NCj5UaGUgZGlm ZmVyZW50IHByb3Bvc2FscyBmb3IgdGhlIHBocmFzaW5nIG9mIFUxLjEgaW5kaWNhdGUgYSBkaWZm ZXJlbnQNCj5wcm9ibGVtOiBEbyB3ZSB3YW50IHRvIGRldmVsb3AgYSBzb2x1dGlvbiB0aGF0IGV4 Y2x1c2l2ZWx5IHByb3RlY3RzDQo+cmVzb3VyY2VzIG9yIGRvIHdlIGFsc28gd2FudCB0byBjb25z aWRlciB0aGUgY2xpZW50IHNpZGU/IE1vc3Qgb2YgdXMgYXJlDQo+bW9yZSBmYW1pbGlhciB3aXRo IHRoZSBwcm90ZWN0aW9uIG9mIHJlc291cmNlcyBiZWNhdXNlIHdlIGFscmVhZHkga25vdw0KPnRo YXQgZnJvbSB3ZWIgc2NlbmFyaW9zLiBCdXQgaW4gdGhlc2Ugc2NlbmFyaW9zIHdlIGFsd2F5cyBo YXZlIGEgdXNlcg0KPnRoYXQgcGVyZm9ybXMgYXV0aG9yaXphdGlvbiBvbiB0aGUgY2xpZW50IHNp ZGUuIEZvciBjb25zdHJhaW5lZA0KPmVudmlyb25tZW50cywgaXQgaXMgbm90IGFsd2F5cyB0aGF0 IHNpbXBsZS4gV2UgbWlnaHQgaGF2ZSB0cnVlIG1hY2hpbmUNCj50byBtYWNoaW5lIChNMk0pIGNv bW11bmljYXRpb24gd2hlcmUgYSBkZXZpY2UgbXVzdCBkZWNpZGUgZm9yIGl0c2VsZg0KPndoZXRo ZXIgc29tZXRoaW5nIGlzIGF1dGhvcml6ZWQgYnkgaXRzIHVzZXIgb3Igbm90LiBNb3Jlb3Zlciwg ZGV2aWNlcw0KPm1pZ2h0IG5vdCBoYXZlIGRpc3BsYXlzIGFuZCB0aHVzIGl0IG1pZ2h0IG5vdCBi ZSBwb3NzaWJsZSBmb3IgdGhlIHVzZXINCj50byBkaXJlY3RseSBpbnRlcmFjdCB3aXRoIHRoZSBk ZXZpY2UgZm9yIGF1dGhvcml6YXRpb24uIFNvbHZpbmcgdGhlc2UNCj5wcm9ibGVtcyBpcyBub3Qg b3B0aW9uYWwuIEFuZCBJIHRoaW5rIGl0IGlzIGltcG9ydGFudCB0byBiZSBhd2FyZSBvZg0KPnRo ZXNlIHByb2JsZW1zLiBBIHNvbHV0aW9uIGNhbiBkZWNpZGUgaWYgYW5kIGhvdyB0byBzb2x2ZSB0 aGVtLg0KPg0KPj4NCj4+DQo+PiBSZWZlcnJpbmcgdG8gdGhlIFUxLjFhLCBJIHByb3Bvc2VkIHRv IGNsYXJpZnkgd2hhdCBVMS4xYiBtZWFucyBpbiB0ZXJtcw0KPj5vZg0KPj4gdGhlIGFjdG9ycyBh bmQgcmVzb3VyY2VzIG9mIHRoZSB1c2UgY2FzZToNCj4+IChodHRwOi8vd3d3LmlldGYub3JnL21h aWwtYXJjaGl2ZS93ZWIvYWNlL2N1cnJlbnQvbXNnMDEwMDAuaHRtbCkNCj4+DQo+PiDigJxVMS4x YzogUmVzb3VyY2UgT3duZXJzLCBzdWNoIGFzIGZydWl0IHZlbmRvcnMgYW5kIGNvbnRhaW5lciBv d25lcnMsDQo+PndhbnQNCj4+IHRvDQo+PiBncmFudCBkaWZmZXJlbnQgYWNjZXNzIHJpZ2h0cyB0 byBkaWZmZXJlbnQgcGFydGllcyBmb3IgdGhlaXIgcmVzcGVjdGl2ZQ0KPj4gcmVzb3VyY2VzLCBz dWNoIGFzIHRlbXBlcmF0dXJlcyBhbmQgZmFuIHNldHRpbmdzLiINCj4+DQo+Pg0KPj4gVGhpcyB3 YXMgbm90IGFncmVlZCwgc2VlIGRpc2N1c3Npb24gYWJvdXQgcmVzb3VyY2UgYW5kIGNsaWVudCBi ZWxvdy4NCj4+DQo+PiBXaXRoIHJlZ2FyZHMgdG8gVTEuMmIsIEkgcmVxdWVzdGVkIHRoYXQgdGhp cyBhYnN0cmFjdCBzdGF0ZW1lbnQgc2hvdWxkDQo+PmJlDQo+PiBleGVtcGxpZmllZCB3aXRoIGFj dG9ycyBhbmQgY2xpZW50IGRldmljZXMgZnJvbSB0aGlzIHVzZSBjYXNlIHRvIGFsbG93DQo+PiBl dmVyeW9uZSB0byBmb3JtIGFuIG9waW5pb24gaWYgdGhpcyBpcyBhIHJlbGV2YW50IGFjY2VzcyBj b250cm9sIHByb2JsZW0NCj4+IGluIHRoZSBzY29wZSBvZiBBQ0Ugb3Igbm90LiBJZiB0aGF0IGNh buKAmXQgYmUgbWFkZSwgdGhlbiBJIHRoaW5rIHRoaXMNCj4+IHJlcXVpcmVtZW50IGlzIGxlc3Mg cmVsZXZhbnQgZm9yIHRoaXMgdXNlIGNhc2UgYW5kIGNvbnNpZGVyIGxlYXZlIGl0DQo+Pm91dC4N Cj4NCj5JbWFnaW5lIGEgc3BlY2lmaWMgaW1wbGVtZW50YXRpb24gb2YgdGhlIGNvbnRhaW5lciBz Y2VuYXJpbyB3aGVyZSB0aGUNCj50ZW1wZXJhdHVyZSBzZW5zb3IgaXMgdGhlIGNsaWVudCBhbmQg dGhlIGZhbiBhY3R1YXRvciBpcyB0aGUgc2VydmVyLiBUaGUNCj5mcnVpdCB2ZW5kb3Igd2FudHMg dG8gbWFrZSBzdXJlIHRoYXQgdGhlIHRlbXBlcmF0dXJlIHNlbnNvciBzZW5kcyB0aGUNCj50ZW1w ZXJhdHVyZSB2YWx1ZXMgb25seSB0byBhdXRob3JpemVkIGZhbiBhY3R1YXRvciByZXNvdXJjZXMg YmVjYXVzZSBzaGUNCj5kb2Vzbid0IHdhbnQgdW5hdXRob3JpemVkIHBlb3BsZSB0byBnYWluIGtu b3dsZWRnZSBhYm91dCB0aGUgc3RhdGUgb2YNCj50aGUgZ29vZHMuIFRoZSBjb250YWluZXIgb3du ZXIgd2FudHMgdG8gbWFrZSBzdXJlIHRoYXQgdGhlIHNlcnZlciBvbmx5DQo+YWNjZXB0cyBkYXRh IGZyb20gYXV0aG9yaXplZCBjbGllbnRzLiBJbiB0aGlzIGNhc2UsIGJvdGggdGhlIGNsaWVudA0K Pm93bmVyIGFuZCB0aGUgcmVzb3VyY2Ugb3duZXIgd2lsbCBuZWVkIHRvIGRlZmluZSBhY2Nlc3Mg cG9saWNpZXMuIFRoZQ0KPmNsaWVudCBvd25lciAodGhlIGZydWl0IHZlbmRvcikgZGVmaW5lcyBh IHJ1bGUgdGhhdCBzdGF0ZXMgdGhhdCB0aGUNCj5jbGllbnQgKHRoZSB0ZW1wZXJhdHVyZSBzZW5z b3IpIGlzIGFsbG93ZWQgdG8gZG8gYSBQVVQgb24gcmVzb3VyY2VzIHRoYXQNCj5iZWxvbmcgdG8g YSBzcGVjaWZpYyBjb250YWluZXIgb3duZXIuIFRoZSByZXNvdXJjZSBvd25lciAodGhlIGNvbnRh aW5lcg0KPm93bmVyKSBkZWZpbmVzIGEgcnVsZSB0aGF0IHN0YXRlcyB0aGF0IGNsaWVudHMgb2Yg YSBjZXJ0YWluIGZydWl0IHZlbmRvcg0KPmFyZSBhbGxvd2VkIHRvIGRvIGEgUFVUIG9uIHRoZWly IHJlc291cmNlcy4gSWYgdGhlIHRlbXBlcmF0dXJlIHNlbnNvciBpcw0KPm5vdCBhYmxlIHRvIGRl Y2lkZSBpZiBhIHJlc291cmNlIGlzIGF1dGhvcml6ZWQsIGl0IGNhbm5vdCBlbmZvcmNlIHRoZQ0K PmF1dGhvcml6YXRpb24gZGVjaXNpb25zIG9mIGl0cyBvd25lci4NCj4NCj4+DQo+PiBOT1RFOiBJ 4oCZbSBub3Qgc2F5aW5nIFUxLjJiIGlzIG5vdCBhIHBvc3NpYmxlIHNlY3VyaXR5IGNvbmNlcm4u IEnigJltDQo+PiBxdWVzdGlvbmluZyB0aGF0IGl0IGlzIGFuIGFjY2VzcyBjb250cm9sIHByb2Js ZW0gYW5hbG9nb3VzIHRvIFUxLjFiLiBUaGUNCj4+IG9yaWdpbmFsIHJlcXVpcmVtZW50IGZvcm11 bGF0aW9uIFUxLjEgKGluIHRoZSBkcmFmdCkgYW5kIFUxLjFhIGJsdXJzIHRoZQ0KPj4gZGlzdGlu Y3Rpb24gYmV0d2VlbiByZXNvdXJjZSBhbmQgY2xpZW50IGFuZCBnaXZlcyB0aGUgaW1wcmVzc2lv biB0aGF0DQo+PiB0aGVyZSBpcyBhbiBhbmFsb2dvdXMgY2xpZW50IGFjY2VzcyBjb250cm9sIHBy b2JsZW0sIGJ1dCBJIGRvbuKAmXQgc2VlIGFueQ0KPj4gZXZpZGVuY2Ugb2YgdGhhdCBmcm9tIHRo ZSB1c2UgY2FzZXMuIEFuZCB0aGUgY3VycmVudCB0ZXJtaW5vbG9neSBpcw0KPj5tYWtpbmcNCj4+ IHRoZSBkaXN0aW5jdGlvbiBkaWZmaWN1bHQuDQo+Pg0KPj4gTm93IHdlIG1ha2UgdGhlIHNhbWUg ZXhlcmNpc2UgaW4geW91ciBleGFtcGxlIGJlbG93Lg0KPj4NCj4+Pg0KPj4+IFRoZSBxdWVzdGlv biB0aGF0IHN1cmZhY2VkIGhlcmUgaXMgd2hldGhlciAncHJpbmNpcGFsJyBpcyB0aGUgcmlnaHQN Cj4+PnRlcm0NCj4+PiBvciBub3QuIFRoZSBkb2N1bWVudCBkZWZpbmVzIHByaW5jaXBhbCBhcyAi QSBzdWJqZWN0IHdobyBpcyBlaXRoZXIgYQ0KPj4+IHJlc291cmNlIG93bmVyIG9yIGEgY2xpZW50 IG93bmVyIG9yIGJvdGguIg0KPj4+DQo+Pj4gSGVyZSBpcyBhIHNsaWdodGx5IG1vZGlmaWVkIGV4 YW1wbGUgdXNpbmcgYSBkb29yIGxvY2sgc2NlbmFyaW8gdGhhdCBtYXkNCj4+PiBoZWxwIHVzIHNl ZSB0aHJvdWdoIHRoaXMgY2FzZS4gSW1hZ2luZSBhIGZhbWlseSB3aXRoIGEga2lkOiBBbGljZSwg Qm9iDQo+Pj4gYW5kIHRoZWlyIHlvdW5nIGNoaWxkIEV2ZS4NCj4+Pg0KPj4+IEFsaWNlIGFuZCBC b2IgYm91Z2h0IG9uZSBvZiB0aGVzZSBJbnRlcm5ldCBjb25uZWN0ZWQgZG9vciBsb2NrcyBhbmQg bm93DQo+Pj4gd2FudCB0byBjb25maWd1cmUgaXQuIFRoZXkgd2FudCB0byBjb25maWd1cmUgaXQg aW4gc3VjaCBhIHdheSB0aGF0IGFsbA0KPj4+IHRocmVlIGNhbiBlbnRlciB0aGVpciBob3VzZSBq dXN0IHVzaW5nIHRoZWlyIHNtYXJ0IHBob25lIChhbmQgYQ0KPj4+IHNwZWNpYWxseSBsb2FkZWQg YXBwKS4NCj4+Pg0KPj4+IFdoZXRoZXIgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGlzIGluY2x1 ZGVkIGluIHRoZSBkb29yIGxvY2sgaXRzZWxmIG9yDQo+Pj4gaXMgcGFydCBvZiBzb21lIG90aGVy IGhvbWUgYXBwbGlhbmNlIGRvZXMgbm90IHJlYWxseSBtYXR0ZXIgZm9yIHRoZQ0KPj4+IG1vbWVu dC4gSW4gYW55IGNhc2UsIEFsaWNlIGFuZCBCb2IgY29uZmlndXJlIHRoZSBkb29yIGxvY2sgaW4g c3VjaCBhDQo+Pj53YXkNCj4+PiB0aGF0IEV2ZSBpcyBncmFudGVkIGFjY2Vzcy4gQWxpY2UgYW5k IEJvYiBhcmUgdGhlIG93bmVyIG9mIHRoZSByZXNvdXJjZQ0KPj4+ICg9ZG9vciBsb2NrKSBidXQg ZXZlbiBpZiB0aGV5IGRvIG5vdCAnb3duJyB0aGUgZG9vciBsb2NrIChidXQgaGF2ZQ0KPj4+IHJh dGhlciByZW50ZWQgaXQpIGRvZXMgbm90IHJlYWxseSBtYXR0ZXIuDQo+Pg0KPj4gSSBhZ3JlZSBh Ym91dCDigJxvd25lcnNoaXDigJ0sIGJ1dCBsZXTigJlzIGtlZXAgdGhlIHRlcm1pbm9sb2d5IGlu IHRoaXMNCj4+ZXhhbXBsZS4NCj4+DQo+Pj4NCj4+PiBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg ZG9lcyBub3QgbmVjZXNzYXJpbHkgbmVlZCB0byBrbm93IHRoYXQgdGhpcw0KPj4+IGFjY2VzcyBj b250cm9sIHBvbGljeSBpcyBhYm91dCAiRXZlIi4gQWxsIGl0IGNhcmVzIGlzIHRoYXQgdGhlcmUg aXMgYW4NCj4+PiBlbnRyeSBpbiB0aGUgYWNjZXNzIGNvbnRyb2wgbGlzdCB0aGF0IHBvaW50cyB0 byBzb21lIGNyZWRlbnRpYWwgb24gc29tZQ0KPj4+IGRldmljZS4gVGhhdCBjcmVkZW50aWFsIGhh cHBlbnMgdG8gcG9pbnQgdG8gYXBwIG9uIHRoZSBzbWFydCBwaG9uZSBFdmUNCj4+PiBpcyB1c2lu Zy4NCj4+Pg0KPj4+IE5vdywgdGhlIHF1ZXN0aW9uIGlzIGhvdyBFdmUsIHdobyBpcyB0aGUgY2xp ZW50IG93bmVyLCBmaXRzIGludG8gdGhhdA0KPj4+IHBpY3R1cmUuIFNoZSB3b3VsZCB1c2UgaGVy IHBob25lICg9Y2xpZW50KSB0byByZXF1ZXN0IGFjY2VzcyB0byB0aGUNCj4+PmRvb3INCj4+PiBi dXQgc2hlIHdvdWxkIG5vdCBiZSBpbnZvbHZlZCBpbiBwcm92aXNpb25pbmcgdGhlIGFjY2VzcyBj b250cm9sIHBvbGljeQ0KPj4+IGF0IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4NCj4+Pg0KPj4+ IERpZCBJIGNvcnJlY3RseSB1bmRlcnN0b29kIHRoaXMgaXNzdWU/DQo+Pg0KPj4gSSB0aGluayB5 b3UgYXJlIGNvcnJlY3QgaW4gdGhhdCB0aGUgZGlzY3Vzc2lvbiBpcyBob3cgdGhlIGNsaWVudCBv d25lcg0KPj4gZml0cyBpbnRvIHRoZSBwaWN0dXJlLg0KPg0KPkkgd291bGQgYWxzbyB0aGluayB0 aGF0IHRoaXMgaXMgdGhlIHByb2JsZW0uIEV2ZSB1c2VzIGhlciBzbWFydHBob25lIHRvDQo+cmVx dWVzdCBhY2Nlc3MgdG8gdGhlIGRvb3IgYW5kIGlzIGdyYW50ZWQgYWNjZXNzIGRlcGVuZGluZyBv biBBbGljZSBhbmQNCj5Cb2JzIGF1dGhvcml6YXRpb24uIEV2ZSBoYXMgbm8gaW5mbHVlbmNlIG9u IHRoZWlyIGRlY2lzaW9uLiBJbiB0aGUgZG9vcg0KPmxvY2sgY2FzZSB0aGlzIG1pZ2h0IG5vdCBh IGJpZyBwcm9ibGVtLiBFdmUgYWN0aXZlbHkgdXNlcyBoZXIgc21hcnRwaG9uZQ0KPnRvIGludGVy YWN0IHdpdGggdGhlIGRvb3IgbG9jay4gVGhlIHBob25lIG1pZ2h0IGFsc28gZGlzcGxheSBzb21l IGtpbmQNCj5vZiBkaWFsb2cgd2hlcmUgRXZlIGNhbiBkZWNpZGUgdG8gYWNjZXNzIHRoZSBkb29y IGxvY2sgb3Igbm90Lg0KPg0KPklmIEV2ZSBkb2Vzbid0IHVzZSBoZXIgcGhvbmUgYnV0IGEgY29u c3RyYWluZWQgZGV2aWNlIHRvIGFjY2VzcywgZS5nLg0KPnNvbWUgc29ydCBvZiBrZXkgZm9iLCBz aGUgbWlnaHQgd2FudCB0byBtYWtlIHN1cmUgdGhhdCBpdCBkb2Vzbid0DQo+cHJvdmlkZSBoZXIg Y3JlZGVudGlhbHMgdG8gZXZlcnlvbmUgd2hvIGlzIGFza2luZy4NCj4NCj4+DQo+PiBXaGV0aGVy IHRoZSBwaG9uZSBpcyBpbnZvbHZlZCBvciBub3QgaW4gdHJhbnNwb3J0aW5nIGFjY2VzcyBjb250 cm9sDQo+PnBvbGljeQ0KPj4gb3Igb3RoZXIgYXV0aG9yaXphdGlvbiBpbmZvcm1hdGlvbiB0byB0 aGUgcmVzb3VyY2Ugc2VydmVyIGlzIG5vdCB0aGUNCj4+aXNzdWUuDQo+Pg0KPj4gT25lIGlzc3Vl IHdlIGhhdmUgaXMgaWYgdGhlIGRvb3IgbG9jayBjYW4gYmUgY2FsbGVkIOKAnFJlc291cmNl4oCd IG9yIGlmIGl0DQo+PmlzDQo+PiBjb21wbGV0ZWx5IGFyYml0cmFyeSB3aGljaCBpcyDigJxSZXNv dXJjZSIgYW5kIHdoaWNoIGlzIOKAnENsaWVudOKAnS4gKEnigJltIGluDQo+PiBmYXZvdXIgb2Yg dGhlIGZvcm1lci4pDQo+Pg0KPj4gT25lIHRoaW5nIHdlIGRvIGFncmVlIGFib3V0IGlzIHRoYXQg dGhlIHRlbmFudHMsIEFsaWNlIGFuZCBCb2IsIHNob3VsZA0KPj5iZQ0KPj4gYWJsZSB0byBzZXQg YWNjZXNzIHBvbGljaWVzIGZvciB0aGUgbG9jay4gSSB0aGluayB0aGlzIGlzIHRoZSBhbmFsb2d1 ZQ0KPj5vZg0KPj4gVTEuMWIvYy4gQnV0IHNpbmNlIHdlIGNhbuKAmXQgYWdyZWVkIHdoZXRoZXIg dGhlIGxvY2sgaXMg4oCcUmVzb3VyY2UiIG9yIGNhbg0KPj4gYWx0ZXJuYXRpdmVseSBiZSDigJxD bGllbnQiLCBJIGNhbuKAmXQgdXNlIHRoZSB0ZXJtIOKAnFJlc291cmNlIE93bmVy4oCdLiAgTm9y DQo+PmNhbg0KPj4gd2UgdXNlIHRoZSB0ZXJtIOKAnENsaWVudCBPd25lcuKAnS4gV2l0aCByZWdh cmRzIHRvIHRoaXMsIEkgaGF2ZSBiZWVuDQo+PiBxdWVzdGlvbmluZyB0aGUgdXNlZnVsbmVzcyBv ZiB0aGUgY3VycmVudCB0ZXJtaW5vbG9neSBpbiB0aGUgZHJhZnQsIG9yDQo+Pmhvdw0KPj4gaXQg aXMgYXBwbGllZC4NCj4NCj5JbiB0aGUgdXNlIGNhc2VzIGRvY3VtZW50LCB3ZSBhcmUgZGVmaW5p bmcgdXNlIGNhc2VzIGZvciBjb25zdHJhaW5lZA0KPmVudmlyb25tZW50cy4gV2hlcmUgbmVlZGVk LCB3ZSBhc3N1bWUgQ29BUCBhcyB0aGUgdXNlZCBwcm90b2NvbC4gSW4gQ29BUA0KPndlIGhhdmUg dHdvIGVuZHBvaW50cywgdGhlIGNsaWVudCBhbmQgdGhlIHNlcnZlciwgdGhhdCBhcmUgY29tbXVu aWNhdGluZw0KPndpdGggZWFjaCBvdGhlci4gVGhlIHNlcnZlciBob3N0cyByZXNvdXJjZXMgdGhh dCBjYW4gYmUgYWNjZXNzZWQgYnkgdGhlDQo+Y2xpZW50LiBXZSBjb3VsZCBkZWZpbmUgdGhhdCBh IGRvb3IgbG9jayBNVVNUIGJlIGEgIENvQVAgc2VydmVyIGFuZCB0aGF0DQo+dGhlIGRldmljZSBh Y2Nlc3NpbmcgdGhlIGRvb3IgbG9jayBNVVNUIGJlIGEgQ29BUCBjbGllbnQgb3IgdmljZSB2ZXJz YS4NCj5JZiB0aGVyZSBpcyBubyBzdHJvbmcgZXZpZGVuY2UgdG8gZG8gc28sIEkgd291bGQgcmF0 aGVyIG5vdCByZXN0cmljdA0KPkNvQVAgaW1wbGVtZW50YXRpb25zIGluIHN1Y2ggYSB3YXkuIEl0 IHNlZW1zIHdyb25nIHRvIG1lIHRvIHNheSB0aGF0DQo+Q29BUCBpcyBmbGV4aWJsZSBlbm91Z2gg dG8gYWxsb3cgZm9yIGFsbCBraW5kcyBvZiBzZXR0aW5ncyBidXQNCj51bmZvcnR1bmF0ZWx5IG91 ciBhdXRob3JpemF0aW9uIHNvbHV0aW9uIGRvZXMgbm90IGNvbnNpZGVyIHRoaXMNCj5mbGV4aWJp bGl0eSB3aGljaCBpcyB3aHkgQ29BUCBpcyBsZXNzIGZsZXhpYmxlIGlmIHdlIGFyZSB1c2luZw0K PmF1dGhvcml6YXRpb24uDQo+DQo+Pg0KPj4gTWF5YmUgd2UgY2FuIHVzZSB0aGUgcXVhbGlmaWNh dGlvbiDigJxsb2NrLVJlc291cmNlIiBhbmQg4oCcbG9jay1DbGllbnQiIHRvDQo+PiBkaXN0aW5n dWlzaCBmcm9tIG90aGVyIHJlc291cmNlcyBhbmQgY2xpZW50cz8gQW5kIHRoZW4g4oCcbG9jay1S ZXNvdXJjZQ0KPj4gT3duZXLigJ0gKEFsaWNlIGFuZCBCb2IpIGFuZCDigJxsb2NrLUNsaWVudCBP d25lcuKAnSAoRXZlKSB3b3VsZCBhbHNvIGJlIHdlbGwNCj4+IGRlZmluZWQ/DQo+Pg0KPj4NCj4+ IFRoZSBvdGhlciBpc3N1ZSByZWxhdGVzIHRvIHdoYXQgaXMgdGhlIHByb2JsZW0gZm9yIEV2ZS4g Q29uc2lkZXIgdGhlDQo+PiBhbmFsb2d1ZSBvZiBVMS4yYiBhYm92ZSBpbiB0aGlzIHNldHRpbmc6 DQo+Pg0KPj4gVTEuMmI6ICJFdmUgd2FudHMgdG8gZGVmaW5lIGZvciBoZXIgcGhvbmUgaWYgYW5k IGhvdyBpdCBpcyBhbGxvdyB0bw0KPj4gcmVxdWVzdCB0aGUgbG9jayB0byBiZSBvcGVuZWQuIg0K Pj4NCj4+IFRvIG1lIGl0IGlzIHF1aXRlIGNsZWFyIHRoYXQgdGhpcyBpcyBhbiBhd2t3YXJkIHdh eSBvZiBmb3JjaW5nIGFuIGFjY2Vzcw0KPj4gY29udHJvbCBwcm9ibGVtIGZvcm11bGF0aW9uIGlu dG8gd2hhdCBpc27igJl0LiBXaGVuIEV2ZSB3YW50cyB0byBvcGVuIGENCj4+IGxvY2ssIHNoZSBw cmVzc2VzIGEgYnV0dG9uIGluIHRoZSBhcHAsIHRoZXJlYnkgYXV0aG9yaXplcyB0aGUgcmVxdWVz dC4NCj4+IFRoZXJlIGlzIG5vIG5lZWQgdG8gc29sdmUgdGhpcyB3aXRoIGFjY2VzcyBjb250cm9s IHBvbGljaWVzLCB0cmFuc3BvcnQNCj4+IGF1dGhvcml6YXRpb24gaW5mb3JtYXRpb24sIGVuZm9y Y2VtZW50IGV0Yy4gIFRoZXJlIGlzIGEgbmF0dXJhbA0KPj5hc3ltbWV0cnkNCj4+IHdoaWNoIGlz IGNsZWFybHkgaWxsdXN0cmF0ZWQgaW4gdGhlIHVzZSBjYXNlcy4gV2Ugc2hvdWxkIG5vdCBoaWRl IHRoYXQNCj4+IGJlaGluZCBzdHJhbmdlIHRlcm1pbm9sb2d5IGFuZCBmb3JtdWxhdGlvbnMuDQo+ DQo+WWVzLCBleGFjdGx5LCBFdmUgaXMgYXV0aG9yaXppbmcgdGhlIHJlcXVlc3QuIEFuZCBpbiB0 aGlzIHNwZWNpZmljDQo+c2NlbmFyaW8gaW1wbGljaXQgYXV0aG9yaXphdGlvbiAoYW4gYXV0aGVu dGljYXRlZCBkZXZpY2UgaXMgYXV0aG9yaXplZCkNCj5taWdodCBiZSBnb29kIGVub3VnaC4gU2lu Y2UgRXZlIGNhbiBkZWNpZGUgd2hhdCBoZXIgc21hcnRwaG9uZSBpcw0KPnN1cHBvc2VkIHRvIGRv LCB0aGVyZSBpcyBubyBuZWVkIGZvciBtb3JlIHNvcGhpc3RpY2F0ZWQgYXV0aG9yaXphdGlvbg0K PnBvbGljaWVzLiBUaGlzIGlzIGRpZmZlcmVudCBmb3Igb3RoZXIgdXNlIGNhc2VzLg0KPg0KPklm IHlvdSB0aGluayBhYm91dCBpdCwgdGhlcmUgaXMgYWxzbyBubyBuZWVkIGZvciBzb3BoaXN0aWNh dGVkDQo+YXV0aG9yaXphdGlvbiBvbiB0aGUgZG9vciBsb2NrIHNpZGUsIGVpdGhlci4gSXQgbWln aHQgYmUgc3VmZmljaWVudCBpZiBhDQo+ZGV2aWNlIHRoYXQgY2FuIGJlIGF1dGhlbnRpY2F0ZWQg aXMgYXV0aG9yaXplZCB0byBvcGVuIHRoZSBkb29yLiBJbiB0aGlzDQo+Y2FzZSwgaW1wbGljaXQg YXV0aG9yaXphdGlvbiBpcyBzdWZmaWNpZW50IG9uIGJvdGggc2lkZXMuIEFnYWluIHRoaXMgaXMN Cj5kaWZmZXJlbnQgZm9yIG90aGVyIHVzZSBjYXNlcy4NCj4NCj5CZXN0IHJlZ2FyZHMsDQo+U3Rl ZmZpDQoNCg== From nobody Wed Mar 4 20:56: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 8D7C11A9025 for ; Wed, 4 Mar 2015 20:56:42 -0800 (PST) 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 htblJ80CzusY for ; Wed, 4 Mar 2015 20:56:39 -0800 (PST) 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 157EE1A026E for ; Wed, 4 Mar 2015 20:56:37 -0800 (PST) X-AuditID: c1b4fb2d-f79aa6d00000359d-b7-54f7e20342e1 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id DE.65.13725.302E7F45; Thu, 5 Mar 2015 05:56:36 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.70]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0210.002; Thu, 5 Mar 2015 05:56:35 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Stefanie Gerdes , Hannes Tschofenig , "Ace@ietf.org" Thread-Topic: [Ace] U1.2 in Use Case Document Thread-Index: AQHQVbL1RkiN6OYzzEyLTf3fE9ZKCp0K/GYAgAAliYCAAe0ZgIAANliA Date: Thu, 5 Mar 2015 04:56:35 +0000 Message-ID: <2E772E75-4113-4851-99D8-CF2C47E7AE64@ericsson.com> References: <54F5B1F2.6050205@gmx.net> <54F616CF.20607@tzi.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; boundary="Apple-Mail-5D0591B9-EE78-4F02-A34D-5923E060F039"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZGfG3Rpfl0fcQgzUT2C2+f+thtth48S6j xdKd91gdmD0Wb9rP5rFkyU8mj21vvzIHMEdx2aSk5mSWpRbp2yVwZazbdZSpYMJVxor9m+6y NzDuOs/YxcjJISFgIvF78glmCFtM4sK99WxdjFwcQgJHGCVWnfrBAuEsYpS4eekBO0gVm4CL xIOGR0wgtohAscTUKU/AJgkL6Ehs/bsDyOYAiutKXF/vBVHiJnFp+0ywchYBFYn7dzrZQGxe AXuJi8dWMkHMn8Mose3VQ7AiTgFLib/nb7CA2IxAF30/tQYsziwgLnHryXwmiEtFJB5ePM0G YYtKvHz8jxVkELPAZKBBE+ayQmwQlDg58wnLBEbhWUj6ZyGrm4WkDqJIU2J/93IoW1FiSvdD dgjbWmLGr4NsELapxOujHxmR1Sxg5FjFKFqcWlycm25krJdalJlcXJyfp5eXWrKJERh1B7f8 1t3BuPq14yFGAQ5GJR7eDce+hwixJpYVV+YeYpTmYFES57UzPhQiJJCeWJKanZpakFoUX1Sa k1p8iJGJg1OqgTGpKE5whaec+AQmi8sXN/7qf619vzHox8RH2w6Fi+a5y/C9MbHnvuMRPrlr yYfS1IdHX1bpTdloubjrYmVRyOxA0drzk587Xt0yMdTuTVBsnr7HaZnpVXMabQx/Pv389dJc pnftRmH+5u+yTLK5vm+VSZmWpWz+aANv9WLTbT+NL7zk613tIavEUpyRaKjFXFScCADlFvzH mwIAAA== Archived-At: Subject: Re: [Ace] U1.2 in Use Case Document 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, 05 Mar 2015 04:56:42 -0000 --Apple-Mail-5D0591B9-EE78-4F02-A34D-5923E060F039 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpQbGVhc2UgZGlzcmVnYXJkICJJdCBpcyBwdXJlIHNwZWN1bGF0aW9ucy4iIGZy b20gbXkgcHJldmlvdXMgcG9zdCwgIGFuIHVubmVzc2VjYXJ5IHJlbWFyayBkdWUgdG8gbG9uZyB3 b3Jrc2hpZnQuIA0KDQpHw7ZyYW4NCg0KDQoNCj4gT24gNSBtYXIgMjAxNSwgYXQgMDE6NDIsIEfD tnJhbiBTZWxhbmRlciA8Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4gDQo+ IEhpIFN0ZWZmaSBhbmQgYWxsLA0KPiANCj4gDQo+IFRyeWluZyB0byBjYXRjaCB1cCB3aXRoIHRo ZSBtYWlscy4gSSBqdXN0IHN1bW1hcml6ZSBzb21lIGNvbW1lbnRzIG9uIHRoaXMNCj4gbWFpbCBm b3Igbm93Lg0KPiANCj4gVGVybWlub2xvZ3kgYW5kIHByb2JsZW0gc3RhdGVtZW50DQo+IC0gLSAt DQo+IEN1cnJlbnQgdGVybWlub2xvZ3ksIG9yIGhvdyBpdCBpcyBhcHBsaWVkLCBpcyB1bnNhdGlz ZmFjdG9yeSwgYXMgSeKAmXZlDQo+IHJlLWl0ZXJhdGVkIGEgY291cGxlIG9mIHRpbWVzLiBJ4oCZ dmUgcHJldmlvdXNseSBiZWVuIHdvcmtpbmcgaW4gbGFyZ2UNCj4gcHJvamVjdHMgd2hlcmUgdGVy bWlub2xvZ3kgYW5kIHByb2JsZW0gc3RhdGVtZW50IHdhcyB1bmNsZWFyIGFuZCBpdCBpcyBhbg0K PiBhYnNvbHV0ZSB3YXN0ZSBvZiB0aW1lLiBJIHRoaW5rIG90aGVycyBpbiB0aGlzIGdyb3VwIGhh dmluZyBzaW1pbGFyDQo+IGV4cGVyaWVuY2VzIGNhbiBjb25maXJtIHRoaXMuDQo+IA0KPiANCj4g V2UgaGF2ZSBkaWZmZXJlbnQgb3B0aW9ucyB0byByZXNvbHZlIHRoaXMuDQo+IA0KPiAxLiBXZSBj YW4gcmVtb3ZlIHJvbGUgdGVybWlub2xvZ3kgZnJvbSB0aGUgdXNlIGNhc2UgZHJhZnQgYW5kIGV4 cHJlc3MgdGhlDQo+IHByb2JsZW1zIGluIHRlcm1zIG9mIHRoZSBhY3RvcnMgaW4gdGhlIHVzZSBj YXNlcy4gRS5nLiAiZnJ1aXQgdmVuZG9ycyB3YW50DQo+IHRvIGdyYW50IGRpZmZlcmVudCBhY2Nl c3MgcmlnaHRzIHRvIGRpZmZlcmVudCBwYXJ0aWVzIHRvIG1lYXN1cmVtZW50cyBvZg0KPiBnb29k c+KAmSB0ZW1wZXJhdHVyZXMiLiBUaGF0IHdvdWxkIHNhdmUgdGhlIHVzZSBjYXNlIGRvY3VtZW50 LCBidXQgaW4gdGhpcw0KPiBjYXNlIHdlIGRvbuKAmXQgaGF2ZSBhIGdlbmVyYWwgcHJvYmxlbSBz dGF0ZW1lbnQgaW4gdGVybXMgb2Ygcm9sZXMsIGFuZCB0aGF0DQo+IHRoZW4gYmVjb21lcyB0aGVu IG91ciBuZXh0IGNoYWxsZW5nZS4NCj4gDQo+IDIuIElmIHdlIGluc3RlYWQgZGVmaW5lIHJvbGVz IChSZXNvdXJjZSBTZXJ2ZXIsIENsaWVudCBldGMuKSB0aGVuIHdlIG11c3QNCj4gYmUgYWJsZSB0 byBleHByZXNzIHRoZSByZWxldmFudCBwcm9ibGVtcyBiYXNlZCBvbiB0aGUgdXNlIGNhc2VzIGlu IHRlcm1zDQo+IG9mIHRoZSByb2xlcyBkZWZpbmVkLiBPdGhlcndpc2UgdGhlIHJvbGUgZGVmaW5p dGlvbnMgYXJlIG5vdCBnb29kIGVub3VnaC4NCj4gRm9yIGV4YW1wbGUgIlJlc291cmNlIE93bmVy cywgc3VjaCBhcyBmcnVpdCB2ZW5kb3JzLCB3YW50cyB0byBncmFudA0KPiBkaWZmZXJlbnQgYWNj ZXNzIHJpZ2h0cyB0byBkaWZmZXJlbnQgcGFydGllcyBmb3IgdGhlaXIgcmVzb3VyY2VzLCBzdWNo IGFzDQo+IHRlbXBlcmF0dXJlcyINCj4gDQo+IElmIHdlIGNhbuKAmXQgZXhwcmVzcyB3aGF0IGFy ZSB0aGUgYXNzZXRzIGFuZCB0aGUgc3Rha2Vob2xkZXJzIGluIGEgd2VsbA0KPiBkZWZpbmVkIHdh eSwgc28gdGhhdCB3ZSBjYW4gZm9ybXVsYXRlIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBpbiB0ZXJt cyBvZg0KPiB0aGVzZSwgdGhlbiB3ZSBoYXZlIGEgc2VyaW91cyBwcm9ibGVtLiBJIGFkdm9jYXRl IHRoYXQgd2UgYWRvcHQgYW4NCj4gZXN0YWJsaXNoZWQgdGVybWlub2xvZ3kgc3VjaCBhcyBPQXV0 aCBvciBVTUEuIFdoYXRldmVyIGNsaWVudCBhc3BlY3RzIHdlDQo+IHdhbnQgdG8gZm9ybXVsYXRl IGNhbiBzdXJlbHkgYmUgZXhwcmVzc2VkIGluIGFueSBvZiB0aGVzZSB0ZXJtaW5vbG9neS4NCj4g DQo+IFNvbWUgY29udHJvbCBxdWVzdGlvbnMgb24gaG93IGZhciB3ZSBoYXZlIHJlYWNoZWQgaW4g dGhpcyB3b3JrOg0KPiANCj4gLSBJbiB0aGUgY29udGFpbmVyIHVzZSBjYXNlLCBjYW4gd2UgYWdy ZWUgdGhhdCB0aGUgdGVtcGVyYXR1cmUgc2Vuc29ycyBhbmQNCj4gZmFuIGFjdHVhdG9ycyBhcmUg dGhlIG1haW4g4oCcaXRlbXMgb2YgaW50ZXJlc3TigJ0uDQo+IA0KPiAtIENhbiB3ZSBkZW5vdGUg dGhlIHRlbXBlcmF0dXJlIHNlbnNvciBhbmQgZmFuIGFjdHVhdG9ycyDigJxSZXNvdXJjZXPigJ0/ DQo+IA0KPiAtIENhbiB3ZSwgYXMgRXZlIHByb3Bvc2VkLCBhZ3JlZSB0byB2aWV3IHRoZSB0ZW1w ZXJhdHVyZSBzZW5zb3IgLSBmYW4NCj4gYWN0dWF0b3IgaW50ZXJhY3Rpb24gYXMgdHdvIG9uZS13 YXkgcmVsYXRpb25zaGlwcywgaS5lLiB0aGVyZSBhcmUNCj4gdGVtcGVyYXR1cmUtcmVzb3VyY2Vz IGFuZCB0ZW1wZXJhdHVyZS1jbGllbnRzLCBhcyB3ZWxsIGFzIGZhbi1yZXNvdXJjZXMNCj4gYW5k IGZhbi1jbGllbnRzIChzb21lIG9mIHdoaWNoIG1heSBiZSBjby1sb2NhdGVkKS4NCj4gDQo+IChN YXliZSB3ZSBjYW4gdGhlbiBhdm9pZCBmb3JtdWxhdGlvbnMgc3VjaCBhcyAiSWYgdGhlIHRlbXBl cmF0dXJlIHNlbnNvcg0KPiBpcyBub3QgYWJsZSB0byBkZWNpZGUgaWYgYSByZXNvdXJjZSBpcyBh dXRob3JpemVk4oCdPyBTZWUgZnVydGhlciBkb3duIGluDQo+IHRoaXMgbWFpbC4pDQo+IA0KPiAN Cj4gDQo+IENvbnN0cmFpbmVkIGNsaWVudHMNCj4gLSAtIC0NCj4gT25lIHJlY3VycmluZyB0aGVt ZSBpbiB0aGlzIGRpc2N1c3Npb24gaGFzIGJlZW4gb24gY29uc3RyYWluZWQgY2xpZW50DQo+IGRl dmljZXMuICBUaGVyZSBpcyBhIHF1ZXN0aW9uIGFib3V0IHdoYXQga2luZCBvZiAiYXV0aG9yaXph dGlvbiBwcm9ibGVtc+KAnQ0KPiB0aGF0IGFyZSByZWxldmFudCB0byB0aGUgY2xpZW50IGRldmlj ZS4gSXQgaXMgbWFpbmx5IHJlbGF0ZWQgdG8gYXNwZWN0cyBvZg0KPiBhIGNsaWVudCBkaXNjbG9z aW5nIGEgcmVxdWVzdC4gVGhlcmUgaGFzIGJlZW4gcmVwZWF0ZWQgY2xhaW1zIGFib3V0IHRoZQ0K PiBuZWVkIGZvciBzb3BoaXN0aWNhdGVkIGFjY2VzcyBjb250cm9sIHBvbGljaWVzIG9uIHRoZSBj bGllbnQgc2lkZSwgaW4gdGhlDQo+IHNlbnNlIHRoYXQgdGhlIGNsaWVudCBhY3Rpb25zLCBzdWNo IGFzIG1ha2luZyBhIHJlcXVlc3QsIG5lZWQgdG8gYmUNCj4gc3ViamVjdCB0byBhY2Nlc3MgY29u dHJvbCBwb2xpY2llcywganVzdCBiZWNhdXNlIHRoZSBkZXZpY2VzIGFyZQ0KPiBjb25zdHJhaW5l ZC4gQnV0IG5vd2hlcmUgaW4gdGhlIHVzZSBjYXNlIGRvY3VtZW50IGlzIHRoaXMgY2xhaW0NCj4g c3Vic3RhbnRpYXRlZCwgaS5lLiB0aGF0IGEgcGFydGljdWxhciB1c2UgY2FzZSBpcyByZXF1aXJp bmcgc3VjaCBhDQo+IGZlYXR1cmUuIFRoZXJlIGFyZSBvbmx5IGFic3RyYWN0IGZvcm11bGF0aW9u cyBhYm91dCBwcmluY2lwYWxzLCBhbmQNCj4gaW50ZXJwcmV0ZWQgYXMgcmVzb3VyY2Ugb3duZXIg YXMgd2VsbCBhcyBjbGllbnQgb3duZXJzLiBUaGUgbW90aXZhdGlvbiBmb3INCj4gdGhhdCBoYXMg YmVlbiB0aGF0IGlmIHdlIGRlc2NyaWJlIHRoZSB1c2UgY2FzZSBpbiB0b28gbXVjaCBkZXRhaWwg aXQNCj4gYmVjb21lcyBzb2x1dGlvbiBzcGVjaWZpYy4gQW4gYWx0ZXJuYXRpdmUgZXhwbGFuYXRp b24gaXMgdGhhdCBvbmx5IGZldywgaWYNCj4gYW55LCBvZiB0aGUgdXNlIGNhc2VzIGFjdHVhbGx5 IHJlcXVpcmUgY2xpZW50IHNpZGUgYWNjZXNzIGNvbnRyb2wgcG9saWNpZXMuDQo+IA0KPiBJIHRo aW5rIHdlIHNob3VsZCBkZXRhY2ggYW55IHBvdGVudGlhbCBhY2Nlc3MgY29udHJvbCBwb2xpY3kg cHJvYmxlbXMgb2YNCj4gdGhlIGNsaWVudCBmcm9tIHRoYXQgcmVsYXRlZCB0byByZXNvdXJjZSBh Y2Nlc3MsIGJlY2F1c2UgaXQgaXMgZGlmZmVyZW50LA0KPiBpdCBpcyBub3QgZG9jdW1lbnRlZCB0 byBiZSByZWxldmFudCwgYW5kIGl0IGlzIGFuIGluZGVwZW5kZW50IHByb2JsZW0gdGhhdA0KPiBt YWtlcyB0aGUgcHJvYmxlbSBmb3JtdWxhdGlvbiBjb21wbGV4LiBGdXJ0aGVybW9yZSwgbm8gb25l IGFjdHVhbGx5IGtub3dzDQo+IGFib3V0IHRoZSBuZWVkIGFuZCBuYXR1cmUgb2YgcG9saWNpZXMg Zm9yIGluIHRoZXNlIHNpdHVhdGlvbnMuIEl0IGlzIHB1cmUNCj4gc3BlY3VsYXRpb25zLiBJIHRo aW5rIHRoYXQgaWYgYW55dGhpbmcsIHNvbWUgc29ydCBvZiAiZGVjaXNpb24gcG9saWNpZXPigJ0N Cj4gY291bGQgcG90ZW50aWFsbHkgYmUgdXNlZnVsLiBGb3JtdWxhdGluZyBpdCBhcyBhY2Nlc3Mg Y29udHJvbCBwcm9ibGVtDQo+IGxlYWRzIHRvIHZlcnkgc3RyYW5nZSBzdGF0ZW1lbnRzIGFzIEkg c2hvd2VkIGF0IHRoZSBlbmQgb2YgdGhpcyBtYWlsOg0KPiBodHRwOi8vd3d3LmlldGYub3JnL21h aWwtYXJjaGl2ZS93ZWIvYWNlL2N1cnJlbnQvbXNnMDEwMTkuaHRtbA0KPiANCj4gDQo+IE1vcmUg bGF0ZXIuDQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IEfDtnJhbg0KPiANCj4gDQo+IA0KPj4gT24g MjAxNS0wMy0wMyAyMToxNywgIlN0ZWZhbmllIEdlcmRlcyIgPGdlcmRlc0B0emkuZGU+IHdyb3Rl Og0KPj4gDQo+PiBIaSBhbGwsDQo+PiANCj4+PiBPbiAwMy8wMy8yMDE1IDA2OjAzIFBNLCBHw7Zy YW4gU2VsYW5kZXIgd3JvdGU6DQo+Pj4gSGkgSGFubmVzLA0KPj4+IA0KPj4+IE9uIDIwMTUtMDMt MDMgMTQ6MDYsICJIYW5uZXMgVHNjaG9mZW5pZyIgPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+ DQo+Pj4gd3JvdGU6DQo+Pj4gDQo+Pj4+IEhpIGFsbCwNCj4+Pj4gDQo+Pj4+IGxldCBtZSB0cnkg dG8gc2VlIHdoZXRoZXIgSSB1bmRlcnN0YW5kIHRoZSBpc3N1ZSB0aGF0J3MgY3VycmVudGx5IHVu ZGVyDQo+Pj4+IGRpc2N1c3Npb24uDQo+Pj4+IA0KPj4+PiBJdCBzZWVtcyB0aGF0IHRoZSBkZWJh dGUgZm9jdXNlcyBvbiB0aGlzIHJlcXVpcmVtZW50IGZyb20gdGhlDQo+Pj4+ICdDb250YWluZXIN Cj4+Pj4gbW9uaXRvcmluZycgdXNlIGNhc2U6DQo+Pj4+IA0KPj4+PiAiDQo+Pj4+ICAgbyAgVTEu MiBQcmluY2lwYWxzIHdhbnQgdG8gZ3JhbnQgZGlmZmVyZW50IGFjY2VzcyByaWdodHMgZm9yDQo+ Pj4+ICAgICAgZGlmZmVyZW50IHJlc291cmNlcyBvbiBhbiBlbmRwb2ludC4NCj4+Pj4gIg0KPj4+ IA0KPj4+IEFjdHVhbGx5LCB3ZSBhcmUgbm90IGRlYmF0aW5nIHRoaXMgVTEuMiByZXF1aXJlbWVu dC4gU3RlZmZpIG1hZGUgYSBuZXcNCj4+PiBzZXQNCj4+PiBvZiByZXF1aXJlbWVudHMsIHNlZQ0K Pj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9hY2UvY3VycmVudC9tc2cw MDk4Mi5odG1sDQo+Pj4gDQo+Pj4gVGhlIGRlYmF0ZSBmb2N1c2VkIG9uIHRoaXMgcmVxdWlyZW1l bnQgcHJvcG9zZWQgYnkgU3RlZmZpOg0KPj4+IA0KPj4+ICJVMS4xYSBQcmluY2lwYWxzIHN1Y2gg YXMgdGhlIGZydWl0IHZlbmRvciwgdGhlIHRyYW5zbG9hZGluZyBwZXJzb25uZWwNCj4+PiBvcg0K Pj4+IHRoZSBjb250YWluZXIgb3duZXJzIHdhbnQgdG8gZGVmaW5lIGF1dGhvcml6YXRpb25zIGZv ciB0aGVpciByZXNvdXJjZXMNCj4+PiBhbmQgZW5kcG9pbnRzLiINCj4+PiANCj4+PiAoSSBpbnNl cnQg4oCcYeKAnSwg4oCcYuKAnSwg4oCcY+KAnSBldGMuIHRvIGRpc3Rpbmd1aXNoIHRoZSBkaWZm ZXJlbnQgdmVyc2lvbnMgb2YNCj4+PiByZXF1aXJlbWVudHMpDQo+Pj4gDQo+Pj4gDQo+Pj4gVGhl biBTdGVmZmkgcHJvcG9zZWQgdG8gc3BsaXQgVTEuMWEgaW4gdGhlc2UgcmVxdWlyZW1lbnRzOg0K Pj4+IA0KPj4+IChodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvYWNlL2N1cnJl bnQvbXNnMDA5OTIuaHRtbCkNCj4+PiANCj4+PiANCj4+PiDigJxVMS4xYjogUmVzb3VyY2UgT3du ZXJzIHdhbnQgdG8gZ3JhbnQgZGlmZmVyZW50IGFjY2VzcyByaWdodHMgZm9yIHRoZWlyDQo+Pj4g cmVzb3VyY2VzIHRvIGRpZmZlcmVudCBwYXJ0aWVzLg0KPj4+IA0KPj4+IFUxLjJiOiBDbGllbnQg T3duZXJzIHdhbnQgdG8gZGVmaW5lIGZvciB0aGVpciBjbGllbnRzIGlmIGFuZCBob3cgdGhleQ0K Pj4+IGFyZQ0KPj4+IGFsbG93ZWQgdG8gYWNjZXNzIHJlc291cmNlcyBob3N0ZWQgb24gYSBSZXNv dXJjZSBTZXJ2ZXIuIg0KPj4gDQo+PiBJbiBmYWN0IEkgZGlkbid0IHdhbnQgdG8gc3BsaXQgVTEu MWEuIFlvdSwgR8O2cmFuLCBwcm9wb3NlZCBpbg0KPj4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL2FjZS9jdXJyZW50L21zZzAwOTkxLmh0bWwgdG8NCj4+IHJlcGxhY2UgVTEu MSB3aXRoIHR3byAicmVxdWlyZW1lbnRzIiBhcyB5b3UgY2FsbGVkIHRoZW0uIEkgYW0gbm90IGhh cHB5DQo+PiB3aXRoIHRoaXMgcHJvcG9zYWwgYnV0IHdvdWxkIGhhdmUgYWdyZWVkIHRvIGl0IGlm IGl0IGhlbHBlZCB0aGluZ3MuDQo+PiANCj4+IFRoZSBtZWFuaW5nIG9mIHRoZSBvcmlnaW5hbCBV MS4xIHByb2JsZW0gaXMgdGhhdCBwcmluY2lwYWxzIGluIHRoaXMgdXNlDQo+PiBjYXNlIHdhbnQg dG8gZ3JhbnQgZGlmZmVyZW50IGF1dGhvcml6YXRpb25zIHRvIGRpZmZlcmVudCBwZW9wbGUgLw0K Pj4gZGV2aWNlcyAvIHJlc291cmNlcyAobWVhbmluZyB0aGF0IGRldmljZXMgb2YgY29tcGFueSBB IGdldCBkaWZmZXJlbnQNCj4+IGFjY2VzcyByaWdodHMgdGhlbiBkZXZpY2VzIG9mIGNvbXBhbnkg QikuIEl0IHNlZW1zIHRoYXQgaXQgaXMgcXVpdGUNCj4+IGRpZmZpY3VsdCB0byBmaW5kIGEgbmV1 dHJhbCBwaHJhc2luZyBmb3IgdGhpcyBwcm9ibGVtLg0KPj4gDQo+PiBUaGUgc3BsaXQgbm93IHNo b3dzIGEgY29tcGxldGVseSBkaWZmZXJlbnQgYXNwZWN0IG9mIHRoaXMgcHJvYmxlbTogd2UNCj4+ IGNhbiBwcm90ZWN0IHRoZSBjbGllbnQgc2lkZSBvciB3ZSBjYW4gcHJvdGVjdCB0aGUgc2VydmVy IHNpZGUgb3IgYm90aC4NCj4+IFRoZXNlIHJlYWxseSBhcmUgc29sdXRpb24gc3BlY2lmaWMgYW5k IGFzIHdlIGNhbiBzZWUsIHRoaXMgbGVhZHMgdG8NCj4+IHBlb3BsZSB3YW50aW5nIHRvIGRlZmVu ZCB0aGVpciBmYXZvcml0ZSBzb2x1dGlvbi4gSW5zdGVhZCBvZjogInVzZXJzDQo+PiBzb21laG93 IHdhbnQgdG8gZ3JhbnQgZGlmZmVyZW50IGF1dGhvcml6YXRpb25zIHRvIGRpZmZlcmVudCBwZW9w bGUiIHdlDQo+PiBhcmUgZGVlcCBpbnRvIGEgc29sdXRpb24gc3BhY2UgZGlzY3Vzc2lvbiBhYm91 dCB3aGV0aGVyIGl0IGlzIG1vcmUNCj4+IHVzZWZ1bCB0byBwcm90ZWN0IHRoZSBzZXJ2ZXIgb3Ig dGhlIGNsaWVudCBzaWRlLCBpZiB0aGUgY2xpZW50IHNpZGUgZXZlbg0KPj4gbmVlZHMgcHJvdGVj dGlvbiBhbmQgc28gb24uIEkgd291bGQgbGlrZSB0byBlbXBoYXNpemUgdGhhdCB0aGlzIGlzIG5v dA0KPj4gd2hhdCBVMS4xIGlzIGFib3V0LiBNYXliZSB3ZSBjYW4gc3RpbGwgZmluZCBhIGJldHRl ciBwaHJhc2luZyB0aGF0IGRvZXMNCj4+IG5vdCBpbmRpY2F0ZSBhIHNwZWNpZmljIHNvbHV0aW9u Lg0KPj4gDQo+PiBUaGUgZGlmZmVyZW50IHByb3Bvc2FscyBmb3IgdGhlIHBocmFzaW5nIG9mIFUx LjEgaW5kaWNhdGUgYSBkaWZmZXJlbnQNCj4+IHByb2JsZW06IERvIHdlIHdhbnQgdG8gZGV2ZWxv cCBhIHNvbHV0aW9uIHRoYXQgZXhjbHVzaXZlbHkgcHJvdGVjdHMNCj4+IHJlc291cmNlcyBvciBk byB3ZSBhbHNvIHdhbnQgdG8gY29uc2lkZXIgdGhlIGNsaWVudCBzaWRlPyBNb3N0IG9mIHVzIGFy ZQ0KPj4gbW9yZSBmYW1pbGlhciB3aXRoIHRoZSBwcm90ZWN0aW9uIG9mIHJlc291cmNlcyBiZWNh dXNlIHdlIGFscmVhZHkga25vdw0KPj4gdGhhdCBmcm9tIHdlYiBzY2VuYXJpb3MuIEJ1dCBpbiB0 aGVzZSBzY2VuYXJpb3Mgd2UgYWx3YXlzIGhhdmUgYSB1c2VyDQo+PiB0aGF0IHBlcmZvcm1zIGF1 dGhvcml6YXRpb24gb24gdGhlIGNsaWVudCBzaWRlLiBGb3IgY29uc3RyYWluZWQNCj4+IGVudmly b25tZW50cywgaXQgaXMgbm90IGFsd2F5cyB0aGF0IHNpbXBsZS4gV2UgbWlnaHQgaGF2ZSB0cnVl IG1hY2hpbmUNCj4+IHRvIG1hY2hpbmUgKE0yTSkgY29tbXVuaWNhdGlvbiB3aGVyZSBhIGRldmlj ZSBtdXN0IGRlY2lkZSBmb3IgaXRzZWxmDQo+PiB3aGV0aGVyIHNvbWV0aGluZyBpcyBhdXRob3Jp emVkIGJ5IGl0cyB1c2VyIG9yIG5vdC4gTW9yZW92ZXIsIGRldmljZXMNCj4+IG1pZ2h0IG5vdCBo YXZlIGRpc3BsYXlzIGFuZCB0aHVzIGl0IG1pZ2h0IG5vdCBiZSBwb3NzaWJsZSBmb3IgdGhlIHVz ZXINCj4+IHRvIGRpcmVjdGx5IGludGVyYWN0IHdpdGggdGhlIGRldmljZSBmb3IgYXV0aG9yaXph dGlvbi4gU29sdmluZyB0aGVzZQ0KPj4gcHJvYmxlbXMgaXMgbm90IG9wdGlvbmFsLiBBbmQgSSB0 aGluayBpdCBpcyBpbXBvcnRhbnQgdG8gYmUgYXdhcmUgb2YNCj4+IHRoZXNlIHByb2JsZW1zLiBB IHNvbHV0aW9uIGNhbiBkZWNpZGUgaWYgYW5kIGhvdyB0byBzb2x2ZSB0aGVtLg0KPj4gDQo+Pj4g DQo+Pj4gDQo+Pj4gUmVmZXJyaW5nIHRvIHRoZSBVMS4xYSwgSSBwcm9wb3NlZCB0byBjbGFyaWZ5 IHdoYXQgVTEuMWIgbWVhbnMgaW4gdGVybXMNCj4+PiBvZg0KPj4+IHRoZSBhY3RvcnMgYW5kIHJl c291cmNlcyBvZiB0aGUgdXNlIGNhc2U6DQo+Pj4gKGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h cmNoaXZlL3dlYi9hY2UvY3VycmVudC9tc2cwMTAwMC5odG1sKQ0KPj4+IA0KPj4+IOKAnFUxLjFj OiBSZXNvdXJjZSBPd25lcnMsIHN1Y2ggYXMgZnJ1aXQgdmVuZG9ycyBhbmQgY29udGFpbmVyIG93 bmVycywNCj4+PiB3YW50DQo+Pj4gdG8NCj4+PiBncmFudCBkaWZmZXJlbnQgYWNjZXNzIHJpZ2h0 cyB0byBkaWZmZXJlbnQgcGFydGllcyBmb3IgdGhlaXIgcmVzcGVjdGl2ZQ0KPj4+IHJlc291cmNl cywgc3VjaCBhcyB0ZW1wZXJhdHVyZXMgYW5kIGZhbiBzZXR0aW5ncy4iDQo+Pj4gDQo+Pj4gDQo+ Pj4gVGhpcyB3YXMgbm90IGFncmVlZCwgc2VlIGRpc2N1c3Npb24gYWJvdXQgcmVzb3VyY2UgYW5k IGNsaWVudCBiZWxvdy4NCj4+PiANCj4+PiBXaXRoIHJlZ2FyZHMgdG8gVTEuMmIsIEkgcmVxdWVz dGVkIHRoYXQgdGhpcyBhYnN0cmFjdCBzdGF0ZW1lbnQgc2hvdWxkDQo+Pj4gYmUNCj4+PiBleGVt cGxpZmllZCB3aXRoIGFjdG9ycyBhbmQgY2xpZW50IGRldmljZXMgZnJvbSB0aGlzIHVzZSBjYXNl IHRvIGFsbG93DQo+Pj4gZXZlcnlvbmUgdG8gZm9ybSBhbiBvcGluaW9uIGlmIHRoaXMgaXMgYSBy ZWxldmFudCBhY2Nlc3MgY29udHJvbCBwcm9ibGVtDQo+Pj4gaW4gdGhlIHNjb3BlIG9mIEFDRSBv ciBub3QuIElmIHRoYXQgY2Fu4oCZdCBiZSBtYWRlLCB0aGVuIEkgdGhpbmsgdGhpcw0KPj4+IHJl cXVpcmVtZW50IGlzIGxlc3MgcmVsZXZhbnQgZm9yIHRoaXMgdXNlIGNhc2UgYW5kIGNvbnNpZGVy IGxlYXZlIGl0DQo+Pj4gb3V0Lg0KPj4gDQo+PiBJbWFnaW5lIGEgc3BlY2lmaWMgaW1wbGVtZW50 YXRpb24gb2YgdGhlIGNvbnRhaW5lciBzY2VuYXJpbyB3aGVyZSB0aGUNCj4+IHRlbXBlcmF0dXJl IHNlbnNvciBpcyB0aGUgY2xpZW50IGFuZCB0aGUgZmFuIGFjdHVhdG9yIGlzIHRoZSBzZXJ2ZXIu IFRoZQ0KPj4gZnJ1aXQgdmVuZG9yIHdhbnRzIHRvIG1ha2Ugc3VyZSB0aGF0IHRoZSB0ZW1wZXJh dHVyZSBzZW5zb3Igc2VuZHMgdGhlDQo+PiB0ZW1wZXJhdHVyZSB2YWx1ZXMgb25seSB0byBhdXRo b3JpemVkIGZhbiBhY3R1YXRvciByZXNvdXJjZXMgYmVjYXVzZSBzaGUNCj4+IGRvZXNuJ3Qgd2Fu dCB1bmF1dGhvcml6ZWQgcGVvcGxlIHRvIGdhaW4ga25vd2xlZGdlIGFib3V0IHRoZSBzdGF0ZSBv Zg0KPj4gdGhlIGdvb2RzLiBUaGUgY29udGFpbmVyIG93bmVyIHdhbnRzIHRvIG1ha2Ugc3VyZSB0 aGF0IHRoZSBzZXJ2ZXIgb25seQ0KPj4gYWNjZXB0cyBkYXRhIGZyb20gYXV0aG9yaXplZCBjbGll bnRzLiBJbiB0aGlzIGNhc2UsIGJvdGggdGhlIGNsaWVudA0KPj4gb3duZXIgYW5kIHRoZSByZXNv dXJjZSBvd25lciB3aWxsIG5lZWQgdG8gZGVmaW5lIGFjY2VzcyBwb2xpY2llcy4gVGhlDQo+PiBj bGllbnQgb3duZXIgKHRoZSBmcnVpdCB2ZW5kb3IpIGRlZmluZXMgYSBydWxlIHRoYXQgc3RhdGVz IHRoYXQgdGhlDQo+PiBjbGllbnQgKHRoZSB0ZW1wZXJhdHVyZSBzZW5zb3IpIGlzIGFsbG93ZWQg dG8gZG8gYSBQVVQgb24gcmVzb3VyY2VzIHRoYXQNCj4+IGJlbG9uZyB0byBhIHNwZWNpZmljIGNv bnRhaW5lciBvd25lci4gVGhlIHJlc291cmNlIG93bmVyICh0aGUgY29udGFpbmVyDQo+PiBvd25l cikgZGVmaW5lcyBhIHJ1bGUgdGhhdCBzdGF0ZXMgdGhhdCBjbGllbnRzIG9mIGEgY2VydGFpbiBm cnVpdCB2ZW5kb3INCj4+IGFyZSBhbGxvd2VkIHRvIGRvIGEgUFVUIG9uIHRoZWlyIHJlc291cmNl cy4gSWYgdGhlIHRlbXBlcmF0dXJlIHNlbnNvciBpcw0KPj4gbm90IGFibGUgdG8gZGVjaWRlIGlm IGEgcmVzb3VyY2UgaXMgYXV0aG9yaXplZCwgaXQgY2Fubm90IGVuZm9yY2UgdGhlDQo+PiBhdXRo b3JpemF0aW9uIGRlY2lzaW9ucyBvZiBpdHMgb3duZXIuDQo+PiANCj4+PiANCj4+PiBOT1RFOiBJ 4oCZbSBub3Qgc2F5aW5nIFUxLjJiIGlzIG5vdCBhIHBvc3NpYmxlIHNlY3VyaXR5IGNvbmNlcm4u IEnigJltDQo+Pj4gcXVlc3Rpb25pbmcgdGhhdCBpdCBpcyBhbiBhY2Nlc3MgY29udHJvbCBwcm9i bGVtIGFuYWxvZ291cyB0byBVMS4xYi4gVGhlDQo+Pj4gb3JpZ2luYWwgcmVxdWlyZW1lbnQgZm9y bXVsYXRpb24gVTEuMSAoaW4gdGhlIGRyYWZ0KSBhbmQgVTEuMWEgYmx1cnMgdGhlDQo+Pj4gZGlz dGluY3Rpb24gYmV0d2VlbiByZXNvdXJjZSBhbmQgY2xpZW50IGFuZCBnaXZlcyB0aGUgaW1wcmVz c2lvbiB0aGF0DQo+Pj4gdGhlcmUgaXMgYW4gYW5hbG9nb3VzIGNsaWVudCBhY2Nlc3MgY29udHJv bCBwcm9ibGVtLCBidXQgSSBkb27igJl0IHNlZSBhbnkNCj4+PiBldmlkZW5jZSBvZiB0aGF0IGZy b20gdGhlIHVzZSBjYXNlcy4gQW5kIHRoZSBjdXJyZW50IHRlcm1pbm9sb2d5IGlzDQo+Pj4gbWFr aW5nDQo+Pj4gdGhlIGRpc3RpbmN0aW9uIGRpZmZpY3VsdC4NCj4+PiANCj4+PiBOb3cgd2UgbWFr ZSB0aGUgc2FtZSBleGVyY2lzZSBpbiB5b3VyIGV4YW1wbGUgYmVsb3cuDQo+Pj4gDQo+Pj4+IA0K Pj4+PiBUaGUgcXVlc3Rpb24gdGhhdCBzdXJmYWNlZCBoZXJlIGlzIHdoZXRoZXIgJ3ByaW5jaXBh bCcgaXMgdGhlIHJpZ2h0DQo+Pj4+IHRlcm0NCj4+Pj4gb3Igbm90LiBUaGUgZG9jdW1lbnQgZGVm aW5lcyBwcmluY2lwYWwgYXMgIkEgc3ViamVjdCB3aG8gaXMgZWl0aGVyIGENCj4+Pj4gcmVzb3Vy Y2Ugb3duZXIgb3IgYSBjbGllbnQgb3duZXIgb3IgYm90aC4iDQo+Pj4+IA0KPj4+PiBIZXJlIGlz IGEgc2xpZ2h0bHkgbW9kaWZpZWQgZXhhbXBsZSB1c2luZyBhIGRvb3IgbG9jayBzY2VuYXJpbyB0 aGF0IG1heQ0KPj4+PiBoZWxwIHVzIHNlZSB0aHJvdWdoIHRoaXMgY2FzZS4gSW1hZ2luZSBhIGZh bWlseSB3aXRoIGEga2lkOiBBbGljZSwgQm9iDQo+Pj4+IGFuZCB0aGVpciB5b3VuZyBjaGlsZCBF dmUuDQo+Pj4+IA0KPj4+PiBBbGljZSBhbmQgQm9iIGJvdWdodCBvbmUgb2YgdGhlc2UgSW50ZXJu ZXQgY29ubmVjdGVkIGRvb3IgbG9ja3MgYW5kIG5vdw0KPj4+PiB3YW50IHRvIGNvbmZpZ3VyZSBp dC4gVGhleSB3YW50IHRvIGNvbmZpZ3VyZSBpdCBpbiBzdWNoIGEgd2F5IHRoYXQgYWxsDQo+Pj4+ IHRocmVlIGNhbiBlbnRlciB0aGVpciBob3VzZSBqdXN0IHVzaW5nIHRoZWlyIHNtYXJ0IHBob25l IChhbmQgYQ0KPj4+PiBzcGVjaWFsbHkgbG9hZGVkIGFwcCkuDQo+Pj4+IA0KPj4+PiBXaGV0aGVy IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpcyBpbmNsdWRlZCBpbiB0aGUgZG9vciBsb2NrIGl0 c2VsZiBvcg0KPj4+PiBpcyBwYXJ0IG9mIHNvbWUgb3RoZXIgaG9tZSBhcHBsaWFuY2UgZG9lcyBu b3QgcmVhbGx5IG1hdHRlciBmb3IgdGhlDQo+Pj4+IG1vbWVudC4gSW4gYW55IGNhc2UsIEFsaWNl IGFuZCBCb2IgY29uZmlndXJlIHRoZSBkb29yIGxvY2sgaW4gc3VjaCBhDQo+Pj4+IHdheQ0KPj4+ PiB0aGF0IEV2ZSBpcyBncmFudGVkIGFjY2Vzcy4gQWxpY2UgYW5kIEJvYiBhcmUgdGhlIG93bmVy IG9mIHRoZSByZXNvdXJjZQ0KPj4+PiAoPWRvb3IgbG9jaykgYnV0IGV2ZW4gaWYgdGhleSBkbyBu b3QgJ293bicgdGhlIGRvb3IgbG9jayAoYnV0IGhhdmUNCj4+Pj4gcmF0aGVyIHJlbnRlZCBpdCkg ZG9lcyBub3QgcmVhbGx5IG1hdHRlci4NCj4+PiANCj4+PiBJIGFncmVlIGFib3V0IOKAnG93bmVy c2hpcOKAnSwgYnV0IGxldOKAmXMga2VlcCB0aGUgdGVybWlub2xvZ3kgaW4gdGhpcw0KPj4+IGV4 YW1wbGUuDQo+Pj4gDQo+Pj4+IA0KPj4+PiBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZG9lcyBu b3QgbmVjZXNzYXJpbHkgbmVlZCB0byBrbm93IHRoYXQgdGhpcw0KPj4+PiBhY2Nlc3MgY29udHJv bCBwb2xpY3kgaXMgYWJvdXQgIkV2ZSIuIEFsbCBpdCBjYXJlcyBpcyB0aGF0IHRoZXJlIGlzIGFu DQo+Pj4+IGVudHJ5IGluIHRoZSBhY2Nlc3MgY29udHJvbCBsaXN0IHRoYXQgcG9pbnRzIHRvIHNv bWUgY3JlZGVudGlhbCBvbiBzb21lDQo+Pj4+IGRldmljZS4gVGhhdCBjcmVkZW50aWFsIGhhcHBl bnMgdG8gcG9pbnQgdG8gYXBwIG9uIHRoZSBzbWFydCBwaG9uZSBFdmUNCj4+Pj4gaXMgdXNpbmcu DQo+Pj4+IA0KPj4+PiBOb3csIHRoZSBxdWVzdGlvbiBpcyBob3cgRXZlLCB3aG8gaXMgdGhlIGNs aWVudCBvd25lciwgZml0cyBpbnRvIHRoYXQNCj4+Pj4gcGljdHVyZS4gU2hlIHdvdWxkIHVzZSBo ZXIgcGhvbmUgKD1jbGllbnQpIHRvIHJlcXVlc3QgYWNjZXNzIHRvIHRoZQ0KPj4+PiBkb29yDQo+ Pj4+IGJ1dCBzaGUgd291bGQgbm90IGJlIGludm9sdmVkIGluIHByb3Zpc2lvbmluZyB0aGUgYWNj ZXNzIGNvbnRyb2wgcG9saWN5DQo+Pj4+IGF0IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4NCj4+ Pj4gDQo+Pj4+IERpZCBJIGNvcnJlY3RseSB1bmRlcnN0b29kIHRoaXMgaXNzdWU/DQo+Pj4gDQo+ Pj4gSSB0aGluayB5b3UgYXJlIGNvcnJlY3QgaW4gdGhhdCB0aGUgZGlzY3Vzc2lvbiBpcyBob3cg dGhlIGNsaWVudCBvd25lcg0KPj4+IGZpdHMgaW50byB0aGUgcGljdHVyZS4NCj4+IA0KPj4gSSB3 b3VsZCBhbHNvIHRoaW5rIHRoYXQgdGhpcyBpcyB0aGUgcHJvYmxlbS4gRXZlIHVzZXMgaGVyIHNt YXJ0cGhvbmUgdG8NCj4+IHJlcXVlc3QgYWNjZXNzIHRvIHRoZSBkb29yIGFuZCBpcyBncmFudGVk IGFjY2VzcyBkZXBlbmRpbmcgb24gQWxpY2UgYW5kDQo+PiBCb2JzIGF1dGhvcml6YXRpb24uIEV2 ZSBoYXMgbm8gaW5mbHVlbmNlIG9uIHRoZWlyIGRlY2lzaW9uLiBJbiB0aGUgZG9vcg0KPj4gbG9j ayBjYXNlIHRoaXMgbWlnaHQgbm90IGEgYmlnIHByb2JsZW0uIEV2ZSBhY3RpdmVseSB1c2VzIGhl ciBzbWFydHBob25lDQo+PiB0byBpbnRlcmFjdCB3aXRoIHRoZSBkb29yIGxvY2suIFRoZSBwaG9u ZSBtaWdodCBhbHNvIGRpc3BsYXkgc29tZSBraW5kDQo+PiBvZiBkaWFsb2cgd2hlcmUgRXZlIGNh biBkZWNpZGUgdG8gYWNjZXNzIHRoZSBkb29yIGxvY2sgb3Igbm90Lg0KPj4gDQo+PiBJZiBFdmUg ZG9lc24ndCB1c2UgaGVyIHBob25lIGJ1dCBhIGNvbnN0cmFpbmVkIGRldmljZSB0byBhY2Nlc3Ms IGUuZy4NCj4+IHNvbWUgc29ydCBvZiBrZXkgZm9iLCBzaGUgbWlnaHQgd2FudCB0byBtYWtlIHN1 cmUgdGhhdCBpdCBkb2Vzbid0DQo+PiBwcm92aWRlIGhlciBjcmVkZW50aWFscyB0byBldmVyeW9u ZSB3aG8gaXMgYXNraW5nLg0KPj4gDQo+Pj4gDQo+Pj4gV2hldGhlciB0aGUgcGhvbmUgaXMgaW52 b2x2ZWQgb3Igbm90IGluIHRyYW5zcG9ydGluZyBhY2Nlc3MgY29udHJvbA0KPj4+IHBvbGljeQ0K Pj4+IG9yIG90aGVyIGF1dGhvcml6YXRpb24gaW5mb3JtYXRpb24gdG8gdGhlIHJlc291cmNlIHNl cnZlciBpcyBub3QgdGhlDQo+Pj4gaXNzdWUuDQo+Pj4gDQo+Pj4gT25lIGlzc3VlIHdlIGhhdmUg aXMgaWYgdGhlIGRvb3IgbG9jayBjYW4gYmUgY2FsbGVkIOKAnFJlc291cmNl4oCdIG9yIGlmIGl0 DQo+Pj4gaXMNCj4+PiBjb21wbGV0ZWx5IGFyYml0cmFyeSB3aGljaCBpcyDigJxSZXNvdXJjZSIg YW5kIHdoaWNoIGlzIOKAnENsaWVudOKAnS4gKEnigJltIGluDQo+Pj4gZmF2b3VyIG9mIHRoZSBm b3JtZXIuKQ0KPj4+IA0KPj4+IE9uZSB0aGluZyB3ZSBkbyBhZ3JlZSBhYm91dCBpcyB0aGF0IHRo ZSB0ZW5hbnRzLCBBbGljZSBhbmQgQm9iLCBzaG91bGQNCj4+PiBiZQ0KPj4+IGFibGUgdG8gc2V0 IGFjY2VzcyBwb2xpY2llcyBmb3IgdGhlIGxvY2suIEkgdGhpbmsgdGhpcyBpcyB0aGUgYW5hbG9n dWUNCj4+PiBvZg0KPj4+IFUxLjFiL2MuIEJ1dCBzaW5jZSB3ZSBjYW7igJl0IGFncmVlZCB3aGV0 aGVyIHRoZSBsb2NrIGlzIOKAnFJlc291cmNlIiBvciBjYW4NCj4+PiBhbHRlcm5hdGl2ZWx5IGJl IOKAnENsaWVudCIsIEkgY2Fu4oCZdCB1c2UgdGhlIHRlcm0g4oCcUmVzb3VyY2UgT3duZXLigJ0u ICBOb3INCj4+PiBjYW4NCj4+PiB3ZSB1c2UgdGhlIHRlcm0g4oCcQ2xpZW50IE93bmVy4oCdLiBX aXRoIHJlZ2FyZHMgdG8gdGhpcywgSSBoYXZlIGJlZW4NCj4+PiBxdWVzdGlvbmluZyB0aGUgdXNl ZnVsbmVzcyBvZiB0aGUgY3VycmVudCB0ZXJtaW5vbG9neSBpbiB0aGUgZHJhZnQsIG9yDQo+Pj4g aG93DQo+Pj4gaXQgaXMgYXBwbGllZC4NCj4+IA0KPj4gSW4gdGhlIHVzZSBjYXNlcyBkb2N1bWVu dCwgd2UgYXJlIGRlZmluaW5nIHVzZSBjYXNlcyBmb3IgY29uc3RyYWluZWQNCj4+IGVudmlyb25t ZW50cy4gV2hlcmUgbmVlZGVkLCB3ZSBhc3N1bWUgQ29BUCBhcyB0aGUgdXNlZCBwcm90b2NvbC4g SW4gQ29BUA0KPj4gd2UgaGF2ZSB0d28gZW5kcG9pbnRzLCB0aGUgY2xpZW50IGFuZCB0aGUgc2Vy dmVyLCB0aGF0IGFyZSBjb21tdW5pY2F0aW5nDQo+PiB3aXRoIGVhY2ggb3RoZXIuIFRoZSBzZXJ2 ZXIgaG9zdHMgcmVzb3VyY2VzIHRoYXQgY2FuIGJlIGFjY2Vzc2VkIGJ5IHRoZQ0KPj4gY2xpZW50 LiBXZSBjb3VsZCBkZWZpbmUgdGhhdCBhIGRvb3IgbG9jayBNVVNUIGJlIGEgIENvQVAgc2VydmVy IGFuZCB0aGF0DQo+PiB0aGUgZGV2aWNlIGFjY2Vzc2luZyB0aGUgZG9vciBsb2NrIE1VU1QgYmUg YSBDb0FQIGNsaWVudCBvciB2aWNlIHZlcnNhLg0KPj4gSWYgdGhlcmUgaXMgbm8gc3Ryb25nIGV2 aWRlbmNlIHRvIGRvIHNvLCBJIHdvdWxkIHJhdGhlciBub3QgcmVzdHJpY3QNCj4+IENvQVAgaW1w bGVtZW50YXRpb25zIGluIHN1Y2ggYSB3YXkuIEl0IHNlZW1zIHdyb25nIHRvIG1lIHRvIHNheSB0 aGF0DQo+PiBDb0FQIGlzIGZsZXhpYmxlIGVub3VnaCB0byBhbGxvdyBmb3IgYWxsIGtpbmRzIG9m IHNldHRpbmdzIGJ1dA0KPj4gdW5mb3J0dW5hdGVseSBvdXIgYXV0aG9yaXphdGlvbiBzb2x1dGlv biBkb2VzIG5vdCBjb25zaWRlciB0aGlzDQo+PiBmbGV4aWJpbGl0eSB3aGljaCBpcyB3aHkgQ29B UCBpcyBsZXNzIGZsZXhpYmxlIGlmIHdlIGFyZSB1c2luZw0KPj4gYXV0aG9yaXphdGlvbi4NCj4+ IA0KPj4+IA0KPj4+IE1heWJlIHdlIGNhbiB1c2UgdGhlIHF1YWxpZmljYXRpb24g4oCcbG9jay1S ZXNvdXJjZSIgYW5kIOKAnGxvY2stQ2xpZW50IiB0bw0KPj4+IGRpc3Rpbmd1aXNoIGZyb20gb3Ro ZXIgcmVzb3VyY2VzIGFuZCBjbGllbnRzPyBBbmQgdGhlbiDigJxsb2NrLVJlc291cmNlDQo+Pj4g T3duZXLigJ0gKEFsaWNlIGFuZCBCb2IpIGFuZCDigJxsb2NrLUNsaWVudCBPd25lcuKAnSAoRXZl KSB3b3VsZCBhbHNvIGJlIHdlbGwNCj4+PiBkZWZpbmVkPw0KPj4+IA0KPj4+IA0KPj4+IFRoZSBv dGhlciBpc3N1ZSByZWxhdGVzIHRvIHdoYXQgaXMgdGhlIHByb2JsZW0gZm9yIEV2ZS4gQ29uc2lk ZXIgdGhlDQo+Pj4gYW5hbG9ndWUgb2YgVTEuMmIgYWJvdmUgaW4gdGhpcyBzZXR0aW5nOg0KPj4+ IA0KPj4+IFUxLjJiOiAiRXZlIHdhbnRzIHRvIGRlZmluZSBmb3IgaGVyIHBob25lIGlmIGFuZCBo b3cgaXQgaXMgYWxsb3cgdG8NCj4+PiByZXF1ZXN0IHRoZSBsb2NrIHRvIGJlIG9wZW5lZC4iDQo+ Pj4gDQo+Pj4gVG8gbWUgaXQgaXMgcXVpdGUgY2xlYXIgdGhhdCB0aGlzIGlzIGFuIGF3a3dhcmQg d2F5IG9mIGZvcmNpbmcgYW4gYWNjZXNzDQo+Pj4gY29udHJvbCBwcm9ibGVtIGZvcm11bGF0aW9u IGludG8gd2hhdCBpc27igJl0LiBXaGVuIEV2ZSB3YW50cyB0byBvcGVuIGENCj4+PiBsb2NrLCBz aGUgcHJlc3NlcyBhIGJ1dHRvbiBpbiB0aGUgYXBwLCB0aGVyZWJ5IGF1dGhvcml6ZXMgdGhlIHJl cXVlc3QuDQo+Pj4gVGhlcmUgaXMgbm8gbmVlZCB0byBzb2x2ZSB0aGlzIHdpdGggYWNjZXNzIGNv bnRyb2wgcG9saWNpZXMsIHRyYW5zcG9ydA0KPj4+IGF1dGhvcml6YXRpb24gaW5mb3JtYXRpb24s IGVuZm9yY2VtZW50IGV0Yy4gIFRoZXJlIGlzIGEgbmF0dXJhbA0KPj4+IGFzeW1tZXRyeQ0KPj4+ IHdoaWNoIGlzIGNsZWFybHkgaWxsdXN0cmF0ZWQgaW4gdGhlIHVzZSBjYXNlcy4gV2Ugc2hvdWxk IG5vdCBoaWRlIHRoYXQNCj4+PiBiZWhpbmQgc3RyYW5nZSB0ZXJtaW5vbG9neSBhbmQgZm9ybXVs YXRpb25zLg0KPj4gDQo+PiBZZXMsIGV4YWN0bHksIEV2ZSBpcyBhdXRob3JpemluZyB0aGUgcmVx dWVzdC4gQW5kIGluIHRoaXMgc3BlY2lmaWMNCj4+IHNjZW5hcmlvIGltcGxpY2l0IGF1dGhvcml6 YXRpb24gKGFuIGF1dGhlbnRpY2F0ZWQgZGV2aWNlIGlzIGF1dGhvcml6ZWQpDQo+PiBtaWdodCBi ZSBnb29kIGVub3VnaC4gU2luY2UgRXZlIGNhbiBkZWNpZGUgd2hhdCBoZXIgc21hcnRwaG9uZSBp cw0KPj4gc3VwcG9zZWQgdG8gZG8sIHRoZXJlIGlzIG5vIG5lZWQgZm9yIG1vcmUgc29waGlzdGlj YXRlZCBhdXRob3JpemF0aW9uDQo+PiBwb2xpY2llcy4gVGhpcyBpcyBkaWZmZXJlbnQgZm9yIG90 aGVyIHVzZSBjYXNlcy4NCj4+IA0KPj4gSWYgeW91IHRoaW5rIGFib3V0IGl0LCB0aGVyZSBpcyBh bHNvIG5vIG5lZWQgZm9yIHNvcGhpc3RpY2F0ZWQNCj4+IGF1dGhvcml6YXRpb24gb24gdGhlIGRv b3IgbG9jayBzaWRlLCBlaXRoZXIuIEl0IG1pZ2h0IGJlIHN1ZmZpY2llbnQgaWYgYQ0KPj4gZGV2 aWNlIHRoYXQgY2FuIGJlIGF1dGhlbnRpY2F0ZWQgaXMgYXV0aG9yaXplZCB0byBvcGVuIHRoZSBk b29yLiBJbiB0aGlzDQo+PiBjYXNlLCBpbXBsaWNpdCBhdXRob3JpemF0aW9uIGlzIHN1ZmZpY2ll bnQgb24gYm90aCBzaWRlcy4gQWdhaW4gdGhpcyBpcw0KPj4gZGlmZmVyZW50IGZvciBvdGhlciB1 c2UgY2FzZXMuDQo+PiANCj4+IEJlc3QgcmVnYXJkcywNCj4+IFN0ZWZmaQ0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQWNlIG1haWxpbmcg bGlzdA0KPiBBY2VAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9hY2UNCg== --Apple-Mail-5D0591B9-EE78-4F02-A34D-5923E060F039 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF9jCCBfIw ggPaoAMCAQICED5j3SSNCPxYeGdCFol+BckwDQYJKoZIhvcNAQEFBQAwOjERMA8GA1UECgwIRXJp Y3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjIwHhcNMTQxMjIyMDky NjE0WhcNMTcxMjIyMDkyNjEzWjBrMREwDwYDVQQKDAhFcmljc3NvbjEYMBYGA1UEAwwPR8O2cmFu IFNlbGFuZGVyMSowKAYJKoZIhvcNAQkBFhtnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20xEDAO BgNVBAUTB2VyYWdvc2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCSU5mmTfwCXmA8 +o6zD0QBUzHdSI8Nnh1/IJqdUCNMsXGhyh13VB0fb/dlvGxNuFK7EKzKAmV54EVajL+FRucgxen9 lcC7bp4f1qd3au9kgOXYKzHuw9btR1xuqWG+fvzrZGaSAt2bewZenaZnyZWxoX9o7ia2ZviWktr0 frBlXciopyIlMnIgZ4D4eif47wlcX/ZPATYvm+AkdIH6/PqkY/8Cq3FMILYvrRvO5X1przyuLH+d suuETUeGbbHQrU+C2DKJnE6xVm4K9nXBvpcfkdKVQuqqg7O71Sd1QRDyt6BCXjrSZ4prRy/n26DU 6FMcIn2DkeXdWnm8SpxxoE/zAgMBAAGjggHBMIIBvTBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8v Y3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjIuY3JsMIGCBggrBgEF BQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYB BQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1 YWxjYXYyLmNlcjAmBgNVHREEHzAdgRtnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20wVQYDVR0g BE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRy dXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0G A1UdDgQWBBSB4nTbn3t1sB2zhLxonZW3Hhv9/zAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52 cX9LNzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBANSVTbxCbSceXCp/tX+UCloB 5q5UI743Q5vKV+h+TB86caGnHBuBtHatVJTD/k+myt8+B+Iu60M2UrX3gBmwSTW6Y8MZhtXYijOM OPvKVyqHkf9ikVMWDBKG+b6O9UB+EomtcfZ7cElXCu/AjXW4Q7CZWVwPrJORLec6mfER9usYEa0O x+meWW5sRDKVHTFgVgsub3+4ouzgOQpsqGrQydYhovIptNPalWGSSTMYpW+r6rukSQ/sUjl54pCA SZj5zs9mQu9fhRtm4I+9HcBNSe1+yq6ECW0Zvc82ynYTFx3w0Art1hmmnd7euM17JzpORrh3y07D ey0wc3RoP4z4ISNffsC+z+jVMl54H1PYYiDuHiPf+cMorlMXFPs7rTFgZS/mY1B2v+qZP9O9k4i/ g4HPQlsJgnWxC5TWluMsOHzQS35FR+oei/35aDwNYvdPixeWNhUmkR4vtfydjpLW+3eKyxcf0Hf/ SVJuzMYrnssBFe+jYNGJYGvdOFjJFffqKCcRocJ0l25ALTVDtv3kpZap6YZXaBAeYTncGWVyv9te bhtILVdqlO7sLtP3zAGZ46bPTW/54F7TOwZ+kfI0vptFgJN5iAA8GwOvhBatrNw9oA9dM2ioAlBb iD3gQ8Fz7Mxq/5AkpSdt3Gzxd7HNwhi5GIkuyPtq1U7B/o19KWC7MYICljCCApICAQEwTjA6MREw DwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIQ PmPdJI0I/Fh4Z0IWiX4FyTAJBgUrDgMCGgUAoIIBHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xNTAzMDUwNDU2NDFaMCMGCSqGSIb3DQEJBDEWBBSkFJYhYaQC1q8Z WhYRpkjG4qSVgjBdBgkrBgEEAYI3EAQxUDBOMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhA+Y90kjQj8WHhnQhaJfgXJMF8GCyqGSIb3 DQEJEAILMVCgTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MgIQPmPdJI0I/Fh4Z0IWiX4FyTANBgkqhkiG9w0BAQEFAASCAQBF9WhoK+M0 l8U2SsD7NGZkqSdGBn9k/19GSbGM8m3fUiGhRx2tG+yK1mu+2VDzeZKfO1USQ/jjXMGD8s3uUabK a6d0CJmoTN81sFl3Aunfv8K4OCAqqBEc3SFcE1By6vZ2sxT0VXgiCFqKVCjHKE2JLRR+SyeOn7+d g15zChshA1jJK+vn/23hcZEWNPyNFIL6cY9DvUlxSx0kRX7tUg/yPcJnWH6qnRmURZ7+sLPK58ss Md2H956eX6ME26al0cv6xOpEmE9Ds8mRJl3bO927X1eixAvvCPAXXMH2hI6QjZSVNPO9B0i7O7ZE K4xkQQSBkbuPAB1hylSipjSUQsKVAAAAAAAA --Apple-Mail-5D0591B9-EE78-4F02-A34D-5923E060F039-- From nobody Thu Mar 5 00:39: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 63E111B2A93 for ; Thu, 5 Mar 2015 00:39:50 -0800 (PST) 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 o8P-LVdVdrDZ for ; Thu, 5 Mar 2015 00:39:48 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04C081B2A98 for ; Thu, 5 Mar 2015 00:39:46 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t258dgsC002833; Thu, 5 Mar 2015 09:39:42 +0100 (CET) Received: from [192.168.1.109] (p57A63DDF.dip0.t-ipconnect.de [87.166.61.223]) (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 3kyQVk4153z2lbW; Thu, 5 Mar 2015 09:39:42 +0100 (CET) Message-ID: <54F8164A.4080801@tzi.de> Date: Thu, 05 Mar 2015 09:39:38 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= , "Ace@ietf.org" References: <54F75101.4050008@tzi.de> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] Authorization on the client side 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, 05 Mar 2015 08:39:50 -0000 Hi Göran, I didn't forget our discussion. But it would be helpful to summarize the things we agreed on. You said that you agree that there is an authorization problem on the client side. You also agree that we don't need a sophisticated authorization mechanism to solve every authorization problem. In your e-mail, you listed additional authorization problems that are not part of the current discussion. I don't see how discussing these helps things. Best regards, Steffi On 03/04/2015 08:07 PM, Göran Selander wrote: > Hi Steffi, > > I disagree. If you recall from > http://www.ietf.org/mail-archive/web/ace/current/msg00995.html > I listed a number of “authorization problems” on the client side, none of > which is of the concern of ACE IMHO. The same applies the problem you > list, corresponding to U1.2b of > http://www.ietf.org/mail-archive/web/ace/current/msg01019.html. > > Just because I haven’t had time to answer this mail thread today doesn’t > mean that you can forget about our last months of discussions. I’ll be > back. > > > Best regards, > Göran > > > > > On 2015-03-04 19:37, "Stefanie Gerdes" wrote: > >> Hi all, >> >> What I get from the discussion is that we agree that there is an >> authorization problem on the client side. We also agree that for some >> authorization problems we don't need a sophisticated authorization >> mechanism. >> >> So maybe we can postpone further discussions about solutions and just >> finish the use cases draft? >> >> We can keep the authorization problem on the client side in the problem >> summary sections. Moreover, we can add the following to section 3.2 >> (Configuration of Access Permissions): "Endpoints need to be enabled to >> enforce the authorization policies of their principals. In some cases, >> authorization problems might bei solved by implicit authorization (all >> authenticated entities are authorized)." >> >> What do you think? >> >> Best regards >> Steffi >> >> -- >> Stefanie Gerdes Tel: +49 421 218 63906 >> TZI Universität Bremen E-Mail: gerdes@tzi.de >> Bibliothekstr. 1, MZH 5150 >> 28359 Bremen, Germany >> >> _______________________________________________ >> 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 Thu Mar 5 00:40: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 1950D1B2A9E for ; Thu, 5 Mar 2015 00:39:58 -0800 (PST) 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 L3Bf123Nh3Ra for ; Thu, 5 Mar 2015 00:39:54 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D39EA1B2A9C for ; Thu, 5 Mar 2015 00:39:53 -0800 (PST) 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 t258dk9C003189; Thu, 5 Mar 2015 09:39:46 +0100 (CET) Received: from [192.168.1.109] (p57A63DDF.dip0.t-ipconnect.de [87.166.61.223]) (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 3kyQVp5H77z2lbX; Thu, 5 Mar 2015 09:39:46 +0100 (CET) Message-ID: <54F81652.6040102@tzi.de> Date: Thu, 05 Mar 2015 09:39:46 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= , Hannes Tschofenig , "Ace@ietf.org" References: <54F5B1F2.6050205@gmx.net> <54F616CF.20607@tzi.de> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] U1.2 in Use Case Document 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, 05 Mar 2015 08:39:58 -0000 Hi Göran, if we use any kind of solution specific terminology in the draft, we must use CoAP terminology since we want to find an authorization solution that fits to CoAP. Yes, I agree that terminology and problem statement need to be clear. But they need to fit to the problem, not to the solution. I am pretty sure that we will find out how a solution can be mapped to the use cases. But if the use cases document don't reflect how things work in CoAP, I don't think we will be able to find a fitting solution. Best regards, Steffi On 03/05/2015 01:42 AM, Göran Selander wrote: > Hi Steffi and all, > > > Trying to catch up with the mails. I just summarize some comments on this > mail for now. > > Terminology and problem statement > - - - > Current terminology, or how it is applied, is unsatisfactory, as I’ve > re-iterated a couple of times. I’ve previously been working in large > projects where terminology and problem statement was unclear and it is an > absolute waste of time. I think others in this group having similar > experiences can confirm this. > > > We have different options to resolve this. > > 1. We can remove role terminology from the use case draft and express the > problems in terms of the actors in the use cases. E.g. "fruit vendors want > to grant different access rights to different parties to measurements of > goods’ temperatures". That would save the use case document, but in this > case we don’t have a general problem statement in terms of roles, and that > then becomes then our next challenge. > > 2. If we instead define roles (Resource Server, Client etc.) then we must > be able to express the relevant problems based on the use cases in terms > of the roles defined. Otherwise the role definitions are not good enough. > For example "Resource Owners, such as fruit vendors, wants to grant > different access rights to different parties for their resources, such as > temperatures" > > If we can’t express what are the assets and the stakeholders in a well > defined way, so that we can formulate the problem statement in terms of > these, then we have a serious problem. I advocate that we adopt an > established terminology such as OAuth or UMA. Whatever client aspects we > want to formulate can surely be expressed in any of these terminology. > > Some control questions on how far we have reached in this work: > > - In the container use case, can we agree that the temperature sensors and > fan actuators are the main “items of interest”. > > - Can we denote the temperature sensor and fan actuators “Resources”? > > - Can we, as Eve proposed, agree to view the temperature sensor - fan > actuator interaction as two one-way relationships, i.e. there are > temperature-resources and temperature-clients, as well as fan-resources > and fan-clients (some of which may be co-located). > > (Maybe we can then avoid formulations such as "If the temperature sensor > is not able to decide if a resource is authorized”? See further down in > this mail.) > > > > Constrained clients > - - - > One recurring theme in this discussion has been on constrained client > devices. There is a question about what kind of "authorization problems” > that are relevant to the client device. It is mainly related to aspects of > a client disclosing a request. There has been repeated claims about the > need for sophisticated access control policies on the client side, in the > sense that the client actions, such as making a request, need to be > subject to access control policies, just because the devices are > constrained. But nowhere in the use case document is this claim > substantiated, i.e. that a particular use case is requiring such a > feature. There are only abstract formulations about principals, and > interpreted as resource owner as well as client owners. The motivation for > that has been that if we describe the use case in too much detail it > becomes solution specific. An alternative explanation is that only few, if > any, of the use cases actually require client side access control policies. > > I think we should detach any potential access control policy problems of > the client from that related to resource access, because it is different, > it is not documented to be relevant, and it is an independent problem that > makes the problem formulation complex. Furthermore, no one actually knows > about the need and nature of policies for in these situations. It is pure > speculations. I think that if anything, some sort of "decision policies” > could potentially be useful. Formulating it as access control problem > leads to very strange statements as I showed at the end of this mail: > http://www.ietf.org/mail-archive/web/ace/current/msg01019.html > > > More later. > > Best regards, > Göran > > > > On 2015-03-03 21:17, "Stefanie Gerdes" wrote: > >> Hi all, >> >> On 03/03/2015 06:03 PM, Göran Selander wrote: >>> Hi Hannes, >>> >>> On 2015-03-03 14:06, "Hannes Tschofenig" >>> wrote: >>> >>>> Hi all, >>>> >>>> let me try to see whether I understand the issue that's currently under >>>> discussion. >>>> >>>> It seems that the debate focuses on this requirement from the >>>> 'Container >>>> monitoring' use case: >>>> >>>> " >>>> o U1.2 Principals want to grant different access rights for >>>> different resources on an endpoint. >>>> " >>> >>> Actually, we are not debating this U1.2 requirement. Steffi made a new >>> set >>> of requirements, see >>> http://www.ietf.org/mail-archive/web/ace/current/msg00982.html >>> >>> The debate focused on this requirement proposed by Steffi: >>> >>> "U1.1a Principals such as the fruit vendor, the transloading personnel >>> or >>> the container owners want to define authorizations for their resources >>> and endpoints." >>> >>> (I insert “a”, “b”, “c” etc. to distinguish the different versions of >>> requirements) >>> >>> >>> Then Steffi proposed to split U1.1a in these requirements: >>> >>> (http://www.ietf.org/mail-archive/web/ace/current/msg00992.html) >>> >>> >>> “U1.1b: Resource Owners want to grant different access rights for their >>> resources to different parties. >>> >>> U1.2b: Client Owners want to define for their clients if and how they >>> are >>> allowed to access resources hosted on a Resource Server." >> >> In fact I didn't want to split U1.1a. You, Göran, proposed in >> http://www.ietf.org/mail-archive/web/ace/current/msg00991.html to >> replace U1.1 with two "requirements" as you called them. I am not happy >> with this proposal but would have agreed to it if it helped things. >> >> The meaning of the original U1.1 problem is that principals in this use >> case want to grant different authorizations to different people / >> devices / resources (meaning that devices of company A get different >> access rights then devices of company B). It seems that it is quite >> difficult to find a neutral phrasing for this problem. >> >> The split now shows a completely different aspect of this problem: we >> can protect the client side or we can protect the server side or both. >> These really are solution specific and as we can see, this leads to >> people wanting to defend their favorite solution. Instead of: "users >> somehow want to grant different authorizations to different people" we >> are deep into a solution space discussion about whether it is more >> useful to protect the server or the client side, if the client side even >> needs protection and so on. I would like to emphasize that this is not >> what U1.1 is about. Maybe we can still find a better phrasing that does >> not indicate a specific solution. >> >> The different proposals for the phrasing of U1.1 indicate a different >> problem: Do we want to develop a solution that exclusively protects >> resources or do we also want to consider the client side? Most of us are >> more familiar with the protection of resources because we already know >> that from web scenarios. But in these scenarios we always have a user >> that performs authorization on the client side. For constrained >> environments, it is not always that simple. We might have true machine >> to machine (M2M) communication where a device must decide for itself >> whether something is authorized by its user or not. Moreover, devices >> might not have displays and thus it might not be possible for the user >> to directly interact with the device for authorization. Solving these >> problems is not optional. And I think it is important to be aware of >> these problems. A solution can decide if and how to solve them. >> >>> >>> >>> Referring to the U1.1a, I proposed to clarify what U1.1b means in terms >>> of >>> the actors and resources of the use case: >>> (http://www.ietf.org/mail-archive/web/ace/current/msg01000.html) >>> >>> “U1.1c: Resource Owners, such as fruit vendors and container owners, >>> want >>> to >>> grant different access rights to different parties for their respective >>> resources, such as temperatures and fan settings." >>> >>> >>> This was not agreed, see discussion about resource and client below. >>> >>> With regards to U1.2b, I requested that this abstract statement should >>> be >>> exemplified with actors and client devices from this use case to allow >>> everyone to form an opinion if this is a relevant access control problem >>> in the scope of ACE or not. If that can’t be made, then I think this >>> requirement is less relevant for this use case and consider leave it >>> out. >> >> Imagine a specific implementation of the container scenario where the >> temperature sensor is the client and the fan actuator is the server. The >> fruit vendor wants to make sure that the temperature sensor sends the >> temperature values only to authorized fan actuator resources because she >> doesn't want unauthorized people to gain knowledge about the state of >> the goods. The container owner wants to make sure that the server only >> accepts data from authorized clients. In this case, both the client >> owner and the resource owner will need to define access policies. The >> client owner (the fruit vendor) defines a rule that states that the >> client (the temperature sensor) is allowed to do a PUT on resources that >> belong to a specific container owner. The resource owner (the container >> owner) defines a rule that states that clients of a certain fruit vendor >> are allowed to do a PUT on their resources. If the temperature sensor is >> not able to decide if a resource is authorized, it cannot enforce the >> authorization decisions of its owner. >> >>> >>> NOTE: I’m not saying U1.2b is not a possible security concern. I’m >>> questioning that it is an access control problem analogous to U1.1b. The >>> original requirement formulation U1.1 (in the draft) and U1.1a blurs the >>> distinction between resource and client and gives the impression that >>> there is an analogous client access control problem, but I don’t see any >>> evidence of that from the use cases. And the current terminology is >>> making >>> the distinction difficult. >>> >>> Now we make the same exercise in your example below. >>> >>>> >>>> The question that surfaced here is whether 'principal' is the right >>>> term >>>> or not. The document defines principal as "A subject who is either a >>>> resource owner or a client owner or both." >>>> >>>> Here is a slightly modified example using a door lock scenario that may >>>> help us see through this case. Imagine a family with a kid: Alice, Bob >>>> and their young child Eve. >>>> >>>> Alice and Bob bought one of these Internet connected door locks and now >>>> want to configure it. They want to configure it in such a way that all >>>> three can enter their house just using their smart phone (and a >>>> specially loaded app). >>>> >>>> Whether the authorization server is included in the door lock itself or >>>> is part of some other home appliance does not really matter for the >>>> moment. In any case, Alice and Bob configure the door lock in such a >>>> way >>>> that Eve is granted access. Alice and Bob are the owner of the resource >>>> (=door lock) but even if they do not 'own' the door lock (but have >>>> rather rented it) does not really matter. >>> >>> I agree about “ownership”, but let’s keep the terminology in this >>> example. >>> >>>> >>>> The authorization server does not necessarily need to know that this >>>> access control policy is about "Eve". All it cares is that there is an >>>> entry in the access control list that points to some credential on some >>>> device. That credential happens to point to app on the smart phone Eve >>>> is using. >>>> >>>> Now, the question is how Eve, who is the client owner, fits into that >>>> picture. She would use her phone (=client) to request access to the >>>> door >>>> but she would not be involved in provisioning the access control policy >>>> at the authorization server. >>>> >>>> Did I correctly understood this issue? >>> >>> I think you are correct in that the discussion is how the client owner >>> fits into the picture. >> >> I would also think that this is the problem. Eve uses her smartphone to >> request access to the door and is granted access depending on Alice and >> Bobs authorization. Eve has no influence on their decision. In the door >> lock case this might not a big problem. Eve actively uses her smartphone >> to interact with the door lock. The phone might also display some kind >> of dialog where Eve can decide to access the door lock or not. >> >> If Eve doesn't use her phone but a constrained device to access, e.g. >> some sort of key fob, she might want to make sure that it doesn't >> provide her credentials to everyone who is asking. >> >>> >>> Whether the phone is involved or not in transporting access control >>> policy >>> or other authorization information to the resource server is not the >>> issue. >>> >>> One issue we have is if the door lock can be called “Resource” or if it >>> is >>> completely arbitrary which is “Resource" and which is “Client”. (I’m in >>> favour of the former.) >>> >>> One thing we do agree about is that the tenants, Alice and Bob, should >>> be >>> able to set access policies for the lock. I think this is the analogue >>> of >>> U1.1b/c. But since we can’t agreed whether the lock is “Resource" or can >>> alternatively be “Client", I can’t use the term “Resource Owner”. Nor >>> can >>> we use the term “Client Owner”. With regards to this, I have been >>> questioning the usefulness of the current terminology in the draft, or >>> how >>> it is applied. >> >> In the use cases document, we are defining use cases for constrained >> environments. Where needed, we assume CoAP as the used protocol. In CoAP >> we have two endpoints, the client and the server, that are communicating >> with each other. The server hosts resources that can be accessed by the >> client. We could define that a door lock MUST be a CoAP server and that >> the device accessing the door lock MUST be a CoAP client or vice versa. >> If there is no strong evidence to do so, I would rather not restrict >> CoAP implementations in such a way. It seems wrong to me to say that >> CoAP is flexible enough to allow for all kinds of settings but >> unfortunately our authorization solution does not consider this >> flexibility which is why CoAP is less flexible if we are using >> authorization. >> >>> >>> Maybe we can use the qualification “lock-Resource" and “lock-Client" to >>> distinguish from other resources and clients? And then “lock-Resource >>> Owner” (Alice and Bob) and “lock-Client Owner” (Eve) would also be well >>> defined? >>> >>> >>> The other issue relates to what is the problem for Eve. Consider the >>> analogue of U1.2b above in this setting: >>> >>> U1.2b: "Eve wants to define for her phone if and how it is allow to >>> request the lock to be opened." >>> >>> To me it is quite clear that this is an awkward way of forcing an access >>> control problem formulation into what isn’t. When Eve wants to open a >>> lock, she presses a button in the app, thereby authorizes the request. >>> There is no need to solve this with access control policies, transport >>> authorization information, enforcement etc. There is a natural >>> asymmetry >>> which is clearly illustrated in the use cases. We should not hide that >>> behind strange terminology and formulations. >> >> Yes, exactly, Eve is authorizing the request. And in this specific >> scenario implicit authorization (an authenticated device is authorized) >> might be good enough. Since Eve can decide what her smartphone is >> supposed to do, there is no need for more sophisticated authorization >> policies. This is different for other use cases. >> >> If you think about it, there is also no need for sophisticated >> authorization on the door lock side, either. It might be sufficient if a >> device that can be authenticated is authorized to open the door. In this >> case, implicit authorization is sufficient on both sides. Again this is >> different for other use cases. >> >> Best regards, >> Steffi > > > -- Stefanie Gerdes Tel: +49 421 218 63906 TZI Universität Bremen E-Mail: gerdes@tzi.de Bibliothekstr. 1, MZH 5150 28359 Bremen, Germany From nobody Thu Mar 5 00:47: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 3EFD01B2ABD for ; Thu, 5 Mar 2015 00:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Y7_uWFVhY8K3 for ; Thu, 5 Mar 2015 00:47:48 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9123B1B2AB9 for ; Thu, 5 Mar 2015 00:47:47 -0800 (PST) Received: from [192.168.131.142] ([80.92.121.102]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MTkNU-1Y39983gaO-00QT3E; Thu, 05 Mar 2015 09:47:31 +0100 Message-ID: <54F8181E.7080304@gmx.net> Date: Thu, 05 Mar 2015 09:47:26 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Stefanie Gerdes , =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= , "Ace@ietf.org" References: <54F5B1F2.6050205@gmx.net> <54F616CF.20607@tzi.de> <54F81652.6040102@tzi.de> In-Reply-To: <54F81652.6040102@tzi.de> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qJcemG4GlptSN7gfNmwpvAJkCbRMMSUsq" X-Provags-ID: V03:K0:DVpMMIjVV/fiP80hMirmG+EHh4Vs418Ra/dnRW/QGkvoweOSMG5 x/QfFQvd2iL1kFMvRSOGN2TuOtJu2effhHuZkvtNkdUurIlNi1AufpAA2trRs5iIJUQMo6n uBd2wFL/grklMWByFlzU4NBTHDvOnjN5wzXmhpRPiNCUqllFiphu5UF/eFxtrxhUcsdvzJn AyBrSNNzSHQ95r5PsVYUQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [Ace] U1.2 in Use Case Document 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, 05 Mar 2015 08:47:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qJcemG4GlptSN7gfNmwpvAJkCbRMMSUsq Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Steffi, Hi G=C3=B6ran, we do not want to have CoAP specific terminology in the document. While it has to be applicable to CoAP early in the charter discussion we wanted to also not rule out other protocols and there is nothing really in the document that depends on CoAP. In terms of listing the requirements in reference to the use cases, such as saying "fruit vendors want to grant different access rights to different parties to measurements of goods=E2=80=99 temperatures" sounds = OK to me. The text in the use case should anyway say what rule the fruit vendor plays. Ciao Hannes On 03/05/2015 09:39 AM, Stefanie Gerdes wrote: > Hi G=C3=B6ran, >=20 > if we use any kind of solution specific terminology in the draft, we > must use CoAP terminology since we want to find an authorization > solution that fits to CoAP. >=20 > Yes, I agree that terminology and problem statement need to be clear. > But they need to fit to the problem, not to the solution. >=20 > I am pretty sure that we will find out how a solution can be mapped to > the use cases. But if the use cases document don't reflect how things > work in CoAP, I don't think we will be able to find a fitting solution.= >=20 > Best regards, > Steffi >=20 >=20 > On 03/05/2015 01:42 AM, G=C3=B6ran Selander wrote: >> Hi Steffi and all, >> >> >> Trying to catch up with the mails. I just summarize some comments on t= his >> mail for now. >> >> Terminology and problem statement >> - - - >> Current terminology, or how it is applied, is unsatisfactory, as I=E2=80= =99ve >> re-iterated a couple of times. I=E2=80=99ve previously been working in= large >> projects where terminology and problem statement was unclear and it is= an >> absolute waste of time. I think others in this group having similar >> experiences can confirm this. >> >> >> We have different options to resolve this. >> >> 1. We can remove role terminology from the use case draft and express = the >> problems in terms of the actors in the use cases. E.g. "fruit vendors >> want >> to grant different access rights to different parties to measurements = of >> goods=E2=80=99 temperatures". That would save the use case document, b= ut in this >> case we don=E2=80=99t have a general problem statement in terms of rol= es, and >> that >> then becomes then our next challenge. >> >> 2. If we instead define roles (Resource Server, Client etc.) then we m= ust >> be able to express the relevant problems based on the use cases in ter= ms >> of the roles defined. Otherwise the role definitions are not good enou= gh. >> For example "Resource Owners, such as fruit vendors, wants to grant >> different access rights to different parties for their resources, such= as >> temperatures" >> >> If we can=E2=80=99t express what are the assets and the stakeholders i= n a well >> defined way, so that we can formulate the problem statement in terms o= f >> these, then we have a serious problem. I advocate that we adopt an >> established terminology such as OAuth or UMA. Whatever client aspects = we >> want to formulate can surely be expressed in any of these terminology.= >> >> Some control questions on how far we have reached in this work: >> >> - In the container use case, can we agree that the temperature sensors= >> and >> fan actuators are the main =E2=80=9Citems of interest=E2=80=9D. >> >> - Can we denote the temperature sensor and fan actuators =E2=80=9CReso= urces=E2=80=9D? >> >> - Can we, as Eve proposed, agree to view the temperature sensor - fan >> actuator interaction as two one-way relationships, i.e. there are >> temperature-resources and temperature-clients, as well as fan-resource= s >> and fan-clients (some of which may be co-located). >> >> (Maybe we can then avoid formulations such as "If the temperature sens= or >> is not able to decide if a resource is authorized=E2=80=9D? See furthe= r down in >> this mail.) >> >> >> >> Constrained clients >> - - - >> One recurring theme in this discussion has been on constrained client >> devices. There is a question about what kind of "authorization proble= ms=E2=80=9D >> that are relevant to the client device. It is mainly related to >> aspects of >> a client disclosing a request. There has been repeated claims about th= e >> need for sophisticated access control policies on the client side, in = the >> sense that the client actions, such as making a request, need to be >> subject to access control policies, just because the devices are >> constrained. But nowhere in the use case document is this claim >> substantiated, i.e. that a particular use case is requiring such a >> feature. There are only abstract formulations about principals, and >> interpreted as resource owner as well as client owners. The motivation= >> for >> that has been that if we describe the use case in too much detail it >> becomes solution specific. An alternative explanation is that only >> few, if >> any, of the use cases actually require client side access control >> policies. >> >> I think we should detach any potential access control policy problems = of >> the client from that related to resource access, because it is differe= nt, >> it is not documented to be relevant, and it is an independent problem >> that >> makes the problem formulation complex. Furthermore, no one actually kn= ows >> about the need and nature of policies for in these situations. It is p= ure >> speculations. I think that if anything, some sort of "decision policie= s=E2=80=9D >> could potentially be useful. Formulating it as access control problem >> leads to very strange statements as I showed at the end of this mail: >> http://www.ietf.org/mail-archive/web/ace/current/msg01019.html >> >> >> More later. >> >> Best regards, >> G=C3=B6ran >> >> >> >> On 2015-03-03 21:17, "Stefanie Gerdes" wrote: >> >>> Hi all, >>> >>> On 03/03/2015 06:03 PM, G=C3=B6ran Selander wrote: >>>> Hi Hannes, >>>> >>>> On 2015-03-03 14:06, "Hannes Tschofenig" = >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> let me try to see whether I understand the issue that's currently >>>>> under >>>>> discussion. >>>>> >>>>> It seems that the debate focuses on this requirement from the >>>>> 'Container >>>>> monitoring' use case: >>>>> >>>>> " >>>>> o U1.2 Principals want to grant different access rights for >>>>> different resources on an endpoint. >>>>> " >>>> >>>> Actually, we are not debating this U1.2 requirement. Steffi made a n= ew >>>> set >>>> of requirements, see >>>> http://www.ietf.org/mail-archive/web/ace/current/msg00982.html >>>> >>>> The debate focused on this requirement proposed by Steffi: >>>> >>>> "U1.1a Principals such as the fruit vendor, the transloading personn= el >>>> or >>>> the container owners want to define authorizations for their resourc= es >>>> and endpoints." >>>> >>>> (I insert =E2=80=9Ca=E2=80=9D, =E2=80=9Cb=E2=80=9D, =E2=80=9Cc=E2=80= =9D etc. to distinguish the different versions of >>>> requirements) >>>> >>>> >>>> Then Steffi proposed to split U1.1a in these requirements: >>>> >>>> (http://www.ietf.org/mail-archive/web/ace/current/msg00992.html) >>>> >>>> >>>> =E2=80=9CU1.1b: Resource Owners want to grant different access right= s for their >>>> resources to different parties. >>>> >>>> U1.2b: Client Owners want to define for their clients if and how the= y >>>> are >>>> allowed to access resources hosted on a Resource Server." >>> >>> In fact I didn't want to split U1.1a. You, G=C3=B6ran, proposed in >>> http://www.ietf.org/mail-archive/web/ace/current/msg00991.html to >>> replace U1.1 with two "requirements" as you called them. I am not hap= py >>> with this proposal but would have agreed to it if it helped things. >>> >>> The meaning of the original U1.1 problem is that principals in this u= se >>> case want to grant different authorizations to different people / >>> devices / resources (meaning that devices of company A get different >>> access rights then devices of company B). It seems that it is quite >>> difficult to find a neutral phrasing for this problem. >>> >>> The split now shows a completely different aspect of this problem: we= >>> can protect the client side or we can protect the server side or both= =2E >>> These really are solution specific and as we can see, this leads to >>> people wanting to defend their favorite solution. Instead of: "users >>> somehow want to grant different authorizations to different people" w= e >>> are deep into a solution space discussion about whether it is more >>> useful to protect the server or the client side, if the client side e= ven >>> needs protection and so on. I would like to emphasize that this is no= t >>> what U1.1 is about. Maybe we can still find a better phrasing that do= es >>> not indicate a specific solution. >>> >>> The different proposals for the phrasing of U1.1 indicate a different= >>> problem: Do we want to develop a solution that exclusively protects >>> resources or do we also want to consider the client side? Most of us = are >>> more familiar with the protection of resources because we already kno= w >>> that from web scenarios. But in these scenarios we always have a user= >>> that performs authorization on the client side. For constrained >>> environments, it is not always that simple. We might have true machin= e >>> to machine (M2M) communication where a device must decide for itself >>> whether something is authorized by its user or not. Moreover, devices= >>> might not have displays and thus it might not be possible for the use= r >>> to directly interact with the device for authorization. Solving these= >>> problems is not optional. And I think it is important to be aware of >>> these problems. A solution can decide if and how to solve them. >>> >>>> >>>> >>>> Referring to the U1.1a, I proposed to clarify what U1.1b means in te= rms >>>> of >>>> the actors and resources of the use case: >>>> (http://www.ietf.org/mail-archive/web/ace/current/msg01000.html) >>>> >>>> =E2=80=9CU1.1c: Resource Owners, such as fruit vendors and container= owners, >>>> want >>>> to >>>> grant different access rights to different parties for their respect= ive >>>> resources, such as temperatures and fan settings." >>>> >>>> >>>> This was not agreed, see discussion about resource and client below.= >>>> >>>> With regards to U1.2b, I requested that this abstract statement shou= ld >>>> be >>>> exemplified with actors and client devices from this use case to all= ow >>>> everyone to form an opinion if this is a relevant access control >>>> problem >>>> in the scope of ACE or not. If that can=E2=80=99t be made, then I th= ink this >>>> requirement is less relevant for this use case and consider leave it= >>>> out. >>> >>> Imagine a specific implementation of the container scenario where the= >>> temperature sensor is the client and the fan actuator is the server. = The >>> fruit vendor wants to make sure that the temperature sensor sends the= >>> temperature values only to authorized fan actuator resources because = she >>> doesn't want unauthorized people to gain knowledge about the state of= >>> the goods. The container owner wants to make sure that the server onl= y >>> accepts data from authorized clients. In this case, both the client >>> owner and the resource owner will need to define access policies. The= >>> client owner (the fruit vendor) defines a rule that states that the >>> client (the temperature sensor) is allowed to do a PUT on resources t= hat >>> belong to a specific container owner. The resource owner (the contain= er >>> owner) defines a rule that states that clients of a certain fruit ven= dor >>> are allowed to do a PUT on their resources. If the temperature sensor= is >>> not able to decide if a resource is authorized, it cannot enforce the= >>> authorization decisions of its owner. >>> >>>> >>>> NOTE: I=E2=80=99m not saying U1.2b is not a possible security concer= n. I=E2=80=99m >>>> questioning that it is an access control problem analogous to U1.1b.= >>>> The >>>> original requirement formulation U1.1 (in the draft) and U1.1a blurs= >>>> the >>>> distinction between resource and client and gives the impression tha= t >>>> there is an analogous client access control problem, but I don=E2=80= =99t see >>>> any >>>> evidence of that from the use cases. And the current terminology is >>>> making >>>> the distinction difficult. >>>> >>>> Now we make the same exercise in your example below. >>>> >>>>> >>>>> The question that surfaced here is whether 'principal' is the right= >>>>> term >>>>> or not. The document defines principal as "A subject who is either = a >>>>> resource owner or a client owner or both." >>>>> >>>>> Here is a slightly modified example using a door lock scenario that= >>>>> may >>>>> help us see through this case. Imagine a family with a kid: Alice, = Bob >>>>> and their young child Eve. >>>>> >>>>> Alice and Bob bought one of these Internet connected door locks and= >>>>> now >>>>> want to configure it. They want to configure it in such a way that = all >>>>> three can enter their house just using their smart phone (and a >>>>> specially loaded app). >>>>> >>>>> Whether the authorization server is included in the door lock >>>>> itself or >>>>> is part of some other home appliance does not really matter for the= >>>>> moment. In any case, Alice and Bob configure the door lock in such = a >>>>> way >>>>> that Eve is granted access. Alice and Bob are the owner of the >>>>> resource >>>>> (=3Ddoor lock) but even if they do not 'own' the door lock (but hav= e >>>>> rather rented it) does not really matter. >>>> >>>> I agree about =E2=80=9Cownership=E2=80=9D, but let=E2=80=99s keep th= e terminology in this >>>> example. >>>> >>>>> >>>>> The authorization server does not necessarily need to know that thi= s >>>>> access control policy is about "Eve". All it cares is that there is= an >>>>> entry in the access control list that points to some credential on >>>>> some >>>>> device. That credential happens to point to app on the smart phone = Eve >>>>> is using. >>>>> >>>>> Now, the question is how Eve, who is the client owner, fits into th= at >>>>> picture. She would use her phone (=3Dclient) to request access to t= he >>>>> door >>>>> but she would not be involved in provisioning the access control >>>>> policy >>>>> at the authorization server. >>>>> >>>>> Did I correctly understood this issue? >>>> >>>> I think you are correct in that the discussion is how the client own= er >>>> fits into the picture. >>> >>> I would also think that this is the problem. Eve uses her smartphone = to >>> request access to the door and is granted access depending on Alice a= nd >>> Bobs authorization. Eve has no influence on their decision. In the do= or >>> lock case this might not a big problem. Eve actively uses her smartph= one >>> to interact with the door lock. The phone might also display some kin= d >>> of dialog where Eve can decide to access the door lock or not. >>> >>> If Eve doesn't use her phone but a constrained device to access, e.g.= >>> some sort of key fob, she might want to make sure that it doesn't >>> provide her credentials to everyone who is asking. >>> >>>> >>>> Whether the phone is involved or not in transporting access control >>>> policy >>>> or other authorization information to the resource server is not the= >>>> issue. >>>> >>>> One issue we have is if the door lock can be called =E2=80=9CResourc= e=E2=80=9D or if it >>>> is >>>> completely arbitrary which is =E2=80=9CResource" and which is =E2=80= =9CClient=E2=80=9D. (I=E2=80=99m in >>>> favour of the former.) >>>> >>>> One thing we do agree about is that the tenants, Alice and Bob, shou= ld >>>> be >>>> able to set access policies for the lock. I think this is the analog= ue >>>> of >>>> U1.1b/c. But since we can=E2=80=99t agreed whether the lock is =E2=80= =9CResource" or >>>> can >>>> alternatively be =E2=80=9CClient", I can=E2=80=99t use the term =E2=80= =9CResource Owner=E2=80=9D. Nor >>>> can >>>> we use the term =E2=80=9CClient Owner=E2=80=9D. With regards to this= , I have been >>>> questioning the usefulness of the current terminology in the draft, = or >>>> how >>>> it is applied. >>> >>> In the use cases document, we are defining use cases for constrained >>> environments. Where needed, we assume CoAP as the used protocol. In C= oAP >>> we have two endpoints, the client and the server, that are communicat= ing >>> with each other. The server hosts resources that can be accessed by t= he >>> client. We could define that a door lock MUST be a CoAP server and t= hat >>> the device accessing the door lock MUST be a CoAP client or vice vers= a. >>> If there is no strong evidence to do so, I would rather not restrict >>> CoAP implementations in such a way. It seems wrong to me to say that >>> CoAP is flexible enough to allow for all kinds of settings but >>> unfortunately our authorization solution does not consider this >>> flexibility which is why CoAP is less flexible if we are using >>> authorization. >>> >>>> >>>> Maybe we can use the qualification =E2=80=9Clock-Resource" and =E2=80= =9Clock-Client" to >>>> distinguish from other resources and clients? And then =E2=80=9Clock= -Resource >>>> Owner=E2=80=9D (Alice and Bob) and =E2=80=9Clock-Client Owner=E2=80=9D= (Eve) would also be well >>>> defined? >>>> >>>> >>>> The other issue relates to what is the problem for Eve. Consider the= >>>> analogue of U1.2b above in this setting: >>>> >>>> U1.2b: "Eve wants to define for her phone if and how it is allow to >>>> request the lock to be opened." >>>> >>>> To me it is quite clear that this is an awkward way of forcing an >>>> access >>>> control problem formulation into what isn=E2=80=99t. When Eve wants = to open a >>>> lock, she presses a button in the app, thereby authorizes the reques= t. >>>> There is no need to solve this with access control policies, transpo= rt >>>> authorization information, enforcement etc. There is a natural >>>> asymmetry >>>> which is clearly illustrated in the use cases. We should not hide th= at >>>> behind strange terminology and formulations. >>> >>> Yes, exactly, Eve is authorizing the request. And in this specific >>> scenario implicit authorization (an authenticated device is authorize= d) >>> might be good enough. Since Eve can decide what her smartphone is >>> supposed to do, there is no need for more sophisticated authorization= >>> policies. This is different for other use cases. >>> >>> If you think about it, there is also no need for sophisticated >>> authorization on the door lock side, either. It might be sufficient i= f a >>> device that can be authenticated is authorized to open the door. In t= his >>> case, implicit authorization is sufficient on both sides. Again this = is >>> different for other use cases. >>> >>> Best regards, >>> Steffi >> >> >> >=20 --qJcemG4GlptSN7gfNmwpvAJkCbRMMSUsq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU+BgeAAoJEGhJURNOOiAtj4wH/28sOvD/bvK0lptCT+DVlpRT 383FSHIknhpTRl7QzWzsIYrTSNuxN2LHtekzkIrIxC8ExEDY9PGNber9V37xJoOm d/juOeodkYBLrib98lIz9Y70ZacOlvJgfQq6xelx966wIT5KeRO56+ms69NWCRQ2 EXGwTil7JnPccce4gyhtCoRhVIZHhK5PptKQk9D4f40bKrTi5ah8QRjOXl8WWge4 ZtmE30mJeYoFsV5tkiB9CVX2f6TbyasFsdqK0u9mK98BdsCRRLNJiugYP0nqfNoK akxT9RmGJ4Cg+sxWDwO8uqr61V9M7gh2pwxQmSNhqWlGJziARGQK+ZyF4Ah3nU4= =HMYk -----END PGP SIGNATURE----- --qJcemG4GlptSN7gfNmwpvAJkCbRMMSUsq-- From nobody Thu Mar 5 00:54: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 6956F1B2ABF for ; Thu, 5 Mar 2015 00:54:33 -0800 (PST) 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 mq-XWAhKt_xu for ; Thu, 5 Mar 2015 00:54:32 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 391911B2AB9 for ; Thu, 5 Mar 2015 00:54:32 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t258sRmF007323; Thu, 5 Mar 2015 09:54:27 +0100 (CET) Received: from alma.local (p5DC7E14D.dip0.t-ipconnect.de [93.199.225.77]) (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 3kyQql1ScKz2lcH; Thu, 5 Mar 2015 09:54:27 +0100 (CET) Message-ID: <54F819C1.9040409@tzi.org> Date: Thu, 05 Mar 2015 09:54:25 +0100 From: Carsten Bormann User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Hannes Tschofenig References: <54F5B1F2.6050205@gmx.net> <54F616CF.20607@tzi.de> <54F81652.6040102@tzi.de> <54F8181E.7080304@gmx.net> In-Reply-To: <54F8181E.7080304@gmx.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Stefanie Gerdes , =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= , "Ace@ietf.org" Subject: Re: [Ace] U1.2 in Use Case Document 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, 05 Mar 2015 08:54:33 -0000 > we do not want to have CoAP specific terminology in the document. While > it has to be applicable to CoAP early in the charter discussion we > wanted to also not rule out other protocols and there is nothing really > in the document that depends on CoAP. 1) should not depend on CoAP ≠ cannot use CoAP terminology. 2) Trying to be as general as possible here would amount to severe mission creep. ACE was set up to support CoAP, with a view to other protocols, not the other way around. (If there actually is another protocol that merits ignoring CoAP terminology, maybe now is the time to bring it to the table.) Grüße, Carsten From nobody Thu Mar 5 22:51: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 9F1281ACCEA for ; Thu, 5 Mar 2015 22:51:13 -0800 (PST) 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 mF4wh6G3KAuM for ; Thu, 5 Mar 2015 22:51:09 -0800 (PST) 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 BFA5E1ACCE7 for ; Thu, 5 Mar 2015 22:51:08 -0800 (PST) X-AuditID: c1b4fb2d-f79aa6d00000359d-25-54f94e5af63e Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id FD.37.13725.A5E49F45; Fri, 6 Mar 2015 07:51:06 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.70]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0210.002; Fri, 6 Mar 2015 07:51:06 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Stefanie Gerdes , Hannes Tschofenig , "Ace@ietf.org" Thread-Topic: [Ace] U1.2 in Use Case Document Thread-Index: AQHQVbL1RkiN6OYzzEyLTf3fE9ZKCp0K/GYAgAAliYCAAe0ZgIAAdKwAgAGEugA= Date: Fri, 6 Mar 2015 06:51:05 +0000 Message-ID: References: <54F5B1F2.6050205@gmx.net> <54F616CF.20607@tzi.de> <54F81652.6040102@tzi.de> In-Reply-To: <54F81652.6040102@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: <6F4D206DDA7E614283A1C371D9CF95CB@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGfG3RjfK72eIwZJGLYvv33qYLTZevMto sXTnPVYHZo/Fm/azeSxZ8pPJY9vbr8wBzFFcNimpOZllqUX6dglcGXe2rmQueHCGseLbvC7m BsYDxxm7GDk5JARMJDpPPWCBsMUkLtxbz9bFyMUhJHCEUeL/scXMEM4iRonpP6czg1SxCbhI PGh4xARiiwgUS0yd8gRskrCAjsTWvzuAbA6guK7E9fVeEKafxJ+ZMiAVLAIqEr2bt7CB2LwC FhIT1pxjhxi/jVHizoHHYEdwCqhJnFpyDqyIEeig76fWgK1iFhCXuPVkPhPEoQISS/acZ4aw RSVePv7HCmKLCuhJrLzexAYRV5JoXPKEFeQGZgFNifW79CHGWEt8fbaVFcJWlJjS/ZAd4h5B iZMzn7BMYBSfhWTbLITuWUi6ZyHpnoWkewEj6ypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2M wBg8uOW37g7G1a8dDzEKcDAq8fAaSPwMEWJNLCuuzD3EKM3BoiTOa2d8KERIID2xJDU7NbUg tSi+qDQntfgQIxMHp1QDo/emVw/vu5x3MHYV+D914bZszwd7q5z3CBdaS73lvv8vSfPaRZHf k7pmsH6X0PYTX71p6em1gqqPWqbmv5h35p5I7KIt2bd3FTA4lF87fPCcYGPw4kn8LRLXQnp2 1FY0tpS97OzM2X876WW4T3nPn47zR/6H+z1c1n1YZ/VZRe8I5z6v+9r3dimxFGckGmoxFxUn AgDppEj7ogIAAA== Archived-At: Subject: Re: [Ace] U1.2 in Use Case Document 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, 06 Mar 2015 06:51:13 -0000 SGkgU3RlZmZpLA0KDQpXZSBuZWVkIGEgdGVybWlub2xvZ3kgZm9yIGFzc2V0cyBhbmQgc3Rha2Vo b2xkZXJzIGluIHRoZSB1c2UgY2FzZXMgdG8NCmRlc2NyaWJlIHRoZSByZWxldmFudCBhY2Nlc3Mg Y29udHJvbCBwb2xpY3kgcHJvYmxlbXMgYW5kIG1ha2Ugc2VjdXJpdHkNCmNvbnNpZGVyYXRpb25z Lg0KDQpJIHByb3Bvc2UgdG8gY2FsbCBhbGwgc2Vuc29ycyBhbmQgYWN0dWF0b3JzIChvciByYXRo ZXIgYXNzZXRzIHByb3ZpZGVkIGJ5DQp0aGVzZSkg4oCcUmVzb3VyY2Vz4oCdLiBUaGlzIGFsbG93 cyBhIGRpc3RpbmN0aW9uIGJldHdlZW4gcGFydGllcyBwcm92aWRpbmcNCnRoZXNlIGFzc2V0cyBh bmQgcGFydGllcyBhY2Nlc3NpbmcgdGhlc2UgYXNzZXRzLiBJbiB0aGlzIHdheSB3ZSBjYW4NCmRp c2N1c3MgdGhlIGFjY2VzcyBjb250cm9sIHBvbGljaWVzIG9uIHRoZSBhc3NldCBwcm92aWRpbmcg c2lkZSB3aXRob3V0DQpmb3JjaW5nIGFuIGFjY2VzcyBjb250cm9sIHBvbGljeSBwcm9ibGVtIG9u dG8gd2hhdCBpc27igJl0LCBvbiB0aGUgYXNzZXQNCmFjY2Vzc2luZyBzaWRlLg0KDQpJcyB0aGlz IHNvbWVob3cgY29udHJhZGljdGluZyBhIHNvbHV0aW9uIGJhc2VkIG9uIENvQVA/DQoNCklmIHNv LCB3aHkgaXNuJ3QgdGhlcmUgYW4gYXNzb2NpYXRlZCBjb250cmFkaWN0aW9uIGJldHdlZW4gT0F1 dGggYW5kIEhUVFA/DQooT3IgaXMgdGhlcmU/KQ0KDQoNCkJlc3QgcmVnYXJkcywNCkfDtnJhbg0K DQoNCk9uIDIwMTUtMDMtMDUgMDk6MzksICJTdGVmYW5pZSBHZXJkZXMiIDxnZXJkZXNAdHppLmRl PiB3cm90ZToNCg0KPkhpIEfDtnJhbiwNCj4NCj5pZiB3ZSB1c2UgYW55IGtpbmQgb2Ygc29sdXRp b24gc3BlY2lmaWMgdGVybWlub2xvZ3kgaW4gdGhlIGRyYWZ0LCB3ZQ0KPm11c3QgdXNlIENvQVAg dGVybWlub2xvZ3kgc2luY2Ugd2Ugd2FudCB0byBmaW5kIGFuIGF1dGhvcml6YXRpb24NCj5zb2x1 dGlvbiB0aGF0IGZpdHMgdG8gQ29BUC4NCj4NCj5ZZXMsIEkgYWdyZWUgdGhhdCB0ZXJtaW5vbG9n eSBhbmQgcHJvYmxlbSBzdGF0ZW1lbnQgbmVlZCB0byBiZSBjbGVhci4NCj5CdXQgdGhleSBuZWVk IHRvIGZpdCB0byB0aGUgcHJvYmxlbSwgbm90IHRvIHRoZSBzb2x1dGlvbi4NCj4NCj5JIGFtIHBy ZXR0eSBzdXJlIHRoYXQgd2Ugd2lsbCBmaW5kIG91dCBob3cgYSBzb2x1dGlvbiBjYW4gYmUgbWFw cGVkIHRvDQo+dGhlIHVzZSBjYXNlcy4gQnV0IGlmIHRoZSB1c2UgY2FzZXMgZG9jdW1lbnQgZG9u J3QgcmVmbGVjdCBob3cgdGhpbmdzDQo+d29yayBpbiBDb0FQLCBJIGRvbid0IHRoaW5rIHdlIHdp bGwgYmUgYWJsZSB0byBmaW5kIGEgZml0dGluZyBzb2x1dGlvbi4NCj4NCj5CZXN0IHJlZ2FyZHMs DQo+U3RlZmZpDQo+DQo+DQo+T24gMDMvMDUvMjAxNSAwMTo0MiBBTSwgR8O2cmFuIFNlbGFuZGVy IHdyb3RlOg0KPj4gSGkgU3RlZmZpIGFuZCBhbGwsDQo+Pg0KPj4NCj4+IFRyeWluZyB0byBjYXRj aCB1cCB3aXRoIHRoZSBtYWlscy4gSSBqdXN0IHN1bW1hcml6ZSBzb21lIGNvbW1lbnRzIG9uDQo+ PnRoaXMNCj4+IG1haWwgZm9yIG5vdy4NCj4+DQo+PiBUZXJtaW5vbG9neSBhbmQgcHJvYmxlbSBz dGF0ZW1lbnQNCj4+IC0gLSAtDQo+PiBDdXJyZW50IHRlcm1pbm9sb2d5LCBvciBob3cgaXQgaXMg YXBwbGllZCwgaXMgdW5zYXRpc2ZhY3RvcnksIGFzIEnigJl2ZQ0KPj4gcmUtaXRlcmF0ZWQgYSBj b3VwbGUgb2YgdGltZXMuIEnigJl2ZSBwcmV2aW91c2x5IGJlZW4gd29ya2luZyBpbiBsYXJnZQ0K Pj4gcHJvamVjdHMgd2hlcmUgdGVybWlub2xvZ3kgYW5kIHByb2JsZW0gc3RhdGVtZW50IHdhcyB1 bmNsZWFyIGFuZCBpdCBpcw0KPj5hbg0KPj4gYWJzb2x1dGUgd2FzdGUgb2YgdGltZS4gSSB0aGlu ayBvdGhlcnMgaW4gdGhpcyBncm91cCBoYXZpbmcgc2ltaWxhcg0KPj4gZXhwZXJpZW5jZXMgY2Fu IGNvbmZpcm0gdGhpcy4NCj4+DQo+Pg0KPj4gV2UgaGF2ZSBkaWZmZXJlbnQgb3B0aW9ucyB0byBy ZXNvbHZlIHRoaXMuDQo+Pg0KPj4gMS4gV2UgY2FuIHJlbW92ZSByb2xlIHRlcm1pbm9sb2d5IGZy b20gdGhlIHVzZSBjYXNlIGRyYWZ0IGFuZCBleHByZXNzDQo+PnRoZQ0KPj4gcHJvYmxlbXMgaW4g dGVybXMgb2YgdGhlIGFjdG9ycyBpbiB0aGUgdXNlIGNhc2VzLiBFLmcuICJmcnVpdCB2ZW5kb3Jz DQo+PndhbnQNCj4+IHRvIGdyYW50IGRpZmZlcmVudCBhY2Nlc3MgcmlnaHRzIHRvIGRpZmZlcmVu dCBwYXJ0aWVzIHRvIG1lYXN1cmVtZW50cyBvZg0KPj4gZ29vZHPigJkgdGVtcGVyYXR1cmVzIi4g VGhhdCB3b3VsZCBzYXZlIHRoZSB1c2UgY2FzZSBkb2N1bWVudCwgYnV0IGluIHRoaXMNCj4+IGNh c2Ugd2UgZG9u4oCZdCBoYXZlIGEgZ2VuZXJhbCBwcm9ibGVtIHN0YXRlbWVudCBpbiB0ZXJtcyBv ZiByb2xlcywgYW5kDQo+PnRoYXQNCj4+IHRoZW4gYmVjb21lcyB0aGVuIG91ciBuZXh0IGNoYWxs ZW5nZS4NCj4+DQo+PiAyLiBJZiB3ZSBpbnN0ZWFkIGRlZmluZSByb2xlcyAoUmVzb3VyY2UgU2Vy dmVyLCBDbGllbnQgZXRjLikgdGhlbiB3ZQ0KPj5tdXN0DQo+PiBiZSBhYmxlIHRvIGV4cHJlc3Mg dGhlIHJlbGV2YW50IHByb2JsZW1zIGJhc2VkIG9uIHRoZSB1c2UgY2FzZXMgaW4gdGVybXMNCj4+ IG9mIHRoZSByb2xlcyBkZWZpbmVkLiBPdGhlcndpc2UgdGhlIHJvbGUgZGVmaW5pdGlvbnMgYXJl IG5vdCBnb29kDQo+PmVub3VnaC4NCj4+IEZvciBleGFtcGxlICJSZXNvdXJjZSBPd25lcnMsIHN1 Y2ggYXMgZnJ1aXQgdmVuZG9ycywgd2FudHMgdG8gZ3JhbnQNCj4+IGRpZmZlcmVudCBhY2Nlc3Mg cmlnaHRzIHRvIGRpZmZlcmVudCBwYXJ0aWVzIGZvciB0aGVpciByZXNvdXJjZXMsIHN1Y2gNCj4+ YXMNCj4+IHRlbXBlcmF0dXJlcyINCj4+DQo+PiBJZiB3ZSBjYW7igJl0IGV4cHJlc3Mgd2hhdCBh cmUgdGhlIGFzc2V0cyBhbmQgdGhlIHN0YWtlaG9sZGVycyBpbiBhIHdlbGwNCj4+IGRlZmluZWQg d2F5LCBzbyB0aGF0IHdlIGNhbiBmb3JtdWxhdGUgdGhlIHByb2JsZW0gc3RhdGVtZW50IGluIHRl cm1zIG9mDQo+PiB0aGVzZSwgdGhlbiB3ZSBoYXZlIGEgc2VyaW91cyBwcm9ibGVtLiBJIGFkdm9j YXRlIHRoYXQgd2UgYWRvcHQgYW4NCj4+IGVzdGFibGlzaGVkIHRlcm1pbm9sb2d5IHN1Y2ggYXMg T0F1dGggb3IgVU1BLiBXaGF0ZXZlciBjbGllbnQgYXNwZWN0cyB3ZQ0KPj4gd2FudCB0byBmb3Jt dWxhdGUgY2FuIHN1cmVseSBiZSBleHByZXNzZWQgaW4gYW55IG9mIHRoZXNlIHRlcm1pbm9sb2d5 Lg0KPj4NCj4+IFNvbWUgY29udHJvbCBxdWVzdGlvbnMgb24gaG93IGZhciB3ZSBoYXZlIHJlYWNo ZWQgaW4gdGhpcyB3b3JrOg0KPj4NCj4+IC0gSW4gdGhlIGNvbnRhaW5lciB1c2UgY2FzZSwgY2Fu IHdlIGFncmVlIHRoYXQgdGhlIHRlbXBlcmF0dXJlIHNlbnNvcnMNCj4+YW5kDQo+PiBmYW4gYWN0 dWF0b3JzIGFyZSB0aGUgbWFpbiDigJxpdGVtcyBvZiBpbnRlcmVzdOKAnS4NCj4+DQo+PiAtIENh biB3ZSBkZW5vdGUgdGhlIHRlbXBlcmF0dXJlIHNlbnNvciBhbmQgZmFuIGFjdHVhdG9ycyDigJxS ZXNvdXJjZXPigJ0/DQo+Pg0KPj4gLSBDYW4gd2UsIGFzIEV2ZSBwcm9wb3NlZCwgYWdyZWUgdG8g dmlldyB0aGUgdGVtcGVyYXR1cmUgc2Vuc29yIC0gZmFuDQo+PiBhY3R1YXRvciBpbnRlcmFjdGlv biBhcyB0d28gb25lLXdheSByZWxhdGlvbnNoaXBzLCBpLmUuIHRoZXJlIGFyZQ0KPj4gdGVtcGVy YXR1cmUtcmVzb3VyY2VzIGFuZCB0ZW1wZXJhdHVyZS1jbGllbnRzLCBhcyB3ZWxsIGFzIGZhbi1y ZXNvdXJjZXMNCj4+IGFuZCBmYW4tY2xpZW50cyAoc29tZSBvZiB3aGljaCBtYXkgYmUgY28tbG9j YXRlZCkuDQo+Pg0KPj4gKE1heWJlIHdlIGNhbiB0aGVuIGF2b2lkIGZvcm11bGF0aW9ucyBzdWNo IGFzICJJZiB0aGUgdGVtcGVyYXR1cmUgc2Vuc29yDQo+PiBpcyBub3QgYWJsZSB0byBkZWNpZGUg aWYgYSByZXNvdXJjZSBpcyBhdXRob3JpemVk4oCdPyBTZWUgZnVydGhlciBkb3duIGluDQo+PiB0 aGlzIG1haWwuKQ0KPj4NCj4+DQo+Pg0KPj4gQ29uc3RyYWluZWQgY2xpZW50cw0KPj4gLSAtIC0N Cj4+IE9uZSByZWN1cnJpbmcgdGhlbWUgaW4gdGhpcyBkaXNjdXNzaW9uIGhhcyBiZWVuIG9uIGNv bnN0cmFpbmVkIGNsaWVudA0KPj4gZGV2aWNlcy4gIFRoZXJlIGlzIGEgcXVlc3Rpb24gYWJvdXQg d2hhdCBraW5kIG9mICJhdXRob3JpemF0aW9uDQo+PnByb2JsZW1z4oCdDQo+PiB0aGF0IGFyZSBy ZWxldmFudCB0byB0aGUgY2xpZW50IGRldmljZS4gSXQgaXMgbWFpbmx5IHJlbGF0ZWQgdG8gYXNw ZWN0cw0KPj5vZg0KPj4gYSBjbGllbnQgZGlzY2xvc2luZyBhIHJlcXVlc3QuIFRoZXJlIGhhcyBi ZWVuIHJlcGVhdGVkIGNsYWltcyBhYm91dCB0aGUNCj4+IG5lZWQgZm9yIHNvcGhpc3RpY2F0ZWQg YWNjZXNzIGNvbnRyb2wgcG9saWNpZXMgb24gdGhlIGNsaWVudCBzaWRlLCBpbg0KPj50aGUNCj4+ IHNlbnNlIHRoYXQgdGhlIGNsaWVudCBhY3Rpb25zLCBzdWNoIGFzIG1ha2luZyBhIHJlcXVlc3Qs IG5lZWQgdG8gYmUNCj4+IHN1YmplY3QgdG8gYWNjZXNzIGNvbnRyb2wgcG9saWNpZXMsIGp1c3Qg YmVjYXVzZSB0aGUgZGV2aWNlcyBhcmUNCj4+IGNvbnN0cmFpbmVkLiBCdXQgbm93aGVyZSBpbiB0 aGUgdXNlIGNhc2UgZG9jdW1lbnQgaXMgdGhpcyBjbGFpbQ0KPj4gc3Vic3RhbnRpYXRlZCwgaS5l LiB0aGF0IGEgcGFydGljdWxhciB1c2UgY2FzZSBpcyByZXF1aXJpbmcgc3VjaCBhDQo+PiBmZWF0 dXJlLiBUaGVyZSBhcmUgb25seSBhYnN0cmFjdCBmb3JtdWxhdGlvbnMgYWJvdXQgcHJpbmNpcGFs cywgYW5kDQo+PiBpbnRlcnByZXRlZCBhcyByZXNvdXJjZSBvd25lciBhcyB3ZWxsIGFzIGNsaWVu dCBvd25lcnMuIFRoZSBtb3RpdmF0aW9uDQo+PmZvcg0KPj4gdGhhdCBoYXMgYmVlbiB0aGF0IGlm IHdlIGRlc2NyaWJlIHRoZSB1c2UgY2FzZSBpbiB0b28gbXVjaCBkZXRhaWwgaXQNCj4+IGJlY29t ZXMgc29sdXRpb24gc3BlY2lmaWMuIEFuIGFsdGVybmF0aXZlIGV4cGxhbmF0aW9uIGlzIHRoYXQg b25seSBmZXcsDQo+PmlmDQo+PiBhbnksIG9mIHRoZSB1c2UgY2FzZXMgYWN0dWFsbHkgcmVxdWly ZSBjbGllbnQgc2lkZSBhY2Nlc3MgY29udHJvbA0KPj5wb2xpY2llcy4NCj4+DQo+PiBJIHRoaW5r IHdlIHNob3VsZCBkZXRhY2ggYW55IHBvdGVudGlhbCBhY2Nlc3MgY29udHJvbCBwb2xpY3kgcHJv YmxlbXMgb2YNCj4+IHRoZSBjbGllbnQgZnJvbSB0aGF0IHJlbGF0ZWQgdG8gcmVzb3VyY2UgYWNj ZXNzLCBiZWNhdXNlIGl0IGlzDQo+PmRpZmZlcmVudCwNCj4+IGl0IGlzIG5vdCBkb2N1bWVudGVk IHRvIGJlIHJlbGV2YW50LCBhbmQgaXQgaXMgYW4gaW5kZXBlbmRlbnQgcHJvYmxlbQ0KPj50aGF0 DQo+PiBtYWtlcyB0aGUgcHJvYmxlbSBmb3JtdWxhdGlvbiBjb21wbGV4LiBGdXJ0aGVybW9yZSwg bm8gb25lIGFjdHVhbGx5DQo+Pmtub3dzDQo+PiBhYm91dCB0aGUgbmVlZCBhbmQgbmF0dXJlIG9m IHBvbGljaWVzIGZvciBpbiB0aGVzZSBzaXR1YXRpb25zLiBJdCBpcw0KPj5wdXJlDQo+PiBzcGVj dWxhdGlvbnMuIEkgdGhpbmsgdGhhdCBpZiBhbnl0aGluZywgc29tZSBzb3J0IG9mICJkZWNpc2lv biBwb2xpY2llc+KAnQ0KPj4gY291bGQgcG90ZW50aWFsbHkgYmUgdXNlZnVsLiBGb3JtdWxhdGlu ZyBpdCBhcyBhY2Nlc3MgY29udHJvbCBwcm9ibGVtDQo+PiBsZWFkcyB0byB2ZXJ5IHN0cmFuZ2Ug c3RhdGVtZW50cyBhcyBJIHNob3dlZCBhdCB0aGUgZW5kIG9mIHRoaXMgbWFpbDoNCj4+IGh0dHA6 Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9hY2UvY3VycmVudC9tc2cwMTAxOS5odG1s DQo+Pg0KPj4NCj4+IE1vcmUgbGF0ZXIuDQo+Pg0KPj4gQmVzdCByZWdhcmRzLA0KPj4gR8O2cmFu DQo+Pg0KPj4NCj4+DQo+PiBPbiAyMDE1LTAzLTAzIDIxOjE3LCAiU3RlZmFuaWUgR2VyZGVzIiA8 Z2VyZGVzQHR6aS5kZT4gd3JvdGU6DQo+Pg0KPj4+IEhpIGFsbCwNCj4+Pg0KPj4+IE9uIDAzLzAz LzIwMTUgMDY6MDMgUE0sIEfDtnJhbiBTZWxhbmRlciB3cm90ZToNCj4+Pj4gSGkgSGFubmVzLA0K Pj4+Pg0KPj4+PiBPbiAyMDE1LTAzLTAzIDE0OjA2LCAiSGFubmVzIFRzY2hvZmVuaWciIDxoYW5u ZXMudHNjaG9mZW5pZ0BnbXgubmV0Pg0KPj4+PiB3cm90ZToNCj4+Pj4NCj4+Pj4+IEhpIGFsbCwN Cj4+Pj4+DQo+Pj4+PiBsZXQgbWUgdHJ5IHRvIHNlZSB3aGV0aGVyIEkgdW5kZXJzdGFuZCB0aGUg aXNzdWUgdGhhdCdzIGN1cnJlbnRseQ0KPj4+Pj51bmRlcg0KPj4+Pj4gZGlzY3Vzc2lvbi4NCj4+ Pj4+DQo+Pj4+PiBJdCBzZWVtcyB0aGF0IHRoZSBkZWJhdGUgZm9jdXNlcyBvbiB0aGlzIHJlcXVp cmVtZW50IGZyb20gdGhlDQo+Pj4+PiAnQ29udGFpbmVyDQo+Pj4+PiBtb25pdG9yaW5nJyB1c2Ug Y2FzZToNCj4+Pj4+DQo+Pj4+PiAiDQo+Pj4+PiAgICAgbyAgVTEuMiBQcmluY2lwYWxzIHdhbnQg dG8gZ3JhbnQgZGlmZmVyZW50IGFjY2VzcyByaWdodHMgZm9yDQo+Pj4+PiAgICAgICAgZGlmZmVy ZW50IHJlc291cmNlcyBvbiBhbiBlbmRwb2ludC4NCj4+Pj4+ICINCj4+Pj4NCj4+Pj4gQWN0dWFs bHksIHdlIGFyZSBub3QgZGViYXRpbmcgdGhpcyBVMS4yIHJlcXVpcmVtZW50LiBTdGVmZmkgbWFk ZSBhIG5ldw0KPj4+PiBzZXQNCj4+Pj4gb2YgcmVxdWlyZW1lbnRzLCBzZWUNCj4+Pj4gaHR0cDov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2FjZS9jdXJyZW50L21zZzAwOTgyLmh0bWwN Cj4+Pj4NCj4+Pj4gVGhlIGRlYmF0ZSBmb2N1c2VkIG9uIHRoaXMgcmVxdWlyZW1lbnQgcHJvcG9z ZWQgYnkgU3RlZmZpOg0KPj4+Pg0KPj4+PiAiVTEuMWEgUHJpbmNpcGFscyBzdWNoIGFzIHRoZSBm cnVpdCB2ZW5kb3IsIHRoZSB0cmFuc2xvYWRpbmcgcGVyc29ubmVsDQo+Pj4+IG9yDQo+Pj4+IHRo ZSBjb250YWluZXIgb3duZXJzIHdhbnQgdG8gZGVmaW5lIGF1dGhvcml6YXRpb25zIGZvciB0aGVp ciByZXNvdXJjZXMNCj4+Pj4gYW5kIGVuZHBvaW50cy4iDQo+Pj4+DQo+Pj4+IChJIGluc2VydCDi gJxh4oCdLCDigJxi4oCdLCDigJxj4oCdIGV0Yy4gdG8gZGlzdGluZ3Vpc2ggdGhlIGRpZmZlcmVu dCB2ZXJzaW9ucyBvZg0KPj4+PiByZXF1aXJlbWVudHMpDQo+Pj4+DQo+Pj4+DQo+Pj4+IFRoZW4g U3RlZmZpIHByb3Bvc2VkIHRvIHNwbGl0IFUxLjFhIGluIHRoZXNlIHJlcXVpcmVtZW50czoNCj4+ Pj4NCj4+Pj4gKGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9hY2UvY3VycmVu dC9tc2cwMDk5Mi5odG1sKQ0KPj4+Pg0KPj4+Pg0KPj4+PiDigJxVMS4xYjogUmVzb3VyY2UgT3du ZXJzIHdhbnQgdG8gZ3JhbnQgZGlmZmVyZW50IGFjY2VzcyByaWdodHMgZm9yDQo+Pj4+dGhlaXIN Cj4+Pj4gcmVzb3VyY2VzIHRvIGRpZmZlcmVudCBwYXJ0aWVzLg0KPj4+Pg0KPj4+PiBVMS4yYjog Q2xpZW50IE93bmVycyB3YW50IHRvIGRlZmluZSBmb3IgdGhlaXIgY2xpZW50cyBpZiBhbmQgaG93 IHRoZXkNCj4+Pj4gYXJlDQo+Pj4+IGFsbG93ZWQgdG8gYWNjZXNzIHJlc291cmNlcyBob3N0ZWQg b24gYSBSZXNvdXJjZSBTZXJ2ZXIuIg0KPj4+DQo+Pj4gSW4gZmFjdCBJIGRpZG4ndCB3YW50IHRv IHNwbGl0IFUxLjFhLiBZb3UsIEfDtnJhbiwgcHJvcG9zZWQgaW4NCj4+PiBodHRwOi8vd3d3Lmll dGYub3JnL21haWwtYXJjaGl2ZS93ZWIvYWNlL2N1cnJlbnQvbXNnMDA5OTEuaHRtbCB0bw0KPj4+ IHJlcGxhY2UgVTEuMSB3aXRoIHR3byAicmVxdWlyZW1lbnRzIiBhcyB5b3UgY2FsbGVkIHRoZW0u IEkgYW0gbm90IGhhcHB5DQo+Pj4gd2l0aCB0aGlzIHByb3Bvc2FsIGJ1dCB3b3VsZCBoYXZlIGFn cmVlZCB0byBpdCBpZiBpdCBoZWxwZWQgdGhpbmdzLg0KPj4+DQo+Pj4gVGhlIG1lYW5pbmcgb2Yg dGhlIG9yaWdpbmFsIFUxLjEgcHJvYmxlbSBpcyB0aGF0IHByaW5jaXBhbHMgaW4gdGhpcyB1c2UN Cj4+PiBjYXNlIHdhbnQgdG8gZ3JhbnQgZGlmZmVyZW50IGF1dGhvcml6YXRpb25zIHRvIGRpZmZl cmVudCBwZW9wbGUgLw0KPj4+IGRldmljZXMgLyByZXNvdXJjZXMgKG1lYW5pbmcgdGhhdCBkZXZp Y2VzIG9mIGNvbXBhbnkgQSBnZXQgZGlmZmVyZW50DQo+Pj4gYWNjZXNzIHJpZ2h0cyB0aGVuIGRl dmljZXMgb2YgY29tcGFueSBCKS4gSXQgc2VlbXMgdGhhdCBpdCBpcyBxdWl0ZQ0KPj4+IGRpZmZp Y3VsdCB0byBmaW5kIGEgbmV1dHJhbCBwaHJhc2luZyBmb3IgdGhpcyBwcm9ibGVtLg0KPj4+DQo+ Pj4gVGhlIHNwbGl0IG5vdyBzaG93cyBhIGNvbXBsZXRlbHkgZGlmZmVyZW50IGFzcGVjdCBvZiB0 aGlzIHByb2JsZW06IHdlDQo+Pj4gY2FuIHByb3RlY3QgdGhlIGNsaWVudCBzaWRlIG9yIHdlIGNh biBwcm90ZWN0IHRoZSBzZXJ2ZXIgc2lkZSBvciBib3RoLg0KPj4+IFRoZXNlIHJlYWxseSBhcmUg c29sdXRpb24gc3BlY2lmaWMgYW5kIGFzIHdlIGNhbiBzZWUsIHRoaXMgbGVhZHMgdG8NCj4+PiBw ZW9wbGUgd2FudGluZyB0byBkZWZlbmQgdGhlaXIgZmF2b3JpdGUgc29sdXRpb24uIEluc3RlYWQg b2Y6ICJ1c2Vycw0KPj4+IHNvbWVob3cgd2FudCB0byBncmFudCBkaWZmZXJlbnQgYXV0aG9yaXph dGlvbnMgdG8gZGlmZmVyZW50IHBlb3BsZSIgd2UNCj4+PiBhcmUgZGVlcCBpbnRvIGEgc29sdXRp b24gc3BhY2UgZGlzY3Vzc2lvbiBhYm91dCB3aGV0aGVyIGl0IGlzIG1vcmUNCj4+PiB1c2VmdWwg dG8gcHJvdGVjdCB0aGUgc2VydmVyIG9yIHRoZSBjbGllbnQgc2lkZSwgaWYgdGhlIGNsaWVudCBz aWRlDQo+Pj5ldmVuDQo+Pj4gbmVlZHMgcHJvdGVjdGlvbiBhbmQgc28gb24uIEkgd291bGQgbGlr ZSB0byBlbXBoYXNpemUgdGhhdCB0aGlzIGlzIG5vdA0KPj4+IHdoYXQgVTEuMSBpcyBhYm91dC4g TWF5YmUgd2UgY2FuIHN0aWxsIGZpbmQgYSBiZXR0ZXIgcGhyYXNpbmcgdGhhdCBkb2VzDQo+Pj4g bm90IGluZGljYXRlIGEgc3BlY2lmaWMgc29sdXRpb24uDQo+Pj4NCj4+PiBUaGUgZGlmZmVyZW50 IHByb3Bvc2FscyBmb3IgdGhlIHBocmFzaW5nIG9mIFUxLjEgaW5kaWNhdGUgYSBkaWZmZXJlbnQN Cj4+PiBwcm9ibGVtOiBEbyB3ZSB3YW50IHRvIGRldmVsb3AgYSBzb2x1dGlvbiB0aGF0IGV4Y2x1 c2l2ZWx5IHByb3RlY3RzDQo+Pj4gcmVzb3VyY2VzIG9yIGRvIHdlIGFsc28gd2FudCB0byBjb25z aWRlciB0aGUgY2xpZW50IHNpZGU/IE1vc3Qgb2YgdXMNCj4+PmFyZQ0KPj4+IG1vcmUgZmFtaWxp YXIgd2l0aCB0aGUgcHJvdGVjdGlvbiBvZiByZXNvdXJjZXMgYmVjYXVzZSB3ZSBhbHJlYWR5IGtu b3cNCj4+PiB0aGF0IGZyb20gd2ViIHNjZW5hcmlvcy4gQnV0IGluIHRoZXNlIHNjZW5hcmlvcyB3 ZSBhbHdheXMgaGF2ZSBhIHVzZXINCj4+PiB0aGF0IHBlcmZvcm1zIGF1dGhvcml6YXRpb24gb24g dGhlIGNsaWVudCBzaWRlLiBGb3IgY29uc3RyYWluZWQNCj4+PiBlbnZpcm9ubWVudHMsIGl0IGlz IG5vdCBhbHdheXMgdGhhdCBzaW1wbGUuIFdlIG1pZ2h0IGhhdmUgdHJ1ZSBtYWNoaW5lDQo+Pj4g dG8gbWFjaGluZSAoTTJNKSBjb21tdW5pY2F0aW9uIHdoZXJlIGEgZGV2aWNlIG11c3QgZGVjaWRl IGZvciBpdHNlbGYNCj4+PiB3aGV0aGVyIHNvbWV0aGluZyBpcyBhdXRob3JpemVkIGJ5IGl0cyB1 c2VyIG9yIG5vdC4gTW9yZW92ZXIsIGRldmljZXMNCj4+PiBtaWdodCBub3QgaGF2ZSBkaXNwbGF5 cyBhbmQgdGh1cyBpdCBtaWdodCBub3QgYmUgcG9zc2libGUgZm9yIHRoZSB1c2VyDQo+Pj4gdG8g ZGlyZWN0bHkgaW50ZXJhY3Qgd2l0aCB0aGUgZGV2aWNlIGZvciBhdXRob3JpemF0aW9uLiBTb2x2 aW5nIHRoZXNlDQo+Pj4gcHJvYmxlbXMgaXMgbm90IG9wdGlvbmFsLiBBbmQgSSB0aGluayBpdCBp cyBpbXBvcnRhbnQgdG8gYmUgYXdhcmUgb2YNCj4+PiB0aGVzZSBwcm9ibGVtcy4gQSBzb2x1dGlv biBjYW4gZGVjaWRlIGlmIGFuZCBob3cgdG8gc29sdmUgdGhlbS4NCj4+Pg0KPj4+Pg0KPj4+Pg0K Pj4+PiBSZWZlcnJpbmcgdG8gdGhlIFUxLjFhLCBJIHByb3Bvc2VkIHRvIGNsYXJpZnkgd2hhdCBV MS4xYiBtZWFucyBpbg0KPj4+PnRlcm1zDQo+Pj4+IG9mDQo+Pj4+IHRoZSBhY3RvcnMgYW5kIHJl c291cmNlcyBvZiB0aGUgdXNlIGNhc2U6DQo+Pj4+IChodHRwOi8vd3d3LmlldGYub3JnL21haWwt YXJjaGl2ZS93ZWIvYWNlL2N1cnJlbnQvbXNnMDEwMDAuaHRtbCkNCj4+Pj4NCj4+Pj4g4oCcVTEu MWM6IFJlc291cmNlIE93bmVycywgc3VjaCBhcyBmcnVpdCB2ZW5kb3JzIGFuZCBjb250YWluZXIg b3duZXJzLA0KPj4+PiB3YW50DQo+Pj4+IHRvDQo+Pj4+IGdyYW50IGRpZmZlcmVudCBhY2Nlc3Mg cmlnaHRzIHRvIGRpZmZlcmVudCBwYXJ0aWVzIGZvciB0aGVpcg0KPj4+PnJlc3BlY3RpdmUNCj4+ Pj4gcmVzb3VyY2VzLCBzdWNoIGFzIHRlbXBlcmF0dXJlcyBhbmQgZmFuIHNldHRpbmdzLiINCj4+ Pj4NCj4+Pj4NCj4+Pj4gVGhpcyB3YXMgbm90IGFncmVlZCwgc2VlIGRpc2N1c3Npb24gYWJvdXQg cmVzb3VyY2UgYW5kIGNsaWVudCBiZWxvdy4NCj4+Pj4NCj4+Pj4gV2l0aCByZWdhcmRzIHRvIFUx LjJiLCBJIHJlcXVlc3RlZCB0aGF0IHRoaXMgYWJzdHJhY3Qgc3RhdGVtZW50IHNob3VsZA0KPj4+ PiBiZQ0KPj4+PiBleGVtcGxpZmllZCB3aXRoIGFjdG9ycyBhbmQgY2xpZW50IGRldmljZXMgZnJv bSB0aGlzIHVzZSBjYXNlIHRvIGFsbG93DQo+Pj4+IGV2ZXJ5b25lIHRvIGZvcm0gYW4gb3Bpbmlv biBpZiB0aGlzIGlzIGEgcmVsZXZhbnQgYWNjZXNzIGNvbnRyb2wNCj4+Pj5wcm9ibGVtDQo+Pj4+ IGluIHRoZSBzY29wZSBvZiBBQ0Ugb3Igbm90LiBJZiB0aGF0IGNhbuKAmXQgYmUgbWFkZSwgdGhl biBJIHRoaW5rIHRoaXMNCj4+Pj4gcmVxdWlyZW1lbnQgaXMgbGVzcyByZWxldmFudCBmb3IgdGhp cyB1c2UgY2FzZSBhbmQgY29uc2lkZXIgbGVhdmUgaXQNCj4+Pj4gb3V0Lg0KPj4+DQo+Pj4gSW1h Z2luZSBhIHNwZWNpZmljIGltcGxlbWVudGF0aW9uIG9mIHRoZSBjb250YWluZXIgc2NlbmFyaW8g d2hlcmUgdGhlDQo+Pj4gdGVtcGVyYXR1cmUgc2Vuc29yIGlzIHRoZSBjbGllbnQgYW5kIHRoZSBm YW4gYWN0dWF0b3IgaXMgdGhlIHNlcnZlci4NCj4+PlRoZQ0KPj4+IGZydWl0IHZlbmRvciB3YW50 cyB0byBtYWtlIHN1cmUgdGhhdCB0aGUgdGVtcGVyYXR1cmUgc2Vuc29yIHNlbmRzIHRoZQ0KPj4+ IHRlbXBlcmF0dXJlIHZhbHVlcyBvbmx5IHRvIGF1dGhvcml6ZWQgZmFuIGFjdHVhdG9yIHJlc291 cmNlcyBiZWNhdXNlDQo+Pj5zaGUNCj4+PiBkb2Vzbid0IHdhbnQgdW5hdXRob3JpemVkIHBlb3Bs ZSB0byBnYWluIGtub3dsZWRnZSBhYm91dCB0aGUgc3RhdGUgb2YNCj4+PiB0aGUgZ29vZHMuIFRo ZSBjb250YWluZXIgb3duZXIgd2FudHMgdG8gbWFrZSBzdXJlIHRoYXQgdGhlIHNlcnZlciBvbmx5 DQo+Pj4gYWNjZXB0cyBkYXRhIGZyb20gYXV0aG9yaXplZCBjbGllbnRzLiBJbiB0aGlzIGNhc2Us IGJvdGggdGhlIGNsaWVudA0KPj4+IG93bmVyIGFuZCB0aGUgcmVzb3VyY2Ugb3duZXIgd2lsbCBu ZWVkIHRvIGRlZmluZSBhY2Nlc3MgcG9saWNpZXMuIFRoZQ0KPj4+IGNsaWVudCBvd25lciAodGhl IGZydWl0IHZlbmRvcikgZGVmaW5lcyBhIHJ1bGUgdGhhdCBzdGF0ZXMgdGhhdCB0aGUNCj4+PiBj bGllbnQgKHRoZSB0ZW1wZXJhdHVyZSBzZW5zb3IpIGlzIGFsbG93ZWQgdG8gZG8gYSBQVVQgb24g cmVzb3VyY2VzDQo+Pj50aGF0DQo+Pj4gYmVsb25nIHRvIGEgc3BlY2lmaWMgY29udGFpbmVyIG93 bmVyLiBUaGUgcmVzb3VyY2Ugb3duZXIgKHRoZSBjb250YWluZXINCj4+PiBvd25lcikgZGVmaW5l cyBhIHJ1bGUgdGhhdCBzdGF0ZXMgdGhhdCBjbGllbnRzIG9mIGEgY2VydGFpbiBmcnVpdA0KPj4+ dmVuZG9yDQo+Pj4gYXJlIGFsbG93ZWQgdG8gZG8gYSBQVVQgb24gdGhlaXIgcmVzb3VyY2VzLiBJ ZiB0aGUgdGVtcGVyYXR1cmUgc2Vuc29yDQo+Pj5pcw0KPj4+IG5vdCBhYmxlIHRvIGRlY2lkZSBp ZiBhIHJlc291cmNlIGlzIGF1dGhvcml6ZWQsIGl0IGNhbm5vdCBlbmZvcmNlIHRoZQ0KPj4+IGF1 dGhvcml6YXRpb24gZGVjaXNpb25zIG9mIGl0cyBvd25lci4NCj4+Pg0KPj4+Pg0KPj4+PiBOT1RF OiBJ4oCZbSBub3Qgc2F5aW5nIFUxLjJiIGlzIG5vdCBhIHBvc3NpYmxlIHNlY3VyaXR5IGNvbmNl cm4uIEnigJltDQo+Pj4+IHF1ZXN0aW9uaW5nIHRoYXQgaXQgaXMgYW4gYWNjZXNzIGNvbnRyb2wg cHJvYmxlbSBhbmFsb2dvdXMgdG8gVTEuMWIuDQo+Pj4+VGhlDQo+Pj4+IG9yaWdpbmFsIHJlcXVp cmVtZW50IGZvcm11bGF0aW9uIFUxLjEgKGluIHRoZSBkcmFmdCkgYW5kIFUxLjFhIGJsdXJzDQo+ Pj4+dGhlDQo+Pj4+IGRpc3RpbmN0aW9uIGJldHdlZW4gcmVzb3VyY2UgYW5kIGNsaWVudCBhbmQg Z2l2ZXMgdGhlIGltcHJlc3Npb24gdGhhdA0KPj4+PiB0aGVyZSBpcyBhbiBhbmFsb2dvdXMgY2xp ZW50IGFjY2VzcyBjb250cm9sIHByb2JsZW0sIGJ1dCBJIGRvbuKAmXQgc2VlDQo+Pj4+YW55DQo+ Pj4+IGV2aWRlbmNlIG9mIHRoYXQgZnJvbSB0aGUgdXNlIGNhc2VzLiBBbmQgdGhlIGN1cnJlbnQg dGVybWlub2xvZ3kgaXMNCj4+Pj4gbWFraW5nDQo+Pj4+IHRoZSBkaXN0aW5jdGlvbiBkaWZmaWN1 bHQuDQo+Pj4+DQo+Pj4+IE5vdyB3ZSBtYWtlIHRoZSBzYW1lIGV4ZXJjaXNlIGluIHlvdXIgZXhh bXBsZSBiZWxvdy4NCj4+Pj4NCj4+Pj4+DQo+Pj4+PiBUaGUgcXVlc3Rpb24gdGhhdCBzdXJmYWNl ZCBoZXJlIGlzIHdoZXRoZXIgJ3ByaW5jaXBhbCcgaXMgdGhlIHJpZ2h0DQo+Pj4+PiB0ZXJtDQo+ Pj4+PiBvciBub3QuIFRoZSBkb2N1bWVudCBkZWZpbmVzIHByaW5jaXBhbCBhcyAiQSBzdWJqZWN0 IHdobyBpcyBlaXRoZXIgYQ0KPj4+Pj4gcmVzb3VyY2Ugb3duZXIgb3IgYSBjbGllbnQgb3duZXIg b3IgYm90aC4iDQo+Pj4+Pg0KPj4+Pj4gSGVyZSBpcyBhIHNsaWdodGx5IG1vZGlmaWVkIGV4YW1w bGUgdXNpbmcgYSBkb29yIGxvY2sgc2NlbmFyaW8gdGhhdA0KPj4+Pj5tYXkNCj4+Pj4+IGhlbHAg dXMgc2VlIHRocm91Z2ggdGhpcyBjYXNlLiBJbWFnaW5lIGEgZmFtaWx5IHdpdGggYSBraWQ6IEFs aWNlLA0KPj4+Pj5Cb2INCj4+Pj4+IGFuZCB0aGVpciB5b3VuZyBjaGlsZCBFdmUuDQo+Pj4+Pg0K Pj4+Pj4gQWxpY2UgYW5kIEJvYiBib3VnaHQgb25lIG9mIHRoZXNlIEludGVybmV0IGNvbm5lY3Rl ZCBkb29yIGxvY2tzIGFuZA0KPj4+Pj5ub3cNCj4+Pj4+IHdhbnQgdG8gY29uZmlndXJlIGl0LiBU aGV5IHdhbnQgdG8gY29uZmlndXJlIGl0IGluIHN1Y2ggYSB3YXkgdGhhdA0KPj4+Pj5hbGwNCj4+ Pj4+IHRocmVlIGNhbiBlbnRlciB0aGVpciBob3VzZSBqdXN0IHVzaW5nIHRoZWlyIHNtYXJ0IHBo b25lIChhbmQgYQ0KPj4+Pj4gc3BlY2lhbGx5IGxvYWRlZCBhcHApLg0KPj4+Pj4NCj4+Pj4+IFdo ZXRoZXIgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGlzIGluY2x1ZGVkIGluIHRoZSBkb29yIGxv Y2sgaXRzZWxmDQo+Pj4+Pm9yDQo+Pj4+PiBpcyBwYXJ0IG9mIHNvbWUgb3RoZXIgaG9tZSBhcHBs aWFuY2UgZG9lcyBub3QgcmVhbGx5IG1hdHRlciBmb3IgdGhlDQo+Pj4+PiBtb21lbnQuIEluIGFu eSBjYXNlLCBBbGljZSBhbmQgQm9iIGNvbmZpZ3VyZSB0aGUgZG9vciBsb2NrIGluIHN1Y2ggYQ0K Pj4+Pj4gd2F5DQo+Pj4+PiB0aGF0IEV2ZSBpcyBncmFudGVkIGFjY2Vzcy4gQWxpY2UgYW5kIEJv YiBhcmUgdGhlIG93bmVyIG9mIHRoZQ0KPj4+Pj5yZXNvdXJjZQ0KPj4+Pj4gKD1kb29yIGxvY2sp IGJ1dCBldmVuIGlmIHRoZXkgZG8gbm90ICdvd24nIHRoZSBkb29yIGxvY2sgKGJ1dCBoYXZlDQo+ Pj4+PiByYXRoZXIgcmVudGVkIGl0KSBkb2VzIG5vdCByZWFsbHkgbWF0dGVyLg0KPj4+Pg0KPj4+ PiBJIGFncmVlIGFib3V0IOKAnG93bmVyc2hpcOKAnSwgYnV0IGxldOKAmXMga2VlcCB0aGUgdGVy bWlub2xvZ3kgaW4gdGhpcw0KPj4+PiBleGFtcGxlLg0KPj4+Pg0KPj4+Pj4NCj4+Pj4+IFRoZSBh dXRob3JpemF0aW9uIHNlcnZlciBkb2VzIG5vdCBuZWNlc3NhcmlseSBuZWVkIHRvIGtub3cgdGhh dCB0aGlzDQo+Pj4+PiBhY2Nlc3MgY29udHJvbCBwb2xpY3kgaXMgYWJvdXQgIkV2ZSIuIEFsbCBp dCBjYXJlcyBpcyB0aGF0IHRoZXJlIGlzDQo+Pj4+PmFuDQo+Pj4+PiBlbnRyeSBpbiB0aGUgYWNj ZXNzIGNvbnRyb2wgbGlzdCB0aGF0IHBvaW50cyB0byBzb21lIGNyZWRlbnRpYWwgb24NCj4+Pj4+ c29tZQ0KPj4+Pj4gZGV2aWNlLiBUaGF0IGNyZWRlbnRpYWwgaGFwcGVucyB0byBwb2ludCB0byBh cHAgb24gdGhlIHNtYXJ0IHBob25lDQo+Pj4+PkV2ZQ0KPj4+Pj4gaXMgdXNpbmcuDQo+Pj4+Pg0K Pj4+Pj4gTm93LCB0aGUgcXVlc3Rpb24gaXMgaG93IEV2ZSwgd2hvIGlzIHRoZSBjbGllbnQgb3du ZXIsIGZpdHMgaW50byB0aGF0DQo+Pj4+PiBwaWN0dXJlLiBTaGUgd291bGQgdXNlIGhlciBwaG9u ZSAoPWNsaWVudCkgdG8gcmVxdWVzdCBhY2Nlc3MgdG8gdGhlDQo+Pj4+PiBkb29yDQo+Pj4+PiBi dXQgc2hlIHdvdWxkIG5vdCBiZSBpbnZvbHZlZCBpbiBwcm92aXNpb25pbmcgdGhlIGFjY2VzcyBj b250cm9sDQo+Pj4+PnBvbGljeQ0KPj4+Pj4gYXQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLg0K Pj4+Pj4NCj4+Pj4+IERpZCBJIGNvcnJlY3RseSB1bmRlcnN0b29kIHRoaXMgaXNzdWU/DQo+Pj4+ DQo+Pj4+IEkgdGhpbmsgeW91IGFyZSBjb3JyZWN0IGluIHRoYXQgdGhlIGRpc2N1c3Npb24gaXMg aG93IHRoZSBjbGllbnQgb3duZXINCj4+Pj4gZml0cyBpbnRvIHRoZSBwaWN0dXJlLg0KPj4+DQo+ Pj4gSSB3b3VsZCBhbHNvIHRoaW5rIHRoYXQgdGhpcyBpcyB0aGUgcHJvYmxlbS4gRXZlIHVzZXMg aGVyIHNtYXJ0cGhvbmUgdG8NCj4+PiByZXF1ZXN0IGFjY2VzcyB0byB0aGUgZG9vciBhbmQgaXMg Z3JhbnRlZCBhY2Nlc3MgZGVwZW5kaW5nIG9uIEFsaWNlIGFuZA0KPj4+IEJvYnMgYXV0aG9yaXph dGlvbi4gRXZlIGhhcyBubyBpbmZsdWVuY2Ugb24gdGhlaXIgZGVjaXNpb24uIEluIHRoZSBkb29y DQo+Pj4gbG9jayBjYXNlIHRoaXMgbWlnaHQgbm90IGEgYmlnIHByb2JsZW0uIEV2ZSBhY3RpdmVs eSB1c2VzIGhlcg0KPj4+c21hcnRwaG9uZQ0KPj4+IHRvIGludGVyYWN0IHdpdGggdGhlIGRvb3Ig bG9jay4gVGhlIHBob25lIG1pZ2h0IGFsc28gZGlzcGxheSBzb21lIGtpbmQNCj4+PiBvZiBkaWFs b2cgd2hlcmUgRXZlIGNhbiBkZWNpZGUgdG8gYWNjZXNzIHRoZSBkb29yIGxvY2sgb3Igbm90Lg0K Pj4+DQo+Pj4gSWYgRXZlIGRvZXNuJ3QgdXNlIGhlciBwaG9uZSBidXQgYSBjb25zdHJhaW5lZCBk ZXZpY2UgdG8gYWNjZXNzLCBlLmcuDQo+Pj4gc29tZSBzb3J0IG9mIGtleSBmb2IsIHNoZSBtaWdo dCB3YW50IHRvIG1ha2Ugc3VyZSB0aGF0IGl0IGRvZXNuJ3QNCj4+PiBwcm92aWRlIGhlciBjcmVk ZW50aWFscyB0byBldmVyeW9uZSB3aG8gaXMgYXNraW5nLg0KPj4+DQo+Pj4+DQo+Pj4+IFdoZXRo ZXIgdGhlIHBob25lIGlzIGludm9sdmVkIG9yIG5vdCBpbiB0cmFuc3BvcnRpbmcgYWNjZXNzIGNv bnRyb2wNCj4+Pj4gcG9saWN5DQo+Pj4+IG9yIG90aGVyIGF1dGhvcml6YXRpb24gaW5mb3JtYXRp b24gdG8gdGhlIHJlc291cmNlIHNlcnZlciBpcyBub3QgdGhlDQo+Pj4+IGlzc3VlLg0KPj4+Pg0K Pj4+PiBPbmUgaXNzdWUgd2UgaGF2ZSBpcyBpZiB0aGUgZG9vciBsb2NrIGNhbiBiZSBjYWxsZWQg 4oCcUmVzb3VyY2XigJ0gb3IgaWYNCj4+Pj5pdA0KPj4+PiBpcw0KPj4+PiBjb21wbGV0ZWx5IGFy Yml0cmFyeSB3aGljaCBpcyDigJxSZXNvdXJjZSIgYW5kIHdoaWNoIGlzIOKAnENsaWVudOKAnS4g KEnigJltDQo+Pj4+aW4NCj4+Pj4gZmF2b3VyIG9mIHRoZSBmb3JtZXIuKQ0KPj4+Pg0KPj4+PiBP bmUgdGhpbmcgd2UgZG8gYWdyZWUgYWJvdXQgaXMgdGhhdCB0aGUgdGVuYW50cywgQWxpY2UgYW5k IEJvYiwgc2hvdWxkDQo+Pj4+IGJlDQo+Pj4+IGFibGUgdG8gc2V0IGFjY2VzcyBwb2xpY2llcyBm b3IgdGhlIGxvY2suIEkgdGhpbmsgdGhpcyBpcyB0aGUgYW5hbG9ndWUNCj4+Pj4gb2YNCj4+Pj4g VTEuMWIvYy4gQnV0IHNpbmNlIHdlIGNhbuKAmXQgYWdyZWVkIHdoZXRoZXIgdGhlIGxvY2sgaXMg 4oCcUmVzb3VyY2UiIG9yDQo+Pj4+Y2FuDQo+Pj4+IGFsdGVybmF0aXZlbHkgYmUg4oCcQ2xpZW50 IiwgSSBjYW7igJl0IHVzZSB0aGUgdGVybSDigJxSZXNvdXJjZSBPd25lcuKAnS4gIE5vcg0KPj4+ PiBjYW4NCj4+Pj4gd2UgdXNlIHRoZSB0ZXJtIOKAnENsaWVudCBPd25lcuKAnS4gV2l0aCByZWdh cmRzIHRvIHRoaXMsIEkgaGF2ZSBiZWVuDQo+Pj4+IHF1ZXN0aW9uaW5nIHRoZSB1c2VmdWxuZXNz IG9mIHRoZSBjdXJyZW50IHRlcm1pbm9sb2d5IGluIHRoZSBkcmFmdCwgb3INCj4+Pj4gaG93DQo+ Pj4+IGl0IGlzIGFwcGxpZWQuDQo+Pj4NCj4+PiBJbiB0aGUgdXNlIGNhc2VzIGRvY3VtZW50LCB3 ZSBhcmUgZGVmaW5pbmcgdXNlIGNhc2VzIGZvciBjb25zdHJhaW5lZA0KPj4+IGVudmlyb25tZW50 cy4gV2hlcmUgbmVlZGVkLCB3ZSBhc3N1bWUgQ29BUCBhcyB0aGUgdXNlZCBwcm90b2NvbC4gSW4N Cj4+PkNvQVANCj4+PiB3ZSBoYXZlIHR3byBlbmRwb2ludHMsIHRoZSBjbGllbnQgYW5kIHRoZSBz ZXJ2ZXIsIHRoYXQgYXJlDQo+Pj5jb21tdW5pY2F0aW5nDQo+Pj4gd2l0aCBlYWNoIG90aGVyLiBU aGUgc2VydmVyIGhvc3RzIHJlc291cmNlcyB0aGF0IGNhbiBiZSBhY2Nlc3NlZCBieSB0aGUNCj4+ PiBjbGllbnQuIFdlIGNvdWxkIGRlZmluZSB0aGF0IGEgZG9vciBsb2NrIE1VU1QgYmUgYSAgQ29B UCBzZXJ2ZXIgYW5kDQo+Pj50aGF0DQo+Pj4gdGhlIGRldmljZSBhY2Nlc3NpbmcgdGhlIGRvb3Ig bG9jayBNVVNUIGJlIGEgQ29BUCBjbGllbnQgb3IgdmljZSB2ZXJzYS4NCj4+PiBJZiB0aGVyZSBp cyBubyBzdHJvbmcgZXZpZGVuY2UgdG8gZG8gc28sIEkgd291bGQgcmF0aGVyIG5vdCByZXN0cmlj dA0KPj4+IENvQVAgaW1wbGVtZW50YXRpb25zIGluIHN1Y2ggYSB3YXkuIEl0IHNlZW1zIHdyb25n IHRvIG1lIHRvIHNheSB0aGF0DQo+Pj4gQ29BUCBpcyBmbGV4aWJsZSBlbm91Z2ggdG8gYWxsb3cg Zm9yIGFsbCBraW5kcyBvZiBzZXR0aW5ncyBidXQNCj4+PiB1bmZvcnR1bmF0ZWx5IG91ciBhdXRo b3JpemF0aW9uIHNvbHV0aW9uIGRvZXMgbm90IGNvbnNpZGVyIHRoaXMNCj4+PiBmbGV4aWJpbGl0 eSB3aGljaCBpcyB3aHkgQ29BUCBpcyBsZXNzIGZsZXhpYmxlIGlmIHdlIGFyZSB1c2luZw0KPj4+ IGF1dGhvcml6YXRpb24uDQo+Pj4NCj4+Pj4NCj4+Pj4gTWF5YmUgd2UgY2FuIHVzZSB0aGUgcXVh bGlmaWNhdGlvbiDigJxsb2NrLVJlc291cmNlIiBhbmQg4oCcbG9jay1DbGllbnQiDQo+Pj4+dG8N Cj4+Pj4gZGlzdGluZ3Vpc2ggZnJvbSBvdGhlciByZXNvdXJjZXMgYW5kIGNsaWVudHM/IEFuZCB0 aGVuIOKAnGxvY2stUmVzb3VyY2UNCj4+Pj4gT3duZXLigJ0gKEFsaWNlIGFuZCBCb2IpIGFuZCDi gJxsb2NrLUNsaWVudCBPd25lcuKAnSAoRXZlKSB3b3VsZCBhbHNvIGJlDQo+Pj4+d2VsbA0KPj4+ PiBkZWZpbmVkPw0KPj4+Pg0KPj4+Pg0KPj4+PiBUaGUgb3RoZXIgaXNzdWUgcmVsYXRlcyB0byB3 aGF0IGlzIHRoZSBwcm9ibGVtIGZvciBFdmUuIENvbnNpZGVyIHRoZQ0KPj4+PiBhbmFsb2d1ZSBv ZiBVMS4yYiBhYm92ZSBpbiB0aGlzIHNldHRpbmc6DQo+Pj4+DQo+Pj4+IFUxLjJiOiAiRXZlIHdh bnRzIHRvIGRlZmluZSBmb3IgaGVyIHBob25lIGlmIGFuZCBob3cgaXQgaXMgYWxsb3cgdG8NCj4+ Pj4gcmVxdWVzdCB0aGUgbG9jayB0byBiZSBvcGVuZWQuIg0KPj4+Pg0KPj4+PiBUbyBtZSBpdCBp cyBxdWl0ZSBjbGVhciB0aGF0IHRoaXMgaXMgYW4gYXdrd2FyZCB3YXkgb2YgZm9yY2luZyBhbg0K Pj4+PmFjY2Vzcw0KPj4+PiBjb250cm9sIHByb2JsZW0gZm9ybXVsYXRpb24gaW50byB3aGF0IGlz buKAmXQuIFdoZW4gRXZlIHdhbnRzIHRvIG9wZW4gYQ0KPj4+PiBsb2NrLCBzaGUgcHJlc3NlcyBh IGJ1dHRvbiBpbiB0aGUgYXBwLCB0aGVyZWJ5IGF1dGhvcml6ZXMgdGhlIHJlcXVlc3QuDQo+Pj4+ IFRoZXJlIGlzIG5vIG5lZWQgdG8gc29sdmUgdGhpcyB3aXRoIGFjY2VzcyBjb250cm9sIHBvbGlj aWVzLCB0cmFuc3BvcnQNCj4+Pj4gYXV0aG9yaXphdGlvbiBpbmZvcm1hdGlvbiwgZW5mb3JjZW1l bnQgZXRjLiAgVGhlcmUgaXMgYSBuYXR1cmFsDQo+Pj4+IGFzeW1tZXRyeQ0KPj4+PiB3aGljaCBp cyBjbGVhcmx5IGlsbHVzdHJhdGVkIGluIHRoZSB1c2UgY2FzZXMuIFdlIHNob3VsZCBub3QgaGlk ZSB0aGF0DQo+Pj4+IGJlaGluZCBzdHJhbmdlIHRlcm1pbm9sb2d5IGFuZCBmb3JtdWxhdGlvbnMu DQo+Pj4NCj4+PiBZZXMsIGV4YWN0bHksIEV2ZSBpcyBhdXRob3JpemluZyB0aGUgcmVxdWVzdC4g QW5kIGluIHRoaXMgc3BlY2lmaWMNCj4+PiBzY2VuYXJpbyBpbXBsaWNpdCBhdXRob3JpemF0aW9u IChhbiBhdXRoZW50aWNhdGVkIGRldmljZSBpcyBhdXRob3JpemVkKQ0KPj4+IG1pZ2h0IGJlIGdv b2QgZW5vdWdoLiBTaW5jZSBFdmUgY2FuIGRlY2lkZSB3aGF0IGhlciBzbWFydHBob25lIGlzDQo+ Pj4gc3VwcG9zZWQgdG8gZG8sIHRoZXJlIGlzIG5vIG5lZWQgZm9yIG1vcmUgc29waGlzdGljYXRl ZCBhdXRob3JpemF0aW9uDQo+Pj4gcG9saWNpZXMuIFRoaXMgaXMgZGlmZmVyZW50IGZvciBvdGhl ciB1c2UgY2FzZXMuDQo+Pj4NCj4+PiBJZiB5b3UgdGhpbmsgYWJvdXQgaXQsIHRoZXJlIGlzIGFs c28gbm8gbmVlZCBmb3Igc29waGlzdGljYXRlZA0KPj4+IGF1dGhvcml6YXRpb24gb24gdGhlIGRv b3IgbG9jayBzaWRlLCBlaXRoZXIuIEl0IG1pZ2h0IGJlIHN1ZmZpY2llbnQgaWYNCj4+PmENCj4+ PiBkZXZpY2UgdGhhdCBjYW4gYmUgYXV0aGVudGljYXRlZCBpcyBhdXRob3JpemVkIHRvIG9wZW4g dGhlIGRvb3IuIEluDQo+Pj50aGlzDQo+Pj4gY2FzZSwgaW1wbGljaXQgYXV0aG9yaXphdGlvbiBp cyBzdWZmaWNpZW50IG9uIGJvdGggc2lkZXMuIEFnYWluIHRoaXMgaXMNCj4+PiBkaWZmZXJlbnQg Zm9yIG90aGVyIHVzZSBjYXNlcy4NCj4+Pg0KPj4+IEJlc3QgcmVnYXJkcywNCj4+PiBTdGVmZmkN Cj4+DQo+Pg0KPj4NCj4NCj4tLSANCj5TdGVmYW5pZSBHZXJkZXMJCQlUZWw6ICs0OSA0MjEgMjE4 IDYzOTA2DQo+VFpJIFVuaXZlcnNpdMOkdCBCcmVtZW4JCUUtTWFpbDogZ2VyZGVzQHR6aS5kZQ0K PkJpYmxpb3RoZWtzdHIuIDEsIE1aSCA1MTUwDQo+MjgzNTkgQnJlbWVuLCBHZXJtYW55DQoNCg== From nobody Thu Mar 5 22:52: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 1B0691ACCF0 for ; Thu, 5 Mar 2015 22:52:37 -0800 (PST) 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 LfuFnMvWcZBp for ; Thu, 5 Mar 2015 22:52:32 -0800 (PST) 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 6B5621ACCE7 for ; Thu, 5 Mar 2015 22:52:31 -0800 (PST) X-AuditID: c1b4fb2d-f79aa6d00000359d-f7-54f94ead3c9a Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id EF.57.13725.DAE49F45; Fri, 6 Mar 2015 07:52:29 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.70]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0210.002; Fri, 6 Mar 2015 07:52:28 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Hannes Tschofenig , Stefanie Gerdes , "Ace@ietf.org" Thread-Topic: [Ace] U1.2 in Use Case Document Thread-Index: AQHQVbL1RkiN6OYzzEyLTf3fE9ZKCp0K/GYAgAAliYCAAe0ZgIAAdKwAgAACJQCAAYL5AA== Date: Fri, 6 Mar 2015 06:52:28 +0000 Message-ID: References: <54F5B1F2.6050205@gmx.net> <54F616CF.20607@tzi.de> <54F81652.6040102@tzi.de> <54F8181E.7080304@gmx.net> In-Reply-To: <54F8181E.7080304@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+NgFprAIsWRmVeSWpSXmKPExsUyM+Jvje5av58hBjeWG1h8/9bDbLHx4l1G i6U777E6MHss3rSfzWPJkp9MHtvefmUOYI7isklJzcksSy3St0vgyvg5ZxJrwYPLjBWTnh9m bWBccY6xi5GTQ0LAROLK+ZvsELaYxIV769m6GLk4hASOMEp8mT0fylnEKLHh9DEWkCo2AReJ Bw2PmEBsEYFiiXubZ4BNEhbQkdj6dweQzQEU15W4vt4LoiRM4v/alcwgNouAisTSHX2sIDav gIXE2ovt7BDzLzNK9E47yQaS4BRQl/j+9hzYLkagi76fWgO2i1lAXOLWk/lMEJcKSCzZc54Z whaVePn4H9hQUQE9iZXXm9gg4koSK7ZfAruHWUBTYv0ufYgx1hL9d7ezQtiKElO6H7JD3CMo cXLmE5YJjOKzkGybhdA9C0n3LCTds5B0L2BkXcUoWpxaXJybbmSsl1qUmVxcnJ+nl5dasokR GIUHt/zW3cG4+rXjIUYBDkYlHl4DiZ8hQqyJZcWVuYcYpTlYlMR57YwPhQgJpCeWpGanphak FsUXleakFh9iZOLglGpgNN38pnte+7z6EsdkVc9lf658T50d4RnTd9bXmFfUJnX2Wx8PFsnH X7zZM4O9nrJobzIXSE/fHLWRxUY63sG71uHlVeZO3T36zuwe/IdfleqYTbIqDWGNvMSy5XfH hWkyoryTz7W03vx35trd+BYrbperjxxTO+rvbjv4dk76058zF619Et2oxFKckWioxVxUnAgA ncwzvKMCAAA= Archived-At: Subject: Re: [Ace] U1.2 in Use Case Document 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, 06 Mar 2015 06:52:37 -0000 SGkgSGFubmVzLA0KDQpPbiAyMDE1LTAzLTA1IDA5OjQ3LCAiSGFubmVzIFRzY2hvZmVuaWciIDxo YW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PiB3cm90ZToNCg0KPkhpIFN0ZWZmaSwgSGkgR8O2cmFu LA0KPg0KPndlIGRvIG5vdCB3YW50IHRvIGhhdmUgQ29BUCBzcGVjaWZpYyB0ZXJtaW5vbG9neSBp biB0aGUgZG9jdW1lbnQuIFdoaWxlDQo+aXQgaGFzIHRvIGJlIGFwcGxpY2FibGUgdG8gQ29BUCBl YXJseSBpbiB0aGUgY2hhcnRlciBkaXNjdXNzaW9uIHdlDQo+d2FudGVkIHRvIGFsc28gbm90IHJ1 bGUgb3V0IG90aGVyIHByb3RvY29scyBhbmQgdGhlcmUgaXMgbm90aGluZyByZWFsbHkNCj5pbiB0 aGUgZG9jdW1lbnQgdGhhdCBkZXBlbmRzIG9uIENvQVAuDQo+DQo+SW4gdGVybXMgb2YgbGlzdGlu ZyB0aGUgcmVxdWlyZW1lbnRzIGluIHJlZmVyZW5jZSB0byB0aGUgdXNlIGNhc2VzLCBzdWNoDQo+ YXMgc2F5aW5nICJmcnVpdCB2ZW5kb3JzIHdhbnQgdG8gZ3JhbnQgZGlmZmVyZW50IGFjY2VzcyBy aWdodHMgdG8NCj5kaWZmZXJlbnQgcGFydGllcyB0byBtZWFzdXJlbWVudHMgb2YgZ29vZHPigJkg dGVtcGVyYXR1cmVzIiBzb3VuZHMgT0sgdG8NCj5tZS4gVGhlIHRleHQgaW4gdGhlIHVzZSBjYXNl IHNob3VsZCBhbnl3YXkgc2F5IHdoYXQgcnVsZSB0aGUgZnJ1aXQNCj52ZW5kb3IgcGxheXMuDQoN Ckl0IGlzIGFsc28gT0sgZm9yIG1lIHRvIHJlbW92ZSBhbGwgcm9sZSB0ZXJtaW5vbG9neSBmcm9t IGEgdXNlIGNhc2UNCmRvY3VtZW50LiBUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgYmVjb21l cyBtb3JlIGF3a3dhcmQsIGJ1dCBJIHN1cHBvc2UNCnlvdSBjb3VsZCByZWFzb24gYnkgbWVhbnMg b2YgZXhhbXBsZXMuDQoNCkJlc3QgcmVnYXJkcywNCkfDtnJhbg0KDQoNCj4NCj5DaWFvDQo+SGFu bmVzDQo+DQo+DQo+T24gMDMvMDUvMjAxNSAwOTozOSBBTSwgU3RlZmFuaWUgR2VyZGVzIHdyb3Rl Og0KPj4gSGkgR8O2cmFuLA0KPj4gDQo+PiBpZiB3ZSB1c2UgYW55IGtpbmQgb2Ygc29sdXRpb24g c3BlY2lmaWMgdGVybWlub2xvZ3kgaW4gdGhlIGRyYWZ0LCB3ZQ0KPj4gbXVzdCB1c2UgQ29BUCB0 ZXJtaW5vbG9neSBzaW5jZSB3ZSB3YW50IHRvIGZpbmQgYW4gYXV0aG9yaXphdGlvbg0KPj4gc29s dXRpb24gdGhhdCBmaXRzIHRvIENvQVAuDQo+PiANCj4+IFllcywgSSBhZ3JlZSB0aGF0IHRlcm1p bm9sb2d5IGFuZCBwcm9ibGVtIHN0YXRlbWVudCBuZWVkIHRvIGJlIGNsZWFyLg0KPj4gQnV0IHRo ZXkgbmVlZCB0byBmaXQgdG8gdGhlIHByb2JsZW0sIG5vdCB0byB0aGUgc29sdXRpb24uDQo+PiAN Cj4+IEkgYW0gcHJldHR5IHN1cmUgdGhhdCB3ZSB3aWxsIGZpbmQgb3V0IGhvdyBhIHNvbHV0aW9u IGNhbiBiZSBtYXBwZWQgdG8NCj4+IHRoZSB1c2UgY2FzZXMuIEJ1dCBpZiB0aGUgdXNlIGNhc2Vz IGRvY3VtZW50IGRvbid0IHJlZmxlY3QgaG93IHRoaW5ncw0KPj4gd29yayBpbiBDb0FQLCBJIGRv bid0IHRoaW5rIHdlIHdpbGwgYmUgYWJsZSB0byBmaW5kIGEgZml0dGluZyBzb2x1dGlvbi4NCj4+ IA0KPj4gQmVzdCByZWdhcmRzLA0KPj4gU3RlZmZpDQo+PiANCj4+IA0KPj4gT24gMDMvMDUvMjAx NSAwMTo0MiBBTSwgR8O2cmFuIFNlbGFuZGVyIHdyb3RlOg0KPj4+IEhpIFN0ZWZmaSBhbmQgYWxs LA0KPj4+DQo+Pj4NCj4+PiBUcnlpbmcgdG8gY2F0Y2ggdXAgd2l0aCB0aGUgbWFpbHMuIEkganVz dCBzdW1tYXJpemUgc29tZSBjb21tZW50cyBvbg0KPj4+dGhpcw0KPj4+IG1haWwgZm9yIG5vdy4N Cj4+Pg0KPj4+IFRlcm1pbm9sb2d5IGFuZCBwcm9ibGVtIHN0YXRlbWVudA0KPj4+IC0gLSAtDQo+ Pj4gQ3VycmVudCB0ZXJtaW5vbG9neSwgb3IgaG93IGl0IGlzIGFwcGxpZWQsIGlzIHVuc2F0aXNm YWN0b3J5LCBhcyBJ4oCZdmUNCj4+PiByZS1pdGVyYXRlZCBhIGNvdXBsZSBvZiB0aW1lcy4gSeKA mXZlIHByZXZpb3VzbHkgYmVlbiB3b3JraW5nIGluIGxhcmdlDQo+Pj4gcHJvamVjdHMgd2hlcmUg dGVybWlub2xvZ3kgYW5kIHByb2JsZW0gc3RhdGVtZW50IHdhcyB1bmNsZWFyIGFuZCBpdCBpcw0K Pj4+YW4NCj4+PiBhYnNvbHV0ZSB3YXN0ZSBvZiB0aW1lLiBJIHRoaW5rIG90aGVycyBpbiB0aGlz IGdyb3VwIGhhdmluZyBzaW1pbGFyDQo+Pj4gZXhwZXJpZW5jZXMgY2FuIGNvbmZpcm0gdGhpcy4N Cj4+Pg0KPj4+DQo+Pj4gV2UgaGF2ZSBkaWZmZXJlbnQgb3B0aW9ucyB0byByZXNvbHZlIHRoaXMu DQo+Pj4NCj4+PiAxLiBXZSBjYW4gcmVtb3ZlIHJvbGUgdGVybWlub2xvZ3kgZnJvbSB0aGUgdXNl IGNhc2UgZHJhZnQgYW5kIGV4cHJlc3MNCj4+PnRoZQ0KPj4+IHByb2JsZW1zIGluIHRlcm1zIG9m IHRoZSBhY3RvcnMgaW4gdGhlIHVzZSBjYXNlcy4gRS5nLiAiZnJ1aXQgdmVuZG9ycw0KPj4+IHdh bnQNCj4+PiB0byBncmFudCBkaWZmZXJlbnQgYWNjZXNzIHJpZ2h0cyB0byBkaWZmZXJlbnQgcGFy dGllcyB0byBtZWFzdXJlbWVudHMNCj4+Pm9mDQo+Pj4gZ29vZHPigJkgdGVtcGVyYXR1cmVzIi4g VGhhdCB3b3VsZCBzYXZlIHRoZSB1c2UgY2FzZSBkb2N1bWVudCwgYnV0IGluDQo+Pj50aGlzDQo+ Pj4gY2FzZSB3ZSBkb27igJl0IGhhdmUgYSBnZW5lcmFsIHByb2JsZW0gc3RhdGVtZW50IGluIHRl cm1zIG9mIHJvbGVzLCBhbmQNCj4+PiB0aGF0DQo+Pj4gdGhlbiBiZWNvbWVzIHRoZW4gb3VyIG5l eHQgY2hhbGxlbmdlLg0KPj4+DQo+Pj4gMi4gSWYgd2UgaW5zdGVhZCBkZWZpbmUgcm9sZXMgKFJl c291cmNlIFNlcnZlciwgQ2xpZW50IGV0Yy4pIHRoZW4gd2UNCj4+Pm11c3QNCj4+PiBiZSBhYmxl IHRvIGV4cHJlc3MgdGhlIHJlbGV2YW50IHByb2JsZW1zIGJhc2VkIG9uIHRoZSB1c2UgY2FzZXMg aW4NCj4+PnRlcm1zDQo+Pj4gb2YgdGhlIHJvbGVzIGRlZmluZWQuIE90aGVyd2lzZSB0aGUgcm9s ZSBkZWZpbml0aW9ucyBhcmUgbm90IGdvb2QNCj4+PmVub3VnaC4NCj4+PiBGb3IgZXhhbXBsZSAi UmVzb3VyY2UgT3duZXJzLCBzdWNoIGFzIGZydWl0IHZlbmRvcnMsIHdhbnRzIHRvIGdyYW50DQo+ Pj4gZGlmZmVyZW50IGFjY2VzcyByaWdodHMgdG8gZGlmZmVyZW50IHBhcnRpZXMgZm9yIHRoZWly IHJlc291cmNlcywgc3VjaA0KPj4+YXMNCj4+PiB0ZW1wZXJhdHVyZXMiDQo+Pj4NCj4+PiBJZiB3 ZSBjYW7igJl0IGV4cHJlc3Mgd2hhdCBhcmUgdGhlIGFzc2V0cyBhbmQgdGhlIHN0YWtlaG9sZGVy cyBpbiBhIHdlbGwNCj4+PiBkZWZpbmVkIHdheSwgc28gdGhhdCB3ZSBjYW4gZm9ybXVsYXRlIHRo ZSBwcm9ibGVtIHN0YXRlbWVudCBpbiB0ZXJtcyBvZg0KPj4+IHRoZXNlLCB0aGVuIHdlIGhhdmUg YSBzZXJpb3VzIHByb2JsZW0uIEkgYWR2b2NhdGUgdGhhdCB3ZSBhZG9wdCBhbg0KPj4+IGVzdGFi bGlzaGVkIHRlcm1pbm9sb2d5IHN1Y2ggYXMgT0F1dGggb3IgVU1BLiBXaGF0ZXZlciBjbGllbnQg YXNwZWN0cw0KPj4+d2UNCj4+PiB3YW50IHRvIGZvcm11bGF0ZSBjYW4gc3VyZWx5IGJlIGV4cHJl c3NlZCBpbiBhbnkgb2YgdGhlc2UgdGVybWlub2xvZ3kuDQo+Pj4NCj4+PiBTb21lIGNvbnRyb2wg cXVlc3Rpb25zIG9uIGhvdyBmYXIgd2UgaGF2ZSByZWFjaGVkIGluIHRoaXMgd29yazoNCj4+Pg0K Pj4+IC0gSW4gdGhlIGNvbnRhaW5lciB1c2UgY2FzZSwgY2FuIHdlIGFncmVlIHRoYXQgdGhlIHRl bXBlcmF0dXJlIHNlbnNvcnMNCj4+PiBhbmQNCj4+PiBmYW4gYWN0dWF0b3JzIGFyZSB0aGUgbWFp biDigJxpdGVtcyBvZiBpbnRlcmVzdOKAnS4NCj4+Pg0KPj4+IC0gQ2FuIHdlIGRlbm90ZSB0aGUg dGVtcGVyYXR1cmUgc2Vuc29yIGFuZCBmYW4gYWN0dWF0b3JzIOKAnFJlc291cmNlc+KAnT8NCj4+ Pg0KPj4+IC0gQ2FuIHdlLCBhcyBFdmUgcHJvcG9zZWQsIGFncmVlIHRvIHZpZXcgdGhlIHRlbXBl cmF0dXJlIHNlbnNvciAtIGZhbg0KPj4+IGFjdHVhdG9yIGludGVyYWN0aW9uIGFzIHR3byBvbmUt d2F5IHJlbGF0aW9uc2hpcHMsIGkuZS4gdGhlcmUgYXJlDQo+Pj4gdGVtcGVyYXR1cmUtcmVzb3Vy Y2VzIGFuZCB0ZW1wZXJhdHVyZS1jbGllbnRzLCBhcyB3ZWxsIGFzIGZhbi1yZXNvdXJjZXMNCj4+ PiBhbmQgZmFuLWNsaWVudHMgKHNvbWUgb2Ygd2hpY2ggbWF5IGJlIGNvLWxvY2F0ZWQpLg0KPj4+ DQo+Pj4gKE1heWJlIHdlIGNhbiB0aGVuIGF2b2lkIGZvcm11bGF0aW9ucyBzdWNoIGFzICJJZiB0 aGUgdGVtcGVyYXR1cmUNCj4+PnNlbnNvcg0KPj4+IGlzIG5vdCBhYmxlIHRvIGRlY2lkZSBpZiBh IHJlc291cmNlIGlzIGF1dGhvcml6ZWTigJ0/IFNlZSBmdXJ0aGVyIGRvd24gaW4NCj4+PiB0aGlz IG1haWwuKQ0KPj4+DQo+Pj4NCj4+Pg0KPj4+IENvbnN0cmFpbmVkIGNsaWVudHMNCj4+PiAtIC0g LQ0KPj4+IE9uZSByZWN1cnJpbmcgdGhlbWUgaW4gdGhpcyBkaXNjdXNzaW9uIGhhcyBiZWVuIG9u IGNvbnN0cmFpbmVkIGNsaWVudA0KPj4+IGRldmljZXMuICBUaGVyZSBpcyBhIHF1ZXN0aW9uIGFi b3V0IHdoYXQga2luZCBvZiAiYXV0aG9yaXphdGlvbg0KPj4+cHJvYmxlbXPigJ0NCj4+PiB0aGF0 IGFyZSByZWxldmFudCB0byB0aGUgY2xpZW50IGRldmljZS4gSXQgaXMgbWFpbmx5IHJlbGF0ZWQg dG8NCj4+PiBhc3BlY3RzIG9mDQo+Pj4gYSBjbGllbnQgZGlzY2xvc2luZyBhIHJlcXVlc3QuIFRo ZXJlIGhhcyBiZWVuIHJlcGVhdGVkIGNsYWltcyBhYm91dCB0aGUNCj4+PiBuZWVkIGZvciBzb3Bo aXN0aWNhdGVkIGFjY2VzcyBjb250cm9sIHBvbGljaWVzIG9uIHRoZSBjbGllbnQgc2lkZSwgaW4N Cj4+PnRoZQ0KPj4+IHNlbnNlIHRoYXQgdGhlIGNsaWVudCBhY3Rpb25zLCBzdWNoIGFzIG1ha2lu ZyBhIHJlcXVlc3QsIG5lZWQgdG8gYmUNCj4+PiBzdWJqZWN0IHRvIGFjY2VzcyBjb250cm9sIHBv bGljaWVzLCBqdXN0IGJlY2F1c2UgdGhlIGRldmljZXMgYXJlDQo+Pj4gY29uc3RyYWluZWQuIEJ1 dCBub3doZXJlIGluIHRoZSB1c2UgY2FzZSBkb2N1bWVudCBpcyB0aGlzIGNsYWltDQo+Pj4gc3Vi c3RhbnRpYXRlZCwgaS5lLiB0aGF0IGEgcGFydGljdWxhciB1c2UgY2FzZSBpcyByZXF1aXJpbmcg c3VjaCBhDQo+Pj4gZmVhdHVyZS4gVGhlcmUgYXJlIG9ubHkgYWJzdHJhY3QgZm9ybXVsYXRpb25z IGFib3V0IHByaW5jaXBhbHMsIGFuZA0KPj4+IGludGVycHJldGVkIGFzIHJlc291cmNlIG93bmVy IGFzIHdlbGwgYXMgY2xpZW50IG93bmVycy4gVGhlIG1vdGl2YXRpb24NCj4+PiBmb3INCj4+PiB0 aGF0IGhhcyBiZWVuIHRoYXQgaWYgd2UgZGVzY3JpYmUgdGhlIHVzZSBjYXNlIGluIHRvbyBtdWNo IGRldGFpbCBpdA0KPj4+IGJlY29tZXMgc29sdXRpb24gc3BlY2lmaWMuIEFuIGFsdGVybmF0aXZl IGV4cGxhbmF0aW9uIGlzIHRoYXQgb25seQ0KPj4+IGZldywgaWYNCj4+PiBhbnksIG9mIHRoZSB1 c2UgY2FzZXMgYWN0dWFsbHkgcmVxdWlyZSBjbGllbnQgc2lkZSBhY2Nlc3MgY29udHJvbA0KPj4+ IHBvbGljaWVzLg0KPj4+DQo+Pj4gSSB0aGluayB3ZSBzaG91bGQgZGV0YWNoIGFueSBwb3RlbnRp YWwgYWNjZXNzIGNvbnRyb2wgcG9saWN5IHByb2JsZW1zDQo+Pj5vZg0KPj4+IHRoZSBjbGllbnQg ZnJvbSB0aGF0IHJlbGF0ZWQgdG8gcmVzb3VyY2UgYWNjZXNzLCBiZWNhdXNlIGl0IGlzDQo+Pj5k aWZmZXJlbnQsDQo+Pj4gaXQgaXMgbm90IGRvY3VtZW50ZWQgdG8gYmUgcmVsZXZhbnQsIGFuZCBp dCBpcyBhbiBpbmRlcGVuZGVudCBwcm9ibGVtDQo+Pj4gdGhhdA0KPj4+IG1ha2VzIHRoZSBwcm9i bGVtIGZvcm11bGF0aW9uIGNvbXBsZXguIEZ1cnRoZXJtb3JlLCBubyBvbmUgYWN0dWFsbHkNCj4+ Pmtub3dzDQo+Pj4gYWJvdXQgdGhlIG5lZWQgYW5kIG5hdHVyZSBvZiBwb2xpY2llcyBmb3IgaW4g dGhlc2Ugc2l0dWF0aW9ucy4gSXQgaXMNCj4+PnB1cmUNCj4+PiBzcGVjdWxhdGlvbnMuIEkgdGhp bmsgdGhhdCBpZiBhbnl0aGluZywgc29tZSBzb3J0IG9mICJkZWNpc2lvbg0KPj4+cG9saWNpZXPi gJ0NCj4+PiBjb3VsZCBwb3RlbnRpYWxseSBiZSB1c2VmdWwuIEZvcm11bGF0aW5nIGl0IGFzIGFj Y2VzcyBjb250cm9sIHByb2JsZW0NCj4+PiBsZWFkcyB0byB2ZXJ5IHN0cmFuZ2Ugc3RhdGVtZW50 cyBhcyBJIHNob3dlZCBhdCB0aGUgZW5kIG9mIHRoaXMgbWFpbDoNCj4+PiBodHRwOi8vd3d3Lmll dGYub3JnL21haWwtYXJjaGl2ZS93ZWIvYWNlL2N1cnJlbnQvbXNnMDEwMTkuaHRtbA0KPj4+DQo+ Pj4NCj4+PiBNb3JlIGxhdGVyLg0KPj4+DQo+Pj4gQmVzdCByZWdhcmRzLA0KPj4+IEfDtnJhbg0K Pj4+DQo+Pj4NCj4+Pg0KPj4+IE9uIDIwMTUtMDMtMDMgMjE6MTcsICJTdGVmYW5pZSBHZXJkZXMi IDxnZXJkZXNAdHppLmRlPiB3cm90ZToNCj4+Pg0KPj4+PiBIaSBhbGwsDQo+Pj4+DQo+Pj4+IE9u IDAzLzAzLzIwMTUgMDY6MDMgUE0sIEfDtnJhbiBTZWxhbmRlciB3cm90ZToNCj4+Pj4+IEhpIEhh bm5lcywNCj4+Pj4+DQo+Pj4+PiBPbiAyMDE1LTAzLTAzIDE0OjA2LCAiSGFubmVzIFRzY2hvZmVu aWciIDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Pg0KPj4+Pj4gd3JvdGU6DQo+Pj4+Pg0KPj4+ Pj4+IEhpIGFsbCwNCj4+Pj4+Pg0KPj4+Pj4+IGxldCBtZSB0cnkgdG8gc2VlIHdoZXRoZXIgSSB1 bmRlcnN0YW5kIHRoZSBpc3N1ZSB0aGF0J3MgY3VycmVudGx5DQo+Pj4+Pj4gdW5kZXINCj4+Pj4+ PiBkaXNjdXNzaW9uLg0KPj4+Pj4+DQo+Pj4+Pj4gSXQgc2VlbXMgdGhhdCB0aGUgZGViYXRlIGZv Y3VzZXMgb24gdGhpcyByZXF1aXJlbWVudCBmcm9tIHRoZQ0KPj4+Pj4+ICdDb250YWluZXINCj4+ Pj4+PiBtb25pdG9yaW5nJyB1c2UgY2FzZToNCj4+Pj4+Pg0KPj4+Pj4+ICINCj4+Pj4+PiAgICAg byAgVTEuMiBQcmluY2lwYWxzIHdhbnQgdG8gZ3JhbnQgZGlmZmVyZW50IGFjY2VzcyByaWdodHMg Zm9yDQo+Pj4+Pj4gICAgICAgIGRpZmZlcmVudCByZXNvdXJjZXMgb24gYW4gZW5kcG9pbnQuDQo+ Pj4+Pj4gIg0KPj4+Pj4NCj4+Pj4+IEFjdHVhbGx5LCB3ZSBhcmUgbm90IGRlYmF0aW5nIHRoaXMg VTEuMiByZXF1aXJlbWVudC4gU3RlZmZpIG1hZGUgYQ0KPj4+Pj5uZXcNCj4+Pj4+IHNldA0KPj4+ Pj4gb2YgcmVxdWlyZW1lbnRzLCBzZWUNCj4+Pj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h cmNoaXZlL3dlYi9hY2UvY3VycmVudC9tc2cwMDk4Mi5odG1sDQo+Pj4+Pg0KPj4+Pj4gVGhlIGRl YmF0ZSBmb2N1c2VkIG9uIHRoaXMgcmVxdWlyZW1lbnQgcHJvcG9zZWQgYnkgU3RlZmZpOg0KPj4+ Pj4NCj4+Pj4+ICJVMS4xYSBQcmluY2lwYWxzIHN1Y2ggYXMgdGhlIGZydWl0IHZlbmRvciwgdGhl IHRyYW5zbG9hZGluZw0KPj4+Pj5wZXJzb25uZWwNCj4+Pj4+IG9yDQo+Pj4+PiB0aGUgY29udGFp bmVyIG93bmVycyB3YW50IHRvIGRlZmluZSBhdXRob3JpemF0aW9ucyBmb3IgdGhlaXINCj4+Pj4+ cmVzb3VyY2VzDQo+Pj4+PiBhbmQgZW5kcG9pbnRzLiINCj4+Pj4+DQo+Pj4+PiAoSSBpbnNlcnQg 4oCcYeKAnSwg4oCcYuKAnSwg4oCcY+KAnSBldGMuIHRvIGRpc3Rpbmd1aXNoIHRoZSBkaWZmZXJl bnQgdmVyc2lvbnMgb2YNCj4+Pj4+IHJlcXVpcmVtZW50cykNCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4g VGhlbiBTdGVmZmkgcHJvcG9zZWQgdG8gc3BsaXQgVTEuMWEgaW4gdGhlc2UgcmVxdWlyZW1lbnRz Og0KPj4+Pj4NCj4+Pj4+IChodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvYWNl L2N1cnJlbnQvbXNnMDA5OTIuaHRtbCkNCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4g4oCcVTEuMWI6IFJl c291cmNlIE93bmVycyB3YW50IHRvIGdyYW50IGRpZmZlcmVudCBhY2Nlc3MgcmlnaHRzIGZvcg0K Pj4+Pj50aGVpcg0KPj4+Pj4gcmVzb3VyY2VzIHRvIGRpZmZlcmVudCBwYXJ0aWVzLg0KPj4+Pj4N Cj4+Pj4+IFUxLjJiOiBDbGllbnQgT3duZXJzIHdhbnQgdG8gZGVmaW5lIGZvciB0aGVpciBjbGll bnRzIGlmIGFuZCBob3cgdGhleQ0KPj4+Pj4gYXJlDQo+Pj4+PiBhbGxvd2VkIHRvIGFjY2VzcyBy ZXNvdXJjZXMgaG9zdGVkIG9uIGEgUmVzb3VyY2UgU2VydmVyLiINCj4+Pj4NCj4+Pj4gSW4gZmFj dCBJIGRpZG4ndCB3YW50IHRvIHNwbGl0IFUxLjFhLiBZb3UsIEfDtnJhbiwgcHJvcG9zZWQgaW4N Cj4+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2FjZS9jdXJyZW50L21z ZzAwOTkxLmh0bWwgdG8NCj4+Pj4gcmVwbGFjZSBVMS4xIHdpdGggdHdvICJyZXF1aXJlbWVudHMi IGFzIHlvdSBjYWxsZWQgdGhlbS4gSSBhbSBub3QNCj4+Pj5oYXBweQ0KPj4+PiB3aXRoIHRoaXMg cHJvcG9zYWwgYnV0IHdvdWxkIGhhdmUgYWdyZWVkIHRvIGl0IGlmIGl0IGhlbHBlZCB0aGluZ3Mu DQo+Pj4+DQo+Pj4+IFRoZSBtZWFuaW5nIG9mIHRoZSBvcmlnaW5hbCBVMS4xIHByb2JsZW0gaXMg dGhhdCBwcmluY2lwYWxzIGluIHRoaXMNCj4+Pj51c2UNCj4+Pj4gY2FzZSB3YW50IHRvIGdyYW50 IGRpZmZlcmVudCBhdXRob3JpemF0aW9ucyB0byBkaWZmZXJlbnQgcGVvcGxlIC8NCj4+Pj4gZGV2 aWNlcyAvIHJlc291cmNlcyAobWVhbmluZyB0aGF0IGRldmljZXMgb2YgY29tcGFueSBBIGdldCBk aWZmZXJlbnQNCj4+Pj4gYWNjZXNzIHJpZ2h0cyB0aGVuIGRldmljZXMgb2YgY29tcGFueSBCKS4g SXQgc2VlbXMgdGhhdCBpdCBpcyBxdWl0ZQ0KPj4+PiBkaWZmaWN1bHQgdG8gZmluZCBhIG5ldXRy YWwgcGhyYXNpbmcgZm9yIHRoaXMgcHJvYmxlbS4NCj4+Pj4NCj4+Pj4gVGhlIHNwbGl0IG5vdyBz aG93cyBhIGNvbXBsZXRlbHkgZGlmZmVyZW50IGFzcGVjdCBvZiB0aGlzIHByb2JsZW06IHdlDQo+ Pj4+IGNhbiBwcm90ZWN0IHRoZSBjbGllbnQgc2lkZSBvciB3ZSBjYW4gcHJvdGVjdCB0aGUgc2Vy dmVyIHNpZGUgb3IgYm90aC4NCj4+Pj4gVGhlc2UgcmVhbGx5IGFyZSBzb2x1dGlvbiBzcGVjaWZp YyBhbmQgYXMgd2UgY2FuIHNlZSwgdGhpcyBsZWFkcyB0bw0KPj4+PiBwZW9wbGUgd2FudGluZyB0 byBkZWZlbmQgdGhlaXIgZmF2b3JpdGUgc29sdXRpb24uIEluc3RlYWQgb2Y6ICJ1c2Vycw0KPj4+ PiBzb21laG93IHdhbnQgdG8gZ3JhbnQgZGlmZmVyZW50IGF1dGhvcml6YXRpb25zIHRvIGRpZmZl cmVudCBwZW9wbGUiIHdlDQo+Pj4+IGFyZSBkZWVwIGludG8gYSBzb2x1dGlvbiBzcGFjZSBkaXNj dXNzaW9uIGFib3V0IHdoZXRoZXIgaXQgaXMgbW9yZQ0KPj4+PiB1c2VmdWwgdG8gcHJvdGVjdCB0 aGUgc2VydmVyIG9yIHRoZSBjbGllbnQgc2lkZSwgaWYgdGhlIGNsaWVudCBzaWRlDQo+Pj4+ZXZl bg0KPj4+PiBuZWVkcyBwcm90ZWN0aW9uIGFuZCBzbyBvbi4gSSB3b3VsZCBsaWtlIHRvIGVtcGhh c2l6ZSB0aGF0IHRoaXMgaXMgbm90DQo+Pj4+IHdoYXQgVTEuMSBpcyBhYm91dC4gTWF5YmUgd2Ug Y2FuIHN0aWxsIGZpbmQgYSBiZXR0ZXIgcGhyYXNpbmcgdGhhdA0KPj4+PmRvZXMNCj4+Pj4gbm90 IGluZGljYXRlIGEgc3BlY2lmaWMgc29sdXRpb24uDQo+Pj4+DQo+Pj4+IFRoZSBkaWZmZXJlbnQg cHJvcG9zYWxzIGZvciB0aGUgcGhyYXNpbmcgb2YgVTEuMSBpbmRpY2F0ZSBhIGRpZmZlcmVudA0K Pj4+PiBwcm9ibGVtOiBEbyB3ZSB3YW50IHRvIGRldmVsb3AgYSBzb2x1dGlvbiB0aGF0IGV4Y2x1 c2l2ZWx5IHByb3RlY3RzDQo+Pj4+IHJlc291cmNlcyBvciBkbyB3ZSBhbHNvIHdhbnQgdG8gY29u c2lkZXIgdGhlIGNsaWVudCBzaWRlPyBNb3N0IG9mIHVzDQo+Pj4+YXJlDQo+Pj4+IG1vcmUgZmFt aWxpYXIgd2l0aCB0aGUgcHJvdGVjdGlvbiBvZiByZXNvdXJjZXMgYmVjYXVzZSB3ZSBhbHJlYWR5 IGtub3cNCj4+Pj4gdGhhdCBmcm9tIHdlYiBzY2VuYXJpb3MuIEJ1dCBpbiB0aGVzZSBzY2VuYXJp b3Mgd2UgYWx3YXlzIGhhdmUgYSB1c2VyDQo+Pj4+IHRoYXQgcGVyZm9ybXMgYXV0aG9yaXphdGlv biBvbiB0aGUgY2xpZW50IHNpZGUuIEZvciBjb25zdHJhaW5lZA0KPj4+PiBlbnZpcm9ubWVudHMs IGl0IGlzIG5vdCBhbHdheXMgdGhhdCBzaW1wbGUuIFdlIG1pZ2h0IGhhdmUgdHJ1ZSBtYWNoaW5l DQo+Pj4+IHRvIG1hY2hpbmUgKE0yTSkgY29tbXVuaWNhdGlvbiB3aGVyZSBhIGRldmljZSBtdXN0 IGRlY2lkZSBmb3IgaXRzZWxmDQo+Pj4+IHdoZXRoZXIgc29tZXRoaW5nIGlzIGF1dGhvcml6ZWQg YnkgaXRzIHVzZXIgb3Igbm90LiBNb3Jlb3ZlciwgZGV2aWNlcw0KPj4+PiBtaWdodCBub3QgaGF2 ZSBkaXNwbGF5cyBhbmQgdGh1cyBpdCBtaWdodCBub3QgYmUgcG9zc2libGUgZm9yIHRoZSB1c2Vy DQo+Pj4+IHRvIGRpcmVjdGx5IGludGVyYWN0IHdpdGggdGhlIGRldmljZSBmb3IgYXV0aG9yaXph dGlvbi4gU29sdmluZyB0aGVzZQ0KPj4+PiBwcm9ibGVtcyBpcyBub3Qgb3B0aW9uYWwuIEFuZCBJ IHRoaW5rIGl0IGlzIGltcG9ydGFudCB0byBiZSBhd2FyZSBvZg0KPj4+PiB0aGVzZSBwcm9ibGVt cy4gQSBzb2x1dGlvbiBjYW4gZGVjaWRlIGlmIGFuZCBob3cgdG8gc29sdmUgdGhlbS4NCj4+Pj4N Cj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gUmVmZXJyaW5nIHRvIHRoZSBVMS4xYSwgSSBwcm9wb3NlZCB0 byBjbGFyaWZ5IHdoYXQgVTEuMWIgbWVhbnMgaW4NCj4+Pj4+dGVybXMNCj4+Pj4+IG9mDQo+Pj4+ PiB0aGUgYWN0b3JzIGFuZCByZXNvdXJjZXMgb2YgdGhlIHVzZSBjYXNlOg0KPj4+Pj4gKGh0dHA6 Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9hY2UvY3VycmVudC9tc2cwMTAwMC5odG1s KQ0KPj4+Pj4NCj4+Pj4+IOKAnFUxLjFjOiBSZXNvdXJjZSBPd25lcnMsIHN1Y2ggYXMgZnJ1aXQg dmVuZG9ycyBhbmQgY29udGFpbmVyIG93bmVycywNCj4+Pj4+IHdhbnQNCj4+Pj4+IHRvDQo+Pj4+ PiBncmFudCBkaWZmZXJlbnQgYWNjZXNzIHJpZ2h0cyB0byBkaWZmZXJlbnQgcGFydGllcyBmb3Ig dGhlaXINCj4+Pj4+cmVzcGVjdGl2ZQ0KPj4+Pj4gcmVzb3VyY2VzLCBzdWNoIGFzIHRlbXBlcmF0 dXJlcyBhbmQgZmFuIHNldHRpbmdzLiINCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gVGhpcyB3YXMgbm90 IGFncmVlZCwgc2VlIGRpc2N1c3Npb24gYWJvdXQgcmVzb3VyY2UgYW5kIGNsaWVudCBiZWxvdy4N Cj4+Pj4+DQo+Pj4+PiBXaXRoIHJlZ2FyZHMgdG8gVTEuMmIsIEkgcmVxdWVzdGVkIHRoYXQgdGhp cyBhYnN0cmFjdCBzdGF0ZW1lbnQNCj4+Pj4+c2hvdWxkDQo+Pj4+PiBiZQ0KPj4+Pj4gZXhlbXBs aWZpZWQgd2l0aCBhY3RvcnMgYW5kIGNsaWVudCBkZXZpY2VzIGZyb20gdGhpcyB1c2UgY2FzZSB0 bw0KPj4+Pj5hbGxvdw0KPj4+Pj4gZXZlcnlvbmUgdG8gZm9ybSBhbiBvcGluaW9uIGlmIHRoaXMg aXMgYSByZWxldmFudCBhY2Nlc3MgY29udHJvbA0KPj4+Pj4gcHJvYmxlbQ0KPj4+Pj4gaW4gdGhl IHNjb3BlIG9mIEFDRSBvciBub3QuIElmIHRoYXQgY2Fu4oCZdCBiZSBtYWRlLCB0aGVuIEkgdGhp bmsgdGhpcw0KPj4+Pj4gcmVxdWlyZW1lbnQgaXMgbGVzcyByZWxldmFudCBmb3IgdGhpcyB1c2Ug Y2FzZSBhbmQgY29uc2lkZXIgbGVhdmUgaXQNCj4+Pj4+IG91dC4NCj4+Pj4NCj4+Pj4gSW1hZ2lu ZSBhIHNwZWNpZmljIGltcGxlbWVudGF0aW9uIG9mIHRoZSBjb250YWluZXIgc2NlbmFyaW8gd2hl cmUgdGhlDQo+Pj4+IHRlbXBlcmF0dXJlIHNlbnNvciBpcyB0aGUgY2xpZW50IGFuZCB0aGUgZmFu IGFjdHVhdG9yIGlzIHRoZSBzZXJ2ZXIuDQo+Pj4+VGhlDQo+Pj4+IGZydWl0IHZlbmRvciB3YW50 cyB0byBtYWtlIHN1cmUgdGhhdCB0aGUgdGVtcGVyYXR1cmUgc2Vuc29yIHNlbmRzIHRoZQ0KPj4+ PiB0ZW1wZXJhdHVyZSB2YWx1ZXMgb25seSB0byBhdXRob3JpemVkIGZhbiBhY3R1YXRvciByZXNv dXJjZXMgYmVjYXVzZQ0KPj4+PnNoZQ0KPj4+PiBkb2Vzbid0IHdhbnQgdW5hdXRob3JpemVkIHBl b3BsZSB0byBnYWluIGtub3dsZWRnZSBhYm91dCB0aGUgc3RhdGUgb2YNCj4+Pj4gdGhlIGdvb2Rz LiBUaGUgY29udGFpbmVyIG93bmVyIHdhbnRzIHRvIG1ha2Ugc3VyZSB0aGF0IHRoZSBzZXJ2ZXIg b25seQ0KPj4+PiBhY2NlcHRzIGRhdGEgZnJvbSBhdXRob3JpemVkIGNsaWVudHMuIEluIHRoaXMg Y2FzZSwgYm90aCB0aGUgY2xpZW50DQo+Pj4+IG93bmVyIGFuZCB0aGUgcmVzb3VyY2Ugb3duZXIg d2lsbCBuZWVkIHRvIGRlZmluZSBhY2Nlc3MgcG9saWNpZXMuIFRoZQ0KPj4+PiBjbGllbnQgb3du ZXIgKHRoZSBmcnVpdCB2ZW5kb3IpIGRlZmluZXMgYSBydWxlIHRoYXQgc3RhdGVzIHRoYXQgdGhl DQo+Pj4+IGNsaWVudCAodGhlIHRlbXBlcmF0dXJlIHNlbnNvcikgaXMgYWxsb3dlZCB0byBkbyBh IFBVVCBvbiByZXNvdXJjZXMNCj4+Pj50aGF0DQo+Pj4+IGJlbG9uZyB0byBhIHNwZWNpZmljIGNv bnRhaW5lciBvd25lci4gVGhlIHJlc291cmNlIG93bmVyICh0aGUNCj4+Pj5jb250YWluZXINCj4+ Pj4gb3duZXIpIGRlZmluZXMgYSBydWxlIHRoYXQgc3RhdGVzIHRoYXQgY2xpZW50cyBvZiBhIGNl cnRhaW4gZnJ1aXQNCj4+Pj52ZW5kb3INCj4+Pj4gYXJlIGFsbG93ZWQgdG8gZG8gYSBQVVQgb24g dGhlaXIgcmVzb3VyY2VzLiBJZiB0aGUgdGVtcGVyYXR1cmUgc2Vuc29yDQo+Pj4+aXMNCj4+Pj4g bm90IGFibGUgdG8gZGVjaWRlIGlmIGEgcmVzb3VyY2UgaXMgYXV0aG9yaXplZCwgaXQgY2Fubm90 IGVuZm9yY2UgdGhlDQo+Pj4+IGF1dGhvcml6YXRpb24gZGVjaXNpb25zIG9mIGl0cyBvd25lci4N Cj4+Pj4NCj4+Pj4+DQo+Pj4+PiBOT1RFOiBJ4oCZbSBub3Qgc2F5aW5nIFUxLjJiIGlzIG5vdCBh IHBvc3NpYmxlIHNlY3VyaXR5IGNvbmNlcm4uIEnigJltDQo+Pj4+PiBxdWVzdGlvbmluZyB0aGF0 IGl0IGlzIGFuIGFjY2VzcyBjb250cm9sIHByb2JsZW0gYW5hbG9nb3VzIHRvIFUxLjFiLg0KPj4+ Pj4gVGhlDQo+Pj4+PiBvcmlnaW5hbCByZXF1aXJlbWVudCBmb3JtdWxhdGlvbiBVMS4xIChpbiB0 aGUgZHJhZnQpIGFuZCBVMS4xYSBibHVycw0KPj4+Pj4gdGhlDQo+Pj4+PiBkaXN0aW5jdGlvbiBi ZXR3ZWVuIHJlc291cmNlIGFuZCBjbGllbnQgYW5kIGdpdmVzIHRoZSBpbXByZXNzaW9uIHRoYXQN Cj4+Pj4+IHRoZXJlIGlzIGFuIGFuYWxvZ291cyBjbGllbnQgYWNjZXNzIGNvbnRyb2wgcHJvYmxl bSwgYnV0IEkgZG9u4oCZdCBzZWUNCj4+Pj4+IGFueQ0KPj4+Pj4gZXZpZGVuY2Ugb2YgdGhhdCBm cm9tIHRoZSB1c2UgY2FzZXMuIEFuZCB0aGUgY3VycmVudCB0ZXJtaW5vbG9neSBpcw0KPj4+Pj4g bWFraW5nDQo+Pj4+PiB0aGUgZGlzdGluY3Rpb24gZGlmZmljdWx0Lg0KPj4+Pj4NCj4+Pj4+IE5v dyB3ZSBtYWtlIHRoZSBzYW1lIGV4ZXJjaXNlIGluIHlvdXIgZXhhbXBsZSBiZWxvdy4NCj4+Pj4+ DQo+Pj4+Pj4NCj4+Pj4+PiBUaGUgcXVlc3Rpb24gdGhhdCBzdXJmYWNlZCBoZXJlIGlzIHdoZXRo ZXIgJ3ByaW5jaXBhbCcgaXMgdGhlIHJpZ2h0DQo+Pj4+Pj4gdGVybQ0KPj4+Pj4+IG9yIG5vdC4g VGhlIGRvY3VtZW50IGRlZmluZXMgcHJpbmNpcGFsIGFzICJBIHN1YmplY3Qgd2hvIGlzIGVpdGhl ciBhDQo+Pj4+Pj4gcmVzb3VyY2Ugb3duZXIgb3IgYSBjbGllbnQgb3duZXIgb3IgYm90aC4iDQo+ Pj4+Pj4NCj4+Pj4+PiBIZXJlIGlzIGEgc2xpZ2h0bHkgbW9kaWZpZWQgZXhhbXBsZSB1c2luZyBh IGRvb3IgbG9jayBzY2VuYXJpbyB0aGF0DQo+Pj4+Pj4gbWF5DQo+Pj4+Pj4gaGVscCB1cyBzZWUg dGhyb3VnaCB0aGlzIGNhc2UuIEltYWdpbmUgYSBmYW1pbHkgd2l0aCBhIGtpZDogQWxpY2UsDQo+ Pj4+Pj5Cb2INCj4+Pj4+PiBhbmQgdGhlaXIgeW91bmcgY2hpbGQgRXZlLg0KPj4+Pj4+DQo+Pj4+ Pj4gQWxpY2UgYW5kIEJvYiBib3VnaHQgb25lIG9mIHRoZXNlIEludGVybmV0IGNvbm5lY3RlZCBk b29yIGxvY2tzIGFuZA0KPj4+Pj4+IG5vdw0KPj4+Pj4+IHdhbnQgdG8gY29uZmlndXJlIGl0LiBU aGV5IHdhbnQgdG8gY29uZmlndXJlIGl0IGluIHN1Y2ggYSB3YXkgdGhhdA0KPj4+Pj4+YWxsDQo+ Pj4+Pj4gdGhyZWUgY2FuIGVudGVyIHRoZWlyIGhvdXNlIGp1c3QgdXNpbmcgdGhlaXIgc21hcnQg cGhvbmUgKGFuZCBhDQo+Pj4+Pj4gc3BlY2lhbGx5IGxvYWRlZCBhcHApLg0KPj4+Pj4+DQo+Pj4+ Pj4gV2hldGhlciB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXMgaW5jbHVkZWQgaW4gdGhlIGRv b3IgbG9jaw0KPj4+Pj4+IGl0c2VsZiBvcg0KPj4+Pj4+IGlzIHBhcnQgb2Ygc29tZSBvdGhlciBo b21lIGFwcGxpYW5jZSBkb2VzIG5vdCByZWFsbHkgbWF0dGVyIGZvciB0aGUNCj4+Pj4+PiBtb21l bnQuIEluIGFueSBjYXNlLCBBbGljZSBhbmQgQm9iIGNvbmZpZ3VyZSB0aGUgZG9vciBsb2NrIGlu IHN1Y2ggYQ0KPj4+Pj4+IHdheQ0KPj4+Pj4+IHRoYXQgRXZlIGlzIGdyYW50ZWQgYWNjZXNzLiBB bGljZSBhbmQgQm9iIGFyZSB0aGUgb3duZXIgb2YgdGhlDQo+Pj4+Pj4gcmVzb3VyY2UNCj4+Pj4+ PiAoPWRvb3IgbG9jaykgYnV0IGV2ZW4gaWYgdGhleSBkbyBub3QgJ293bicgdGhlIGRvb3IgbG9j ayAoYnV0IGhhdmUNCj4+Pj4+PiByYXRoZXIgcmVudGVkIGl0KSBkb2VzIG5vdCByZWFsbHkgbWF0 dGVyLg0KPj4+Pj4NCj4+Pj4+IEkgYWdyZWUgYWJvdXQg4oCcb3duZXJzaGlw4oCdLCBidXQgbGV0 4oCZcyBrZWVwIHRoZSB0ZXJtaW5vbG9neSBpbiB0aGlzDQo+Pj4+PiBleGFtcGxlLg0KPj4+Pj4N Cj4+Pj4+Pg0KPj4+Pj4+IFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBkb2VzIG5vdCBuZWNlc3Nh cmlseSBuZWVkIHRvIGtub3cgdGhhdCB0aGlzDQo+Pj4+Pj4gYWNjZXNzIGNvbnRyb2wgcG9saWN5 IGlzIGFib3V0ICJFdmUiLiBBbGwgaXQgY2FyZXMgaXMgdGhhdCB0aGVyZSBpcw0KPj4+Pj4+YW4N Cj4+Pj4+PiBlbnRyeSBpbiB0aGUgYWNjZXNzIGNvbnRyb2wgbGlzdCB0aGF0IHBvaW50cyB0byBz b21lIGNyZWRlbnRpYWwgb24NCj4+Pj4+PiBzb21lDQo+Pj4+Pj4gZGV2aWNlLiBUaGF0IGNyZWRl bnRpYWwgaGFwcGVucyB0byBwb2ludCB0byBhcHAgb24gdGhlIHNtYXJ0IHBob25lDQo+Pj4+Pj5F dmUNCj4+Pj4+PiBpcyB1c2luZy4NCj4+Pj4+Pg0KPj4+Pj4+IE5vdywgdGhlIHF1ZXN0aW9uIGlz IGhvdyBFdmUsIHdobyBpcyB0aGUgY2xpZW50IG93bmVyLCBmaXRzIGludG8NCj4+Pj4+PnRoYXQN Cj4+Pj4+PiBwaWN0dXJlLiBTaGUgd291bGQgdXNlIGhlciBwaG9uZSAoPWNsaWVudCkgdG8gcmVx dWVzdCBhY2Nlc3MgdG8gdGhlDQo+Pj4+Pj4gZG9vcg0KPj4+Pj4+IGJ1dCBzaGUgd291bGQgbm90 IGJlIGludm9sdmVkIGluIHByb3Zpc2lvbmluZyB0aGUgYWNjZXNzIGNvbnRyb2wNCj4+Pj4+PiBw b2xpY3kNCj4+Pj4+PiBhdCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuDQo+Pj4+Pj4NCj4+Pj4+ PiBEaWQgSSBjb3JyZWN0bHkgdW5kZXJzdG9vZCB0aGlzIGlzc3VlPw0KPj4+Pj4NCj4+Pj4+IEkg dGhpbmsgeW91IGFyZSBjb3JyZWN0IGluIHRoYXQgdGhlIGRpc2N1c3Npb24gaXMgaG93IHRoZSBj bGllbnQNCj4+Pj4+b3duZXINCj4+Pj4+IGZpdHMgaW50byB0aGUgcGljdHVyZS4NCj4+Pj4NCj4+ Pj4gSSB3b3VsZCBhbHNvIHRoaW5rIHRoYXQgdGhpcyBpcyB0aGUgcHJvYmxlbS4gRXZlIHVzZXMg aGVyIHNtYXJ0cGhvbmUNCj4+Pj50bw0KPj4+PiByZXF1ZXN0IGFjY2VzcyB0byB0aGUgZG9vciBh bmQgaXMgZ3JhbnRlZCBhY2Nlc3MgZGVwZW5kaW5nIG9uIEFsaWNlDQo+Pj4+YW5kDQo+Pj4+IEJv YnMgYXV0aG9yaXphdGlvbi4gRXZlIGhhcyBubyBpbmZsdWVuY2Ugb24gdGhlaXIgZGVjaXNpb24u IEluIHRoZQ0KPj4+PmRvb3INCj4+Pj4gbG9jayBjYXNlIHRoaXMgbWlnaHQgbm90IGEgYmlnIHBy b2JsZW0uIEV2ZSBhY3RpdmVseSB1c2VzIGhlcg0KPj4+PnNtYXJ0cGhvbmUNCj4+Pj4gdG8gaW50 ZXJhY3Qgd2l0aCB0aGUgZG9vciBsb2NrLiBUaGUgcGhvbmUgbWlnaHQgYWxzbyBkaXNwbGF5IHNv bWUga2luZA0KPj4+PiBvZiBkaWFsb2cgd2hlcmUgRXZlIGNhbiBkZWNpZGUgdG8gYWNjZXNzIHRo ZSBkb29yIGxvY2sgb3Igbm90Lg0KPj4+Pg0KPj4+PiBJZiBFdmUgZG9lc24ndCB1c2UgaGVyIHBo b25lIGJ1dCBhIGNvbnN0cmFpbmVkIGRldmljZSB0byBhY2Nlc3MsIGUuZy4NCj4+Pj4gc29tZSBz b3J0IG9mIGtleSBmb2IsIHNoZSBtaWdodCB3YW50IHRvIG1ha2Ugc3VyZSB0aGF0IGl0IGRvZXNu J3QNCj4+Pj4gcHJvdmlkZSBoZXIgY3JlZGVudGlhbHMgdG8gZXZlcnlvbmUgd2hvIGlzIGFza2lu Zy4NCj4+Pj4NCj4+Pj4+DQo+Pj4+PiBXaGV0aGVyIHRoZSBwaG9uZSBpcyBpbnZvbHZlZCBvciBu b3QgaW4gdHJhbnNwb3J0aW5nIGFjY2VzcyBjb250cm9sDQo+Pj4+PiBwb2xpY3kNCj4+Pj4+IG9y IG90aGVyIGF1dGhvcml6YXRpb24gaW5mb3JtYXRpb24gdG8gdGhlIHJlc291cmNlIHNlcnZlciBp cyBub3QgdGhlDQo+Pj4+PiBpc3N1ZS4NCj4+Pj4+DQo+Pj4+PiBPbmUgaXNzdWUgd2UgaGF2ZSBp cyBpZiB0aGUgZG9vciBsb2NrIGNhbiBiZSBjYWxsZWQg4oCcUmVzb3VyY2XigJ0gb3IgaWYNCj4+ Pj4+aXQNCj4+Pj4+IGlzDQo+Pj4+PiBjb21wbGV0ZWx5IGFyYml0cmFyeSB3aGljaCBpcyDigJxS ZXNvdXJjZSIgYW5kIHdoaWNoIGlzIOKAnENsaWVudOKAnS4gKEnigJltDQo+Pj4+PmluDQo+Pj4+ PiBmYXZvdXIgb2YgdGhlIGZvcm1lci4pDQo+Pj4+Pg0KPj4+Pj4gT25lIHRoaW5nIHdlIGRvIGFn cmVlIGFib3V0IGlzIHRoYXQgdGhlIHRlbmFudHMsIEFsaWNlIGFuZCBCb2IsDQo+Pj4+PnNob3Vs ZA0KPj4+Pj4gYmUNCj4+Pj4+IGFibGUgdG8gc2V0IGFjY2VzcyBwb2xpY2llcyBmb3IgdGhlIGxv Y2suIEkgdGhpbmsgdGhpcyBpcyB0aGUNCj4+Pj4+YW5hbG9ndWUNCj4+Pj4+IG9mDQo+Pj4+PiBV MS4xYi9jLiBCdXQgc2luY2Ugd2UgY2Fu4oCZdCBhZ3JlZWQgd2hldGhlciB0aGUgbG9jayBpcyDi gJxSZXNvdXJjZSIgb3INCj4+Pj4+IGNhbg0KPj4+Pj4gYWx0ZXJuYXRpdmVseSBiZSDigJxDbGll bnQiLCBJIGNhbuKAmXQgdXNlIHRoZSB0ZXJtIOKAnFJlc291cmNlIE93bmVy4oCdLg0KPj4+Pj5O b3INCj4+Pj4+IGNhbg0KPj4+Pj4gd2UgdXNlIHRoZSB0ZXJtIOKAnENsaWVudCBPd25lcuKAnS4g V2l0aCByZWdhcmRzIHRvIHRoaXMsIEkgaGF2ZSBiZWVuDQo+Pj4+PiBxdWVzdGlvbmluZyB0aGUg dXNlZnVsbmVzcyBvZiB0aGUgY3VycmVudCB0ZXJtaW5vbG9neSBpbiB0aGUgZHJhZnQsDQo+Pj4+ Pm9yDQo+Pj4+PiBob3cNCj4+Pj4+IGl0IGlzIGFwcGxpZWQuDQo+Pj4+DQo+Pj4+IEluIHRoZSB1 c2UgY2FzZXMgZG9jdW1lbnQsIHdlIGFyZSBkZWZpbmluZyB1c2UgY2FzZXMgZm9yIGNvbnN0cmFp bmVkDQo+Pj4+IGVudmlyb25tZW50cy4gV2hlcmUgbmVlZGVkLCB3ZSBhc3N1bWUgQ29BUCBhcyB0 aGUgdXNlZCBwcm90b2NvbC4gSW4NCj4+Pj5Db0FQDQo+Pj4+IHdlIGhhdmUgdHdvIGVuZHBvaW50 cywgdGhlIGNsaWVudCBhbmQgdGhlIHNlcnZlciwgdGhhdCBhcmUNCj4+Pj5jb21tdW5pY2F0aW5n DQo+Pj4+IHdpdGggZWFjaCBvdGhlci4gVGhlIHNlcnZlciBob3N0cyByZXNvdXJjZXMgdGhhdCBj YW4gYmUgYWNjZXNzZWQgYnkNCj4+Pj50aGUNCj4+Pj4gY2xpZW50LiBXZSBjb3VsZCBkZWZpbmUg dGhhdCBhIGRvb3IgbG9jayBNVVNUIGJlIGEgIENvQVAgc2VydmVyIGFuZA0KPj4+PnRoYXQNCj4+ Pj4gdGhlIGRldmljZSBhY2Nlc3NpbmcgdGhlIGRvb3IgbG9jayBNVVNUIGJlIGEgQ29BUCBjbGll bnQgb3IgdmljZQ0KPj4+PnZlcnNhLg0KPj4+PiBJZiB0aGVyZSBpcyBubyBzdHJvbmcgZXZpZGVu Y2UgdG8gZG8gc28sIEkgd291bGQgcmF0aGVyIG5vdCByZXN0cmljdA0KPj4+PiBDb0FQIGltcGxl bWVudGF0aW9ucyBpbiBzdWNoIGEgd2F5LiBJdCBzZWVtcyB3cm9uZyB0byBtZSB0byBzYXkgdGhh dA0KPj4+PiBDb0FQIGlzIGZsZXhpYmxlIGVub3VnaCB0byBhbGxvdyBmb3IgYWxsIGtpbmRzIG9m IHNldHRpbmdzIGJ1dA0KPj4+PiB1bmZvcnR1bmF0ZWx5IG91ciBhdXRob3JpemF0aW9uIHNvbHV0 aW9uIGRvZXMgbm90IGNvbnNpZGVyIHRoaXMNCj4+Pj4gZmxleGliaWxpdHkgd2hpY2ggaXMgd2h5 IENvQVAgaXMgbGVzcyBmbGV4aWJsZSBpZiB3ZSBhcmUgdXNpbmcNCj4+Pj4gYXV0aG9yaXphdGlv bi4NCj4+Pj4NCj4+Pj4+DQo+Pj4+PiBNYXliZSB3ZSBjYW4gdXNlIHRoZSBxdWFsaWZpY2F0aW9u IOKAnGxvY2stUmVzb3VyY2UiIGFuZCDigJxsb2NrLUNsaWVudCINCj4+Pj4+dG8NCj4+Pj4+IGRp c3Rpbmd1aXNoIGZyb20gb3RoZXIgcmVzb3VyY2VzIGFuZCBjbGllbnRzPyBBbmQgdGhlbiDigJxs b2NrLVJlc291cmNlDQo+Pj4+PiBPd25lcuKAnSAoQWxpY2UgYW5kIEJvYikgYW5kIOKAnGxvY2st Q2xpZW50IE93bmVy4oCdIChFdmUpIHdvdWxkIGFsc28gYmUNCj4+Pj4+d2VsbA0KPj4+Pj4gZGVm aW5lZD8NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gVGhlIG90aGVyIGlzc3VlIHJlbGF0ZXMgdG8gd2hh dCBpcyB0aGUgcHJvYmxlbSBmb3IgRXZlLiBDb25zaWRlciB0aGUNCj4+Pj4+IGFuYWxvZ3VlIG9m IFUxLjJiIGFib3ZlIGluIHRoaXMgc2V0dGluZzoNCj4+Pj4+DQo+Pj4+PiBVMS4yYjogIkV2ZSB3 YW50cyB0byBkZWZpbmUgZm9yIGhlciBwaG9uZSBpZiBhbmQgaG93IGl0IGlzIGFsbG93IHRvDQo+ Pj4+PiByZXF1ZXN0IHRoZSBsb2NrIHRvIGJlIG9wZW5lZC4iDQo+Pj4+Pg0KPj4+Pj4gVG8gbWUg aXQgaXMgcXVpdGUgY2xlYXIgdGhhdCB0aGlzIGlzIGFuIGF3a3dhcmQgd2F5IG9mIGZvcmNpbmcg YW4NCj4+Pj4+IGFjY2Vzcw0KPj4+Pj4gY29udHJvbCBwcm9ibGVtIGZvcm11bGF0aW9uIGludG8g d2hhdCBpc27igJl0LiBXaGVuIEV2ZSB3YW50cyB0byBvcGVuIGENCj4+Pj4+IGxvY2ssIHNoZSBw cmVzc2VzIGEgYnV0dG9uIGluIHRoZSBhcHAsIHRoZXJlYnkgYXV0aG9yaXplcyB0aGUNCj4+Pj4+ cmVxdWVzdC4NCj4+Pj4+IFRoZXJlIGlzIG5vIG5lZWQgdG8gc29sdmUgdGhpcyB3aXRoIGFjY2Vz cyBjb250cm9sIHBvbGljaWVzLA0KPj4+Pj50cmFuc3BvcnQNCj4+Pj4+IGF1dGhvcml6YXRpb24g aW5mb3JtYXRpb24sIGVuZm9yY2VtZW50IGV0Yy4gIFRoZXJlIGlzIGEgbmF0dXJhbA0KPj4+Pj4g YXN5bW1ldHJ5DQo+Pj4+PiB3aGljaCBpcyBjbGVhcmx5IGlsbHVzdHJhdGVkIGluIHRoZSB1c2Ug Y2FzZXMuIFdlIHNob3VsZCBub3QgaGlkZQ0KPj4+Pj50aGF0DQo+Pj4+PiBiZWhpbmQgc3RyYW5n ZSB0ZXJtaW5vbG9neSBhbmQgZm9ybXVsYXRpb25zLg0KPj4+Pg0KPj4+PiBZZXMsIGV4YWN0bHks IEV2ZSBpcyBhdXRob3JpemluZyB0aGUgcmVxdWVzdC4gQW5kIGluIHRoaXMgc3BlY2lmaWMNCj4+ Pj4gc2NlbmFyaW8gaW1wbGljaXQgYXV0aG9yaXphdGlvbiAoYW4gYXV0aGVudGljYXRlZCBkZXZp Y2UgaXMNCj4+Pj5hdXRob3JpemVkKQ0KPj4+PiBtaWdodCBiZSBnb29kIGVub3VnaC4gU2luY2Ug RXZlIGNhbiBkZWNpZGUgd2hhdCBoZXIgc21hcnRwaG9uZSBpcw0KPj4+PiBzdXBwb3NlZCB0byBk bywgdGhlcmUgaXMgbm8gbmVlZCBmb3IgbW9yZSBzb3BoaXN0aWNhdGVkIGF1dGhvcml6YXRpb24N Cj4+Pj4gcG9saWNpZXMuIFRoaXMgaXMgZGlmZmVyZW50IGZvciBvdGhlciB1c2UgY2FzZXMuDQo+ Pj4+DQo+Pj4+IElmIHlvdSB0aGluayBhYm91dCBpdCwgdGhlcmUgaXMgYWxzbyBubyBuZWVkIGZv ciBzb3BoaXN0aWNhdGVkDQo+Pj4+IGF1dGhvcml6YXRpb24gb24gdGhlIGRvb3IgbG9jayBzaWRl LCBlaXRoZXIuIEl0IG1pZ2h0IGJlIHN1ZmZpY2llbnQNCj4+Pj5pZiBhDQo+Pj4+IGRldmljZSB0 aGF0IGNhbiBiZSBhdXRoZW50aWNhdGVkIGlzIGF1dGhvcml6ZWQgdG8gb3BlbiB0aGUgZG9vci4g SW4NCj4+Pj50aGlzDQo+Pj4+IGNhc2UsIGltcGxpY2l0IGF1dGhvcml6YXRpb24gaXMgc3VmZmlj aWVudCBvbiBib3RoIHNpZGVzLiBBZ2FpbiB0aGlzDQo+Pj4+aXMNCj4+Pj4gZGlmZmVyZW50IGZv ciBvdGhlciB1c2UgY2FzZXMuDQo+Pj4+DQo+Pj4+IEJlc3QgcmVnYXJkcywNCj4+Pj4gU3RlZmZp DQo+Pj4NCj4+Pg0KPj4+DQo+PiANCj4NCg0K From nobody Thu Mar 5 23:45: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 CF11E1ACD13 for ; Thu, 5 Mar 2015 23:45:56 -0800 (PST) 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 oFzkr28qQ6La for ; Thu, 5 Mar 2015 23:45:55 -0800 (PST) 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 8BBF71ACD11 for ; Thu, 5 Mar 2015 23:45:54 -0800 (PST) X-AuditID: c1b4fb3a-f79036d000001e94-93-54f95b2f8c32 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id CC.86.07828.F2B59F45; Fri, 6 Mar 2015 08:45:52 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.70]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0210.002; Fri, 6 Mar 2015 08:45:52 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Stefanie Gerdes , "Ace@ietf.org" Thread-Topic: [Ace] Authorization on the client side Thread-Index: AQHQVqpqTif+C3cGv0q2foXO5/I1WJ0Mr5aAgADSJgCAAZQQAA== Date: Fri, 6 Mar 2015 07:45:50 +0000 Message-ID: References: <54F75101.4050008@tzi.de> <54F8164A.4080801@tzi.de> In-Reply-To: <54F8164A.4080801@tzi.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-ID: <367B28A2FABE8F418B9C9C8AD7794C52@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGfG3Rtcg+meIwdO57Bbfv/UwW2y8eJfR gcljyZKfTB7b3n5lDmCK4rJJSc3JLEst0rdL4Mp4e6W2YIJKRf+k10wNjDOUuxg5OSQETCT2 zH3LBmGLSVy4tx7I5uIQEjjCKDHj/ykoZxGjxO9dS9hBqtgEXCQeNDxiArFFBJwklm77y9LF yMEhLGAs0XZHESJsIjH9QA8bSBikZGFPHUiYRUBF4tPjh2BTeAUsJB59OAg2RUggT+LB0wss IDangJrE97l7wO5hBLrn+6k1YDXMAuISt57MZ4K4U0BiyZ7zzBC2qMTLx/9YQWxRAT2Jldeb oH5Rklh0+zMTyAnMApoS63fpQ4yxljh1ezYrhK0oMaUb5hxBiZMzn7BMYBSfhWTbLITuWUi6 ZyHpnoWkewEj6ypG0eLU4uLcdCMjvdSizOTi4vw8vbzUkk2MwDg7uOW31Q7Gg88dDzEKcDAq 8fAaSPwMEWJNLCuuzD3EKM3BoiTOa2d8KERIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD4yI1 9xefKv8sUZrLbRUvGKbAVs2pp3748Mwu9rYVLhbqC9TupYm2+zb6dF+3jjlYrXLzT02+6L6q SUJpYvxOTUXivGdjTx8INoni5u+MYZ7+e+9HL/vZ7S1PbP84fvxc4vNim+yRG2sZfEMMDr3W M1HcknP77w6nJ+Uz1Mr5In+vOtM0ZcITJZbijERDLeai4kQAaSzVrpQCAAA= Archived-At: Subject: Re: [Ace] Authorization on the client side 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, 06 Mar 2015 07:45:57 -0000 SGkgU3RlZmZpLA0KDQpJIHN5bXBhdGhpc2Ugd2l0aCB0cnlpbmcgdG8gc3VtbWFyaXplLg0KDQpJ IGFkbWl0IHRoYXQgSSBjYWxsZWQgcmVxdWVzdGluZyB0byBvcGVuIGEgbG9jayDigJxhdXRob3Jp emF0aW9u4oCdLiBBDQptb21lbnRhcnkgbGFwc2Ugb2YgcmVhc29uLiBUaGlzIGlzIGEga25vd24g cmlzayB3aGVuICB3b3JraW5nIHdpdGggcHJvb2YNCmJ5IGNvbnRyYWRpY3Rpb24uIElmIHlvdSBy ZWZsZWN0IG9uIGl0LCBpZiBldmVyeSBwb3RlbnRpYWwgcmVxdWVzdCBvcg0KYWN0aW9uIGlzIGlu dGVycHJldGVkIGFzIGF1dGhvcml6YXRpb24sIHRoZXJlIGlzIG5vdCBtdWNoIGxlZnQgdGhhdCBp cyBub3QNCmF1dGhvcml6YXRpb24uIFNvIEkgdGFrZSB0aGF0IGJhY2suIEkgd291bGQgbm90IGNh bGwgZGVjaWRpbmcgd2hldGhlcg0KcmVxdWVzdGluZyBhIGxvY2sgdG8gYmUgb3BlbmVkIHRvIGJl IGFuIGF1dGhvcml6YXRpb24gcHJvYmxlbS4NCg0KVGhlIG90aGVyIGV4YW1wbGVzIEkgbWVudGlv bmVkIHNlcnZlZCB0aGUgc2FtZSBwdXJwb3NlOiB0aGV5IGlsbHVzdHJhdGUgYQ0KbG90IG9mIHRo aW5ncyBvbiB0aGUgY2xpZW50IHNpZGUgdGhhdCBhbmFsb2dvdXNseSB3b3VsZCBiZSBjYWxsZWQN CmF1dGhvcml6YXRpb24sIGFuZCBmb3IgdGhhdCByZWFzb24gc2hvdWxkIG5vdCBiZSBjYWxsZWQg YXV0aG9yaXphdGlvbi4NCg0KQmVzdCByZWdhcmRzLA0KR8O2cmFuDQoNCg0KT24gMjAxNS0wMy0w NSAwOTozOSwgIlN0ZWZhbmllIEdlcmRlcyIgPGdlcmRlc0B0emkuZGU+IHdyb3RlOg0KDQo+SGkg R8O2cmFuLA0KPg0KPkkgZGlkbid0IGZvcmdldCBvdXIgZGlzY3Vzc2lvbi4gQnV0IGl0IHdvdWxk IGJlIGhlbHBmdWwgdG8gc3VtbWFyaXplIHRoZQ0KPnRoaW5ncyB3ZSBhZ3JlZWQgb24uIFlvdSBz YWlkIHRoYXQgeW91IGFncmVlIHRoYXQgdGhlcmUgaXMgYW4NCj5hdXRob3JpemF0aW9uIHByb2Js ZW0gb24gdGhlIGNsaWVudCBzaWRlLiBZb3UgYWxzbyBhZ3JlZSB0aGF0IHdlIGRvbid0DQo+bmVl ZCBhIHNvcGhpc3RpY2F0ZWQgYXV0aG9yaXphdGlvbiBtZWNoYW5pc20gdG8gc29sdmUgZXZlcnkN Cj5hdXRob3JpemF0aW9uIHByb2JsZW0uDQo+DQo+SW4geW91ciBlLW1haWwsIHlvdSBsaXN0ZWQg YWRkaXRpb25hbCBhdXRob3JpemF0aW9uIHByb2JsZW1zIHRoYXQgYXJlDQo+bm90IHBhcnQgb2Yg dGhlIGN1cnJlbnQgZGlzY3Vzc2lvbi4gSSBkb24ndCBzZWUgaG93IGRpc2N1c3NpbmcgdGhlc2UN Cj5oZWxwcyB0aGluZ3MuDQo+DQo+QmVzdCByZWdhcmRzLA0KPlN0ZWZmaQ0KPg0KPg0KPg0KPk9u IDAzLzA0LzIwMTUgMDg6MDcgUE0sIEfDtnJhbiBTZWxhbmRlciB3cm90ZToNCj4+IEhpIFN0ZWZm aSwNCj4+DQo+PiBJIGRpc2FncmVlLiAgSWYgeW91IHJlY2FsbCBmcm9tDQo+PiBodHRwOi8vd3d3 LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvYWNlL2N1cnJlbnQvbXNnMDA5OTUuaHRtbA0KPj4g SSBsaXN0ZWQgYSBudW1iZXIgb2Yg4oCcYXV0aG9yaXphdGlvbiBwcm9ibGVtc+KAnSBvbiB0aGUg Y2xpZW50IHNpZGUsIG5vbmUNCj4+b2YNCj4+IHdoaWNoIGlzIG9mIHRoZSBjb25jZXJuIG9mIEFD RSBJTUhPLiBUaGUgc2FtZSBhcHBsaWVzIHRoZSBwcm9ibGVtIHlvdQ0KPj4gbGlzdCwgY29ycmVz cG9uZGluZyB0byBVMS4yYiBvZg0KPj4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL2FjZS9jdXJyZW50L21zZzAxMDE5Lmh0bWwuDQo+Pg0KPj4gSnVzdCBiZWNhdXNlIEkgaGF2 ZW7igJl0IGhhZCB0aW1lIHRvIGFuc3dlciB0aGlzIG1haWwgdGhyZWFkIHRvZGF5IGRvZXNu4oCZ dA0KPj4gbWVhbiB0aGF0IHlvdSBjYW4gZm9yZ2V0IGFib3V0IG91ciBsYXN0IG1vbnRocyBvZiBk aXNjdXNzaW9ucy4gSeKAmWxsIGJlDQo+PiBiYWNrLg0KPj4NCj4+DQo+PiBCZXN0IHJlZ2FyZHMs DQo+PiBHw7ZyYW4NCj4+DQo+Pg0KPj4NCj4+DQo+PiBPbiAyMDE1LTAzLTA0IDE5OjM3LCAiU3Rl ZmFuaWUgR2VyZGVzIiA8Z2VyZGVzQHR6aS5kZT4gd3JvdGU6DQo+Pg0KPj4+IEhpIGFsbCwNCj4+ Pg0KPj4+IFdoYXQgSSBnZXQgZnJvbSB0aGUgZGlzY3Vzc2lvbiBpcyB0aGF0IHdlIGFncmVlIHRo YXQgdGhlcmUgaXMgYW4NCj4+PiBhdXRob3JpemF0aW9uIHByb2JsZW0gb24gdGhlIGNsaWVudCBz aWRlLiBXZSBhbHNvIGFncmVlIHRoYXQgZm9yIHNvbWUNCj4+PiBhdXRob3JpemF0aW9uIHByb2Js ZW1zIHdlIGRvbid0IG5lZWQgYSBzb3BoaXN0aWNhdGVkIGF1dGhvcml6YXRpb24NCj4+PiBtZWNo YW5pc20uDQo+Pj4NCj4+PiBTbyBtYXliZSB3ZSBjYW4gcG9zdHBvbmUgZnVydGhlciBkaXNjdXNz aW9ucyBhYm91dCBzb2x1dGlvbnMgYW5kIGp1c3QNCj4+PiBmaW5pc2ggdGhlIHVzZSBjYXNlcyBk cmFmdD8NCj4+Pg0KPj4+IFdlIGNhbiBrZWVwIHRoZSBhdXRob3JpemF0aW9uIHByb2JsZW0gb24g dGhlIGNsaWVudCBzaWRlIGluIHRoZSBwcm9ibGVtDQo+Pj4gc3VtbWFyeSBzZWN0aW9ucy4gTW9y ZW92ZXIsIHdlIGNhbiBhZGQgdGhlIGZvbGxvd2luZyB0byBzZWN0aW9uIDMuMg0KPj4+IChDb25m aWd1cmF0aW9uIG9mIEFjY2VzcyBQZXJtaXNzaW9ucyk6ICJFbmRwb2ludHMgbmVlZCB0byBiZSBl bmFibGVkIHRvDQo+Pj4gZW5mb3JjZSB0aGUgYXV0aG9yaXphdGlvbiBwb2xpY2llcyBvZiB0aGVp ciBwcmluY2lwYWxzLiBJbiBzb21lIGNhc2VzLA0KPj4+IGF1dGhvcml6YXRpb24gcHJvYmxlbXMg bWlnaHQgYmVpIHNvbHZlZCBieSBpbXBsaWNpdCBhdXRob3JpemF0aW9uIChhbGwNCj4+PiBhdXRo ZW50aWNhdGVkIGVudGl0aWVzIGFyZSBhdXRob3JpemVkKS4iDQo+Pj4NCj4+PiBXaGF0IGRvIHlv dSB0aGluaz8NCj4+Pg0KPj4+IEJlc3QgcmVnYXJkcw0KPj4+IFN0ZWZmaQ0KPj4+DQo+Pj4gLS0N Cj4+PiBTdGVmYW5pZSBHZXJkZXMJCQlUZWw6ICs0OSA0MjEgMjE4IDYzOTA2DQo+Pj4gVFpJIFVu aXZlcnNpdMOkdCBCcmVtZW4JCUUtTWFpbDogZ2VyZGVzQHR6aS5kZQ0KPj4+IEJpYmxpb3RoZWtz dHIuIDEsIE1aSCA1MTUwDQo+Pj4gMjgzNTkgQnJlbWVuLCBHZXJtYW55DQo+Pj4NCj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IEFjZSBtYWls aW5nIGxpc3QNCj4+PiBBY2VAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2FjZQ0KPj4NCj4+DQo+Pg0KPg0KPi0tIA0KPlN0ZWZhbmllIEdlcmRlcwkJ CVRlbDogKzQ5IDQyMSAyMTggNjM5MDYNCj5UWkkgVW5pdmVyc2l0w6R0IEJyZW1lbgkJRS1NYWls OiBnZXJkZXNAdHppLmRlDQo+QmlibGlvdGhla3N0ci4gMSwgTVpIIDUxNTANCj4yODM1OSBCcmVt ZW4sIEdlcm1hbnkNCg0K From nobody Fri Mar 6 02:22: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 D8F831A87C8 for ; Fri, 6 Mar 2015 02:22:07 -0800 (PST) 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 uZZ2e-4xnw9s for ; Fri, 6 Mar 2015 02:22:06 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A6C91A87C3 for ; Fri, 6 Mar 2015 02:22:05 -0800 (PST) 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 t26AM1Mh020680; Fri, 6 Mar 2015 11:22:01 +0100 (CET) Received: from [IPv6:2001:638:708:30da:a0e1:77b7:e892:2e40] (unknown [IPv6:2001:638:708:30da:a0e1:77b7:e892:2e40]) (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 3kz4kK13bYz2l0X; Fri, 6 Mar 2015 11:22:01 +0100 (CET) Message-ID: <54F97FC5.4020305@tzi.de> Date: Fri, 06 Mar 2015 11:21:57 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= , Hannes Tschofenig , "Ace@ietf.org" References: <54F5B1F2.6050205@gmx.net> <54F616CF.20607@tzi.de> <54F81652.6040102@tzi.de> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] U1.2 in Use Case Document 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, 06 Mar 2015 10:22:08 -0000 Hi Göran, On 03/06/2015 07:51 AM, Göran Selander wrote: > Hi Steffi, > > We need a terminology for assets and stakeholders in the use cases to > describe the relevant access control policy problems and make security > considerations. > > I propose to call all sensors and actuators (or rather assets provided by > these) “Resources”. This allows a distinction between parties providing > these assets and parties accessing these assets. In this way we can > discuss the access control policies on the asset providing side without > forcing an access control policy problem onto what isn’t, on the asset > accessing side. > > Is this somehow contradicting a solution based on CoAP? Let's use an example. Imagine a container scenario where the temperature sensor is the CoAP client and the fan actuator is the CoAP server. If you want to represent both the sensor values and the actuator settings by resources, this does not fit to CoAP where only the server has resources. It might be confusing for people if you want to distinguish between authorization resources and CoAP resources. The interesting question for the use cases document is how things work in CoAP (or other protocols that serve the same purpose). We can discuss the solution design later when we know what the problems are. > > If so, why isn't there an associated contradiction between OAuth and HTTP? > (Or is there?) HTTP was designed for web scenarios and not for constrained environments. CoAP was designed to better address the special characteristics of constrained environments. OAuth was also designed for web scenarios. In web scenarios we have an active user. We can solve authorization problems by asking the user. The use cases show that we don't always have an active user in constrained environments. We need to deal with this fact (or we don't but then we likely will not find the best solution). Best regards, Steffi From nobody Fri Mar 6 03:56: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 9F13F1ACDA7 for ; Fri, 6 Mar 2015 03:56:35 -0800 (PST) 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 NGxGHBvNGYSI for ; Fri, 6 Mar 2015 03:56:34 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D2AA1ACDA2 for ; Fri, 6 Mar 2015 03:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t26BuTU1023601; Fri, 6 Mar 2015 12:56:29 +0100 (CET) Received: from [IPv6:2001:638:708:30da:a0e1:77b7:e892:2e40] (unknown [IPv6:2001:638:708:30da:a0e1:77b7:e892:2e40]) (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 3kz6qK0rDmz2l4r; Fri, 6 Mar 2015 12:56:29 +0100 (CET) Message-ID: <54F995EC.9000508@tzi.de> Date: Fri, 06 Mar 2015 12:56:28 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Hannes Tschofenig , =?windows-1252?Q?G=F6r?= =?windows-1252?Q?an_Selander?= , "Ace@ietf.org" References: <54F5B1F2.6050205@gmx.net> <54F616CF.20607@tzi.de> <54F81652.6040102@tzi.de> <54F8181E.7080304@gmx.net> In-Reply-To: <54F8181E.7080304@gmx.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] U1.2 in Use Case Document 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, 06 Mar 2015 11:56:35 -0000 Hi Hannes, On 03/05/2015 09:47 AM, Hannes Tschofenig wrote: > > In terms of listing the requirements in reference to the use cases, such > as saying "fruit vendors want to grant different access rights to > different parties to measurements of goods temperatures" sounds OK to > me. The text in the use case should anyway say what rule the fruit > vendor plays. > I already suggested an update of the problem summary section a while ago in http://www.ietf.org/mail-archive/web/ace/current/msg00982.html that favors the real actors where possible: "U1.1 Principals such as the fruit vendor, the transloading personnel or the container owners want to define authorizations for their resources and endpoints." If the term "Principal" is offending for some reason, we can replace this with: U1.1 Fruit vendors, transloading personnel and container owners want to define authorizations for their resources and endpoints. "U1.2 The fruit vendor requires the integrity of the sensor data that pertains the state of the goods for climate control and to ensure the quality of the monitored recordings. U1.3 The container owner requires the integrity of the sensor data that is used for climate control. U1.4 The fruit vendor requires the confidentiality of the sensor data that pertains the state of the goods. U1.5 The fruit vendor may have several types of data that may be controlled by the same endpoint, e.g., sensor data and the data used for logistics. U1.6 The fruit vendor requires the confidentiality of the data that is used to locate the goods. U1.7 The fruit vendor requires the integrity of the data that is used to locate the goods. U1.8 The transloading personnel requires the integrity of the data that is used to locate the goods. U1.9 The container owner and the fruit vendor may not be present at the time of access and cannot manually intervene in the authorization process. U1.10 The principals want to grant temporary access permissions to a party." We can replace this with: U1.10 The fruit vendor, container owner and transloading company want to grant temporary access permissions to a party. "U1.11 Messages between client and resource server might need to be forwarded over multiple hops. U1.12 The constrained devices might not always be able to reach the Internet." What do you think? Best regards, Steffi From nobody Fri Mar 6 04:15: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 066CF1ACDB8 for ; Fri, 6 Mar 2015 04:14:59 -0800 (PST) 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 Xqg9Gkhg0wav for ; Fri, 6 Mar 2015 04:14:57 -0800 (PST) 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 4C7181ACDB3 for ; Fri, 6 Mar 2015 04:14:57 -0800 (PST) X-AuditID: c1b4fb25-f79b76d00000113a-1c-54f99a3fff49 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 4F.A5.04410.F3A99F45; Fri, 6 Mar 2015 13:14:55 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.70]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0210.002; Fri, 6 Mar 2015 13:14:54 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Stefanie Gerdes , Hannes Tschofenig , "Ace@ietf.org" Thread-Topic: [Ace] U1.2 in Use Case Document Thread-Index: AQHQVbL1RkiN6OYzzEyLTf3fE9ZKCp0K/GYAgAAliYCAAe0ZgIAAdKwAgAGEugCAACoogIAAMFIA Date: Fri, 6 Mar 2015 12:14:54 +0000 Message-ID: References: <54F5B1F2.6050205@gmx.net> <54F616CF.20607@tzi.de> <54F81652.6040102@tzi.de> <54F97FC5.4020305@tzi.de> In-Reply-To: <54F97FC5.4020305@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.17] Content-Type: text/plain; charset="utf-8" Content-ID: <9936EC4DEB2EBE4496509BCE2EE0C056@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZGfG3Rtd+1s8Qg+ZtMhbfv/UwW2y8eJfR YunOe6wOzB6LN+1n81iy5CeTx7a3X5kDmKO4bFJSczLLUov07RK4MhauKirYIlnx5fV8xgbG BxJdjJwcEgImEkvv3WeBsMUkLtxbzwZiCwkcYZTo6naAsBcxSvRM5gex2QRcJB40PGICsUUE iiWmTnnCCGILC+hIbP27A8jmAIrrSlxf7wVREiUx59dhsBIWARWJyW3tYK28AhYSPa0TWLsY uYDG/2eUWLj7DNheTgE1iUtHtrGD2IxA93w/tQasgVlAXOLWk/lMEHcKSCzZc54ZwhaVePn4 HyuILSqgJ7HyehMbyA0SAooSy/vlQExmAU2J9bv0IaZYS/y/+JkdwlaUmNL9kB3iHEGJkzOf sExgFJ+FZNkshO5ZSLpnIemehaR7ASPrKkbR4tTipNx0I2O91KLM5OLi/Dy9vNSSTYzAyDu4 5bfqDsbLbxwPMQpwMCrx8BpI/AwRYk0sK67MPcQozcGiJM5rZ3woREggPbEkNTs1tSC1KL6o NCe1+BAjEwenVAOjvSOPZd2zS61Fh27XbF24tllqZlGti6uXou3CzEYXnkXrvn858HuN7Oyz W5YsFL24J/Lkpj0qTbLpjUvvXI3b8aT8Trrpy6rNJq/ZHkbOS5dvKW9Zw7H5hHZx/WmrpWET wy2/FD1mU1j5/MBjPwM2Hod/a6+vONX+LMnN5rWwsXjvA9WbMcfmKbEUZyQaajEXFScCADUa To+dAgAA Archived-At: Subject: Re: [Ace] U1.2 in Use Case Document 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, 06 Mar 2015 12:14:59 -0000 SGkgU3RlZmZpLA0KDQpPbiAyMDE1LTAzLTA2IDExOjIxLCAiU3RlZmFuaWUgR2VyZGVzIiA8Z2Vy ZGVzQHR6aS5kZT4gd3JvdGU6DQoNCj5IaSBHw7ZyYW4sDQo+DQo+T24gMDMvMDYvMjAxNSAwNzo1 MSBBTSwgR8O2cmFuIFNlbGFuZGVyIHdyb3RlOg0KPj4gSGkgU3RlZmZpLA0KPj4NCj4+IFdlIG5l ZWQgYSB0ZXJtaW5vbG9neSBmb3IgYXNzZXRzIGFuZCBzdGFrZWhvbGRlcnMgaW4gdGhlIHVzZSBj YXNlcyB0bw0KPj4gZGVzY3JpYmUgdGhlIHJlbGV2YW50IGFjY2VzcyBjb250cm9sIHBvbGljeSBw cm9ibGVtcyBhbmQgbWFrZSBzZWN1cml0eQ0KPj4gY29uc2lkZXJhdGlvbnMuDQo+Pg0KPj4gSSBw cm9wb3NlIHRvIGNhbGwgYWxsIHNlbnNvcnMgYW5kIGFjdHVhdG9ycyAob3IgcmF0aGVyIGFzc2V0 cyBwcm92aWRlZA0KPj5ieQ0KPj4gdGhlc2UpIOKAnFJlc291cmNlc+KAnS4gVGhpcyBhbGxvd3Mg YSBkaXN0aW5jdGlvbiBiZXR3ZWVuIHBhcnRpZXMgcHJvdmlkaW5nDQo+PiB0aGVzZSBhc3NldHMg YW5kIHBhcnRpZXMgYWNjZXNzaW5nIHRoZXNlIGFzc2V0cy4gSW4gdGhpcyB3YXkgd2UgY2FuDQo+ PiBkaXNjdXNzIHRoZSBhY2Nlc3MgY29udHJvbCBwb2xpY2llcyBvbiB0aGUgYXNzZXQgcHJvdmlk aW5nIHNpZGUgd2l0aG91dA0KPj4gZm9yY2luZyBhbiBhY2Nlc3MgY29udHJvbCBwb2xpY3kgcHJv YmxlbSBvbnRvIHdoYXQgaXNu4oCZdCwgb24gdGhlIGFzc2V0DQo+PiBhY2Nlc3Npbmcgc2lkZS4N Cj4+DQo+PiBJcyB0aGlzIHNvbWVob3cgY29udHJhZGljdGluZyBhIHNvbHV0aW9uIGJhc2VkIG9u IENvQVA/DQo+DQo+TGV0J3MgdXNlIGFuIGV4YW1wbGUuIEltYWdpbmUgYSBjb250YWluZXIgc2Nl bmFyaW8gd2hlcmUgdGhlIHRlbXBlcmF0dXJlDQo+c2Vuc29yIGlzIHRoZSBDb0FQIGNsaWVudCBh bmQgdGhlIGZhbiBhY3R1YXRvciBpcyB0aGUgQ29BUCBzZXJ2ZXIuIElmDQo+eW91IHdhbnQgdG8g cmVwcmVzZW50IGJvdGggdGhlIHNlbnNvciB2YWx1ZXMgYW5kIHRoZSBhY3R1YXRvciBzZXR0aW5n cw0KPmJ5IHJlc291cmNlcywgdGhpcyBkb2VzIG5vdCBmaXQgdG8gQ29BUCB3aGVyZSBvbmx5IHRo ZSBzZXJ2ZXIgaGFzDQo+cmVzb3VyY2VzLiBJdCBtaWdodCBiZSBjb25mdXNpbmcgZm9yIHBlb3Bs ZSBpZiB5b3Ugd2FudCB0byBkaXN0aW5ndWlzaA0KPmJldHdlZW4gYXV0aG9yaXphdGlvbiByZXNv dXJjZXMgYW5kIENvQVAgcmVzb3VyY2VzLg0KDQpTbyB0aGVyZSBhcmUgdHdvIGRpZmZlcmVudCBh Y2Nlc3MgY29udHJvbCBwcm9ibGVtcywgZWFjaCBoYXZlIHRoZWlyDQpyZXNvdXJjZXMuIEEgZmFu LXJlc291cmNlIGFuZCBhIHRlbXBlcmF0dXJlLWNsaWVudCBjYW4gYmUgY28tbG9jYXRlZCwgb3Ig YQ0KZmFuLWNsaWVudCBhbmQgdGVtcGVyYXR1cmUtc2VydmVyIGRlcGVuZGluZyBvbiB3aGVyZSB0 aGUgY29udHJvbCBsb2dpYyBpcw0KaG9zdGVkLiBXaGF0IGlzIHRoZSBwcm9ibGVtPw0KIA0KDQpC ZXN0IHJlZ2FyZHMsDQpHw7ZyYW4NCg0KPg0KPlRoZSBpbnRlcmVzdGluZyBxdWVzdGlvbiBmb3Ig dGhlIHVzZSBjYXNlcyBkb2N1bWVudCBpcyBob3cgdGhpbmdzIHdvcmsNCj5pbiBDb0FQIChvciBv dGhlciBwcm90b2NvbHMgdGhhdCBzZXJ2ZSB0aGUgc2FtZSBwdXJwb3NlKS4gV2UgY2FuIGRpc2N1 c3MNCj50aGUgc29sdXRpb24gZGVzaWduIGxhdGVyIHdoZW4gd2Uga25vdyB3aGF0IHRoZSBwcm9i bGVtcyBhcmUuDQo+DQo+Pg0KPj4gSWYgc28sIHdoeSBpc24ndCB0aGVyZSBhbiBhc3NvY2lhdGVk IGNvbnRyYWRpY3Rpb24gYmV0d2VlbiBPQXV0aCBhbmQNCj4+SFRUUD8NCj4+IChPciBpcyB0aGVy ZT8pDQo+DQo+SFRUUCB3YXMgZGVzaWduZWQgZm9yIHdlYiBzY2VuYXJpb3MgYW5kIG5vdCBmb3Ig Y29uc3RyYWluZWQNCj5lbnZpcm9ubWVudHMuIENvQVAgd2FzIGRlc2lnbmVkIHRvIGJldHRlciBh ZGRyZXNzIHRoZSBzcGVjaWFsDQo+Y2hhcmFjdGVyaXN0aWNzIG9mIGNvbnN0cmFpbmVkIGVudmly b25tZW50cy4NCj4NCj5PQXV0aCB3YXMgYWxzbyBkZXNpZ25lZCBmb3Igd2ViIHNjZW5hcmlvcy4g SW4gd2ViIHNjZW5hcmlvcyB3ZSBoYXZlIGFuDQo+YWN0aXZlIHVzZXIuIFdlIGNhbiBzb2x2ZSBh dXRob3JpemF0aW9uIHByb2JsZW1zIGJ5IGFza2luZyB0aGUgdXNlci4gVGhlDQo+dXNlIGNhc2Vz IHNob3cgdGhhdCB3ZSBkb24ndCBhbHdheXMgaGF2ZSBhbiBhY3RpdmUgdXNlciBpbiBjb25zdHJh aW5lZA0KPmVudmlyb25tZW50cy4gV2UgbmVlZCB0byBkZWFsIHdpdGggdGhpcyBmYWN0IChvciB3 ZSBkb24ndCBidXQgdGhlbiB3ZQ0KPmxpa2VseSB3aWxsIG5vdCBmaW5kIHRoZSBiZXN0IHNvbHV0 aW9uKS4NCj4NCj5CZXN0IHJlZ2FyZHMsDQo+U3RlZmZpDQoNCg== From nobody Fri Mar 6 06:45:39 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 844471ACE5E for ; Fri, 6 Mar 2015 06:45:38 -0800 (PST) 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 xP12hujcDX3v for ; Fri, 6 Mar 2015 06:45:37 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB0571ACE49 for ; Fri, 6 Mar 2015 06:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t26EhPY5010788; Fri, 6 Mar 2015 15:43:25 +0100 (CET) Received: from [IPv6:2001:638:708:30da:a0e1:77b7:e892:2e40] (unknown [IPv6:2001:638:708:30da:a0e1:77b7:e892:2e40]) (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 3kzBWx0lWGz2lGy; Fri, 6 Mar 2015 15:43:25 +0100 (CET) Message-ID: <54F9BD0C.5070302@tzi.de> Date: Fri, 06 Mar 2015 15:43:24 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= , Hannes Tschofenig , "Ace@ietf.org" References: <54F5B1F2.6050205@gmx.net> <54F616CF.20607@tzi.de> <54F81652.6040102@tzi.de> <54F97FC5.4020305@tzi.de> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] U1.2 in Use Case Document 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, 06 Mar 2015 14:45:38 -0000 Hi Göran, On 03/06/2015 01:14 PM, Göran Selander wrote: > > On 2015-03-06 11:21, "Stefanie Gerdes" wrote: >> Let's use an example. Imagine a container scenario where the temperature >> sensor is the CoAP client and the fan actuator is the CoAP server. If >> you want to represent both the sensor values and the actuator settings >> by resources, this does not fit to CoAP where only the server has >> resources. It might be confusing for people if you want to distinguish >> between authorization resources and CoAP resources. > > So there are two different access control problems, each have their > resources. A fan-resource and a temperature-client can be co-located, or a > fan-client and temperature-server depending on where the control logic is > hosted. What is the problem? Maybe the scenario was not clear. The temperature sensor is a CoAP client. It makes a PUT on the fan setting resource of the fan device. The client does not have a CoAP resource. Only the server has. The use cases document describes problems in constrained environments. After we described the problem we can consider how solutions fit to these problems. I don't think it will work very well the other way around. Best regards, Steffi From nobody Fri Mar 6 07:59: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 3E5EF1A0023 for ; Fri, 6 Mar 2015 07:59:48 -0800 (PST) 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 jGpIv2IjrLsE for ; Fri, 6 Mar 2015 07:59:46 -0800 (PST) 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 16A2F1A004D for ; Fri, 6 Mar 2015 07:59:45 -0800 (PST) X-AuditID: c1b4fb25-f79b76d00000113a-6f-54f9ceef3336 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 62.0D.04410.FEEC9F45; Fri, 6 Mar 2015 16:59:44 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.70]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0210.002; Fri, 6 Mar 2015 16:59:43 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Stefanie Gerdes , Hannes Tschofenig , "Ace@ietf.org" Thread-Topic: [Ace] U1.2 in Use Case Document Thread-Index: AQHQVbL1RkiN6OYzzEyLTf3fE9ZKCp0K/GYAgAAliYCAAe0ZgIAAdKwAgAGEugCAACoogIAAMFIAgAAYugCAACYWgA== Date: Fri, 6 Mar 2015 15:59:43 +0000 Message-ID: References: <54F5B1F2.6050205@gmx.net> <54F616CF.20607@tzi.de> <54F81652.6040102@tzi.de> <54F97FC5.4020305@tzi.de> <54F9BD0C.5070302@tzi.de> In-Reply-To: <54F9BD0C.5070302@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.20] Content-Type: text/plain; charset="utf-8" Content-ID: <9757E7971CDC924B90579CB93A27240C@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZGfG3RvfDuZ8hBq/28Vl8/9bDbLHx4l1G i6U777E6MHss3rSfzWPJkp9MHtvefmUOYI7isklJzcksSy3St0vgyjjWsoi1oE20YufynUwN jAdEuhg5OSQETCSa73UwQdhiEhfurWfrYuTiEBI4wigx6fQ3VghnEaPE6TX/WEGq2ARcJB40 PALrEBEolpg65QkjiC0soCOx9e8OIJsDKK4rcX29F0RJlsS/hg42EJtFQEXi/uKvzCA2r4CF xJI7axkh5p9gkti6s5UFJMEpoCax/XgTmM0IdNH3U2vAdjELiEvcejIf6lIBiSV7zjND2KIS Lx9D3CYqoCex8noTG0RcUeLq9OVMIPcwC2hKrN+lDzHGWmLlz63sELaixJTuh+wQ9whKnJz5 hGUCo/gsJNtmIXTPQtI9C0n3LCTdCxhZVzGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIERuDB Lb9VdzBefuN4iFGAg1GJh9dA4meIEGtiWXFl7iFGaQ4WJXFeO+NDIUIC6YklqdmpqQWpRfFF pTmpxYcYmTg4pRoYJWxt9hqePXb63y7dmKNbJpVp86y4aVZ8SPGBerrpvjkP6rvf9rc7V7N+ O7Hmj+PUjNNRYvypC3MVk2NWpQae2ci+s2H5jW+Zr76ct9m0n7niePiRToFpbJVzKvbvsel/ z3DbUt1UbrP8ppv8JS90rKcqndyaeFYnQ7pt96+13wL3rm5Nf7wwXYmlOCPRUIu5qDgRAOOU tzShAgAA Archived-At: Subject: Re: [Ace] U1.2 in Use Case Document 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, 06 Mar 2015 15:59:48 -0000 DQoNCk9uIDIwMTUtMDMtMDYgMTU6NDMsICJTdGVmYW5pZSBHZXJkZXMiIDxnZXJkZXNAdHppLmRl PiB3cm90ZToNCg0KPkhpIEfDtnJhbiwNCj4NCj5PbiAwMy8wNi8yMDE1IDAxOjE0IFBNLCBHw7Zy YW4gU2VsYW5kZXIgd3JvdGU6DQo+Pg0KPj4gT24gMjAxNS0wMy0wNiAxMToyMSwgIlN0ZWZhbmll IEdlcmRlcyIgPGdlcmRlc0B0emkuZGU+IHdyb3RlOg0KPg0KPj4+IExldCdzIHVzZSBhbiBleGFt cGxlLiBJbWFnaW5lIGEgY29udGFpbmVyIHNjZW5hcmlvIHdoZXJlIHRoZQ0KPj4+dGVtcGVyYXR1 cmUNCj4+PiBzZW5zb3IgaXMgdGhlIENvQVAgY2xpZW50IGFuZCB0aGUgZmFuIGFjdHVhdG9yIGlz IHRoZSBDb0FQIHNlcnZlci4gSWYNCj4+PiB5b3Ugd2FudCB0byByZXByZXNlbnQgYm90aCB0aGUg c2Vuc29yIHZhbHVlcyBhbmQgdGhlIGFjdHVhdG9yIHNldHRpbmdzDQo+Pj4gYnkgcmVzb3VyY2Vz LCB0aGlzIGRvZXMgbm90IGZpdCB0byBDb0FQIHdoZXJlIG9ubHkgdGhlIHNlcnZlciBoYXMNCj4+ PiByZXNvdXJjZXMuIEl0IG1pZ2h0IGJlIGNvbmZ1c2luZyBmb3IgcGVvcGxlIGlmIHlvdSB3YW50 IHRvIGRpc3Rpbmd1aXNoDQo+Pj4gYmV0d2VlbiBhdXRob3JpemF0aW9uIHJlc291cmNlcyBhbmQg Q29BUCByZXNvdXJjZXMuDQo+Pg0KPj4gU28gdGhlcmUgYXJlIHR3byBkaWZmZXJlbnQgYWNjZXNz IGNvbnRyb2wgcHJvYmxlbXMsIGVhY2ggaGF2ZSB0aGVpcg0KPj4gcmVzb3VyY2VzLiBBIGZhbi1y ZXNvdXJjZSBhbmQgYSB0ZW1wZXJhdHVyZS1jbGllbnQgY2FuIGJlIGNvLWxvY2F0ZWQsDQo+Pm9y IGENCj4+IGZhbi1jbGllbnQgYW5kIHRlbXBlcmF0dXJlLXNlcnZlciBkZXBlbmRpbmcgb24gd2hl cmUgdGhlIGNvbnRyb2wgbG9naWMNCj4+aXMNCj4+IGhvc3RlZC4gV2hhdCBpcyB0aGUgcHJvYmxl bT8NCj4NCj5NYXliZSB0aGUgc2NlbmFyaW8gd2FzIG5vdCBjbGVhci4gVGhlIHRlbXBlcmF0dXJl IHNlbnNvciBpcyBhIENvQVANCj5jbGllbnQuIEl0IG1ha2VzIGEgUFVUIG9uIHRoZSBmYW4gc2V0 dGluZyByZXNvdXJjZSBvZiB0aGUgZmFuIGRldmljZS4NCj5UaGUgY2xpZW50IGRvZXMgbm90IGhh dmUgYSBDb0FQIHJlc291cmNlLiBPbmx5IHRoZSBzZXJ2ZXIgaGFzLg0KDQpBcmUgeW91IHRoaW5r aW5nIG9mIGEgZmFuLWNsaWVudCAoaG9zdGVkIGluIHRoZSB0ZW1wZXJhdHVyZSBzZW5zb3IpIHdo aWNoDQptYWtlcyBhIFBVVCBvZiBhIGZhbiBzZXR0aW5nIHRvIGEgZmFuLXJlc291cmNlIChmYW4g YWN0dWF0b3IpPyBPciwNCmFsdGVybmF0aXZlbHksIHRoZXJlIGNvdWxkIGJlIGEgdGVtcGVyYXR1 cmUgY2xpZW50IChpbiB0aGUgZmFuKSByZWNlaXZpbmcNCm9ic2VydmUgbm90aWZpY2F0aW9ucyB3 aXRoIHRlbXBlcmF0dXJlcyBmcm9tIHRoZSB0ZW1wZXJhdHVyZS1yZXNvdXJjZQ0KKHRlbXBlcmF0 dXJlIHNlbnNvcikgaW4gYSBHRVQgcmVzcG9uc2UuIEnigJltIHNvcnJ5IGJ1dCBJIHN0aWxsIGRv buKAmXQNCnVuZGVyc3RhbmQgdGhlIHByb2JsZW0gaW4gYW55IG9mIHRoZXNlLiBPciBtYXliZSB5 b3Ugd2FudGVkIHRvIGV4Y2x1ZGUgdGhlDQpzZWNvbmQgY2FzZSB3aGVuIHlvdSBzYXkg4oCcdGhl IGNsaWVudCBkb2VzIG5vdCBoYXZlIGEgQ29BUCByZXNvdXJjZeKAnT8gSWYNCnNvLCB3aHkgZG8g eW91IG1ha2UgdGhhdCBhc3N1bXB0aW9uPw0KDQoNCg0KQmVzdCByZWdhcmRzLA0KR8O2cmFuDQoN Cg0KPg0KPlRoZSB1c2UgY2FzZXMgZG9jdW1lbnQgZGVzY3JpYmVzIHByb2JsZW1zIGluIGNvbnN0 cmFpbmVkIGVudmlyb25tZW50cy4NCj5BZnRlciB3ZSBkZXNjcmliZWQgdGhlIHByb2JsZW0gd2Ug Y2FuIGNvbnNpZGVyIGhvdyBzb2x1dGlvbnMgZml0IHRvDQo+dGhlc2UgcHJvYmxlbXMuIEkgZG9u J3QgdGhpbmsgaXQgd2lsbCB3b3JrIHZlcnkgd2VsbCB0aGUgb3RoZXIgd2F5IGFyb3VuZC4NCj4N Cj5CZXN0IHJlZ2FyZHMsDQo+U3RlZmZpDQoNCg== From nobody Fri Mar 6 08:18:03 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2861A00CF for ; Fri, 6 Mar 2015 08:18:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] 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 6RjfyJaEYPhC for ; Fri, 6 Mar 2015 08:18:00 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 0485C1ACEF0 for ; Fri, 6 Mar 2015 08:14:39 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8CD2252E079; Fri, 6 Mar 2015 11:14:38 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 7D73152E06F; Fri, 6 Mar 2015 11:14:38 -0500 (EST) Received: from imshyb02.MITRE.ORG (129.83.29.3) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 6 Mar 2015 11:14:37 -0500 Received: from imshyb02.MITRE.ORG (129.83.29.3) by imshyb02.MITRE.ORG (129.83.29.3) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 6 Mar 2015 11:14:38 -0500 Received: from na01-bl2-obe.outbound.protection.outlook.com (10.140.19.249) by imshyb02.MITRE.ORG (129.83.29.3) with Microsoft SMTP Server (TLS) id 15.0.1044.25 via Frontend Transport; Fri, 6 Mar 2015 11:14:38 -0500 Received: from DM2PR09MB0317.namprd09.prod.outlook.com (25.160.96.150) by DM2PR09MB0319.namprd09.prod.outlook.com (25.160.96.152) with Microsoft SMTP Server (TLS) id 15.1.99.14; Fri, 6 Mar 2015 16:14:36 +0000 Received: from DM2PR09MB0317.namprd09.prod.outlook.com ([25.160.96.150]) by DM2PR09MB0317.namprd09.prod.outlook.com ([25.160.96.150]) with mapi id 15.01.0099.004; Fri, 6 Mar 2015 16:14:36 +0000 From: "Moore, Steve" To: =?Windows-1252?Q?G=F6ran_Selander?= , Stefanie Gerdes , Hannes Tschofenig , "Ace@ietf.org" Thread-Topic: [Ace] U1.2 in Use Case Document Thread-Index: AQHQVbN6DLG+xjM1Jk2lW2NqXMS6tZ0K/GcAgAA2S4CAAdxWAIAAhW8AgAFz94CAADrqgIAAH48AgAApfgCAABVSgIAAAhr0 Date: Fri, 6 Mar 2015 16:14:36 +0000 Message-ID: <1425658471858.51869@mitre.org> References: <54F5B1F2.6050205@gmx.net> <54F616CF.20607@tzi.de> <54F81652.6040102@tzi.de> <54F97FC5.4020305@tzi.de> <54F9BD0C.5070302@tzi.de>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.3] authentication-results: ericsson.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0319; x-forefront-antispam-report: BMV:0; SFV:NSPM; SFS:(10009020)(6009001)(377454003)(24454002)(51704005)(53754006)(377424004)(479174004)(2900100001)(2950100001)(36756003)(99286002)(19580405001)(106116001)(86362001)(66066001)(93886004)(92566002)(117636001)(40100003)(54356999)(46102003)(76176999)(15975445007)(122556002)(102836002)(2501003)(77156002)(19580395003)(50986999)(2656002)(87936001)(62966003)(107886001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR09MB0319; H:DM2PR09MB0317.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5001007)(5005006); SRVR:DM2PR09MB0319; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0319; x-forefront-prvs: 05079D8470 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2015 16:14:36.1958 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0319 X-OriginatorOrg: mitre.org Archived-At: Subject: Re: [Ace] U1.2 in Use Case Document 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, 06 Mar 2015 16:18:02 -0000 Hi everyone (new to posting to the list, but have been watching for a bit),= =0A= =0A= It seems to me that the discussion has wandered into specific implementatio= ns of solutions to the use case. It really seems that the use case is compa= ny A has sensors in boxes that are shipped via a container that company B o= wns. The container has an actuator owned by company B. (I know ownership is= a contested thing here...) The actuator should operated based on the value= s the sensors have. The logic could be in the fan, or it could be in the se= nsors. The directionality of the requests could be either way. Those detail= s are up to the people designing the Banana Container Monitoring protocol w= hich would hopefully use the ACE protocol for authentication and authorizat= ion. If I were building such a system I'd probably go with the CoAP observe= route having the fan have authorization to communicate with specific senso= rs. There would be another set of authorizations for the guy who is loading= the container to modify the sensor ID list in the fan.=0A= =0A= In my opinion the use case should be used to highlight the types of problem= s the spec should provide solutions to, not dictate what the specific solut= ions for the use case should be.=0A= =0A= That's the long way of saying I think I agree with G=F6ran.=0A= -steve=0A= =0A= ________________________________________=0A= From: Ace on behalf of G=F6ran Selander =0A= Sent: Friday, March 6, 2015 10:59 AM=0A= To: Stefanie Gerdes; Hannes Tschofenig; Ace@ietf.org=0A= Subject: Re: [Ace] U1.2 in Use Case Document=0A= =0A= On 2015-03-06 15:43, "Stefanie Gerdes" wrote:=0A= =0A= >Hi G=F6ran,=0A= >=0A= >On 03/06/2015 01:14 PM, G=F6ran Selander wrote:=0A= >>=0A= >> On 2015-03-06 11:21, "Stefanie Gerdes" wrote:=0A= >=0A= >>> Let's use an example. Imagine a container scenario where the=0A= >>>temperature=0A= >>> sensor is the CoAP client and the fan actuator is the CoAP server. If= =0A= >>> you want to represent both the sensor values and the actuator settings= =0A= >>> by resources, this does not fit to CoAP where only the server has=0A= >>> resources. It might be confusing for people if you want to distinguish= =0A= >>> between authorization resources and CoAP resources.=0A= >>=0A= >> So there are two different access control problems, each have their=0A= >> resources. A fan-resource and a temperature-client can be co-located,=0A= >>or a=0A= >> fan-client and temperature-server depending on where the control logic= =0A= >>is=0A= >> hosted. What is the problem?=0A= >=0A= >Maybe the scenario was not clear. The temperature sensor is a CoAP=0A= >client. It makes a PUT on the fan setting resource of the fan device.=0A= >The client does not have a CoAP resource. Only the server has.=0A= =0A= Are you thinking of a fan-client (hosted in the temperature sensor) which= =0A= makes a PUT of a fan setting to a fan-resource (fan actuator)? Or,=0A= alternatively, there could be a temperature client (in the fan) receiving= =0A= observe notifications with temperatures from the temperature-resource=0A= (temperature sensor) in a GET response. I=92m sorry but I still don=92t=0A= understand the problem in any of these. Or maybe you wanted to exclude the= =0A= second case when you say =93the client does not have a CoAP resource=94? If= =0A= so, why do you make that assumption?=0A= =0A= =0A= =0A= Best regards,=0A= G=F6ran=0A= =0A= =0A= >=0A= >The use cases document describes problems in constrained environments.=0A= >After we described the problem we can consider how solutions fit to=0A= >these problems. I don't think it will work very well the other way around.= =0A= >=0A= >Best regards,=0A= >Steffi=0A= =0A= _______________________________________________=0A= Ace mailing list=0A= Ace@ietf.org=0A= https://www.ietf.org/mailman/listinfo/ace= From nobody Fri Mar 6 08:23: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 653B81A0371 for ; Fri, 6 Mar 2015 08:23:49 -0800 (PST) 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 iNnqskonc1sJ for ; Fri, 6 Mar 2015 08:23:47 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 427821A036B for ; Fri, 6 Mar 2015 08:23:47 -0800 (PST) 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 t26GNgsR026732; Fri, 6 Mar 2015 17:23:42 +0100 (CET) Received: from [IPv6:2001:638:708:30da:a0e1:77b7:e892:2e40] (unknown [IPv6:2001:638:708:30da:a0e1:77b7:e892:2e40]) (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 3kzDlf6rrpz2lLw; Fri, 6 Mar 2015 17:23:42 +0100 (CET) Message-ID: <54F9D48E.2070207@tzi.de> Date: Fri, 06 Mar 2015 17:23:42 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= , Hannes Tschofenig , "Ace@ietf.org" References: <54F5B1F2.6050205@gmx.net> <54F616CF.20607@tzi.de> <54F81652.6040102@tzi.de> <54F97FC5.4020305@tzi.de> <54F9BD0C.5070302@tzi.de> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] U1.2 in Use Case Document 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, 06 Mar 2015 16:23:49 -0000 Hi Göran, On 03/06/2015 04:59 PM, Göran Selander wrote: > > > On 2015-03-06 15:43, "Stefanie Gerdes" wrote: > >> Hi Göran, >> >> On 03/06/2015 01:14 PM, Göran Selander wrote: >>> >>> On 2015-03-06 11:21, "Stefanie Gerdes" wrote: >> >>>> Let's use an example. Imagine a container scenario where the >>>> temperature >>>> sensor is the CoAP client and the fan actuator is the CoAP server. If >>>> you want to represent both the sensor values and the actuator settings >>>> by resources, this does not fit to CoAP where only the server has >>>> resources. It might be confusing for people if you want to distinguish >>>> between authorization resources and CoAP resources. >>> >>> So there are two different access control problems, each have their >>> resources. A fan-resource and a temperature-client can be co-located, >>> or a >>> fan-client and temperature-server depending on where the control logic >>> is >>> hosted. What is the problem? >> >> Maybe the scenario was not clear. The temperature sensor is a CoAP >> client. It makes a PUT on the fan setting resource of the fan device. >> The client does not have a CoAP resource. Only the server has. > > Are you thinking of a fan-client (hosted in the temperature sensor) which > makes a PUT of a fan setting to a fan-resource (fan actuator)? Or, > alternatively, there could be a temperature client (in the fan) receiving > observe notifications with temperatures from the temperature-resource > (temperature sensor) in a GET response. I’m sorry but I still don’t > understand the problem in any of these. Or maybe you wanted to exclude the > second case when you say “the client does not have a CoAP resource”? If > so, why do you make that assumption? From a CoAP perspective, one possibility to implement the communication between the temperature sensor in the banana boxes and the fan actuator is that the temperature sensor is the CoAP client and the fan actuator is the CoAP server. A CoAP client does not have a resource. Only the server has a resource. Your proposal seems to exclude this configuration. Your proposal seems to require that a device MUST always implement a CoAP client and a CoAP server and that they change their role within the communication. Otherwise we cannot have resources on both sides. Best regards, Steffi > > > > Best regards, > Göran > > >> >> The use cases document describes problems in constrained environments. >> After we described the problem we can consider how solutions fit to >> these problems. I don't think it will work very well the other way around. >> >> Best regards, >> Steffi > > > -- 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 Fri Mar 6 08:42:10 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7928B1A09C9 for ; Fri, 6 Mar 2015 08:42:09 -0800 (PST) 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 Gqag7SA5Bi4N for ; Fri, 6 Mar 2015 08:42:08 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4874E1A0140 for ; Fri, 6 Mar 2015 08:41:34 -0800 (PST) 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 t26GfSLt008623; Fri, 6 Mar 2015 17:41:28 +0100 (CET) Received: from [IPv6:2001:638:708:30da:a0e1:77b7:e892:2e40] (unknown [IPv6:2001:638:708:30da:a0e1:77b7:e892:2e40]) (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 3kzF876jPPz2lMX; Fri, 6 Mar 2015 17:41:27 +0100 (CET) Message-ID: <54F9D8B7.4050708@tzi.de> Date: Fri, 06 Mar 2015 17:41:27 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Moore, Steve" , =?windows-1252?Q?G=F6ran_Seland?= =?windows-1252?Q?er?= , Hannes Tschofenig , "Ace@ietf.org" References: <54F5B1F2.6050205@gmx.net> <54F616CF.20607@tzi.de> <54F81652.6040102@tzi.de> <54F97FC5.4020305@tzi.de> <54F9BD0C.5070302@tzi.de>, <1425658471858.51869@mitre.org> In-Reply-To: <1425658471858.51869@mitre.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] U1.2 in Use Case Document 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, 06 Mar 2015 16:42:09 -0000 Hi Steve, Thank you for you comment. On 03/06/2015 05:14 PM, Moore, Steve wrote: > Hi everyone (new to posting to the list, but have been watching for a bit), > > It seems to me that the discussion has wandered into specific implementations of solutions to the use case. It really seems that the use case is company A has sensors in boxes that are shipped via a container that company B owns. The container has an actuator owned by company B. (I know ownership is a contested thing here...) The actuator should operated based on the values the sensors have. The logic could be in the fan, or it could be in the sensors. The directionality of the requests could be either way. Those details are up to the people designing the Banana Container Monitoring protocol which would hopefully use the ACE protocol for authentication and authorization. If I were building such a system I'd probably go with the CoAP observe route having the fan have authorization to communicate with specific sensors. There would be another set of authorizations for the guy who is loading the container to modify the sensor ID list in the fan. Yes, it should be up the implementor which device is the client and which is the server. I completely agree with this. Gran proposes that we define that fruit vendors and container owners are resource owners. This implies that fruit vendors and container owners control the server since only CoAP servers have resources. One possible configuration is that the temperature sensor of the fruit vendor is the client and the fan actuator is the server. If we define that fruit vendors are resource owners, this configuration would not be possible since clients don't have resources. We would need a client device between the server of the fruit vendor and the server of the container owner. > > In my opinion the use case should be used to highlight the types of problems the spec should provide solutions to, not dictate what the specific solutions for the use case should be. Yes, I totally agree with this. Thanks, Steffi > > That's the long way of saying I think I agree with Gran. > -steve > > ________________________________________ > From: Ace on behalf of Gran Selander > Sent: Friday, March 6, 2015 10:59 AM > To: Stefanie Gerdes; Hannes Tschofenig; Ace@ietf.org > Subject: Re: [Ace] U1.2 in Use Case Document > > On 2015-03-06 15:43, "Stefanie Gerdes" wrote: > >> Hi Gran, >> >> On 03/06/2015 01:14 PM, Gran Selander wrote: >>> >>> On 2015-03-06 11:21, "Stefanie Gerdes" wrote: >> >>>> Let's use an example. Imagine a container scenario where the >>>> temperature >>>> sensor is the CoAP client and the fan actuator is the CoAP server. If >>>> you want to represent both the sensor values and the actuator settings >>>> by resources, this does not fit to CoAP where only the server has >>>> resources. It might be confusing for people if you want to distinguish >>>> between authorization resources and CoAP resources. >>> >>> So there are two different access control problems, each have their >>> resources. A fan-resource and a temperature-client can be co-located, >>> or a >>> fan-client and temperature-server depending on where the control logic >>> is >>> hosted. What is the problem? >> >> Maybe the scenario was not clear. The temperature sensor is a CoAP >> client. It makes a PUT on the fan setting resource of the fan device. >> The client does not have a CoAP resource. Only the server has. > > Are you thinking of a fan-client (hosted in the temperature sensor) which > makes a PUT of a fan setting to a fan-resource (fan actuator)? Or, > alternatively, there could be a temperature client (in the fan) receiving > observe notifications with temperatures from the temperature-resource > (temperature sensor) in a GET response. Im sorry but I still dont > understand the problem in any of these. Or maybe you wanted to exclude the > second case when you say the client does not have a CoAP resource? If > so, why do you make that assumption? > > > > Best regards, > Gran > > >> >> The use cases document describes problems in constrained environments. >> After we described the problem we can consider how solutions fit to >> these problems. I don't think it will work very well the other way around. >> >> Best regards, >> Steffi > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > -- Stefanie Gerdes Tel: +49 421 218 63906 TZI Universitt Bremen E-Mail: gerdes@tzi.de Bibliothekstr. 1, MZH 5150 28359 Bremen, Germany From nobody Fri Mar 6 09:41: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 080BF1A0222 for ; Fri, 6 Mar 2015 09:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] 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 yR5cQTg03Mqr for ; Fri, 6 Mar 2015 09:41:01 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 329A01A0119 for ; Fri, 6 Mar 2015 09:41:01 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D19D972E182; Fri, 6 Mar 2015 12:41:00 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id C647C332100; Fri, 6 Mar 2015 12:41:00 -0500 (EST) Received: from imshyb02.MITRE.ORG (129.83.29.3) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 6 Mar 2015 12:41:00 -0500 Received: from imshyb02.MITRE.ORG (129.83.29.3) by imshyb02.MITRE.ORG (129.83.29.3) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 6 Mar 2015 12:41:00 -0500 Received: from na01-bl2-obe.outbound.protection.outlook.com (10.140.19.249) by imshyb02.MITRE.ORG (129.83.29.3) with Microsoft SMTP Server (TLS) id 15.0.1044.25 via Frontend Transport; Fri, 6 Mar 2015 12:41:00 -0500 Received: from DM2PR09MB0317.namprd09.prod.outlook.com (25.160.96.150) by DM2PR09MB0319.namprd09.prod.outlook.com (25.160.96.152) with Microsoft SMTP Server (TLS) id 15.1.99.14; Fri, 6 Mar 2015 17:40:59 +0000 Received: from DM2PR09MB0317.namprd09.prod.outlook.com ([25.160.96.150]) by DM2PR09MB0317.namprd09.prod.outlook.com ([25.160.96.150]) with mapi id 15.01.0099.004; Fri, 6 Mar 2015 17:40:59 +0000 From: "Moore, Steve" To: Stefanie Gerdes , =?Windows-1252?Q?G=F6ran_Selander?= , Hannes Tschofenig , "Ace@ietf.org" Thread-Topic: [Ace] U1.2 in Use Case Document Thread-Index: AQHQVbN6DLG+xjM1Jk2lW2NqXMS6tZ0K/GcAgAA2S4CAAdxWAIAAhW8AgAFz94CAADrqgIAAH48AgAApfgCAABVSgIAAAhr0gAAJj4D//7zNAA== Date: Fri, 6 Mar 2015 17:40:59 +0000 Message-ID: References: <54F5B1F2.6050205@gmx.net> <54F616CF.20607@tzi.de> <54F81652.6040102@tzi.de> <54F97FC5.4020305@tzi.de> <54F9BD0C.5070302@tzi.de> <1425658471858.51869@mitre.org> <54F9D8B7.4050708@tzi.de> In-Reply-To: <54F9D8B7.4050708@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: [192.160.51.87] authentication-results: tzi.de; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0319; x-forefront-antispam-report: BMV:0; SFV:NSPM; SFS:(10009020)(6009001)(24454002)(51704005)(53754006)(479174004)(377424004)(377454003)(164054003)(102836002)(122556002)(15975445007)(19580395003)(77156002)(2501003)(46102003)(54356999)(76176999)(87936001)(2656002)(50986999)(107886001)(62966003)(19580405001)(99286002)(2950100001)(2900100001)(36756003)(93886004)(66066001)(83506001)(40100003)(92566002)(106116001)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR09MB0319; H:DM2PR09MB0317.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5001007)(5005006); SRVR:DM2PR09MB0319; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0319; x-forefront-prvs: 05079D8470 Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2015 17:40:59.0984 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0319 X-OriginatorOrg: mitre.org Archived-At: Subject: Re: [Ace] U1.2 in Use Case Document 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, 06 Mar 2015 17:41:03 -0000 Ah ha, I think I now understand what the core of the discussion is. (Other comments inline) On 3/6/15, 11:41 AM, "Stefanie Gerdes" wrote: >Hi Steve, > >Thank you for you comment. > >On 03/06/2015 05:14 PM, Moore, Steve wrote: >> Hi everyone (new to posting to the list, but have been watching for a >>bit), >> >> It seems to me that the discussion has wandered into specific >>implementations of solutions to the use case. It really seems that the >>use case is company A has sensors in boxes that are shipped via a >>container that company B owns. The container has an actuator owned by >>company B. (I know ownership is a contested thing here...) The actuator >>should operated based on the values the sensors have. The logic could be >>in the fan, or it could be in the sensors. The directionality of the >>requests could be either way. Those details are up to the people >>designing the Banana Container Monitoring protocol which would hopefully >>use the ACE protocol for authentication and authorization. If I were >>building such a system I'd probably go with the CoAP observe route >>having the fan have authorization to communicate with specific sensors. >>There would be another set of authorizations for the guy who is loading >>the container to modify the sensor ID list in the fan. > >Yes, it should be up the implementor which device is the client and >which is the server. I completely agree with this. > >G=F6ran proposes that we define that fruit vendors and container owners >are resource owners. This implies that fruit vendors and container >owners control the server since only CoAP servers have resources. > >One possible configuration is that the temperature sensor of the fruit >vendor is the client and the fan actuator is the server. If we define >that fruit vendors are resource owners, this configuration would not be >possible since clients don't have resources. We would need a client >device between the server of the fruit vendor and the server of the >container owner. Just because the fruit vendor is a resource owner doesn=B9t preclude it fro= m also being a client. Taking the HTTP definition of resource (and hence CoAP=B9s definition of resource) as a =B3network data object or service that can be identified by = a URI=B2, I can see the issue with =8Cresource owner=B9. Although it should be noted that neither spec defines a =8Cresource owner= =B9 in particular, and the CoAP spec does define that requests can include a representation of a resource. However, if we were to imagine a system built on MQTT, they don=B9t define = a resource so that issue goes away. (A bunch of others probably pop up but that is besides the point) I can=B9t really see a good way to define a resource owner in the abstract case that a client can send the resource on to the server that doesn=B9t conflict with the HTTP/CoAP resource definition. Data Owner? Doesn=B9t seem generic enough=8A -steve > >> >> In my opinion the use case should be used to highlight the types of >>problems the spec should provide solutions to, not dictate what the >>specific solutions for the use case should be. > >Yes, I totally agree with this. > >Thanks, >Steffi > >> >> That's the long way of saying I think I agree with G=F6ran. >> -steve >> >> ________________________________________ >> From: Ace on behalf of G=F6ran Selander >> >> Sent: Friday, March 6, 2015 10:59 AM >> To: Stefanie Gerdes; Hannes Tschofenig; Ace@ietf.org >> Subject: Re: [Ace] U1.2 in Use Case Document >> >> On 2015-03-06 15:43, "Stefanie Gerdes" wrote: >> >>> Hi G=F6ran, >>> >>> On 03/06/2015 01:14 PM, G=F6ran Selander wrote: >>>> >>>> On 2015-03-06 11:21, "Stefanie Gerdes" wrote: >>> >>>>> Let's use an example. Imagine a container scenario where the >>>>> temperature >>>>> sensor is the CoAP client and the fan actuator is the CoAP server. If >>>>> you want to represent both the sensor values and the actuator >>>>>settings >>>>> by resources, this does not fit to CoAP where only the server has >>>>> resources. It might be confusing for people if you want to >>>>>distinguish >>>>> between authorization resources and CoAP resources. >>>> >>>> So there are two different access control problems, each have their >>>> resources. A fan-resource and a temperature-client can be co-located, >>>> or a >>>> fan-client and temperature-server depending on where the control logic >>>> is >>>> hosted. What is the problem? >>> >>> Maybe the scenario was not clear. The temperature sensor is a CoAP >>> client. It makes a PUT on the fan setting resource of the fan device. >>> The client does not have a CoAP resource. Only the server has. >> >> Are you thinking of a fan-client (hosted in the temperature sensor) >>which >> makes a PUT of a fan setting to a fan-resource (fan actuator)? Or, >> alternatively, there could be a temperature client (in the fan) >>receiving >> observe notifications with temperatures from the temperature-resource >> (temperature sensor) in a GET response. I=B9m sorry but I still don=B9t >> understand the problem in any of these. Or maybe you wanted to exclude >>the >> second case when you say =B3the client does not have a CoAP resource=B2?= If >> so, why do you make that assumption? >> >> >> >> Best regards, >> G=F6ran >> >> >>> >>> The use cases document describes problems in constrained environments. >>> After we described the problem we can consider how solutions fit to >>> these problems. I don't think it will work very well the other way >>>around. >>> >>> Best regards, >>> Steffi >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >> > >--=20 >Stefanie Gerdes Tel: +49 421 218 63906 >TZI Universit=E4t Bremen E-Mail: gerdes@tzi.de >Bibliothekstr. 1, MZH 5150 >28359 Bremen, Germany From nobody Fri Mar 6 09:49: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 5F1401A1ABE for ; Fri, 6 Mar 2015 09:49:50 -0800 (PST) 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 Rtp5aOH9oSap for ; Fri, 6 Mar 2015 09:49:48 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 569FE1A1A97 for ; Fri, 6 Mar 2015 09:49:48 -0800 (PST) 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 t26HnhMi010743; Fri, 6 Mar 2015 18:49:43 +0100 (CET) Received: from [IPv6:2001:638:708:30da:a0e1:77b7:e892:2e40] (unknown [IPv6:2001:638:708:30da:a0e1:77b7:e892:2e40]) (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 3kzGfv1V55z2lNc; Fri, 6 Mar 2015 18:49:43 +0100 (CET) Message-ID: <54F9E8B7.5050209@tzi.de> Date: Fri, 06 Mar 2015 18:49:43 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Moore, Steve" , =?windows-1252?Q?G=F6ran_Seland?= =?windows-1252?Q?er?= , Hannes Tschofenig , "Ace@ietf.org" References: <54F5B1F2.6050205@gmx.net> <54F616CF.20607@tzi.de> <54F81652.6040102@tzi.de> <54F97FC5.4020305@tzi.de> <54F9BD0C.5070302@tzi.de> <1425658471858.51869@mitre.org> <54F9D8B7.4050708@tzi.de> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] U1.2 in Use Case Document 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, 06 Mar 2015 17:49:50 -0000 Hi Steve, On 03/06/2015 06:40 PM, Moore, Steve wrote: > Ah ha, I think I now understand what the core of the discussion is. (Other > comments inline) > > On 3/6/15, 11:41 AM, "Stefanie Gerdes" wrote: > >> Hi Steve, >> >> Thank you for you comment. >> >> On 03/06/2015 05:14 PM, Moore, Steve wrote: >>> Hi everyone (new to posting to the list, but have been watching for a >>> bit), >>> >>> It seems to me that the discussion has wandered into specific >>> implementations of solutions to the use case. It really seems that the >>> use case is company A has sensors in boxes that are shipped via a >>> container that company B owns. The container has an actuator owned by >>> company B. (I know ownership is a contested thing here...) The actuator >>> should operated based on the values the sensors have. The logic could be >>> in the fan, or it could be in the sensors. The directionality of the >>> requests could be either way. Those details are up to the people >>> designing the Banana Container Monitoring protocol which would hopefully >>> use the ACE protocol for authentication and authorization. If I were >>> building such a system I'd probably go with the CoAP observe route >>> having the fan have authorization to communicate with specific sensors. >>> There would be another set of authorizations for the guy who is loading >>> the container to modify the sensor ID list in the fan. >> >> Yes, it should be up the implementor which device is the client and >> which is the server. I completely agree with this. >> >> Gran proposes that we define that fruit vendors and container owners >> are resource owners. This implies that fruit vendors and container >> owners control the server since only CoAP servers have resources. >> >> One possible configuration is that the temperature sensor of the fruit >> vendor is the client and the fan actuator is the server. If we define >> that fruit vendors are resource owners, this configuration would not be >> possible since clients don't have resources. We would need a client >> device between the server of the fruit vendor and the server of the >> container owner. > > Just because the fruit vendor is a resource owner doesnt preclude it from > also being a client. > Taking the HTTP definition of resource (and hence CoAPs definition of > resource) as a network data object or service that can be identified by a > URI, I can see the issue with resource owner. > Although it should be noted that neither spec defines a resource owner > in particular, and the CoAP spec does define that requests can include a > representation of a resource. > > However, if we were to imagine a system built on MQTT, they dont define a > resource so that issue goes away. (A bunch of others probably pop up but > that is besides the point) > > I cant really see a good way to define a resource owner in the abstract > case that a client can send the resource on to the server that doesnt > conflict with the HTTP/CoAP resource definition. > Data Owner? Doesnt seem generic enough Right now the use cases document uses the term "principal": A subject who is either a resource owner or a client owner or both. Gran's proposal is to replace the term "principal" by "resource owner". This is one part of the current discussion. Best regards, Steffi From nobody Fri Mar 6 23:19: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 194701A8A0C for ; Fri, 6 Mar 2015 23:19:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 2qb4Wy-kr0FQ for ; Fri, 6 Mar 2015 23:19:40 -0800 (PST) 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 81A661A89EB for ; Fri, 6 Mar 2015 23:19:38 -0800 (PST) X-AuditID: c1b4fb25-f79b76d00000113a-2d-54faa6894226 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 40.2B.04410.986AAF45; Sat, 7 Mar 2015 08:19:37 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.70]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0210.002; Sat, 7 Mar 2015 08:19:36 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Stefanie Gerdes , "Moore, Steve" , "Ace@ietf.org" Thread-Topic: [Ace] U1.2 in Use Case Document Thread-Index: AQHQVbL1RkiN6OYzzEyLTf3fE9ZKCp0K/GYAgAAliYCAAe0ZgIAAdKwAgAGEugCAACoogIAAMFIAgAAYugCAACYWgP//82UAgAAHgYCAABCigIAAAnCAgADzCQA= Date: Sat, 7 Mar 2015 07:19:35 +0000 Message-ID: References: <54F5B1F2.6050205@gmx.net> <54F616CF.20607@tzi.de> <54F81652.6040102@tzi.de> <54F97FC5.4020305@tzi.de> <54F9BD0C.5070302@tzi.de> <1425658471858.51869@mitre.org> <54F9D8B7.4050708@tzi.de> <54F9E8B7.5050209@tzi.de> In-Reply-To: <54F9E8B7.5050209@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+NgFlrKIsWRmVeSWpSXmKPExsUyM+JvjW7nsl8hBmtX8ll8/9bDbLHx4l1G i6U777FaPP02l8mBxWPxpv1sHkuW/GTyeNtwld1j29uvzAEsUVw2Kak5mWWpRfp2CVwZn249 Yy+4ZV9x5MNn1gbGDrsuRk4OCQETie2HpzJD2GISF+6tZ+ti5OIQEjjCKLFjwS8WCGcRo8SR Od1sIFVsAi4SDxoeMYHYIgIZEjdP/2MHsZkFDCWeNLexgtjCAjoSW//uYOxi5ACq0ZW4vt4L ZI6IQBejxNs5XWDbWARUJJbfnMUIYvMKWEgs3dPACLHsE7PE6xWfwYZyCqhJHPjRADaUEei8 76fWMEEsE5e49WQ+E8TZAhJL9pyHekFU4uXjf2D1ogJ6EiuvN7FBxJUk1h7ezgJyELOApsT6 XfoQY6wlPu+fBTVSUWJK90N2iHsEJU7OfMIygVFiFpJtsxC6ZyHpnoWkexaS7gWMrKsYRYtT i5Ny042M9VKLMpOLi/Pz9PJSSzYxAuP14JbfqjsYL79xPMQowMGoxMP7YeGvECHWxLLiytxD jNIcLErivHbGh0KEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MLK56O65+Nc/786mowePzFjg PK2EZ8m96o4nAgoF8+o2pmzzTlycL/Tom1/dm/9tvXINeyTklMoyWioqdpvNqBa6LBn5/YyW j6Sl4dxte1/cLt8Y9nRXxZrPNU8048KW1NZWh7G9byx7IlStp7b8YF7Tjrd+F9+2OuvuntGw IOXD3ve3Q5ey5CqxFGckGmoxFxUnAgBPatKsuAIAAA== Archived-At: Cc: Hannes Tschofenig Subject: Re: [Ace] U1.2 in Use Case Document X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2015 07:19:42 -0000 SGkgU3RlZmZpLCBoaSBTdGV2ZQ0KDQpJbiB0aGUgbGFzdCBmZXcgbWFpbHMgaGF2ZSBzdXJmYWNl ZCBzb21lIG5ldyBhc3BlY3RzIGFuZCBJIHRoaW5rIEkNCnVuZGVyc3RhbmQgYmV0dGVyIHdoYXQg eW91IGFyZSBhZnRlciwgU3RlZmZpLiBUaGFua3MgU3RldmUgZm9yIHN0ZXBwaW5nIGluDQphbmQg cHJvdmlkZWQgYSBvdXRzaWRlIHZpZXcuDQoNCkEgbG90IG9mIHRoZSBkaXNjdXNzaW9uIHNvIGZh ciBoYXMgY2VudGVyZWQgb24gd2hldGhlciB0aGlzIGlzc3VlIG9uIHRoZQ0KY2xpZW50IHNpZGUg aXMgYW4gYWNjZXNzIGNvbnRyb2wgcHJvYmxlbSBvciBub3QuIEkgbWFpbnRhaW4gaXQgaXNu4oCZ dCwgYW5kDQpJIGJlbGlldmUgSSBoYXZlIHN1cHBvcnQgZm9yIHRoYXQgb3Bpbmlvbi4gSnVzdCBi ZWNhdXNlIHRoZSBjbGllbnQgaXMNCmNvbnN0cmFpbmVkIGRvZXNu4oCZdCBjaGFuZ2UgdGhhdCwg dW5mb3J0dW5hdGVseS4NCg0KVHJ5aW5nIHRvIGJlIG1vcmUgY29uc3RydWN0aXZlLCB0aGUgc2lt aWxhcml0eSBiZXR3ZWVuIHRoZSBjbGllbnQgcHJvYmxlbQ0KYW5kIHNlcnZlciBwcm9ibGVtIGlz IHRoYXQgYm90aCBhcmUgYWJvdXQgdGhlIG5lZWQgZm9yIGR5bmFtaWMNCnJlY29uZmlndXJhdGlv biBvZiBpbmZvcm1hdGlvbiB3aGljaCB3aWxsIGltcGFjdCBob3cgdGhleSBhY3QgYW5kDQppbnRl cmFjdC4gT24gYSBoaWdoIGxldmVsLCBpcyB0aGlzIHRoZSBwcm9ibGVtIHlvdSB3YW50IHRvIHdv cmsgb24gaW4gQUNFPw0KVGhpcyBpcyBub3Qgd2hhdCBzcHJpbmdzIHRvIG15IG1pbmQgd2hlbiBJ IHJlYWQgdGhlIGNoYXJ0ZXIsIGJ1dCB0aGVuDQphZ2Fpbiwgd2Ugc2VlbSB0byBpbnRlcnByZXQg ImF1dGhvcml6YXRpb24iIHF1aXRlIGRpZmZlcmVudGx5LiAoTGV04oCZcyBub3QNCm1ha2UgdGhp cyBhIOKAnENoYXJ0ZXIgYW5kIERpY3Rpb25hcnnigJ0gc2VxdWVsLCBJ4oCZbSBqdXN0IHRyeWlu ZyB0byBzdW1tYXJpemUNCmhvdyB3ZSBnb3QgaW50byB0aGUgdHJlbmNoZXMgdG8gc2VlIGlmIHdl IGNhbiBnZXQgb3V0LikNCg0KTm93IHRoZSBwcm9ibGVtIHdpdGggdGVybWlub2xvZ3kuIEN1cnJl bnQgdGVybWlub2xvZ3kgZXNzZW50aWFsbHkgb25seQ0KdXNlcyB0aGUgdGVybSDigJxwcmluY2lw YWwiIHdoaWNoIGVzc2VudGlhbGx5IG1lYW5zIOKAnGFueW9uZeKAnS4gU2luY2UgdGhlDQpvdGhl ciB0ZXJtcyBhcmUgbm90IHVzZWQsIHRoZXkgYXJlIHJlZHVuZGFudCwgc28gd2UgY2FuIGVzc2Vu dGlhbGx5IHJlbW92ZQ0KdGhlIHRlcm1pbm9sb2d5IHNlY3Rpb24uIEFjdHVhbGx5LCBmcm9tIGEg cGVkYWdvZ2ljYWwgcG9pbnQgb2YgdmlldywgdGhlDQpjdXJyZW50IHRlcm1pbm9sb2d5IG1ha2Vz IHRoZSBzaXR1YXRpb24gd29yc2UgdGhhbiBubyB0ZXJtaW5vbG9neSBhdCBhbGwsDQpzaW5jZSBp dCBtYWtlcyB0aGUgcmVhZGVyIGZpcnN0IGZvY3VzIG9uIHRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVu IHJlc291cmNlDQphbmQgY2xpZW50LCBhbmQgdGhlbiBpbiB0aGUgImF1dGhvcml6YXRpb24gcHJv YmxlbSBzdW1tYXJ54oCdLCB3aXRob3V0IGFueQ0KZXhwbGFuYXRpb24sIHN1bW1hcml6ZXMgdGhh dCBldmVyeXRoaW5nIHRoYXQgYXBwbGllcyB0byB0aGUgcmVzb3VyY2UgYWxzbw0KYXBwbGllcyB0 byB0aGUgY2xpZW50LiBUaGlzIGlzIHN0aWxsIGEgcHJvYmxlbSBJIGhhdmUgd2l0aCBncm91cGlu ZyBzZXJ2ZXINCmFuZCBjbGllbnQgY29uY2VybnMgaW4gb25lIHNlbnRlbmNlLCBidXQgZW5vdWdo IHNhaWQgb24gdGhhdC4NCg0KTWF5YmUgaXQgaXMgZ29vZCBpZGVhIGFueXdheSBpZiB3ZSBsZWF2 ZSBvdXQgYXJjaGl0ZWN0dXJlIGltcGx5aW5nDQp0ZXJtaW5vbG9neSBpbiB0aGUgdXNlIGNhc2Ug ZG9jdW1lbnQgZm9yIG5vdywgb3IganVzdCBoYXZlIGEgdGVybSBmb3INCuKAnHN0YWtlaG9sZGVy 4oCdLCBhbmQgZmlyc3QgaGF2ZSBhIGRpc2N1c3Npb24gd2hldGhlciB3ZSBzaG91bGQgd29yayBi ZXlvbmQNCmFjY2VzcyBjb250cm9sIGluIEFDRT8NCg0KDQooQSBmZWVibGUgdGhvdWdodCBoZXJl OiByYXRoZXIgdGhhbiBmb2N1cyBvZiDigJxSZXNvdXJjZeKAnSwgb25lIGNvdWxkIGZvY3VzDQpv biDigJxTb3VyY2XigJ0gKEdFVCBTZXJ2ZXIgb3IgUFVUL1BPU1QgQ2xpZW50KSBhcyBhIGNvbnRh c3QgdG8g4oCcU2lua+KAnSAoR0VUDQpDbGllbnQgb3IgUFVUL1BPU1QgU2VydmVyKS4gVGhlbiBh dCBsZWFzdCBvbmUgZ2V0cyBhIGhpbnQgdG8gd2h5IHRoZQ0KcHJvYmxlbSB5b3Ugd2FudCB0byBz b2x2ZSBpcyBzb21laG93IGludGVydHdpbmVkIGluIGNsaWVudCBhbmQgc2VydmVyLikNCg0KDQpC ZXN0IHJlZ2FyZHMsDQpHw7ZyYW4NCg0KDQoNCk9uIDIwMTUtMDMtMDYgMTg6NDksICJTdGVmYW5p ZSBHZXJkZXMiIDxnZXJkZXNAdHppLmRlPiB3cm90ZToNCg0KPkhpIFN0ZXZlLA0KPg0KPk9uIDAz LzA2LzIwMTUgMDY6NDAgUE0sIE1vb3JlLCBTdGV2ZSB3cm90ZToNCj4+IEFoIGhhLCBJIHRoaW5r IEkgbm93IHVuZGVyc3RhbmQgd2hhdCB0aGUgY29yZSBvZiB0aGUgZGlzY3Vzc2lvbiBpcy4NCj4+ KE90aGVyDQo+PiBjb21tZW50cyBpbmxpbmUpDQo+Pg0KPj4gT24gMy82LzE1LCAxMTo0MSBBTSwg IlN0ZWZhbmllIEdlcmRlcyIgPGdlcmRlc0B0emkuZGU+IHdyb3RlOg0KPj4NCj4+PiBIaSBTdGV2 ZSwNCj4+Pg0KPj4+IFRoYW5rIHlvdSBmb3IgeW91IGNvbW1lbnQuDQo+Pj4NCj4+PiBPbiAwMy8w Ni8yMDE1IDA1OjE0IFBNLCBNb29yZSwgU3RldmUgd3JvdGU6DQo+Pj4+IEhpIGV2ZXJ5b25lIChu ZXcgdG8gcG9zdGluZyB0byB0aGUgbGlzdCwgYnV0IGhhdmUgYmVlbiB3YXRjaGluZyBmb3IgYQ0K Pj4+PiBiaXQpLA0KPj4+Pg0KPj4+PiBJdCBzZWVtcyB0byBtZSB0aGF0IHRoZSBkaXNjdXNzaW9u IGhhcyB3YW5kZXJlZCBpbnRvIHNwZWNpZmljDQo+Pj4+IGltcGxlbWVudGF0aW9ucyBvZiBzb2x1 dGlvbnMgdG8gdGhlIHVzZSBjYXNlLiBJdCByZWFsbHkgc2VlbXMgdGhhdCB0aGUNCj4+Pj4gdXNl IGNhc2UgaXMgY29tcGFueSBBIGhhcyBzZW5zb3JzIGluIGJveGVzIHRoYXQgYXJlIHNoaXBwZWQg dmlhIGENCj4+Pj4gY29udGFpbmVyIHRoYXQgY29tcGFueSBCIG93bnMuIFRoZSBjb250YWluZXIg aGFzIGFuIGFjdHVhdG9yIG93bmVkIGJ5DQo+Pj4+IGNvbXBhbnkgQi4gKEkga25vdyBvd25lcnNo aXAgaXMgYSBjb250ZXN0ZWQgdGhpbmcgaGVyZS4uLikgVGhlDQo+Pj4+YWN0dWF0b3INCj4+Pj4g c2hvdWxkIG9wZXJhdGVkIGJhc2VkIG9uIHRoZSB2YWx1ZXMgdGhlIHNlbnNvcnMgaGF2ZS4gVGhl IGxvZ2ljIGNvdWxkDQo+Pj4+YmUNCj4+Pj4gaW4gdGhlIGZhbiwgb3IgaXQgY291bGQgYmUgaW4g dGhlIHNlbnNvcnMuIFRoZSBkaXJlY3Rpb25hbGl0eSBvZiB0aGUNCj4+Pj4gcmVxdWVzdHMgY291 bGQgYmUgZWl0aGVyIHdheS4gVGhvc2UgZGV0YWlscyBhcmUgdXAgdG8gdGhlIHBlb3BsZQ0KPj4+ PiBkZXNpZ25pbmcgdGhlIEJhbmFuYSBDb250YWluZXIgTW9uaXRvcmluZyBwcm90b2NvbCB3aGlj aCB3b3VsZA0KPj4+PmhvcGVmdWxseQ0KPj4+PiB1c2UgdGhlIEFDRSBwcm90b2NvbCBmb3IgYXV0 aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24uIElmIEkgd2VyZQ0KPj4+PiBidWlsZGluZyBz dWNoIGEgc3lzdGVtIEknZCBwcm9iYWJseSBnbyB3aXRoIHRoZSBDb0FQIG9ic2VydmUgcm91dGUN Cj4+Pj4gaGF2aW5nIHRoZSBmYW4gaGF2ZSBhdXRob3JpemF0aW9uIHRvIGNvbW11bmljYXRlIHdp dGggc3BlY2lmaWMNCj4+Pj5zZW5zb3JzLg0KPj4+PiBUaGVyZSB3b3VsZCBiZSBhbm90aGVyIHNl dCBvZiBhdXRob3JpemF0aW9ucyBmb3IgdGhlIGd1eSB3aG8gaXMNCj4+Pj5sb2FkaW5nDQo+Pj4+ IHRoZSBjb250YWluZXIgdG8gbW9kaWZ5IHRoZSBzZW5zb3IgSUQgbGlzdCBpbiB0aGUgZmFuLg0K Pj4+DQo+Pj4gWWVzLCBpdCBzaG91bGQgYmUgdXAgdGhlIGltcGxlbWVudG9yIHdoaWNoIGRldmlj ZSBpcyB0aGUgY2xpZW50IGFuZA0KPj4+IHdoaWNoIGlzIHRoZSBzZXJ2ZXIuIEkgY29tcGxldGVs eSBhZ3JlZSB3aXRoIHRoaXMuDQo+Pj4NCj4+PiBHw7ZyYW4gcHJvcG9zZXMgdGhhdCB3ZSBkZWZp bmUgdGhhdCBmcnVpdCB2ZW5kb3JzIGFuZCBjb250YWluZXIgb3duZXJzDQo+Pj4gYXJlIHJlc291 cmNlIG93bmVycy4gVGhpcyBpbXBsaWVzIHRoYXQgZnJ1aXQgdmVuZG9ycyBhbmQgY29udGFpbmVy DQo+Pj4gb3duZXJzIGNvbnRyb2wgdGhlIHNlcnZlciBzaW5jZSBvbmx5IENvQVAgc2VydmVycyBo YXZlIHJlc291cmNlcy4NCj4+Pg0KPj4+IE9uZSBwb3NzaWJsZSBjb25maWd1cmF0aW9uIGlzIHRo YXQgdGhlIHRlbXBlcmF0dXJlIHNlbnNvciBvZiB0aGUgZnJ1aXQNCj4+PiB2ZW5kb3IgaXMgdGhl IGNsaWVudCBhbmQgdGhlIGZhbiBhY3R1YXRvciBpcyB0aGUgc2VydmVyLiBJZiB3ZSBkZWZpbmUN Cj4+PiB0aGF0IGZydWl0IHZlbmRvcnMgYXJlIHJlc291cmNlIG93bmVycywgdGhpcyBjb25maWd1 cmF0aW9uIHdvdWxkIG5vdCBiZQ0KPj4+IHBvc3NpYmxlIHNpbmNlIGNsaWVudHMgZG9uJ3QgaGF2 ZSByZXNvdXJjZXMuIFdlIHdvdWxkIG5lZWQgYSBjbGllbnQNCj4+PiBkZXZpY2UgYmV0d2VlbiB0 aGUgc2VydmVyIG9mIHRoZSBmcnVpdCB2ZW5kb3IgYW5kIHRoZSBzZXJ2ZXIgb2YgdGhlDQo+Pj4g Y29udGFpbmVyIG93bmVyLg0KPj4NCj4+IEp1c3QgYmVjYXVzZSB0aGUgZnJ1aXQgdmVuZG9yIGlz IGEgcmVzb3VyY2Ugb3duZXIgZG9lc27CuXQgcHJlY2x1ZGUgaXQNCj4+ZnJvbQ0KPj4gYWxzbyBi ZWluZyBhIGNsaWVudC4NCj4+IFRha2luZyB0aGUgSFRUUCBkZWZpbml0aW9uIG9mIHJlc291cmNl IChhbmQgaGVuY2UgQ29BUMK5cyBkZWZpbml0aW9uIG9mDQo+PiByZXNvdXJjZSkgYXMgYSDCs25l dHdvcmsgZGF0YSBvYmplY3Qgb3Igc2VydmljZSB0aGF0IGNhbiBiZSBpZGVudGlmaWVkDQo+PmJ5 IGENCj4+IFVSScKyLCBJIGNhbiBzZWUgdGhlIGlzc3VlIHdpdGggxZJyZXNvdXJjZSBvd25lcsK5 Lg0KPj4gQWx0aG91Z2ggaXQgc2hvdWxkIGJlIG5vdGVkIHRoYXQgbmVpdGhlciBzcGVjIGRlZmlu ZXMgYSDFknJlc291cmNlIG93bmVywrkNCj4+IGluIHBhcnRpY3VsYXIsIGFuZCB0aGUgQ29BUCBz cGVjIGRvZXMgZGVmaW5lIHRoYXQgcmVxdWVzdHMgY2FuIGluY2x1ZGUgYQ0KPj4gcmVwcmVzZW50 YXRpb24gb2YgYSByZXNvdXJjZS4NCj4+DQo+PiBIb3dldmVyLCBpZiB3ZSB3ZXJlIHRvIGltYWdp bmUgYSBzeXN0ZW0gYnVpbHQgb24gTVFUVCwgdGhleSBkb27CuXQNCj4+ZGVmaW5lIGENCj4+IHJl c291cmNlIHNvIHRoYXQgaXNzdWUgZ29lcyBhd2F5LiAoQSBidW5jaCBvZiBvdGhlcnMgcHJvYmFi bHkgcG9wIHVwIGJ1dA0KPj4gdGhhdCBpcyBiZXNpZGVzIHRoZSBwb2ludCkNCj4+DQo+PiBJIGNh bsK5dCByZWFsbHkgc2VlIGEgZ29vZCB3YXkgdG8gZGVmaW5lIGEgcmVzb3VyY2Ugb3duZXIgaW4g dGhlIGFic3RyYWN0DQo+PiBjYXNlIHRoYXQgYSBjbGllbnQgY2FuIHNlbmQgdGhlIHJlc291cmNl IG9uIHRvIHRoZSBzZXJ2ZXIgdGhhdCBkb2VzbsK5dA0KPj4gY29uZmxpY3Qgd2l0aCB0aGUgSFRU UC9Db0FQIHJlc291cmNlIGRlZmluaXRpb24uDQo+PiBEYXRhIE93bmVyPyBEb2VzbsK5dCBzZWVt IGdlbmVyaWMgZW5vdWdoxaANCj4NCj5SaWdodCBub3cgdGhlIHVzZSBjYXNlcyBkb2N1bWVudCB1 c2VzIHRoZSB0ZXJtICJwcmluY2lwYWwiOiBBIHN1YmplY3QNCj53aG8gaXMgZWl0aGVyIGEgcmVz b3VyY2Ugb3duZXIgb3IgYSBjbGllbnQgb3duZXIgb3IgYm90aC4NCj4NCj5Hw7ZyYW4ncyBwcm9w b3NhbCBpcyB0byByZXBsYWNlIHRoZSB0ZXJtICJwcmluY2lwYWwiIGJ5ICJyZXNvdXJjZSBvd25l ciIuDQo+VGhpcyBpcyBvbmUgcGFydCBvZiB0aGUgY3VycmVudCBkaXNjdXNzaW9uLg0KPg0KPkJl c3QgcmVnYXJkcywNCj5TdGVmZmkNCj4NCj4NCg0K From nobody Sun Mar 8 07:26: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 901791A8720 for ; Sun, 8 Mar 2015 07:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.45 X-Spam-Level: * X-Spam-Status: No, score=1.45 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 uZ5qpyiLZvKc for ; Sun, 8 Mar 2015 07:26:34 -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 9A0991A871F for ; Sun, 8 Mar 2015 07:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t28EQSM1027549; Sun, 8 Mar 2015 15:26:28 +0100 (CET) Received: from [192.168.1.109] (p57A639B0.dip0.t-ipconnect.de [87.166.57.176]) (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 3l0Q3S4KWfz2klN; Sun, 8 Mar 2015 15:26:28 +0100 (CET) Message-ID: <54FC5C10.10902@tzi.de> Date: Sun, 08 Mar 2015 15:26:24 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= , "Moore, Steve" , "Ace@ietf.org" References: <54F5B1F2.6050205@gmx.net> <54F616CF.20607@tzi.de> <54F81652.6040102@tzi.de> <54F97FC5.4020305@tzi.de> <54F9BD0C.5070302@tzi.de> <1425658471858.51869@mitre.org> <54F9D8B7.4050708@tzi.de> <54F9E8B7.5050209@tzi.de> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Hannes Tschofenig Subject: Re: [Ace] U1.2 in Use Case Document 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, 08 Mar 2015 14:26:36 -0000 Hi Göran, On 03/07/2015 08:19 AM, Göran Selander wrote: > Hi Steffi, hi Steve > > In the last few mails have surfaced some new aspects and I think I > understand better what you are after, Steffi. Thanks Steve for stepping in > and provided a outside view. So we agree that we want to leave it to the implementers to decide which device is the CoAP client and which is the CoAP server? > > A lot of the discussion so far has centered on whether this issue on the > client side is an access control problem or not. I maintain it isn’t, and > I believe I have support for that opinion. Just because the client is > constrained doesn’t change that, unfortunately. If we don't want to exclude settings where the fruit vendor's sensor is the client we need to make sure that the client is able to enforce the security policies of its owner. Authorization on the server side will not solve this problem. Authorization on the client side does. Considering this, I see no reason to exclude client side authorization. > > Trying to be more constructive, the similarity between the client problem > and server problem is that both are about the need for dynamic > reconfiguration of information which will impact how they act and > interact. On a high level, is this the problem you want to work on in ACE? > This is not what springs to my mind when I read the charter, but then > again, we seem to interpret "authorization" quite differently. (Let’s not > make this a “Charter and Dictionary” sequel, I’m just trying to summarize > how we got into the trenches to see if we can get out.) > > Now the problem with terminology. Current terminology essentially only > uses the term “principal" which essentially means “anyone”. A principal is "a subject who is either a resource owner or a client owner or both" and therefore refers to the subject who controls the authorizations for a resource and / or a client. Since the important aspect is who is in charge of authorizations, I would think that this is exactly the term that we need here. We can remove the terms client owner and resource owner as you proposed and change the definition of principal to: Principal: The subject who controls the authorizations for a resource and / or a client. > Maybe it is good idea anyway if we leave out architecture implying > terminology in the use case document for now, or just have a term for > “stakeholder”, and first have a discussion whether we should work beyond > access control in ACE? I don't see a need right now to discuss if we want to work on other things then authentication and authorization in ACE. > > (A feeble thought here: rather than focus of “Resource”, one could focus > on “Source” (GET Server or PUT/POST Client) as a contast to “Sink” (GET > Client or PUT/POST Server). Then at least one gets a hint to why the > problem you want to solve is somehow intertwined in client and server.) I prefer to describe the problems using the CoAP terminology because we want to find an authorization solution that works with CoAP or similar protocols in this area. It might be difficult to figure out how to map something to CoAP if we use a different terminology in the use cases. Best regards, Steffi From nobody Sun Mar 8 13:35: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 365931A0146 for ; Sun, 8 Mar 2015 13:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 d0vS89MC-6AL for ; Sun, 8 Mar 2015 13:34:56 -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 7E8651A013B for ; Sun, 8 Mar 2015 13:34:54 -0700 (PDT) X-AuditID: c1b4fb2d-f79aa6d00000359d-8e-54fcb26c329c Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 0F.B7.13725.C62BCF45; Sun, 8 Mar 2015 21:34:52 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.70]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0210.002; Sun, 8 Mar 2015 21:34:51 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Stefanie Gerdes , "Ace@ietf.org" Thread-Topic: [Ace] U1.2 in Use Case Document Thread-Index: AQHQVbL1RkiN6OYzzEyLTf3fE9ZKCp0K/GYAgAAliYCAAe0ZgIAAdKwAgAGEugCAACoogIAAMFIAgAAYugCAACYWgP//82UAgAAHgYCAABCigIAAAnCAgADzCQCAAfjTAIAAd7QA Date: Sun, 8 Mar 2015 20:34:50 +0000 Message-ID: References: <54F5B1F2.6050205@gmx.net> <54F616CF.20607@tzi.de> <54F81652.6040102@tzi.de> <54F97FC5.4020305@tzi.de> <54F9BD0C.5070302@tzi.de> <1425658471858.51869@mitre.org> <54F9D8B7.4050708@tzi.de> <54F9E8B7.5050209@tzi.de> <54FC5C10.10902@tzi.de> In-Reply-To: <54FC5C10.10902@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: <2A0F41FA6FF9E54593DC02C481364AE6@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGfG3Rjdn058Qg3kXZC2+f+thtth48S6j A5PHkiU/mTy2vf3KHMAUxWWTkpqTWZZapG+XwJXxr/EZY0GPfkXD/bPMDYwfdLsYOTkkBEwk 3j99xgRhi0lcuLeerYuRi0NI4AijxPnvv6GcRYwSPfdaWECq2ARcJB40PALrEBFwkli67S9Y XFhAR2Lr3x2MXYwcQHFdievrvUB6RQSmMUqsW3CWEaSGRUBF4sSPrWD1vAIWEu933IBasJNF YkPjTlaQBCdQ0cp3T5hBbEagk76fWgO2jFlAXOLWk/lQpwpILNlznhnCFpV4+fgfWK+ogJ7E yutNbBBxJYnGJU9YQQ5iFtCUWL9LH2KMtcSclw1QIxUlpnQ/ZIe4R1Di5MwnLBMYxWch2TYL oXsWku5ZSLpnIelewMi6ilG0OLW4ODfdyFgvtSgzubg4P08vL7VkEyMw3g5u+a27g3H1a8dD jAIcjEo8vBu0/4QIsSaWFVfmHmKU5mBREue1Mz4UIiSQnliSmp2aWpBaFF9UmpNafIiRiYNT qoHR4XBMx/vqkjyD4sxdN1dNW7Vv5yNp6WlHPlR0dT0Ul7Fbz9a/lrPx/OYlrt/mn+iPPsks cYV93dTKZbUnija8cJm21umpxKSpQa+WCd1tmL1C+/eLU3U2cq+WLFv2ueZh9Wv1NdM4p9/x XMN58X/hUZ7PkRfs8543rfy2ZvWdL3ccvA/+nZvtaa3EUpyRaKjFXFScCACOGpMymAIAAA== Archived-At: Subject: Re: [Ace] U1.2 in Use Case Document 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, 08 Mar 2015 20:34:58 -0000 SGkgU3RlZmZpDQoNCkluIG15IHByZXZpb3VzIG1haWwgSSBqdXN0IHdhbnRlZCB0byBzYXkgdGhh dCBJIHRoaW5rIEkgdW5kZXJzdGFuZCBiZXR0ZXINCndoYXQgeW91IGFyZSBhZnRlci4gVGhlIGNv cmUgb2YgdGhlIGRpc2N1c3Npb24gaXMgc3RpbGwgYWJvdXQgd2hhdCBpcyB0aGUNCm5hdHVyZSBv ZiB0aGUgcHJvYmxlbSBvbiB0aGUgY2xpZW50IHNpZGUgYW5kIHdoZXRoZXIgdGhhdCBpcyBpbiBz Y29wZSBvZg0KQUNFLiBTaW5jZSB3ZSBkaXNhZ3JlZSBhYm91dCB0aGF0LCBJIGRvbuKAmXQgZmlu ZCBpdCBtZWFuaW5nZnVsIHRvIHRyeSB0bw0KYWdyZWUgb24gZGV0YWlscy4gTGV04oCZcyBmb2N1 cyBvbiB0aGUgdXNlIGNhc2UgdGVybWlub2xvZ3kgYW5kIGdldCB0aGF0DQpkb25lLg0KDQpZb3Vy IGxhdGVzdCBwcm9wb3NhbCBmb3IgInByaW5jaXBhbOKAnSBpdCBpcyBxdWl0ZSBzaW1pbGFyIHRv IHRoZSBleGlzdGluZy4NCklmIHlvdSBhcmUgbm90IHByZXBhcmVkIHRvIGxlYXZlIG91dCBjbGll bnQgYXV0aG9yaXphdGlvbiwgdGhlbiBiZXR0ZXINCnJlbW92ZSBwcmluY2lwYWwgYW5kIGRvIGFz IHlvdSBwcm9wb3NlZCBpbiB5b3VyIHJlY2VudCB1cGRhdGU6DQoNCmh0dHA6Ly93d3cuaWV0Zi5v cmcvbWFpbC1hcmNoaXZlL3dlYi9hY2UvY3VycmVudC9tc2cwMTA0Mi5odG1sDQoNCkkgcmVhZCB0 aHJvdWdoIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucywgYW5kIGl0IGlzIGFjdHVhbGx5IHF1 aXRlDQpzdHJhaWdodGZvcndhcmQgdG8gcmVtb3ZlIOKAnHByaW5jaXBhbOKAnSBhbmQgbWFpbnRh aW4gdGhlIGdpc3Qgb2YgdGhlDQptZXNzYWdlLiBJIHZvbHVudGVlciB0byBkbyB0aGF0IHVubGVz cyBzb21lb25lIGVsc2UgZmVlbHMgY2hhbGxlbmdlZC4NCg0KQmVzdCByZWdhcmRzLA0KR8O2cmFu DQoNCg0KDQoNCk9uIDIwMTUtMDMtMDggMTU6MjYsICJTdGVmYW5pZSBHZXJkZXMiIDxnZXJkZXNA dHppLmRlPiB3cm90ZToNCg0KPkhpIEfDtnJhbiwNCj4NCj5PbiAwMy8wNy8yMDE1IDA4OjE5IEFN LCBHw7ZyYW4gU2VsYW5kZXIgd3JvdGU6DQo+PiBIaSBTdGVmZmksIGhpIFN0ZXZlDQo+Pg0KPj4g SW4gdGhlIGxhc3QgZmV3IG1haWxzIGhhdmUgc3VyZmFjZWQgc29tZSBuZXcgYXNwZWN0cyBhbmQg SSB0aGluayBJDQo+PiB1bmRlcnN0YW5kIGJldHRlciB3aGF0IHlvdSBhcmUgYWZ0ZXIsIFN0ZWZm aS4gVGhhbmtzIFN0ZXZlIGZvciBzdGVwcGluZw0KPj5pbg0KPj4gYW5kIHByb3ZpZGVkIGEgb3V0 c2lkZSB2aWV3Lg0KPg0KPlNvIHdlIGFncmVlIHRoYXQgd2Ugd2FudCB0byBsZWF2ZSBpdCB0byB0 aGUgaW1wbGVtZW50ZXJzIHRvIGRlY2lkZSB3aGljaA0KPmRldmljZSBpcyB0aGUgQ29BUCBjbGll bnQgYW5kIHdoaWNoIGlzIHRoZSBDb0FQIHNlcnZlcj8NCj4NCj4+DQo+PiBBIGxvdCBvZiB0aGUg ZGlzY3Vzc2lvbiBzbyBmYXIgaGFzIGNlbnRlcmVkIG9uIHdoZXRoZXIgdGhpcyBpc3N1ZSBvbiB0 aGUNCj4+IGNsaWVudCBzaWRlIGlzIGFuIGFjY2VzcyBjb250cm9sIHByb2JsZW0gb3Igbm90LiBJ IG1haW50YWluIGl0IGlzbuKAmXQsDQo+PmFuZA0KPj4gSSBiZWxpZXZlIEkgaGF2ZSBzdXBwb3J0 IGZvciB0aGF0IG9waW5pb24uIEp1c3QgYmVjYXVzZSB0aGUgY2xpZW50IGlzDQo+PiBjb25zdHJh aW5lZCBkb2VzbuKAmXQgY2hhbmdlIHRoYXQsIHVuZm9ydHVuYXRlbHkuDQo+DQo+SWYgd2UgZG9u J3Qgd2FudCB0byBleGNsdWRlIHNldHRpbmdzIHdoZXJlIHRoZSBmcnVpdCB2ZW5kb3IncyBzZW5z b3IgaXMNCj50aGUgY2xpZW50IHdlIG5lZWQgdG8gbWFrZSBzdXJlIHRoYXQgdGhlIGNsaWVudCBp cyBhYmxlIHRvIGVuZm9yY2UgdGhlDQo+c2VjdXJpdHkgcG9saWNpZXMgb2YgaXRzIG93bmVyLiBB dXRob3JpemF0aW9uIG9uIHRoZSBzZXJ2ZXIgc2lkZSB3aWxsDQo+bm90IHNvbHZlIHRoaXMgcHJv YmxlbS4gQXV0aG9yaXphdGlvbiBvbiB0aGUgY2xpZW50IHNpZGUgZG9lcy4NCj5Db25zaWRlcmlu ZyB0aGlzLCBJIHNlZSBubyByZWFzb24gdG8gZXhjbHVkZSBjbGllbnQgc2lkZSBhdXRob3JpemF0 aW9uLg0KPg0KPj4NCj4+IFRyeWluZyB0byBiZSBtb3JlIGNvbnN0cnVjdGl2ZSwgdGhlIHNpbWls YXJpdHkgYmV0d2VlbiB0aGUgY2xpZW50DQo+PnByb2JsZW0NCj4+IGFuZCBzZXJ2ZXIgcHJvYmxl bSBpcyB0aGF0IGJvdGggYXJlIGFib3V0IHRoZSBuZWVkIGZvciBkeW5hbWljDQo+PiByZWNvbmZp Z3VyYXRpb24gb2YgaW5mb3JtYXRpb24gd2hpY2ggd2lsbCBpbXBhY3QgaG93IHRoZXkgYWN0IGFu ZA0KPj4gaW50ZXJhY3QuIE9uIGEgaGlnaCBsZXZlbCwgaXMgdGhpcyB0aGUgcHJvYmxlbSB5b3Ug d2FudCB0byB3b3JrIG9uIGluDQo+PkFDRT8NCj4+IFRoaXMgaXMgbm90IHdoYXQgc3ByaW5ncyB0 byBteSBtaW5kIHdoZW4gSSByZWFkIHRoZSBjaGFydGVyLCBidXQgdGhlbg0KPj4gYWdhaW4sIHdl IHNlZW0gdG8gaW50ZXJwcmV0ICJhdXRob3JpemF0aW9uIiBxdWl0ZSBkaWZmZXJlbnRseS4gKExl dOKAmXMNCj4+bm90DQo+PiBtYWtlIHRoaXMgYSDigJxDaGFydGVyIGFuZCBEaWN0aW9uYXJ54oCd IHNlcXVlbCwgSeKAmW0ganVzdCB0cnlpbmcgdG8NCj4+c3VtbWFyaXplDQo+PiBob3cgd2UgZ290 IGludG8gdGhlIHRyZW5jaGVzIHRvIHNlZSBpZiB3ZSBjYW4gZ2V0IG91dC4pDQo+Pg0KPj4gTm93 IHRoZSBwcm9ibGVtIHdpdGggdGVybWlub2xvZ3kuIEN1cnJlbnQgdGVybWlub2xvZ3kgZXNzZW50 aWFsbHkgb25seQ0KPj4gdXNlcyB0aGUgdGVybSDigJxwcmluY2lwYWwiIHdoaWNoIGVzc2VudGlh bGx5IG1lYW5zIOKAnGFueW9uZeKAnS4NCj4NCj5BIHByaW5jaXBhbCBpcyAiYSBzdWJqZWN0IHdo byBpcyBlaXRoZXIgYSByZXNvdXJjZSBvd25lciBvciBhIGNsaWVudA0KPm93bmVyIG9yIGJvdGgi IGFuZCB0aGVyZWZvcmUgcmVmZXJzIHRvIHRoZSBzdWJqZWN0IHdobyBjb250cm9scyB0aGUNCj5h dXRob3JpemF0aW9ucyBmb3IgYSByZXNvdXJjZSBhbmQgLyBvciBhIGNsaWVudC4gU2luY2UgdGhl IGltcG9ydGFudA0KPmFzcGVjdCBpcyB3aG8gaXMgaW4gY2hhcmdlIG9mIGF1dGhvcml6YXRpb25z LCBJIHdvdWxkIHRoaW5rIHRoYXQgdGhpcyBpcw0KPmV4YWN0bHkgdGhlIHRlcm0gdGhhdCB3ZSBu ZWVkIGhlcmUuIFdlIGNhbiByZW1vdmUgdGhlIHRlcm1zIGNsaWVudCBvd25lcg0KPmFuZCByZXNv dXJjZSBvd25lciBhcyB5b3UgcHJvcG9zZWQgYW5kIGNoYW5nZSB0aGUgZGVmaW5pdGlvbiBvZg0K PnByaW5jaXBhbCB0bzoNCj4NCj5QcmluY2lwYWw6IFRoZSBzdWJqZWN0IHdobyBjb250cm9scyB0 aGUgYXV0aG9yaXphdGlvbnMgZm9yIGEgcmVzb3VyY2UNCj5hbmQgLyBvciBhIGNsaWVudC4NCj4N Cj4gPiBNYXliZSBpdCBpcyBnb29kIGlkZWEgYW55d2F5IGlmIHdlIGxlYXZlIG91dCBhcmNoaXRl Y3R1cmUgaW1wbHlpbmcNCj4gPiB0ZXJtaW5vbG9neSBpbiB0aGUgdXNlIGNhc2UgZG9jdW1lbnQg Zm9yIG5vdywgb3IganVzdCBoYXZlIGEgdGVybSBmb3INCj4gPiDigJxzdGFrZWhvbGRlcuKAnSwg YW5kIGZpcnN0IGhhdmUgYSBkaXNjdXNzaW9uIHdoZXRoZXIgd2Ugc2hvdWxkIHdvcmsNCj5iZXlv bmQNCj4gPiBhY2Nlc3MgY29udHJvbCBpbiBBQ0U/DQo+DQo+SSBkb24ndCBzZWUgYSBuZWVkIHJp Z2h0IG5vdyB0byBkaXNjdXNzIGlmIHdlIHdhbnQgdG8gd29yayBvbiBvdGhlcg0KPnRoaW5ncyB0 aGVuIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIGluIEFDRS4NCj4NCj4gPg0KPiA+ IChBIGZlZWJsZSB0aG91Z2h0IGhlcmU6IHJhdGhlciB0aGFuIGZvY3VzIG9mIOKAnFJlc291cmNl 4oCdLCBvbmUgY291bGQNCj5mb2N1cw0KPiA+IG9uIOKAnFNvdXJjZeKAnSAoR0VUIFNlcnZlciBv ciBQVVQvUE9TVCBDbGllbnQpIGFzIGEgY29udGFzdCB0byDigJxTaW5r4oCdIChHRVQNCj4gPiBD bGllbnQgb3IgUFVUL1BPU1QgU2VydmVyKS4gVGhlbiBhdCBsZWFzdCBvbmUgZ2V0cyBhIGhpbnQg dG8gd2h5IHRoZQ0KPiA+IHByb2JsZW0geW91IHdhbnQgdG8gc29sdmUgaXMgc29tZWhvdyBpbnRl cnR3aW5lZCBpbiBjbGllbnQgYW5kIHNlcnZlci4pDQo+DQo+SSBwcmVmZXIgdG8gZGVzY3JpYmUg dGhlIHByb2JsZW1zIHVzaW5nIHRoZSBDb0FQIHRlcm1pbm9sb2d5IGJlY2F1c2Ugd2UNCj53YW50 IHRvIGZpbmQgYW4gYXV0aG9yaXphdGlvbiBzb2x1dGlvbiB0aGF0IHdvcmtzIHdpdGggQ29BUCBv ciBzaW1pbGFyDQo+cHJvdG9jb2xzIGluIHRoaXMgYXJlYS4gSXQgbWlnaHQgYmUgZGlmZmljdWx0 IHRvIGZpZ3VyZSBvdXQgaG93IHRvIG1hcA0KPnNvbWV0aGluZyB0byBDb0FQIGlmIHdlIHVzZSBh IGRpZmZlcmVudCB0ZXJtaW5vbG9neSBpbiB0aGUgdXNlIGNhc2VzLg0KPg0KPkJlc3QgcmVnYXJk cywNCj5TdGVmZmkNCg0K From nobody Sun Mar 8 18:10: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 A83401A007B for ; Sun, 8 Mar 2015 18:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.514 X-Spam-Level: * X-Spam-Status: No, score=1.514 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 NkpN9pcw40gt for ; Sun, 8 Mar 2015 18:10:03 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 585CA1A0052 for ; Sun, 8 Mar 2015 18:10:03 -0700 (PDT) Received: from [217.140.96.140] by 3capp-gmx-bs34.server.lan (via HTTP); Mon, 9 Mar 2015 02:10:01 +0100 MIME-Version: 1.0 Message-ID: From: "Hannes Tschofenig" To: ace@ietf.org Content-Type: text/html; charset=UTF-8 Date: Mon, 9 Mar 2015 02:10:01 +0100 Importance: normal Sensitivity: Normal X-Priority: 3 X-Provags-ID: V03:K0:e6+akxXXSdcRhiM0NmSWnIVbcBK7+pcLEDolB5GkQpV tVy16F+uuT3GGbC53+xAE46+aGRlscHNLZaGthXbxu8XtbytBh 1k8l3FKVYWAkYcUPWqAl/dmG2v65UstcpRFCX2BPXL2AHPG3Nn sCKWg1+b3TOd3oLXOyXKhPjEA7UYkm9zexgTRCP33Z4rfeEDrI wC+BfxrMymw67SbEeyxYbNjPZVopapBy0+HH2MfXK9uYKwDZlw Li0B8iS+VwvGSlZYONMcCKIJAL8xFi0DK12dXWFD8I0fHGbT0y Slk4cM= X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [Ace] draft-tschofenig-ace-oauth-iot-01 and draft-tschofenig-ace-oauth-bt-01 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, 09 Mar 2015 01:10:04 -0000
Refreshed these two documents to prevent them from expiring: 
http://www.ietf.org/id/draft-tschofenig-ace-oauth-iot-01.txt
http://www.ietf.org/id/draft-tschofenig-ace-oauth-bt-01.txt
 
Ciao
Hannes
 
 
From nobody Mon Mar 9 03:06: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 8E3181A875C for ; Mon, 9 Mar 2015 03:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xhm2nDhkNKK for ; Mon, 9 Mar 2015 03:06:51 -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 1306C1A8758 for ; Mon, 9 Mar 2015 03:06:50 -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 t29A6jji005630; Mon, 9 Mar 2015 11:06:45 +0100 (CET) Received: from [IPv6:2001:638:708:30da:88d7:8f69:3b87:6ed5] (unknown [IPv6:2001:638:708:30da:88d7:8f69:3b87:6ed5]) (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 3l0wFK3fY3z2lTH; Mon, 9 Mar 2015 11:06:45 +0100 (CET) Message-ID: <54FD70B2.2030601@tzi.de> Date: Mon, 09 Mar 2015 11:06:42 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= References: <201503090843.t298h3k6025846@mailhost.informatik.uni-bremen.de> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] U1.2 in Use Case Document 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, 09 Mar 2015 10:06:53 -0000 Hi Göran, I think you forgot to include the mailing list. On 03/09/2015 10:08 AM, Göran Selander wrote: > Hi Steffi, > > Let’s be brief, since you are probably also working on other drafts. > > This is a use case document. We should just describe what we consider are > the relevant to understand the access control problems of the use cases. > What you describe as acccess control problem (or authorization problems) > on the client is > not what I call an access control problem. Hence when you refer to > authorizations of a client I don’t consider that to be in scope of ACE. Yes, we should describe the problems that we have in certain use cases. Your proposal that we do authorization solely on the server side is not a problem. It is a solution. > > For the same reason, I don’t propose a new formulation, because you will > not approve of one which doesn’t explicitly mention the client, right? Wrong. I only want to make sure that the phrasing does not indicate that authorization on the server side is more important. > Or > would you accept something more general such as "Principal is an entity > setting access control polices” (I haven’t polished on this formulation as > it may be just a waste of time) How about "Principal: The subject who is in charge of granting authorizations". > > I don’t expect anyone of us to change opinion about this today, do you? > > When do you want an update of the security considerations? Since the client side / server side authorization problem is not mentioned in the security considerations as far as I can see, I don't see a need to update this section. If you see a problem there, please point it out to me. Concerning the problem summary sections, do we agree on the proposal in http://www.ietf.org/mail-archive/web/ace/current/msg01042.html: U1.1 Fruit vendors, transloading personnel and container owners want to define authorizations for their resources and endpoints. We can change this to: U1.1 Fruit vendors, transloading personnel and container owners want to grant different authorizations for their resources and/or endpoints to different parties. or to: U1.1 Fruit vendors, transloading personnel and container owners want to grant different authorizations to different parties. U1.2 The fruit vendor requires the integrity of the sensor data that pertains the state of the goods for climate control and to ensure the quality of the monitored recordings. U1.3 The container owner requires the integrity of the sensor data that is used for climate control. U1.4 The fruit vendor requires the confidentiality of the sensor data that pertains the state of the goods. U1.5 The fruit vendor may have several types of data that may be controlled by the same endpoint, e.g., sensor data and the data used for logistics. U1.6 The fruit vendor requires the confidentiality of the data that is used to locate the goods. U1.7 The fruit vendor requires the integrity of the data that is used to locate the goods. U1.8 The transloading personnel requires the integrity of the data that is used to locate the goods. U1.9 The container owner and the fruit vendor may not be present at the time of access and cannot manually intervene in the authorization process. U1.10 The fruit vendor, container owner and transloading company want to grant temporary access permissions to a party. U1.11 Messages between client and resource server might need to be forwarded over multiple hops. U1.12 The constrained devices might not always be able to reach the Internet. Best regards, Steffi From nobody Mon Mar 9 03:48: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 6D58B1A87A2 for ; Mon, 9 Mar 2015 03:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 G5LMnPavUYTj for ; Mon, 9 Mar 2015 03:48:06 -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 BF47C1A875C for ; Mon, 9 Mar 2015 03:48:05 -0700 (PDT) X-AuditID: c1b4fb25-f79b76d00000113a-98-54fd7a63d2f0 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id FA.00.04410.36A7DF45; Mon, 9 Mar 2015 11:48:03 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.70]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0210.002; Mon, 9 Mar 2015 11:48:03 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Stefanie Gerdes Thread-Topic: [Ace] U1.2 in Use Case Document Thread-Index: AQHQWkUGRkiN6OYzzEyLTf3fE9ZKCp0T3KaA////hwCAABxQAA== Date: Mon, 9 Mar 2015 10:48:03 +0000 Message-ID: References: <201503090843.t298h3k6025846@mailhost.informatik.uni-bremen.de> <54FD70B2.2030601@tzi.de> In-Reply-To: <54FD70B2.2030601@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.18] Content-Type: text/plain; charset="utf-8" Content-ID: <01E0B159FE10DA4E97F42DF5DB7CA360@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM+JvjW5y1d8QgyfXLC2+f+thtth48S6j A5PHkiU/mTy2vf3KHMAUxWWTkpqTWZZapG+XwJXxYucsloIHqxkrnh3rYWpgXLOcsYuRk0NC wERi6pYHTBC2mMSFe+vZuhi5OIQEjjBKXJ+9hhHCWcQo8WLqXBaQKjYBF4kHDY/AOkQElCV+ L/4EZjMLKErsnnWWHcQWFtCR2Pp3B1AzB1CNrsT19V4QppPE3FPiIBUsAioSLX9+gXXyClhI PFs2F2rvFEaJfW+bwBKcAmoSp16+YQWxGYGO+35qDdQqcYlbT+ZDHS0gsWTPeWYIW1Ti5eN/ YPWiAnoSK683sUHEFSU+vtoHdg6zgKbE+l36EGOsJZoXfGSBuX5K90N2iHsEJU7OfMIygVFi FpJtsxC6ZyHpnoWkexaS7gWMrKsYRYtTi5Ny042M9VKLMpOLi/Pz9PJSSzYxAuPw4JbfqjsY L79xPMQowMGoxMNbcOVPiBBrYllxZe4hRmkOFiVxXjvjQyFCAumJJanZqakFqUXxRaU5qcWH GJk4OKUaGOWM/qiaCj+qPe/dtyP57LncH75TOYNbHd/ttnNPLLW3TuoytjCTC0q627Zxdot1 xAvOBc3+umdCjJpnnk3YOVlE5bLQpTen/KoCvz3YveG/xzT1iY6X7+/6NvFQk+6XQrnb03Kn ON2cFrBl54W7wn4Rn286qBj9FigPlT/rz/rgndTnuJUr/yuxFGckGmoxFxUnAgDmW2FbpAIA AA== Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] U1.2 in Use Case Document 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, 09 Mar 2015 10:48:10 -0000 SGkgU3RlZmZpLA0KDQoNCk9uIDIwMTUtMDMtMDkgMTE6MDYsICJTdGVmYW5pZSBHZXJkZXMiIDxn ZXJkZXNAdHppLmRlPiB3cm90ZToNCg0KPkhpIEfDtnJhbiwNCj4NCj5JIHRoaW5rIHlvdSBmb3Jn b3QgdG8gaW5jbHVkZSB0aGUgbWFpbGluZyBsaXN0Lg0KDQpXZWxsLCBubyBJIGRpZG4ndCwgSSBy ZXNwb25kZWQgdG8gYSBtYWlsIGRpcmVjdGx5IGZyb20geW91Lg0KDQo+DQo+T24gMDMvMDkvMjAx NSAxMDowOCBBTSwgR8O2cmFuIFNlbGFuZGVyIHdyb3RlOg0KPj4gSGkgU3RlZmZpLA0KPj4NCj4+ IExldOKAmXMgYmUgYnJpZWYsIHNpbmNlIHlvdSBhcmUgcHJvYmFibHkgYWxzbyB3b3JraW5nIG9u IG90aGVyIGRyYWZ0cy4NCj4+DQo+PiBUaGlzIGlzIGEgdXNlIGNhc2UgZG9jdW1lbnQuIFdlIHNo b3VsZCBqdXN0IGRlc2NyaWJlIHdoYXQgd2UgY29uc2lkZXINCj4+YXJlDQo+PiB0aGUgcmVsZXZh bnQgdG8gdW5kZXJzdGFuZCB0aGUgYWNjZXNzIGNvbnRyb2wgcHJvYmxlbXMgb2YgdGhlIHVzZSBj YXNlcy4NCj4+IFdoYXQgeW91IGRlc2NyaWJlIGFzIGFjY2Nlc3MgY29udHJvbCBwcm9ibGVtIChv ciBhdXRob3JpemF0aW9uIHByb2JsZW1zKQ0KPj4gb24gdGhlIGNsaWVudCBpcw0KPj4gbm90IHdo YXQgSSBjYWxsIGFuIGFjY2VzcyBjb250cm9sIHByb2JsZW0uIEhlbmNlIHdoZW4geW91IHJlZmVy IHRvDQo+PiBhdXRob3JpemF0aW9ucyBvZiBhIGNsaWVudCBJIGRvbuKAmXQgY29uc2lkZXIgdGhh dCB0byBiZSBpbiBzY29wZSBvZiBBQ0UuDQo+DQo+WWVzLCB3ZSBzaG91bGQgZGVzY3JpYmUgdGhl IHByb2JsZW1zIHRoYXQgd2UgaGF2ZSBpbiBjZXJ0YWluIHVzZSBjYXNlcy4NCj5Zb3VyIHByb3Bv c2FsIHRoYXQgd2UgZG8gYXV0aG9yaXphdGlvbiBzb2xlbHkgb24gdGhlIHNlcnZlciBzaWRlIGlz IG5vdA0KPmEgcHJvYmxlbS4gSXQgaXMgYSBzb2x1dGlvbi4NCg0KTXkgcHJvcG9zYWwgaXMgdG8g ZGVzY3JpYmUgdGhlIHByb2JsZW1zIHlvdSBzZWUgaW4gZWFjaCB1c2UgY2FzZXMgYW5kDQpkb27i gJl0IGhpZGUgYmVoaW5kIHRlcm1pbm9sb2d5Lg0KDQo+DQo+Pg0KPj4gRm9yIHRoZSBzYW1lIHJl YXNvbiwgSSBkb27igJl0IHByb3Bvc2UgYSBuZXcgZm9ybXVsYXRpb24sIGJlY2F1c2UgeW91IHdp bGwNCj4+IG5vdCBhcHByb3ZlIG9mIG9uZSB3aGljaCBkb2VzbuKAmXQgZXhwbGljaXRseSBtZW50 aW9uIHRoZSBjbGllbnQsIHJpZ2h0Pw0KPg0KPldyb25nLiBJIG9ubHkgd2FudCB0byBtYWtlIHN1 cmUgdGhhdCB0aGUgcGhyYXNpbmcgZG9lcyBub3QgaW5kaWNhdGUgdGhhdA0KPmF1dGhvcml6YXRp b24gb24gdGhlIHNlcnZlciBzaWRlIGlzIG1vcmUgaW1wb3J0YW50Lg0KPg0KPj4gT3INCj4+IHdv dWxkIHlvdSBhY2NlcHQgc29tZXRoaW5nIG1vcmUgZ2VuZXJhbCBzdWNoIGFzICJQcmluY2lwYWwg aXMgYW4gZW50aXR5DQo+PiBzZXR0aW5nIGFjY2VzcyBjb250cm9sIHBvbGljZXPigJ0gKEkgaGF2 ZW7igJl0IHBvbGlzaGVkIG9uIHRoaXMgZm9ybXVsYXRpb24NCj4+YXMNCj4+IGl0IG1heSBiZSBq dXN0IGEgd2FzdGUgb2YgdGltZSkNCj4NCj5Ib3cgYWJvdXQgIlByaW5jaXBhbDogVGhlIHN1Ympl Y3Qgd2hvIGlzIGluIGNoYXJnZSBvZiBncmFudGluZw0KPmF1dGhvcml6YXRpb25zIi4NCg0KSSB0 aGluayB0aGVyZSBtYXkgYmUgYSBwcm9ibGVtIGlmIHdlIHdvdWxkIGFncmVlIG9uIGEgdGVybSB0 aGF0IHdlIGJvdGgNCmtub3cgaXMgaW50ZXJwcmV0ZWQgZGlmZmVyZW50bHkuIEFuZCBJIGRvbuKA mXQgdGhpbmsgdGhlIHRlcm0gaXMgbmVjZXNzYXJ5Lg0KUGxlYXNlIGZpbmQgYXQgdGhlIGVuZCBv ZiB0aGlzIG1haWwgYSBwcm9wb3NlZCB1cGRhdGUgdG8gdGhlIHNlY3VyaXR5IGFuZA0KcHJpdmFj eSBjb25zaWRlcmF0aW9ucyAoc2VjdGlvbnMgMyAmIDQpIHdpdGhvdXQgdGhlIHRlcm1zIOKAnFBy aW5jaXBhbOKAnSwNCuKAnENsaWVudOKAnSBhbmQg4oCcUmVzb3VyY2UgU2VydmVy4oCdLg0KDQoN Cj4NCj4+DQo+PiBJIGRvbuKAmXQgZXhwZWN0IGFueW9uZSBvZiB1cyB0byBjaGFuZ2Ugb3Bpbmlv biBhYm91dCB0aGlzIHRvZGF5LCBkbyB5b3U/DQo+Pg0KPj4gV2hlbiBkbyB5b3Ugd2FudCBhbiB1 cGRhdGUgb2YgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zPw0KPg0KPlNpbmNlIHRoZSBjbGll bnQgc2lkZSAvIHNlcnZlciBzaWRlIGF1dGhvcml6YXRpb24gcHJvYmxlbSBpcyBub3QNCj5tZW50 aW9uZWQgaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGFzIGZhciBhcyBJIGNhbiBzZWUs IEkgZG9uJ3QNCj5zZWUgYSBuZWVkIHRvIHVwZGF0ZSB0aGlzIHNlY3Rpb24uIElmIHlvdSBzZWUg YSBwcm9ibGVtIHRoZXJlLCBwbGVhc2UNCj5wb2ludCBpdCBvdXQgdG8gbWUuDQo+DQo+Q29uY2Vy bmluZyB0aGUgcHJvYmxlbSBzdW1tYXJ5IHNlY3Rpb25zLCBkbyB3ZSBhZ3JlZSBvbiB0aGUgcHJv cG9zYWwgaW4NCj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvYWNlL2N1cnJl bnQvbXNnMDEwNDIuaHRtbDoNCj4NCj5VMS4xIEZydWl0IHZlbmRvcnMsIHRyYW5zbG9hZGluZyBw ZXJzb25uZWwgYW5kIGNvbnRhaW5lciBvd25lcnMgd2FudCB0bw0KPmRlZmluZSBhdXRob3JpemF0 aW9ucyBmb3IgdGhlaXIgcmVzb3VyY2VzIGFuZCBlbmRwb2ludHMuDQo+DQo+V2UgY2FuIGNoYW5n ZSB0aGlzIHRvOg0KPg0KPlUxLjEgRnJ1aXQgdmVuZG9ycywgdHJhbnNsb2FkaW5nIHBlcnNvbm5l bCBhbmQgY29udGFpbmVyIG93bmVycyB3YW50IHRvDQo+Z3JhbnQgZGlmZmVyZW50IGF1dGhvcml6 YXRpb25zIGZvciB0aGVpciByZXNvdXJjZXMgYW5kL29yIGVuZHBvaW50cyB0bw0KPmRpZmZlcmVu dCBwYXJ0aWVzLg0KPg0KPm9yIHRvOg0KPg0KPlUxLjEgRnJ1aXQgdmVuZG9ycywgdHJhbnNsb2Fk aW5nIHBlcnNvbm5lbCBhbmQgY29udGFpbmVyIG93bmVycyB3YW50IHRvDQo+Z3JhbnQgZGlmZmVy ZW50IGF1dGhvcml6YXRpb25zIHRvIGRpZmZlcmVudCBwYXJ0aWVzLg0KPg0KPlUxLjIgVGhlIGZy dWl0IHZlbmRvciByZXF1aXJlcyB0aGUgaW50ZWdyaXR5IG9mIHRoZSBzZW5zb3IgZGF0YSB0aGF0 DQo+cGVydGFpbnMgdGhlIHN0YXRlIG9mIHRoZSBnb29kcyBmb3IgY2xpbWF0ZSBjb250cm9sIGFu ZCB0byBlbnN1cmUgdGhlDQo+cXVhbGl0eSBvZiB0aGUgbW9uaXRvcmVkIHJlY29yZGluZ3MuDQo+ DQo+VTEuMyBUaGUgY29udGFpbmVyIG93bmVyIHJlcXVpcmVzIHRoZSBpbnRlZ3JpdHkgb2YgdGhl IHNlbnNvciBkYXRhIHRoYXQNCj5pcyB1c2VkIGZvciBjbGltYXRlIGNvbnRyb2wuDQo+DQo+VTEu NCBUaGUgZnJ1aXQgdmVuZG9yIHJlcXVpcmVzIHRoZSBjb25maWRlbnRpYWxpdHkgb2YgdGhlIHNl bnNvciBkYXRhDQo+dGhhdCBwZXJ0YWlucyB0aGUgc3RhdGUgb2YgdGhlIGdvb2RzLg0KPg0KPlUx LjUgVGhlIGZydWl0IHZlbmRvciBtYXkgaGF2ZSBzZXZlcmFsIHR5cGVzIG9mIGRhdGEgdGhhdCBt YXkgYmUNCj5jb250cm9sbGVkIGJ5IHRoZSBzYW1lIGVuZHBvaW50LCBlLmcuLCBzZW5zb3IgZGF0 YSBhbmQgdGhlIGRhdGEgdXNlZCBmb3INCj5sb2dpc3RpY3MuDQo+DQo+VTEuNiBUaGUgZnJ1aXQg dmVuZG9yIHJlcXVpcmVzIHRoZSBjb25maWRlbnRpYWxpdHkgb2YgdGhlIGRhdGEgdGhhdCBpcw0K PnVzZWQgdG8gbG9jYXRlIHRoZSBnb29kcy4NCj4NCj5VMS43IFRoZSBmcnVpdCB2ZW5kb3IgcmVx dWlyZXMgdGhlIGludGVncml0eSBvZiB0aGUgZGF0YSB0aGF0IGlzIHVzZWQgdG8NCj5sb2NhdGUg dGhlIGdvb2RzLg0KPg0KPlUxLjggVGhlIHRyYW5zbG9hZGluZyBwZXJzb25uZWwgcmVxdWlyZXMg dGhlIGludGVncml0eSBvZiB0aGUgZGF0YSB0aGF0DQo+aXMgdXNlZCB0byBsb2NhdGUgdGhlIGdv b2RzLg0KPg0KPlUxLjkgVGhlIGNvbnRhaW5lciBvd25lciBhbmQgdGhlIGZydWl0IHZlbmRvciBt YXkgbm90IGJlIHByZXNlbnQgYXQgdGhlDQo+dGltZSBvZiBhY2Nlc3MgYW5kIGNhbm5vdCBtYW51 YWxseSBpbnRlcnZlbmUgaW4gdGhlIGF1dGhvcml6YXRpb24gcHJvY2Vzcy4NCj4NCj5VMS4xMCBU aGUgZnJ1aXQgdmVuZG9yLCBjb250YWluZXIgb3duZXIgYW5kIHRyYW5zbG9hZGluZyBjb21wYW55 IHdhbnQgdG8NCj5ncmFudCB0ZW1wb3JhcnkgYWNjZXNzIHBlcm1pc3Npb25zIHRvIGEgcGFydHku DQo+DQo+VTEuMTEgTWVzc2FnZXMgYmV0d2VlbiBjbGllbnQgYW5kIHJlc291cmNlIHNlcnZlciBt aWdodCBuZWVkIHRvIGJlDQo+Zm9yd2FyZGVkIG92ZXIgbXVsdGlwbGUgaG9wcy4NCj4NCj5VMS4x MiBUaGUgY29uc3RyYWluZWQgZGV2aWNlcyBtaWdodCBub3QgYWx3YXlzIGJlIGFibGUgdG8gcmVh Y2ggdGhlDQo+SW50ZXJuZXQuDQoNClRoaXMgaXMgZmluZSBieSBtZS4NCg0KQmVzdCBSZWdhcmRz LA0KR8O2cmFuDQoNCj4NCj5CZXN0IHJlZ2FyZHMsDQo+U3RlZmZpDQoNCg0KQmVsb3cgYXJlIHNl Y3Rpb25zIDMgJiA0IHdpdGggZHVwbGljYXRlIHBhcmFncmFwaHMgbGFiZWxsZWQgdGhlbSDigJxP TETigJ0gYW5kDQpORVfigJ0gZm9yIGNvbXBhcmlzb24uDQoNCg0KDQozLiAgU2VjdXJpdHkgQ29u c2lkZXJhdGlvbnMNCg0KICAgQXMgdGhlIHVzZSBjYXNlcyBsaXN0ZWQgaW4gdGhpcyBkb2N1bWVu dCBkZW1vbnN0cmF0ZSwgY29uc3RyYWluZWQNCiAgIGRldmljZXMgYXJlIHVzZWQgaW4gdmFyaW91 cyBhcHBsaWNhdGlvbiBhcmVhcy4gIFRoZSBhcHBlYWwgb2YgdGhlc2UNCiAgIGRldmljZXMgaXMg dGhhdCB0aGV5IGFyZSBzbWFsbCBhbmQgaW5leHBlbnNpdmUuICBUaGF0IG1ha2VzIGl0IGVhc3kN CiAgIHRvIGludGVncmF0ZSB0aGVtIGludG8gbWFueSBhc3BlY3RzIG9mIGV2ZXJ5ZGF5IGxpZmUu ICBUaGVyZWZvcmUsIHRoZQ0KICAgZGV2aWNlcyB3aWxsIGJlIGVudHJ1c3RlZCB3aXRoIHZhc3Qg YW1vdW50cyBvZiB2YWx1YWJsZSBkYXRhIG9yIGV2ZW4NCiAgIGNvbnRyb2wgZnVuY3Rpb25zLCB0 aGF0IG5lZWQgdG8gYmUgcHJvdGVjdGVkIGZyb20gdW5hdXRob3JpemVkDQogICBhY2Nlc3MuICBN b3Jlb3ZlciwgdGhlIGFnZ3JlZ2F0aW9uIG9mIGRhdGEgbXVzdCBiZSBjb25zaWRlcmVkOg0KICAg YXR0YWNrZXJzIG1pZ2h0IG5vdCBvbmx5IGNvbGxlY3QgZGF0YSBmcm9tIGEgc2luZ2xlIGRldmlj ZSBidXQgZnJvbQ0KICAgbWFueSBkZXZpY2VzLCB0aHVzIGluY3JlYXNpbmcgdGhlIHBvdGVudGlh bCBkYW1hZ2UuDQoNCiAgIE5vdCBvbmx5IHRoZSBkYXRhIG9uIHRoZSBjb25zdHJhaW5lZCBkZXZp Y2VzIHRoZW1zZWx2ZXMgaXMNCiAgIHRocmVhdGVuZWQsIHRoZSBkZXZpY2VzIG1pZ2h0IGFsc28g YmUgYWJ1c2VkIGFzIGFuIGludHJ1c2lvbiBwb2ludCB0bw0KICAgaW5maWx0cmF0ZSBhIG5ldHdv cmsuICBPbmNlIGFuIGF0dGFja2VyIGdhaW5lZCBjb250cm9sIG92ZXIgdGhlDQogICBkZXZpY2Us IGl0IGNhbiBiZSB1c2VkIHRvIGF0dGFjayBvdGhlciBkZXZpY2VzIGFzIHdlbGwuICBEdWUgdG8g dGhlaXINCiAgIGxpbWl0ZWQgY2FwYWJpbGl0aWVzLCBjb25zdHJhaW5lZCBkZXZpY2VzIGFwcGVh ciBhcyB0aGUgd2Vha2VzdCBsaW5rDQogICBpbiB0aGUgbmV0d29yayBhbmQgaGVuY2UgcG9zZSBh biBhdHRyYWN0aXZlIHRhcmdldCBmb3IgYXR0YWNrZXJzLg0KDQogICBUaGlzIHNlY3Rpb24gc3Vt bWFyaXplcyB0aGUgc2VjdXJpdHkgcHJvYmxlbXMgaGlnaGxpZ2h0ZWQgYnkgdGhlIHVzZQ0KICAg Y2FzZXMgYWJvdmUgYW5kIHByb3ZpZGVzIGd1aWRlbGluZXMgZm9yIHRoZSBkZXNpZ24gb2YgcHJv dG9jb2xzIGZvcg0KICAgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gaW4gY29uc3Ry YWluZWQgUkVTVGZ1bCBlbnZpcm9ubWVudHMuDQoNCjMuMS4gIEF0dGFja3MNCg0KT0xEDQogICBU aGlzIGRvY3VtZW50IGxpc3RzIHNlY3VyaXR5IHByb2JsZW1zIHRoYXQgcHJpbmNpcGFscyBvZiBj b25zdHJhaW5lZA0KICAgZGV2aWNlcyB3YW50IHRvIHNvbHZlLiAgRnVydGhlciBhbmFseXNpcyBv ZiBhdHRhY2sgc2NlbmFyaW9zIGlzIG5vdA0KICAgaW4gc2NvcGUgb2YgdGhlIGRvY3VtZW50LiAg SG93ZXZlciwgdGhlcmUgYXJlIGF0dGFja3MgdGhhdCBtdXN0IGJlDQogICBjb25zaWRlcmVkIGJ5 IHNvbHV0aW9uIGRldmVsb3BlcnMuDQpORVcNCiAgIFRoaXMgZG9jdW1lbnQgbGlzdHMgc2VjdXJp dHkgcHJvYmxlbXMgb2YgY29uc3RyYWluZWQtbm9kZSBuZXR3b3Jrcy4NCiAgIEZ1cnRoZXIgYW5h bHlzaXMgb2YgYXR0YWNrIHNjZW5hcmlvcyBpcyBub3QNCiAgIGluIHNjb3BlIG9mIHRoZSBkb2N1 bWVudC4gIEhvd2V2ZXIsIHRoZXJlIGFyZSBhdHRhY2tzIHRoYXQgbXVzdCBiZQ0KICAgY29uc2lk ZXJlZCBieSBzb2x1dGlvbiBkZXZlbG9wZXJzLg0KDQogICBCZWNhdXNlIG9mIHRoZSBleHBlY3Rl ZCBsYXJnZSBudW1iZXIgb2YgZGV2aWNlcyBhbmQgdGhlaXIgdWJpcXVpdHksDQogICBjb25zdHJh aW5lZCBkZXZpY2VzIGluY3JlYXNlIHRoZSBkYW5nZXIgZnJvbSBQZXJ2YXNpdmUgTW9uaXRvcmlu Zw0KICAgW1JGQzcyNThdIGF0dGFja3MuDQoNCg0KICAgQXMgc29tZSBvZiB0aGUgdXNlIGNhc2Vz IGluZGljYXRlLCBjb25zdHJhaW5lZCBkZXZpY2VzIG1heSBiZQ0KICAgaW5zdGFsbGVkIGluIGhv c3RpbGUgZW52aXJvbm1lbnRzIHdoZXJlIHRoZXkgYXJlIHBoeXNpY2FsbHkNCiAgIGFjY2Vzc2li bGUgKHNlZSBTZWN0aW9uIDIuNSkuICBQcm90ZWN0aW9uIGZyb20gcGh5c2ljYWwgYXR0YWNrcyBp cw0KICAgbm90IGluIHRoZSBzY29wZSBvZiBBQ0UsIGJ1dCBzaG91bGQgYmUga2VwdCBpbiBtaW5k IGJ5IGRldmVsb3BlcnMgb2YNCiAgIGF1dGhvcml6YXRpb24gc29sdXRpb25zLg0KDQogICBEZW5p YWwgb2Ygc2VydmljZSAoRG9TKSBhdHRhY2tzIHRocmVhdGVuIHRoZSBhdmFpbGFiaWxpdHkgb2Yg c2VydmljZXMNCiAgIGEgZGV2aWNlIHByb3ZpZGVzLiAgRS5nLiwgYW4gYXR0YWNrZXIgY2FuIGlu ZHVjZSBhIGRldmljZSB0byBwZXJmb3JtDQogICBzdGVwcyBvZiBhIGhlYXZ5IHdlaWdodCBzZWN1 cml0eSBwcm90b2NvbCAoZS5nLiAgRGF0YWdyYW0gVHJhbnNwb3J0DQogICBMYXllciBTZWN1cml0 eSAoRFRMUykgW1JGQzYzNDddKSBiZWZvcmUgYXV0aGVudGljYXRpb24gYW5kDQogICBhdXRob3Jp emF0aW9uIGNhbiBiZSB2ZXJpZmllZCwgdGh1cyBleGhhdXN0aW5nIHRoZSBkZXZpY2UncyBzeXN0 ZW0NCiAgIHJlc291cmNlcy4gIFRoaXMgbGVhZHMgdG8gYSB0ZW1wb3Jhcnkgb3IgLSBlLmcuIGlm IHRoZSBiYXR0ZXJpZXMgYXJlDQogICBkcmFpbmVkIC0gcGVybWFuZW50IGZhaWx1cmUgb2YgdGhl IHNlcnZpY2UuICBGb3Igc29tZSBzZXJ2aWNlcyBvZg0KICAgY29uc3RyYWluZWQgZGV2aWNlcywg YXZhaWxhYmlsaXR5IGlzIGVzcGVjaWFsbHkgaW1wb3J0YW50IChzZWUNCiAgIFNlY3Rpb24gMi4z KS4gIEJlY2F1c2Ugb2YgdGhlaXIgbGltaXRhdGlvbnMsIGNvbnN0cmFpbmVkIGRldmljZXMgYXJl DQogICBlc3BlY2lhbGx5IHZ1bG5lcmFibGUgdG8gZGVuaWFsIG9mIHNlcnZpY2UgYXR0YWNrcy4g IFNvbHV0aW9uDQogICBkZXNpZ25lcnMgbXVzdCBiZSBwYXJ0aWN1bGFybHkgY2FyZWZ1bCB0byBj b25zaWRlciB0aGVzZSBsaW1pdGF0aW9ucw0KICAgaW4gZXZlcnkgcGFydCBvZiB0aGUgcHJvdG9j b2wuICBUaGlzIGluY2x1ZGVzOg0KDQogICBvICBCYXR0ZXJ5IHVzYWdlDQoNCiAgIG8gIE51bWJl ciBvZiBtZXNzYWdlIGV4Y2hhbmdlcyByZXF1aXJlZCBieSBzZWN1cml0eSBtZWFzdXJlcw0KDQog ICBvICBTaXplIG9mIGRhdGEgdGhhdCBpcyB0cmFuc21pdHRlZCAoZS5nLiBhdXRoZW50aWNhdGlv biBhbmQgYWNjZXNzDQogICAgICBjb250cm9sIGRhdGEpDQoNCiAgIG8gIFNpemUgb2YgY29kZSBy ZXF1aXJlZCB0byBydW4gdGhlIHByb3RvY29sDQoNCiAgIG8gIFNpemUgb2YgUkFNIG1lbW9yeSBh bmQgc3RhY2sgcmVxdWlyZWQgdG8gcnVuIHRoZSBwcm90b2NvbA0KDQogICBBbm90aGVyIGNhdGVn b3J5IG9mIGF0dGFja3MgdGhhdCBuZWVkcyB0byBiZSBjb25zaWRlcmVkIGJ5IHNvbHV0aW9uDQog ICBkZXZlbG9wZXJzIGlzIHNlc3Npb24gaW50ZXJjZXB0aW9uIGFuZCBoaWphY2tpbmcuDQoNCjMu Mi4gIENvbmZpZ3VyYXRpb24gb2YgQWNjZXNzIFBlcm1pc3Npb25zDQoNCk9MRA0KICAgbyAgVGhl IGFjY2VzcyBjb250cm9sIHBvbGljaWVzIG9mIHRoZSBwcmluY2lwYWxzIG5lZWQgdG8gYmUgZW5m b3JjZWQNCiAgICAgIChhbGwgdXNlIGNhc2VzKTogVGhlIGluZm9ybWF0aW9uIHRoYXQgaXMgbmVl ZGVkIHRvIGltcGxlbWVudCB0aGUNCiAgICAgIGFjY2VzcyBjb250cm9sIHBvbGljaWVzIG9mIHRo ZSBQcmluY2lwYWxzIG5lZWQgdG8gYmUgcHJvdmlkZWQgdG8NCiAgICAgIHRoZSBkZXZpY2UgdGhh dCBlbmZvcmNlcyB0aGUgYXV0aG9yaXphdGlvbiBhbmQgYXBwbGllZCB0byBldmVyeQ0KICAgICAg aW5jb21pbmcgcmVxdWVzdC4NCk5FVw0KICAgbyAgVGhlIGFjY2VzcyBjb250cm9sIHBvbGljaWVz IG5lZWQgdG8gYmUgZW5mb3JjZWQNCiAgICAgIChhbGwgdXNlIGNhc2VzKTogVGhlIGluZm9ybWF0 aW9uIHRoYXQgaXMgbmVlZGVkIHRvIGltcGxlbWVudCB0aGUNCiAgICAgIGFjY2VzcyBjb250cm9s IHBvbGljaWVzIG5lZWQgdG8gYmUgcHJvdmlkZWQgdG8NCiAgICAgIHRoZSBkZXZpY2UgdGhhdCBl bmZvcmNlcyB0aGUgYXV0aG9yaXphdGlvbiBhbmQgYXBwbGllZCB0byBldmVyeQ0KICAgICAgaW5j b21pbmcgcmVxdWVzdC4NCg0KDQogICBvICBBIHNpbmdsZSByZXNvdXJjZSBtaWdodCBoYXZlIGRp ZmZlcmVudCBhY2Nlc3MgcmlnaHRzIGZvciBkaWZmZXJlbnQNCiAgICAgIHJlcXVlc3RpbmcgZW50 aXRpZXMgKGFsbCB1c2UgY2FzZXMpLg0KDQogICAgICBSYXRpb25hbGU6IEluIHNvbWUgY2FzZXMg ZGlmZmVyZW50IHR5cGVzIG9mIHVzZXJzIG5lZWQgZGlmZmVyZW50DQogICAgICBhY2Nlc3Mgcmln aHRzLCBhcyBvcHBvc2VkIHRvIGEgYmluYXJ5IGFwcHJvYWNoIHdoZXJlIHRoZSBzYW1lDQogICAg ICBhY2Nlc3MgcGVybWlzc2lvbnMgYXJlIGdyYW50ZWQgdG8gYWxsIGF1dGhlbnRpY2F0ZWQgdXNl cnMuDQoNCg0KICAgbyAgQSBkZXZpY2UgbWlnaHQgaG9zdCBzZXZlcmFsIHJlc291cmNlcyB3aGVy ZSBlYWNoIHJlc291cmNlIGhhcyBpdHMNCiAgICAgIG93biBhY2Nlc3MgY29udHJvbCBwb2xpY3kg KGFsbCB1c2UgY2FzZXMpLg0KDQogICBvICBUaGUgZGV2aWNlIHRoYXQgbWFrZXMgdGhlIHBvbGlj eSBkZWNpc2lvbnMgc2hvdWxkIGJlIGFibGUgdG8NCiAgICAgIGV2YWx1YXRlIGNvbnRleHQtYmFz ZWQgcGVybWlzc2lvbnMgc3VjaCBhcyBsb2NhdGlvbiBvciB0aW1lIG9mDQogICAgICBhY2Nlc3Mg KHNlZSBlLmcuICBTZWN0aW9uIDIuMiwgU2VjdGlvbiAyLjMsIFNlY3Rpb24gMi40KS4gIEFjY2Vz cw0KICAgICAgbWF5IGRlcGVuZCBvbiBsb2NhbCBjb25kaXRpb25zLCBlLmcuIGFjY2VzcyB0byBo ZWFsdGggZGF0YSBpbiBhbg0KICAgICAgZW1lcmdlbmN5LiAgVGhlIGRldmljZSB0aGF0IG1ha2Vz IHRoZSBwb2xpY3kgZGVjaXNpb25zIHNob3VsZCBiZQ0KICAgICAgYWJsZSB0byB0YWtlIHN1Y2gg Y29uZGl0aW9ucyBpbnRvIGFjY291bnQuDQoNCjMuMy4gIERlc2lnbiBDb25zaWRlcmF0aW9ucyBm b3IgQXV0aG9yaXphdGlvbiBTb2x1dGlvbnMNCg0KT0xEDQogICBvICBEZXZpY2VzIG5lZWQgdG8g YmUgZW5hYmxlZCB0byBlbmZvcmNlIHRoZSBwcmluY2lwYWwncw0KICAgICAgYXV0aG9yaXphdGlv biBwb2xpY2llcyB3aXRob3V0IHRoZSBwcmluY2lwYWwncyBpbnRlcnZlbnRpb24gYXQgdGhlDQog ICAgICB0aW1lIG9mIHRoZSBhY2Nlc3MgcmVxdWVzdCAoc2VlIGUuZy4gIFNlY3Rpb24gMi4xLCBT ZWN0aW9uIDIuMiwNCiAgICAgIFNlY3Rpb24gMi40LCBTZWN0aW9uIDIuNSkuDQpORVcNCiAgIG8g IERldmljZXMgbmVlZCB0byBiZSBlbmFibGVkIHRvIGVuZm9yY2UNCiAgICAgIGF1dGhvcml6YXRp b24gcG9saWNpZXMgd2l0aG91dCBodW1hbiBpbnRlcnZlbnRpb24gYXQgdGhlDQogICAgICB0aW1l IG9mIHRoZSBhY2Nlc3MgcmVxdWVzdCAoc2VlIGUuZy4gIFNlY3Rpb24gMi4xLCBTZWN0aW9uIDIu MiwNCiAgICAgIFNlY3Rpb24gMi40LCBTZWN0aW9uIDIuNSkuDQoNCiAgIG8gIEF1dGhvcml6YXRp b24gc29sdXRpb25zIG5lZWQgdG8gY29uc2lkZXIgdGhhdCBjb25zdHJhaW5lZCBkZXZpY2VzDQog ICAgICBtaWdodCBub3QgaGF2ZSBpbnRlcm5ldCBhY2Nlc3MgYXQgdGhlIHRpbWUgb2YgdGhlIGFj Y2VzcyByZXF1ZXN0DQogICAgICAoc2VlIGUuZy4gIFNlY3Rpb24gMi4xLCBTZWN0aW9uIDIuMywg U2VjdGlvbiAyLjUsIFNlY3Rpb24gMi42KS4NCg0KICAgbyAgSXQgc2hvdWxkIGJlIHBvc3NpYmxl IHRvIHVwZGF0ZSBhY2Nlc3MgY29udHJvbCBwb2xpY2llcyB3aXRob3V0DQogICAgICBtYW51YWxs eSByZS1wcm92aXNpb25pbmcgaW5kaXZpZHVhbCBkZXZpY2VzIChzZWUgZS5nLg0KICAgICAgU2Vj dGlvbiAyLjIsIFNlY3Rpb24gMi4zLCBTZWN0aW9uIDIuNSwgU2VjdGlvbiAyLjYpLg0KDQogICAg ICBSYXRpb25hbGU6IFBlZXJzIGNhbiBjaGFuZ2UgcmFwaWRseSB3aGljaCBtYWtlcyBtYW51YWwg cmUtDQogICAgICBwcm92aXNpb25pbmcgdW5yZWFzb25hYmx5IGV4cGVuc2l2ZS4NCg0KT0xEDQog ICBvICBQcmluY2lwYWxzIG1pZ2h0IGRlZmluZSBhdXRob3JpemF0aW9uIHBvbGljaWVzIGZvciBh IGxhcmdlIG51bWJlcg0KICAgICAgb2YgZGV2aWNlcyB0aGF0IG1pZ2h0IG9ubHkgaGF2ZSBpbnRl cm1pdHRlbnQgY29ubmVjdGl2aXR5Lg0KICAgICAgRGlzdHJpYnV0aW5nIHBvbGljeSB1cGRhdGVz IHRvIGV2ZXJ5IGRldmljZSBmb3IgZXZlcnkgdXBkYXRlIG1pZ2h0DQogICAgICBub3QgYmUgYSBm ZWFzaWJsZSBzb2x1dGlvbiAoc2VlIGUuZy4gIFNlY3Rpb24gMi41KS4NCk5FVw0KICAgbyAgQXV0 aG9yaXphdGlvbiBwb2xpY2llcyBtYXkgYmUgZGVmaW5lZCB0byBhcHBseSB0byBhIGxhcmdlIG51 bWJlcg0KICAgICAgb2YgZGV2aWNlcyB0aGF0IG1pZ2h0IG9ubHkgaGF2ZSBpbnRlcm1pdHRlbnQg Y29ubmVjdGl2aXR5Lg0KICAgICAgRGlzdHJpYnV0aW5nIHBvbGljeSB1cGRhdGVzIHRvIGV2ZXJ5 IGRldmljZSBmb3IgZXZlcnkgdXBkYXRlIG1pZ2h0DQogICAgICBub3QgYmUgYSBmZWFzaWJsZSBz b2x1dGlvbiAoc2VlIGUuZy4gIFNlY3Rpb24gMi41KS4NCg0KICAgbyAgSXQgbXVzdCBiZSBwb3Nz aWJsZSB0byBkeW5hbWljYWxseSByZXZva2UgYXV0aG9yaXphdGlvbnMgKHNlZSBlLmcuDQogICAg ICBTZWN0aW9uIDIuNCkuDQoNCiAgIG8gIFRoZSBhdXRoZW50aWNhdGlvbiBhbmQgYWNjZXNzIGNv bnRyb2wgcHJvdG9jb2wgY2FuIHB1dCB1bmR1ZQ0KICAgICAgYnVyZGVuIG9uIHRoZSBjb25zdHJh aW5lZCBzeXN0ZW0gcmVzb3VyY2VzIG9mIGEgZGV2aWNlDQogICAgICBwYXJ0aWNpcGF0aW5nIGlu IHRoZSBwcm90b2NvbC4gIEFuIGF1dGhvcml6YXRpb24gc29sdXRpb25zIG11c3QNCiAgICAgIHRh a2UgdGhlIGxpbWl0YXRpb25zIG9mIHRoZSBjb25zdHJhaW5lZCBkZXZpY2VzIGludG8gYWNjb3Vu dCAoYWxsDQogICAgICB1c2UgY2FzZXMsIHNlZSBhbHNvIFNlY3Rpb24gMy4xKS4NCg0KICAgbyAg U2VjdXJlIGRlZmF1bHQgc2V0dGluZ3MgYXJlIG5lZWRlZCBmb3IgdGhlIGluaXRpYWwgc3RhdGUg b2YgdGhlDQogICAgICBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBwcm90b2NvbHMg KGFsbCB1c2UgY2FzZXMpLg0KDQogICAgICBSYXRpb25hbGU6IE1hbnkgYXR0YWNrcyBleHBsb2l0 IGluc2VjdXJlIGRlZmF1bHQgc2V0dGluZ3MsIGFuZA0KICAgICAgZXhwZXJpZW5jZSBzaG93cyB0 aGF0IGRlZmF1bHQgc2V0dGluZ3MgYXJlIGZyZXF1ZW50bHkgbGVmdA0KICAgICAgdW5jaGFuZ2Vk IGJ5IHRoZSBlbmQgdXNlcnMuDQoNCiAgIG8gIEFjY2VzcyB0byByZXNvdXJjZXMgb24gb3RoZXIg ZGV2aWNlcyBzaG91bGQgb25seSBiZSBwZXJtaXR0ZWQgaWYgYQ0KICAgICAgcnVsZSBleGlzdHMg dGhhdCBleHBsaWNpdGx5IGFsbG93cyB0aGlzIGFjY2VzcyAoZGVmYXVsdCBkZW55KSAoc2VlDQog ICAgICBlLmcuICBTZWN0aW9uIDIuNCkuDQoNCiAgIG8gIFVzYWJpbGl0eSBpcyBpbXBvcnRhbnQg Zm9yIGFsbCB1c2UgY2FzZXMuICBUaGUgY29uZmlndXJhdGlvbiBvZg0KICAgICAgYXV0aG9yaXph dGlvbiBwb2xpY2llcyBhcyB3ZWxsIGFzIHRoZSBnYWluaW5nIGFjY2VzcyB0byBkZXZpY2VzDQog ICAgICBtdXN0IGJlIHNpbXBsZSBmb3IgdGhlIHVzZXJzIG9mIHRoZSBkZXZpY2VzLiAgU3BlY2lh bCBjYXJlIG5lZWRzDQogICAgICB0byBiZSB0YWtlbiBmb3IgaG9tZSBzY2VuYXJpb3Mgd2hlcmUg YWNjZXNzIGNvbnRyb2wgcG9saWNpZXMgaGF2ZQ0KICAgICAgdG8gYmUgY29uZmlndXJlZCBieSB1 c2VycyB0aGF0IGFyZSB0eXBpY2FsbHkgbm90IHRyYWluZWQgaW4NCiAgICAgIHNlY3VyaXR5IChz ZWUgU2VjdGlvbiAyLjIsIFNlY3Rpb24gMi4zLCBTZWN0aW9uIDIuNikuDQoNCjMuNC4gIFByb3hp ZXMNCg0KT0xEDQogICBJbiBzb21lIGNhc2VzLCB0aGUgdHJhZmZpYyBiZXR3ZWVuIENsaWVudCBh bmQgUmVzb3VyY2UgU2VydmVyIG1pZ2h0DQogICBnbyB0aHJvdWdoIGludGVybWVkaWFyeSBub2Rl cyAoZS5nLiBwcm94aWVzLCBnYXRld2F5cykuICBUaGlzIG1pZ2h0DQogICBhZmZlY3QgdGhlIGZ1 bmN0aW9uIG9yIHRoZSBzZWN1cml0eSBtb2RlbCBvZiBhdXRoZW50aWNhdGlvbiBhbmQNCiAgIGFj Y2VzcyBjb250cm9sIHByb3RvY29scyBlLmcuIGVuZC10by1lbmQgc2VjdXJpdHkgYmV0d2VlbiBD bGllbnQgYW5kDQogICBSZXNvdXJjZSBTZXJ2ZXIgd2l0aCBEVExTIG1pZ2h0IG5vdCBiZSBwb3Nz aWJsZSAoc2VlIFNlY3Rpb24gMi41KS4NCk5FVw0KICAgSW4gc29tZSBjYXNlcywgdGhlIHRyYWZm aWMgYmV0d2VlbiBlbmRwb2ludHMgbWlnaHQNCiAgIGdvIHRocm91Z2ggaW50ZXJtZWRpYXJ5IG5v ZGVzIChlLmcuIHByb3hpZXMsIGdhdGV3YXlzKS4gIFRoaXMgbWlnaHQNCiAgIGFmZmVjdCB0aGUg ZnVuY3Rpb24gb3IgdGhlIHNlY3VyaXR5IG1vZGVsIG9mIGF1dGhlbnRpY2F0aW9uIGFuZA0KICAg YWNjZXNzIGNvbnRyb2wgcHJvdG9jb2xzIGUuZy4gZW5kLXRvLWVuZCBzZWN1cml0eSBiZXR3ZWVu IGVuZHBvaW50cw0KICAgd2l0aCBEVExTIG1pZ2h0IG5vdCBiZSBwb3NzaWJsZSAoc2VlIFNlY3Rp b24gMi41KS4NCg0KNC4gIFByaXZhY3kgQ29uc2lkZXJhdGlvbnMNCg0KICAgTWFueSBvZiB0aGUg ZGV2aWNlcyB0aGF0IGFyZSBpbiBmb2N1cyBvZiB0aGlzIGRvY3VtZW50IHJlZ2lzdGVyIGRhdGEN CiAgIGZyb20gdGhlIHBoeXNpY2FsIHdvcmxkIChzZW5zb3JzKSBvciBhZmZlY3QgcHJvY2Vzc2Vz IGluIHRoZSBwaHlzaWNhbA0KICAgd29ybGQgKGFjdHVhdG9ycyksIHdoaWNoIG1heSBpbnZvbHZl IGRhdGEgb3IgcHJvY2Vzc2VzIGJlbG9uZ2luZyB0bw0KICAgaW5kaXZpZHVhbHMuICBUbyBtYWtl IG1hdHRlcnMgd29yc2UgdGhlIHNlbnNvciBkYXRhIG1heSBiZSByZWNvcmRlZA0KICAgY29udGlu dW91c2x5IHRodXMgYWxsb3dpbmcgdG8gZ2F0aGVyIHNpZ25pZmljYW50IGluZm9ybWF0aW9uIGFi b3V0IGFuDQogICBpbmRpdmlkdWFsIHN1YmplY3QgdGhyb3VnaCB0aGUgc2Vuc29yIHJlYWRpbmdz LiAgVGhlcmVmb3JlIHByaXZhY3kNCiAgIHByb3RlY3Rpb24gaXMgZXNwZWNpYWxseSBpbXBvcnRh bnQsIGFuZCBBdXRoZW50aWNhdGlvbiBhbmQgQWNjZXNzDQogICBjb250cm9sIGFyZSBpbXBvcnRh bnQgdG9vbHMgZm9yIHRoaXMsIHNpbmNlIHRoZXkgbWFrZSBpdCBwb3NzaWJsZSB0bw0KICAgY29u dHJvbCB3aG8gZ2V0cyBhY2Nlc3MgdG8gcHJpdmF0ZSBkYXRhLg0KT0xEDQogICBQcml2YWN5IHBy b3RlY3Rpb24gY2FuIGFsc28gYmUgd2VpZ2h0ZWQgaW4gd2hlbiBldmFsdWF0aW5nIHRoZSBuZWVk DQogICBmb3IgZW5kLXRvLWVuZCBjb25maWRlbnRpYWxpdHksIHNpbmNlIG90aGVyd2lzZSBpbnRl cm1lZGlhcnkgbm9kZXMNCiAgIHdpbGwgbGVhcm4gdGhlIGNvbnRlbnQgb2YgcG90ZW50aWFsbHkg c2Vuc2l0aXZlIG1lc3NhZ2VzIHNlbnQgYmV0d2Vlbg0KICAgYSBjbGllbnQgYW5kIGEgcmVzb3Vy Y2Ugc2VydmVyIGFuZCB0aGVyZWJ5IGVuZGFuZ2VyIHRoZSBwcml2YWN5IG9mDQogICB0aGUgaW5k aXZpZHVhbCB0aGF0IG1heSBiZSBzdWJqZWN0IG9mIHRoaXMgZGF0YS4NCk5FVw0KICAgUHJpdmFj eSBwcm90ZWN0aW9uIGNhbiBhbHNvIGJlIHdlaWdodGVkIGluIHdoZW4gZXZhbHVhdGluZyB0aGUg bmVlZA0KICAgZm9yIGVuZC10by1lbmQgY29uZmlkZW50aWFsaXR5LCBzaW5jZSBvdGhlcndpc2Ug aW50ZXJtZWRpYXJ5IG5vZGVzDQogICB3aWxsIGxlYXJuIHRoZSBjb250ZW50IG9mIHBvdGVudGlh bGx5IHNlbnNpdGl2ZSBtZXNzYWdlcyBzZW50IGJldHdlZW4NCiAgIGVuZHBvaW50cyBhbmQgdGhl cmVieSBlbmRhbmdlciB0aGUgcHJpdmFjeSBvZg0KICAgdGhlIGluZGl2aWR1YWwgdGhhdCBtYXkg YmUgc3ViamVjdCBvZiB0aGlzIGRhdGEuDQoNCg0KT0xEDQogICBJbiBzb21lIGNhc2VzLCBldmVu IHRoZSBwb3NzZXNzaW9uIG9mIGEgY2VydGFpbiB0eXBlIG9mIGRldmljZSBjYW4gYmUNCiAgIGNv bmZpZGVudGlhbCwgZS5nLiBwcmluY2lwYWxzIG1pZ2h0IG5vdCB3YW50IHRvIG90aGVycyB0byBr bm93IHRoYXQNCiAgIHRoZXkgYXJlIHdlYXJpbmcgYSBjZXJ0YWluIG1lZGljYWwgZGV2aWNlIChz ZWUgU2VjdGlvbiAyLjMpLg0KTkVXDQogICBJbiBzb21lIGNhc2VzLCBldmVuIHRoZSBwb3NzZXNz aW9uIG9mIGEgY2VydGFpbiB0eXBlIG9mIGRldmljZSBjYW4gYmUNCiAgIGNvbmZpZGVudGlhbCwg ZS5nLiBpbmRpdmlkdWFscyBtaWdodCBub3Qgd2FudCB0byBvdGhlcnMgdG8ga25vdyB0aGF0DQog ICB0aGV5IGFyZSB3ZWFyaW5nIGEgY2VydGFpbiBtZWRpY2FsIGRldmljZSAoc2VlIFNlY3Rpb24g Mi4zKS4NCg0KT0xEDQogICBUaGUgcGVyc29uYWwgaGVhbHRoIG1vbml0b3JpbmcgdXNlIGNhc2Ug KHNlZSBTZWN0aW9uIDIuMykgaW5kaWNhdGVzDQogICB0aGUgbmVlZCBmb3Igc2VjdXJlIGF1ZGl0 IGxvZ3Mgd2hpY2ggaW1wb3NlIHNwZWNpZmljIHJlcXVpcmVtZW50cyBvbg0KICAgYSBzb2x1dGlv bi4gIEF1ZGl0aW5nIGlzIG5vdCBpbiB0aGUgc2NvcGUgb2YgQUNFLiAgSG93ZXZlciwgaWYgYW4N CiAgIGF1dGhvcml6YXRpb24gc29sdXRpb24gcHJvdmlkZXMgbWVhbnMgZm9yIGF1ZGl0IGxvZ3Ms IGl0IG11c3QNCiAgIGNvbnNpZGVyIHRoZSBpbXBhY3Qgb2YgbG9nZ2VkIGRhdGEgZm9yIHRoZSBw cml2YWN5IG9mIHRoZSBwcmluY2lwYWwNCiAgIGFuZCBvdGhlciBwYXJ0aWVzIGludm9sdmVkLiAg U3VpdGFibGUgbWVhc3VyZXMgZm9yIHByb3RlY3RpbmcgYW5kDQogICBwdXJnaW5nIHRoZSBsb2dz IG11c3QgYmUgdGFrZW4gZHVyaW5nIG9wZXJhdGlvbiwgbWFpbnRlbmFuY2UgYW5kDQogICBkZWNv bW1pc3Npb25pbmcgb2YgdGhlIGRldmljZS4NCk5FVw0KICAgVGhlIHBlcnNvbmFsIGhlYWx0aCBt b25pdG9yaW5nIHVzZSBjYXNlIChzZWUgU2VjdGlvbiAyLjMpIGluZGljYXRlcw0KICAgdGhlIG5l ZWQgZm9yIHNlY3VyZSBhdWRpdCBsb2dzIHdoaWNoIGltcG9zZSBzcGVjaWZpYyByZXF1aXJlbWVu dHMgb24NCiAgIGEgc29sdXRpb24uICBBdWRpdGluZyBpcyBub3QgaW4gdGhlIHNjb3BlIG9mIEFD RS4gIEhvd2V2ZXIsIGlmIGFuDQogICBhdXRob3JpemF0aW9uIHNvbHV0aW9uIHByb3ZpZGVzIG1l YW5zIGZvciBhdWRpdCBsb2dzLCBpdCBtdXN0DQogICBjb25zaWRlciB0aGUgaW1wYWN0IG9mIGxv Z2dlZCBkYXRhIGZvciB0aGUgcHJpdmFjeSBvZiBhbGwgcGFydGllcw0KaW52b2x2ZWQuICANCiAg IFN1aXRhYmxlIG1lYXN1cmVzIGZvciBwcm90ZWN0aW5nIGFuZA0KICAgcHVyZ2luZyB0aGUgbG9n cyBtdXN0IGJlIHRha2VuIGR1cmluZyBvcGVyYXRpb24sIG1haW50ZW5hbmNlIGFuZA0KICAgZGVj b21taXNzaW9uaW5nIG9mIHRoZSBkZXZpY2UuDQoNCg0KDQoNCg0KDQo+DQoNCg== From nobody Mon Mar 9 07:02:24 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2254F1A8937 for ; Mon, 9 Mar 2015 07:02:23 -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 8EI2x8cGUZSB for ; Mon, 9 Mar 2015 07:02:15 -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 00E101A893A for ; Mon, 9 Mar 2015 07:01:24 -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 t29E1JE2000465; Mon, 9 Mar 2015 15:01:19 +0100 (CET) Received: from [IPv6:2001:638:708:30da:88d7:8f69:3b87:6ed5] (unknown [IPv6:2001:638:708:30da:88d7:8f69:3b87:6ed5]) (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 3l11Rz5TMzz2kvK; Mon, 9 Mar 2015 15:01:19 +0100 (CET) Message-ID: <54FDA7AF.6020300@tzi.de> Date: Mon, 09 Mar 2015 15:01:19 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= References: <201503090843.t298h3k6025846@mailhost.informatik.uni-bremen.de> <54FD70B2.2030601@tzi.de> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] U1.2 in Use Case Document 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, 09 Mar 2015 14:02:23 -0000 Hi Göran On 03/09/2015 11:48 AM, Göran Selander wrote: > Hi Steffi, > > > On 2015-03-09 11:06, "Stefanie Gerdes" wrote: > >> Hi Göran, >> >> I think you forgot to include the mailing list. > > Well, no I didn't, I responded to a mail directly from you. Oh I see, my mistake, sorry. > >> >> On 03/09/2015 10:08 AM, Göran Selander wrote: >>> Hi Steffi, >>> >>> Let’s be brief, since you are probably also working on other drafts. >>> >>> This is a use case document. We should just describe what we consider >>> are >>> the relevant to understand the access control problems of the use cases. >>> What you describe as acccess control problem (or authorization problems) >>> on the client is >>> not what I call an access control problem. Hence when you refer to >>> authorizations of a client I don’t consider that to be in scope of ACE. >> >> Yes, we should describe the problems that we have in certain use cases. >> Your proposal that we do authorization solely on the server side is not >> a problem. It is a solution. > > My proposal is to describe the problems you see in each use cases and > don’t hide behind terminology. Great, then we agree on this. >>> For the same reason, I don’t propose a new formulation, because you will >>> not approve of one which doesn’t explicitly mention the client, right? >> >> Wrong. I only want to make sure that the phrasing does not indicate that >> authorization on the server side is more important. >> >>> Or >>> would you accept something more general such as "Principal is an entity >>> setting access control polices” (I haven’t polished on this formulation >>> as >>> it may be just a waste of time) >> >> How about "Principal: The subject who is in charge of granting >> authorizations". > > I think there may be a problem if we would agree on a term that we both > know is interpreted differently. And I don’t think the term is necessary. > Please find at the end of this mail a proposed update to the security and > privacy considerations (sections 3 & 4) without the terms “Principal”, > “Client” and “Resource Server”. > > >> >>> >>> I don’t expect anyone of us to change opinion about this today, do you? >>> >>> When do you want an update of the security considerations? >> >> Since the client side / server side authorization problem is not >> mentioned in the security considerations as far as I can see, I don't >> see a need to update this section. If you see a problem there, please >> point it out to me. >> >> Concerning the problem summary sections, do we agree on the proposal in >> http://www.ietf.org/mail-archive/web/ace/current/msg01042.html: >> >> U1.1 Fruit vendors, transloading personnel and container owners want to >> define authorizations for their resources and endpoints. >> >> We can change this to: >> >> U1.1 Fruit vendors, transloading personnel and container owners want to >> grant different authorizations for their resources and/or endpoints to >> different parties. >> >> or to: >> >> U1.1 Fruit vendors, transloading personnel and container owners want to >> grant different authorizations to different parties. >> >> U1.2 The fruit vendor requires the integrity of the sensor data that >> pertains the state of the goods for climate control and to ensure the >> quality of the monitored recordings. >> >> U1.3 The container owner requires the integrity of the sensor data that >> is used for climate control. >> >> U1.4 The fruit vendor requires the confidentiality of the sensor data >> that pertains the state of the goods. >> >> U1.5 The fruit vendor may have several types of data that may be >> controlled by the same endpoint, e.g., sensor data and the data used for >> logistics. >> >> U1.6 The fruit vendor requires the confidentiality of the data that is >> used to locate the goods. >> >> U1.7 The fruit vendor requires the integrity of the data that is used to >> locate the goods. >> >> U1.8 The transloading personnel requires the integrity of the data that >> is used to locate the goods. >> >> U1.9 The container owner and the fruit vendor may not be present at the >> time of access and cannot manually intervene in the authorization process. >> >> U1.10 The fruit vendor, container owner and transloading company want to >> grant temporary access permissions to a party. >> >> U1.11 Messages between client and resource server might need to be >> forwarded over multiple hops. >> >> U1.12 The constrained devices might not always be able to reach the >> Internet. > > This is fine by me. Okay, I will change the draft accordingly. > > Best Regards, > Göran > >> >> Best regards, >> Steffi > > > Below are sections 3 & 4 with duplicate paragraphs labelled them “OLD” and > NEW” for comparison. > > > > 3. Security Considerations > > As the use cases listed in this document demonstrate, constrained > devices are used in various application areas. The appeal of these > devices is that they are small and inexpensive. That makes it easy > to integrate them into many aspects of everyday life. Therefore, the > devices will be entrusted with vast amounts of valuable data or even > control functions, that need to be protected from unauthorized > access. Moreover, the aggregation of data must be considered: > attackers might not only collect data from a single device but from > many devices, thus increasing the potential damage. > > Not only the data on the constrained devices themselves is > threatened, the devices might also be abused as an intrusion point to > infiltrate a network. Once an attacker gained control over the > device, it can be used to attack other devices as well. Due to their > limited capabilities, constrained devices appear as the weakest link > in the network and hence pose an attractive target for attackers. > > This section summarizes the security problems highlighted by the use > cases above and provides guidelines for the design of protocols for > authentication and authorization in constrained RESTful environments. > > 3.1. Attacks > > OLD > This document lists security problems that principals of constrained > devices want to solve. Further analysis of attack scenarios is not > in scope of the document. However, there are attacks that must be > considered by solution developers. > NEW > This document lists security problems of constrained-node networks. > Further analysis of attack scenarios is not > in scope of the document. However, there are attacks that must be > considered by solution developers. Maybe we can replace the first sentence with: This document lists authorization problems that users of constrained-node networks want to solve. "Security problem" was a bit too broad in the first place and the document focuses on owner/principal/user problems. > 3.2. Configuration of Access Permissions > > OLD > o The access control policies of the principals need to be enforced > (all use cases): The information that is needed to implement the > access control policies of the Principals need to be provided to > the device that enforces the authorization and applied to every > incoming request. > NEW > o The access control policies need to be enforced > (all use cases): The information that is needed to implement the > access control policies need to be provided to > the device that enforces the authorization and applied to every > incoming request. Okay. > > 3.3. Design Considerations for Authorization Solutions > > OLD > o Devices need to be enabled to enforce the principal's > authorization policies without the principal's intervention at the > time of the access request (see e.g. Section 2.1, Section 2.2, > Section 2.4, Section 2.5). > NEW > o Devices need to be enabled to enforce > authorization policies without human intervention at the > time of the access request (see e.g. Section 2.1, Section 2.2, > Section 2.4, Section 2.5). Okay. > > OLD > o Principals might define authorization policies for a large number > of devices that might only have intermittent connectivity. > Distributing policy updates to every device for every update might > not be a feasible solution (see e.g. Section 2.5). > NEW > o Authorization policies may be defined to apply to a large number > of devices that might only have intermittent connectivity. > Distributing policy updates to every device for every update might > not be a feasible solution (see e.g. Section 2.5). Okay. > 3.4. Proxies > > OLD > In some cases, the traffic between Client and Resource Server might > go through intermediary nodes (e.g. proxies, gateways). This might > affect the function or the security model of authentication and > access control protocols e.g. end-to-end security between Client and > Resource Server with DTLS might not be possible (see Section 2.5). > NEW > In some cases, the traffic between endpoints might > go through intermediary nodes (e.g. proxies, gateways). This might > affect the function or the security model of authentication and > access control protocols e.g. end-to-end security between endpoints > with DTLS might not be possible (see Section 2.5). Okay. > OLD > Privacy protection can also be weighted in when evaluating the need > for end-to-end confidentiality, since otherwise intermediary nodes > will learn the content of potentially sensitive messages sent between > a client and a resource server and thereby endanger the privacy of > the individual that may be subject of this data. > NEW > Privacy protection can also be weighted in when evaluating the need > for end-to-end confidentiality, since otherwise intermediary nodes > will learn the content of potentially sensitive messages sent between > endpoints and thereby endanger the privacy of > the individual that may be subject of this data. Okay. > > > OLD > In some cases, even the possession of a certain type of device can be > confidential, e.g. principals might not want to others to know that > they are wearing a certain medical device (see Section 2.3). > NEW > In some cases, even the possession of a certain type of device can be > confidential, e.g. individuals might not want to others to know that > they are wearing a certain medical device (see Section 2.3). Okay. > > OLD > The personal health monitoring use case (see Section 2.3) indicates > the need for secure audit logs which impose specific requirements on > a solution. Auditing is not in the scope of ACE. However, if an > authorization solution provides means for audit logs, it must > consider the impact of logged data for the privacy of the principal > and other parties involved. Suitable measures for protecting and > purging the logs must be taken during operation, maintenance and > decommissioning of the device. > NEW > The personal health monitoring use case (see Section 2.3) indicates > the need for secure audit logs which impose specific requirements on > a solution. Auditing is not in the scope of ACE. However, if an > authorization solution provides means for audit logs, it must > consider the impact of logged data for the privacy of all parties > involved. > Suitable measures for protecting and > purging the logs must be taken during operation, maintenance and > decommissioning of the device. Okay. So if you agree to the change in the attack section I suggested above, I will update the draft accordingly. Additionally, I will go through the sections and replace the term principal with terms such as "user" or "individual". I assume that we remove the terms "resource", "resource server", "client", "resource owner", "client owner" and "principal" from the terminology section? Best regards, Steffi From nobody Mon Mar 9 07: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 2B5821A895D for ; Mon, 9 Mar 2015 07:19:59 -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 piNe6wiibAHG for ; Mon, 9 Mar 2015 07:19:55 -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 2D9081A8991 for ; Mon, 9 Mar 2015 07:18:51 -0700 (PDT) X-AuditID: c1b4fb25-f79b76d00000113a-77-54fdabc98065 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 41.F6.04410.9CBADF45; Mon, 9 Mar 2015 15:18:49 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.70]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0210.002; Mon, 9 Mar 2015 15:18:48 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Stefanie Gerdes Thread-Topic: [Ace] U1.2 in Use Case Document Thread-Index: AQHQWkUGRkiN6OYzzEyLTf3fE9ZKCp0T3KaA////hwCAABxQAIAAJT2AgAAVpgA= Date: Mon, 9 Mar 2015 14:18:48 +0000 Message-ID: References: <201503090843.t298h3k6025846@mailhost.informatik.uni-bremen.de> <54FD70B2.2030601@tzi.de> <54FDA7AF.6020300@tzi.de> In-Reply-To: <54FDA7AF.6020300@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.147] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM+Jvje7J1X9DDI5+l7f4/q2H2WLjxbuM DkweS5b8ZPLY9vYrcwBTFJdNSmpOZllqkb5dAlfGkl//WAom9DBWbDj9kKmB8UgHYxcjJ4eE gInEuscfmSBsMYkL99azdTFycQgJHGGUaNjUzAzhLGKUeA5VxSbgIvGg4RGYLSKgLPF78Scw m1lAUWL3rLPsILawgI7E1r87gDZwANXoSlxf7wVR7ifxed4CsBIWARWJ7+/fMoPYvAIWEtP2 HGaE2HWXUeL+pBlgRZwCahIvl25hBbEZga77fmoN1C5xiVtP5kNdLSCxZM95ZghbVOLl439g 9aICehIrrzexgdwgIaAkMW1rGojJLKApsX6XPsQUa4mNp5cxwlw/pfshO8Q5ghInZz5hmcAo MQvJslkI3bOQdM9C0j0LSfcCRtZVjKLFqcVJuelGxnqpRZnJxcX5eXp5qSWbGIFxeHDLb9Ud jJffOB5iFOBgVOLhLbjyJ0SINbGsuDL3EKM0B4uSOK+d8aEQIYH0xJLU7NTUgtSi+KLSnNTi Q4xMHJxSDYxd+dylvT8ELgskbM5bccr++uFdve0XLfZHrpNUzN+kJ7jqvbhZdEGniIbhftPq aV8/z1d8a2H+Vqd+ZZnC4ZJrNXx7vv/0tebeVSiydOXjWxUp1sH+fI+txXft/Ly7vzBZzoNX bAZjWyZXwqo7URsuyVyYNEnd/VjRy/V++24tNvkiwnFTy1uJpTgj0VCLuag4EQAO6m9BpAIA AA== Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] U1.2 in Use Case Document 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, 09 Mar 2015 14:19:59 -0000 SGkgU3RlZmZpLA0KDQpJ4oCZbSBmaW5lIHdpdGggeW91ciBzdWdnZXN0aW9ucy4gUGxlYXNlIGdv IGFoZWFkIGFuZCBtYWtlIGEgcHJvcG9zYWwgZm9yDQp1cGRhdGVkIHByb2JsZW0gZGVzY3JpcHRp b25zLg0KDQpCZXN0IHJlZ2FyZHMsDQpHw7ZyYW4NCg0KDQoNCk9uIDIwMTUtMDMtMDkgMTU6MDEs ICJTdGVmYW5pZSBHZXJkZXMiIDxnZXJkZXNAdHppLmRlPiB3cm90ZToNCg0KPkhpIEfDtnJhbg0K Pg0KPk9uIDAzLzA5LzIwMTUgMTE6NDggQU0sIEfDtnJhbiBTZWxhbmRlciB3cm90ZToNCj4+IEhp IFN0ZWZmaSwNCj4+DQo+Pg0KPj4gT24gMjAxNS0wMy0wOSAxMTowNiwgIlN0ZWZhbmllIEdlcmRl cyIgPGdlcmRlc0B0emkuZGU+IHdyb3RlOg0KPj4NCj4+PiBIaSBHw7ZyYW4sDQo+Pj4NCj4+PiBJ IHRoaW5rIHlvdSBmb3Jnb3QgdG8gaW5jbHVkZSB0aGUgbWFpbGluZyBsaXN0Lg0KPj4NCj4+IFdl bGwsIG5vIEkgZGlkbid0LCBJIHJlc3BvbmRlZCB0byBhIG1haWwgZGlyZWN0bHkgZnJvbSB5b3Uu DQo+DQo+T2ggSSBzZWUsIG15IG1pc3Rha2UsIHNvcnJ5Lg0KPg0KPj4NCj4+Pg0KPj4+IE9uIDAz LzA5LzIwMTUgMTA6MDggQU0sIEfDtnJhbiBTZWxhbmRlciB3cm90ZToNCj4+Pj4gSGkgU3RlZmZp LA0KPj4+Pg0KPj4+PiBMZXTigJlzIGJlIGJyaWVmLCBzaW5jZSB5b3UgYXJlIHByb2JhYmx5IGFs c28gd29ya2luZyBvbiBvdGhlciBkcmFmdHMuDQo+Pj4+DQo+Pj4+IFRoaXMgaXMgYSB1c2UgY2Fz ZSBkb2N1bWVudC4gV2Ugc2hvdWxkIGp1c3QgZGVzY3JpYmUgd2hhdCB3ZSBjb25zaWRlcg0KPj4+ PiBhcmUNCj4+Pj4gdGhlIHJlbGV2YW50IHRvIHVuZGVyc3RhbmQgdGhlIGFjY2VzcyBjb250cm9s IHByb2JsZW1zIG9mIHRoZSB1c2UNCj4+Pj5jYXNlcy4NCj4+Pj4gV2hhdCB5b3UgZGVzY3JpYmUg YXMgYWNjY2VzcyBjb250cm9sIHByb2JsZW0gKG9yIGF1dGhvcml6YXRpb24NCj4+Pj5wcm9ibGVt cykNCj4+Pj4gb24gdGhlIGNsaWVudCBpcw0KPj4+PiBub3Qgd2hhdCBJIGNhbGwgYW4gYWNjZXNz IGNvbnRyb2wgcHJvYmxlbS4gSGVuY2Ugd2hlbiB5b3UgcmVmZXIgdG8NCj4+Pj4gYXV0aG9yaXph dGlvbnMgb2YgYSBjbGllbnQgSSBkb27igJl0IGNvbnNpZGVyIHRoYXQgdG8gYmUgaW4gc2NvcGUg b2YNCj4+Pj5BQ0UuDQo+Pj4NCj4+PiBZZXMsIHdlIHNob3VsZCBkZXNjcmliZSB0aGUgcHJvYmxl bXMgdGhhdCB3ZSBoYXZlIGluIGNlcnRhaW4gdXNlIGNhc2VzLg0KPj4+IFlvdXIgcHJvcG9zYWwg dGhhdCB3ZSBkbyBhdXRob3JpemF0aW9uIHNvbGVseSBvbiB0aGUgc2VydmVyIHNpZGUgaXMgbm90 DQo+Pj4gYSBwcm9ibGVtLiBJdCBpcyBhIHNvbHV0aW9uLg0KPj4NCj4+IE15IHByb3Bvc2FsIGlz IHRvIGRlc2NyaWJlIHRoZSBwcm9ibGVtcyB5b3Ugc2VlIGluIGVhY2ggdXNlIGNhc2VzIGFuZA0K Pj4gZG9u4oCZdCBoaWRlIGJlaGluZCB0ZXJtaW5vbG9neS4NCj4NCj5HcmVhdCwgdGhlbiB3ZSBh Z3JlZSBvbiB0aGlzLg0KPg0KPj4+PiBGb3IgdGhlIHNhbWUgcmVhc29uLCBJIGRvbuKAmXQgcHJv cG9zZSBhIG5ldyBmb3JtdWxhdGlvbiwgYmVjYXVzZSB5b3UNCj4+Pj53aWxsDQo+Pj4+IG5vdCBh cHByb3ZlIG9mIG9uZSB3aGljaCBkb2VzbuKAmXQgZXhwbGljaXRseSBtZW50aW9uIHRoZSBjbGll bnQsIHJpZ2h0Pw0KPj4+DQo+Pj4gV3JvbmcuIEkgb25seSB3YW50IHRvIG1ha2Ugc3VyZSB0aGF0 IHRoZSBwaHJhc2luZyBkb2VzIG5vdCBpbmRpY2F0ZQ0KPj4+dGhhdA0KPj4+IGF1dGhvcml6YXRp b24gb24gdGhlIHNlcnZlciBzaWRlIGlzIG1vcmUgaW1wb3J0YW50Lg0KPj4+DQo+Pj4+IE9yDQo+ Pj4+IHdvdWxkIHlvdSBhY2NlcHQgc29tZXRoaW5nIG1vcmUgZ2VuZXJhbCBzdWNoIGFzICJQcmlu Y2lwYWwgaXMgYW4NCj4+Pj5lbnRpdHkNCj4+Pj4gc2V0dGluZyBhY2Nlc3MgY29udHJvbCBwb2xp Y2Vz4oCdIChJIGhhdmVu4oCZdCBwb2xpc2hlZCBvbiB0aGlzDQo+Pj4+Zm9ybXVsYXRpb24NCj4+ Pj4gYXMNCj4+Pj4gaXQgbWF5IGJlIGp1c3QgYSB3YXN0ZSBvZiB0aW1lKQ0KPj4+DQo+Pj4gSG93 IGFib3V0ICJQcmluY2lwYWw6IFRoZSBzdWJqZWN0IHdobyBpcyBpbiBjaGFyZ2Ugb2YgZ3JhbnRp bmcNCj4+PiBhdXRob3JpemF0aW9ucyIuDQo+Pg0KPj4gSSB0aGluayB0aGVyZSBtYXkgYmUgYSBw cm9ibGVtIGlmIHdlIHdvdWxkIGFncmVlIG9uIGEgdGVybSB0aGF0IHdlIGJvdGgNCj4+IGtub3cg aXMgaW50ZXJwcmV0ZWQgZGlmZmVyZW50bHkuIEFuZCBJIGRvbuKAmXQgdGhpbmsgdGhlIHRlcm0g aXMNCj4+bmVjZXNzYXJ5Lg0KPj4gUGxlYXNlIGZpbmQgYXQgdGhlIGVuZCBvZiB0aGlzIG1haWwg YSBwcm9wb3NlZCB1cGRhdGUgdG8gdGhlIHNlY3VyaXR5DQo+PmFuZA0KPj4gcHJpdmFjeSBjb25z aWRlcmF0aW9ucyAoc2VjdGlvbnMgMyAmIDQpIHdpdGhvdXQgdGhlIHRlcm1zIOKAnFByaW5jaXBh bOKAnSwNCj4+IOKAnENsaWVudOKAnSBhbmQg4oCcUmVzb3VyY2UgU2VydmVy4oCdLg0KPj4NCj4+ DQo+Pj4NCj4+Pj4NCj4+Pj4gSSBkb27igJl0IGV4cGVjdCBhbnlvbmUgb2YgdXMgdG8gY2hhbmdl IG9waW5pb24gYWJvdXQgdGhpcyB0b2RheSwgZG8NCj4+Pj55b3U/DQo+Pj4+DQo+Pj4+IFdoZW4g ZG8geW91IHdhbnQgYW4gdXBkYXRlIG9mIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucz8NCj4+ Pg0KPj4+IFNpbmNlIHRoZSBjbGllbnQgc2lkZSAvIHNlcnZlciBzaWRlIGF1dGhvcml6YXRpb24g cHJvYmxlbSBpcyBub3QNCj4+PiBtZW50aW9uZWQgaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zIGFzIGZhciBhcyBJIGNhbiBzZWUsIEkgZG9uJ3QNCj4+PiBzZWUgYSBuZWVkIHRvIHVwZGF0 ZSB0aGlzIHNlY3Rpb24uIElmIHlvdSBzZWUgYSBwcm9ibGVtIHRoZXJlLCBwbGVhc2UNCj4+PiBw b2ludCBpdCBvdXQgdG8gbWUuDQo+Pj4NCj4+PiBDb25jZXJuaW5nIHRoZSBwcm9ibGVtIHN1bW1h cnkgc2VjdGlvbnMsIGRvIHdlIGFncmVlIG9uIHRoZSBwcm9wb3NhbCBpbg0KPj4+IGh0dHA6Ly93 d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9hY2UvY3VycmVudC9tc2cwMTA0Mi5odG1sOg0K Pj4+DQo+Pj4gVTEuMSBGcnVpdCB2ZW5kb3JzLCB0cmFuc2xvYWRpbmcgcGVyc29ubmVsIGFuZCBj b250YWluZXIgb3duZXJzIHdhbnQgdG8NCj4+PiBkZWZpbmUgYXV0aG9yaXphdGlvbnMgZm9yIHRo ZWlyIHJlc291cmNlcyBhbmQgZW5kcG9pbnRzLg0KPj4+DQo+Pj4gV2UgY2FuIGNoYW5nZSB0aGlz IHRvOg0KPj4+DQo+Pj4gVTEuMSBGcnVpdCB2ZW5kb3JzLCB0cmFuc2xvYWRpbmcgcGVyc29ubmVs IGFuZCBjb250YWluZXIgb3duZXJzIHdhbnQgdG8NCj4+PiBncmFudCBkaWZmZXJlbnQgYXV0aG9y aXphdGlvbnMgZm9yIHRoZWlyIHJlc291cmNlcyBhbmQvb3IgZW5kcG9pbnRzIHRvDQo+Pj4gZGlm ZmVyZW50IHBhcnRpZXMuDQo+Pj4NCj4+PiBvciB0bzoNCj4+Pg0KPj4+IFUxLjEgRnJ1aXQgdmVu ZG9ycywgdHJhbnNsb2FkaW5nIHBlcnNvbm5lbCBhbmQgY29udGFpbmVyIG93bmVycyB3YW50IHRv DQo+Pj4gZ3JhbnQgZGlmZmVyZW50IGF1dGhvcml6YXRpb25zIHRvIGRpZmZlcmVudCBwYXJ0aWVz Lg0KPj4+DQo+Pj4gVTEuMiBUaGUgZnJ1aXQgdmVuZG9yIHJlcXVpcmVzIHRoZSBpbnRlZ3JpdHkg b2YgdGhlIHNlbnNvciBkYXRhIHRoYXQNCj4+PiBwZXJ0YWlucyB0aGUgc3RhdGUgb2YgdGhlIGdv b2RzIGZvciBjbGltYXRlIGNvbnRyb2wgYW5kIHRvIGVuc3VyZSB0aGUNCj4+PiBxdWFsaXR5IG9m IHRoZSBtb25pdG9yZWQgcmVjb3JkaW5ncy4NCj4+Pg0KPj4+IFUxLjMgVGhlIGNvbnRhaW5lciBv d25lciByZXF1aXJlcyB0aGUgaW50ZWdyaXR5IG9mIHRoZSBzZW5zb3IgZGF0YSB0aGF0DQo+Pj4g aXMgdXNlZCBmb3IgY2xpbWF0ZSBjb250cm9sLg0KPj4+DQo+Pj4gVTEuNCBUaGUgZnJ1aXQgdmVu ZG9yIHJlcXVpcmVzIHRoZSBjb25maWRlbnRpYWxpdHkgb2YgdGhlIHNlbnNvciBkYXRhDQo+Pj4g dGhhdCBwZXJ0YWlucyB0aGUgc3RhdGUgb2YgdGhlIGdvb2RzLg0KPj4+DQo+Pj4gVTEuNSBUaGUg ZnJ1aXQgdmVuZG9yIG1heSBoYXZlIHNldmVyYWwgdHlwZXMgb2YgZGF0YSB0aGF0IG1heSBiZQ0K Pj4+IGNvbnRyb2xsZWQgYnkgdGhlIHNhbWUgZW5kcG9pbnQsIGUuZy4sIHNlbnNvciBkYXRhIGFu ZCB0aGUgZGF0YSB1c2VkDQo+Pj5mb3INCj4+PiBsb2dpc3RpY3MuDQo+Pj4NCj4+PiBVMS42IFRo ZSBmcnVpdCB2ZW5kb3IgcmVxdWlyZXMgdGhlIGNvbmZpZGVudGlhbGl0eSBvZiB0aGUgZGF0YSB0 aGF0IGlzDQo+Pj4gdXNlZCB0byBsb2NhdGUgdGhlIGdvb2RzLg0KPj4+DQo+Pj4gVTEuNyBUaGUg ZnJ1aXQgdmVuZG9yIHJlcXVpcmVzIHRoZSBpbnRlZ3JpdHkgb2YgdGhlIGRhdGEgdGhhdCBpcyB1 c2VkDQo+Pj50bw0KPj4+IGxvY2F0ZSB0aGUgZ29vZHMuDQo+Pj4NCj4+PiBVMS44IFRoZSB0cmFu c2xvYWRpbmcgcGVyc29ubmVsIHJlcXVpcmVzIHRoZSBpbnRlZ3JpdHkgb2YgdGhlIGRhdGEgdGhh dA0KPj4+IGlzIHVzZWQgdG8gbG9jYXRlIHRoZSBnb29kcy4NCj4+Pg0KPj4+IFUxLjkgVGhlIGNv bnRhaW5lciBvd25lciBhbmQgdGhlIGZydWl0IHZlbmRvciBtYXkgbm90IGJlIHByZXNlbnQgYXQg dGhlDQo+Pj4gdGltZSBvZiBhY2Nlc3MgYW5kIGNhbm5vdCBtYW51YWxseSBpbnRlcnZlbmUgaW4g dGhlIGF1dGhvcml6YXRpb24NCj4+PnByb2Nlc3MuDQo+Pj4NCj4+PiBVMS4xMCBUaGUgZnJ1aXQg dmVuZG9yLCBjb250YWluZXIgb3duZXIgYW5kIHRyYW5zbG9hZGluZyBjb21wYW55IHdhbnQNCj4+ PnRvDQo+Pj4gZ3JhbnQgdGVtcG9yYXJ5IGFjY2VzcyBwZXJtaXNzaW9ucyB0byBhIHBhcnR5Lg0K Pj4+DQo+Pj4gVTEuMTEgTWVzc2FnZXMgYmV0d2VlbiBjbGllbnQgYW5kIHJlc291cmNlIHNlcnZl ciBtaWdodCBuZWVkIHRvIGJlDQo+Pj4gZm9yd2FyZGVkIG92ZXIgbXVsdGlwbGUgaG9wcy4NCj4+ Pg0KPj4+IFUxLjEyIFRoZSBjb25zdHJhaW5lZCBkZXZpY2VzIG1pZ2h0IG5vdCBhbHdheXMgYmUg YWJsZSB0byByZWFjaCB0aGUNCj4+PiBJbnRlcm5ldC4NCj4+DQo+PiBUaGlzIGlzIGZpbmUgYnkg bWUuDQo+DQo+T2theSwgSSB3aWxsIGNoYW5nZSB0aGUgZHJhZnQgYWNjb3JkaW5nbHkuDQo+DQo+ Pg0KPj4gQmVzdCBSZWdhcmRzLA0KPj4gR8O2cmFuDQo+Pg0KPj4+DQo+Pj4gQmVzdCByZWdhcmRz LA0KPj4+IFN0ZWZmaQ0KPj4NCj4+DQo+PiBCZWxvdyBhcmUgc2VjdGlvbnMgMyAmIDQgd2l0aCBk dXBsaWNhdGUgcGFyYWdyYXBocyBsYWJlbGxlZCB0aGVtIOKAnE9MROKAnQ0KPj5hbmQNCj4+IE5F V+KAnSBmb3IgY29tcGFyaXNvbi4NCj4+DQo+Pg0KPj4NCj4+IDMuICBTZWN1cml0eSBDb25zaWRl cmF0aW9ucw0KPj4NCj4+ICAgICBBcyB0aGUgdXNlIGNhc2VzIGxpc3RlZCBpbiB0aGlzIGRvY3Vt ZW50IGRlbW9uc3RyYXRlLCBjb25zdHJhaW5lZA0KPj4gICAgIGRldmljZXMgYXJlIHVzZWQgaW4g dmFyaW91cyBhcHBsaWNhdGlvbiBhcmVhcy4gIFRoZSBhcHBlYWwgb2YgdGhlc2UNCj4+ICAgICBk ZXZpY2VzIGlzIHRoYXQgdGhleSBhcmUgc21hbGwgYW5kIGluZXhwZW5zaXZlLiAgVGhhdCBtYWtl cyBpdCBlYXN5DQo+PiAgICAgdG8gaW50ZWdyYXRlIHRoZW0gaW50byBtYW55IGFzcGVjdHMgb2Yg ZXZlcnlkYXkgbGlmZS4gIFRoZXJlZm9yZSwNCj4+dGhlDQo+PiAgICAgZGV2aWNlcyB3aWxsIGJl IGVudHJ1c3RlZCB3aXRoIHZhc3QgYW1vdW50cyBvZiB2YWx1YWJsZSBkYXRhIG9yIGV2ZW4NCj4+ ICAgICBjb250cm9sIGZ1bmN0aW9ucywgdGhhdCBuZWVkIHRvIGJlIHByb3RlY3RlZCBmcm9tIHVu YXV0aG9yaXplZA0KPj4gICAgIGFjY2Vzcy4gIE1vcmVvdmVyLCB0aGUgYWdncmVnYXRpb24gb2Yg ZGF0YSBtdXN0IGJlIGNvbnNpZGVyZWQ6DQo+PiAgICAgYXR0YWNrZXJzIG1pZ2h0IG5vdCBvbmx5 IGNvbGxlY3QgZGF0YSBmcm9tIGEgc2luZ2xlIGRldmljZSBidXQgZnJvbQ0KPj4gICAgIG1hbnkg ZGV2aWNlcywgdGh1cyBpbmNyZWFzaW5nIHRoZSBwb3RlbnRpYWwgZGFtYWdlLg0KPj4NCj4+ICAg ICBOb3Qgb25seSB0aGUgZGF0YSBvbiB0aGUgY29uc3RyYWluZWQgZGV2aWNlcyB0aGVtc2VsdmVz IGlzDQo+PiAgICAgdGhyZWF0ZW5lZCwgdGhlIGRldmljZXMgbWlnaHQgYWxzbyBiZSBhYnVzZWQg YXMgYW4gaW50cnVzaW9uIHBvaW50DQo+PnRvDQo+PiAgICAgaW5maWx0cmF0ZSBhIG5ldHdvcmsu ICBPbmNlIGFuIGF0dGFja2VyIGdhaW5lZCBjb250cm9sIG92ZXIgdGhlDQo+PiAgICAgZGV2aWNl LCBpdCBjYW4gYmUgdXNlZCB0byBhdHRhY2sgb3RoZXIgZGV2aWNlcyBhcyB3ZWxsLiAgRHVlIHRv DQo+PnRoZWlyDQo+PiAgICAgbGltaXRlZCBjYXBhYmlsaXRpZXMsIGNvbnN0cmFpbmVkIGRldmlj ZXMgYXBwZWFyIGFzIHRoZSB3ZWFrZXN0IGxpbmsNCj4+ICAgICBpbiB0aGUgbmV0d29yayBhbmQg aGVuY2UgcG9zZSBhbiBhdHRyYWN0aXZlIHRhcmdldCBmb3IgYXR0YWNrZXJzLg0KPj4NCj4+ICAg ICBUaGlzIHNlY3Rpb24gc3VtbWFyaXplcyB0aGUgc2VjdXJpdHkgcHJvYmxlbXMgaGlnaGxpZ2h0 ZWQgYnkgdGhlIHVzZQ0KPj4gICAgIGNhc2VzIGFib3ZlIGFuZCBwcm92aWRlcyBndWlkZWxpbmVz IGZvciB0aGUgZGVzaWduIG9mIHByb3RvY29scyBmb3INCj4+ICAgICBhdXRoZW50aWNhdGlvbiBh bmQgYXV0aG9yaXphdGlvbiBpbiBjb25zdHJhaW5lZCBSRVNUZnVsDQo+PmVudmlyb25tZW50cy4N Cj4+DQo+PiAzLjEuICBBdHRhY2tzDQo+Pg0KPj4gT0xEDQo+PiAgICAgVGhpcyBkb2N1bWVudCBs aXN0cyBzZWN1cml0eSBwcm9ibGVtcyB0aGF0IHByaW5jaXBhbHMgb2YgY29uc3RyYWluZWQNCj4+ ICAgICBkZXZpY2VzIHdhbnQgdG8gc29sdmUuICBGdXJ0aGVyIGFuYWx5c2lzIG9mIGF0dGFjayBz Y2VuYXJpb3MgaXMgbm90DQo+PiAgICAgaW4gc2NvcGUgb2YgdGhlIGRvY3VtZW50LiAgSG93ZXZl ciwgdGhlcmUgYXJlIGF0dGFja3MgdGhhdCBtdXN0IGJlDQo+PiAgICAgY29uc2lkZXJlZCBieSBz b2x1dGlvbiBkZXZlbG9wZXJzLg0KPj4gTkVXDQo+PiAgICAgVGhpcyBkb2N1bWVudCBsaXN0cyBz ZWN1cml0eSBwcm9ibGVtcyBvZiBjb25zdHJhaW5lZC1ub2RlIG5ldHdvcmtzLg0KPj4gICAgIEZ1 cnRoZXIgYW5hbHlzaXMgb2YgYXR0YWNrIHNjZW5hcmlvcyBpcyBub3QNCj4+ICAgICBpbiBzY29w ZSBvZiB0aGUgZG9jdW1lbnQuICBIb3dldmVyLCB0aGVyZSBhcmUgYXR0YWNrcyB0aGF0IG11c3Qg YmUNCj4+ICAgICBjb25zaWRlcmVkIGJ5IHNvbHV0aW9uIGRldmVsb3BlcnMuDQo+DQo+TWF5YmUg d2UgY2FuIHJlcGxhY2UgdGhlIGZpcnN0IHNlbnRlbmNlIHdpdGg6DQo+VGhpcyBkb2N1bWVudCBs aXN0cyBhdXRob3JpemF0aW9uIHByb2JsZW1zIHRoYXQgdXNlcnMgb2YNCj5jb25zdHJhaW5lZC1u b2RlIG5ldHdvcmtzIHdhbnQgdG8gc29sdmUuDQo+DQo+IlNlY3VyaXR5IHByb2JsZW0iIHdhcyBh IGJpdCB0b28gYnJvYWQgaW4gdGhlIGZpcnN0IHBsYWNlIGFuZCB0aGUNCj5kb2N1bWVudCBmb2N1 c2VzIG9uIG93bmVyL3ByaW5jaXBhbC91c2VyIHByb2JsZW1zLg0KPg0KPjxzbmlwPg0KPg0KPg0K Pj4gMy4yLiAgQ29uZmlndXJhdGlvbiBvZiBBY2Nlc3MgUGVybWlzc2lvbnMNCj4+DQo+PiBPTEQN Cj4+ICAgICBvICBUaGUgYWNjZXNzIGNvbnRyb2wgcG9saWNpZXMgb2YgdGhlIHByaW5jaXBhbHMg bmVlZCB0byBiZSBlbmZvcmNlZA0KPj4gICAgICAgIChhbGwgdXNlIGNhc2VzKTogVGhlIGluZm9y bWF0aW9uIHRoYXQgaXMgbmVlZGVkIHRvIGltcGxlbWVudCB0aGUNCj4+ICAgICAgICBhY2Nlc3Mg Y29udHJvbCBwb2xpY2llcyBvZiB0aGUgUHJpbmNpcGFscyBuZWVkIHRvIGJlIHByb3ZpZGVkIHRv DQo+PiAgICAgICAgdGhlIGRldmljZSB0aGF0IGVuZm9yY2VzIHRoZSBhdXRob3JpemF0aW9uIGFu ZCBhcHBsaWVkIHRvIGV2ZXJ5DQo+PiAgICAgICAgaW5jb21pbmcgcmVxdWVzdC4NCj4+IE5FVw0K Pj4gICAgIG8gIFRoZSBhY2Nlc3MgY29udHJvbCBwb2xpY2llcyBuZWVkIHRvIGJlIGVuZm9yY2Vk DQo+PiAgICAgICAgKGFsbCB1c2UgY2FzZXMpOiBUaGUgaW5mb3JtYXRpb24gdGhhdCBpcyBuZWVk ZWQgdG8gaW1wbGVtZW50IHRoZQ0KPj4gICAgICAgIGFjY2VzcyBjb250cm9sIHBvbGljaWVzIG5l ZWQgdG8gYmUgcHJvdmlkZWQgdG8NCj4+ICAgICAgICB0aGUgZGV2aWNlIHRoYXQgZW5mb3JjZXMg dGhlIGF1dGhvcml6YXRpb24gYW5kIGFwcGxpZWQgdG8gZXZlcnkNCj4+ICAgICAgICBpbmNvbWlu ZyByZXF1ZXN0Lg0KPg0KPk9rYXkuDQo+DQo+PHNuaXA+DQo+DQo+Pg0KPj4gMy4zLiAgRGVzaWdu IENvbnNpZGVyYXRpb25zIGZvciBBdXRob3JpemF0aW9uIFNvbHV0aW9ucw0KPj4NCj4+IE9MRA0K Pj4gICAgIG8gIERldmljZXMgbmVlZCB0byBiZSBlbmFibGVkIHRvIGVuZm9yY2UgdGhlIHByaW5j aXBhbCdzDQo+PiAgICAgICAgYXV0aG9yaXphdGlvbiBwb2xpY2llcyB3aXRob3V0IHRoZSBwcmlu Y2lwYWwncyBpbnRlcnZlbnRpb24gYXQNCj4+dGhlDQo+PiAgICAgICAgdGltZSBvZiB0aGUgYWNj ZXNzIHJlcXVlc3QgKHNlZSBlLmcuICBTZWN0aW9uIDIuMSwgU2VjdGlvbiAyLjIsDQo+PiAgICAg ICAgU2VjdGlvbiAyLjQsIFNlY3Rpb24gMi41KS4NCj4+IE5FVw0KPj4gICAgIG8gIERldmljZXMg bmVlZCB0byBiZSBlbmFibGVkIHRvIGVuZm9yY2UNCj4+ICAgICAgICBhdXRob3JpemF0aW9uIHBv bGljaWVzIHdpdGhvdXQgaHVtYW4gaW50ZXJ2ZW50aW9uIGF0IHRoZQ0KPj4gICAgICAgIHRpbWUg b2YgdGhlIGFjY2VzcyByZXF1ZXN0IChzZWUgZS5nLiAgU2VjdGlvbiAyLjEsIFNlY3Rpb24gMi4y LA0KPj4gICAgICAgIFNlY3Rpb24gMi40LCBTZWN0aW9uIDIuNSkuDQo+DQo+T2theS4NCj4NCj48 c25pcD4NCj4NCj4+DQo+PiBPTEQNCj4+ICAgICBvICBQcmluY2lwYWxzIG1pZ2h0IGRlZmluZSBh dXRob3JpemF0aW9uIHBvbGljaWVzIGZvciBhIGxhcmdlIG51bWJlcg0KPj4gICAgICAgIG9mIGRl dmljZXMgdGhhdCBtaWdodCBvbmx5IGhhdmUgaW50ZXJtaXR0ZW50IGNvbm5lY3Rpdml0eS4NCj4+ ICAgICAgICBEaXN0cmlidXRpbmcgcG9saWN5IHVwZGF0ZXMgdG8gZXZlcnkgZGV2aWNlIGZvciBl dmVyeSB1cGRhdGUNCj4+bWlnaHQNCj4+ICAgICAgICBub3QgYmUgYSBmZWFzaWJsZSBzb2x1dGlv biAoc2VlIGUuZy4gIFNlY3Rpb24gMi41KS4NCj4+IE5FVw0KPj4gICAgIG8gIEF1dGhvcml6YXRp b24gcG9saWNpZXMgbWF5IGJlIGRlZmluZWQgdG8gYXBwbHkgdG8gYSBsYXJnZSBudW1iZXINCj4+ ICAgICAgICBvZiBkZXZpY2VzIHRoYXQgbWlnaHQgb25seSBoYXZlIGludGVybWl0dGVudCBjb25u ZWN0aXZpdHkuDQo+PiAgICAgICAgRGlzdHJpYnV0aW5nIHBvbGljeSB1cGRhdGVzIHRvIGV2ZXJ5 IGRldmljZSBmb3IgZXZlcnkgdXBkYXRlDQo+Pm1pZ2h0DQo+PiAgICAgICAgbm90IGJlIGEgZmVh c2libGUgc29sdXRpb24gKHNlZSBlLmcuICBTZWN0aW9uIDIuNSkuDQo+DQo+T2theS4NCj4NCj48 c25pcD4NCj4NCj4+IDMuNC4gIFByb3hpZXMNCj4+DQo+PiBPTEQNCj4+ICAgICBJbiBzb21lIGNh c2VzLCB0aGUgdHJhZmZpYyBiZXR3ZWVuIENsaWVudCBhbmQgUmVzb3VyY2UgU2VydmVyIG1pZ2h0 DQo+PiAgICAgZ28gdGhyb3VnaCBpbnRlcm1lZGlhcnkgbm9kZXMgKGUuZy4gcHJveGllcywgZ2F0 ZXdheXMpLiAgVGhpcyBtaWdodA0KPj4gICAgIGFmZmVjdCB0aGUgZnVuY3Rpb24gb3IgdGhlIHNl Y3VyaXR5IG1vZGVsIG9mIGF1dGhlbnRpY2F0aW9uIGFuZA0KPj4gICAgIGFjY2VzcyBjb250cm9s IHByb3RvY29scyBlLmcuIGVuZC10by1lbmQgc2VjdXJpdHkgYmV0d2VlbiBDbGllbnQgYW5kDQo+ PiAgICAgUmVzb3VyY2UgU2VydmVyIHdpdGggRFRMUyBtaWdodCBub3QgYmUgcG9zc2libGUgKHNl ZSBTZWN0aW9uIDIuNSkuDQo+PiBORVcNCj4+ICAgICBJbiBzb21lIGNhc2VzLCB0aGUgdHJhZmZp YyBiZXR3ZWVuIGVuZHBvaW50cyBtaWdodA0KPj4gICAgIGdvIHRocm91Z2ggaW50ZXJtZWRpYXJ5 IG5vZGVzIChlLmcuIHByb3hpZXMsIGdhdGV3YXlzKS4gIFRoaXMgbWlnaHQNCj4+ICAgICBhZmZl Y3QgdGhlIGZ1bmN0aW9uIG9yIHRoZSBzZWN1cml0eSBtb2RlbCBvZiBhdXRoZW50aWNhdGlvbiBh bmQNCj4+ICAgICBhY2Nlc3MgY29udHJvbCBwcm90b2NvbHMgZS5nLiBlbmQtdG8tZW5kIHNlY3Vy aXR5IGJldHdlZW4gZW5kcG9pbnRzDQo+PiAgICAgd2l0aCBEVExTIG1pZ2h0IG5vdCBiZSBwb3Nz aWJsZSAoc2VlIFNlY3Rpb24gMi41KS4NCj4NCj5Pa2F5Lg0KPg0KPjxzbmlwPg0KPg0KPj4gT0xE DQo+PiAgICAgUHJpdmFjeSBwcm90ZWN0aW9uIGNhbiBhbHNvIGJlIHdlaWdodGVkIGluIHdoZW4g ZXZhbHVhdGluZyB0aGUgbmVlZA0KPj4gICAgIGZvciBlbmQtdG8tZW5kIGNvbmZpZGVudGlhbGl0 eSwgc2luY2Ugb3RoZXJ3aXNlIGludGVybWVkaWFyeSBub2Rlcw0KPj4gICAgIHdpbGwgbGVhcm4g dGhlIGNvbnRlbnQgb2YgcG90ZW50aWFsbHkgc2Vuc2l0aXZlIG1lc3NhZ2VzIHNlbnQNCj4+YmV0 d2Vlbg0KPj4gICAgIGEgY2xpZW50IGFuZCBhIHJlc291cmNlIHNlcnZlciBhbmQgdGhlcmVieSBl bmRhbmdlciB0aGUgcHJpdmFjeSBvZg0KPj4gICAgIHRoZSBpbmRpdmlkdWFsIHRoYXQgbWF5IGJl IHN1YmplY3Qgb2YgdGhpcyBkYXRhLg0KPj4gTkVXDQo+PiAgICAgUHJpdmFjeSBwcm90ZWN0aW9u IGNhbiBhbHNvIGJlIHdlaWdodGVkIGluIHdoZW4gZXZhbHVhdGluZyB0aGUgbmVlZA0KPj4gICAg IGZvciBlbmQtdG8tZW5kIGNvbmZpZGVudGlhbGl0eSwgc2luY2Ugb3RoZXJ3aXNlIGludGVybWVk aWFyeSBub2Rlcw0KPj4gICAgIHdpbGwgbGVhcm4gdGhlIGNvbnRlbnQgb2YgcG90ZW50aWFsbHkg c2Vuc2l0aXZlIG1lc3NhZ2VzIHNlbnQNCj4+YmV0d2Vlbg0KPj4gICAgIGVuZHBvaW50cyBhbmQg dGhlcmVieSBlbmRhbmdlciB0aGUgcHJpdmFjeSBvZg0KPj4gICAgIHRoZSBpbmRpdmlkdWFsIHRo YXQgbWF5IGJlIHN1YmplY3Qgb2YgdGhpcyBkYXRhLg0KPg0KPk9rYXkuDQo+DQo+Pg0KPj4NCj4+ IE9MRA0KPj4gICAgIEluIHNvbWUgY2FzZXMsIGV2ZW4gdGhlIHBvc3Nlc3Npb24gb2YgYSBjZXJ0 YWluIHR5cGUgb2YgZGV2aWNlIGNhbg0KPj5iZQ0KPj4gICAgIGNvbmZpZGVudGlhbCwgZS5nLiBw cmluY2lwYWxzIG1pZ2h0IG5vdCB3YW50IHRvIG90aGVycyB0byBrbm93IHRoYXQNCj4+ICAgICB0 aGV5IGFyZSB3ZWFyaW5nIGEgY2VydGFpbiBtZWRpY2FsIGRldmljZSAoc2VlIFNlY3Rpb24gMi4z KS4NCj4+IE5FVw0KPj4gICAgIEluIHNvbWUgY2FzZXMsIGV2ZW4gdGhlIHBvc3Nlc3Npb24gb2Yg YSBjZXJ0YWluIHR5cGUgb2YgZGV2aWNlIGNhbg0KPj5iZQ0KPj4gICAgIGNvbmZpZGVudGlhbCwg ZS5nLiBpbmRpdmlkdWFscyBtaWdodCBub3Qgd2FudCB0byBvdGhlcnMgdG8ga25vdyB0aGF0DQo+ PiAgICAgdGhleSBhcmUgd2VhcmluZyBhIGNlcnRhaW4gbWVkaWNhbCBkZXZpY2UgKHNlZSBTZWN0 aW9uIDIuMykuDQo+DQo+T2theS4NCj4NCj4+DQo+PiBPTEQNCj4+ICAgICBUaGUgcGVyc29uYWwg aGVhbHRoIG1vbml0b3JpbmcgdXNlIGNhc2UgKHNlZSBTZWN0aW9uIDIuMykgaW5kaWNhdGVzDQo+ PiAgICAgdGhlIG5lZWQgZm9yIHNlY3VyZSBhdWRpdCBsb2dzIHdoaWNoIGltcG9zZSBzcGVjaWZp YyByZXF1aXJlbWVudHMgb24NCj4+ICAgICBhIHNvbHV0aW9uLiAgQXVkaXRpbmcgaXMgbm90IGlu IHRoZSBzY29wZSBvZiBBQ0UuICBIb3dldmVyLCBpZiBhbg0KPj4gICAgIGF1dGhvcml6YXRpb24g c29sdXRpb24gcHJvdmlkZXMgbWVhbnMgZm9yIGF1ZGl0IGxvZ3MsIGl0IG11c3QNCj4+ICAgICBj b25zaWRlciB0aGUgaW1wYWN0IG9mIGxvZ2dlZCBkYXRhIGZvciB0aGUgcHJpdmFjeSBvZiB0aGUg cHJpbmNpcGFsDQo+PiAgICAgYW5kIG90aGVyIHBhcnRpZXMgaW52b2x2ZWQuICBTdWl0YWJsZSBt ZWFzdXJlcyBmb3IgcHJvdGVjdGluZyBhbmQNCj4+ICAgICBwdXJnaW5nIHRoZSBsb2dzIG11c3Qg YmUgdGFrZW4gZHVyaW5nIG9wZXJhdGlvbiwgbWFpbnRlbmFuY2UgYW5kDQo+PiAgICAgZGVjb21t aXNzaW9uaW5nIG9mIHRoZSBkZXZpY2UuDQo+PiBORVcNCj4+ICAgICBUaGUgcGVyc29uYWwgaGVh bHRoIG1vbml0b3JpbmcgdXNlIGNhc2UgKHNlZSBTZWN0aW9uIDIuMykgaW5kaWNhdGVzDQo+PiAg ICAgdGhlIG5lZWQgZm9yIHNlY3VyZSBhdWRpdCBsb2dzIHdoaWNoIGltcG9zZSBzcGVjaWZpYyBy ZXF1aXJlbWVudHMgb24NCj4+ICAgICBhIHNvbHV0aW9uLiAgQXVkaXRpbmcgaXMgbm90IGluIHRo ZSBzY29wZSBvZiBBQ0UuICBIb3dldmVyLCBpZiBhbg0KPj4gICAgIGF1dGhvcml6YXRpb24gc29s dXRpb24gcHJvdmlkZXMgbWVhbnMgZm9yIGF1ZGl0IGxvZ3MsIGl0IG11c3QNCj4+ICAgICBjb25z aWRlciB0aGUgaW1wYWN0IG9mIGxvZ2dlZCBkYXRhIGZvciB0aGUgcHJpdmFjeSBvZiBhbGwgcGFy dGllcw0KPj4gaW52b2x2ZWQuDQo+PiAgICAgU3VpdGFibGUgbWVhc3VyZXMgZm9yIHByb3RlY3Rp bmcgYW5kDQo+PiAgICAgcHVyZ2luZyB0aGUgbG9ncyBtdXN0IGJlIHRha2VuIGR1cmluZyBvcGVy YXRpb24sIG1haW50ZW5hbmNlIGFuZA0KPj4gICAgIGRlY29tbWlzc2lvbmluZyBvZiB0aGUgZGV2 aWNlLg0KPg0KPk9rYXkuDQo+DQo+U28gaWYgeW91IGFncmVlIHRvIHRoZSBjaGFuZ2UgaW4gdGhl IGF0dGFjayBzZWN0aW9uIEkgc3VnZ2VzdGVkIGFib3ZlLCBJDQo+d2lsbCB1cGRhdGUgdGhlIGRy YWZ0IGFjY29yZGluZ2x5Lg0KPg0KPkFkZGl0aW9uYWxseSwgSSB3aWxsIGdvIHRocm91Z2ggdGhl IHNlY3Rpb25zIGFuZCByZXBsYWNlIHRoZSB0ZXJtDQo+cHJpbmNpcGFsIHdpdGggdGVybXMgc3Vj aCBhcyAidXNlciIgb3IgImluZGl2aWR1YWwiLg0KPg0KPkkgYXNzdW1lIHRoYXQgd2UgcmVtb3Zl IHRoZSB0ZXJtcyAicmVzb3VyY2UiLCAicmVzb3VyY2Ugc2VydmVyIiwNCj4iY2xpZW50IiwgInJl c291cmNlIG93bmVyIiwgImNsaWVudCBvd25lciIgYW5kICJwcmluY2lwYWwiIGZyb20gdGhlDQo+ dGVybWlub2xvZ3kgc2VjdGlvbj8NCj4NCj5CZXN0IHJlZ2FyZHMsDQo+U3RlZmZpDQoNCg== From nobody Mon Mar 9 08:45: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 ADE2D1A898F for ; Mon, 9 Mar 2015 08:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvcP7sEeTDCK for ; Mon, 9 Mar 2015 08:45:55 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C254F1A9034 for ; Mon, 9 Mar 2015 08:43:06 -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 t29Fh3H3020616 for ; Mon, 9 Mar 2015 16:43:03 +0100 (CET) Received: from [IPv6:2001:638:708:30da:88d7:8f69:3b87:6ed5] (unknown [IPv6:2001:638:708:30da:88d7:8f69:3b87:6ed5]) (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 3l13jM3VLvz2l4q for ; Mon, 9 Mar 2015 16:43:03 +0100 (CET) Message-ID: <54FDBF87.8000102@tzi.de> Date: Mon, 09 Mar 2015 16:43:03 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Ace@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [Ace] Protecting the physical access to a device 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, 09 Mar 2015 15:45:55 -0000 Hi all, while reading through the draft, I stumbled upon the following sentence in the health monitoring use case: "The device includes some authentication mechanism, in order to prevent other persons who get physical access to it from acting as the owner and messing up the access control and security settings." I was wondering whether this sentence intentionally addresses physical access and whether an authentication mechanism can help against physical attacks. If not, we might remove the term "physical" here. What do you think? Best regards, Steffi -- 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 Mon Mar 9 09:28: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 B4E311A6FF0; Mon, 9 Mar 2015 09:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_DOMAIN_NOVOWEL=0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNXc7uK8P6eb; Mon, 9 Mar 2015 09:28:23 -0700 (PDT) Received: from mail.promanage-inc.com (eliasisrael.com [50.47.36.5]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DEDF1A8991; Mon, 9 Mar 2015 09:28:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.promanage-inc.com (Postfix) with ESMTP id 4262B73B1C45; Mon, 9 Mar 2015 09:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at promanage-inc.com Received: from mail.promanage-inc.com ([127.0.0.1]) by localhost (greendome.promanage-inc.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gob_JN_aKbQ9; Mon, 9 Mar 2015 09:28:20 -0700 (PDT) Received: from [192.168.168.101] (unknown [192.168.168.101]) by mail.promanage-inc.com (Postfix) with ESMTPS id 799D473B1C37; Mon, 9 Mar 2015 09:28:20 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=utf-8 From: Eve Maler In-Reply-To: <54BFB249.1060000@sics.se> Date: Mon, 9 Mar 2015 09:28:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54BF8185.9090609@sics.se> <54BFB249.1060000@sics.se> To: Ludwig Seitz X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: core , "ace@ietf.org" Subject: Re: [Ace] Unique resource identifiers 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, 09 Mar 2015 16:28:24 -0000 FYI, a side-effect of the UMA model of enabling loose coupling of a = resource server and authorization server was that the RS has to register = "resource sets" (nominally sets of multiple resources, but in practice = individual resources) and available scopes over them with the AS, so = that the AS can attach authorization policies to them. The act of = registration involves creating a (web) resource on the AS side, for = which the AS ends up assigning a resource ID and sending back an ID in a = Location header. Info on this mechanism is in this spec (which is generic and could be = applied to OAuth and OIDC, as well as UMA): http://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-05 Eve > On 21 Jan 2015, at 6:06 AM, Ludwig Seitz wrote: >=20 > Hello, >=20 > I'm just (re-)thinking the issue of authorization tokens and how to > encode authorization decisions, and the following problem has come up: >=20 > We need to uniquely identify a resource in order to do any kind of > non-local authorization on it. >=20 > At first the obvious approach seemed to be to use Uri-host and = Uri-path > of the origin server, but there are several problems with this: >=20 >=20 > 1.) The origin server might change address, see e.g. > http://www.ietf.org/mail-archive/web/core/current/msg05625.html >=20 > 2.) The resource might not be on the origin server when access control > has to be performed, say e.g. a store-and-forward scenario, or a > publish-subscribe scenario as in > http://tools.ietf.org/html/draft-koster-core-coapmq-00. >=20 > I think we might need some unique resource identifier that is neither > dependent on the host address nor on the internal resource hierarchies > on the origin server. >=20 > The added benefit would be that a proxy could handle encrypted > resource representations, without gaining any knowledge about the > internal resource structure on the origin server. >=20 > What do you think about this issue? >=20 > Regards, >=20 > Ludwig Seitz >=20 > PS: Sorry for cross-posting this to CoRE, but I suspect we might get > some useful input from there. >=20 > --=20 > Ludwig Seitz, PhD > SICS Swedish ICT AB > Ideon Science Park > Building Beta 2 > Scheelev=C3=A4gen 17 > SE-223 70 Lund >=20 > Phone +46(0)70-349 92 51 > http://www.sics.se >=20 >=20 >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl From nobody Mon Mar 9 10:31: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 A1CFC1A8F45 for ; Mon, 9 Mar 2015 10:31:23 -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 9vbxPZpTRrFS for ; Mon, 9 Mar 2015 10:31:22 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CFF61A8BBD for ; Mon, 9 Mar 2015 10:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t29HVImv024352 for ; Mon, 9 Mar 2015 18:31:18 +0100 (CET) Received: from [IPv6:2001:638:708:30da:88d7:8f69:3b87:6ed5] (unknown [IPv6:2001:638:708:30da:88d7:8f69:3b87:6ed5]) (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 3l166G4yFjz2l8P for ; Mon, 9 Mar 2015 18:31:18 +0100 (CET) Message-ID: <54FDD8E6.2020404@tzi.de> Date: Mon, 09 Mar 2015 18:31:18 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Ace@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [Ace] Avoiding fixed client-server settings 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, 09 Mar 2015 17:31:23 -0000 Hi all, The Industrial Control System section still indicates a certain client/server setting. We could resolve this as follows: Old: The main interest of the operator is to ensure the integrity of control messages and sensor readings. The access to some resources needs to be restricted to certain clients, e.g. the operator wants wireless actuators only to accept commands by authorized control units. New: The main interest of the operator is to ensure the integrity of control messages and sensor readings. Access in some cases needs to be restricted, e.g. the operator wants wireless actuators only to accept commands by authorized control units. If you have no objections, we will include this in the next update. Best regards, Steffi -- 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 Mon Mar 9 10:39:10 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F5B1A90B1 for ; Mon, 9 Mar 2015 10:39:08 -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 Dk7_ODRgFwEj for ; Mon, 9 Mar 2015 10:39:07 -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 C3A591A8BBD for ; Mon, 9 Mar 2015 10:39:06 -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 t29Hd3qd009853 for ; Mon, 9 Mar 2015 18:39:03 +0100 (CET) Received: from [IPv6:2001:638:708:30da:88d7:8f69:3b87:6ed5] (unknown [IPv6:2001:638:708:30da:88d7:8f69:3b87:6ed5]) (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 3l16HC2tWHz2l8X for ; Mon, 9 Mar 2015 18:39:03 +0100 (CET) Message-ID: <54FDDAB7.1010500@tzi.de> Date: Mon, 09 Mar 2015 18:39:03 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Ace@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [Ace] New problem summary sections 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, 09 Mar 2015 17:39:08 -0000 Hi all, Please find below the new problem summary sections. Since we want to update the draft before the Internet Draft submission cut-off please respond quickly (until 21:00 UTC) if you have any objections. The problem summary section for the home automation use case was not changed. Health Monitoring: Old: o U3.1 A principal, such as the owner of a health monitoring device, wants to pre-configure access rights to specific data for persons or groups, in the context of an emergency. o U3.2 A principal wants to selectively allow different persons or groups to access medical data. o U3.3 The security measures could affect battery lifetime of the devices and should changes of battery are highly inconvenient. o U3.4 Devices are often used with default access control settings. o U3.5 Principals are often not trained in computer use and especially computer security. o U3.6 Security mechanisms themselves could provide opportunities for denial of service attacks on the device. o U3.7 The device provides a service that can be fatal for the principal if it fails. Accordingly, the principal wants a security mechanism to provide a high level of security. New: * U3.1 The wearer of an eHealth device (John in the example above) wants to pre-configure special access rights in the context of an emergency. * U3.2 The wearer of an eHealth device wants to selectively allow different persons or groups access to medical data. * U3.3 The Security measures could affect battery lifetime of the device and changing the battery is very inconvenient. * U3.4 Devices are often used with default access control settings. * U3.5 Wearers of eHealth devices are often not trained in computer use, and especially computer security. * U3.6 Security mechanisms themselves could provide opportunities for denial of service attacks on the device. * U3.7 The device provides a service that can be fatal for the wearer if it fails. Accordingly, the wearer wants a security mechanism to provide a high level of security. Building Automation: old: o U4.1 Principals want to be able to add a new device to their administrative domain (commissioning). o U4.2 Principals want to be able to integrate a device that formerly belonged to a different administrative domain to their own administrative domain (handover). o U4.3 Principal want to be able to remove a device from their administrative domain (decomissioning). o U4.4 Principals want to be able to delegate selected administration tasks for their devices to others. o U4.5 The principal wants to be able to define context-based Authorization rules. o U4.6 The principal wants to be able to revoke granted permissions and delegations. o U4.7 The principal wants to allow authorized entities to send data to their endpoints (default deny). o U4.8 The principal wants to be able to authorize a device to control several devices at the same time using a multicast protocol. o U4.9 Principals want to be able to interconnect their own subsystems with those from a different operational domain while keeping the control over the authorizations (e.g. granting and revoking permissions) for their endpoints and devices. new: * U4.1 The building owner and the companies want to be able to add new devices to their administrative domain (commissioning). * U4.2 The building owner and the companies want to be able to integrate a device that formerly belonged to a different administrative domain to their own administrative domain (handover). * U4.3 The building owner and the companies want to be able to remove a device from their administrative domain (decomissioning). * U4.4 The building owner and the companies want to be able to delegate selected administration tasks for their devices to others. * U4.5 The building owner and the companies want to be able to define context-based authorization rules. * U4.6 The building owner and the companies want to be able to revoke granted permissions and delegations. * U4.7 The building owner and the companies want to allow authorized entities to send data to their endpoints (default deny). * U4.8 The building owner and the companies want to be able to authorize a device to control several devices at the same time using a multicast protocol. * U4.9 The companies want to be able to interconnect their own subsystems with those from a different operational domain while keeping the control over the authorizations (e.g. granting and revoking permissions) for their endpoints and devices. Smart Metering: * U5.1 Devices are installed in hostile environments where they are physically accessible by attackers. The service operator and the utility company want to make sure that an attacker cannot use a captured device to attack other parts of their infrastructure. * U5.2 The utility company wants to restrict which entities are allowed to send data to their endpoints and to ensure the integrity of the data on their endpoints. * U5.3 The utility company wants to control which entities are allowed to read data on their endpoints and protect such data in transfer. * U5.4 The devices may have intermittent Internet connectivity. * U5.5 Neither the service operator nor the utility company are always present at the time of access and cannot manually intervene in the authorization process. * U5.6 When authorization policies are updated it is impossible, or at least very inefficient to contact all affected endpoints directly. Old: * U5.7 Messages between clients and resource servers may need to be stored and forwarded over multiple nodes. New: * U5.7 Messages between endpoints may need to be stored and forwarded over multiple nodes. Sports and Entertainment: Old: o U6.1 The principal wants to be able to grant access rights dynamically when needed. o U6.2 The principle wants the configuration of access rights to work with very little effort. o U6.3 The principal wants to be able to preconfigure access policies that grant certain access permissions to endpoints with certain attributes (e.g. endpoints of a certain user) without additional configuration effort at the time of access. o U6.4 Principals wants to protect the confidentiality of their data for privacy reasons. o U6.5 Devices might not have an Internet connection at the time of access. New: * U6.1 Sports equipment owners want to be able to grant access rights dynamically when needed. * U6.2 Sports equipment owners want the configuration of access rights to work with very little effort. * U6.3 Sports equipment owners want to be able to preconfigure access policies that grant certain access permissions to endpoints with certain attributes (e.g. endpoints of a certain user) without additional configuration effort at the time of access. * U6.4 Sports equipment owners to protect the confidentiality of their data for privacy reasons. * U6.5 Devices might not have an Internet connection at the time of access. Industrial Control Systems: Old: o U7.1 The principal wants to ensure that only authorized clients can read data from sensors and sent commands to actuators. o U7.2 The principal wants to ensure that data coming from sensors and commands sent to actuators are authentic. o U7.3 Some devices do not have direct Internet connection. o U7.4 Some devices have wired connection while others use wireless. o U7.5 The execution of unauthorized commands in an ICS can lead to significant financial damage, and threaten the availability of critical infrastructure services. Accordingly, the principal wants a security solution that provides a very high level of security. New: * U7.1 The operator of the platform wants to ensure the confidentiality of sensor data and the integrity of actuator data. * U7.2 The operator wants to ensure that data coming from sensors and commands sent to actuators are authentic. * U7.3 Some devices do not have direct Internet connection. * U7.4 Some devices have wired connection while others use wireless. * U7.5 The execution of unauthorized commands in an ICS can lead to significant financial damage, and threaten the availability of critical infrastructure services. Accordingly, the operator wants a security solution that provides a very high level of security. Best regards, Steffi -- 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 Mon Mar 9 11:17: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 0986D1A8894 for ; Mon, 9 Mar 2015 11:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 752mYTNT3Ogk for ; Mon, 9 Mar 2015 11:17:11 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (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 114961A8A4E for ; Mon, 9 Mar 2015 11:16:54 -0700 (PDT) Received: from [192.168.2.49] ([88.235.151.242]) by mrelay.perfora.net (mreueus002) with ESMTPA (Nemesis) id 0Lr0tB-1XraXn0Gt1-00ecmf for ; Mon, 09 Mar 2015 19:16:53 +0100 From: Alper Yegin Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_6B73AB3A-438A-4B3E-97CC-2A0E08262474" Date: Mon, 9 Mar 2015 20:16:46 +0200 In-Reply-To: <54FDDAB7.1010500@tzi.de> To: Ace@ietf.org References: <54FDDAB7.1010500@tzi.de> Message-Id: <4A0F1671-EE4C-427F-BBC5-E9C44DD0CAC0@yegin.org> X-Mailer: Apple Mail (2.1283) X-Provags-ID: V03:K0:82afe5QUpCFPaOJREWwRro8jUK4X5Ds29FA2gUCR8dPhBWAtZHW O7H0GTbP2/XklSwUBIgu9+WOGmesQAaezq5e95uhvxAn7jSmF6xC4bkguB/8iAWe9f04gch YgasEoakfeNkq0Kh7RsVN3P45M8fvC+zGX97YRT8/k0dmFy8ERvoBYiMSVdxS0tnPNhRUqE 9p4CnEP8MUttkablT/cqA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [Ace] ace-usecases-02 comments 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, 09 Mar 2015 18:17:22 -0000 --Apple-Mail=_6B73AB3A-438A-4B3E-97CC-2A0E08262474 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, I've just read the ace-usecases-02 I-D, and here are my comments. Title: ACE use cases It seems the document is more than just description of the use cases. It = includes authorization problems, design considerations (sometimes = reading like requirements), attacks, etc. It'd be better to rename the = document to capture the actual scope. These use cases aim at identifying authorization problems that arise during the lifecycle of a constrained device. Note that this document does not aim at collecting all possible use cases. At times the document also talks about authentication, integrity = protection, and confidentiality. Again, scope is not really limited to = "authorization" only as the aforementioned text states. They are connected to the Internet through an intermediary base-station, using wireless technologies. =20 Later smartphone is given as an example of "access point." It may be = better to replace the term "base-station" with "device, such as = smartphone, access point, or base station." The device includes some authentication mechanism, in order to prevent other persons who get physical access to it from acting as the owner and messing up the access control and security settings. s/authentication/authentication and authorization o U5.6 When authorization policies are updated it is impossible, or at least very inefficient to contact all affected endpoints directly. s/directly/simultaneously?? Due to their limited capabilities, constrained devices appear as the weakest link in the network and hence pose an attractive target for attackers. Physical accessibility is an important factor here too. o Usability is important for all use cases. The configuration of authorization policies as well as the gaining access to devices must be simple for the users of the devices. Special care needs to be taken for home scenarios where access control policies have to be configured by users that are typically not trained in security (see Section 2.2, Section 2.3, Section 2.6). Actually, in addition to the home scenario, sports&entertainment, = personal health care, and even building automation have same kind of = non-techie users involved. Question: is this document supposed to cover the requirements as well, = or will there be a separate document for that? If former, then I think = there's more work needed on the document. Thanks. Alper --Apple-Mail=_6B73AB3A-438A-4B3E-97CC-2A0E08262474 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hello,

I've = just read the ace-usecases-02 I-D, and here are my = comments.

Title: ACE use cases
It seems the document is more than just description of = the use cases. It includes authorization problems, design considerations = (sometimes reading like requirements), attacks, etc. It'd be better to = rename the document to capture the actual scope.

   These use cases = aim at identifying authorization
   problems that arise = during the lifecycle of a constrained device.
   = cases.


At times the document = also talks about authentication, integrity protection, and = confidentiality. Again, scope is not really limited to "authorization" = only as the aforementioned text = states.


   They
   using = wireless technologies.  

Later smartphone is given as an example of "access = point." It may be better to replace the term "base-station" with = "device, such as smartphone, access point, or base = station."

   The device includes some = authentication mechanism, in order to
   prevent other persons who get physical access to it = from acting as
   the owner and messing up the access = control and security settings.

      at least very inefficient to = contact all affected endpoints
      = directly.


   Due to = their
   limited capabilities, constrained = devices appear as the weakest link
   in the network and = hence pose an attractive target for attackers.
Physical accessibility is an important factor = here too.


   o  = Usability is important for all use cases.  The configuration = of
      must be simple for the users = of the devices.  Special care needs
      to be = taken for home scenarios where access control policies have
      security (see Section 2.2, = Section 2.3, Section 2.6).






Alper






Thread-Topic: [Ace] New problem summary sections Thread-Index: AQHQWo/1SdLNXZn7UUS2QWTmWl38y50UfzUA Date: Mon, 9 Mar 2015 18:52:17 +0000 Message-ID: References: <54FDDAB7.1010500@tzi.de> In-Reply-To: <54FDDAB7.1010500@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: <06937DF8DABF9C4F8A79684DFFF50550@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGfG3RvfR678hBpPfmll8/9bDbLHx4l1G ByaPJUt+Mnlse/uVOYApissmJTUnsyy1SN8ugSvjy70mpoJraRX/l59hb2BsSeli5OSQEDCR aHj3nx3CFpO4cG89WxcjF4eQwBFGieapB5ghnEVAzqk3TCBVbAIuEg8aHoHZIgJOEku3/WUB sYUF9CX+/N8A1MABFDeQ+PYjEKLESGLdkhlgJSwCKhKXzy9mBLF5BSwkfh9vArOFBFQlrrfc ARvJKaAmsePAfLA4I9BB30+tAYszC4hL3HoynwniUAGJJXvOM0PYohIvH/9jBbFFBfQkVl5v YoOIK0msPbydBeQcZgFNifW79CHGWEt8nLUOaqSixJTuh+wQ5whKnJz5hGUCo/gsJNtmIXTP QtI9C0n3LCTdCxhZVzGKFqcWF+emGxnppRZlJhcX5+fp5aWWbGIExtrBLb+tdjAefO54iFGA g1GJh7fgyp8QIdbEsuLK3EOM0hwsSuK8dsaHQoQE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUw sszbleL0KO6kdfqm6TYrZv2JKg/8FamVcPDYTWmdMKb4MlntX5tVl24Nry1d/3fbjXOyv47a u06XWfhmUnJvZFO60ILXLuez7RIUZzx88Kx9fczEVXOSgoSXVDkHVSUd+s1x2JG79r9Z3eOz W/Ob/7HbiSzr8Vhsbq0heDhVWmtqyfbm2YkTlViKMxINtZiLihMBOsncs5YCAAA= Archived-At: Subject: Re: [Ace] New problem summary sections 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, 09 Mar 2015 18:52:29 -0000 SGkgU3RlZmZpLA0KDQpUaGlzIGlzIG11Y2ggYmV0dGVyISBBcyB5b3Uga25vdywgSeKAmW0gbm90 IGNvbnZpbmNlZCB0aGF0IGV2ZXJ5dGhpbmcgaXMgaW4NCnNjb3BlIG9mIEFDRSwgYnV0IHRoaXMg dGV4dCBpcyBtdWNoIG1vcmUgcmVhZGFibGUgYW5kIHRyYW5zcGFyZW50IGFuZCB0aHVzDQphbGxv d3MgYW55b25lIHRvIGZvcm0gYW4gb3BpbmlvbiBvbiB0aGUgdG9waWMuDQoNClRoYW5rcw0KR8O2 cmFuDQoNCg0KT24gMjAxNS0wMy0wOSAxODozOSwgIlN0ZWZhbmllIEdlcmRlcyIgPGdlcmRlc0B0 emkuZGU+IHdyb3RlOg0KDQo+SGkgYWxsLA0KPg0KPlBsZWFzZSBmaW5kIGJlbG93IHRoZSBuZXcg cHJvYmxlbSBzdW1tYXJ5IHNlY3Rpb25zLiBTaW5jZSB3ZSB3YW50IHRvDQo+dXBkYXRlIHRoZSBk cmFmdCBiZWZvcmUgdGhlIEludGVybmV0IERyYWZ0IHN1Ym1pc3Npb24gY3V0LW9mZiBwbGVhc2UN Cj5yZXNwb25kIHF1aWNrbHkgKHVudGlsIDIxOjAwIFVUQykgaWYgeW91IGhhdmUgYW55IG9iamVj dGlvbnMuDQo+DQo+DQo+VGhlIHByb2JsZW0gc3VtbWFyeSBzZWN0aW9uIGZvciB0aGUgaG9tZSBh dXRvbWF0aW9uIHVzZSBjYXNlIHdhcyBub3QNCj5jaGFuZ2VkLg0KPg0KPkhlYWx0aCBNb25pdG9y aW5nOg0KPg0KPk9sZDoNCj4NCj4gICBvICBVMy4xIEEgcHJpbmNpcGFsLCBzdWNoIGFzIHRoZSBv d25lciBvZiBhIGhlYWx0aCBtb25pdG9yaW5nIGRldmljZSwNCj4gICAgICAgd2FudHMgdG8gcHJl LWNvbmZpZ3VyZSBhY2Nlc3MgcmlnaHRzIHRvIHNwZWNpZmljIGRhdGEgZm9yIHBlcnNvbnMNCj4g ICAgICAgb3IgZ3JvdXBzLCBpbiB0aGUgY29udGV4dCBvZiBhbiBlbWVyZ2VuY3kuDQo+ICAgIG8g IFUzLjIgQSBwcmluY2lwYWwgd2FudHMgdG8gc2VsZWN0aXZlbHkgYWxsb3cgZGlmZmVyZW50IHBl cnNvbnMgb3INCj4gICAgICAgZ3JvdXBzIHRvIGFjY2VzcyBtZWRpY2FsIGRhdGEuDQo+ICAgIG8g IFUzLjMgVGhlIHNlY3VyaXR5IG1lYXN1cmVzIGNvdWxkIGFmZmVjdCBiYXR0ZXJ5IGxpZmV0aW1l IG9mIHRoZQ0KPiAgICAgICBkZXZpY2VzIGFuZCBzaG91bGQgY2hhbmdlcyBvZiBiYXR0ZXJ5IGFy ZSBoaWdobHkgaW5jb252ZW5pZW50Lg0KPiAgICBvICBVMy40IERldmljZXMgYXJlIG9mdGVuIHVz ZWQgd2l0aCBkZWZhdWx0IGFjY2VzcyBjb250cm9sIHNldHRpbmdzLg0KPiAgICBvICBVMy41IFBy aW5jaXBhbHMgYXJlIG9mdGVuIG5vdCB0cmFpbmVkIGluIGNvbXB1dGVyIHVzZSBhbmQNCj4gICAg ICAgZXNwZWNpYWxseSBjb21wdXRlciBzZWN1cml0eS4NCj4gICAgbyAgVTMuNiBTZWN1cml0eSBt ZWNoYW5pc21zIHRoZW1zZWx2ZXMgY291bGQgcHJvdmlkZSBvcHBvcnR1bml0aWVzDQo+ICAgICAg IGZvciBkZW5pYWwgb2Ygc2VydmljZSBhdHRhY2tzIG9uIHRoZSBkZXZpY2UuDQo+ICAgIG8gIFUz LjcgVGhlIGRldmljZSBwcm92aWRlcyBhIHNlcnZpY2UgdGhhdCBjYW4gYmUgZmF0YWwgZm9yIHRo ZQ0KPiAgICAgICBwcmluY2lwYWwgaWYgaXQgZmFpbHMuICBBY2NvcmRpbmdseSwgdGhlIHByaW5j aXBhbCB3YW50cyBhDQo+ICAgICAgIHNlY3VyaXR5IG1lY2hhbmlzbSB0byBwcm92aWRlIGEgaGln aCBsZXZlbCBvZiBzZWN1cml0eS4NCj4NCj5OZXc6DQo+DQo+KiBVMy4xICBUaGUgd2VhcmVyIG9m IGFuIGVIZWFsdGggZGV2aWNlIChKb2huIGluIHRoZSBleGFtcGxlIGFib3ZlKQ0KPndhbnRzIHRv IHByZS1jb25maWd1cmUgc3BlY2lhbCBhY2Nlc3MgcmlnaHRzIGluIHRoZSBjb250ZXh0IG9mIGFu DQo+ZW1lcmdlbmN5Lg0KPiogVTMuMiBUaGUgd2VhcmVyIG9mIGFuIGVIZWFsdGggZGV2aWNlIHdh bnRzIHRvIHNlbGVjdGl2ZWx5IGFsbG93DQo+ZGlmZmVyZW50IHBlcnNvbnMgb3IgZ3JvdXBzIGFj Y2VzcyB0byBtZWRpY2FsIGRhdGEuDQo+KiBVMy4zIFRoZSBTZWN1cml0eSBtZWFzdXJlcyBjb3Vs ZCBhZmZlY3QgYmF0dGVyeSBsaWZldGltZSBvZiB0aGUgZGV2aWNlDQo+YW5kIGNoYW5naW5nIHRo ZSBiYXR0ZXJ5IGlzIHZlcnkgaW5jb252ZW5pZW50Lg0KPiogVTMuNCBEZXZpY2VzIGFyZSBvZnRl biB1c2VkIHdpdGggZGVmYXVsdCBhY2Nlc3MgY29udHJvbCBzZXR0aW5ncy4NCj4qIFUzLjUgV2Vh cmVycyBvZiBlSGVhbHRoIGRldmljZXMgYXJlIG9mdGVuIG5vdCB0cmFpbmVkIGluIGNvbXB1dGVy IHVzZSwNCj5hbmQgZXNwZWNpYWxseSBjb21wdXRlciBzZWN1cml0eS4NCj4qIFUzLjYgU2VjdXJp dHkgbWVjaGFuaXNtcyB0aGVtc2VsdmVzIGNvdWxkIHByb3ZpZGUgb3Bwb3J0dW5pdGllcyBmb3IN Cj5kZW5pYWwgb2Ygc2VydmljZSBhdHRhY2tzIG9uIHRoZSBkZXZpY2UuDQo+KiBVMy43IFRoZSBk ZXZpY2UgcHJvdmlkZXMgYSBzZXJ2aWNlIHRoYXQgY2FuIGJlIGZhdGFsIGZvciB0aGUgd2VhcmVy IGlmDQo+aXQgZmFpbHMuICBBY2NvcmRpbmdseSwgdGhlIHdlYXJlciB3YW50cyBhIHNlY3VyaXR5 IG1lY2hhbmlzbSB0byBwcm92aWRlDQo+YSBoaWdoIGxldmVsIG9mIHNlY3VyaXR5Lg0KPg0KPg0K PkJ1aWxkaW5nIEF1dG9tYXRpb246DQo+DQo+b2xkOg0KPg0KPiAgICBvICBVNC4xIFByaW5jaXBh bHMgd2FudCB0byBiZSBhYmxlIHRvIGFkZCBhIG5ldyBkZXZpY2UgdG8gdGhlaXINCj4gICAgICAg YWRtaW5pc3RyYXRpdmUgZG9tYWluIChjb21taXNzaW9uaW5nKS4NCj4gICAgbyAgVTQuMiBQcmlu Y2lwYWxzIHdhbnQgdG8gYmUgYWJsZSB0byBpbnRlZ3JhdGUgYSBkZXZpY2UgdGhhdA0KPiAgICAg ICBmb3JtZXJseSBiZWxvbmdlZCB0byBhIGRpZmZlcmVudCBhZG1pbmlzdHJhdGl2ZSBkb21haW4g dG8gdGhlaXINCj4gICAgICAgb3duIGFkbWluaXN0cmF0aXZlIGRvbWFpbiAoaGFuZG92ZXIpLg0K PiAgICBvICBVNC4zIFByaW5jaXBhbCB3YW50IHRvIGJlIGFibGUgdG8gcmVtb3ZlIGEgZGV2aWNl IGZyb20gdGhlaXINCj4gICAgICAgYWRtaW5pc3RyYXRpdmUgZG9tYWluIChkZWNvbWlzc2lvbmlu ZykuDQo+ICAgIG8gIFU0LjQgUHJpbmNpcGFscyB3YW50IHRvIGJlIGFibGUgdG8gZGVsZWdhdGUg c2VsZWN0ZWQNCj4gICAgICAgYWRtaW5pc3RyYXRpb24gdGFza3MgZm9yIHRoZWlyIGRldmljZXMg dG8gb3RoZXJzLg0KPiAgICBvICBVNC41IFRoZSBwcmluY2lwYWwgd2FudHMgdG8gYmUgYWJsZSB0 byBkZWZpbmUgY29udGV4dC1iYXNlZA0KPiAgICAgICBBdXRob3JpemF0aW9uIHJ1bGVzLg0KPiAg ICBvICBVNC42IFRoZSBwcmluY2lwYWwgd2FudHMgdG8gYmUgYWJsZSB0byByZXZva2UgZ3JhbnRl ZCBwZXJtaXNzaW9ucw0KPiAgICAgICBhbmQgZGVsZWdhdGlvbnMuDQo+ICAgbyAgVTQuNyBUaGUg cHJpbmNpcGFsIHdhbnRzIHRvIGFsbG93IGF1dGhvcml6ZWQgZW50aXRpZXMgdG8gc2VuZCBkYXRh DQo+ICAgICAgIHRvIHRoZWlyIGVuZHBvaW50cyAoZGVmYXVsdCBkZW55KS4NCj4gICAgbyAgVTQu OCBUaGUgcHJpbmNpcGFsIHdhbnRzIHRvIGJlIGFibGUgdG8gYXV0aG9yaXplIGEgZGV2aWNlIHRv DQo+ICAgICAgIGNvbnRyb2wgc2V2ZXJhbCBkZXZpY2VzIGF0IHRoZSBzYW1lIHRpbWUgdXNpbmcg YSBtdWx0aWNhc3QNCj4gICAgICAgcHJvdG9jb2wuDQo+ICAgIG8gIFU0LjkgUHJpbmNpcGFscyB3 YW50IHRvIGJlIGFibGUgdG8gaW50ZXJjb25uZWN0IHRoZWlyIG93bg0KPiAgICAgICBzdWJzeXN0 ZW1zIHdpdGggdGhvc2UgZnJvbSBhIGRpZmZlcmVudCBvcGVyYXRpb25hbCBkb21haW4gd2hpbGUN Cj4gICAgICAga2VlcGluZyB0aGUgY29udHJvbCBvdmVyIHRoZSBhdXRob3JpemF0aW9ucyAoZS5n LiBncmFudGluZyBhbmQNCj4gICAgICAgcmV2b2tpbmcgcGVybWlzc2lvbnMpIGZvciB0aGVpciBl bmRwb2ludHMgYW5kIGRldmljZXMuDQo+DQo+bmV3Og0KPg0KPiogVTQuMSBUaGUgYnVpbGRpbmcg b3duZXIgYW5kIHRoZSBjb21wYW5pZXMgd2FudCB0byBiZSBhYmxlIHRvIGFkZCBuZXcNCj5kZXZp Y2VzIHRvIHRoZWlyIGFkbWluaXN0cmF0aXZlIGRvbWFpbiAoY29tbWlzc2lvbmluZykuDQo+KiBV NC4yIFRoZSBidWlsZGluZyBvd25lciBhbmQgdGhlIGNvbXBhbmllcyB3YW50IHRvIGJlIGFibGUg dG8gaW50ZWdyYXRlDQo+YSBkZXZpY2UgdGhhdCBmb3JtZXJseSBiZWxvbmdlZCB0byBhIGRpZmZl cmVudCBhZG1pbmlzdHJhdGl2ZSBkb21haW4gdG8NCj50aGVpciBvd24gYWRtaW5pc3RyYXRpdmUg ZG9tYWluIChoYW5kb3ZlcikuDQo+KiBVNC4zIFRoZSBidWlsZGluZyBvd25lciBhbmQgdGhlIGNv bXBhbmllcyB3YW50IHRvIGJlIGFibGUgdG8gcmVtb3ZlIGENCj5kZXZpY2UgZnJvbSB0aGVpciBh ZG1pbmlzdHJhdGl2ZSBkb21haW4gKGRlY29taXNzaW9uaW5nKS4NCj4qIFU0LjQgVGhlIGJ1aWxk aW5nIG93bmVyIGFuZCB0aGUgY29tcGFuaWVzIHdhbnQgdG8gYmUgYWJsZSB0byBkZWxlZ2F0ZQ0K PnNlbGVjdGVkIGFkbWluaXN0cmF0aW9uIHRhc2tzIGZvciB0aGVpciBkZXZpY2VzIHRvIG90aGVy cy4NCj4qIFU0LjUgVGhlIGJ1aWxkaW5nIG93bmVyIGFuZCB0aGUgY29tcGFuaWVzIHdhbnQgdG8g YmUgYWJsZSB0byBkZWZpbmUNCj4gICBjb250ZXh0LWJhc2VkIGF1dGhvcml6YXRpb24gcnVsZXMu DQo+KiBVNC42IFRoZSBidWlsZGluZyBvd25lciBhbmQgdGhlIGNvbXBhbmllcyB3YW50IHRvIGJl IGFibGUgdG8gcmV2b2tlDQo+Z3JhbnRlZCBwZXJtaXNzaW9ucyBhbmQgZGVsZWdhdGlvbnMuDQo+ KiBVNC43IFRoZSBidWlsZGluZyBvd25lciBhbmQgdGhlIGNvbXBhbmllcyB3YW50IHRvIGFsbG93 IGF1dGhvcml6ZWQNCj5lbnRpdGllcyB0byBzZW5kIGRhdGEgdG8gdGhlaXIgZW5kcG9pbnRzIChk ZWZhdWx0IGRlbnkpLg0KPiogVTQuOCBUaGUgYnVpbGRpbmcgb3duZXIgYW5kIHRoZSBjb21wYW5p ZXMgd2FudCB0byBiZSBhYmxlIHRvIGF1dGhvcml6ZQ0KPmEgZGV2aWNlIHRvIGNvbnRyb2wgc2V2 ZXJhbCBkZXZpY2VzIGF0IHRoZSBzYW1lIHRpbWUgdXNpbmcgYSBtdWx0aWNhc3QNCj5wcm90b2Nv bC4NCj4qIFU0LjkgVGhlIGNvbXBhbmllcyB3YW50IHRvIGJlIGFibGUgdG8gaW50ZXJjb25uZWN0 IHRoZWlyIG93bg0KPnN1YnN5c3RlbXMgd2l0aCB0aG9zZSBmcm9tIGEgZGlmZmVyZW50IG9wZXJh dGlvbmFsIGRvbWFpbiB3aGlsZSBrZWVwaW5nDQo+dGhlIGNvbnRyb2wgb3ZlciB0aGUgYXV0aG9y aXphdGlvbnMgKGUuZy4gZ3JhbnRpbmcgYW5kIHJldm9raW5nDQo+cGVybWlzc2lvbnMpIGZvciB0 aGVpciBlbmRwb2ludHMgYW5kIGRldmljZXMuDQo+DQo+U21hcnQgTWV0ZXJpbmc6DQo+DQo+KiBV NS4xICBEZXZpY2VzIGFyZSBpbnN0YWxsZWQgaW4gaG9zdGlsZSBlbnZpcm9ubWVudHMgd2hlcmUg dGhleSBhcmUNCj5waHlzaWNhbGx5IGFjY2Vzc2libGUgYnkgYXR0YWNrZXJzLiAgVGhlIHNlcnZp Y2Ugb3BlcmF0b3IgYW5kIHRoZQ0KPnV0aWxpdHkgY29tcGFueQl3YW50IHRvIG1ha2Ugc3VyZSB0 aGF0IGFuIGF0dGFja2VyIGNhbm5vdCB1c2UgYSBjYXB0dXJlZA0KPmRldmljZSB0byBhdHRhY2sg b3RoZXIgcGFydHMgb2YgdGhlaXIgaW5mcmFzdHJ1Y3R1cmUuDQo+KiBVNS4yICBUaGUgdXRpbGl0 eSBjb21wYW55IHdhbnRzIHRvIHJlc3RyaWN0IHdoaWNoIGVudGl0aWVzIGFyZSBhbGxvd2VkDQo+ dG8gc2VuZCBkYXRhIHRvIHRoZWlyIGVuZHBvaW50cyBhbmQgdG8gZW5zdXJlIHRoZSBpbnRlZ3Jp dHkgb2YgdGhlIGRhdGENCj5vbiB0aGVpciBlbmRwb2ludHMuCQ0KPiogVTUuMyAgVGhlIHV0aWxp dHkgY29tcGFueSB3YW50cyB0byBjb250cm9sIHdoaWNoIGVudGl0aWVzIGFyZSBhbGxvd2VkDQo+ dG8gcmVhZCBkYXRhIG9uIHRoZWlyIGVuZHBvaW50cyBhbmQgcHJvdGVjdCBzdWNoIGRhdGEgaW4g dHJhbnNmZXIuDQo+KiBVNS40ICBUaGUgZGV2aWNlcyBtYXkgaGF2ZSBpbnRlcm1pdHRlbnQgSW50 ZXJuZXQgY29ubmVjdGl2aXR5Lg0KPiogVTUuNSAgTmVpdGhlciB0aGUgc2VydmljZSBvcGVyYXRv ciBub3IgdGhlIHV0aWxpdHkgY29tcGFueSBhcmUNCj5hbHdheXMgcHJlc2VudAlhdCB0aGUgdGlt ZSBvZiBhY2Nlc3MgYW5kIGNhbm5vdCBtYW51YWxseSBpbnRlcnZlbmUgaW4NCj50aGUgYXV0aG9y aXphdGlvbiBwcm9jZXNzLg0KPiogVTUuNiAgV2hlbiBhdXRob3JpemF0aW9uIHBvbGljaWVzIGFy ZSB1cGRhdGVkIGl0IGlzIGltcG9zc2libGUsIG9yIGF0DQo+bGVhc3QgdmVyeSBpbmVmZmljaWVu dCB0byBjb250YWN0IGFsbCBhZmZlY3RlZCBlbmRwb2ludHMgZGlyZWN0bHkuDQo+DQo+T2xkOg0K Pg0KPiogVTUuNyBNZXNzYWdlcyBiZXR3ZWVuIGNsaWVudHMgYW5kIHJlc291cmNlIHNlcnZlcnMg bWF5IG5lZWQgdG8gYmUNCj5zdG9yZWQgYW5kIGZvcndhcmRlZCBvdmVyIG11bHRpcGxlIG5vZGVz Lg0KPg0KPk5ldzoNCj4NCj4qIFU1LjcgTWVzc2FnZXMgYmV0d2VlbiBlbmRwb2ludHMgbWF5IG5l ZWQgdG8gYmUgc3RvcmVkCWFuZCBmb3J3YXJkZWQNCj5vdmVyIG11bHRpcGxlIG5vZGVzLg0KPg0K PlNwb3J0cyBhbmQgRW50ZXJ0YWlubWVudDoNCj4NCj5PbGQ6DQo+ICAgIG8gIFU2LjEgVGhlIHBy aW5jaXBhbCB3YW50cyB0byBiZSBhYmxlIHRvIGdyYW50IGFjY2VzcyByaWdodHMNCj4gICAgICAg ZHluYW1pY2FsbHkgd2hlbiBuZWVkZWQuDQo+ICAgIG8gIFU2LjIgVGhlIHByaW5jaXBsZSB3YW50 cyB0aGUgY29uZmlndXJhdGlvbiBvZiBhY2Nlc3MgcmlnaHRzIHRvDQo+ICAgICAgIHdvcmsgd2l0 aCB2ZXJ5IGxpdHRsZSBlZmZvcnQuDQo+ICAgIG8gIFU2LjMgVGhlIHByaW5jaXBhbCB3YW50cyB0 byBiZSBhYmxlIHRvIHByZWNvbmZpZ3VyZSBhY2Nlc3MNCj4gICAgICAgcG9saWNpZXMgdGhhdCBn cmFudCBjZXJ0YWluIGFjY2VzcyBwZXJtaXNzaW9ucyB0byBlbmRwb2ludHMgd2l0aA0KPiAgICAg ICBjZXJ0YWluIGF0dHJpYnV0ZXMgKGUuZy4gZW5kcG9pbnRzIG9mIGEgY2VydGFpbiB1c2VyKSB3 aXRob3V0DQo+ICAgICAgIGFkZGl0aW9uYWwgY29uZmlndXJhdGlvbiBlZmZvcnQgYXQgdGhlIHRp bWUgb2YgYWNjZXNzLg0KPiAgICBvICBVNi40IFByaW5jaXBhbHMgd2FudHMgdG8gcHJvdGVjdCB0 aGUgY29uZmlkZW50aWFsaXR5IG9mIHRoZWlyIGRhdGENCj4gICAgICAgZm9yIHByaXZhY3kgcmVh c29ucy4NCj4gICAgbyAgVTYuNSBEZXZpY2VzIG1pZ2h0IG5vdCBoYXZlIGFuIEludGVybmV0IGNv bm5lY3Rpb24gYXQgdGhlIHRpbWUgb2YNCj4gICAgICAgYWNjZXNzLg0KPg0KPk5ldzoNCj4qIFU2 LjEgU3BvcnRzIGVxdWlwbWVudCBvd25lcnMgd2FudCB0byBiZSBhYmxlIHRvIGdyYW50IGFjY2Vz cyByaWdodHMNCj4gICBkeW5hbWljYWxseSB3aGVuIG5lZWRlZC4NCj4qIFU2LjIgU3BvcnRzIGVx dWlwbWVudCBvd25lcnMgd2FudCB0aGUgY29uZmlndXJhdGlvbiBvZiBhY2Nlc3MgcmlnaHRzDQo+ ICAgdG8gd29yayB3aXRoIHZlcnkgbGl0dGxlIGVmZm9ydC4NCj4qIFU2LjMgU3BvcnRzIGVxdWlw bWVudCBvd25lcnMgd2FudCB0byBiZSBhYmxlIHRvIHByZWNvbmZpZ3VyZSBhY2Nlc3MNCj4gICBw b2xpY2llcyB0aGF0IGdyYW50IGNlcnRhaW4gYWNjZXNzIHBlcm1pc3Npb25zIHRvIGVuZHBvaW50 cyB3aXRoDQo+ICAgY2VydGFpbiBhdHRyaWJ1dGVzIChlLmcuIGVuZHBvaW50cyBvZiBhIGNlcnRh aW4gdXNlcikgd2l0aG91dA0KPiAgIGFkZGl0aW9uYWwgY29uZmlndXJhdGlvbiBlZmZvcnQgYXQg dGhlIHRpbWUgb2YgYWNjZXNzLg0KPiogVTYuNCBTcG9ydHMgZXF1aXBtZW50IG93bmVycyB0byBw cm90ZWN0IHRoZSBjb25maWRlbnRpYWxpdHkgb2YgdGhlaXINCj4gICBkYXRhIGZvciBwcml2YWN5 IHJlYXNvbnMuDQo+KiBVNi41IERldmljZXMgbWlnaHQgbm90IGhhdmUgYW4gSW50ZXJuZXQgY29u bmVjdGlvbiBhdCB0aGUgdGltZSBvZg0KPiAgIGFjY2Vzcy4NCj4NCj5JbmR1c3RyaWFsIENvbnRy b2wgU3lzdGVtczoNCj4NCj5PbGQ6DQo+ICAgIG8gIFU3LjEgVGhlIHByaW5jaXBhbCB3YW50cyB0 byBlbnN1cmUgdGhhdCBvbmx5IGF1dGhvcml6ZWQgY2xpZW50cw0KPiAgICAgICBjYW4gcmVhZCBk YXRhIGZyb20gc2Vuc29ycyBhbmQgc2VudCBjb21tYW5kcyB0byBhY3R1YXRvcnMuDQo+ICAgIG8g IFU3LjIgVGhlIHByaW5jaXBhbCB3YW50cyB0byBlbnN1cmUgdGhhdCBkYXRhIGNvbWluZyBmcm9t IHNlbnNvcnMNCj4gICAgICAgYW5kIGNvbW1hbmRzIHNlbnQgdG8gYWN0dWF0b3JzIGFyZSBhdXRo ZW50aWMuDQo+ICAgIG8gIFU3LjMgU29tZSBkZXZpY2VzIGRvIG5vdCBoYXZlIGRpcmVjdCBJbnRl cm5ldCBjb25uZWN0aW9uLg0KPiAgICBvICBVNy40IFNvbWUgZGV2aWNlcyBoYXZlIHdpcmVkIGNv bm5lY3Rpb24gd2hpbGUgb3RoZXJzIHVzZSB3aXJlbGVzcy4NCj4gICAgbyAgVTcuNSBUaGUgZXhl Y3V0aW9uIG9mIHVuYXV0aG9yaXplZCBjb21tYW5kcyBpbiBhbiBJQ1MgY2FuIGxlYWQgdG8NCj4g ICAgICAgc2lnbmlmaWNhbnQgZmluYW5jaWFsIGRhbWFnZSwgYW5kIHRocmVhdGVuIHRoZSBhdmFp bGFiaWxpdHkgb2YNCj4gICAgICAgY3JpdGljYWwgaW5mcmFzdHJ1Y3R1cmUgc2VydmljZXMuICBB Y2NvcmRpbmdseSwgdGhlIHByaW5jaXBhbA0KPiAgICAgICB3YW50cyBhIHNlY3VyaXR5IHNvbHV0 aW9uIHRoYXQgcHJvdmlkZXMgYSB2ZXJ5IGhpZ2ggbGV2ZWwgb2YNCj4gICAgICAgc2VjdXJpdHku DQo+DQo+TmV3Og0KPiogVTcuMSBUaGUgb3BlcmF0b3Igb2YgdGhlIHBsYXRmb3JtIHdhbnRzIHRv IGVuc3VyZSB0aGUNCj4gICBjb25maWRlbnRpYWxpdHkgb2Ygc2Vuc29yIGRhdGEgYW5kIHRoZSBp bnRlZ3JpdHkgb2YgYWN0dWF0b3IgZGF0YS4NCj4qIFU3LjIgVGhlIG9wZXJhdG9yIHdhbnRzIHRv IGVuc3VyZSB0aGF0IGRhdGEgY29taW5nIGZyb20gc2Vuc29ycyBhbmQNCj4gICBjb21tYW5kcyBz ZW50IHRvIGFjdHVhdG9ycyBhcmUgYXV0aGVudGljLg0KPiogVTcuMyBTb21lIGRldmljZXMgZG8g bm90IGhhdmUgZGlyZWN0IEludGVybmV0IGNvbm5lY3Rpb24uDQo+KiBVNy40IFNvbWUgZGV2aWNl cyBoYXZlIHdpcmVkIGNvbm5lY3Rpb24gd2hpbGUgb3RoZXJzIHVzZSB3aXJlbGVzcy4NCj4qIFU3 LjUgVGhlIGV4ZWN1dGlvbiBvZiB1bmF1dGhvcml6ZWQgY29tbWFuZHMgaW4gYW4gSUNTIGNhbiBs ZWFkIHRvDQo+ICAgc2lnbmlmaWNhbnQgZmluYW5jaWFsIGRhbWFnZSwgYW5kIHRocmVhdGVuIHRo ZSBhdmFpbGFiaWxpdHkgb2YNCj4gICBjcml0aWNhbCBpbmZyYXN0cnVjdHVyZSBzZXJ2aWNlcy4g IEFjY29yZGluZ2x5LCB0aGUgb3BlcmF0b3Igd2FudHMgYQ0KPiAgIHNlY3VyaXR5IHNvbHV0aW9u IHRoYXQgcHJvdmlkZXMgYSB2ZXJ5IGhpZ2ggbGV2ZWwgb2Ygc2VjdXJpdHkuDQo+DQo+DQo+QmVz dCByZWdhcmRzLA0KPlN0ZWZmaQ0KPg0KPg0KPi0tIA0KPlN0ZWZhbmllIEdlcmRlcwkJCVRlbDog KzQ5IDQyMSAyMTggNjM5MDYNCj5UWkkgVW5pdmVyc2l0w6R0IEJyZW1lbgkJRS1NYWlsOiBnZXJk ZXNAdHppLmRlDQo+QmlibGlvdGhla3N0ci4gMSwgTVpIIDUxNTANCj4yODM1OSBCcmVtZW4sIEdl cm1hbnkNCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPkFjZSBtYWlsaW5nIGxpc3QNCj5BY2VAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2FjZQ0KDQo= From nobody Mon Mar 9 13:34: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 EA1F01A90D3 for ; Mon, 9 Mar 2015 13:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erOJ2Ng0nKoh for ; Mon, 9 Mar 2015 13:34:20 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 873E41A9029 for ; Mon, 9 Mar 2015 13:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t29KYFmN012206; Mon, 9 Mar 2015 21:34:15 +0100 (CET) Received: from [192.168.1.109] (p57A63B9B.dip0.t-ipconnect.de [87.166.59.155]) (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 3l1B9M1C8Jz2lDh; Mon, 9 Mar 2015 21:34:14 +0100 (CET) Message-ID: <54FE03C6.9050205@tzi.de> Date: Mon, 09 Mar 2015 21:34:14 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Alper Yegin , Ace@ietf.org References: <54FDDAB7.1010500@tzi.de> <4A0F1671-EE4C-427F-BBC5-E9C44DD0CAC0@yegin.org> In-Reply-To: <4A0F1671-EE4C-427F-BBC5-E9C44DD0CAC0@yegin.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ace] ace-usecases-02 comments 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, 09 Mar 2015 20:34:23 -0000 Hi Alper, Thank you for your comments. On 03/09/2015 07:16 PM, Alper Yegin wrote: > Hello, > > I've just read the ace-usecases-02 I-D, and here are my comments. > > Title: ACE use cases > > It seems the document is more than just description of the use cases. It includes authorization problems, design considerations (sometimes reading like requirements), attacks, etc. It'd be better to rename the document to capture the actual scope. > > These use cases aim at identifying authorization > problems that arise during the lifecycle of a constrained device. > Note that this document does not aim at collecting all possible use > cases. The focus of the draft is the description of authorization problems from a user/owner/principal perspective. The listed problems are more useful if we summarize them in the end. That is why we have a part for this in the security summary section. However, the draft is not intended to be a requirements document and I don't think it should be. Summarizing the relevant problems was difficult enough. I can't imagine that we will be able to collect the relevant requirements. Kathleen suggested to add attacks to the security considerations section (cf. http://www.ietf.org/mail-archive/web/ace/current/msg00765.html) > > > At times the document also talks about authentication, integrity protection, and confidentiality. Again, scope is not really limited to "authorization" only as the aforementioned text states. I think it will be difficult to talk about authorization without mentioning integrity and confidentiality since these security objectives are the reason why we need authorization in the first place (see also section 3 of [1]) Authentication and authorization need to work together to be useful as described in section 4 of [1]. [1] https://tools.ietf.org/pdf/draft-gerdes-ace-actors > > > They > are connected to the Internet through an intermediary base-station, > using wireless technologies. > > Later smartphone is given as an example of "access point." It may be better to replace the term "base-station" with "device, such as smartphone, access point, or base station." I don't have a strong opinion on that. > > The device includes some authentication mechanism, in order to > prevent other persons who get physical access to it from acting as > the owner and messing up the access control and security settings. > > s/authentication/authentication and authorization Although some unauthorized entity gets permissions in this case, impersonating as someone else is solved by an authentication solution. Nevertheless, I think that we need both to protect the access control and security settings: An authorization mechanism that makes sure that only authorized entities are able to configure access control and security settings and an authentication mechanism that prevents impersonation. I think we should change the draft accordingly. I am not sure about the physical access part and if an authentication mechanism will help against a physical attack. I think we should replace "physical access" with "access". > > > o U5.6 When authorization policies are updated it is impossible, or > at least very inefficient to contact all affected endpoints > directly. > > s/directly/simultaneously?? The problem that is addressed here is that there are a lot of devices, and that we would need to reach all of them if authorization policies are updated. I don't know if it is necessary to contact them simoultaneously. > > Due to their > limited capabilities, constrained devices appear as the weakest link > in the network and hence pose an attractive target for attackers. > > Physical accessibility is an important factor here too. Yes, it is mentioned in the attacks section. > > > o Usability is important for all use cases. The configuration of > authorization policies as well as the gaining access to devices > must be simple for the users of the devices. Special care needs > to be taken for home scenarios where access control policies have > to be configured by users that are typically not trained in > security (see Section 2.2, Section 2.3, Section 2.6). > > > Actually, in addition to the home scenario, sports&entertainment, personal health care, and even building automation have same kind of non-techie users involved. With home scenarios we meant non-corporate scenarios. Would it help to replace "home scenario" with "non-corporate scenario"? The building automation use case is a bit different because the authorization policies will likely be configured by trained administrators. Best regards, Steffi > > > Question: is this document supposed to cover the requirements as well, or will there be a separate document for that? If former, then I think there's more work needed on the document. > > Thanks. > > Alper > > > > > > > > > > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > From nobody Mon Mar 9 14:46: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 109B41A901F for ; Mon, 9 Mar 2015 14:46:21 -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 qwMI-FJ1-ORH for ; Mon, 9 Mar 2015 14:46:19 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69F221ACD0D for ; Mon, 9 Mar 2015 14:46:19 -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 t29LkFDk021707 for ; Mon, 9 Mar 2015 22:46:15 +0100 (CET) Received: from [192.168.1.109] (p57A63B9B.dip0.t-ipconnect.de [87.166.59.155]) (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 3l1CmR2CLNz2lFW for ; Mon, 9 Mar 2015 22:46:15 +0100 (CET) Message-ID: <54FE14A6.6060803@tzi.de> Date: Mon, 09 Mar 2015 22:46:14 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Ace@ietf.org" References: <20150309212951.13001.12786.idtracker@ietfa.amsl.com> In-Reply-To: <20150309212951.13001.12786.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150309212951.13001.12786.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Ace] Fwd: New Version Notification for draft-ietf-ace-usecases-03.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 21:46:21 -0000 Hi all, We submitted a new version of the use cases draft. The majority of changes were made to focus on the description of authorization problems and remove terminology that might imply certain solutions. Please feel free to comment. Thanks, Steffi -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-ace-usecases-03.txt Date: Mon, 09 Mar 2015 14:29:51 -0700 From: internet-drafts@ietf.org To: Mehdi Mani , Sandeep Kumar , Goeran Selander , Sandeep S. Kumar , Ludwig Seitz , Goran Selander , Stefanie Gerdes , Stefanie Gerdes , Ludwig Seitz , Mehdi Mani A new version of I-D, draft-ietf-ace-usecases-03.txt has been successfully submitted by Stefanie Gerdes and posted to the IETF repository. Name: draft-ietf-ace-usecases Revision: 03 Title: ACE use cases Document date: 2015-03-09 Group: ace Pages: 24 URL: http://www.ietf.org/internet-drafts/draft-ietf-ace-usecases-03.txt Status: https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/ Htmlized: http://tools.ietf.org/html/draft-ietf-ace-usecases-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-ace-usecases-03 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. 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 Mon Mar 9 15:17: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 6CFEE1ACDCB for ; Mon, 9 Mar 2015 15:17: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAMVasfrJW1a for ; Mon, 9 Mar 2015 15:17:28 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (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 72F6A1ACD98 for ; Mon, 9 Mar 2015 15:17:26 -0700 (PDT) Received: from [192.168.2.49] ([88.235.29.144]) by mrelay.perfora.net (mreueus001) with ESMTPA (Nemesis) id 0Lb3jb-1XlKpx0E1p-00keGg; Mon, 09 Mar 2015 23:17:24 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_7F2E056C-30BF-4EDA-983B-FE47E15E158B" From: Alper Yegin In-Reply-To: <54FE03C6.9050205@tzi.de> Date: Tue, 10 Mar 2015 00:17:19 +0200 Message-Id: References: <54FDDAB7.1010500@tzi.de> <4A0F1671-EE4C-427F-BBC5-E9C44DD0CAC0@yegin.org> <54FE03C6.9050205@tzi.de> To: Stefanie Gerdes X-Mailer: Apple Mail (2.1283) X-Provags-ID: V03:K0:NFD2RAXv2SUxS6Oj3h8wf+dG4KfiHHiOGvPQYZDnzGpNjA6TNrj PIs3BH8wwocJvA4IVafpJME3hNCHIrPmf02HHCqieRfNTPTSzpugV4xcaGWVYPQCKrdyDhj K2CZvnrxcQuHnXFQq07DRuUN+tdEdZx7Fc/Krpr1EG636nRHZ/gaVejiGjM4JK5mVmbi1Tu pEPQiSCvhFkl+Qz8j3nrw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: Ace@ietf.org Subject: Re: [Ace] ace-usecases-02 comments 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, 09 Mar 2015 22:17:33 -0000 --Apple-Mail=_7F2E056C-30BF-4EDA-983B-FE47E15E158B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Steffi, On Mar 9, 2015, at 10:34 PM, Stefanie Gerdes wrote: >=20 >>=20 >>=20 >> o U5.6 When authorization policies are updated it is impossible, = or >> at least very inefficient to contact all affected endpoints >> directly. >>=20 >> s/directly/simultaneously?? >=20 > The problem that is addressed here is that there are a lot of devices, = and that we would need to reach all of them if authorization policies = are updated. I don't know if it is necessary to contact them = simultaneously. OK, I'm trying to understand what the issue is. Or, what this text is = really pointing to. Is it implying that, not all affected endpoints need to be contacted? Or, not all affected endpoints need to be contacted directly (i.e., = indirect contact is OK -- and we need to understand what's meant by = that)? I thought the text was trying to say simultaneous contact is not = possible. >>=20 >>=20 >> o Usability is important for all use cases. The configuration of >> authorization policies as well as the gaining access to devices >> must be simple for the users of the devices. Special care = needs >> to be taken for home scenarios where access control policies = have >> to be configured by users that are typically not trained in >> security (see Section 2.2, Section 2.3, Section 2.6). >>=20 >>=20 >> Actually, in addition to the home scenario, sports&entertainment, = personal health care, and even building automation have same kind of = non-techie users involved. >=20 > With home scenarios we meant non-corporate scenarios. Would it help to = replace "home scenario" with "non-corporate scenario"? >=20 > The building automation use case is a bit different because the = authorization policies will likely be configured by trained = administrators. >=20 OK, home scenario is an "example". It's not meant to be provided as an = exclusive list of scenarios. So, an "e.g.," would help in there. Regards, Alper > Best regards, > Steffi >=20 >>=20 >>=20 >> Question: is this document supposed to cover the requirements as = well, or will there be a separate document for that? If former, then I = think there's more work needed on the document. >>=20 >> Thanks. >>=20 >> Alper >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >>=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --Apple-Mail=_7F2E056C-30BF-4EDA-983B-FE47E15E158B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Steffi,

On Mar 9, 2015, at 10:34 PM, Stefanie Gerdes = wrote:



=    o  U5.6 When authorization policies are updated = it is impossible, or
=       at least very inefficient to contact = all affected endpoints
=       directly.

s/directly/simultaneously??

The = problem that is addressed here is that there are a lot of devices, and = that we would need to reach all of them if authorization policies are = updated. I don't know if it is necessary to contact them = simultaneously.

OK, I'm trying = to understand what the issue is. Or, what this text is really pointing = to.
Is it implying that, not all affected endpoints need to be = contacted?
Or, not all affected endpoints need to be contacted = directly (i.e., indirect contact is OK -- and we need to understand = what's meant by that)?
I thought the text was trying to say = simultaneous contact is not possible.



=    o  Usability is important for all use cases. =  The configuration of
=       authorization policies as well as = the gaining access to devices
=       must be simple for the users of the = devices.  Special care needs
      to be taken for home = scenarios where access control policies have
      to be configured by = users that are typically not trained in
      security (see Section = 2.2, Section 2.3, Section 2.6).


Actually, in = addition to the home scenario, sports&entertainment, personal health = care, and even building automation have same kind of non-techie users = involved.

With home scenarios we meant non-corporate = scenarios. Would it help to replace "home scenario" with "non-corporate = scenario"?

The building automation use case is a bit different = because the authorization policies will likely be configured by trained = administrators.


OK, home = scenario is an "example". It's not meant to be provided as an exclusive = list of scenarios. So, an "e.g.," would help in = there.

Regards,

Alper



Best = regards,
Steffi



Question: is = this document supposed to cover the requirements as well, or will there = be a separate document for that? If former, then I think there's more = work needed on the document.

Thanks.

Alper












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


_______________________________________= ________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mail= man/listinfo/ace

= --Apple-Mail=_7F2E056C-30BF-4EDA-983B-FE47E15E158B-- From nobody Mon Mar 9 18:15:10 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 045761AC3D1; Mon, 9 Mar 2015 14:29:53 -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 zQ1ysIrSkeNg; Mon, 9 Mar 2015 14:29:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E5B1A90FF; Mon, 9 Mar 2015 14:29:51 -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: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309212951.13001.62119.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 14:29:51 -0700 Archived-At: X-Mailman-Approved-At: Mon, 09 Mar 2015 18:15:09 -0700 Cc: ace@ietf.org Subject: [Ace] I-D Action: draft-ietf-ace-usecases-03.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 21:29:53 -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-03.txt Pages : 24 Date : 2015-03-09 Abstract: Constrained devices are nodes with limited processing power, storage space and transmission capacities. These devices in many cases do not provide user interfaces and are often intended to interact without human intervention. This document 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: http://tools.ietf.org/html/draft-ietf-ace-usecases-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ace-usecases-03 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 Mar 10 05:14: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 6BEE31AC529 for ; Tue, 10 Mar 2015 05:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 1MNz8p4LlKDa for ; Tue, 10 Mar 2015 05:14:52 -0700 (PDT) Received: from outbox.sics.se (outbox.sics.se [193.10.64.137]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF481A883B for ; Tue, 10 Mar 2015 05:14:52 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [192.36.171.201]) by outbox.sics.se (Postfix) with ESMTPS id 24DA951 for ; Tue, 10 Mar 2015 13:14:50 +0100 (CET) Received: from norm.sics.se (norm.sics.se [193.10.64.192]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id t2ACEnVE013953 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 10 Mar 2015 13:14:49 +0100 Received: from [192.168.0.108] (unknown [85.235.11.178]) by norm.sics.se (Postfix) with ESMTPSA id C0A7B26A for ; Tue, 10 Mar 2015 13:14:49 +0100 (CET) Message-ID: <54FEE038.9040401@sics.se> Date: Tue, 10 Mar 2015 13:14:48 +0100 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: ace@ietf.org References: <54FDDAB7.1010500@tzi.de> <4A0F1671-EE4C-427F-BBC5-E9C44DD0CAC0@yegin.org> <54FE03C6.9050205@tzi.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020103030000030009070701" X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sics-se:default, sics-se:default, base:default, @@RPTN) X-p0f-Info: os=Linux 2.2.x-3.x, link=Ethernet or modem X-CanIt-Geo: =?UTF-8?Q?ip=3D85.235.11.178; _country=3DSE; _region=3DSk=C3=A5ne; _city=3DLund; _latitude=3D55.7028; _longitude=3D13.1927; _http://maps.google.com/maps=3Fq=3D55.7028,13.1927&z=3D6?= X-CanItPRO-Stream: outbound-sics-se:outbound (inherits from outbound-sics-se:default, sics-se:default, base:default) X-Canit-Stats-ID: 09O1MeNmO - d84f2c3c6641 - 20150310 (trained as not-spam) X-Antispam-Training-Forget: https://canit.sunet.se/canit/b.php?i=09O1MeNmO&m=d84f2c3c6641&t=20150310&c=f X-Antispam-Training-Nonspam: https://canit.sunet.se/canit/b.php?i=09O1MeNmO&m=d84f2c3c6641&t=20150310&c=n X-Antispam-Training-Spam: https://canit.sunet.se/canit/b.php?i=09O1MeNmO&m=d84f2c3c6641&t=20150310&c=s X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 85.235.11.178 is neither permitted nor denied by domain ludwig@sics.se) receiver=e-mailfilter01.sunet.se; client-ip=85.235.11.178; envelope-from=; helo=norm.sics.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: Subject: Re: [Ace] ace-usecases-02 comments 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, 10 Mar 2015 12:14:57 -0000 This is a cryptographically signed message in MIME format. --------------ms020103030000030009070701 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 03/09/2015 11:17 PM, Alper Yegin wrote: > Hi Steffi, > > On Mar 9, 2015, at 10:34 PM, Stefanie Gerdes wrote: >> >>> >>> >>> o U5.6 When authorization policies are updated it is impossible, = or >>> at least very inefficient to contact all affected endpoints >>> directly. >>> >>> s/directly/simultaneously?? >> >> The problem that is addressed here is that there are a lot of devices,= >> and that we would need to reach all of them if authorization policies >> are updated. I don't know if it is necessary to contact them >> simultaneously. > > OK, I'm trying to understand what the issue is. Or, what this text is > really pointing to. > Is it implying that, not all affected endpoints need to be contacted? It is implying that it is a problem if all affected endpoints need to be = contacted every time an authorization policy changes. So 'directly' was meant to express some close temporal relation between=20 the update of authorization policies and the need to contact all=20 affected endpoints. Perhaps this warrants a clarification in the draft? 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 --------------ms020103030000030009070701 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVDCC BhgwggUAoAMCAQICAwyGmDANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTE1MDEwODA4MzkwNloXDTE2MDEwOTIyNDEzMFowODEXMBUGA1UE AwwObHVkd2lnQHNpY3Muc2UxHTAbBgkqhkiG9w0BCQEWDmx1ZHdpZ0BzaWNzLnNlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxUHisC6rgXFsBHHBGo8ulz/cLX3gX5Ufhcwo rp+7djzMMuKPM1KOHq0bjWhmFe8ly8CzWdk2NS600t7IEBQWJiHLsdc12UqmNswQUpD7oqkR 1nRGT6leAHYTWapkR+nczZ2NxD+H7u4ZWVIZg0DFiTqtY8ghYHHYYy8BBoc/jHG78X4+JJAg s5XOa0gVl7W38vDvVpo14xhWEBGjzPk9WxWirqAF66PF+JEu2JD9LzFbpEq829SRXJMFB9wp oQNlH0UQ01/2sWCIBxPpHuEjxEF/V3Z/F2VsNTy4zvYrd+/MYO3w30F+bWQNZsMHEkTW1pEh iz7rQPWTBXoO8Fv0wQIDAQABo4IC1DCCAtAwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTqvKspqEm0E4R1sgsABYKk 6xDJqDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZBgNVHREEEjAQgQ5sdWR3 aWdAc2ljcy5zZTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcC AjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0 aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5 aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQEFBQADggEBAGXwFsbSfv4mMWqIk64CoxuR6ozo7J37igca7d9tpKIzVIp6xp7Zt+a+J9X3 1r4zgMRFnZJWQ5hy82W/fVDeG9i3NGMM6p7DNUrGjTbVHd11BQtbUOG9MSlyWKQbmt3Q1ElC f4SRLAQot5SPryLR2FTxQuFkMOrcDzVxNxnMgatOM2fAO8KS0H+wX+I7gC3pEnbg/eMqNgU+ Ktbc2y9naDNmLNLN65s8TT9xZyoQEn9S1oU8Xnh596OMu49Eccws8Ny+vAGESIHG4bqhMSjj rmDilL1Wj9nQahmBnID5oZD5g9s9KyqxiZIGNnowYYOpCrSeITZ1b7wg50dC8ySojnYwggY0 MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEw MjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0d Lep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiU fsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5Dp IpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuC YKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/ MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0j BBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzAB hhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nm c2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9 eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukD FUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyi kfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8Cnykh ExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b 970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCD z+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqA SfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNb BIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBth HSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+ UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAwyGmDAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTAzMTAxMjE0NDhaMCMGCSqGSIb3DQEJBDEW BBS0Ea7UN8+OOT6fj30P4PA/G7RQSDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDDIaYMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJKoZIhvcNAQEBBQAE ggEAX27iEUIhwY1oQyuCvEfcJ7PVZJwmLvmMVlcivi7T9XWE9rDZC22pvaWgpCT5jPJw85SP P+5677fLyDLq/MYSLb9MRZLNKZlrDeFYrCFdtLR3FXcUF0a83NGgrHAcouYDYkFL2BEwKudS R+ZN3bc/F053zWR+wFsC9CVPapeH4scBRTEVxTrs6ZN1p+CRb4yG/93U8YxoL61NFlb0lRTK R0Urkp+1ksRxP89SN7tOAFPiKEEcgukt6cJj2c3pjQ9WpN69NucVzG9aA3Dc2+X1qE6482Zv iLCC2bdv+lkfxHTcmMo+Z5H87RYEZD9d7kMoFDUIkbCGTyj4/f+70E/mJAAAAAAAAA== --------------ms020103030000030009070701-- From nobody Tue Mar 10 05:57: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 78CCA1A885A for ; Tue, 10 Mar 2015 05:57:57 -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 eNp-BJB67g9f for ; Tue, 10 Mar 2015 05:57: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 423941A885F for ; Tue, 10 Mar 2015 05:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t2ACvm7H026675; Tue, 10 Mar 2015 13:57:48 +0100 (CET) Received: from [IPv6:2001:638:708:30da:cd03:a858:fef9:e30f] (unknown [IPv6:2001:638:708:30da:cd03:a858:fef9:e30f]) (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 3l1c0D3dFcz2kCY; Tue, 10 Mar 2015 13:57:48 +0100 (CET) Message-ID: <54FEEA4C.60008@tzi.de> Date: Tue, 10 Mar 2015 13:57:48 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ludwig Seitz , ace@ietf.org References: <54FDDAB7.1010500@tzi.de> <4A0F1671-EE4C-427F-BBC5-E9C44DD0CAC0@yegin.org> <54FE03C6.9050205@tzi.de> <54FEE038.9040401@sics.se> In-Reply-To: <54FEE038.9040401@sics.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ace] ace-usecases-02 comments 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, 10 Mar 2015 12:57:57 -0000 On 03/10/2015 01:14 PM, Ludwig Seitz wrote: > On 03/09/2015 11:17 PM, Alper Yegin wrote: >> Hi Steffi, >> >> On Mar 9, 2015, at 10:34 PM, Stefanie Gerdes wrote: >>> >>>> >>>> >>>> o U5.6 When authorization policies are updated it is impossible, or >>>> at least very inefficient to contact all affected endpoints >>>> directly. >>>> >>>> s/directly/simultaneously?? >>> >>> The problem that is addressed here is that there are a lot of devices, >>> and that we would need to reach all of them if authorization policies >>> are updated. I don't know if it is necessary to contact them >>> simultaneously. >> >> OK, I'm trying to understand what the issue is. Or, what this text is >> really pointing to. >> Is it implying that, not all affected endpoints need to be contacted? > > It is implying that it is a problem if all affected endpoints need to be > contacted every time an authorization policy changes. > > So 'directly' was meant to express some close temporal relation between > the update of authorization policies and the need to contact all > affected endpoints. > > Perhaps this warrants a clarification in the draft? Maybe we should describe the underlying problem a bit more. As far as I understand it, the problem is that we need to make sure that a device can enforce the new authorization policies. Therefore it must know at the time of a new request what the new authorization policies are. One way to solve this would be to provide the update of the authorization policies to all devices as fast as possible. But this might be impossible or very inefficient. It might be good to point this out more clearly. Best regards, Steffi From nobody Tue Mar 10 06:25:55 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF451B2A52 for ; Tue, 10 Mar 2015 06:25:54 -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 0cSkQcJW7zkx for ; Tue, 10 Mar 2015 06:25:53 -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 673891B2A53 for ; Tue, 10 Mar 2015 06:25:32 -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 t2ADPTgM002085 for ; Tue, 10 Mar 2015 14:25:29 +0100 (CET) Received: from [IPv6:2001:638:708:30da:cd03:a858:fef9:e30f] (unknown [IPv6:2001:638:708:30da:cd03:a858:fef9:e30f]) (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 3l1cc9258tz2kF5 for ; Tue, 10 Mar 2015 14:25:29 +0100 (CET) Message-ID: <54FEF0C9.30005@tzi.de> Date: Tue, 10 Mar 2015 14:25:29 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Ace@ietf.org" References: <20150309234920.12025.44848.idtracker@ietfa.amsl.com> In-Reply-To: <20150309234920.12025.44848.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150309234920.12025.44848.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Ace] Fwd: New Version Notification for draft-gerdes-ace-actors-03.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, 10 Mar 2015 13:25:54 -0000 Hi all, Please find attached the new version notification for the actors draft. The main changes are: - To address comments (e.g., in the ACE session in Honolulu) OAuth terminology was removed to avoid misunderstandings. - The term "owner" was replaced since comments on the list indicated that owner might not be a suitable term. - A section about autonomous communication was added to point out that there is not always an active user in constrained environments, and devices need to be able to enforce the user's security policies autonomously. Comments are very welcome. Thanks, Steffi -------- Forwarded Message -------- Subject: New Version Notification for draft-gerdes-ace-actors-03.txt Date: Mon, 09 Mar 2015 16:49:20 -0700 From: internet-drafts@ietf.org To: Stefanie Gerdes , Stefanie Gerdes A new version of I-D, draft-gerdes-ace-actors-03.txt has been successfully submitted by Stefanie Gerdes and posted to the IETF repository. Name: draft-gerdes-ace-actors Revision: 03 Title: Actors in the ACE Architecture Document date: 2015-03-09 Group: Individual Submission Pages: 26 URL: http://www.ietf.org/internet-drafts/draft-gerdes-ace-actors-03.txt Status: https://datatracker.ietf.org/doc/draft-gerdes-ace-actors/ Htmlized: http://tools.ietf.org/html/draft-gerdes-ace-actors-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-gerdes-ace-actors-03 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. Based on the tasks, an architecture is developed to represent the relationships between the logical functional entities involved. 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 Mar 10 06:38: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 35F631A8900 for ; Tue, 10 Mar 2015 06:38:04 -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 ILK87u10Itdy for ; Tue, 10 Mar 2015 06:38: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 DF5D51A887C for ; Tue, 10 Mar 2015 06:37: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 t2ADbXs1027867 for ; Tue, 10 Mar 2015 14:37:33 +0100 (CET) Received: from [IPv6:2001:638:708:30da:cd03:a858:fef9:e30f] (unknown [IPv6:2001:638:708:30da:cd03:a858:fef9:e30f]) (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 3l1ct54Gn5z2kFd for ; Tue, 10 Mar 2015 14:37:33 +0100 (CET) Message-ID: <54FEF39D.6070305@tzi.de> Date: Tue, 10 Mar 2015 14:37:33 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Ace@ietf.org" References: <20150309235613.28208.14389.idtracker@ietfa.amsl.com> In-Reply-To: <20150309235613.28208.14389.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150309235613.28208.14389.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Ace] Fwd: New Version Notification for draft-gerdes-ace-a2a-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, 10 Mar 2015 13:38:04 -0000 Hi all, Please find attached the new version notification for a new draft called "Managing the authorization to authorize in the lifecycle of a constrained device". The draft describes how the authorization to authorize can be managed, e.g., how it is transferred to a new principal, and what steps are required to securely decommission a device. Comments are very welcome. Best regards, Steffi -------- Forwarded Message -------- Subject: New Version Notification for draft-gerdes-ace-a2a-00.txt Date: Mon, 09 Mar 2015 16:56:13 -0700 From: internet-drafts@ietf.org To: Stefanie Gerdes , Stefanie Gerdes A new version of I-D, draft-gerdes-ace-a2a-00.txt has been successfully submitted by Stefanie Gerdes and posted to the IETF repository. Name: draft-gerdes-ace-a2a Revision: 00 Title: Managing the Authorization to Authorize in the Lifecycle of a Constrained Device Document date: 2015-03-09 Group: Individual Submission Pages: 7 URL: http://www.ietf.org/internet-drafts/draft-gerdes-ace-a2a-00.txt Status: https://datatracker.ietf.org/doc/draft-gerdes-ace-a2a/ Htmlized: http://tools.ietf.org/html/draft-gerdes-ace-a2a-00 Abstract: Constrained nodes are 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. During the lifecycle of a constrained device, responsibility for managing authorization policies for the constrained device may change several times. To ensure the security of the constrained devices, the authorization to authorize must be transferred to the new principal in a secure way. The Delegated CoAP Authorization Framework (DCAF) specifies how resource-constrained nodes can delegate defined authentication- and authorization-related tasks to less-constrained devices called Authorization Managers, thus limiting the hardware requirements of the security solution for the constrained devices. This document defines how DCAF can be used to manage the Authorization Manager of a constrained device and introduces a flexible authorization solution for the whole lifecycle of a constrained device. 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 Mar 10 07:41: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 22DD31A8853 for ; Tue, 10 Mar 2015 07:41: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 lzhTHvXtAo3j for ; Tue, 10 Mar 2015 07:41:24 -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 32F121A87ED for ; Tue, 10 Mar 2015 07:41:24 -0700 (PDT) X-AuditID: c1b4fb3a-f79036d000001e94-f9-54ff02924b42 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 5A.1F.07828.2920FF45; Tue, 10 Mar 2015 15:41:22 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.70]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0210.002; Tue, 10 Mar 2015 15:41:21 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "Ace@ietf.org" Thread-Topic: New version of Object Security for CoAP Thread-Index: AQHQW0BGMNNYIYnl2USiI7AxgHo1yg== Date: Tue, 10 Mar 2015 14:41:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="utf-8" Content-ID: <0B00D5422F0A1A4BA4ED8D767E13B3BF@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvje4kpv8hBlsOCFt8/9bD7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujKdXXjEWLBOvWLZzMlMD4w2xLkZODgkBE4mVE1exQdhiEhfu rQeyuTiEBI4wSjyaOocRwlnMKLFszwRGkCo2AReJBw2PmEBsEQFFiUV3LrGA2MICBhJ3Xh1g 7WLkAIqbShyf5ApRoidx6/gUdhCbRUBV4s3XOywgJbwCFhILfoCVMALt/X5qDdhEZgFxiVtP 5jNB3CMgsWTPeWYIW1Ti5eN/rCC2KNDIldeb2EDGSAgoSUzbmgZiMgtoSqzfpQ8xxVri5M4P zBC2osSU7odgB/AKCEqcnPmEZQKj6Cwky2YhdM9C0j0LSfcsJN0LGFlXMYoWpxYX56YbGeml FmUmFxfn5+nlpZZsYgTGyMEtv612MB587niIUYCDUYmH1yDuX4gQa2JZcWXuIUZpDhYlcV47 40MhQgLpiSWp2ampBalF8UWlOanFhxiZODilGhhTxXQnlN8ISX4c7dAolG+72inL7PdPg5/M ybPnlR/cUptclz0z7dWSqPdzLF/ce2HV/XHGW38BZ3MP2YkiJXJlbFdOblB3uPJCR/Vu1fTv UuEOK9X/mM49+jt7Td/Ke9W6jqEfpjYcEQyf4ZhhlJi/4ktiYsO5lbvkElN63bXav2QcXb0w xEaJpTgj0VCLuag4EQDh7pRZcgIAAA== Archived-At: Subject: [Ace] New version of Object Security for CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 14:41:27 -0000 SGkgYWxsLA0KDQpZZXN0ZXJkYXkgd2UgdXBsb2FkZWQgYW4gdXBkYXRlZCBkcmFmdCAoLTAxKSBv biBvYmplY3Qgc2VjdXJpdHkgZm9yIENvQVAuDQoNClRoZSAwMC12ZXJzaW9uIGRlc2NyaWJlZCBh IG5ldyBDb0FQIG9wdGlvbiBmb3Igc2lnbmF0dXJlcywgY29udGFpbmluZw0KZXNzZW50aWFsbHkg YSBKV1Mtd3JhcHBpbmcgb2YgdGhlIENvQVAgbWVzc2FnZSwgZXh0ZW5kZWQgd2l0aCBzZXF1ZW5j ZQ0KbnVtYmVycyBmb3IgcmVwbGF5IHByb3RlY3Rpb24uDQoNCkluIHRoZSAwMS12ZXJzaW9uLCB0 aGlzIGlzIGV4dGVuZGVkIGJ5Og0KLSBhZGRpbmcgYSBuZXcgQ29BUCBvcHRpb24gZm9yIGVuY3J5 cHRpb24sIGhhbmRsaW5nIGUuZy4gSldFLXdyYXBwaW5nDQotIGNvbnNpZGVyaW5nIG90aGVyIG1l c3NhZ2UgZm9ybWF0cywgaW5jbHVkaW5nIGUuZy4gQ09TRQ0KLSBwcm92aWRpbmcgZXN0aW1hdGVz IG9mIHNpemVzIG9mIGRpZmZlcmVudCBtZXNzYWdlIGZvcm1hdHMNCi0gYWRkaW5nIGEgbmV3ICJt b2RlIiBmb3IgYXBwbGljYXRpb24gbGF5ZXIgcHJvdGVjdGlvbiwgdXNpbmcgYSBnaXZlbg0KbWVz c2FnZSBmb3JtYXQNCg0KVGhlcmUgYXJlIGV4YW1wbGVzLCBpbiBzZWN0aW9uIDIgaWxsdXN0cmF0 aW5nIHRoZSBuZWVkIGZvciBlbmQtdG8tZW5kDQpzZWN1cml0eSBvbiBDb0FQIG1lc3NhZ2VzIGFu ZCBvbiBhcHBsaWNhdGlvbiBsYXllciwgYW5kIGluIEFwcGVuZGl4IEQNCnNob3dpbmcgaG93IHRo aXMgc29sdXRpb24gY291bGQgYmUgYXBwbGllZC4NCg0KQ29tbWVudHMgYXJlIGFwcHJlY2lhdGVk LiBIZXJlIGlzIHRoZSBkcmFmdDoNCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtc2VsYW5kZXItYWNlLW9iamVjdC1zZWN1cml0eS0wMS50DQp4dA0KDQoNCg0KQmVz dCByZWdhcmRzLA0KR8O2cmFuDQoNCg0KDQoNCg0KDQoNCk9uIDIwMTUtMDMtMDkgMjA6NTUsICJp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQp3cm90 ZToNCg0KPg0KPkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1zZWxhbmRlci1hY2Utb2JqZWN0 LXNlY3VyaXR5LTAxLnR4dA0KPmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTHVk d2lnIFNlaXR6IGFuZCBwb3N0ZWQgdG8gdGhlDQo+SUVURiByZXBvc2l0b3J5Lg0KPg0KPk5hbWU6 CQlkcmFmdC1zZWxhbmRlci1hY2Utb2JqZWN0LXNlY3VyaXR5DQo+UmV2aXNpb246CTAxDQo+VGl0 bGU6CQlNYXJjaCA5LCAyMDE1DQo+RG9jdW1lbnQgZGF0ZToJMjAxNS0wMy0wOQ0KPkdyb3VwOgkJ SW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+UGFnZXM6CQkzNg0KPlVSTDogICAgICAgICAgICANCj5o dHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1zZWxhbmRlci1hY2Utb2Jq ZWN0LXNlY3VyaXR5LTAxLg0KPnR4dA0KPlN0YXR1czogICAgICAgICANCj5odHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zZWxhbmRlci1hY2Utb2JqZWN0LXNlY3VyaXR5Lw0K Pkh0bWxpemVkOiAgICAgICANCj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zZWxh bmRlci1hY2Utb2JqZWN0LXNlY3VyaXR5LTAxDQo+RGlmZjogICAgICAgICAgIA0KPmh0dHA6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXNlbGFuZGVyLWFjZS1vYmplY3Qtc2VjdXJp dHktMDENCj4NCj5BYnN0cmFjdDoNCj4gICBUaGlzIG1lbW8gcHJlc2VudHMgYSBzY2hlbWUgZm9y IGRhdGEgb2JqZWN0IHNlY3VyaXR5IGFwcGxpY2FibGUgdG8NCj4gICBwcm90ZWN0aW9uIG9mIHBh eWxvYWQgb2YgZ2VuZXJpYyBtZXNzYWdlIGZvcm1hdHMgYXMgd2VsbCBhcyByZXF1ZXN0DQo+ICAg YW5kIHJlc3BvbnNlIG1lc3NhZ2VzIG9mIHRoZSBDb25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90 b2NvbCAoQ29BUCkuDQo+DQo+ICAgICAgICAgICAgICAgICAgDQo+ICAgICAgICANCj4NCj4NCj5Q bGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUg dGltZSBvZg0KPnN1Ym1pc3Npb24NCj51bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlm ZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPg0KPlRoZSBJRVRGIFNlY3JldGFy aWF0DQo+DQoNCg== From nobody Tue Mar 10 10:53: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 6EAAF1A0046 for ; Tue, 10 Mar 2015 10:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_DOMAIN_NOVOWEL=0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fY7H7XAbWmw8 for ; Tue, 10 Mar 2015 10:53:07 -0700 (PDT) Received: from mail.promanage-inc.com (eliasisrael.com [50.47.36.5]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25CF61A001D for ; Tue, 10 Mar 2015 10:53:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.promanage-inc.com (Postfix) with ESMTP id 2FBE673D30DD; Tue, 10 Mar 2015 10:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at promanage-inc.com Received: from mail.promanage-inc.com ([127.0.0.1]) by localhost (greendome.promanage-inc.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIwZVBt2Uab8; Tue, 10 Mar 2015 10:53:05 -0700 (PDT) Received: from [192.168.168.101] (unknown [192.168.168.101]) by mail.promanage-inc.com (Postfix) with ESMTPS id 7F95673D30D3; Tue, 10 Mar 2015 10:53:05 -0700 (PDT) From: Eve Maler Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Mar 2015 10:53:05 -0700 To: ace@ietf.org Message-Id: <59F1C792-B108-4DEC-8B5F-94CA8DC19BF8@xmlgrrl.com> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [Ace] New doc: draft-maler-ace-oauth-uma-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 17:53:08 -0000 Hi all, Hannes, Erik, Samuel, and I worked on a new discussion document that = gives insight into the ways in which OAuth and UMA could be used towards = IoT requirements for authentication and authorization: http://tools.ietf.org/html/draft-maler-ace-oauth-uma-00 Quoting the abstract: Authentication and authorization are fundamental security features used in Internet and Web applications. Providing the same level of security functionality to the Internet of Things (IoT) environment as well is a logical enhancement and reduces the risk of unauthorized access to personal data. IoT devices, however, have limitations in terms of processing power, memory, user interface, Internet connectivity, etc. Since many use cases span Web and IoT environments and the question of "Web" vs. "IoT" can in some cases be considered a continuum, it is required to find security solutions that can accommodate the capabilities and constraints of both environments without significant compromises. Thus, an approach of adapting already standardized and deployed authentication and authorization technologies is worth examining. This document describes how the Web Authorization Protocol (OAuth) in combination with User-Managed Access (UMA) can be used for an IoT environment to bring Web-scale authorization services to the IoT world. Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl From nobody Wed Mar 11 06:03: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 A6EA71A8A09 for ; Wed, 11 Mar 2015 06:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 r5eFYdQ6_DMM for ; Wed, 11 Mar 2015 06:02:57 -0700 (PDT) Received: from outbox.sics.se (outbox.sics.se [193.10.64.137]) by ietfa.amsl.com (Postfix) with ESMTP id EA4701A8799 for ; Wed, 11 Mar 2015 06:02:56 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [192.36.171.201]) by outbox.sics.se (Postfix) with ESMTPS id 9544313A for ; Wed, 11 Mar 2015 14:02:54 +0100 (CET) Received: from norm.sics.se (norm.sics.se [193.10.64.192]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id t2BD2sMq004440 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 11 Mar 2015 14:02:54 +0100 Received: from [192.168.0.108] (unknown [85.235.11.178]) by norm.sics.se (Postfix) with ESMTPSA id 37F80278 for ; Wed, 11 Mar 2015 14:02:54 +0100 (CET) Message-ID: <55003CFD.5080708@sics.se> Date: Wed, 11 Mar 2015 14:02:53 +0100 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "ace@ietf.org" References: <54FED2E3.5080601@sics.se> In-Reply-To: <54FED2E3.5080601@sics.se> X-Forwarded-Message-Id: <54FED2E3.5080601@sics.se> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030309050909090803050708" X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sics-se:default, sics-se:default, base:default, @@RPTN) X-p0f-Info: os=Linux 2.2.x-3.x, link=Ethernet or modem X-CanIt-Geo: =?UTF-8?Q?ip=3D85.235.11.178; _country=3DSE; _region=3DSk=C3=A5ne; _city=3DLund; _latitude=3D55.7028; _longitude=3D13.1927; _http://maps.google.com/maps=3Fq=3D55.7028,13.1927&z=3D6?= X-CanItPRO-Stream: outbound-sics-se:outbound (inherits from outbound-sics-se:default, sics-se:default, base:default) X-Canit-Stats-ID: 09O2d2S1g - 2652505307e3 - 20150311 X-Antispam-Training-Forget: https://canit.sunet.se/canit/b.php?i=09O2d2S1g&m=2652505307e3&t=20150311&c=f X-Antispam-Training-Nonspam: https://canit.sunet.se/canit/b.php?i=09O2d2S1g&m=2652505307e3&t=20150311&c=n X-Antispam-Training-Spam: https://canit.sunet.se/canit/b.php?i=09O2d2S1g&m=2652505307e3&t=20150311&c=s X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 85.235.11.178 is neither permitted nor denied by domain ludwig@sics.se) receiver=e-mailfilter01.sunet.se; client-ip=85.235.11.178; envelope-from=; helo=norm.sics.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: Subject: [Ace] Fwd: New Version Notification for draft-seitz-ace-problem-description-03.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, 11 Mar 2015 13:03:00 -0000 This is a cryptographically signed message in MIME format. --------------ms030309050909090803050708 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi, We submitted a new version of the proposed problem description for ACE. The main updates are - The requirements now account for the end-to-end security problem - A figure illustrating the information flows that need to be protected - Cleaned up solution elements from the problem description Comments are welcome! Ludwig -------- Forwarded Message -------- Subject: New Version Notification for draft-seitz-ace-problem-description-03.txt Date: Mon, 09 Mar 2015 12:39:02 -0700 From: internet-drafts@ietf.org To: Ludwig Seitz , Goeran Selander , Ludwig Seitz , Goran Selander A new version of I-D, draft-seitz-ace-problem-description-03.txt has been successfully submitted by Ludwig Seitz and posted to the IETF repository. Name: draft-seitz-ace-problem-description Revision: 03 Title: Problem Description for Authorization in Constrained Environments= Document date: 2015-03-09 Group: Individual Submission Pages: 17 URL: http://www.ietf.org/internet-drafts/draft-seitz-ace-problem-description-0= 3.txt Status: https://datatracker.ietf.org/doc/draft-seitz-ace-problem-description/ Htmlized: http://tools.ietf.org/html/draft-seitz-ace-problem-description-03 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-seitz-ace-problem-description-03= Abstract: We present a problem description for authentication and authorizatio= n in constrained-node networks, i.e. networks where some devices have severe constraints on memory, processing, power and communication bandwidth. 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 --------------ms030309050909090803050708 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVDCC BhgwggUAoAMCAQICAwyGmDANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTE1MDEwODA4MzkwNloXDTE2MDEwOTIyNDEzMFowODEXMBUGA1UE AwwObHVkd2lnQHNpY3Muc2UxHTAbBgkqhkiG9w0BCQEWDmx1ZHdpZ0BzaWNzLnNlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxUHisC6rgXFsBHHBGo8ulz/cLX3gX5Ufhcwo rp+7djzMMuKPM1KOHq0bjWhmFe8ly8CzWdk2NS600t7IEBQWJiHLsdc12UqmNswQUpD7oqkR 1nRGT6leAHYTWapkR+nczZ2NxD+H7u4ZWVIZg0DFiTqtY8ghYHHYYy8BBoc/jHG78X4+JJAg s5XOa0gVl7W38vDvVpo14xhWEBGjzPk9WxWirqAF66PF+JEu2JD9LzFbpEq829SRXJMFB9wp oQNlH0UQ01/2sWCIBxPpHuEjxEF/V3Z/F2VsNTy4zvYrd+/MYO3w30F+bWQNZsMHEkTW1pEh iz7rQPWTBXoO8Fv0wQIDAQABo4IC1DCCAtAwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTqvKspqEm0E4R1sgsABYKk 6xDJqDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZBgNVHREEEjAQgQ5sdWR3 aWdAc2ljcy5zZTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcC AjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0 aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5 aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQEFBQADggEBAGXwFsbSfv4mMWqIk64CoxuR6ozo7J37igca7d9tpKIzVIp6xp7Zt+a+J9X3 1r4zgMRFnZJWQ5hy82W/fVDeG9i3NGMM6p7DNUrGjTbVHd11BQtbUOG9MSlyWKQbmt3Q1ElC f4SRLAQot5SPryLR2FTxQuFkMOrcDzVxNxnMgatOM2fAO8KS0H+wX+I7gC3pEnbg/eMqNgU+ Ktbc2y9naDNmLNLN65s8TT9xZyoQEn9S1oU8Xnh596OMu49Eccws8Ny+vAGESIHG4bqhMSjj rmDilL1Wj9nQahmBnID5oZD5g9s9KyqxiZIGNnowYYOpCrSeITZ1b7wg50dC8ySojnYwggY0 MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEw MjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0d Lep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiU fsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5Dp IpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuC YKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/ MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0j BBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzAB hhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nm c2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9 eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukD FUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyi kfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8Cnykh ExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b 970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCD z+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqA SfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNb BIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBth HSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+ UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAwyGmDAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTAzMTExMzAyNTNaMCMGCSqGSIb3DQEJBDEW BBSmJu7As43cMayIZtHy8Ddc0Ivr3jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDDIaYMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJKoZIhvcNAQEBBQAE ggEAYlHnmVpqVOLhGUUVJ6P6IKBdrE8Q9gZpazZ7cOhvBmIkmA2m10JieVvPq+0LQtURO3Ds AmcPU9cmT9Pstm9ai8d4cIOuVqmqfSnPtvdrr1Y5N79ExMvLIwLdCkcbhw8Kk7iJmgiCrIg6 a1soLFwq3I5wWKF9KqJQLnH952VobQGKv0wGuTjQQVvuilTxw7vPdcW1v6BPZtUvcKlu+H4C T6iUerqdDmy38WqbbRby2dWpmQfYOPB/Xcvsq/BWwrV3Q59Cz9c3Gtc5a6pdxOEcZ4YWICjq eErCzhXrdtNIp+OcIipwF7FEzA3zLEPjQCeM/hBqm1FCNCNq7PJ9WLFbQwAAAAAAAA== --------------ms030309050909090803050708-- From nobody Fri Mar 13 10:48: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 771F41A1A47 for ; Fri, 13 Mar 2015 10:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vE0v322tC69S for ; Fri, 13 Mar 2015 10:47:57 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (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 1F5EA1A0174 for ; Fri, 13 Mar 2015 10:47:57 -0700 (PDT) Received: from [192.168.2.49] ([85.97.65.144]) by mrelay.perfora.net (mreueus002) with ESMTPA (Nemesis) id 0MUn74-1Z4dk63aSy-00YBnQ for ; Fri, 13 Mar 2015 18:47:56 +0100 From: Alper Yegin Content-Type: multipart/alternative; boundary="Apple-Mail=_F3076FDE-465B-4D5F-B01D-4B9B999F1C2D" Date: Fri, 13 Mar 2015 19:47:57 +0200 Message-Id: To: Ace@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Provags-ID: V03:K0:lfZ8SYYYjdExBb+7wMvML7dygYKtg2NfdPNPhaDW4TNQJz0TSpF /KgcFuWNdA5Vty/QaWYTikKryTBOHXBq8K6cKnHyOSKFOBRs/2mofxoOmk0i6ghf+bIa11x QXE9zri9IZP0fnl6y5dO3dXr6SDyFIArVkxsonJbOeFmy0pR6S6l2wD+Pdu5hPiGBOfa1Ot X3cYYRIUJqtPU7F5AJd6w== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [Ace] greevenbosch-ace-comparison comments 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, 13 Mar 2015 17:48:01 -0000 --Apple-Mail=_F3076FDE-465B-4D5F-B01D-4B9B999F1C2D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, I've read draft-greevenbosch-ace-comparison-01. I'd like to thank the = authors for putting this document together and share my following = comments: An Authentication, Authorization and Accounting (AAA) server may be deployed. Such AAA server is mentioned in [RFC3748], and both RADIUS [RFC2865] and Diameter [RFC6733] define AAA servers. However, the authorization in RADIUS and Diameter is not fine grained, it is a simple all or nothing question. Thus, RADIUS and/or Diameter would need adaptation to cater for CoAP specific requirements, or a new AAA protocol may need to be defined. Actually, it's a just a matter of defining new attributes/AVPs. = Relatively easy. New AAA protocol is not necessary. The authentication allows the exchange of cryptographic material. After authentication, this material is referred to using the new "AUTH" CoAP option. This AUTH option is only used for integrity protection of the related message, encryption is yet to be defined. We have some (expired) work related to that, FYI: https://tools.ietf.org/html/draft-yegin-coap-security-options-00=20 The X.509 certificates are authenticated by a certificate authority, either net-wide or domain-wide. This has an administrative issue: Provisioning the public key of the = right root CA(s) on the devices. Regarding greevenbosch-ace-pull-model: It looks like the Client is not really authenticated. It does send its = "ID", but it does not provide any cryptographic proof that it owns that = ID. Am I missing something? Alper --Apple-Mail=_F3076FDE-465B-4D5F-B01D-4B9B999F1C2D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii draft-greevenbosch-ace-comparison-01. I'd like to thank the = authors for putting this document together and share my following = comments:

   An Authentication, = Authorization and Accounting (AAA) server may be
   [RFC2865] and Diameter = [RFC6733] define AAA servers.  However, the
   simple all or nothing = question.  Thus, RADIUS and/or Diameter would
   protocol may need to be = defined.

Actually, it's a just a matter of = defining new attributes/AVPs. Relatively easy. New AAA protocol is not = necessary.


   The = authentication allows the exchange of cryptographic material.
   "AUTH" CoAP option.  This AUTH = option is only used for integrity
   protection of the = related message, encryption is yet to be defined.
We have some (expired) work related to that, = FYI:


   The X.509 = certificates are authenticated by a certificate authority,
This has an administrative issue: Provisioning = the public key of the right root CA(s) on the devices.

Regarding = greevenbosch-ace-pull-model:

It looks like the Client is = not really authenticated. It does send its "ID", but it does not provide = any cryptographic proof that it owns that ID. Am I missing = something?

Alper


= --Apple-Mail=_F3076FDE-465B-4D5F-B01D-4B9B999F1C2D-- From nobody Mon Mar 16 07:47: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 DF4441A87C8 for ; Mon, 16 Mar 2015 07:47:41 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIR-cMbA8DlB for ; Mon, 16 Mar 2015 07:47:40 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (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 591861A8794 for ; Mon, 16 Mar 2015 07:47:40 -0700 (PDT) Received: from [192.168.2.2] ([88.235.22.33]) by mrelay.perfora.net (mreueus002) with ESMTPA (Nemesis) id 0LdFWZ-1ZFcUt3ewD-00iQBf for ; Mon, 16 Mar 2015 15:47:39 +0100 From: Alper Yegin Content-Type: multipart/alternative; boundary="Apple-Mail=_0A310CEA-2A0A-4B11-91DB-5BCFA67D34D8" Date: Mon, 16 Mar 2015 16:47:24 +0200 Message-Id: <9AC0EA6E-F823-408D-B5FF-123D0855E93B@yegin.org> To: Ace@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Provags-ID: V03:K0:sQPacweSKIlaZ75twWkNjBI+rFWO0HT4D6enfSnUTmNnHjKrG6w epBkfLcUW0pFha9VRWuQsqFvHeUZKAAGZCAjswoA3ek6icpnetz1I+m7Ev+ZvIoe7Z2JPvS 6l3zImMztPzMKh+7rjdQn22ogvaPQpkyC6XZjTJVlsLq9VdFFadc/Z7KnMxWSo8beoTIY9d tlQ5zoGftKnTad1VPQprw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [Ace] draft-gerdes-ace-actors 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, 16 Mar 2015 14:47:42 -0000 --Apple-Mail=_0A310CEA-2A0A-4B11-91DB-5BCFA67D34D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, I've read draft-gerdes-ace-actors-03, and I have one comment: It'd be really useful if specific examples were provided for = COP/ROM/CAM/SAM. Visualizing the examples helps it easier to grasp the = concept and follow the text. Alper --Apple-Mail=_0A310CEA-2A0A-4B11-91DB-5BCFA67D34D8 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hello,

I've read draft-gerdes-ace-actors-03, and I have one comment:

It'd be really useful if specific examples were provided for COP/ROM/CAM/SAM. Visualizing the examples helps it easier to grasp the concept and follow the text.

Alper





--Apple-Mail=_0A310CEA-2A0A-4B11-91DB-5BCFA67D34D8-- From nobody Tue Mar 17 03:59: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 176611A0266 for ; Tue, 17 Mar 2015 03:59:53 -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 xIYcQUEjMAYo for ; Tue, 17 Mar 2015 03:59: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 739151A0267 for ; Tue, 17 Mar 2015 03:59:48 -0700 (PDT) X-AuditID: c1b4fb25-f79126d000004b89-8f-55080922922b Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 8E.BB.19337.22908055; Tue, 17 Mar 2015 11:59:46 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.196]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0210.002; Tue, 17 Mar 2015 11:59:46 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Stefanie Gerdes , "Ace@ietf.org" Thread-Topic: [Ace] Fwd: New Version Notification for draft-gerdes-ace-actors-03.txt Thread-Index: AQHQYKF6eNCV1PF07k29OLhbkWWtbA== Date: Tue, 17 Mar 2015 10:59:45 +0000 Message-ID: References: <20150309234920.12025.44848.idtracker@ietfa.amsl.com> <54FEF0C9.30005@tzi.de> In-Reply-To: <54FEF0C9.30005@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+NgFmpmkeLIzCtJLcpLzFFi42KZGfG3RleJkyPU4OJfA4vv33qYLTZevMvo wOSxZMlPJo9tb78yBzBFcdmkpOZklqUW6dslcGWcmXCSsaBvDmPFqp+XmRsYe2YwdjFycEgI mEjM2xXfxcgJZIpJXLi3nq2LkYtDSOAIo8TFi+tZIZwljBKvF3xjAqliE3CReNDwCMwWEXCS WLrtLwuILSwQKrF3zlp2kKEiAmESnQsYIUr0JCb++wK2i0VAVeLJNEeQMK+AhcSiNffApggJ REvseHkLbAqngIrE3Buz2EFsRqB7vp9aA1bDLCAucevJfCaIOwUkluw5zwxhi0q8fPyPFcQW BVq18noTG0RcSWLt4e0sIGuZBTQl1u/ShxhjLXFq91w2CFtRYkr3Q3aIcwQlTs58wjKBUXwW km2zELpnIemehaR7FpLuBYysqxhFi1OLk3LTjYz1Uosyk4uL8/P08lJLNjECY+3glt+qOxgv v3E8xCjAwajEw7thBnuoEGtiWXFl7iFGaQ4WJXFeO+NDIUIC6YklqdmpqQWpRfFFpTmpxYcY mTg4pRoYJ6/2/qS0fOvyWuXL6ctufBO3n7lyQuzU1pv1VjNCPqWH8b/4szOx85/ndrXXm4RX fPWTFutb4yzyPG7hhW8RtwyOfWfzePWyX2Nv/N0br7dV1AXbcMXfXLt6pqzp5GMZ69ryhU/U 3zljyHj86TQTsZCsuNDt612YggwnS/KrFX29NVFw44liSSWW4oxEQy3mouJEAGTXh72WAgAA Archived-At: Subject: Re: [Ace] Fwd: New Version Notification for draft-gerdes-ace-actors-03.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, 17 Mar 2015 10:59:53 -0000 DQpIaSBTdGVmZmksDQoNCkkndmUgZmluYWxseSBnb3QgYXJvdW5kIHRvIHJlYWQgdGhlICJhY3Rv cnMiIGRyYWZ0IGFzIGEgd2hvbGUuIEkndmUgbGlzdGVkDQpzb21lIGNvbW1lbnRzIGJlbG93Lg0K DQoNCkdlbmVyYWw6DQoNCuKAoiBUaGUgZHJhZnQgaW50cm9kdWNlcyBvbmUgbmV3IG5vZGUgaW4g dGhlIGFyY2hpdGVjdHVyZSAoY29tcGFyZWQgdG8gZS5nLg0KVU1BKSBjYWxsZWQgQ09QLCBzdXBw b3J0aW5nIGEgY29uc3RyYWluZWQgY2xpZW50LiBJIHRoaW5rIHRoaXMga2luZCBvZg0KInN1cHBv cnQgbm9kZSIgaXMgdXNlZnVsLCBidXQgaXRzIGZ1bmN0aW9uYWxpdHkgbmVlZHMgdG8gYmUgZnVy dGhlcg0KZWxhYm9yYXRlZCAoc2VlIGRldGFpbGVkIGNvbW1lbnRzKS4NCg0K4oCiIFRoZXJlIGlz IGxvdHMgb2YgaW5ub3ZhdGlvbiBvZiB0ZXJtaW5vbG9neTsgYm90aCBuZXcgdGVybXMNCihhdXRo ZW50aWNhdGVkIGF1dGhvcml6YXRpb24sIGJpbmFyeSBhdXRob3JpemF0aW9uLCB1bnJlc3RyaWN0 ZWQNCmF1dGhvcml6YXRpb24sIGF1dGhvcml6ZWQgcmVwcmVzZW50YXRpb24sIGF1dGhvcml6ZWQg cmVzb3VyY2UsIGVuZG9yc2VtZW50DQppbmZvcm1hdGlvbiwgY29tcGxleGl0eSBsZXZlbHMsIGV0 Yy4pOyBuZXcgbmFtZXMgZm9yIHJvbGVzIGluIHRoZQ0KYXV0aG9yaXphdGlvbiBhcmNoaXRlY3R1 cmUgKENsaWVudCBPdmVyc2Vlc2luZyBQcmluY2lwYWwsIFNlcnZlcg0KT3ZlcnNlZWluZyBQcmlu Y2lwYWwsIENsaWVudCBBdXRob3JpemF0aW9uIE1hbmFnZXIsIFNlcnZlciBBdXRob3JpemF0aW9u DQpNYW5hZ2VyLCBBdHRyaWJ1dGUgQmluZGluZyBBdXRob3JpdHkpOyBhbmQgYWxzbyB0aGUgbWVh bmluZyBvZiBleGlzdGluZw0KdGVybXMgKGUuZy4gYXV0aG9yaXphdGlvbikgaXMgYmVpbmcgY2hh bmdlZC4gSSBkaXNhZ3JlZSB3aXRoIGhvdyBzb21lDQp0ZXJtcyBhcmUgdXNlZCBhbmQgbW9yZW92 ZXIgSSB0aGluayBpdCB3b3VsZCBiZSBtdWNoIGJldHRlciB0byB1c2UgbGVzcw0KdGVybWlub2xv Z3kgYW5kIHRyeSB0byByZXVzZSBleGlzdGluZyB0ZXJtaW5vbG9neS4gSGVyZSBhcmUgYSBmZXcg cmVhc29uczoNCg0KCS0gQWNjZXNzIGNvbnRyb2wgaXMgbm90IGEgbmV3IHByb2JsZW0uIEFsdGhv dWdoIHRoZSBjb25zdHJhaW5lZA0KZW52aXJvbm1lbnQgbW90aXZhdGVzIHNvbWUgbmV3IGZ1bmN0 aW9uYWxpdHksIHRoYXQgZG9lcyBub3Qgd2FycmFudCBhDQpjb21wbGV0bHkgbmV3IHRlcm1pbm9s b2d5Lg0KDQoJLSBBdCB0aGUgZW5kIG9mIHRoZSBkYXkgd2Ugd2FudCBwZW9wbGUgYXBwcm9hY2hp bmcgdGhpcyB3b3JrIHRvIGJlIGFibGUNCnRvIHJldXNlIGdhaW5lZCBrbm93bGVkZ2UgZnJvbSBv dGhlciBjb250ZXh0cyB0byBxdWlja2x5IHVuZGVyc3RhbmQgd2hhdA0KdGhpcyB3b3JrIGlzIGdv b2QgZm9yLiBUaGUgc2hlZXIgYW1vdW50IG9mIG5ldyB0ZXJtcyBpcyBkaXNjb3VyYWdpbmcuDQoN CgktIFRha2luZyBleGlzdGluZyB0ZXJtaW5vbG9neSBhcyBhIGJhc2lzIGRvZXNuJ3QgbmVjZXNz YXJpbHkgaW1wbHkNCnJlc3RyaWN0aW5nIHRoZSBzb2x1dGlvbiAoYXMgaGFzIGJlZW4gaXRlcmF0 ZWQgbWFueSB0aW1lcyBvbiB0aGlzIGxpc3QsDQpzZWUgYWxzbyBkZXRhaWxlZCBjb21tZW50IGJl bG93KS4gQmVzaWRlcywgaW4gb3VyIGNhc2UgaXQgaXMgbWFpbmx5IGENCnF1ZXN0aW9uIG9mICph ZGRpbmcqIGEgZmV3IHRlcm1zIHN1Y2ggYXMgZGVzY3JpYmluZyB0aGUgZnVuY3Rpb25hbGl0eSBv Zg0KdGhlIGFib3ZlIG1lbnRpb25lZCBzdXBwb3J0IG5vZGUuIChPZiBjb3Vyc2UsIGZvciB0aGF0 IHB1cnBvc2UsIG9uZSBuZXcNCnRlcm0gd2lsbCBiZSBuZWVkZWQuKQ0KDQrigKIgVGhlcmUgaXMg YW4gYW1iaXRpb24gdG8gc3ltbWV0cml6ZSB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgYW5kIHJlbW92 ZSB0aGUNCmludHJpbnNpYyBhc3N5bW1ldHJ5IG9mIHRoZSBhY2Nlc3MgY29udHJvbCBwcm9ibGVt LiBIb3dldmVyIGFlc3RoZXRpYyB0aGlzDQphcmNoaXRlY3R1cmUgbG9va3MgaW4gYWxsIGl0cyBz eW1tZXRyeSBhbmQgbWF0Y2hpbmcgdGVybWlub2xvZ3ksIHRoaXMNCmFtYml0aW9uIGlzIG1pc2d1 aWRlZCBhbmQgaGlkZXMgcGFydCBvZiB0aGUgcHJvYmxlbS4gSSBzdXNwZWN0IGl0IGlzIHRoaXMN CmFtYml0aW9uIHdoaWNoIGlzIGJlaGluZCB0aGUgcmUtaW50ZXJwcmV0YXRpb25zIG9mIGV4aXN0 aW5nIHRlcm1zLCBzdWNoIGFzDQoiYXV0aG9yaXphdGlvbiIuIEZvciBleGFtcGxlIG9ubHkgY29u ZmlkZW50aWFsaXR5IGFuZCBpbnRlZ3JpdHkgYXNwZWN0cyBvZg0KYXV0aG9yaXphdGlvbiBhcmUg Y29uc2lkZXJlZCAgKCJUaGUgc2VjdXJpdHkgb2JqZWN0aXZlcyB0aGF0IGNhbiBiZQ0KYWRkcmVz c2VkIGJ5IGFuIGF1dGhvcml6YXRpb24gc29sdXRpb24gYXJlIGNvbmZpZGVudGlhbGl0eSBhbmQg aW50ZWdyaXR5IikNCnNpbmNlIHRob3NlIGNhbiBiZSBoYW5kbGVkIG1vcmUgc3ltbWV0cmljYWxs eSB0aGFuIG90aGVyIGFzcGVjdHMgb2YNCmF1dGhvcml6YXRpb24uIE1vcmUgYmVsb3cuDQoNCuKA oiBUaGUgZW5kLXRvLWVuZCBzZWN1cml0eSBzZXR0aW5nIGFzIGRlc2NyaWJlZCBpbiBlLmcuDQpk cmFmdC1zZWxhbmRlci1hY2Utb2JqZWN0LXNlY3VyaXR5LCBpcyBtaXNzaW5nIGZyb20gaW4gdGhp cyBkcmFmdC4gKFNlZQ0KYmVsb3cpDQoNCg0KDQpEZXRhaWxlZCBjb21tZW50czoNCg0KU2VjdGlv biAxLjENCuKAlA0KDQrigKIgIkFjdG9yIg0KDQpJIHdvdWxkIGNhbGwgdGhpcyAicm9sZSIuIFRo ZXJlIGlzIGEgY29tbW9uIHVzZSBvZiB0aGUgdGVybXMgImFjdG9yIiBhbmQNCiJyb2xlIiwgd2hl cmVpbiBhICJyb2xlIiBjaGFyYWN0ZXJpemVzIGNlcnRhaW4gZnVuY3Rpb25hbGl0eSBhbmQgYW4N CiJhY3RvciIgaXMgc29tZSBlbnRpdHkgdGhhdCBtYXkgb3IgbWF5IG5vdCBoYXZlIHRoZSBmdW5j dGlvbmFsaXR5DQpjaGFyYWN0ZXJpc2VkIGJ5IHRoZSByb2xlLg0KDQoiUmVzb3VyY2UgT3ZlcnNl ZWluZyBQcmluY2lwYWwgKFJPUCk6DQpDbGllbnQgT3ZlcnNlZWluZyBQcmluY2lwYWwgKENPUCk6 DQpTZXJ2ZXIgQXV0aG9yaXphdGlvbiBNYW5hZ2VyIChTQU0pOiINCg0KVGhlc2UgdGVybXMgaGF2 ZSANCg0KDQpTZWN0aW9uIDINCuKAlA0KDQrigKIgImF1dGhvcml6ZWQgcmVwcmVzZW50YXRpb24i DQoNClRoaXMgdGVybSBpcyBub3QgZGVmaW5lZCBpbiB0aGUgdGVybWlub2xvZ3kgc2VjdGlvbiBi dXQgc3VwcG9zZWRseSBtZWFucyBhDQpyZXByZXNlbnRhdGlvbiB0aGUgY2xpZW50IGlzIGNvbmZp Z3VyZWQgdG8gc2VuZCBpbiBhIHBhcnRpY3VsYXIgcmVxdWVzdA0KDQoNCuKAoiAiYXV0aG9yaXpl ZCByZXNvdXJjZXMiDQoNClRoaXMgdGVybSBpcyBub3QgZGVmaW5lZCBpbiB0aGUgdGVybWlub2xv Z3kgc2VjdGlvbiBidXQgc3VwcG9zZWRseSBtZWFucyBhDQpyZXNvdXJjZSB0aGF0IGEgY2xpZW50 IGlzIGNvbmZpZ3VyZWQgdG8gcmVxdWVzdA0KDQoNCg0K4oCiICJSZXEuMC4yICAgIEMgaXMgZXhj aGFuZ2luZyBzdGF0dXMgdXBkYXRlcyBvZiBhIHJlc291cmNlIG9ubHkgd2l0aA0KICAgICAgYXV0 aG9yaXplZCByZXNvdXJjZXMuIg0KDQpUaGF0IHRoZSB1c2Ugb2YgdGhlIHRlcm0gYXV0aG9yaXph dGlvbiBvbiB0aGUgY2xpZW50IHNpZGUgaXMgbWlzbGVhZGluZy4NCkV2ZXJ5IHRhc2sgYSBjbGll bnQgcGVyZm9ybXMgaXMgb24gYmVoYWxmIG9mIGl0cyBjb250cm9sIG5vZGUgKENPUCkuIElmDQph bGwgdGhlc2UgdGFza3MgYXJlIGNhbGxlZCBhdXRob3JpemF0aW9uLCB0aGVuIHRoZXJlIGlzIG5v dGhpbmcgdGhhdCBpc24ndA0KYXV0aG9yaXphdGlvbi4gIFRoZXJlIGlzIG5vIHN5c3RlbSByZXNv dXJjZSBvbiB0aGUgY2xpZW50IHNpZGUgdG8gd2hpY2gNCmFjY2VzcyBpcyBhdXRob3JpemVkLg0K DQoNCg0KDQpTZWN0aW9uIDMNCuKAlA0KDQrigKIgIlRoZSBzZWN1cml0eSBvYmplY3RpdmVzIHRo YXQgY2FuIGJlIGFkZHJlc3NlZCBieSBhbiBhdXRob3JpemF0aW9uDQpzb2x1dGlvbiBhcmUgY29u ZmlkZW50aWFsaXR5IGFuZCBpbnRlZ3JpdHkuIEF2YWlsYWJpbGl0eSBjYW5ub3QgYmUNCmFjaGll dmVkIGJ5IGF1dGhvcml6YXRpb24gc29sdXRpb25zLiBIb3dldmVyLCBtaXNjb25maWd1cmVkIG9y IHdyb25nbHkNCmRlc2lnbmVkIGF1dGhvcml6YXRpb24gc29sdXRpb25zIGNhbiByZXN1bHQgaW4g YXZhaWxhYmlsaXR5IGJyZWFjaGVzOg0KVXNlcnMgbWlnaHQgbm8gbG9uZ2VyIGJlIGFibGUgdG8g dXNlIGRhdGEgYW5kIHNlcnZpY2VzIGFzIHRoZXkgYXJlDQpzdXBwb3NlZCB0by4gIg0KDQpJIGFn cmVlIHRoYXQgY29uZmlkZW50aWFsaXR5IGFuZCBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBjYW4gYmUg dXNlZCBhcyBvbmUNCmNvbXBvbmVudCB0byBlbmZvcmNlIGFuIGF1dGhvcml6YXRpb24gZGVjaXNp b24sIGJ1dCBjaGFyYWN0ZXJpemluZw0KYXV0aG9yaXphdGlvbiBvbmx5IGFzIHRoYXQgaXMgbWlz bGVhZGluZy4gR2VuZXJhbGx5IHNwZWFraW5nLA0KYXV0aG9yaXphdGlvbiBpcyBhYm91dCByZXN0 cmljdGluZyBhY2Nlc3MgdG8gKHN5c3RlbSkgcmVzb3VyY2VzLCB3aGljaA0KaW5jbHVkZSByZXN0 cmljdGluZyB0aGUgcmlnaHQgdG8gaW5pdGlhdGUgcHJvY2Vzc2luZyBvbiBhIHNlcnZlciwgd2hp Y2ggaW4NCnR1cm4gcHJvdmlkZXMgc29tZSByZXNpc3RhbmNlIGFnYWluc3QgYXR0YWNrcy9vdmVy bG9hZCBhbmQgdGh1cyBpcyByZWxhdGVkDQp0byBhdmFpbGFiaWxpdHkuDQoNCg0KDQrigKIgIklu IG1hbnkgY2FzZXMsIG9uZSBwYXJ0aWNpcGF0aW5nIHBhcnR5IG1pZ2h0IGhhdmUgZGlmZmVyZW50 IHNlY3VyaXR5DQpvYmplY3RpdmVzIHRoYW4gdGhlIG90aGVyLiBIb3dldmVyLCB0byBhY2hpZXZl IGEgc2VjdXJpdHkgb2JqZWN0aXZlLCBib3RoDQpwYXJ0aWVzIG11c3QgcGFydGljaXBhdGUgaW4g cHJvdmlkaW5nIGEgc29sdXRpb24uIEUuZy4sIGlmIENPUCByZXF1aXJlcw0KdGhlIGludGVncml0 eSBvZiBzZW5zb3IgdmFsdWUgcmVwcmVzZW50YXRpb25zIFMgaXMgaG9zdGluZywgQm90aCBDIGFu ZCBTDQpuZWVkIHRvIGludGVncml0eS1wcm90ZWN0IHRoZSB0cmFuc21pdHRlZCBkYXRhLiAiDQoN CldoeSBkb2VzIEMgbmVlZCB0byBpbnRlZ3JpdHkgcHJvdGVjdCB0cmFuc21pdHRlZCBkYXRhPyBJ c24ndCBpdCBzdWZmaWNpZW50DQp0aGF0IFMgaW50ZWdyaXR5IHByb3RlY3RzIHRoZSBzZW5zb3Ig dmFsdWUgcmVwcmVzZW50YXRpb24gaXQgaXMgaG9zdGluZz8NCg0KDQoNClNlY3Rpb24gNA0K4oCU DQoNCuKAoiAiVG8gZGV0ZXJtaW5lIGlmIGFuIGVudGl0eSBpcyBhdXRob3JpemVkIHRvIGFjY2Vz cyBhIHJlc291cmNlLCBhbg0KYXV0aGVudGljYXRpb24gbWVjaGFuaXNtIGlzIG5lZWRlZC4gQWNj b3JkaW5nIHRvIHRoZSBJbnRlcm5ldCBTZWN1cml0eQ0KR2xvc3NhcnkgW1JGQzQ5NDldLCBhdXRo ZW50aWNhdGlvbiBpcyDigJx0aGUgcHJvY2VzcyBvZiB2ZXJpZnlpbmcgYSBjbGFpbQ0KdGhhdCBh IHN5c3RlbSBlbnRpdHkgb3Igc3lzdGVtIHJlc291cmNlIGhhcyBhIGNlcnRhaW4gYXR0cmlidXRl IHZhbHVlLuKAnQ0KRXhhbXBsZXMgZm9yIGF0dHJpYnV0ZSB2YWx1ZXMgYXJlIHRoZSBJRCBvZiBh IGRldmljZSwgdGhlIHR5cGUgb2YgdGhlDQpkZXZpY2Ugb3IgdGhlIG5hbWUgb2YgaXRzIG93bmVy LiAiDQoNCkF1dGhlbnRpY2F0aW9uLCBpbiB0aGUgc2Vuc2Ugb2YgdmVyaWZ5aW5nIGEgY2xhaW0g YWJvdXQgYSBhdHRyaWJ1dGUgdmFsdWUsDQppcyBub3QgbmVjc3NhcnkuIEEgc2VydmVyIG1heSBl bmNyeXB0IGEgcmVzb3VyY2UgcmVwcmVzZW50YXRpb24gd2l0aCBhDQpzcGVjaWZpYyBrZXkgb25s eSBwb3NzZXNzZWQgYnkgYXV0aG9yaXplZCBjbGllbnRzIChjZi4gT1NDQVIsDQpodHRwOi8vYXJ4 aXYub3JnL2Ficy8xNDA0Ljc3OTkpLg0KDQoNCuKAoiAiV2UgdXNlIHRoZSB0ZXJtIGF1dGhlbnRp Y2F0ZWQgYXV0aG9yaXphdGlvbiB0byByZWZlciB0byBhIHN5bnRoZXNpcyBvZg0KbWVjaGFuaXNt IGZvciBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbi4gIg0KDQpUaGUgdGVybSAiQXV0 aGVudGljYXRlZCBhdXRob3JpemF0aW9uIiBpcyBxdWl0ZSB2YWd1ZS4NCg0KDQrigKIgInVucmVz dHJpY3RlZCBhdXRob3JpemF0aW9uIg0KDQpUaGlzIGlzIGRlZmluZWQgYXMgIm5vIGF1dGhvcml6 YXRpb24iLiBXaHkgbm90IGp1c3Qgc2F5IHNvPw0KDQoNCg0K4oCiICJGb3IgYWxsIGNhc2VzIHdo ZXJlIGFuIGF1dGhvcml6YXRpb24gc29sdXRpb24gaXMgbmVlZGVkIChhbGwgYnV0DQpVbnJlc3Ry aWN0ZWQgQXV0aG9yaXphdGlvbiksIHRoZSBhdXRob3JpemluZyBwYXJ0eSBuZWVkcyB0byBiZSBh YmxlIHRvDQphdXRoZW50aWNhdGUgdGhlIHBhcnR5IHRoYXQgaXMgdG8gYmUgYXV0aG9yaXplZC4g QXV0aGVudGljYXRpb24gaXMNCnRoZXJlZm9yZSByZXF1aXJlZCBmb3IgbWVzc2FnZXMgdGhhdCBj b250YWluIHJlcHJlc2VudGF0aW9ucyBvZiBhbg0KYWNjZXNzZWQgaXRlbS4gTW9yZSBwcmVjaXNl bHksIHRoZSBhdXRob3JpemluZyBwYXJ0eSBuZWVkcyB0byBtYWtlIHN1cmUNCnRoYXQgdGhlIHJl Y2VpdmVyIG9mIGEgbWVzc2FnZSBjb250YWluaW5nIGEgcmVwcmVzZW50YXRpb24sIGFuZCB0aGUg c2VuZGVyDQpvZiBhIG1lc3NhZ2UgY29udGFpbmluZyBhIHJlcHJlc2VudGF0aW9uIGFyZSBhdXRo b3JpemVkIHRvIHJlY2VpdmUgYW5kDQpzZW5kIHRoaXMgbWVzc2FnZSwgcmVzcGVjdGl2ZWx5LiBU byBhY2hpZXZlIHRoaXMsIHRoZSBpbnRlZ3JpdHkgb2YgdGhlc2UNCm1lc3NhZ2VzIGlzIHJlcXVp cmVkOiBBdXRoZW50aWNpdHkgY2Fubm90IGJlIGFzc3VyZWQgaWYgaXQgaXMgcG9zc2libGUgZm9y DQphbiBhdHRhY2tlciB0byBtb2RpZnkgdGhlIG1lc3NhZ2UgZHVyaW5nIHRyYW5zbWlzc2lvbi4i DQoNCkkgZmluZCBhIHNldmVyYWwgdGhpbmdzIGNvbmZ1c2luZyBoZXJlOg0KCS0gV2hhdCBwYXJ0 eSBpcyB0aGUgYXV0aG9yaXppbmcgcGFydHk/IEEgc2VydmVyIG9yIGEgU0FNIC8gQXV0aG9yaXph dGlvbg0KU2VydmVyPw0KDQoJLSAiQXV0aGVudGljYXRpb24gaXMgdGhlcmVmb3JlIHJlcXVpcmVk IGZvciBtZXNzYWdlcyB0aGF0IGNvbnRhaW4NCnJlcHJlc2VudGF0aW9ucyBvZiBhbiBhY2Nlc3Nl ZCBpdGVtLiAiIFRoZSBuZXh0IHNlbnRlbmNlIGNsYWltcyB0byBtYWtlDQpwcmVjaXNlLCBidXQg ZG9lcyBzbyBpbiB0ZXJtcyBvZiBhdXRob3JpemF0aW9uLg0KDQoJLSAidGhlIGF1dGhvcml6aW5n IHBhcnR5IG5lZWRzIHRvIG1ha2Ugc3VyZSB0aGF0ICgtIC0gLSl0aGUgc2VuZGVyIG9mIGENCm1l c3NhZ2UgY29udGFpbmluZyBhIHJlcHJlc2VudGF0aW9uIGFyZSBhdXRob3JpemVkIHRvICgtIC0g LSkgc2VuZCB0aGlzDQptZXNzYWdlIi4gSSB0aGluayB0aGlzIGhhZCBiZXR0ZXIgYmUgcmVwaHJh c2VkIGFzIHRoZSBDQU0gZW5hYmxlcw0KY29uZmlndXJhdGlvbiBvZiB0aGUgY2xpZW50Lg0KDQoN CuKAoiAiVGhlIHNlY3VyaXR5IG9iamVjdGl2ZXMgb2Ygb25lIHNpZGUgY2FuIG9mdGVuIG9ubHkg YmUgYWNoaWV2ZWQgd2l0aCB0aGUNCmhlbHAgb2YgdGhlIG90aGVyIHNpZGUuIEUuZy4sIGlmIHRo ZSBzZXJ2ZXIgcmVxdWlyZXMgdGhlIGNvbmZpZGVudGlhbGl0eQ0Kb2YgYSByZXNvdXJjZSByZXBy ZXNlbnRhdGlvbiwgdGhlIGNsaWVudCBtdXN0IG1ha2Ugc3VyZSB0aGF0IGl0IGRvZXMgbm90DQpz ZW5kIHJlc291cmNlIHVwZGF0ZXMgdG8gcGFydGllcyBvdGhlciB0aGFuIHRoZSBzZXJ2ZXIuIFRo ZXJlZm9yZSwgdGhlDQpjbGllbnQgbXVzdCBhdCBsZWFzdCB1c2UgYmluYXJ5IGF1dGhvcml6YXRp b24uIg0KDQpUaGUgZm9ybXVsYXRpb24gaW5kaWNhdGVzIHRoYXQgdGhlIGRlY2lzaW9uIHdoZXRo ZXIgYSBjbGllbnQgdGhhdCBtYWtlcyBhDQpyZXF1ZXN0IGlzIG5lZWRzIHRvIHRha2UgaW50byBh Y2NvdW50IHNlcnZlciBwb2xpY2llcyBiZWZvcmUgZW5jcnlwdGluZw0KdGhlIHJlcXVlc3QuIEkg dGhpbmsgdGhpcyBzaG91bGQgYmUgY29uZmlndXJlZCBpbiB0aGUgY2xpZW50Lg0KDQpTZWN0aW9u IDYNCuKAlA0KDQo2LjENCg0K4oCiICJUaGlzIGRvY3VtZW50IGRvZXMgbm90IGFzc3VtZSBhIHNw ZWNpZmljIHNvbHV0aW9uLiINCg0KVGhpcyBpcyB0d28tZWRnZWQgc3dvcmQuIElmIHlvdSBjbGFp bSB0aGF0IHdlIGNhbid0IHVzZSBPQXV0aC9VTUENCmFyY2hpdGVjdHVyZSBiZWNhdXNlIGl0IGFz c3VtZXMgYSBzcGVjaWZpYyBzb2x1dGlvbiwgdGhlbiBzbyBkb2VzIHRoaXMNCmRvY3VtZW50Lg0K DQoNCjYuMg0KDQrigKIgIlRoZSByZWFzb24gZm9yIHVzaW5nIGFuIGF1dGhvcml6YXRpb24gc29s dXRpb24gaXMgdG8gdmFsaWRhdGUgdGhhdCB0aGUNCmVudGl0eSB0aGF0IHNlbnQgdGhlIGluZm9y bWF0aW9uIHVzZWQgZm9yIHByb2Nlc3NpbmcgaXMgYXV0aG9yaXplZCB0bw0KcHJvdmlkZSBpdC4g VG8gdmFsaWRhdGUgaWYgYSBzZW5kZXIgaXMgYXV0aG9yaXplZCB0byBzZW5kIGEgcmVjZWl2ZWQg cGllY2UNCm9mIGluZm9ybWF0aW9uLCB0aGUgcmVjZWl2ZXIgbXVzdCBkZXRlcm1pbmUgdGhlIHNl bmRlcuKAmXMgYXV0aG9yaXphdGlvbi4NCkNvcnJlc3BvbmRpbmdseSwgdG8gdmFsaWRhdGUgaWYg YSByZWNlaXZlciBpcyBhbGxvd2VkIHRvIHJlY2VpdmUgYQ0KbWVzc2FnZSwgdGhlIHNlbmRlciBt dXN0IGRldGVybWluZSBpdHMgYXV0aG9yaXphdGlvbi4gVGhpcyBjYW4gb25seSBiZQ0KYWNoaWV2 ZWQgd2l0aCB0aGUgaGVscCBvZiBhbiBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20uIg0KDQpJIHRo aW5rIHRoaXMgaXMgYWxsIHZlcnkgY29tcGxpY2F0ZWQsIGFuZCBpcyBvdmVydXNpbmcgdGhlIHRl cm0NCiJhdXRob3JpemF0aW9uIi4gVGhlIHNlcnZlciBzaG91bGQgZGV0ZXJtaW5lIGlmIHRoZSBj bGllbnQgaXMgYXV0aG9yaXplZA0KdG8gYWNjZXNzIGEgcmVzb3VyY2UsIGFuZCBwZXJmb3JtIGFj Y29yZGluZ2x5LiBUaGUgY2xpZW50IHNob3VsZCBwZXJmb3JtDQphcyBjb25maWd1cmVkIChwb3Rl bnRpYWxseSBkeW5hbWljYWxseSB1c2luZyBhIENBTS10eXBlIG5vZGUpLiBUaGF0J3MgaXQuDQoN Cg0KNi40DQoNCml0ZW0gMTogSSB0aGluayB0aGlzIGlzIG91dCBvZiBzY29wZSBmb3IgQUNFDQpp dGVtIDI6IGFncmVlLiBJIHRoaW5rIHdlIHNob3VsZCBhZGQgc29tZXRoaW5nIGFuYWxvZ291cyBh Ym91dA0KY29uZmlndXJhdGlvbiBvZiBjbGllbnQNCml0ZW0gMy00OiB0aGlzIGlzIGFzc3VtaW5n IGEgcGFydGljdWxhciBzb2x1dGlvbi4gV2UgY2FuIG9idGFpbg0KZ3JhbnVsYXJpdHkgd2l0aG91 dCB0aGUgYXR0cmlidXRlIGV4ZXJjaXNlIGJ5IGFzc29jaWF0aW5nIGNlcnRhaW4ga2V5cyB0bw0K Y2VydGFpbiBwZXJtaXNzaW9ucywgYXMgbWVudGlvbmVkIGFib3ZlLg0KDQoNCjcuMQ0KDQoiQyBw ZXJmb3JtcyB0aGUgZm9sbG93aW5nIHRhc2tzOg0K4oCiIE5lZ290aWF0ZSBtZWFucyBmb3Igc2Vj dXJlIGNvbW11bmljYXRpb24gKFRhc2sgVFNlY3VyZUNvbW0sIHNlZSBBcHBlbmRpeA0KQS4yLjMp LiINCg0KTm90IG5lY2Vzc2FyeSBpZiB0aGVyZSBpcyBhIFRUUCwgc3VjaCBhcyBhbiBBdXRob3Jp emF0aW9uIFNlcnZlciwNCnByb3ZpZGluZyBzZWN1cml0eSBjb250ZXh0DQoNCuKAoiAiVmFsaWRh dGUgdGhhdCBhbiBlbnRpdHkgaXMgYW4gYXV0aG9yaXplZCBzb3VyY2UgZm9yIFIgKFRhc2sNClRW YWxTb3VyY2VBdXRoeiwgc2VlIEFwcGVuZGl4IEEuMi4yKS4iDQoNCkkgd291bGQgcGhyYXNlIHRo aXMgdGhhdCBDIGlzIGNvbmZpZ3VyZWQgdG8gcmVxdWVzdCBSLg0KDQoiUyBwZXJmb3JtcyB0aGUg Zm9sbG93aW5nIHRhc2tzOg0K4oCiIE5lZ290aWF0ZSBtZWFucyBmb3Igc2VjdXJlIGNvbW11bmlj YXRpb24gKFRhc2sgVFNlY3VyZUNvbW0sIHNlZSBBcHBlbmRpeA0KQS4yLjMpLiINCg0KTm90IG5l Y2Vzc2FyeSBpZiB0aGVyZSBpcyBhIFRUUCwgc3VjaCBhcyBhbiBBdXRob3JpemF0aW9uIFNlcnZl ciwNCnByb3ZpZGluZyBzZWN1cml0eSBjb250ZXh0DQoNCg0KDQo3LjINCg0KIkNPUCBtdXN0IGZ1 bGZpbGwgdGhlIGZvbGxvd2luZyB0YXNrOg0K4oCiIENvbmZpZ3VyZSBmb3IgQyBhdXRob3JpemF0 aW9uIGluZm9ybWF0aW9uIGZvciBzb3VyY2VzIGZvciBSICINCg0KSSB3b3VsZCByZXBocmFzZSB0 aGlzIGJ1bGxldCBhcyAi4oCiIENvbmZpZ3VyZSBmb3IgQyByZXNvdXJjZXMgUiB0byBiZQ0KYWNj ZXNzZWQiDQoNCg0KNy4zDQoNCuKAoiAgV2h5IGRvZXMgdGhlIENBTSBoYXZlIHRvIGJlIGluIHRo ZSBzYW1lIHNlY3VyaXR5IGRvbWFpbiBhcyBDIGFuZCBDT1AuDQpDb3VsZCBpdCBub3QgYmUgb3V0 c291cmNlZD8gKFNlZSBlLmcuIEhlYWx0aGNhcmUgc2NlbmFyaW8NCmh0dHA6Ly9rYW50YXJhaW5p dGlhdGl2ZS5vcmcvY29uZmx1ZW5jZS9kaXNwbGF5L3VtYS9VTUErVHJ1c3QrTW9kZWwrVXNlcitn dQ0KaWRlKQ0KDQoNCg0K4oCiIFRoZSBzZXR0aW5nIHdpdGggQ0FNIGFsd2F5cyBiZWluZyBpbnRl cm1lZGlhcnkgYmV0d2VlbiBDIGFuZCBTQU0NCig9QXV0aG9yaXphdGlvbiBTZXJ2ZXIpIGlzIHBy b2JsZW1hdGljLiBDIG5lZWRzIHRvIGJlIGF1dGhvcml6ZWQgKGFuZC9vcg0KcHJvdmUgdGhhdCBp dCBpcykgdG8gYWNjZXNzIFMuIEluIGEgZmVkZXJhdGVkIHNldHRpbmcgaXQgY291bGQgd29yayB0 aGF0LA0KYXMgQ0FNIGJlY29tZXMgYXV0aG9yaXplZCBzbyBkb2VzIGFsbCBpdHMgYXNzaWduZWQg Q3MuIEJ1dCBpbiB0aGUgZ2VuZXJhbA0KY2FzZSwgU0FNIG5lZWRzIHRvIGNvbW11bmljYXRlIHNl Y3VyZWx5IHdpdGggQyBhbmQgcHJvdmlkZSB0aGUgbmVjZXNzYXJ5DQprZXlzIG9yIGNyZWRlbnRp YWxzLiBJbiB0aGlzIGNhc2UgQ0FNIGhhcyBubyBzZWN1cml0eSBmdW5jdGlvbi4gQnV0IHRoZQ0K YXJjaGl0ZWN0dXJlIHByZXNjcmliZXMgdGhhdCBpbnRlcmFjdGlvbiBiZXR3ZWVuIEMgYW5kIFNB TSBpcyBuZXZlciBkb25lDQpkaXJlY3RseSwgYnV0IHZpYSBDQU0uIEluIHRoaXMgY2FzZSBDQU0g ZG9lcyBub3QgaGF2ZSBhIHJvbGUgYXQgYWxsLCBzbw0KdGhlcmUgaXMgbm90IG9ubHkgYSBkaWZm ZXJlbmNlIHdoZXJlIENBTSBpcyBob3N0ZWQsIGJ1dCBpbiBpdHMgZnVuY3Rpb24uDQoNCg0KDQo4 LjENCg0K4oCiIE5leHQgdG8gbGFzdCBwYXJhZ3JhcGg6IEFsdGhvdWdoIGNvbmZpZGVudGlhbGl0 eSBhbmQgaW50ZWdyaXR5DQpwcm90ZWN0aW9uIGFyZSB0aGUgc2VjdXJpdHkgb2JqZWN0aXZlcyBj b25zaWRlcmVkIGluIHRoaXMgZG9jdW1lbnQsIHRoZXJlDQppcyBubyBjb25zaWRlcmF0aW9uIG9m IGVuZC10by1lbmQgc2VjdXJpdHkgaW4gdGhlIHByZXNlbmNlIG9mIGludGVybWVkaWFyeQ0Kbm9k ZXMgKHdoaWNoIHdvdWxkIGluZHVjZSBEVExTIGhvcCBieSBob3ApDQoNCjguMg0KDQrigKIgSW4g Y2FzZSBPQXV0aCBpcyBhcHBsaWVkIHRvIHRoZSAibGVzcyBjb25zdHJhaW5lZCBsZXZlbCIsIHdo YXQgYXJlIHRoZQ0KcHJvdGVjdGVkIHJlc291cmNlcyBhdCBTQU0gYWNjZXNzZWQgYnkgQ0FNPyAo QWNjZXNzIHRva2Vucz8pDQoNCg0KDQoNCkJlc3QgcmVnYXJkcw0KR8O2cmFuDQoNCg0KDQoNCg0K T24gMjAxNS0wMy0xMCAxNDoyNSwgIlN0ZWZhbmllIEdlcmRlcyIgPGdlcmRlc0B0emkuZGU+IHdy b3RlOg0KDQo+SGkgYWxsLA0KPg0KPlBsZWFzZSBmaW5kIGF0dGFjaGVkIHRoZSBuZXcgdmVyc2lv biBub3RpZmljYXRpb24gZm9yIHRoZSBhY3RvcnMgZHJhZnQuDQo+DQo+VGhlIG1haW4gY2hhbmdl cyBhcmU6DQo+LSBUbyBhZGRyZXNzIGNvbW1lbnRzIChlLmcuLCBpbiB0aGUgQUNFIHNlc3Npb24g aW4gSG9ub2x1bHUpIE9BdXRoDQo+dGVybWlub2xvZ3kgd2FzIHJlbW92ZWQgdG8gYXZvaWQgbWlz dW5kZXJzdGFuZGluZ3MuDQo+LSBUaGUgdGVybSAib3duZXIiIHdhcyByZXBsYWNlZCBzaW5jZSBj b21tZW50cyBvbiB0aGUgbGlzdCBpbmRpY2F0ZWQNCj50aGF0IG93bmVyIG1pZ2h0IG5vdCBiZSBh IHN1aXRhYmxlIHRlcm0uDQo+LSBBIHNlY3Rpb24gYWJvdXQgYXV0b25vbW91cyBjb21tdW5pY2F0 aW9uIHdhcyBhZGRlZCB0byBwb2ludCBvdXQgdGhhdA0KPnRoZXJlIGlzIG5vdCBhbHdheXMgYW4g YWN0aXZlIHVzZXIgaW4gY29uc3RyYWluZWQgZW52aXJvbm1lbnRzLCBhbmQNCj5kZXZpY2VzIG5l ZWQgdG8gYmUgYWJsZSB0byBlbmZvcmNlIHRoZSB1c2VyJ3Mgc2VjdXJpdHkgcG9saWNpZXMNCj5h dXRvbm9tb3VzbHkuDQo+DQo+Q29tbWVudHMgYXJlIHZlcnkgd2VsY29tZS4NCj4NCj5UaGFua3Ms DQo+U3RlZmZpDQo+DQo+DQo+LS0tLS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2UgLS0tLS0tLS0NCj5T dWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWdlcmRlcy1hY2UtYWN0 b3JzLTAzLnR4dA0KPkRhdGU6IE1vbiwgMDkgTWFyIDIwMTUgMTY6NDk6MjAgLTA3MDANCj5Gcm9t OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj5UbzogU3RlZmFuaWUgR2VyZGVzIDxnZXJkZXNA dHppLm9yZz4sIFN0ZWZhbmllIEdlcmRlcyA8Z2VyZGVzQHR6aS5vcmc+DQo+DQo+DQo+QSBuZXcg dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWdlcmRlcy1hY2UtYWN0b3JzLTAzLnR4dA0KPmhhcyBiZWVu IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgU3RlZmFuaWUgR2VyZGVzIGFuZCBwb3N0ZWQgdG8g dGhlDQo+SUVURiByZXBvc2l0b3J5Lg0KPg0KPk5hbWU6CQlkcmFmdC1nZXJkZXMtYWNlLWFjdG9y cw0KPlJldmlzaW9uOgkwMw0KPlRpdGxlOgkJQWN0b3JzIGluIHRoZSBBQ0UgQXJjaGl0ZWN0dXJl DQo+RG9jdW1lbnQgZGF0ZToJMjAxNS0wMy0wOQ0KPkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNz aW9uDQo+UGFnZXM6CQkyNg0KPlVSTDogDQo+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtZ2VyZGVzLWFjZS1hY3RvcnMtMDMudHh0DQo+U3RhdHVzOiAgICAgICAgIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWdlcmRlcy1hY2UtYWN0b3JzLw0K Pkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nZXJkZXMt YWNlLWFjdG9ycy0wMw0KPkRpZmY6ICAgICAgICAgICANCj5odHRwOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1nZXJkZXMtYWNlLWFjdG9ycy0wMw0KPg0KPkFic3RyYWN0Og0KPiAg ICBDb25zdHJhaW5lZCBub2RlcyBhcmUgc21hbGwgZGV2aWNlcyB3aGljaCBhcmUgbGltaXRlZCBp biB0ZXJtcyBvZg0KPiAgICBwcm9jZXNzaW5nIHBvd2VyLCBtZW1vcnksIG5vbi12b2xhdGlsZSBz dG9yYWdlIGFuZCB0cmFuc21pc3Npb24NCj4gICAgY2FwYWNpdHkuICBEdWUgdG8gdGhlc2UgY29u c3RyYWludHMsIGNvbW1vbmx5IHVzZWQgc2VjdXJpdHkgcHJvdG9jb2xzDQo+ICAgIGFyZSBub3Qg ZWFzaWx5IGFwcGxpY2FibGUuICBOZXZlcnRoZWxlc3MsIGFuIGF1dGhlbnRpY2F0aW9uIGFuZA0K PiAgICBhdXRob3JpemF0aW9uIHNvbHV0aW9uIGlzIG5lZWRlZCB0byBlbnN1cmUgdGhlIHNlY3Vy aXR5IG9mIHRoZXNlDQo+ICAgIGRldmljZXMuDQo+DQo+ICAgIER1ZSB0byB0aGUgbGltaXRhdGlv bnMgb2YgdGhlIGNvbnN0cmFpbmVkIG5vZGVzIGl0IGlzIGVzcGVjaWFsbHkNCj4gICAgaW1wb3J0 YW50IHRvIGRldmVsb3AgYSBsaWdodC13ZWlnaHQgc2VjdXJpdHkgc29sdXRpb24gd2hpY2ggaXMN Cj4gICAgYWRqdXN0ZWQgdG8gdGhlIHJlbGV2YW50IHNlY3VyaXR5IG9iamVjdGl2ZXMgb2YgZWFj aCBwYXJ0aWNpcGF0aW5nDQo+ICAgIHBhcnR5IGluIHRoaXMgZW52aXJvbm1lbnQuICBOZWNlc3Nh cnkgc2VjdXJpdHkgbWVhc3VyZXMgbXVzdCBiZQ0KPiAgICBpZGVudGlmaWVkIGFuZCBhcHBsaWVk IHdoZXJlIG5lZWRlZC4NCj4NCj4gICAgSW4gdGhpcyBkb2N1bWVudCwgdGhlIHJlcXVpcmVkIHNl Y3VyaXR5IHJlbGF0ZWQgdGFza3MgYXJlIGlkZW50aWZpZWQNCj4gICAgYXMgZ3VpZGFuY2UgZm9y IHRoZSBkZXZlbG9wbWVudCBvZiBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbg0KPiAg ICBzb2x1dGlvbnMgZm9yIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy4gIEJhc2VkIG9uIHRoZSB0 YXNrcywgYW4NCj4gICAgYXJjaGl0ZWN0dXJlIGlzIGRldmVsb3BlZCB0byByZXByZXNlbnQgdGhl IHJlbGF0aW9uc2hpcHMgYmV0d2VlbiB0aGUNCj4gICAgbG9naWNhbCBmdW5jdGlvbmFsIGVudGl0 aWVzIGludm9sdmVkLg0KPg0KPiANCj4NCj4NCj4NCj5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0 YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPnN1Ym1pc3Npb24NCj51 bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xz LmlldGYub3JnLg0KPg0KPlRoZSBJRVRGIFNlY3JldGFyaWF0DQo+DQo+DQo+DQo+DQo+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5BY2UgbWFpbGluZyBs aXN0DQo+QWNlQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9hY2UNCg0K From nobody Tue Mar 17 09:11: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 924A81A1AFB for ; Tue, 17 Mar 2015 09:11:53 -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 A7COaLpyZEz0 for ; Tue, 17 Mar 2015 09:11:52 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E2311A873D for ; Tue, 17 Mar 2015 09:11:37 -0700 (PDT) X-AuditID: c1b4fb2d-f79a46d0000006b4-29-55085236fad9 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 05.04.01716.63258055; Tue, 17 Mar 2015 17:11:34 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.196]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0210.002; Tue, 17 Mar 2015 17:11:34 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Hannes Tschofenig , Kepeng Li , "Ace@ietf.org" Thread-Topic: Architecture, terminology and problem statement Thread-Index: AQHQYM0J8wg5T9I84UmvAwjMW1dwTg== Date: Tue, 17 Mar 2015 16:11:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="utf-8" Content-ID: <19A2846086CB054BB06069090C99D097@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM+Jvja5ZEEeoQc9PU4vv33qYLZbuvMdq cXl+kQOzx8S3H1k8Fm/az+axZMlPpgDmKC6blNSczLLUIn27BK6Ml/8PsRYsEq+YNG87SwPj FbEuRk4OCQETiQc7vzFD2GISF+6tZ+ti5OIQEjjCKHH33nsmCGcJo8SCBWuZQKrYBFwkHjQ8 ArNFBKok1h+ayQhiCwtYSDy7vhPI5gCK20qsaDSGKNGTmHXuI9gCFgFVidb3vewgNi9Q+fqX C9hAbEagxd9PrQEbySwgLnHryXwmiIMEJJbsOQ91nKjEy8f/WEFsUaCZK683sUHElSR+bLjE ArKWWUBTYv0ufYgx1hI9s9dCjVSUmNL9EGqtoMTJmU9YJjCKzkKybRZC9ywk3bOQdM9C0r2A kXUVo2hxanFxbrqRsV5qUWZycXF+nl5easkmRmA0HdzyW3cH4+rXjocYBTgYlXh4N8xgDxVi TSwrrsw9xCjNwaIkzmtnfChESCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUAyMvO/ORY9odz+UP alTza0Sahwte/hlSEZL1S3oL/+0rx6olorPfPeBjVYpR8p5s61Ov3X50+xOFuXfNPb6+ud4a 6Jel9broQvKUHbMPLcss3P5B/9mr/PPvzyzcxVPvbHpM4+G3xB0s3il84eeff/si7mV/fUFh 0oFlV8/wRFx1U/u/41d1EacSS3FGoqEWc1FxIgCYEupGhwIAAA== Archived-At: Subject: [Ace] Architecture, terminology and problem statement 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, 17 Mar 2015 16:11:53 -0000 DQpEZWFyIFdHIGNoYWlycywgYW5kIGFsbA0KDQpUaGVyZSBpcyBhIHNldCBvZiBkcmFmdHMgd2hp Y2ggZGlzY3VzcyBhcmNoaXRlY3R1cmUsIHRlcm1pbm9sb2d5IGFuZCBzY29wZQ0Kb2Ygd29yayBv biBpbiBBQ0UgaW5jbHVkaW5nOg0KDQpbMV0gIGRyYWZ0LWdyZWV2ZW5ib3NjaC1hY2UtY29tcGFy aXNvbg0KWzJdICBkcmFmdC1nZXJkZXMtYWNlLWFjdG9ycw0KWzNdICBkcmFmdC1zZWl0ei1hY2Ut cHJvYmxlbS1kZXNjcmlwdGlvbg0KDQpXZSBhbHJlYWR5IG5vdGVkIGR1cmluZyB0aGUgdXNlIGNh c2UgZGlzY3Vzc2lvbnMgdGhhdCBpdCBpcyBkaWZmaWN1bHQgdG8NCmFncmVlIG1vcmUgaW4gZGV0 YWlsIHdoYXQgaXMgdGhlIHByb2JsZW0gc3RhdGVtZW50IGZvciBBQ0UsIGFuZCB0aGlzDQpkaXNh Z3JlZW1lbnQgaXMgc2xvd2luZyBkb3duIHRoZSBwcm9ncmVzcyBvZiB0aGUgd29yay4NCg0KSSB3 b25kZXIgaWYgaXQgY291bGQgbWFrZSBzZW5zZSB0byB0cnkgdG8gaG9sZCBhIGZvY3VzZWQgZGlz Y3Vzc2lvbiBhYm91dA0KaGlnaC1sZXZlbCBpc3N1ZXMgaW4gYXJjaGl0ZWN0dXJlLCB0ZXJtaW5v bG9neSBhbmQgc2NvcGUgb2Ygd29yayBkdXJpbmcNCnRoZSBBQ0UgV0cgbWVldGluZyBpbiBEYWxs YXM/IFRoZSBwdXJwb3NlIHdvdWxkIGJlIHRvIGNvbWUgdG8gc29tZSB3b3JraW5nDQphc3N1bXB0 aW9uIG9uIHRoZXNlIC0gd2hpY2ggaW4gaXRzIGZpcnN0IGl0ZXJhdGlvbiBkb2Vzbid0IGhhdmUg dG8gYmUgYXQNCmFsbCBvbiB0aGUgc2FtZSBsZXZlbCBvZiBkZXRhaWwgYXMgdGhlIGRyYWZ0cy4N Cg0KTWF5YmUgdGhpcyBpcyB0b28gbmFpdmU/IEhlcmUgaXMgdGhlIGlkZWEgYW55d2F5Og0KDQpD b21wYXJpbmcgdGhlIGFyY2hpdGVjdHVyZSBvZiB0aGUgZGlmZmVyZW50IHByb3Bvc2FscyB0aGVy ZSBpcyBhIGJpZw0Kb3ZlcmxhcCBpbiBmdW5jdGlvbmFsaXR5IG9mIG5vZGVzIChhbHRob3VnaCBu b3QgaW4gdGVybWlub2xvZ3ksIGJ1dCBsZXQncw0Kd2FpdCB3aXRoIHRoYXQpLiBDb3VsZCB3ZSBz a2V0Y2ggYSBjb21tb24gZGVub21pbmF0b3IsIGRlc2NyaWJlIHdoYXQgYXJlDQp0aGUgZGlmZmVy ZW5jZXMsIGFuZCBoYXZlIGEgZGlzY3Vzc2lvbiBpbiB0aGUgV0c/DQoNCkdpdmVuIHRoZSBzZXQg b2Ygbm9kZXMgYW5kIGFzc29jaWF0ZWQgZnVuY3Rpb25zIGluIHRoZSBhcmNoaXRlY3R1cmUsIHdl DQpjb3VsZCB0cnkgdG8gZm9ybXVsYXRlIHdoYXQgaXMgdGhlIGhpZ2gtbGV2ZWwgInNlY3VyaXR5 IG9iamVjdGl2ZXMiIGluDQp0ZXJtcyBvZiBpbnRlcmFjdGlvbnMgYmV0d2VlbiB0aGVzZSBub2Rl cy4gVGhpcyBjb3VsZCBiZSBleHByZXNzZWQgZm9yDQpleGFtcGxlIGxpa2UgaW4gU2VjdGlvbiA2 IG9mIFsyXSAoVGFza3MpIG9yIGxpa2UgaW4gU2VjdGlvbiAyLCBwYWdlIDUsIG9mDQpbM10gKHBy b3RlY3RpbmcgaW5mb3JtYXRpb24gZmxvd3MpLiBBZ2Fpbiwgd2hhdCBpcyB0aGUgY29tbW9uIGRl bm9taW5hdG9yDQphbmQgd2hhdCBhcmUgdGhlIGRpZmZlcmVuY2VzIGJldHdlZW4gZGlmZmVyZW50 IHByb3Bvc2Fscy4NCg0KTk9URTogVGhpcyBmaXJzdCBpdGVyYXRpb24gd291bGQgbm90IGJlIG9u IHRoZSBsZXZlbCBvZiBlLmcuDQpkaXN0aW5ndWlzaGluZyBiZXR3ZWVuIFB1c2ggYW5kIFB1bGwg YXMgaW4gU2VjdGlvbiA0IG9mIFsxXSwgYnV0IGV2ZW4gbW9yZQ0KYWJzdHJhY3Q7IGZyb20gd2hh dCBub2RlIGRvZXMgdGhlIGluZm9ybWF0aW9uIGZsb3cgb3JpZ2luYXRlIGFuZCB3aGF0IGlzDQp0 aGUgZGVzdGluYXRpb24gbm9kZT8NCg0KV2UgY291bGQgcHJvZ3Jlc3Mgb24gdGVybWlub2xvZ3kg YXMgd2VsbC4gT24gYSBoaWdoIGxldmVsIHRoZXJlIGFyZSB0d28NCnByb3Bvc2FsczogZGVzaWdu IG91ciBvd24gdGVybWlub2xvZ3kgb3IgcmV1c2UgZXhpc3RpbmcgdGVybWlub2xvZ3kuIE1heWJl DQp3ZSBjb3VsZCBhc2sgdGhlIHdvcmtpbmcgZ3JvdXAgZm9yIGd1aWRhbmNlIGhlcmU/DQoNCklm IHdlIGNhbid0IHJlYWNoIGFsbCB0aGUgd2F5IGluIHRoZSBtZWV0aW5nLCBtYXliZSB3ZSBjYW4g YXNzaWduIGEgdGVhbQ0KdG8gd29yayBvbiB0aGF0IGFuZCByZXBvcnQgYmFjayB0byB0aGUgbGlz dD8NCg0KDQoNCkp1c3Qgc29tZSBsb29zZSB0aG91Z2h0cy4NCg0KQmVzdCByZWdhcmRzLA0KR8O2 cmFuDQoNCg0K From nobody Tue Mar 17 09:38: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 258B11A1B4B for ; Tue, 17 Mar 2015 09:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVwa3XXwnqFM for ; Tue, 17 Mar 2015 09:38:25 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (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 B20571A1A7E for ; Tue, 17 Mar 2015 09:38:25 -0700 (PDT) Received: from [192.168.2.2] ([88.235.141.59]) by mrelay.perfora.net (mreueus001) with ESMTPA (Nemesis) id 0LqSzX-1ZBu9X2LHl-00duQj; Tue, 17 Mar 2015 17:38:14 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Alper Yegin In-Reply-To: Date: Tue, 17 Mar 2015 18:37:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7468AB9C-1663-4F56-B557-6A99EDC692CD@yegin.org> References: To: =?iso-8859-1?Q?G=F6ran_Selander?= X-Mailer: Apple Mail (2.1283) X-Provags-ID: V03:K0:GXFMdPEyAyF1BvwhEsRH3wdihRx7U5+OeW2PBJu2GHtGNxk8vqW ioFS6oU/xIxfhk0s2NkuzaHbky/r1BfIrjN4BShHeQJis57YEIDzmnITMYctyKTQ27zNIkZ 0oAA3l3Cw109WFPY3AtD5ld9Ex24jyKoDjUrlx9cvUaHwP26N6R9NfWT8ExSwg3w4NOFFPR Ia7iN/1YbxWyhD4bBtI1w== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: Hannes Tschofenig , "Ace@ietf.org" , Kepeng Li Subject: Re: [Ace] Architecture, terminology and problem statement 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, 17 Mar 2015 16:38:27 -0000 I'd say a side-discussion prior to the WG meeting would speed things up.=20= On Mar 17, 2015, at 6:11 PM, G=F6ran Selander wrote: >=20 > Dear WG chairs, and all >=20 > There is a set of drafts which discuss architecture, terminology and = scope > of work on in ACE including: >=20 > [1] draft-greevenbosch-ace-comparison > [2] draft-gerdes-ace-actors > [3] draft-seitz-ace-problem-description >=20 > We already noted during the use case discussions that it is difficult = to > agree more in detail what is the problem statement for ACE, and this > disagreement is slowing down the progress of the work. >=20 > I wonder if it could make sense to try to hold a focused discussion = about > high-level issues in architecture, terminology and scope of work = during > the ACE WG meeting in Dallas? The purpose would be to come to some = working > assumption on these - which in its first iteration doesn't have to be = at > all on the same level of detail as the drafts. >=20 > Maybe this is too naive? Here is the idea anyway: >=20 > Comparing the architecture of the different proposals there is a big > overlap in functionality of nodes (although not in terminology, but = let's > wait with that). Could we sketch a common denominator, describe what = are > the differences, and have a discussion in the WG? >=20 > Given the set of nodes and associated functions in the architecture, = we > could try to formulate what is the high-level "security objectives" in > terms of interactions between these nodes. This could be expressed for > example like in Section 6 of [2] (Tasks) or like in Section 2, page 5, = of > [3] (protecting information flows). Again, what is the common = denominator > and what are the differences between different proposals. >=20 > NOTE: This first iteration would not be on the level of e.g. > distinguishing between Push and Pull as in Section 4 of [1], but even = more > abstract; from what node does the information flow originate and what = is > the destination node? >=20 > We could progress on terminology as well. On a high level there are = two > proposals: design our own terminology or reuse existing terminology. = Maybe > we could ask the working group for guidance here? >=20 > If we can't reach all the way in the meeting, maybe we can assign a = team > to work on that and report back to the list? >=20 >=20 >=20 > Just some loose thoughts. >=20 > Best regards, > G=F6ran >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Tue Mar 17 19:17:20 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682D41A8A1C for ; Tue, 17 Mar 2015 19:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 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, 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 IQyTBBjxBYDq for ; Tue, 17 Mar 2015 19:17:18 -0700 (PDT) Received: from out4133-2.mail.aliyun.com (out4133-2.mail.aliyun.com [42.120.133.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1461A89FE for ; Tue, 17 Mar 2015 19:17:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1426645036; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=4rSi4h1m2rSt5IgrhLch4FLqE9ZSlfYQGVXlF7g499s=; b=kgcl+tUeXWS3sTT/qZ3fHxJzieSdpjcZ9hYs2QZlQv181uwI3PQKZNcEmbg7FFsnz6gTBbfMzy81GlP9zgK893Ppshrkv/aRDNL1JDyZMM4OPGQhpn5Pt524xjKhcj7dPbP3iZyNDm6MS7YiQh6o+mu4K3IO52rrdlVc+TshNXM= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R581e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41f05025; MF=kepeng.lkp@alibaba-inc.com; PH=DS; RN=4; RT=4; SR=0; Received: from 10.1.148.174(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.74.157) by smtp.aliyun-inc.com(127.0.0.1); Wed, 18 Mar 2015 10:17:05 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Wed, 18 Mar 2015 10:17:00 +0800 From: "Kepeng Li" To: Alper Yegin , =?ISO-8859-1?B?R/ZyYW4=?= Selander , "Ace@ietf.org" Message-ID: Thread-Topic: [Ace] Side meeting in Dallas Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Cc: Hannes Tschofenig Subject: [Ace] Side meeting in Dallas 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, 18 Mar 2015 02:17:19 -0000 >I'd say a side-discussion prior to the WG meeting would speed things up. Good idea. I created a doodle poll for the side discussion: http://doodle.com/d8rmzyt7nkzpg2f6 Please indicate your attendance. Candidate time:=20 Monday: 11:30 ~ 13:00, 19:10 ~ 18:40; Tuesday: 11:30 ~ 13:00. Thanks, Kind Regards Kepeng =E5=9C=A8 18/3/15 12:37 am=EF=BC=8C "Alper Yegin" =E5=86=99=E5=85=A5: >I'd say a side-discussion prior to the WG meeting would speed things up. > >On Mar 17, 2015, at 6:11 PM, G=C3=B6ran Selander wrote: > >>=20 >> Dear WG chairs, and all >>=20 >> There is a set of drafts which discuss architecture, terminology and >>scope >> of work on in ACE including: >>=20 >> [1] draft-greevenbosch-ace-comparison >> [2] draft-gerdes-ace-actors >> [3] draft-seitz-ace-problem-description >>=20 >> We already noted during the use case discussions that it is difficult to >> agree more in detail what is the problem statement for ACE, and this >> disagreement is slowing down the progress of the work. >>=20 >> I wonder if it could make sense to try to hold a focused discussion >>about >> high-level issues in architecture, terminology and scope of work during >> the ACE WG meeting in Dallas? The purpose would be to come to some >>working >> assumption on these - which in its first iteration doesn't have to be at >> all on the same level of detail as the drafts. >>=20 >> Maybe this is too naive? Here is the idea anyway: >>=20 >> Comparing the architecture of the different proposals there is a big >> overlap in functionality of nodes (although not in terminology, but >>let's >> wait with that). Could we sketch a common denominator, describe what are >> the differences, and have a discussion in the WG? >>=20 >> Given the set of nodes and associated functions in the architecture, we >> could try to formulate what is the high-level "security objectives" in >> terms of interactions between these nodes. This could be expressed for >> example like in Section 6 of [2] (Tasks) or like in Section 2, page 5, >>of >> [3] (protecting information flows). Again, what is the common >>denominator >> and what are the differences between different proposals. >>=20 >> NOTE: This first iteration would not be on the level of e.g. >> distinguishing between Push and Pull as in Section 4 of [1], but even >>more >> abstract; from what node does the information flow originate and what is >> the destination node? >>=20 >> We could progress on terminology as well. On a high level there are two >> proposals: design our own terminology or reuse existing terminology. >>Maybe >> we could ask the working group for guidance here? >>=20 >> If we can't reach all the way in the meeting, maybe we can assign a team >> to work on that and report back to the list? >>=20 >>=20 >>=20 >> Just some loose thoughts. >>=20 >> Best regards, >> G=C3=B6ran >>=20 >>=20 >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace From nobody Wed Mar 18 06:59: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 7AC761A0318 for ; Wed, 18 Mar 2015 06:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 jzaBeAdjnL24 for ; Wed, 18 Mar 2015 06:59:03 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F1E31A02BE for ; Wed, 18 Mar 2015 06:59:02 -0700 (PDT) Received: from [192.168.131.145] ([80.92.115.8]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0La2Xx-1ZEkyi2GpZ-00ljkb; Wed, 18 Mar 2015 14:58:57 +0100 Message-ID: <5509849F.9070704@gmx.net> Date: Wed, 18 Mar 2015 14:58:55 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= , Kepeng Li , "Ace@ietf.org" References: In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DxiRwOUhtcfh8iDIQhL1vjFrSIdiCCahn" X-Provags-ID: V03:K0:B2QaVliiU4cgcalzPBFU4mEMWMKAeAHfGhaa6kpzeXi5yOd+tyn 8KxT4BqoEJRUMDqKF15uO9y/nbMOrkS8n6YK6hAbwjT7lE9SnSN4cA28q0/RZONqDlUO5JC xWjNgqoejl8BUINohJufQ72+X4yoasjUEvrz0e/FvgqIbUoQXzKH4/CkOePTTJASX+jkMNe qwkFaJhJXg6wZxL0nXTLg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [Ace] Architecture, terminology and problem statement 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, 18 Mar 2015 13:59:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DxiRwOUhtcfh8iDIQhL1vjFrSIdiCCahn Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Goeran, your proposal makes sense to me. In fact I made similar observations when advertising the work we do in ACE to others. Quite naturally, many have a preferred IoT deployment model in mind and for some of those deployments the features we discuss aren't even a problem yet or are solved in other ways today. Hence, it gets tricky to communicate the value proposition of ACE. Ciao Hannes On 03/17/2015 05:11 PM, G=C3=B6ran Selander wrote: >=20 > Dear WG chairs, and all >=20 > There is a set of drafts which discuss architecture, terminology and sc= ope > of work on in ACE including: >=20 > [1] draft-greevenbosch-ace-comparison > [2] draft-gerdes-ace-actors > [3] draft-seitz-ace-problem-description >=20 > We already noted during the use case discussions that it is difficult t= o > agree more in detail what is the problem statement for ACE, and this > disagreement is slowing down the progress of the work. >=20 > I wonder if it could make sense to try to hold a focused discussion abo= ut > high-level issues in architecture, terminology and scope of work during= > the ACE WG meeting in Dallas? The purpose would be to come to some work= ing > assumption on these - which in its first iteration doesn't have to be a= t > all on the same level of detail as the drafts. >=20 > Maybe this is too naive? Here is the idea anyway: >=20 > Comparing the architecture of the different proposals there is a big > overlap in functionality of nodes (although not in terminology, but let= 's > wait with that). Could we sketch a common denominator, describe what ar= e > the differences, and have a discussion in the WG? >=20 > Given the set of nodes and associated functions in the architecture, we= > could try to formulate what is the high-level "security objectives" in > terms of interactions between these nodes. This could be expressed for > example like in Section 6 of [2] (Tasks) or like in Section 2, page 5, = of > [3] (protecting information flows). Again, what is the common denominat= or > and what are the differences between different proposals. >=20 > NOTE: This first iteration would not be on the level of e.g. > distinguishing between Push and Pull as in Section 4 of [1], but even m= ore > abstract; from what node does the information flow originate and what i= s > the destination node? >=20 > We could progress on terminology as well. On a high level there are two= > proposals: design our own terminology or reuse existing terminology. Ma= ybe > we could ask the working group for guidance here? >=20 > If we can't reach all the way in the meeting, maybe we can assign a tea= m > to work on that and report back to the list? >=20 >=20 >=20 > Just some loose thoughts. >=20 > Best regards, > G=C3=B6ran >=20 >=20 --DxiRwOUhtcfh8iDIQhL1vjFrSIdiCCahn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVCYSfAAoJEGhJURNOOiAtf1cH/1bwnv3y0UC6yYnZ55c99WqK HBvt2Y/xAv0x5gnGQ51qZFgSCDM4OPL5edNJhzE7fZENQs63wUInNq9GcD7M9KZ6 a8huqpWfBtIJhtuoDhZB+v2VsAR1QT8xca4V5RS+fDEHiJqoiMnNMyb5cJgxYmi4 RxC+UuYvdX1rEpmWQdl9CSUKLCejtjq2BMgLuL5Jntvt362q3AbAW/bhypqqFZTQ 1hf+bWeDwi2A+31kXZrFlZH17dcf5zgvI789ssiLBAuSQdC6tDpshzHUSwR2qiN8 xjBH02axGA0021pXVAINGdrrrGAkkX6bSkPEGSzc7uAOwRTeOtNLTz3Hkh4SXe0= =Opq5 -----END PGP SIGNATURE----- --DxiRwOUhtcfh8iDIQhL1vjFrSIdiCCahn-- From nobody Thu Mar 19 01:40: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 1364B1A6FE7 for ; Thu, 19 Mar 2015 01:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qsRgB5lMGpQ for ; Thu, 19 Mar 2015 01:40:19 -0700 (PDT) Received: from out4133-98.mail.aliyun.com (out4133-98.mail.aliyun.com [42.120.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id 57E141A00C2 for ; Thu, 19 Mar 2015 01:40:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1426754418; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=ANMhZHmk52Gf03fqGD73EJbFGYAZiVcpz3KNTTC6p+E=; b=IHORVf5iVoSqfRCj5La2h288NbhnmxFYTh5CVR4Fe+EIeoEM/4SfxIu+NGx8+mq+hRj28N2XEPomORBngM2lhnuKtuuHmQCzs0+KO/9kXcv3kAcKYovvWQXRreVgR8YZg7i3uSQM/9Redkg/TUXZhDDWONeRvYszdTdJMOXj328= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R141e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41g03016; MF=kepeng.lkp@alibaba-inc.com; PH=DW; RN=2; RT=2; SR=0; Received: from WS-web (kepeng.lkp@alibaba-inc.com[106.120.117.188]) by r41f05013.xy2.aliyun.com at Thu, 19 Mar 2015 16:40:13 +0800 Date: Thu, 19 Mar 2015 16:40:13 +0800 From: "Kepeng Li" To: "Ace@ietf.org" Message-ID: X-Mailer: Alimail-Mailagent revision 2684282 MIME-Version: 1.0 References: , 5509849F.9070704@gmx.net In-Reply-To: 5509849F.9070704@gmx.net Content-Type: multipart/alternative; boundary="----=ALIBOUNDARY_24175_4ac88940_550a8b6d_5229f" Archived-At: Cc: Hannes Tschofenig Subject: [Ace] =?utf-8?q?_Agenda_for_Dallas_F2F_meeting?= X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Kepeng Li List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 08:40:24 -0000 ------=ALIBOUNDARY_24175_4ac88940_550a8b6d_5229f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello all,Please find the agenda for ACE Dallas F2F meeting:http://www.ietf.or= g/proceedings/92/agenda/agenda-92-acePresenters, please send your slides to Ha= nnes and me before the meeting time (Tuesday afternoon).Thanks,Kind RegardsKep= eng=0A ------=ALIBOUNDARY_24175_4ac88940_550a8b6d_5229f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all,

Please find the agenda for ACE Dallas F2F meeti= ng:
=
Presenters, please send your slides to H= annes and me before the meeting time (Tuesday afternoon).

Thanks,

Kind Regards
Kepeng

------=ALIBOUNDARY_24175_4ac88940_550a8b6d_5229f-- From nobody Thu Mar 19 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 6AF811A6FE7 for ; Thu, 19 Mar 2015 01:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.301 X-Spam-Level: * X-Spam-Status: No, score=1.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7l38bvGUdZx for ; Thu, 19 Mar 2015 01:45:31 -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 EAC3C1A8966 for ; Thu, 19 Mar 2015 01:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1426754729; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=SCMmVd2iJNx5EiI5uOUBwC9jIPAOj6qTPjVRe8SSDd4=; b=pxanl4GfEqY6+ivxzox8CuZnLFGEv+JplISu/fP2zt6H40I5zwUeK+8Z+R9DZ6l5zXF5cFnrwC3nU/OH+0FFivhE22LTTfCCKeOaKwuYNNfXM58tBWcH2WhbsnVPZJ/1ShTOGycZIBGfhqApReqwt1QDTwUn7exT+AH+M//vAws= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R121e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41g03022; MF=kepeng.lkp@alibaba-inc.com; PH=DW; RN=2; RT=2; SR=0; Received: from WS-web (kepeng.lkp@alibaba-inc.com[106.120.117.188]) by r41g03009.xy2.aliyun.com at Thu, 19 Mar 2015 16:45:18 +0800 Date: Thu, 19 Mar 2015 16:45:18 +0800 From: "Kepeng Li" To: "Ace" Message-ID: X-Mailer: Alimail-Mailagent revision 2684282 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=ALIBOUNDARY_19751_46659940_550a8c9e_52081" Archived-At: Cc: Hannes Tschofenig Subject: [Ace] =?utf-8?q?=5BACE=5D_Side_meeting_in_Dallas?= X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Kepeng Li List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 08:45:32 -0000 ------=ALIBOUNDARY_19751_46659940_550a8c9e_52081 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello all,According to the doodle poll, our side meeting will be on Monday (23= rd Mar, 2015), =C2=A019:10 ~ 20:40, local time.http://doodle.com/d8rmzyt7nkzpg= 2f62uffu4eq/admin#tableLet's meet at the end of the meeting room after the Tec= hnical Plenary meeting.Thanks,Kind RegardsKepeng=0A=0A ------=ALIBOUNDARY_19751_46659940_550a8c9e_52081 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all,

According to the doodle poll, our side meeting = will be on Monday (23rd Mar, 2015),  19:10 ~ 20:40, local time.
http://d= oodle.com/d8rmzyt7nkzpg2f62uffu4eq/admin#table

Let's meet at the end of the meeting room after the Tec= hnical Plenary meeting.

Thanks= ,

Kind Regards
K= epeng


------=ALIBOUNDARY_19751_46659940_550a8c9e_52081-- From nobody Thu Mar 19 02:00: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 A1B041A00BE for ; Thu, 19 Mar 2015 02:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ll19VHgWx6My for ; Thu, 19 Mar 2015 02:00:54 -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 82A731A1A50 for ; Thu, 19 Mar 2015 02:00:54 -0700 (PDT) Received: from [192.168.131.145] ([80.92.115.8]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M6ioC-1ZUjeI1ZQ4-00wYfB; Thu, 19 Mar 2015 10:00:50 +0100 Message-ID: <550A9041.2040606@gmx.net> Date: Thu, 19 Mar 2015 10:00:49 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Kepeng Li , Ace References: In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ormrrUkVSNNJcq58dxU8kJIdUXXrroMRK" X-Provags-ID: V03:K0:9GsUOrQeRSneIxiDVA7vRo9Q+iWNDyRSpWm0PPHHgS3zwzdaHWq ikbYwzw6H+RKcTgrmeFqsDDCZZH3QeQvm3wg22EfQ60PMJv8u7raz2FopJmHOe3AuWXok9u PP/o4psFi06ueYC7lBB7L+3mNQUF1Ys+WyfmnlS+YZORNeheiqDKUxNXz0YK4cxI+9iGFLe xIvfbDK8+9ETiqcf0CmTg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [Ace] [ACE] Side meeting in Dallas 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, 19 Mar 2015 09:00:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ormrrUkVSNNJcq58dxU8kJIdUXXrroMRK Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable And, btw, the technical topic on the agenda for the IAB technical plenary is about 'smart objects'. Hence, it might make sense to attend it= =2E On 03/19/2015 09:45 AM, Kepeng Li wrote: > Hello all, >=20 > According to the doodle poll, our side meeting will be on Monday (23rd > Mar, 2015), 19:10 ~ 20:40, local time. > http://doodle.com/d8rmzyt7nkzpg2f62uffu4eq/admin#table >=20 > Let's meet at the end of the meeting room after the Technical Plenary > meeting. >=20 > Thanks, >=20 > Kind Regards > Kepeng >=20 >=20 --ormrrUkVSNNJcq58dxU8kJIdUXXrroMRK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVCpBBAAoJEGhJURNOOiAtvN4H/iv4wubiVUGZ06pL4EAck705 4WQpSHsZpDK0FFbRevlkIKdSPtzCVFN+8mbHGSW1IAG4qlUlDM2+QxnLH5Dz2MnO B28IR7tJXmxBMvzvETsnlIV2ABMhJT2OtPRp4qO6KG/7yMQBFi3E4X/v6KFV4WdL x1+Ll56ygq3cOFYpH/EAJwcV1iS6NLqqwhfTDBtR+U07HDbnFll3HoMpCggS4EcI P5X24PQZMxAzYEmVj4XC1RwQmBR/dusn8dOOd5qKoKF/6QhvgZbWn/HAO+qnzprY kKqMlydHSauCR+xOEfdBNTu69nLKUvHksChqe6Q6QY1gTM4YJ4pyNNgdcp/ea9A= =qFqZ -----END PGP SIGNATURE----- --ormrrUkVSNNJcq58dxU8kJIdUXXrroMRK-- From nobody Thu Mar 19 02:55: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 44C551A0173 for ; Thu, 19 Mar 2015 02:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 uHiaHo7hYFgP for ; Thu, 19 Mar 2015 02:55:40 -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 C6EFE1A00FF for ; Thu, 19 Mar 2015 02:55:39 -0700 (PDT) X-AuditID: c1b4fb25-f79126d000004b89-96-550a9d1935dc Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 4A.86.19337.91D9A055; Thu, 19 Mar 2015 10:55:38 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.196]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0210.002; Thu, 19 Mar 2015 10:55:37 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Ace Thread-Topic: [Ace] [ACE] Side meeting in Dallas Thread-Index: AQHQYiESVNSRSTA2dU2tcYgjhEP+sp0jkW8A Date: Thu, 19 Mar 2015 09:55:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_D13058952B657goranselanderericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM+Jvja7UXK5Qg/bpzBbfv/UwW7xqvcPs wOSxZMlPJo/eY7/ZApiiuGxSUnMyy1KL9O0SuDJ6prYzF2x1rmhbcJ21gfGAYxcjJ4eEgInE q/+bWSFsMYkL99azdTFycQgJHGGUWPVmJTuEs4RR4tTyfmaQKjYBF4kHDY+YQGwRoI5t1ztY QGxmAUWJPQ1HwWqEBfQlGtqPskLUGEhc+/IEyjaSuD95GZjNIqAqsXPGRqBtHBy8AhYSC3qc QcJCAk4Su59vAivhFHCWmNx8E2wVI9Cq76fWMEGsEpe49WQ+E8TRAhJL9pxnhrBFJV4+/gfW KyqgJ7HyehMbRFxJYtHtz1C9sRKTXl4Bi/MKCEqcnPmEZQKj2CwkY2chKZuFpGwW0KXMApoS 63fpz4J6eEr3Q3YIW0Oidc5cKNta4kpXKzOymgWMHKsYRYtTi5Ny042M9VKLMpOLi/Pz9PJS SzYxAqPz4JbfqjsYL79xPMQowMGoxMP7oZgrVIg1say4MvcQozQHi5I4r53xoRAhgfTEktTs 1NSC1KL4otKc1OJDjEwcnFINjMrHJP4s9GrZ7PXraHfF87PfWBx5D3vt+XIsxDtt/e7w7YsV 5ipaXc1T/R0VssZ544msH4G1LDYyp+8ZWX0VY99ftU4oI/LT+mvL7jwLDnz2w3n9jeO3K5Ll NiSmGX70XVvqu8bqW1vkhhucG479+bDc5mzq8qzXc7M1rrBz7S8//8tD+Yf3/zNKLMUZiYZa zEXFiQAoLSAjrwIAAA== Archived-At: Cc: Ludwig Seitz Subject: Re: [Ace] [ACE] Side meeting in Dallas 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, 19 Mar 2015 09:55:42 -0000 --_000_D13058952B657goranselanderericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxsLA0KDQoNCkx1ZHdpZyBhbmQgSSBoYXZlIHB1dCB0b2dldGhlciBzb21lIHNsaWRlcyBjb21i aW5pbmcgZGlmZmVyZW50IGlucHV0cyBvbiBhcmNoaXRlY3R1cmUsIHRlcm1pbm9sb2d5IGFuZCBw cm9ibGVtIHN0YXRlbWVudCBmb3IgQUNFLg0KDQoNClRoZSBhcmNoaXRlY3R1cmUgaXMgaW5zcGly ZWQgYnkgZHJhZnQtZ2VyZGVzLWFjZS1hY3RvcnMuIFRoZSB0ZXJtaW5vbG9neSBidWlsZHMgb24g VU1BL09BdXRoLiBUaGUgcHJvYmxlbSBzdGF0ZW1lbnQgaXMgYSBjb21iaW5hdGlvbiBvZiBkcmFm dC1zZWl0ei1hY2UtcHJvYmxlbS1kZXNjcmlwdGlvbiwgZHJhZnQtZ2VyZGVzLWFjZS1hY3RvcnMg YW5kIGRyYWZ0LXNlbGFuZGVyLWFjZS1vYmplY3Qtc2VjdXJpdHkuDQoNCg0KRm9vZCBmb3IgdGhv dWdodC4gSW5wdXQgZm9yIHRoZSBzaWRlIG1lZXRpbmcgb24gTW9uZGF5IGV2ZW5pbmcuIENvbW1l bnRzIGFyZSB3ZWxjb21lLg0KDQoNCkhlcmUgYXJlIHRoZSBzbGlkZXM6DQoNCmh0dHBzOi8vd3d3 LnNpY3Muc2Uvfmx1ZHdpZy9BQ0UvYXJjaC10ZXJtLW4tcHJvYi1kZXNjLTAwLnBkZg0KDQoNCkJl c3QgcmVnYXJkcywNCg0KR8O2cmFuDQoNCg0KRnJvbTogS2VwZW5nIExpIDxrZXBlbmcubGtwQGFs aWJhYmEtaW5jLmNvbTxtYWlsdG86a2VwZW5nLmxrcEBhbGliYWJhLWluYy5jb20+Pg0KUmVwbHkt VG86IEtlcGVuZyBMaSA8a2VwZW5nLmxrcEBhbGliYWJhLWluYy5jb208bWFpbHRvOmtlcGVuZy5s a3BAYWxpYmFiYS1pbmMuY29tPj4NCkRhdGU6IFRodXJzZGF5IDE5IE1hcmNoIDIwMTUgMDk6NDUN ClRvOiBBY2UgPGFjZUBpZXRmLm9yZzxtYWlsdG86YWNlQGlldGYub3JnPj4NCkNjOiBIYW5uZXMg VHNjaG9mZW5pZyA8aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldDxtYWlsdG86aGFubmVzLnRzY2hv ZmVuaWdAZ214Lm5ldD4+DQpTdWJqZWN0OiBbQWNlXSBbQUNFXSBTaWRlIG1lZXRpbmcgaW4gRGFs bGFzDQoNCkhlbGxvIGFsbCwNCg0KQWNjb3JkaW5nIHRvIHRoZSBkb29kbGUgcG9sbCwgb3VyIHNp ZGUgbWVldGluZyB3aWxsIGJlIG9uIE1vbmRheSAoMjNyZCBNYXIsIDIwMTUpLCAgMTk6MTAgfiAy MDo0MCwgbG9jYWwgdGltZS4NCmh0dHA6Ly9kb29kbGUuY29tL2Q4cm16eXQ3bmt6cGcyZjYydWZm dTRlcS9hZG1pbiN0YWJsZQ0KDQpMZXQncyBtZWV0IGF0IHRoZSBlbmQgb2YgdGhlIG1lZXRpbmcg cm9vbSBhZnRlciB0aGUgVGVjaG5pY2FsIFBsZW5hcnkgbWVldGluZy4NCg0KVGhhbmtzLA0KDQpL aW5kIFJlZ2FyZHMNCktlcGVuZw0KDQoNCg== --_000_D13058952B657goranselanderericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5BbGwsPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1z aXplOiAxMnB4OyBmb250LWZhbWlseTogSGVsdmV0aWNhOyI+THVkd2lnIGFuZCBJIGhhdmUgcHV0 IHRvZ2V0aGVyIHNvbWUgc2xpZGVzIGNvbWJpbmluZyBkaWZmZXJlbnQgaW5wdXRzIG9uIGFyY2hp dGVjdHVyZSwgdGVybWlub2xvZ3kgYW5kIHByb2JsZW0gc3RhdGVtZW50IGZvciBBQ0UuJm5ic3A7 PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDEycHg7IGZvbnQtZmFtaWx5 OiBIZWx2ZXRpY2E7IG1pbi1oZWlnaHQ6IDE0cHg7Ij4NCjxicj4NCjwvcD4NCjxwIHN0eWxlPSJt YXJnaW46IDBweDsgZm9udC1zaXplOiAxMnB4OyBmb250LWZhbWlseTogSGVsdmV0aWNhOyI+VGhl IGFyY2hpdGVjdHVyZSBpcyBpbnNwaXJlZCBieSBkcmFmdC1nZXJkZXMtYWNlLWFjdG9ycy4gVGhl IHRlcm1pbm9sb2d5IGJ1aWxkcyBvbiBVTUEvT0F1dGguIFRoZSBwcm9ibGVtIHN0YXRlbWVudCBp cyBhIGNvbWJpbmF0aW9uIG9mIGRyYWZ0LXNlaXR6LWFjZS1wcm9ibGVtLWRlc2NyaXB0aW9uLCBk cmFmdC1nZXJkZXMtYWNlLWFjdG9ycw0KIGFuZCBkcmFmdC1zZWxhbmRlci1hY2Utb2JqZWN0LXNl Y3VyaXR5LjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMnB4OyBmb250 LWZhbWlseTogSGVsdmV0aWNhOyBtaW4taGVpZ2h0OiAxNHB4OyI+DQo8YnI+DQo8L3A+DQo8cCBz dHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1mYW1pbHk6IEhlbHZldGlj YTsiPkZvb2QgZm9yIHRob3VnaHQuIElucHV0IGZvciB0aGUgc2lkZSBtZWV0aW5nIG9uIE1vbmRh eSBldmVuaW5nLiBDb21tZW50cyBhcmUgd2VsY29tZS4mbmJzcDs8L3A+DQo8cCBzdHlsZT0ibWFy Z2luOiAwcHg7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsiPjxicj4N CjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMnB4OyBmb250LWZhbWls eTogSGVsdmV0aWNhOyI+SGVyZSBhcmUgdGhlIHNsaWRlczo8L3A+DQo8cCBzdHlsZT0ibWFyZ2lu OiAwcHg7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgbWluLWhlaWdo dDogMTRweDsiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuc2ljcy5zZS9+bHVkd2lnL0FDRS9hcmNo LXRlcm0tbi1wcm9iLWRlc2MtMDAucGRmIj5odHRwczovL3d3dy5zaWNzLnNlL35sdWR3aWcvQUNF L2FyY2gtdGVybS1uLXByb2ItZGVzYy0wMC5wZGY8L2E+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjog MHB4OyBmb250LXNpemU6IDEycHg7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7Ij48YnI+DQo8L3A+ DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1mYW1pbHk6IEhl bHZldGljYTsiPkJlc3QgcmVnYXJkcyw8L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQt c2l6ZTogMTJweDsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsiPkfDtnJhbjwvcD4NCjxwIHN0eWxl PSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMnB4OyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBt aW4taGVpZ2h0OiAxNHB4OyI+DQo8YnI+DQo8L3A+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7 IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBB RERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47 IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25l OyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9t OiA8L3NwYW4+S2VwZW5nIExpICZsdDs8YSBocmVmPSJtYWlsdG86a2VwZW5nLmxrcEBhbGliYWJh LWluYy5jb20iPmtlcGVuZy5sa3BAYWxpYmFiYS1pbmMuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBz dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+UmVwbHktVG86IDwvc3Bhbj5LZXBlbmcgTGkgJmx0Ozxh IGhyZWY9Im1haWx0bzprZXBlbmcubGtwQGFsaWJhYmEtaW5jLmNvbSI+a2VwZW5nLmxrcEBhbGli YWJhLWluYy5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5E YXRlOiA8L3NwYW4+VGh1cnNkYXkgMTkgTWFyY2ggMjAxNSAwOTo0NTxicj4NCjxzcGFuIHN0eWxl PSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPkFjZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFj ZUBpZXRmLm9yZyI+YWNlQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13 ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj5IYW5uZXMgVHNjaG9mZW5pZyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQiPmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ8 L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3Nw YW4+W0FjZV0gW0FDRV0gU2lkZSBtZWV0aW5nIGluIERhbGxhczxicj4NCjwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9D S1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAg MCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJfX2FsaXl1 bl9lbWFpbF9ib2R5X2Jsb2NrIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiMwMDAwMDA7Zm9udC1zaXpl OjE0cHg7Zm9udC1mYW1pbHk6VGFob21hLEFyaWFsLFNUSGVpdGksU2ltU3VuOyI+DQpIZWxsbyBh bGwsPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjojMDAwMDAwO2ZvbnQtc2l6ZToxNHB4O2ZvbnQt ZmFtaWx5OlRhaG9tYSxBcmlhbCxTVEhlaXRpLFNpbVN1bjsiPg0KPGJyIGRhdGEtbWNlLWJvZ3Vz PSIxIj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IzAwMDAwMDtmb250LXNpemU6MTRweDtm b250LWZhbWlseTpUYWhvbWEsQXJpYWwsU1RIZWl0aSxTaW1TdW47Ij4NCkFjY29yZGluZyB0byB0 aGUgZG9vZGxlIHBvbGwsIG91ciBzaWRlIG1lZXRpbmcgd2lsbCBiZSBvbiBNb25kYXkgKDIzcmQg TWFyLCAyMDE1KSwgJm5ic3A7MTk6MTAgfiAyMDo0MCwgbG9jYWwgdGltZS48L2Rpdj4NCjxkaXYg c3R5bGU9ImNvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7Zm9udC1mYW1pbHk6VGFob21hLEFy aWFsLFNUSGVpdGksU2ltU3VuOyI+DQo8YSBocmVmPSJodHRwOi8vZG9vZGxlLmNvbS9kOHJtenl0 N25renBnMmY2MnVmZnU0ZXEvYWRtaW4jdGFibGUiPmh0dHA6Ly9kb29kbGUuY29tL2Q4cm16eXQ3 bmt6cGcyZjYydWZmdTRlcS9hZG1pbiN0YWJsZTwvYT48L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9y OiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7Zm9udC1mYW1pbHk6VGFob21hLEFyaWFsLFNUSGVpdGks U2ltU3VuOyI+DQo8YnIgZGF0YS1tY2UtYm9ndXM9IjEiPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJj b2xvcjojMDAwMDAwO2ZvbnQtc2l6ZToxNHB4O2ZvbnQtZmFtaWx5OlRhaG9tYSxBcmlhbCxTVEhl aXRpLFNpbVN1bjsiPg0KTGV0J3MgbWVldCBhdCB0aGUgZW5kIG9mIHRoZSBtZWV0aW5nIHJvb20g YWZ0ZXIgdGhlIFRlY2huaWNhbCBQbGVuYXJ5IG1lZXRpbmcuPC9kaXY+DQo8ZGl2IHN0eWxlPSJj b2xvcjojMDAwMDAwO2ZvbnQtc2l6ZToxNHB4O2ZvbnQtZmFtaWx5OlRhaG9tYSxBcmlhbCxTVEhl aXRpLFNpbVN1bjsiPg0KPGJyIGRhdGEtbWNlLWJvZ3VzPSIxIj4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0iY29sb3I6IzAwMDAwMDtmb250LXNpemU6MTRweDtmb250LWZhbWlseTpUYWhvbWEsQXJpYWws U1RIZWl0aSxTaW1TdW47Ij4NClRoYW5rcyw8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiMwMDAw MDA7Zm9udC1zaXplOjE0cHg7Zm9udC1mYW1pbHk6VGFob21hLEFyaWFsLFNUSGVpdGksU2ltU3Vu OyI+DQo8YnIgZGF0YS1tY2UtYm9ndXM9IjEiPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjoj MDAwMDAwO2ZvbnQtc2l6ZToxNHB4O2ZvbnQtZmFtaWx5OlRhaG9tYSxBcmlhbCxTVEhlaXRpLFNp bVN1bjsiPg0KS2luZCBSZWdhcmRzPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjojMDAwMDAwO2Zv bnQtc2l6ZToxNHB4O2ZvbnQtZmFtaWx5OlRhaG9tYSxBcmlhbCxTVEhlaXRpLFNpbVN1bjsiPg0K S2VwZW5nPC9kaXY+DQo8ZGl2IGNsYXNzPSJfX2FsaXl1bl9zaWduYXR1cmVfd3JhcCI+PGJyPg0K PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3Nw YW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D13058952B657goranselanderericssoncom_-- From nobody Thu Mar 19 07:19: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 AB0361ACC92 for ; Thu, 19 Mar 2015 07:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.305 X-Spam-Level: * X-Spam-Status: No, score=1.305 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, TRACKER_ID=1.306] 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 Cdett_NyfIHl for ; Thu, 19 Mar 2015 07:19:57 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (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 612371ACC8B for ; Thu, 19 Mar 2015 07:19:57 -0700 (PDT) Received: from [192.168.1.36] ([213.194.88.106]) by mrelay.perfora.net (mreueus002) with ESMTPA (Nemesis) id 0LsS5u-1ZVojQ0j96-0120Vf for ; Thu, 19 Mar 2015 15:19:56 +0100 From: Alper Yegin Content-Type: multipart/alternative; boundary="Apple-Mail=_7CB09474-006C-4FC6-999A-B8FC19AC64EF" Date: Thu, 19 Mar 2015 16:19:44 +0200 Message-Id: To: Ace@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Provags-ID: V03:K0:53bkMPgCw9BEOyj7sP93iM74Sd8E86/Tdgmpqt9F5cxbcaDRn1Y kzUPhk4UhHBqJcYjykFeJFO/7v+BpPH3aTRhZtvAfPfMJDPF8oj1IqZo6diTx06feVbShzk KPYyXXO3eCkqkAkzDfMUiYx7ETM7PgF66KG4Ze9To8FDekWtTzvKWBKT4hx+UdI0bW1mGVa IlYO2qL0yS3rW7oI4G7wg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [Ace] 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: Thu, 19 Mar 2015 14:19:58 -0000 --Apple-Mail=_7CB09474-006C-4FC6-999A-B8FC19AC64EF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello dear authors of gerdes-ace-dcaf-authorize, Implicit authorization: SAM authenticates the Client for the = Server without specifying the privileges in detail. This can be used for binary or unrestricted authorization (cf section 4 of [I-D.gerdes-ace-actors]). I'd not call this "implicit". I'd call this "unlimited authorization", = or "unrestricted authorization". Authorization is explicitly there, it's just lacking any constrains.=20 Also, don't you need a protocol exchanges between S and SAM, triggered = by the S receiving an authenticated request from C? After all, SAM knows = the Ticket but S does not. And what protocol are you thinking of using between C and CAM, and = between S and SAM? Cheers, Alper --Apple-Mail=_7CB09474-006C-4FC6-999A-B8FC19AC64EF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hello = dear authors of gerdes-ace-dcaf-authorize,

      without = specifying the privileges in detail.  This can be used = for
      binary or unrestricted = authorization (cf section 4 of
      = [I-D.gerdes-ace-actors]).

I'd not call this = "implicit". I'd call this "unlimited authorization", or "unrestricted = authorization".
Authorization is = explicitly there, it's just lacking any = constrains. 
Also, don't you need a = protocol exchanges between S and SAM, triggered by the S receiving an = authenticated request from C? After all, SAM knows the Ticket but S does = not.
And what protocol are = you thinking of using between C and CAM, and between S and = SAM?
To: Kepeng Li References: Date: Thu, 19 Mar 2015 11:46:35 -0400 In-Reply-To: (Kepeng Li's message of "Thu, 19 Mar 2015 16:45:18 +0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: Hannes Tschofenig , Ace Subject: Re: [Ace] [ACE] Side meeting in Dallas 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, 19 Mar 2015 15:46:46 -0000 "Kepeng Li" writes: > Hello all, > > According to the doodle poll, our side meeting will be on Monday (23rd Mar, > 2015), 19:10 ~ 20:40, local time. > http://doodle.com/d8rmzyt7nkzpg2f62uffu4eq/admin#table > > Let's meet at the end of the meeting room after the Technical Plenary meeting. Alas, I already have another Bar BOF at that time so I wont be able to attend this side meeting. :( > Thanks, > > Kind Regards > Kepeng -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Sat Mar 21 07:20:11 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2EE61AC3D4 for ; Sat, 21 Mar 2015 07:20: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 M5Zt24Y33VZn for ; Sat, 21 Mar 2015 07:20: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 875381B2850 for ; Sat, 21 Mar 2015 07:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t2LEJwwq019983; Sat, 21 Mar 2015 15:19:58 +0100 (CET) Received: from aung.tzi.org (p57A63F40.dip0.t-ipconnect.de [87.166.63.64]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3l8PHy0LMYz2nsF; Sat, 21 Mar 2015 15:19:57 +0100 (CET) From: Olaf Bergmann To: Alper Yegin References: Date: Sat, 21 Mar 2015 15:19:56 +0100 In-Reply-To: (Alper Yegin's message of "Thu, 19 Mar 2015 16:19:44 +0200") Message-ID: <87mw36qvoz.fsf@tzi.org> 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] 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: Sat, 21 Mar 2015 14:20:11 -0000 Alper, Thanks for your comments on dcaf which I will try address here: Alper Yegin writes: > Hello dear authors of gerdes-ace-dcaf-authorize, > > Implicit authorization: SAM authenticates the Client for the Server > without specifying the privileges in detail. This can be used for > binary or unrestricted authorization (cf section 4 of > [I-D.gerdes-ace-actors]). > > I'd not call this "implicit". I'd call this "unlimited authorization", > or "unrestricted authorization". > Authorization is explicitly there, it's just lacking any constrains.=20 Well, we had the impression that many people we were talking to did not see that authorization indeed is in effect here. I think, this was the reason for that somehow misleading term. > Also, don't you need a protocol exchanges between S and SAM, triggered > by the S receiving an authenticated request from C? After all, SAM > knows the Ticket but S does not. The protocol exchange between S and SAM is tunneled through CAM and C. Eventually, C puts the ticket face (that contains the authz information) into the psk_identity field of the ClientKeyExchange. This is all that S needs to validate that SAM has authorized C to access certain resources on S. > And what protocol are you thinking of using between C and CAM, and > between S and SAM? For the ticket request and transfer between C and CAM, we envision DCAF of DTLS as described in the draft. (DTLS is not a MUST here but a natural choice. If, e.g., C and CAM happen to be combined into one entity (e.g., a smartphone used as a control device), no explicit communication is required whatsoever as described in Section 11.1 of draft-gerdes-ace-dcaf-authorize.) Direct interaction between S and SAM is not required for the DCAF protocol flow as the DCAF messaging is tunneled through CAM and C. However, a prerequisite for DCAF is the existence of a shared secret between SAM and S (because this is used for integrity protection of the ticket face). DCAF makes no assumptions on the protocol or configuration method that is used to "bootstrap" this initial security relationship between SAM and S (and the same holds for CAM and C). Gr=C3=BC=C3=9Fe Olaf From nobody Mon Mar 23 02:53: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 73CDB1A1B9C for ; Mon, 23 Mar 2015 02:53:48 -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 EY7ccyw4tMmu for ; Mon, 23 Mar 2015 02:53: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 83FC81A1B77 for ; Mon, 23 Mar 2015 02:53: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 [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t2N9rhom011027; Mon, 23 Mar 2015 10:53:43 +0100 (CET) Received: from [192.168.1.109] (pD9F610D0.dip0.t-ipconnect.de [217.246.16.208]) (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 3l9WHq3jDGz2nkV; Mon, 23 Mar 2015 10:53:43 +0100 (CET) Message-ID: <550FE2A7.40407@tzi.de> Date: Mon, 23 Mar 2015 10:53:43 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Alper Yegin , Ace@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ace] 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, 23 Mar 2015 09:53:48 -0000 Hi Alper, Thank you for your comments. On 03/19/2015 03:19 PM, Alper Yegin wrote: > Hello dear authors of gerdes-ace-dcaf-authorize, > > > Implicit authorization: SAM authenticates the Client for the Server > without specifying the privileges in detail. This can be used for > binary or unrestricted authorization (cf section 4 of > [I-D.gerdes-ace-actors]). > > I'd not call this "implicit". I'd call this "unlimited authorization", or "unrestricted authorization". > Authorization is explicitly there, it's just lacking any constrains. We called it implicit because the authorization information is not transmitted. S can still have own means for authorization. Best regards, Steffi From nobody Mon Mar 23 06:26:42 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC0191A8A60 for ; Mon, 23 Mar 2015 06:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nt7SavQRmfHP for ; Mon, 23 Mar 2015 06:26:37 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A15161A8A68 for ; Mon, 23 Mar 2015 06:26:35 -0700 (PDT) X-AuditID: 12074423-f79536d000000e74-65-5510148a7605 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 32.8B.03700.A8410155; Mon, 23 Mar 2015 09:26:34 -0400 (EDT) Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t2NDQXIH000963; Mon, 23 Mar 2015 09:26:33 -0400 Received: from oc11exedge1.exchange.mit.edu (oc11exedge1.exchange.mit.edu [18.9.3.17]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id t2NDQVE5019206; Mon, 23 Mar 2015 09:26:32 -0400 Received: from OC11EXHUB11.exchange.mit.edu (18.9.3.25) by oc11exedge1.exchange.mit.edu (18.9.3.17) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 23 Mar 2015 09:26:14 -0400 Received: from OC11EXPO24.exchange.mit.edu ([169.254.1.184]) by OC11EXHUB11.exchange.mit.edu ([18.9.3.25]) with mapi id 14.03.0158.001; Mon, 23 Mar 2015 09:26:31 -0400 From: Thomas Hardjono To: "ace@ietf.org" Thread-Topic: Fluffy key exchange -- FW: New Version Notification for draft-hardjono-ace-fluffy-00.txt Thread-Index: AQHQZWy3WBdDU5qymUS5unbonOMHbg== Date: Mon, 23 Mar 2015 13:26:31 +0000 Message-ID: <5E393DF26B791A428E5F003BB6C5342A92C4F220@OC11EXPO24.exchange.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [18.111.11.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA01SbUhTURjm7G7zurx63WY7mVZeG4i6aWAxIiSjH4NARJJiRXV1t220L+6d 4hzB/iQ2FPJHP9wgLTVIw0BwlFnZYLPUZKRZVgqGCFkpJTk/Srqnbbp/z/s+H5yH8+KYdFqU iZusDoa10mZKLBFKkzMKVB45WVX86qtME1lrxjTdT+ZEmsl29iSmbf3xU6jt7H8h1nZ1bQgq MJ3khJ4xm+oYtqj0isT4uWUVs88S9f6lG0lusCbxgGQckiXwTu+IOIr3wvDcIx5LcCnZKYAz t7tAdBgG0L0yEGNGABycfxYb/AAGtzeTkF9K9gL4pikLYTGZBxvXW/g9jsvJHPj+C430GNkH 4IexByKkkZE1cCoU1xihe9GJ1nJSDf3BMEBYSCrhincEQ5ggK2GwefP/HvBPjYw+FCCMkQr4 caFdEK2QDu/5hrB4ne3B+Vi1HDg2sRXTF8KOp7/EUVwA79/9FstPh6/bFoS3gMKbEOtNsHgT LN4ESwcQ9oBsvaVBZaFNZo6pUXE1tNXKsKpjaovJoWb0tf0AfV/S6dzH4M9LKgBIHFApRLgy rUoqous4pyUA9uECKoPolZFV0tRqm95ppDnjZbbWzHABAHGMkhOuWV5O6GlnA8Pa4tR+XEgp iP711LNS0kA7mGsMY2fYOJuF4xQkGlFoOssYmPqrJrNjlxbgySg8hQ9vQhqCs9MWzmSI8qMg J1NBDCCCRISx1rrjjZ/jElDwVWQEg1Qp/LHuuJf4YAEfPGFLRcEOepfKdIOpMpF69O2WP9Jz WGcfbZ2hun2L58K6AUO1Lytv4++7S30XTxXTWpdz+pDSnHGBcA57Sub3HDg/lDv+vLL+5srk WPkZX9BlX153KUPHyw4WtS0ur/Y0KauzdYNHgxWmhk+qygmPNq0Qmx43RjSB34228tLv4b6w P78jdH09RAk5I30kH2M5+h/xAm2saQMAAA== Archived-At: Cc: "Hannes.Tschofenig@gmx.net" , "kepeng.lkp@alibaba-inc.com" , Thomas Hardjono Subject: [Ace] Fluffy key exchange -- FW: New Version Notification for draft-hardjono-ace-fluffy-00.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 13:26:40 -0000 Folks, Just wanted to introduce Fluffy to the ACE WG. Sorry I couldn't make it to the Dallas-IETF. Feel free to post questions to the list or privately. Thanks. /thomas/ ________________________________________ From: internet-drafts@ietf.org [internet-drafts@ietf.org] Sent: Monday, March 23, 2015 5:51 AM To: Thomas Hardjono; Thomas Hardjono; Ned Smith; Ned Smith Subject: New Version Notification for draft-hardjono-ace-fluffy-00.txt A new version of I-D, draft-hardjono-ace-fluffy-00.txt has been successfully submitted by Thomas Hardjono and posted to the IETF repository. Name: draft-hardjono-ace-fluffy Revision: 00 Title: Fluffy: Simplified Key Exchange for Constrained Environment= s Document date: 2015-03-23 Group: Individual Submission Pages: 26 URL: http://www.ietf.org/internet-drafts/draft-hardjono-ace-fluf= fy-00.txt Status: https://datatracker.ietf.org/doc/draft-hardjono-ace-fluffy/ Htmlized: http://tools.ietf.org/html/draft-hardjono-ace-fluffy-00 Abstract: This document proposes a simplified key exchange protocol for the establishment of a symmetric key shared between two devices or entities within a constrained environment. The pair-wise key establishment is performed using the mediation of a trusted Simple Key Distribution Center (SKDC) entity. The protocol also supports the mediated distribution of a group-key among multiple devices or entities for the purposes of protecting multicast messages. 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 From nobody Mon Mar 23 07:45:02 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029661A8AD8 for ; Mon, 23 Mar 2015 07:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 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_36=0.6, J_CHICKENPOX_64=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8eFIPXgTMVW for ; Mon, 23 Mar 2015 07:44:59 -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 C1AA41A8ADC for ; Mon, 23 Mar 2015 07:44:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1427121897; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=LisXlY3YZAtpLlEi2IP3QHMe+et5S7oGqwBmwaqSZck=; b=rrDhQaLF3otPxe4i8v6D3+CEAHhl0ozyli3te+Ywo8494J2fm0F0inlmUqSG0TPO4pK9xvjpUC1RLZBl5nRuHlG31wvAonmT5eyFn97KESghhk5Pa6cIAWJq0aI4riKLH7rdKWa+gNoyRYtyjvVp0qYGNcVYhQWJfuw4MTlPqDk= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R891e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41g03021; MF=kepeng.lkp@alibaba-inc.com; PH=DW; RN=3; RT=3; SR=0; Received: from WS-web (kepeng.lkp@alibaba-inc.com[31.133.164.118]) by r41f05043.xy2.aliyun.com at Mon, 23 Mar 2015 22:44:53 +0800 Date: Mon, 23 Mar 2015 22:44:53 +0800 From: "Kepeng Li" To: "Ace" , "=?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?=" Message-ID: X-Mailer: Alimail-Mailagent revision 2684282 MIME-Version: 1.0 References: , D1305895.2B657%goran.selander@ericsson.com In-Reply-To: D1305895.2B657%goran.selander@ericsson.com Content-Type: multipart/alternative; boundary="----=ALIBOUNDARY_5076_4a780940_551026e5_8522a" Archived-At: Cc: Ludwig Seitz Subject: [Ace] =?utf-8?b?562U5aSN77yaIFtBQ0VdIFNpZGUgbWVldGluZyBpbiBEYWxs?= =?utf-8?q?as?= X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Kepeng Li List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 14:45:01 -0000 ------=ALIBOUNDARY_5076_4a780940_551026e5_8522a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello all,Please find the updated slides from Goran and Ludwig.http://www.ietf= .org/proceedings/92/slides/slides-92-ace-1.pdf=0AThanks,Kind RegardsKepeng=0A=0A= ------------------------------------------------------------------=0A=E5=8F=91= =E4=BB=B6=E4=BA=BA=EF=BC=9AG=C3=B6ran Selander =0A= =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A2015=E5=B9=B43=E6=9C=8819=E6=97=A5= (=E6=98=9F=E6=9C=9F=E5=9B=9B) 17:55=0A=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9AAce = =0A=E6=8A=84=E3=80=80=E9=80=81=EF=BC=9ALudwig Seitz =0A=E4=B8=BB=E3=80=80=E9=A2=98=EF=BC=9ARe: [Ace] [ACE] Side meeting in Dal= las=0A=0A=0A=0A=0A=0AAll,=0A=0A=0A=0A=0ALudwig and I have put together some sl= ides combining different inputs on architecture, terminology and problem state= ment for ACE.=C2=A0=0A=0A=0A=0A=0AThe architecture is inspired by draft-gerdes= -ace-actors. The terminology builds on UMA/OAuth. The problem statement is a c= ombination of draft-seitz-ace-problem-description, draft-gerdes-ace-actors=0A = and draft-selander-ace-object-security.=0A=0A=0A=0A=0AFood for thought. Input = for the side meeting on Monday evening. Comments are welcome.=C2=A0=0A=0A=0A=0A= Here are the slides:=0A=0Ahttps://www.sics.se/~ludwig/ACE/arch-term-n-prob-des= c-00.pdf=0A=0A=0A=0ABest regards,=0AG=C3=B6ran=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A= From: Kepeng Li =0A=0AReply-To: Kepeng Li =0A=0ADate: Thursday 19 March 2015 09:45=0A=0ATo: Ace =0A=0ACc: Hannes Tschofenig =0A=0ASubject= : [Ace] [ACE] Side meeting in Dallas=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0AHello all= ,=0A=0A=0A=0A=0A=0AAccording to the doodle poll, our side meeting will be on M= onday (23rd Mar, 2015), =C2=A019:10 ~ 20:40, local time.=0A=0Ahttp://doodle.co= m/d8rmzyt7nkzpg2f62uffu4eq/admin#table=0A=0A=0A=0A=0A=0ALet's meet at the end = of the meeting room after the Technical Plenary meeting.=0A=0A=0A=0A=0A=0AThan= ks,=0A=0A=0A=0A=0A=0AKind Regards=0A=0AKepeng=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A ------=ALIBOUNDARY_5076_4a780940_551026e5_8522a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all,

Please find the updated slides from Goran and L= udwig.
http://www.ietf.org/proceedings/92/slides/slides-92-ace-1.p= df

Thanks,
Kind Regards
K= epeng


-----------------------------------------= -------------------------
=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9AG=C3=B6ran Se= lander <goran.selander@ericsson.com>
=E5=8F=91=E9=80=81=E6=97=B6=E9=97= =B4=EF=BC=9A2015=E5=B9=B43=E6=9C=8819=E6=97=A5(=E6=98=9F=E6=9C=9F=E5=9B=9B) 17= :55
=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9AAce <ace@ietf.org>
=E6=8A=84= =E3=80=80=E9=80=81=EF=BC=9ALudwig Seitz <ludwig@sics.se>
=E4=B8=BB=E3= =80=80=E9=A2=98=EF=BC=9ARe: [Ace] [ACE] Side meeting in Dallas

=0A= =0A=0A=0A
All,
=0A

=0A
=0A
=0A

Ludwig and I have put together = some slides combining different inputs on architecture, terminology and proble= m statement for ACE. 

=0A

=0A
=0A

=0A

The architecture is inspire= d by draft-gerdes-ace-actors. The terminology builds on UMA/OAuth. The problem= statement is a combination of draft-seitz-ace-problem-description, draft-gerd= es-ace-actors=0A and draft-selander-ace-object-security.

=0A

=0A=0A

=0A

Food for thought. Input for the side meeting on Monday evening. Comments ar= e welcome. 

=0A


=0A

=0A

Here are the slides:

=0A

=0Ahttps:= //www.sics.se/~ludwig/ACE/arch-term-n-prob-desc-00.pdf

=0A


=0A

=0A

Best regards,

= =0A

G=C3=B6= ran

=0A

=0A
=0A

=0A
=0A

=0A
=0A=0A
=0AFrom: Kepeng Li <kepeng.lkp@alibaba-inc.com>=0AReply-To: Kepeng Li <kepeng.lkp@alibaba-in= c.com>
=0ADate: Thursday 1= 9 March 2015 09:45
=0ATo: Ace <= ;ace@ietf.org>
=0A= Cc: Hannes Tschofenig <hannes.tschofenig@gmx.net= >
=0ASubject: [Ace] [ACE] = Side meeting in Dallas
=0A
=0A

=0A
=0A
=0A
=0A
=0A
=0A
=0AHello all,
=0A
=0A=0A
=0A
=0AAccording to the doodle poll, our side meet= ing will be on Monday (23rd Mar, 2015),  19:10 ~ 20:40, local time.
= =0A=0A
=0A
=0A
=0A
=0A= Let's meet at the end of the meeting room after the Technical Plenary meeting.=
=0A
=0A
=0A
=0A
=0AThanks,=0A
=0A
=0A
=0A
=0AKind Regards=0A
=0AKepeng
=0A

=0A
=0A
=0A
=0A
=0A
=0A
=0A
------=ALIBOUNDARY_5076_4a780940_551026e5_8522a-- From nobody Mon Mar 23 11:46:21 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EED91AD0C3 for ; Mon, 23 Mar 2015 11:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=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 926_kpC0Du_l for ; Mon, 23 Mar 2015 11:46:18 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B9DB1AD0CE for ; Mon, 23 Mar 2015 11:46:18 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 0B01619023B for ; Mon, 23 Mar 2015 19:46:16 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id AC0EA15805A for ; Mon, 23 Mar 2015 19:46:15 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Mon, 23 Mar 2015 19:46:15 +0100 From: To: "Ace@ietf.org" Thread-Topic: [Ace] Protecting the physical access to a device Thread-Index: AQHQWoAkFK5+IJGF50WKIHnUf6CeQp0qfPVg Date: Mon, 23 Mar 2015 18:46:14 +0000 Message-ID: <3625_1427136375_55105F77_3625_5014_1_8F1D83ADCC1AC94186A867BEE9B7D91306EDB43F@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <54FDBF87.8000102@tzi.de> In-Reply-To: <54FDBF87.8000102@tzi.de> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.3.23.75418 Archived-At: Subject: Re: [Ace] Protecting the physical access to a device 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, 23 Mar 2015 18:46:20 -0000 SGkgYWxsLA0KDQpSZWFkaW5nIDUuMSBvZiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQt c2VpdHotYWNlLXByb2JsZW0tZGVzY3JpcHRpb24tMDMudHh0ICwgSSBoYXZlIGFub3RoZXIgY29t bWVudCBvbiBwaHlzaWNhbCBhY2Nlc3MuDQoiU2luY2UgaXQgZG9lcyBub3QgbWFrZSBzZW5zZSB0 byBkZXNpZ24gYSBzb2x1dGlvbiBmb3IgYSBzaXR1YXRpb24gDQogIHRoYXQgY2Fubm90IGJlIHBy b3RlY3RlZCBhZ2FpbnN0IHdlIGFzc3VtZSB0aGVyZSBpcyBubyBuZWVkIHRvDQogICBwcm90ZWN0 IGFzc2V0cyB3aGljaCBhcmUgZXhwb3NlZCBkdXJpbmcgYSBwaHlzaWNhbCBhdHRhY2suICBJbiBv dGhlcg0KICAgd29yZHMsIGVpdGhlciBhbiBhdHRhY2tlciBkb2VzIG5vdCBoYXZlIHBoeXNpY2Fs IGFjY2VzcyB0byB0aGUgc2Vuc29yDQogICBvciBhY3R1YXRvciBkZXZpY2UsIG9yIGlmIGl0IGhh cywgdGhlIGF0dGFjayBzaGFsbCBvbmx5IGhhdmUgZWZmZWN0DQogICBkdXJpbmcgdGhlIHBlcmlv ZCBvZiBwaHlzaWNhbCBhdHRhY2suIg0KDQpJIHJlY29tbWVuZCB0byBzdGF0ZSB0aGUgZXh0ZW50 IG9mIHRoZSBhdHRhY2sgc2hvdWxkIG5vdCBvbmx5IGJlIGxpbWl0ZWQgaW4gdGltZSwgYnV0IGFs c28gaW4gYnJlYWR0aC4NCkZvciBleGFtcGxlLCBwaHlzaWNhbCBhdHRhY2sgb24gb25lIGxpdHRs ZSBkZXZpY2UgbHlpbmcgb24gdGhlIHN0cmVldCBzaG91bGQgbm90IGdpdmUgYWNjZXNzIHRvIHRo ZSB3aG9sZSBuZXR3b3JrIG9mIHRob3VzYW5kcyBvZiBub2RlcyBpbiB0aGUgY2l0eSwgZXZlbiBv bmx5IGZvciB0aGUgbGltaXRlZCBkdXJhdGlvbiBvZiB0aGUgcGh5c2ljYWwgYXR0YWNrLg0KDQpC ZXN0IHJlZ2FyZHMNCg0KRG9taW5pcXVlDQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0K RGXCoDogQWNlIFttYWlsdG86YWNlLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgU3Rl ZmFuaWUgR2VyZGVzDQpFbnZvecOpwqA6IGx1bmRpIDkgbWFycyAyMDE1IDEwOjQzDQrDgMKgOiBB Y2VAaWV0Zi5vcmcNCk9iamV0wqA6IFtBY2VdIFByb3RlY3RpbmcgdGhlIHBoeXNpY2FsIGFjY2Vz cyB0byBhIGRldmljZQ0KDQpIaSBhbGwsDQoNCndoaWxlIHJlYWRpbmcgdGhyb3VnaCB0aGUgZHJh ZnQsIEkgc3R1bWJsZWQgdXBvbiB0aGUgZm9sbG93aW5nIHNlbnRlbmNlIGluIHRoZSBoZWFsdGgg bW9uaXRvcmluZyB1c2UgY2FzZToNCg0KIlRoZSBkZXZpY2UgaW5jbHVkZXMgc29tZSBhdXRoZW50 aWNhdGlvbiBtZWNoYW5pc20sIGluIG9yZGVyIHRvIHByZXZlbnQgb3RoZXIgcGVyc29ucyB3aG8g Z2V0IHBoeXNpY2FsIGFjY2VzcyB0byBpdCBmcm9tIGFjdGluZyBhcyB0aGUgb3duZXIgYW5kIG1l c3NpbmcgdXAgdGhlIGFjY2VzcyBjb250cm9sIGFuZCBzZWN1cml0eSBzZXR0aW5ncy4iDQoNCkkg d2FzIHdvbmRlcmluZyB3aGV0aGVyIHRoaXMgc2VudGVuY2UgaW50ZW50aW9uYWxseSBhZGRyZXNz ZXMgcGh5c2ljYWwgYWNjZXNzIGFuZCB3aGV0aGVyIGFuIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlz bSBjYW4gaGVscCBhZ2FpbnN0IHBoeXNpY2FsIGF0dGFja3MuIElmIG5vdCwgd2UgbWlnaHQgcmVt b3ZlIHRoZSB0ZXJtICJwaHlzaWNhbCIgaGVyZS4gV2hhdCBkbyB5b3UgdGhpbms/DQoNCkJlc3Qg cmVnYXJkcywNClN0ZWZmaQ0KDQoNCi0tIA0KU3RlZmFuaWUgR2VyZGVzCQkJVGVsOiArNDkgNDIx IDIxOCA2MzkwNg0KVFpJIFVuaXZlcnNpdMOkdCBCcmVtZW4JCUUtTWFpbDogZ2VyZGVzQHR6aS5k ZQ0KQmlibGlvdGhla3N0ci4gMSwgTVpIIDUxNTANCjI4MzU5IEJyZW1lbiwgR2VybWFueQ0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQWNlIG1haWxp bmcgbGlzdA0KQWNlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2FjZQ0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZl bnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdp ZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNv cGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIg ZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWly ZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVl cyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSBy ZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxz aWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFp biBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90 ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29w aWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFp bCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNz YWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jhbmdl IGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFu Z2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Mon Mar 23 12:30: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 D9EA81B29A6 for ; Mon, 23 Mar 2015 12:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 usf-ngupQrhO for ; Mon, 23 Mar 2015 12:30:39 -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 3A5271AD49F for ; Mon, 23 Mar 2015 12:30:39 -0700 (PDT) Received: from [192.168.10.140] ([31.133.152.120]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MCfcc-1YjRjK31wg-009N66 for ; Mon, 23 Mar 2015 20:30:37 +0100 Message-ID: <551069DA.8060707@gmx.net> Date: Mon, 23 Mar 2015 20:30:34 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Ace@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Cv1RR8xoOegnGkBLNr8TvLBvrsnCdE5Jr" X-Provags-ID: V03:K0:Csxj6sNaHE47U+/j3/RauUDUAgAkeZbGneeiCij9EK99M43oDVF 4MeyDkIcc6MnPJxoK9aEtj0LWVShjo1Y77u8lxUDFY3kOTgPnLq6a8E3pnaB9QpTNN6dohr PIFYoubZD96mukvEEzgKD+b7XwE1E6IzGkwZU1OgQDGBppGkH54P4krPEdkpuVPhBDk9mBr fciIfhXKJ9w0dhnuvxY4A== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [Ace] Meeting Room for Tonight 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, 23 Mar 2015 19:30:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Cv1RR8xoOegnGkBLNr8TvLBvrsnCdE5Jr Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, for our meeting this evening after the IAB plenary we are going to meet at the room "Pavilion". See you there! Ciao Hannes --Cv1RR8xoOegnGkBLNr8TvLBvrsnCdE5Jr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVEGnaAAoJEGhJURNOOiAtucIH/2S3sPMTonMEdAxjTTbYcgMT Y8UJQ4obi/XXEnpPn3n9XkNHJFZ5sglkMVv9bLZ0bJUjg35jaLJPylMxJ5EWsxPv 0EfKO6yVs0+pcrTlZSlTppFk3mBb3m5bvC2kGKmRFNGlEvjuwDw8a9hguU9KO0AM 5EQ5/vHB49WGvutuLk7QH1ugBkCOEwzbs7XulhQPN+Jzj7yoKoVvv5CPOqfXZxEl TliablWSWYOwws2dtjBg3OD1OXJk6B6bjw9+REcEBsSLM/Zgghnuho0SDbZhBzex qhrUXBKf9DsYlkfHKgggHZbvDaclhEFWMmWZnc1QSVRefWwMHpOgoF+VuobO0AQ= =w8YN -----END PGP SIGNATURE----- --Cv1RR8xoOegnGkBLNr8TvLBvrsnCdE5Jr-- From nobody Mon Mar 23 18: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 AD4C31B2B0A for ; Mon, 23 Mar 2015 18:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ra3k5e2cj6yR for ; Mon, 23 Mar 2015 18:20:56 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CBDA1B2B09 for ; Mon, 23 Mar 2015 18:20:56 -0700 (PDT) Received: by obcjt1 with SMTP id jt1so116479879obc.2 for ; Mon, 23 Mar 2015 18:20:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:date:message-id:subject:from:to :content-type; bh=uG85cBBpDWpi1rGZvEmB1iHlgHrSnA2ZvTU66NxaYG0=; b=H9nzcApusDHueAlK+yq77dz3yNhX3rwDX2crBfCGSmcH+SEhjdqVeCrsRDEY70Z2Ue 5Xm+Arndq95gz/12BIyxeQtjZbRNvaQvMKrjY4UHOwTTBs/3KWxVsa0l+YW4nWSwodx4 pef1l0s1Mf+Zdxx12HnZ8XDIpz85DR9okXLxAOWVBkRkb4afmbI65ajWeumI4ptyWqMb edHdpQ6sQtOZKTpAc1T+NA+IeIw8F0UfCM1cbtzK/Ebge/NRsLjGwmYBSj+H1KiYscDq Qd/pIHy4k/eF3Ji7mTUqavxZVTi6iBkWVjPUpXPfmjHJC3KDCt+1N2eFr0lCdsstKlet CoZw== MIME-Version: 1.0 X-Received: by 10.202.87.215 with SMTP id l206mr1386275oib.84.1427160055871; Mon, 23 Mar 2015 18:20:55 -0700 (PDT) Sender: robert.cragie@gmail.com Received: by 10.202.80.18 with HTTP; Mon, 23 Mar 2015 18:20:55 -0700 (PDT) Date: Tue, 24 Mar 2015 01:20:55 +0000 X-Google-Sender-Auth: TLXsSeSN-R2QDdYq0tYMYcCwrf4 Message-ID: From: Robert Cragie To: "ace@ietf.org" Content-Type: multipart/alternative; boundary=001a113ac6a42b00a50511fe9831 Archived-At: Subject: [Ace] Transaction model X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 01:20:57 -0000 --001a113ac6a42b00a50511fe9831 Content-Type: text/plain; charset=UTF-8 Further to the discussion in the ACE side meeting, I came up with this (rather complicated) model which in my mind shows what considerations there are when it comes to just a very basic instantaneous request/response transaction with respect to a resource. https://docs.google.com/presentation/d/1qFH5zPoBWx1Rog3OkPwqKnwVd-SNsWsFZR9t7lDFdA0/edit?usp=sharing Happy to explain it further. Robert --001a113ac6a42b00a50511fe9831 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Further to the discussion in the ACE side meeting, I came = up with this (rather complicated) model which in my mind shows what conside= rations there are when it comes to just a very basic instantaneous request/= response transaction with respect to a resource.

<= div>
Happy to explain it further.

Ro= bert
--001a113ac6a42b00a50511fe9831-- From nobody Tue Mar 24 00:51:55 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A215A1A88F6 for ; Tue, 24 Mar 2015 00:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 tmh_g-NCxJ-8 for ; Tue, 24 Mar 2015 00:51:50 -0700 (PDT) Received: from outbox.sics.se (outbox.sics.se [193.10.64.137]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8901B2CC6 for ; Tue, 24 Mar 2015 00:51:50 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [192.36.171.201]) by outbox.sics.se (Postfix) with ESMTPS id 688F454 for ; Tue, 24 Mar 2015 08:51:49 +0100 (CET) Received: from norm.sics.se (norm.sics.se [193.10.64.192]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id t2O7pm8e002435 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 24 Mar 2015 08:51:49 +0100 Received: from [192.168.0.108] (unknown [85.235.11.178]) by norm.sics.se (Postfix) with ESMTPSA id C742122F for ; Tue, 24 Mar 2015 08:51:48 +0100 (CET) Message-ID: <5511178E.90805@sics.se> Date: Tue, 24 Mar 2015 08:51:42 +0100 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: ace@ietf.org References: <54FDBF87.8000102@tzi.de> <3625_1427136375_55105F77_3625_5014_1_8F1D83ADCC1AC94186A867BEE9B7D91306EDB43F@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <3625_1427136375_55105F77_3625_5014_1_8F1D83ADCC1AC94186A867BEE9B7D91306EDB43F@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040500030005030706020606" X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sics-se:default, sics-se:default, base:default, @@RPTN) X-p0f-Info: os=Linux 2.2.x-3.x, link=Ethernet or modem X-CanIt-Geo: =?UTF-8?Q?ip=3D85.235.11.178; _country=3DSE; _region=3DSk=C3=A5ne; _city=3DLund; _latitude=3D55.7028; _longitude=3D13.1927; _http://maps.google.com/maps=3Fq=3D55.7028,13.1927&z=3D6?= X-CanItPRO-Stream: outbound-sics-se:outbound (inherits from outbound-sics-se:default, sics-se:default, base:default) X-Canit-Stats-ID: 09O7jPMTp - e5ea0e276343 - 20150324 X-Antispam-Training-Forget: https://canit.sunet.se/canit/b.php?i=09O7jPMTp&m=e5ea0e276343&t=20150324&c=f X-Antispam-Training-Nonspam: https://canit.sunet.se/canit/b.php?i=09O7jPMTp&m=e5ea0e276343&t=20150324&c=n X-Antispam-Training-Spam: https://canit.sunet.se/canit/b.php?i=09O7jPMTp&m=e5ea0e276343&t=20150324&c=s X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 85.235.11.178 is neither permitted nor denied by domain ludwig@sics.se) receiver=e-mailfilter01.sunet.se; client-ip=85.235.11.178; envelope-from=; helo=norm.sics.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: Subject: Re: [Ace] Protecting the physical access to a device 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, 24 Mar 2015 07:51:53 -0000 This is a cryptographically signed message in MIME format. --------------ms040500030005030706020606 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 03/23/2015 07:46 PM, dominique.barthel@orange.com wrote: > Hi all, > > Reading 5.1 of http://tools.ietf.org/id/draft-seitz-ace-problem-descrip= tion-03.txt , I have another comment on physical access. > "Since it does not make sense to design a solution for a situation > that cannot be protected against we assume there is no need to > protect assets which are exposed during a physical attack. In othe= r > words, either an attacker does not have physical access to the sens= or > or actuator device, or if it has, the attack shall only have effect= > during the period of physical attack." > > I recommend to state the extent of the attack should not only be limite= d in time, but also in breadth. > For example, physical attack on one little device lying on the street s= hould not give access to the whole network of thousands of nodes in the c= ity, even only for the limited duration of the physical attack. > > Best regards > > Dominique > I remember thinking along these lines, but apparently I failed to put it = into words. I'll try to find a suitable phrasing for this in the next=20 update. Thank you for your contribution. /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 --------------ms040500030005030706020606 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVDCC BhgwggUAoAMCAQICAwyGmDANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTE1MDEwODA4MzkwNloXDTE2MDEwOTIyNDEzMFowODEXMBUGA1UE AwwObHVkd2lnQHNpY3Muc2UxHTAbBgkqhkiG9w0BCQEWDmx1ZHdpZ0BzaWNzLnNlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxUHisC6rgXFsBHHBGo8ulz/cLX3gX5Ufhcwo rp+7djzMMuKPM1KOHq0bjWhmFe8ly8CzWdk2NS600t7IEBQWJiHLsdc12UqmNswQUpD7oqkR 1nRGT6leAHYTWapkR+nczZ2NxD+H7u4ZWVIZg0DFiTqtY8ghYHHYYy8BBoc/jHG78X4+JJAg s5XOa0gVl7W38vDvVpo14xhWEBGjzPk9WxWirqAF66PF+JEu2JD9LzFbpEq829SRXJMFB9wp oQNlH0UQ01/2sWCIBxPpHuEjxEF/V3Z/F2VsNTy4zvYrd+/MYO3w30F+bWQNZsMHEkTW1pEh iz7rQPWTBXoO8Fv0wQIDAQABo4IC1DCCAtAwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTqvKspqEm0E4R1sgsABYKk 6xDJqDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZBgNVHREEEjAQgQ5sdWR3 aWdAc2ljcy5zZTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcC AjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0 aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5 aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQEFBQADggEBAGXwFsbSfv4mMWqIk64CoxuR6ozo7J37igca7d9tpKIzVIp6xp7Zt+a+J9X3 1r4zgMRFnZJWQ5hy82W/fVDeG9i3NGMM6p7DNUrGjTbVHd11BQtbUOG9MSlyWKQbmt3Q1ElC f4SRLAQot5SPryLR2FTxQuFkMOrcDzVxNxnMgatOM2fAO8KS0H+wX+I7gC3pEnbg/eMqNgU+ Ktbc2y9naDNmLNLN65s8TT9xZyoQEn9S1oU8Xnh596OMu49Eccws8Ny+vAGESIHG4bqhMSjj rmDilL1Wj9nQahmBnID5oZD5g9s9KyqxiZIGNnowYYOpCrSeITZ1b7wg50dC8ySojnYwggY0 MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEw MjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0d Lep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiU fsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5Dp IpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuC YKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/ MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0j BBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzAB hhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nm c2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9 eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukD FUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyi kfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8Cnykh ExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b 970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCD z+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqA SfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNb BIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBth HSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+ UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAwyGmDAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTAzMjQwNzUxNDJaMCMGCSqGSIb3DQEJBDEW BBQdECUjQchzIGAF61rxCNVeFoNoxjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDDIaYMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJKoZIhvcNAQEBBQAE ggEAClXzO18BOcE3HjGoR3S2Yuyk331eUjvhIPpc0f6nhp9uxQ6tH89kE72xw8Z4zAyQ1Ezw Qi2pmAdGAVE6Ws/MK8v44LISgtu2l9WHv9p5eMGXLRYzc0jQLJpLWpsBGBbbXq6HM/JLeel2 D+mB/CEEVHQFR/hTWLhbGz9iFPF5ybw8SILIszt35NZqJ1rBHQjBjjzIICTv/yEPjTZ0YZoc v4GPMrBP54sr5JC/oRBlZxvj4G2TINC1Vr9fEqLvCJgXDN1jwTrYM+svmseMXu1AJDtnw3NS n3DPoXSlnqUl60KCjbr2Kw8OOEVl2iCDCqfewjEdJeNDJREFFxMR/r5qOwAAAAAAAA== --------------ms040500030005030706020606-- From nobody Tue Mar 24 08:42: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 5DAEC1A8935 for ; Tue, 24 Mar 2015 08:42:48 -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 SbQgYIaymoCn for ; Tue, 24 Mar 2015 08:42: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 BC7EA1A8972 for ; Tue, 24 Mar 2015 08:42: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 t2OFgLCh011188; Tue, 24 Mar 2015 16:42:21 +0100 (CET) Received: from [192.168.1.109] (p57A63B56.dip0.t-ipconnect.de [87.166.59.86]) (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 3lBGzd34Zhz2nb3; Tue, 24 Mar 2015 16:42:21 +0100 (CET) Message-ID: <551185DD.2030804@tzi.de> Date: Tue, 24 Mar 2015 16:42:21 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= , "Ace@ietf.org" References: <20150309234920.12025.44848.idtracker@ietfa.amsl.com> <54FEF0C9.30005@tzi.de> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] Fwd: New Version Notification for draft-gerdes-ace-actors-03.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, 24 Mar 2015 15:42:48 -0000 Hi Göran, Thank you for your comments. On 03/17/2015 11:59 AM, Göran Selander wrote: > > Hi Steffi, > > I've finally got around to read the "actors" draft as a whole. I've listed > some comments below. > > > General: > > • The draft introduces one new node in the architecture (compared to e.g. > UMA) called COP, supporting a constrained client. I think this kind of > "support node" is useful, but its functionality needs to be further > elaborated (see detailed comments). In fact there are two supporting nodes called CAM and SAM. They both help their respective constrained device with authentication and authorization since the constrained devices might be too constrained to perform complex security tasks on their own, e.g. storing a large number of keys or interpreting complex authorization policies. Moreover, CAM and SAM provide user interfaces which the constrained devices might not have. > > • There is lots of innovation of terminology; both new terms > (authenticated authorization, binary authorization, unrestricted > authorization, authorized representation, authorized resource, endorsement > information, complexity levels, etc.); new names for roles in the > authorization architecture (Client Overseesing Principal, Server > Overseeing Principal, Client Authorization Manager, Server Authorization > Manager, Attribute Binding Authority); and also the meaning of existing > terms (e.g. authorization) is being changed. I disagree with how some > terms are used and moreover I think it would be much better to use less > terminology and try to reuse existing terminology. Here are a few reasons: I find it surprising that you seem to think that the actors draft redefines authorization. The common understanding is that authorization is about allowing entities to do or be something. Do you question that? I agree that we should use exisiting terminology where applicable. I am not aware that there are definitions for the levels of granularity for the authorization such as "binary authorization", "device authorization" etc. elsewhere. If there is, please point it out to me. > > - Access control is not a new problem. Although the constrained > environment motivates some new functionality, that does not warrant a > completly new terminology. People found the OAuth terminology in the draft confusing which is why it was removed. I think it will be more damaging to use a terminology that doesn't really fit. > > - At the end of the day we want people approaching this work to be able > to reuse gained knowledge from other contexts to quickly understand what > this work is good for. The sheer amount of new terms is discouraging. Not being able to understand the underlying problems because the terminology indicates a different solution will only make things worse. > > - Taking existing terminology as a basis doesn't necessarily imply > restricting the solution (as has been iterated many times on this list, > see also detailed comment below). Besides, in our case it is mainly a > question of *adding* a few terms such as describing the functionality of > the above mentioned support node. (Of course, for that purpose, one new > term will be needed.) True, existing terminology not necessarily implies restricting the solution and I am a fan of reusing terminology where it fits. I didn't get the impression that the existing terminology fits so well with the architecture proposed in the actor's draft and from earlier comments I got the impression that other people share this impression. > > • There is an ambition to symmetrize the problem statement and remove the > intrinsic assymmetry of the access control problem. However aesthetic this > architecture looks in all its symmetry and matching terminology, this > ambition is misguided and hides part of the problem. I suspect it is this > ambition which is behind the re-interpretations of existing terms, such as > "authorization". For example only confidentiality and integrity aspects of > authorization are considered ("The security objectives that can be > addressed by an authorization solution are confidentiality and integrity") > since those can be handled more symmetrically than other aspects of > authorization. More below. I don't understand what you refer to with "symmetrize". I agree that there are different security objectives on the both sides (client side and server side). That's why we need to modelize them. Only then will we be able to see all the problems. If we only model the server side, client side problems will be difficult to see. It would be really nice if you could state which kind of problems are hidden in the actor's draft. I was already asking you to point them out to me for the use cases document. But unfortunately, you were not able or willing to do so until now. It will be difficult to address your comment if you are not explaining it. > > • The end-to-end security setting as described in e.g. > draft-selander-ace-object-security, is missing from in this draft. (See > below) The tasks address the use of proxies (entities that are authorized to speak for ..). Is that what you are aiming at? > > > > Detailed comments: > > Section 1.1 > — > > • "Actor" > > I would call this "role". There is a common use of the terms "actor" and > "role", wherein a "role" characterizes certain functionality and an > "actor" is some entity that may or may not have the functionality > characterised by the role. The term "role" is quite confusing for authorization solutions since it will easily be mixed up with the roles in role based authorization. There was already so much confusion about the term "resource" that I would rather not use the term "role". > > "Resource Overseeing Principal (ROP): > Client Overseeing Principal (COP): > Server Authorization Manager (SAM):" > > These terms have > > > Section 2 > — > > • "authorized representation" > > This term is not defined in the terminology section but supposedly means a > representation the client is configured to send in a particular request > > > • "authorized resources" > > This term is not defined in the terminology section but supposedly means a > resource that a client is configured to request I don't get what you are trying to tell me with these comments. > > > > • "Req.0.2 C is exchanging status updates of a resource only with > authorized resources." > > That the use of the term authorization on the client side is misleading. > Every task a client performs is on behalf of its control node (COP). If > all these tasks are called authorization, then there is nothing that isn't > authorization. There is no system resource on the client side to which > access is authorized. I don't know what your interpretion of authorization is. The handbook of applied cryptography defines it as the "conveyance, to another entity, of official sanction to do or be something". To achieve the security objectives of the client overseeing principal, the client must be able to enforce them. It needs to be able to answer the question "Does my principal think that this resource on this server is an authorized resource or not". Otherwise the security objectives integrity and confidentiality are threatened. The authorization problems on the client side won't go away if we pretend that they are not there or try to define them away. > > Section 3 > — > > • "The security objectives that can be addressed by an authorization > solution are confidentiality and integrity. Availability cannot be > achieved by authorization solutions. However, misconfigured or wrongly > designed authorization solutions can result in availability breaches: > Users might no longer be able to use data and services as they are > supposed to. " > > I agree that confidentiality and integrity protection can be used as one > component to enforce an authorization decision, but characterizing > authorization only as that is misleading. Generally speaking, > authorization is about restricting access to (system) resources, which > include restricting the right to initiate processing on a server, which in > turn provides some resistance against attacks/overload and thus is related > to availability. It might be useful to point out that authorization might also be used for load control. Integrity and confidentiality have a direct dependency to authorization. If the authorization solution is broken, the integrity and confidentiality of data likely is compromised. I agree that you might also use authorization for load control, but availablity is not necessarily breached if the authorization solution fails. > > • "In many cases, one participating party might have different security > objectives than the other. However, to achieve a security objective, both > parties must participate in providing a solution. E.g., if COP requires > the integrity of sensor value representations S is hosting, Both C and S > need to integrity-protect the transmitted data. " > > Why does C need to integrity protect transmitted data? Isn't it sufficient > that S integrity protects the sensor value representation it is hosting? The integrity-protection won't work if C doesn't check the protection of the received data. I will rephrase this part to make it easier to understand > > Section 4 > — > > • "To determine if an entity is authorized to access a resource, an > authentication mechanism is needed. According to the Internet Security > Glossary [RFC4949], authentication is “the process of verifying a claim > that a system entity or system resource has a certain attribute value.” > Examples for attribute values are the ID of a device, the type of the > device or the name of its owner. " > > Authentication, in the sense of verifying a claim about a attribute value, > is not necssary. A server may encrypt a resource representation with a > specific key only possessed by authorized clients (cf. OSCAR, > http://arxiv.org/abs/1404.7799). This is an example for authentication and authorization working closely together. You can do authorization and authentication together if you bind authorization information to a key. But you will still need to make sure that the key is given to the right entity. You can't do authorization if you are not sure who you are authorizing and if you cannot decide if the one you are talking to really is the one who is authorized. > > > • "We use the term authenticated authorization to refer to a synthesis of > mechanism for authentication and authorization. " > > The term "Authenticated authorization" is quite vague. Can you elaborate that? I think the paragraph shows why authentication and authorization mechanism need to work together. > > > • "unrestricted authorization" > > This is defined as "no authorization". Why not just say so? If unrestricted authorization is used, no authorization mechanism is used. Therefore everyone is authorized. "no authorization" might be misinterpreted. > > • "For all cases where an authorization solution is needed (all but > Unrestricted Authorization), the authorizing party needs to be able to > authenticate the party that is to be authorized. Authentication is > therefore required for messages that contain representations of an > accessed item. More precisely, the authorizing party needs to make sure > that the receiver of a message containing a representation, and the sender > of a message containing a representation are authorized to receive and > send this message, respectively. To achieve this, the integrity of these > messages is required: Authenticity cannot be assured if it is possible for > an attacker to modify the message during transmission." > > I find a several things confusing here: > - What party is the authorizing party? A server or a SAM / Authorization > Server? The client or the server. If the term "authorizing party" is confusing I can try to rephrase the section without using it. Summarizing, the section states that the receiver of a resource representation needs to make sure that the sender of the resource representation is allowed to send it and that the sender of a resource representation must make sure that the receiver of a resource representation is allowed to receive it. > > - "Authentication is therefore required for messages that contain > representations of an accessed item. " The next sentence claims to make > precise, but does so in terms of authorization. I don't understand this comment. > > - "the authorizing party needs to make sure that (- - -)the sender of a > message containing a representation are authorized to (- - -) send this > message". I think this had better be rephrased as the CAM enables > configuration of the client. I think configuration is a very vague term and can mean everything in this context. The problem that we need to solve here is an authorization problem. > > > • "The security objectives of one side can often only be achieved with the > help of the other side. E.g., if the server requires the confidentiality > of a resource representation, the client must make sure that it does not > send resource updates to parties other than the server. Therefore, the > client must at least use binary authorization." > > The formulation indicates that the decision whether a client that makes a > request is needs to take into account server policies before encrypting > the request. I think this should be configured in the client. I think it will be difficult to configure in the client what a server that belongs to someone else wants. I think it will be useful to assume that in some scenarios you will always need at least binary authorization on the client side. > > Section 6 > — > > 6.1 > > • "This document does not assume a specific solution." > > This is two-edged sword. If you claim that we can't use OAuth/UMA > architecture because it assumes a specific solution, then so does this > document. It might be helpful if you also state the context of this sentence. This refers to the exchanged messages between the client and the server which is stated in the next sentence. > > > 6.2 > > • "The reason for using an authorization solution is to validate that the > entity that sent the information used for processing is authorized to > provide it. To validate if a sender is authorized to send a received piece > of information, the receiver must determine the sender’s authorization. > Correspondingly, to validate if a receiver is allowed to receive a > message, the sender must determine its authorization. This can only be > achieved with the help of an authentication mechanism." > > I think this is all very complicated, and is overusing the term > "authorization". The server should determine if the client is authorized > to access a resource, and perform accordingly. The client should perform > as configured (potentially dynamically using a CAM-type node). That's it. With "configure" you mean the configuration of authorization on the client side, I guess. > > > 6.4 > > item 1: I think this is out of scope for ACE The process of configuration might be out of scope but it is still a necessary process. In constrained environments it is necessary to consider how this configuration can occur since constrained devices often don't have user interfaces or displays. > item 2: agree. I think we should add something analogous about > configuration of client No need for that. This already applies to both the client and the server. > item 3-4: this is assuming a particular solution. We can obtain > granularity without the attribute exercise by associating certain keys to > certain permissions, as mentioned above. I guess you are referring to item 3. I will try to rephrase it to better include those solutions. The authorization will still need to be enforced as defined in item 4. > > > 7.1 > > "C performs the following tasks: > • Negotiate means for secure communication (Task TSecureComm, see Appendix > A.2.3)." > > Not necessary if there is a TTP, such as an Authorization Server, > providing security context If a device wants to communicate securely, it somehow hast to obtain the means (e.g. keying material) for that. If the Authorization Server provides this to the device this fulfills TSecureComm. > > • "Validate that an entity is an authorized source for R (Task > TValSourceAuthz, see Appendix A.2.2)." > > I would phrase this that C is configured to request R. You mean that you can make sure that an S is an authorized source for R by configuring C to access R on S? That would be one solution. > > "S performs the following tasks: > • Negotiate means for secure communication (Task TSecureComm, see Appendix > A.2.3)." > > Not necessary if there is a TTP, such as an Authorization Server, > providing security context If the authorization provides this to the device, this is TSecureComm. > > > > 7.2 > > "COP must fulfill the following task: > • Configure for C authorization information for sources for R " > > I would rephrase this bullet as "• Configure for C resources R to be > accessed" > > > 7.3 > > • Why does the CAM have to be in the same security domain as C and COP. > Could it not be outsourced? (See e.g. Healthcare scenario > http://kantarainitiative.org/confluence/display/uma/UMA+Trust+Model+User+gu > ide) What do you mean with outsourced? That the principal controlling C is different from the principal that controls CAM? > > > > • The setting with CAM always being intermediary between C and SAM > (=Authorization Server) is problematic. C needs to be authorized (and/or > prove that it is) to access S. In a federated setting it could work that, > as CAM becomes authorized so does all its assigned Cs. But in the general > case, SAM needs to communicate securely with C and provide the necessary > keys or credentials. In this case CAM has no security function. But the > architecture prescribes that interaction between C and SAM is never done > directly, but via CAM. In this case CAM does not have a role at all, so > there is not only a difference where CAM is hosted, but in its function. I don't quite understand what you are getting at. There may be cases where you don't need a distinct CAM. You can have a single machine or a single piece of software that performs CAM's and SAM's tasks. That's why the draft states: "The architecture of an actual solution might differ as long as the security requirements that derive from the relationship between the identified actors are considered. Several actors might share a single device or even be combined in a single piece of software. Interfaces between actors may be realized as protocols or be internal to such a piece of software." > > > > 8.1 > > • Next to last paragraph: Although confidentiality and integrity > protection are the security objectives considered in this document, there > is no consideration of end-to-end security in the presence of intermediary > nodes (which would induce DTLS hop by hop) What do you think is missing here? > > 8.2 > > • In case OAuth is applied to the "less constrained level", what are the > protected resources at SAM accessed by CAM? (Access tokens?) I think finding out how constrained level and less-constrained level protocols can work together is one of the challenges in ACE. I hope we will find out how we will do this exactly but I don't think this is in scope for the actor's draft. The draft just states that there are different requirements for the different levels. Best regards, Steffi > > > > > Best regards > Göran > > > > > > On 2015-03-10 14:25, "Stefanie Gerdes" wrote: > >> Hi all, >> >> Please find attached the new version notification for the actors draft. >> >> The main changes are: >> - To address comments (e.g., in the ACE session in Honolulu) OAuth >> terminology was removed to avoid misunderstandings. >> - The term "owner" was replaced since comments on the list indicated >> that owner might not be a suitable term. >> - A section about autonomous communication was added to point out that >> there is not always an active user in constrained environments, and >> devices need to be able to enforce the user's security policies >> autonomously. >> >> Comments are very welcome. >> >> Thanks, >> Steffi >> >> >> -------- Forwarded Message -------- >> Subject: New Version Notification for draft-gerdes-ace-actors-03.txt >> Date: Mon, 09 Mar 2015 16:49:20 -0700 >> From: internet-drafts@ietf.org >> To: Stefanie Gerdes , Stefanie Gerdes >> >> >> A new version of I-D, draft-gerdes-ace-actors-03.txt >> has been successfully submitted by Stefanie Gerdes and posted to the >> IETF repository. >> >> Name: draft-gerdes-ace-actors >> Revision: 03 >> Title: Actors in the ACE Architecture >> Document date: 2015-03-09 >> Group: Individual Submission >> Pages: 26 >> URL: >> http://www.ietf.org/internet-drafts/draft-gerdes-ace-actors-03.txt >> Status: https://datatracker.ietf.org/doc/draft-gerdes-ace-actors/ >> Htmlized: http://tools.ietf.org/html/draft-gerdes-ace-actors-03 >> Diff: >> http://www.ietf.org/rfcdiff?url2=draft-gerdes-ace-actors-03 >> >> 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. Based on the tasks, an >> architecture is developed to represent the relationships between the >> logical functional entities involved. >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace > > _______________________________________________ > 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 Tue Mar 24 08:54: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 0BA9E1A8AD6 for ; Tue, 24 Mar 2015 08:54:14 -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 X8GlBECYpAoI for ; Tue, 24 Mar 2015 08:54:13 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63C0B1A8F3D for ; Tue, 24 Mar 2015 08:54:11 -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 t2OFs8L6007349; Tue, 24 Mar 2015 16:54:08 +0100 (CET) Received: from [192.168.1.109] (p57A63B56.dip0.t-ipconnect.de [87.166.59.86]) (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 3lBHFD1NCYz2nbY; Tue, 24 Mar 2015 16:54:08 +0100 (CET) Message-ID: <5511889F.50001@tzi.de> Date: Tue, 24 Mar 2015 16:54:07 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Alper Yegin , Ace@ietf.org References: <9AC0EA6E-F823-408D-B5FF-123D0855E93B@yegin.org> In-Reply-To: <9AC0EA6E-F823-408D-B5FF-123D0855E93B@yegin.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] draft-gerdes-ace-actors 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, 24 Mar 2015 15:54:14 -0000 Hi Alper, Thank you for your comment. I was thinking about adding an example use case to the draft but that is quite difficult without proposing a certain solution. If we take the container scenario, C could be the device with the temperature sensor in the banana box and S could be the cooling unit. In this case COP would be the fruit vendor while ROP would be the container owner. CAM and SAM are more powerful devices (class 2 and above). It is also possible that S is the temperature sensor and C is the cooling unit. In this case, ROP would be the fruit vendor and COP would be the container owner. Best regards, Steffi On 03/16/2015 03:47 PM, Alper Yegin wrote: > Hello, > > I've read draft-gerdes-ace-actors-03, and I have one comment: > > It'd be really useful if specific examples were provided for COP/ROM/CAM/SAM. Visualizing the examples helps it easier to grasp the concept and follow the text. > > Alper > > > > > > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > -- Stefanie Gerdes Tel: +49 421 218 63906 TZI Universitt Bremen E-Mail: gerdes@tzi.de Bibliothekstr. 1, MZH 5150 28359 Bremen, Germany From nobody Tue Mar 24 08:54: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 976CD1A8AD6 for ; Tue, 24 Mar 2015 08:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qw4u9dhbcIEH for ; Tue, 24 Mar 2015 08:54:11 -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 62D011A8BBE for ; Tue, 24 Mar 2015 08:54:11 -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 t2OFs63t007340; Tue, 24 Mar 2015 16:54:06 +0100 (CET) Received: from alma.local (dhcp-987d.meeting.ietf.org [31.133.152.125]) (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 3lBHF86fldz2nbV; Tue, 24 Mar 2015 16:54:04 +0100 (CET) Message-ID: <5511889A.7040704@tzi.org> Date: Tue, 24 Mar 2015 10:54:02 -0500 From: Carsten Bormann User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Stefanie Gerdes References: <20150309234920.12025.44848.idtracker@ietfa.amsl.com> <54FEF0C9.30005@tzi.de> <551185DD.2030804@tzi.de> In-Reply-To: <551185DD.2030804@tzi.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= , "Ace@ietf.org" Subject: Re: [Ace] Fwd: New Version Notification for draft-gerdes-ace-actors-03.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, 24 Mar 2015 15:54:15 -0000 Stefanie Gerdes wrote: > I don't know what your interpretion of authorization is. Yesterday in the side meeting, it seemed Göran wants to use authorization as a synonym for "things you can do with an access control list", i.e. access control to resources on a CoAP server. But then there were some audience comments that you actually can use ACLs to do authorization of client behavior as well. So yes, there is some confusion here. Grüße, Carsten From nobody Tue Mar 24 12:55:36 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9681A8A46 for ; Tue, 24 Mar 2015 12:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 o5NcY8MsDS_c for ; Tue, 24 Mar 2015 12:55:32 -0700 (PDT) Received: from outbox.sics.se (outbox.sics.se [193.10.64.137]) by ietfa.amsl.com (Postfix) with ESMTP id AE1871A875C for ; Tue, 24 Mar 2015 12:55:31 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [192.36.171.201]) by outbox.sics.se (Postfix) with ESMTPS id 34A3E54 for ; Tue, 24 Mar 2015 20:55:30 +0100 (CET) Received: from norm.sics.se (norm.sics.se [193.10.64.192]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id t2OJtTQb024918 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 24 Mar 2015 20:55:30 +0100 Received: from [192.168.0.102] (89-253-76-185.customers.ownit.se [89.253.76.185]) by norm.sics.se (Postfix) with ESMTPSA id D0E5E22F for ; Tue, 24 Mar 2015 20:55:29 +0100 (CET) Message-ID: <5511C124.1000708@sics.se> Date: Tue, 24 Mar 2015 20:55:16 +0100 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "ace@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050704020605000009020702" X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sics-se:default, sics-se:default, base:default, @@RPTN) X-p0f-Info: os=Linux 2.2.x-3.x, link=Ethernet or modem X-CanIt-Geo: =?UTF-8?Q?ip=3D89.253.76.185; _country=3DSE; _region=3DSk=C3=A5ne; _city=3DLund; _latitude=3D55.7028; _longitude=3D13.1927; _http://maps.google.com/maps=3Fq=3D55.7028,13.1927&z=3D6?= X-CanItPRO-Stream: outbound-sics-se:outbound (inherits from outbound-sics-se:default, sics-se:default, base:default) X-Canit-Stats-ID: 09O7vTuxi - ca5a9182aad0 - 20150324 X-Antispam-Training-Forget: https://canit.sunet.se/canit/b.php?i=09O7vTuxi&m=ca5a9182aad0&t=20150324&c=f X-Antispam-Training-Nonspam: https://canit.sunet.se/canit/b.php?i=09O7vTuxi&m=ca5a9182aad0&t=20150324&c=n X-Antispam-Training-Spam: https://canit.sunet.se/canit/b.php?i=09O7vTuxi&m=ca5a9182aad0&t=20150324&c=s X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 89.253.76.185 is neither permitted nor denied by domain ludwig@sics.se) receiver=e-mailfilter01.sunet.se; client-ip=89.253.76.185; envelope-from=; helo=norm.sics.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: Subject: [Ace] End-to-end security use case wrt discussion at ACE@IETF92 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, 24 Mar 2015 19:55:35 -0000 This is a cryptographically signed message in MIME format. --------------ms050704020605000009020702 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable There was a comment during the ACE meeting at IETF 92 that we should=20 take up the end-to-end security usecases from=20 draft-selander-object-security in draft-ietf-ace-usecases. I just wanted to point out that draft-ietf-ace-usecases contains a case=20 that illustrates the end-to-end security problem with intermediate=20 nodes. See section 2.5.3. Advanced Metering Infrastructure and U5.7 Does the WG feel that this covers the issue sufficiently? /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 --------------ms050704020605000009020702 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVDCC BhgwggUAoAMCAQICAwyGmDANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTE1MDEwODA4MzkwNloXDTE2MDEwOTIyNDEzMFowODEXMBUGA1UE AwwObHVkd2lnQHNpY3Muc2UxHTAbBgkqhkiG9w0BCQEWDmx1ZHdpZ0BzaWNzLnNlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxUHisC6rgXFsBHHBGo8ulz/cLX3gX5Ufhcwo rp+7djzMMuKPM1KOHq0bjWhmFe8ly8CzWdk2NS600t7IEBQWJiHLsdc12UqmNswQUpD7oqkR 1nRGT6leAHYTWapkR+nczZ2NxD+H7u4ZWVIZg0DFiTqtY8ghYHHYYy8BBoc/jHG78X4+JJAg s5XOa0gVl7W38vDvVpo14xhWEBGjzPk9WxWirqAF66PF+JEu2JD9LzFbpEq829SRXJMFB9wp oQNlH0UQ01/2sWCIBxPpHuEjxEF/V3Z/F2VsNTy4zvYrd+/MYO3w30F+bWQNZsMHEkTW1pEh iz7rQPWTBXoO8Fv0wQIDAQABo4IC1DCCAtAwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTqvKspqEm0E4R1sgsABYKk 6xDJqDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZBgNVHREEEjAQgQ5sdWR3 aWdAc2ljcy5zZTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcC AjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0 aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5 aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQEFBQADggEBAGXwFsbSfv4mMWqIk64CoxuR6ozo7J37igca7d9tpKIzVIp6xp7Zt+a+J9X3 1r4zgMRFnZJWQ5hy82W/fVDeG9i3NGMM6p7DNUrGjTbVHd11BQtbUOG9MSlyWKQbmt3Q1ElC f4SRLAQot5SPryLR2FTxQuFkMOrcDzVxNxnMgatOM2fAO8KS0H+wX+I7gC3pEnbg/eMqNgU+ Ktbc2y9naDNmLNLN65s8TT9xZyoQEn9S1oU8Xnh596OMu49Eccws8Ny+vAGESIHG4bqhMSjj rmDilL1Wj9nQahmBnID5oZD5g9s9KyqxiZIGNnowYYOpCrSeITZ1b7wg50dC8ySojnYwggY0 MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEw MjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0d Lep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiU fsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5Dp IpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuC YKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/ MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0j BBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzAB hhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nm c2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9 eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukD FUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyi kfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8Cnykh ExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b 970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCD z+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqA SfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNb BIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBth HSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+ UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAwyGmDAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTAzMjQxOTU1MTZaMCMGCSqGSIb3DQEJBDEW BBRsNJRS6tY2un9NIxis3ayA5tlh9zBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDDIaYMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJKoZIhvcNAQEBBQAE ggEAoBpBSMGSnCZCNuXtkK2GuzZH2/hqHXzQfdE5Qdtsir553QXrJeavQLslXEBZoH0/aJI9 6Fr0Jkwx/Zj2nI7yyepnIw1qjUKkbUFtIHkjwpaGGKCIvaozQV86nrgOHozd0I3qrsV9DKmi HM3bCDY2CP4wb2rmBrRSwk+B3hyFN4aaRuovINHOtXM00EeWmfllXllqpbdpaulza3i/32PF 4JigPJVjv7c/7W6UDFtl0RVxtONH2zRpfLUISM05jE6Is0mHoVi0OCG+rjR6y82x6j5q8IBz 69v4VNIkOrMuDhhzgPZLJrTAbw1zXyaq3hDVJIU/t32aIyR9EnclBJVdRQAAAAAAAA== --------------ms050704020605000009020702-- From nobody Tue Mar 24 14:50: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 178B31AC418 for ; Tue, 24 Mar 2015 14:50:11 -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 AXDt60255Ks4 for ; Tue, 24 Mar 2015 14:50:06 -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 6C02B1AC420 for ; Tue, 24 Mar 2015 14:50:01 -0700 (PDT) X-AuditID: c1b4fb30-f79996d000006ebb-7e-5511dc073ab0 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id D1.01.28347.70CD1155; Tue, 24 Mar 2015 22:49:59 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.196]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0210.002; Tue, 24 Mar 2015 22:49:59 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Stefanie Gerdes , "Ace@ietf.org" Thread-Topic: [Ace] Fwd: New Version Notification for draft-gerdes-ace-actors-03.txt Thread-Index: AQHQYKF6eNCV1PF07k29OLhbkWWtbJ0rwDSAgAAS4gA= Date: Tue, 24 Mar 2015 21:49:58 +0000 Message-ID: References: <20150309234920.12025.44848.idtracker@ietfa.amsl.com> <54FEF0C9.30005@tzi.de> <551185DD.2030804@tzi.de> In-Reply-To: <551185DD.2030804@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: <6582EA6D9E48AF4CB4B09169FF3557A3@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGfG3Rpf9jmCowcZzRhbfv/UwW2y8eJfR gcljyZKfTB7b3n5lDmCK4rJJSc3JLEst0rdL4Mp4uq++4FoHU0VP212mBsYPjUxdjJwcEgIm EnNnXoWyxSQu3FvP1sXIxSEkcIRRYsO2BewgCSGBJYwS31tUQGw2AReJBw2PwBpEBJwklm77 ywJiCwuESuydsxaongMoHibRuYARwrSSOLnNC6SCRUBVouPLZ7AKXgELiU/LDCA2AQ2/deUs G0gNp4CaxNQ/XxhBbEagc76fWgO2iVlAXOLWk/lQZwpILNlznhnCFpV4+fgfK4gtKqAnsfJ6 ExtEXEli7eHtLCC7mAU0Jdbv0ocYYy0x5W4PK4StKDGl+yHYg7wCghInZz5hmcAoPgvJtlkI 3bOQdM9C0j0LSfcCRtZVjKLFqcVJuelGRnqpRZnJxcX5eXp5qSWbGIGRdnDLb4MdjC+fOx5i FOBgVOLhNbgsECrEmlhWXJl7iFGag0VJnNfO+FCIkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6p Bsa2pDUvI6NfON549jTOas8HUcfrdg+vFEt0du+00S9/JHpy/dzTpq98DgXnbLKJ+jj/HssE gY+ZAb7T9nI3sOmoqInFzPBJluL4/TlyddyLL8bSzefO215hmvWbze7ztI9mKbvKklvddl5t 2bbCdPZ88cJj8wuy7tu5/snTVBHut4jZwMMgvlyJpTgj0VCLuag4EQBpv7B1lQIAAA== Archived-At: Subject: Re: [Ace] Fwd: New Version Notification for draft-gerdes-ace-actors-03.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, 24 Mar 2015 21:50:11 -0000 SGkgU3RlZmZpLA0KDQpJIGludGVycHJldCB0aGUgb3V0Y29tZSBvZiB0aGUgbWVldGluZyB0aGF0 IEx1ZHdpZywgeW91IGFuZCBJIHNob3VsZA0KY29sbGFib3JhdGUgb24gZHJhZnRpbmcgYSBkb2N1 bWVudCBjb250YWluaW5nIHRoZSBhcmNoaXRlY3R1cmUsIHRlcm1zIGFuZA0KcHJvYmxlbSBzdGF0 ZW1lbnQgYWNjb3JkaW5nIHRvIHRoZSBzaWRlIG1lZXRpbmcgcmVzdWx0cyBmcm9tIHllc3RlcmRh eSBhbmQNCmRvY3VtZW50IHRoYXQgdG9nZXRoZXIgd2l0aCBwYXJ0cyBvZiB0aGUgYWN0b3JzIGRy YWZ0IGFuZCB0aGUgcHJvYmxlbQ0KZGVzY3JpcHRpb24gZHJhZnQuIA0KDQpJIHByb3Bvc2Ugd2Ug dGFrZSB0aGUgY29udGludWVkIGRpc2N1c3Npb24gb2ZmbGluZSB0byBzYXZlIHRoZSBwb29yIGVh cnMNCm9mIHRoZSBBQ0UgbWVtYmVycy4NCg0KQmVzdCByZWdhcmRzLA0KR8O2cmFuDQoNCg0KT24g MjAxNS0wMy0yNCAxMDo0MiwgIlN0ZWZhbmllIEdlcmRlcyIgPGdlcmRlc0B0emkuZGU+IHdyb3Rl Og0KDQo+SGkgR8O2cmFuLA0KPg0KPlRoYW5rIHlvdSBmb3IgeW91ciBjb21tZW50cy4NCj4NCj5P biAwMy8xNy8yMDE1IDExOjU5IEFNLCBHw7ZyYW4gU2VsYW5kZXIgd3JvdGU6DQo+Pg0KPj4gSGkg U3RlZmZpLA0KPj4NCj4+IEkndmUgZmluYWxseSBnb3QgYXJvdW5kIHRvIHJlYWQgdGhlICJhY3Rv cnMiIGRyYWZ0IGFzIGEgd2hvbGUuIEkndmUNCj4+bGlzdGVkDQo+PiBzb21lIGNvbW1lbnRzIGJl bG93Lg0KPj4NCj4+DQo+PiBHZW5lcmFsOg0KPj4NCj4+IOKAoiBUaGUgZHJhZnQgaW50cm9kdWNl cyBvbmUgbmV3IG5vZGUgaW4gdGhlIGFyY2hpdGVjdHVyZSAoY29tcGFyZWQgdG8NCj4+ZS5nLg0K Pj4gVU1BKSBjYWxsZWQgQ09QLCBzdXBwb3J0aW5nIGEgY29uc3RyYWluZWQgY2xpZW50LiBJIHRo aW5rIHRoaXMga2luZCBvZg0KPj4gInN1cHBvcnQgbm9kZSIgaXMgdXNlZnVsLCBidXQgaXRzIGZ1 bmN0aW9uYWxpdHkgbmVlZHMgdG8gYmUgZnVydGhlcg0KPj4gZWxhYm9yYXRlZCAoc2VlIGRldGFp bGVkIGNvbW1lbnRzKS4NCj4NCj5JbiBmYWN0IHRoZXJlIGFyZSB0d28gc3VwcG9ydGluZyBub2Rl cyBjYWxsZWQgQ0FNIGFuZCBTQU0uIFRoZXkgYm90aA0KPmhlbHAgdGhlaXIgcmVzcGVjdGl2ZSBj b25zdHJhaW5lZCBkZXZpY2Ugd2l0aCBhdXRoZW50aWNhdGlvbiBhbmQNCj5hdXRob3JpemF0aW9u IHNpbmNlIHRoZSBjb25zdHJhaW5lZCBkZXZpY2VzIG1pZ2h0IGJlIHRvbyBjb25zdHJhaW5lZCB0 bw0KPnBlcmZvcm0gY29tcGxleCBzZWN1cml0eSB0YXNrcyBvbiB0aGVpciBvd24sIGUuZy4gc3Rv cmluZyBhIGxhcmdlIG51bWJlcg0KPm9mIGtleXMgb3IgaW50ZXJwcmV0aW5nIGNvbXBsZXggYXV0 aG9yaXphdGlvbiBwb2xpY2llcy4gTW9yZW92ZXIsIENBTQ0KPmFuZCBTQU0gcHJvdmlkZSB1c2Vy IGludGVyZmFjZXMgd2hpY2ggdGhlIGNvbnN0cmFpbmVkIGRldmljZXMgbWlnaHQgbm90DQo+aGF2 ZS4NCj4NCj4+DQo+PiDigKIgVGhlcmUgaXMgbG90cyBvZiBpbm5vdmF0aW9uIG9mIHRlcm1pbm9s b2d5OyBib3RoIG5ldyB0ZXJtcw0KPj4gKGF1dGhlbnRpY2F0ZWQgYXV0aG9yaXphdGlvbiwgYmlu YXJ5IGF1dGhvcml6YXRpb24sIHVucmVzdHJpY3RlZA0KPj4gYXV0aG9yaXphdGlvbiwgYXV0aG9y aXplZCByZXByZXNlbnRhdGlvbiwgYXV0aG9yaXplZCByZXNvdXJjZSwNCj4+ZW5kb3JzZW1lbnQN Cj4+IGluZm9ybWF0aW9uLCBjb21wbGV4aXR5IGxldmVscywgZXRjLik7IG5ldyBuYW1lcyBmb3Ig cm9sZXMgaW4gdGhlDQo+PiBhdXRob3JpemF0aW9uIGFyY2hpdGVjdHVyZSAoQ2xpZW50IE92ZXJz ZWVzaW5nIFByaW5jaXBhbCwgU2VydmVyDQo+PiBPdmVyc2VlaW5nIFByaW5jaXBhbCwgQ2xpZW50 IEF1dGhvcml6YXRpb24gTWFuYWdlciwgU2VydmVyIEF1dGhvcml6YXRpb24NCj4+IE1hbmFnZXIs IEF0dHJpYnV0ZSBCaW5kaW5nIEF1dGhvcml0eSk7IGFuZCBhbHNvIHRoZSBtZWFuaW5nIG9mIGV4 aXN0aW5nDQo+PiB0ZXJtcyAoZS5nLiBhdXRob3JpemF0aW9uKSBpcyBiZWluZyBjaGFuZ2VkLiBJ IGRpc2FncmVlIHdpdGggaG93IHNvbWUNCj4+IHRlcm1zIGFyZSB1c2VkIGFuZCBtb3Jlb3ZlciBJ IHRoaW5rIGl0IHdvdWxkIGJlIG11Y2ggYmV0dGVyIHRvIHVzZSBsZXNzDQo+PiB0ZXJtaW5vbG9n eSBhbmQgdHJ5IHRvIHJldXNlIGV4aXN0aW5nIHRlcm1pbm9sb2d5LiBIZXJlIGFyZSBhIGZldw0K Pj5yZWFzb25zOg0KPg0KPkkgZmluZCBpdCBzdXJwcmlzaW5nIHRoYXQgeW91IHNlZW0gdG8gdGhp bmsgdGhhdCB0aGUgYWN0b3JzIGRyYWZ0DQo+cmVkZWZpbmVzIGF1dGhvcml6YXRpb24uIFRoZSBj b21tb24gdW5kZXJzdGFuZGluZyBpcyB0aGF0IGF1dGhvcml6YXRpb24NCj5pcyBhYm91dCBhbGxv d2luZyBlbnRpdGllcyB0byBkbyBvciBiZSBzb21ldGhpbmcuIERvIHlvdSBxdWVzdGlvbiB0aGF0 Pw0KPg0KPkkgYWdyZWUgdGhhdCB3ZSBzaG91bGQgdXNlIGV4aXNpdGluZyB0ZXJtaW5vbG9neSB3 aGVyZSBhcHBsaWNhYmxlLiBJIGFtDQo+bm90IGF3YXJlIHRoYXQgdGhlcmUgYXJlIGRlZmluaXRp b25zIGZvciB0aGUgbGV2ZWxzIG9mIGdyYW51bGFyaXR5IGZvcg0KPnRoZSBhdXRob3JpemF0aW9u IHN1Y2ggYXMgImJpbmFyeSBhdXRob3JpemF0aW9uIiwgImRldmljZSBhdXRob3JpemF0aW9uIg0K PmV0Yy4gZWxzZXdoZXJlLiBJZiB0aGVyZSBpcywgcGxlYXNlIHBvaW50IGl0IG91dCB0byBtZS4N Cj4NCj4+DQo+PiAJLSBBY2Nlc3MgY29udHJvbCBpcyBub3QgYSBuZXcgcHJvYmxlbS4gQWx0aG91 Z2ggdGhlIGNvbnN0cmFpbmVkDQo+PiBlbnZpcm9ubWVudCBtb3RpdmF0ZXMgc29tZSBuZXcgZnVu Y3Rpb25hbGl0eSwgdGhhdCBkb2VzIG5vdCB3YXJyYW50IGENCj4+IGNvbXBsZXRseSBuZXcgdGVy bWlub2xvZ3kuDQo+DQo+UGVvcGxlIGZvdW5kIHRoZSBPQXV0aCB0ZXJtaW5vbG9neSBpbiB0aGUg ZHJhZnQgY29uZnVzaW5nIHdoaWNoIGlzIHdoeQ0KPml0IHdhcyByZW1vdmVkLiBJIHRoaW5rIGl0 IHdpbGwgYmUgbW9yZSBkYW1hZ2luZyB0byB1c2UgYSB0ZXJtaW5vbG9neQ0KPnRoYXQgZG9lc24n dCByZWFsbHkgZml0Lg0KPg0KPj4NCj4+IAktIEF0IHRoZSBlbmQgb2YgdGhlIGRheSB3ZSB3YW50 IHBlb3BsZSBhcHByb2FjaGluZyB0aGlzIHdvcmsgdG8gYmUgYWJsZQ0KPj4gdG8gcmV1c2UgZ2Fp bmVkIGtub3dsZWRnZSBmcm9tIG90aGVyIGNvbnRleHRzIHRvIHF1aWNrbHkgdW5kZXJzdGFuZCB3 aGF0DQo+PiB0aGlzIHdvcmsgaXMgZ29vZCBmb3IuIFRoZSBzaGVlciBhbW91bnQgb2YgbmV3IHRl cm1zIGlzIGRpc2NvdXJhZ2luZy4NCj4NCj5Ob3QgYmVpbmcgYWJsZSB0byB1bmRlcnN0YW5kIHRo ZSB1bmRlcmx5aW5nIHByb2JsZW1zIGJlY2F1c2UgdGhlDQo+dGVybWlub2xvZ3kgaW5kaWNhdGVz IGEgZGlmZmVyZW50IHNvbHV0aW9uIHdpbGwgb25seSBtYWtlIHRoaW5ncyB3b3JzZS4NCj4NCj4+ DQo+PiAJLSBUYWtpbmcgZXhpc3RpbmcgdGVybWlub2xvZ3kgYXMgYSBiYXNpcyBkb2Vzbid0IG5l Y2Vzc2FyaWx5IGltcGx5DQo+PiByZXN0cmljdGluZyB0aGUgc29sdXRpb24gKGFzIGhhcyBiZWVu IGl0ZXJhdGVkIG1hbnkgdGltZXMgb24gdGhpcyBsaXN0LA0KPj4gc2VlIGFsc28gZGV0YWlsZWQg Y29tbWVudCBiZWxvdykuIEJlc2lkZXMsIGluIG91ciBjYXNlIGl0IGlzIG1haW5seSBhDQo+PiBx dWVzdGlvbiBvZiAqYWRkaW5nKiBhIGZldyB0ZXJtcyBzdWNoIGFzIGRlc2NyaWJpbmcgdGhlIGZ1 bmN0aW9uYWxpdHkgb2YNCj4+IHRoZSBhYm92ZSBtZW50aW9uZWQgc3VwcG9ydCBub2RlLiAoT2Yg Y291cnNlLCBmb3IgdGhhdCBwdXJwb3NlLCBvbmUgbmV3DQo+PiB0ZXJtIHdpbGwgYmUgbmVlZGVk LikNCj4NCj5UcnVlLCBleGlzdGluZyB0ZXJtaW5vbG9neSBub3QgbmVjZXNzYXJpbHkgaW1wbGll cyByZXN0cmljdGluZyB0aGUNCj5zb2x1dGlvbiBhbmQgSSBhbSBhIGZhbiBvZiByZXVzaW5nIHRl cm1pbm9sb2d5IHdoZXJlIGl0IGZpdHMuIEkgZGlkbid0DQo+Z2V0IHRoZSBpbXByZXNzaW9uIHRo YXQgdGhlIGV4aXN0aW5nIHRlcm1pbm9sb2d5IGZpdHMgc28gd2VsbCB3aXRoIHRoZQ0KPmFyY2hp dGVjdHVyZSBwcm9wb3NlZCBpbiB0aGUgYWN0b3IncyBkcmFmdCBhbmQgZnJvbSBlYXJsaWVyIGNv bW1lbnRzIEkNCj5nb3QgdGhlIGltcHJlc3Npb24gdGhhdCBvdGhlciBwZW9wbGUgc2hhcmUgdGhp cyBpbXByZXNzaW9uLg0KPg0KPj4NCj4+IOKAoiBUaGVyZSBpcyBhbiBhbWJpdGlvbiB0byBzeW1t ZXRyaXplIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBhbmQgcmVtb3ZlDQo+PnRoZQ0KPj4gaW50cmlu c2ljIGFzc3ltbWV0cnkgb2YgdGhlIGFjY2VzcyBjb250cm9sIHByb2JsZW0uIEhvd2V2ZXIgYWVz dGhldGljDQo+PnRoaXMNCj4+IGFyY2hpdGVjdHVyZSBsb29rcyBpbiBhbGwgaXRzIHN5bW1ldHJ5 IGFuZCBtYXRjaGluZyB0ZXJtaW5vbG9neSwgdGhpcw0KPj4gYW1iaXRpb24gaXMgbWlzZ3VpZGVk IGFuZCBoaWRlcyBwYXJ0IG9mIHRoZSBwcm9ibGVtLiBJIHN1c3BlY3QgaXQgaXMNCj4+dGhpcw0K Pj4gYW1iaXRpb24gd2hpY2ggaXMgYmVoaW5kIHRoZSByZS1pbnRlcnByZXRhdGlvbnMgb2YgZXhp c3RpbmcgdGVybXMsIHN1Y2gNCj4+YXMNCj4+ICJhdXRob3JpemF0aW9uIi4gRm9yIGV4YW1wbGUg b25seSBjb25maWRlbnRpYWxpdHkgYW5kIGludGVncml0eSBhc3BlY3RzDQo+Pm9mDQo+PiBhdXRo b3JpemF0aW9uIGFyZSBjb25zaWRlcmVkICAoIlRoZSBzZWN1cml0eSBvYmplY3RpdmVzIHRoYXQg Y2FuIGJlDQo+PiBhZGRyZXNzZWQgYnkgYW4gYXV0aG9yaXphdGlvbiBzb2x1dGlvbiBhcmUgY29u ZmlkZW50aWFsaXR5IGFuZA0KPj5pbnRlZ3JpdHkiKQ0KPj4gc2luY2UgdGhvc2UgY2FuIGJlIGhh bmRsZWQgbW9yZSBzeW1tZXRyaWNhbGx5IHRoYW4gb3RoZXIgYXNwZWN0cyBvZg0KPj4gYXV0aG9y aXphdGlvbi4gTW9yZSBiZWxvdy4NCj4NCj5JIGRvbid0IHVuZGVyc3RhbmQgd2hhdCB5b3UgcmVm ZXIgdG8gd2l0aCAic3ltbWV0cml6ZSIuIEkgYWdyZWUgdGhhdA0KPnRoZXJlIGFyZSBkaWZmZXJl bnQgc2VjdXJpdHkgb2JqZWN0aXZlcyBvbiB0aGUgYm90aCBzaWRlcyAoY2xpZW50IHNpZGUNCj5h bmQgc2VydmVyIHNpZGUpLiBUaGF0J3Mgd2h5IHdlIG5lZWQgdG8gbW9kZWxpemUgdGhlbS4gT25s eSB0aGVuIHdpbGwgd2UNCj5iZSBhYmxlIHRvIHNlZSBhbGwgdGhlIHByb2JsZW1zLiBJZiB3ZSBv bmx5IG1vZGVsIHRoZSBzZXJ2ZXIgc2lkZSwNCj5jbGllbnQgc2lkZSBwcm9ibGVtcyB3aWxsIGJl IGRpZmZpY3VsdCB0byBzZWUuDQo+DQo+SXQgd291bGQgYmUgcmVhbGx5IG5pY2UgaWYgeW91IGNv dWxkIHN0YXRlIHdoaWNoIGtpbmQgb2YgcHJvYmxlbXMgYXJlDQo+aGlkZGVuIGluIHRoZSBhY3Rv cidzIGRyYWZ0LiBJIHdhcyBhbHJlYWR5IGFza2luZyB5b3UgdG8gcG9pbnQgdGhlbSBvdXQNCj50 byBtZSBmb3IgdGhlIHVzZSBjYXNlcyBkb2N1bWVudC4gQnV0IHVuZm9ydHVuYXRlbHksIHlvdSB3 ZXJlIG5vdCBhYmxlDQo+b3Igd2lsbGluZyB0byBkbyBzbyB1bnRpbCBub3cuIEl0IHdpbGwgYmUg ZGlmZmljdWx0IHRvIGFkZHJlc3MgeW91cg0KPmNvbW1lbnQgaWYgeW91IGFyZSBub3QgZXhwbGFp bmluZyBpdC4NCj4NCj4+DQo+PiDigKIgVGhlIGVuZC10by1lbmQgc2VjdXJpdHkgc2V0dGluZyBh cyBkZXNjcmliZWQgaW4gZS5nLg0KPj4gZHJhZnQtc2VsYW5kZXItYWNlLW9iamVjdC1zZWN1cml0 eSwgaXMgbWlzc2luZyBmcm9tIGluIHRoaXMgZHJhZnQuIChTZWUNCj4+IGJlbG93KQ0KPg0KPlRo ZSB0YXNrcyBhZGRyZXNzIHRoZSB1c2Ugb2YgcHJveGllcyAoZW50aXRpZXMgdGhhdCBhcmUgYXV0 aG9yaXplZCB0bw0KPnNwZWFrIGZvciAuLikuIElzIHRoYXQgd2hhdCB5b3UgYXJlIGFpbWluZyBh dD8NCj4NCj4+DQo+Pg0KPj4NCj4+IERldGFpbGVkIGNvbW1lbnRzOg0KPj4NCj4+IFNlY3Rpb24g MS4xDQo+PiDigJQNCj4+DQo+PiDigKIgIkFjdG9yIg0KPj4NCj4+IEkgd291bGQgY2FsbCB0aGlz ICJyb2xlIi4gVGhlcmUgaXMgYSBjb21tb24gdXNlIG9mIHRoZSB0ZXJtcyAiYWN0b3IiIGFuZA0K Pj4gInJvbGUiLCB3aGVyZWluIGEgInJvbGUiIGNoYXJhY3Rlcml6ZXMgY2VydGFpbiBmdW5jdGlv bmFsaXR5IGFuZCBhbg0KPj4gImFjdG9yIiBpcyBzb21lIGVudGl0eSB0aGF0IG1heSBvciBtYXkg bm90IGhhdmUgdGhlIGZ1bmN0aW9uYWxpdHkNCj4+IGNoYXJhY3RlcmlzZWQgYnkgdGhlIHJvbGUu DQo+DQo+VGhlIHRlcm0gInJvbGUiIGlzIHF1aXRlIGNvbmZ1c2luZyBmb3IgYXV0aG9yaXphdGlv biBzb2x1dGlvbnMgc2luY2UgaXQNCj53aWxsIGVhc2lseSBiZSBtaXhlZCB1cCB3aXRoIHRoZSBy b2xlcyBpbiByb2xlIGJhc2VkIGF1dGhvcml6YXRpb24uDQo+VGhlcmUgd2FzIGFscmVhZHkgc28g bXVjaCBjb25mdXNpb24gYWJvdXQgdGhlIHRlcm0gInJlc291cmNlIiB0aGF0IEkNCj53b3VsZCBy YXRoZXIgbm90IHVzZSB0aGUgdGVybSAicm9sZSIuDQo+DQo+Pg0KPj4gIlJlc291cmNlIE92ZXJz ZWVpbmcgUHJpbmNpcGFsIChST1ApOg0KPj4gQ2xpZW50IE92ZXJzZWVpbmcgUHJpbmNpcGFsIChD T1ApOg0KPj4gU2VydmVyIEF1dGhvcml6YXRpb24gTWFuYWdlciAoU0FNKToiDQo+Pg0KPj4gVGhl c2UgdGVybXMgaGF2ZQ0KPj4NCj4+DQo+PiBTZWN0aW9uIDINCj4+IOKAlA0KPj4NCj4+IOKAoiAi YXV0aG9yaXplZCByZXByZXNlbnRhdGlvbiINCj4+DQo+PiBUaGlzIHRlcm0gaXMgbm90IGRlZmlu ZWQgaW4gdGhlIHRlcm1pbm9sb2d5IHNlY3Rpb24gYnV0IHN1cHBvc2VkbHkNCj4+bWVhbnMgYQ0K Pj4gcmVwcmVzZW50YXRpb24gdGhlIGNsaWVudCBpcyBjb25maWd1cmVkIHRvIHNlbmQgaW4gYSBw YXJ0aWN1bGFyIHJlcXVlc3QNCj4+DQo+Pg0KPj4g4oCiICJhdXRob3JpemVkIHJlc291cmNlcyIN Cj4+DQo+PiBUaGlzIHRlcm0gaXMgbm90IGRlZmluZWQgaW4gdGhlIHRlcm1pbm9sb2d5IHNlY3Rp b24gYnV0IHN1cHBvc2VkbHkNCj4+bWVhbnMgYQ0KPj4gcmVzb3VyY2UgdGhhdCBhIGNsaWVudCBp cyBjb25maWd1cmVkIHRvIHJlcXVlc3QNCj4NCj5JIGRvbid0IGdldCB3aGF0IHlvdSBhcmUgdHJ5 aW5nIHRvIHRlbGwgbWUgd2l0aCB0aGVzZSBjb21tZW50cy4NCj4NCj4+DQo+Pg0KPj4NCj4+IOKA oiAiUmVxLjAuMiAgICBDIGlzIGV4Y2hhbmdpbmcgc3RhdHVzIHVwZGF0ZXMgb2YgYSByZXNvdXJj ZSBvbmx5IHdpdGgNCj4+ICAgICAgICBhdXRob3JpemVkIHJlc291cmNlcy4iDQo+Pg0KPj4gVGhh dCB0aGUgdXNlIG9mIHRoZSB0ZXJtIGF1dGhvcml6YXRpb24gb24gdGhlIGNsaWVudCBzaWRlIGlz IG1pc2xlYWRpbmcuDQo+PiBFdmVyeSB0YXNrIGEgY2xpZW50IHBlcmZvcm1zIGlzIG9uIGJlaGFs ZiBvZiBpdHMgY29udHJvbCBub2RlIChDT1ApLiBJZg0KPj4gYWxsIHRoZXNlIHRhc2tzIGFyZSBj YWxsZWQgYXV0aG9yaXphdGlvbiwgdGhlbiB0aGVyZSBpcyBub3RoaW5nIHRoYXQNCj4+aXNuJ3QN Cj4+IGF1dGhvcml6YXRpb24uICBUaGVyZSBpcyBubyBzeXN0ZW0gcmVzb3VyY2Ugb24gdGhlIGNs aWVudCBzaWRlIHRvIHdoaWNoDQo+PiBhY2Nlc3MgaXMgYXV0aG9yaXplZC4NCj4NCj5JIGRvbid0 IGtub3cgd2hhdCB5b3VyIGludGVycHJldGlvbiBvZiBhdXRob3JpemF0aW9uIGlzLiBUaGUgaGFu ZGJvb2sgb2YNCj5hcHBsaWVkIGNyeXB0b2dyYXBoeSBkZWZpbmVzIGl0IGFzIHRoZSAiY29udmV5 YW5jZSwgdG8gYW5vdGhlciBlbnRpdHksDQo+b2Ygb2ZmaWNpYWwgc2FuY3Rpb24gdG8gZG8gb3Ig YmUgc29tZXRoaW5nIi4NCj4NCj5UbyBhY2hpZXZlIHRoZSBzZWN1cml0eSBvYmplY3RpdmVzIG9m IHRoZSBjbGllbnQgb3ZlcnNlZWluZyBwcmluY2lwYWwsDQo+dGhlIGNsaWVudCBtdXN0IGJlIGFi bGUgdG8gZW5mb3JjZSB0aGVtLiBJdCBuZWVkcyB0byBiZSBhYmxlIHRvIGFuc3dlcg0KPnRoZSBx dWVzdGlvbiAiRG9lcyBteSBwcmluY2lwYWwgdGhpbmsgdGhhdCB0aGlzIHJlc291cmNlIG9uIHRo aXMgc2VydmVyDQo+aXMgYW4gYXV0aG9yaXplZCByZXNvdXJjZSBvciBub3QiLiBPdGhlcndpc2Ug dGhlIHNlY3VyaXR5IG9iamVjdGl2ZXMNCj5pbnRlZ3JpdHkgYW5kIGNvbmZpZGVudGlhbGl0eSBh cmUgdGhyZWF0ZW5lZC4NCj4NCj5UaGUgYXV0aG9yaXphdGlvbiBwcm9ibGVtcyBvbiB0aGUgY2xp ZW50IHNpZGUgd29uJ3QgZ28gYXdheSBpZiB3ZQ0KPnByZXRlbmQgdGhhdCB0aGV5IGFyZSBub3Qg dGhlcmUgb3IgdHJ5IHRvIGRlZmluZSB0aGVtIGF3YXkuDQo+DQo+Pg0KPj4gU2VjdGlvbiAzDQo+ PiDigJQNCj4+DQo+PiDigKIgIlRoZSBzZWN1cml0eSBvYmplY3RpdmVzIHRoYXQgY2FuIGJlIGFk ZHJlc3NlZCBieSBhbiBhdXRob3JpemF0aW9uDQo+PiBzb2x1dGlvbiBhcmUgY29uZmlkZW50aWFs aXR5IGFuZCBpbnRlZ3JpdHkuIEF2YWlsYWJpbGl0eSBjYW5ub3QgYmUNCj4+IGFjaGlldmVkIGJ5 IGF1dGhvcml6YXRpb24gc29sdXRpb25zLiBIb3dldmVyLCBtaXNjb25maWd1cmVkIG9yIHdyb25n bHkNCj4+IGRlc2lnbmVkIGF1dGhvcml6YXRpb24gc29sdXRpb25zIGNhbiByZXN1bHQgaW4gYXZh aWxhYmlsaXR5IGJyZWFjaGVzOg0KPj4gVXNlcnMgbWlnaHQgbm8gbG9uZ2VyIGJlIGFibGUgdG8g dXNlIGRhdGEgYW5kIHNlcnZpY2VzIGFzIHRoZXkgYXJlDQo+PiBzdXBwb3NlZCB0by4gIg0KPj4N Cj4+IEkgYWdyZWUgdGhhdCBjb25maWRlbnRpYWxpdHkgYW5kIGludGVncml0eSBwcm90ZWN0aW9u IGNhbiBiZSB1c2VkIGFzIG9uZQ0KPj4gY29tcG9uZW50IHRvIGVuZm9yY2UgYW4gYXV0aG9yaXph dGlvbiBkZWNpc2lvbiwgYnV0IGNoYXJhY3Rlcml6aW5nDQo+PiBhdXRob3JpemF0aW9uIG9ubHkg YXMgdGhhdCBpcyBtaXNsZWFkaW5nLiBHZW5lcmFsbHkgc3BlYWtpbmcsDQo+PiBhdXRob3JpemF0 aW9uIGlzIGFib3V0IHJlc3RyaWN0aW5nIGFjY2VzcyB0byAoc3lzdGVtKSByZXNvdXJjZXMsIHdo aWNoDQo+PiBpbmNsdWRlIHJlc3RyaWN0aW5nIHRoZSByaWdodCB0byBpbml0aWF0ZSBwcm9jZXNz aW5nIG9uIGEgc2VydmVyLCB3aGljaA0KPj5pbg0KPj4gdHVybiBwcm92aWRlcyBzb21lIHJlc2lz dGFuY2UgYWdhaW5zdCBhdHRhY2tzL292ZXJsb2FkIGFuZCB0aHVzIGlzDQo+PnJlbGF0ZWQNCj4+ IHRvIGF2YWlsYWJpbGl0eS4NCj4NCj5JdCBtaWdodCBiZSB1c2VmdWwgdG8gcG9pbnQgb3V0IHRo YXQgYXV0aG9yaXphdGlvbiBtaWdodCBhbHNvIGJlIHVzZWQNCj5mb3IgbG9hZCBjb250cm9sLg0K Pg0KPkludGVncml0eSBhbmQgY29uZmlkZW50aWFsaXR5IGhhdmUgYSBkaXJlY3QgZGVwZW5kZW5j eSB0byBhdXRob3JpemF0aW9uLg0KPklmIHRoZSBhdXRob3JpemF0aW9uIHNvbHV0aW9uIGlzIGJy b2tlbiwgdGhlIGludGVncml0eSBhbmQNCj5jb25maWRlbnRpYWxpdHkgb2YgZGF0YSBsaWtlbHkg aXMgY29tcHJvbWlzZWQuIEkgYWdyZWUgdGhhdCB5b3UgbWlnaHQNCj5hbHNvIHVzZSBhdXRob3Jp emF0aW9uIGZvciBsb2FkIGNvbnRyb2wsIGJ1dCBhdmFpbGFibGl0eSBpcyBub3QNCj5uZWNlc3Nh cmlseSBicmVhY2hlZCBpZiB0aGUgYXV0aG9yaXphdGlvbiBzb2x1dGlvbiBmYWlscy4NCj4NCj4+ DQo+PiDigKIgIkluIG1hbnkgY2FzZXMsIG9uZSBwYXJ0aWNpcGF0aW5nIHBhcnR5IG1pZ2h0IGhh dmUgZGlmZmVyZW50IHNlY3VyaXR5DQo+PiBvYmplY3RpdmVzIHRoYW4gdGhlIG90aGVyLiBIb3dl dmVyLCB0byBhY2hpZXZlIGEgc2VjdXJpdHkgb2JqZWN0aXZlLA0KPj5ib3RoDQo+PiBwYXJ0aWVz IG11c3QgcGFydGljaXBhdGUgaW4gcHJvdmlkaW5nIGEgc29sdXRpb24uIEUuZy4sIGlmIENPUCBy ZXF1aXJlcw0KPj4gdGhlIGludGVncml0eSBvZiBzZW5zb3IgdmFsdWUgcmVwcmVzZW50YXRpb25z IFMgaXMgaG9zdGluZywgQm90aCBDIGFuZCBTDQo+PiBuZWVkIHRvIGludGVncml0eS1wcm90ZWN0 IHRoZSB0cmFuc21pdHRlZCBkYXRhLiAiDQo+Pg0KPj4gV2h5IGRvZXMgQyBuZWVkIHRvIGludGVn cml0eSBwcm90ZWN0IHRyYW5zbWl0dGVkIGRhdGE/IElzbid0IGl0DQo+PnN1ZmZpY2llbnQNCj4+ IHRoYXQgUyBpbnRlZ3JpdHkgcHJvdGVjdHMgdGhlIHNlbnNvciB2YWx1ZSByZXByZXNlbnRhdGlv biBpdCBpcyBob3N0aW5nPw0KPg0KPlRoZSBpbnRlZ3JpdHktcHJvdGVjdGlvbiB3b24ndCB3b3Jr IGlmIEMgZG9lc24ndCBjaGVjayB0aGUgcHJvdGVjdGlvbiBvZg0KPnRoZSByZWNlaXZlZCBkYXRh LiBJIHdpbGwgcmVwaHJhc2UgdGhpcyBwYXJ0IHRvIG1ha2UgaXQgZWFzaWVyIHRvDQo+dW5kZXJz dGFuZA0KPg0KPj4NCj4+IFNlY3Rpb24gNA0KPj4g4oCUDQo+Pg0KPj4g4oCiICJUbyBkZXRlcm1p bmUgaWYgYW4gZW50aXR5IGlzIGF1dGhvcml6ZWQgdG8gYWNjZXNzIGEgcmVzb3VyY2UsIGFuDQo+ PiBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20gaXMgbmVlZGVkLiBBY2NvcmRpbmcgdG8gdGhlIElu dGVybmV0IFNlY3VyaXR5DQo+PiBHbG9zc2FyeSBbUkZDNDk0OV0sIGF1dGhlbnRpY2F0aW9uIGlz IOKAnHRoZSBwcm9jZXNzIG9mIHZlcmlmeWluZyBhIGNsYWltDQo+PiB0aGF0IGEgc3lzdGVtIGVu dGl0eSBvciBzeXN0ZW0gcmVzb3VyY2UgaGFzIGEgY2VydGFpbiBhdHRyaWJ1dGUgdmFsdWUu4oCd DQo+PiBFeGFtcGxlcyBmb3IgYXR0cmlidXRlIHZhbHVlcyBhcmUgdGhlIElEIG9mIGEgZGV2aWNl LCB0aGUgdHlwZSBvZiB0aGUNCj4+IGRldmljZSBvciB0aGUgbmFtZSBvZiBpdHMgb3duZXIuICIN Cj4+DQo+PiBBdXRoZW50aWNhdGlvbiwgaW4gdGhlIHNlbnNlIG9mIHZlcmlmeWluZyBhIGNsYWlt IGFib3V0IGEgYXR0cmlidXRlDQo+PnZhbHVlLA0KPj4gaXMgbm90IG5lY3NzYXJ5LiBBIHNlcnZl ciBtYXkgZW5jcnlwdCBhIHJlc291cmNlIHJlcHJlc2VudGF0aW9uIHdpdGggYQ0KPj4gc3BlY2lm aWMga2V5IG9ubHkgcG9zc2Vzc2VkIGJ5IGF1dGhvcml6ZWQgY2xpZW50cyAoY2YuIE9TQ0FSLA0K Pj4gaHR0cDovL2FyeGl2Lm9yZy9hYnMvMTQwNC43Nzk5KS4NCj4NCj5UaGlzIGlzIGFuIGV4YW1w bGUgZm9yIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIHdvcmtpbmcgY2xvc2VseQ0K PnRvZ2V0aGVyLiBZb3UgY2FuIGRvIGF1dGhvcml6YXRpb24gYW5kIGF1dGhlbnRpY2F0aW9uIHRv Z2V0aGVyIGlmIHlvdQ0KPmJpbmQgYXV0aG9yaXphdGlvbiBpbmZvcm1hdGlvbiB0byBhIGtleS4g QnV0IHlvdSB3aWxsIHN0aWxsIG5lZWQgdG8gbWFrZQ0KPnN1cmUgdGhhdCB0aGUga2V5IGlzIGdp dmVuIHRvIHRoZSByaWdodCBlbnRpdHkuIFlvdSBjYW4ndCBkbw0KPmF1dGhvcml6YXRpb24gaWYg eW91IGFyZSBub3Qgc3VyZSB3aG8geW91IGFyZSBhdXRob3JpemluZyBhbmQgaWYgeW91DQo+Y2Fu bm90IGRlY2lkZSBpZiB0aGUgb25lIHlvdSBhcmUgdGFsa2luZyB0byByZWFsbHkgaXMgdGhlIG9u ZSB3aG8gaXMNCj5hdXRob3JpemVkLg0KPg0KPj4NCj4+DQo+PiDigKIgIldlIHVzZSB0aGUgdGVy bSBhdXRoZW50aWNhdGVkIGF1dGhvcml6YXRpb24gdG8gcmVmZXIgdG8gYSBzeW50aGVzaXMNCj4+ b2YNCj4+IG1lY2hhbmlzbSBmb3IgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24uICIN Cj4+DQo+PiBUaGUgdGVybSAiQXV0aGVudGljYXRlZCBhdXRob3JpemF0aW9uIiBpcyBxdWl0ZSB2 YWd1ZS4NCj4NCj5DYW4geW91IGVsYWJvcmF0ZSB0aGF0PyBJIHRoaW5rIHRoZSBwYXJhZ3JhcGgg c2hvd3Mgd2h5IGF1dGhlbnRpY2F0aW9uDQo+YW5kIGF1dGhvcml6YXRpb24gbWVjaGFuaXNtIG5l ZWQgdG8gd29yayB0b2dldGhlci4NCj4NCj4+DQo+Pg0KPj4g4oCiICJ1bnJlc3RyaWN0ZWQgYXV0 aG9yaXphdGlvbiINCj4+DQo+PiBUaGlzIGlzIGRlZmluZWQgYXMgIm5vIGF1dGhvcml6YXRpb24i LiBXaHkgbm90IGp1c3Qgc2F5IHNvPw0KPg0KPklmIHVucmVzdHJpY3RlZCBhdXRob3JpemF0aW9u IGlzIHVzZWQsIG5vIGF1dGhvcml6YXRpb24gbWVjaGFuaXNtIGlzDQo+dXNlZC4gVGhlcmVmb3Jl IGV2ZXJ5b25lIGlzIGF1dGhvcml6ZWQuICJubyBhdXRob3JpemF0aW9uIiBtaWdodCBiZQ0KPm1p c2ludGVycHJldGVkLg0KPg0KPj4NCj4+IOKAoiAiRm9yIGFsbCBjYXNlcyB3aGVyZSBhbiBhdXRo b3JpemF0aW9uIHNvbHV0aW9uIGlzIG5lZWRlZCAoYWxsIGJ1dA0KPj4gVW5yZXN0cmljdGVkIEF1 dGhvcml6YXRpb24pLCB0aGUgYXV0aG9yaXppbmcgcGFydHkgbmVlZHMgdG8gYmUgYWJsZSB0bw0K Pj4gYXV0aGVudGljYXRlIHRoZSBwYXJ0eSB0aGF0IGlzIHRvIGJlIGF1dGhvcml6ZWQuIEF1dGhl bnRpY2F0aW9uIGlzDQo+PiB0aGVyZWZvcmUgcmVxdWlyZWQgZm9yIG1lc3NhZ2VzIHRoYXQgY29u dGFpbiByZXByZXNlbnRhdGlvbnMgb2YgYW4NCj4+IGFjY2Vzc2VkIGl0ZW0uIE1vcmUgcHJlY2lz ZWx5LCB0aGUgYXV0aG9yaXppbmcgcGFydHkgbmVlZHMgdG8gbWFrZSBzdXJlDQo+PiB0aGF0IHRo ZSByZWNlaXZlciBvZiBhIG1lc3NhZ2UgY29udGFpbmluZyBhIHJlcHJlc2VudGF0aW9uLCBhbmQg dGhlDQo+PnNlbmRlcg0KPj4gb2YgYSBtZXNzYWdlIGNvbnRhaW5pbmcgYSByZXByZXNlbnRhdGlv biBhcmUgYXV0aG9yaXplZCB0byByZWNlaXZlIGFuZA0KPj4gc2VuZCB0aGlzIG1lc3NhZ2UsIHJl c3BlY3RpdmVseS4gVG8gYWNoaWV2ZSB0aGlzLCB0aGUgaW50ZWdyaXR5IG9mIHRoZXNlDQo+PiBt ZXNzYWdlcyBpcyByZXF1aXJlZDogQXV0aGVudGljaXR5IGNhbm5vdCBiZSBhc3N1cmVkIGlmIGl0 IGlzIHBvc3NpYmxlDQo+PmZvcg0KPj4gYW4gYXR0YWNrZXIgdG8gbW9kaWZ5IHRoZSBtZXNzYWdl IGR1cmluZyB0cmFuc21pc3Npb24uIg0KPj4NCj4+IEkgZmluZCBhIHNldmVyYWwgdGhpbmdzIGNv bmZ1c2luZyBoZXJlOg0KPj4gCS0gV2hhdCBwYXJ0eSBpcyB0aGUgYXV0aG9yaXppbmcgcGFydHk/ IEEgc2VydmVyIG9yIGEgU0FNIC8NCj4+QXV0aG9yaXphdGlvbg0KPj4gU2VydmVyPw0KPg0KPlRo ZSBjbGllbnQgb3IgdGhlIHNlcnZlci4gSWYgdGhlIHRlcm0gImF1dGhvcml6aW5nIHBhcnR5IiBp cyBjb25mdXNpbmcgSQ0KPmNhbiB0cnkgdG8gcmVwaHJhc2UgdGhlIHNlY3Rpb24gd2l0aG91dCB1 c2luZyBpdC4NCj4NCj5TdW1tYXJpemluZywgdGhlIHNlY3Rpb24gc3RhdGVzIHRoYXQgdGhlIHJl Y2VpdmVyIG9mIGEgcmVzb3VyY2UNCj5yZXByZXNlbnRhdGlvbiBuZWVkcyB0byBtYWtlIHN1cmUg dGhhdCB0aGUgc2VuZGVyIG9mIHRoZSByZXNvdXJjZQ0KPnJlcHJlc2VudGF0aW9uIGlzIGFsbG93 ZWQgdG8gc2VuZCBpdCBhbmQgdGhhdCB0aGUgc2VuZGVyIG9mIGEgcmVzb3VyY2UNCj5yZXByZXNl bnRhdGlvbiBtdXN0IG1ha2Ugc3VyZSB0aGF0IHRoZSByZWNlaXZlciBvZiBhIHJlc291cmNlDQo+ cmVwcmVzZW50YXRpb24gaXMgYWxsb3dlZCB0byByZWNlaXZlIGl0Lg0KPg0KPj4NCj4+IAktICJB dXRoZW50aWNhdGlvbiBpcyB0aGVyZWZvcmUgcmVxdWlyZWQgZm9yIG1lc3NhZ2VzIHRoYXQgY29u dGFpbg0KPj4gcmVwcmVzZW50YXRpb25zIG9mIGFuIGFjY2Vzc2VkIGl0ZW0uICIgVGhlIG5leHQg c2VudGVuY2UgY2xhaW1zIHRvIG1ha2UNCj4+IHByZWNpc2UsIGJ1dCBkb2VzIHNvIGluIHRlcm1z IG9mIGF1dGhvcml6YXRpb24uDQo+DQo+SSBkb24ndCB1bmRlcnN0YW5kIHRoaXMgY29tbWVudC4N Cj4NCj4+DQo+PiAJLSAidGhlIGF1dGhvcml6aW5nIHBhcnR5IG5lZWRzIHRvIG1ha2Ugc3VyZSB0 aGF0ICgtIC0gLSl0aGUgc2VuZGVyIG9mIGENCj4+IG1lc3NhZ2UgY29udGFpbmluZyBhIHJlcHJl c2VudGF0aW9uIGFyZSBhdXRob3JpemVkIHRvICgtIC0gLSkgc2VuZCB0aGlzDQo+PiBtZXNzYWdl Ii4gSSB0aGluayB0aGlzIGhhZCBiZXR0ZXIgYmUgcmVwaHJhc2VkIGFzIHRoZSBDQU0gZW5hYmxl cw0KPj4gY29uZmlndXJhdGlvbiBvZiB0aGUgY2xpZW50Lg0KPg0KPkkgdGhpbmsgY29uZmlndXJh dGlvbiBpcyBhIHZlcnkgdmFndWUgdGVybSBhbmQgY2FuIG1lYW4gZXZlcnl0aGluZyBpbg0KPnRo aXMgY29udGV4dC4gVGhlIHByb2JsZW0gdGhhdCB3ZSBuZWVkIHRvIHNvbHZlIGhlcmUgaXMgYW4g YXV0aG9yaXphdGlvbg0KPnByb2JsZW0uDQo+DQo+Pg0KPj4NCj4+IOKAoiAiVGhlIHNlY3VyaXR5 IG9iamVjdGl2ZXMgb2Ygb25lIHNpZGUgY2FuIG9mdGVuIG9ubHkgYmUgYWNoaWV2ZWQgd2l0aA0K Pj50aGUNCj4+IGhlbHAgb2YgdGhlIG90aGVyIHNpZGUuIEUuZy4sIGlmIHRoZSBzZXJ2ZXIgcmVx dWlyZXMgdGhlIGNvbmZpZGVudGlhbGl0eQ0KPj4gb2YgYSByZXNvdXJjZSByZXByZXNlbnRhdGlv biwgdGhlIGNsaWVudCBtdXN0IG1ha2Ugc3VyZSB0aGF0IGl0IGRvZXMgbm90DQo+PiBzZW5kIHJl c291cmNlIHVwZGF0ZXMgdG8gcGFydGllcyBvdGhlciB0aGFuIHRoZSBzZXJ2ZXIuIFRoZXJlZm9y ZSwgdGhlDQo+PiBjbGllbnQgbXVzdCBhdCBsZWFzdCB1c2UgYmluYXJ5IGF1dGhvcml6YXRpb24u Ig0KPj4NCj4+IFRoZSBmb3JtdWxhdGlvbiBpbmRpY2F0ZXMgdGhhdCB0aGUgZGVjaXNpb24gd2hl dGhlciBhIGNsaWVudCB0aGF0IG1ha2VzDQo+PmENCj4+IHJlcXVlc3QgaXMgbmVlZHMgdG8gdGFr ZSBpbnRvIGFjY291bnQgc2VydmVyIHBvbGljaWVzIGJlZm9yZSBlbmNyeXB0aW5nDQo+PiB0aGUg cmVxdWVzdC4gSSB0aGluayB0aGlzIHNob3VsZCBiZSBjb25maWd1cmVkIGluIHRoZSBjbGllbnQu DQo+DQo+SSB0aGluayBpdCB3aWxsIGJlIGRpZmZpY3VsdCB0byBjb25maWd1cmUgaW4gdGhlIGNs aWVudCB3aGF0IGEgc2VydmVyDQo+dGhhdCBiZWxvbmdzIHRvIHNvbWVvbmUgZWxzZSB3YW50cy4g SSB0aGluayBpdCB3aWxsIGJlIHVzZWZ1bCB0byBhc3N1bWUNCj50aGF0IGluIHNvbWUgc2NlbmFy aW9zIHlvdSB3aWxsIGFsd2F5cyBuZWVkIGF0IGxlYXN0IGJpbmFyeQ0KPmF1dGhvcml6YXRpb24g b24gdGhlIGNsaWVudCBzaWRlLg0KPg0KPj4NCj4+IFNlY3Rpb24gNg0KPj4g4oCUDQo+Pg0KPj4g Ni4xDQo+Pg0KPj4g4oCiICJUaGlzIGRvY3VtZW50IGRvZXMgbm90IGFzc3VtZSBhIHNwZWNpZmlj IHNvbHV0aW9uLiINCj4+DQo+PiBUaGlzIGlzIHR3by1lZGdlZCBzd29yZC4gSWYgeW91IGNsYWlt IHRoYXQgd2UgY2FuJ3QgdXNlIE9BdXRoL1VNQQ0KPj4gYXJjaGl0ZWN0dXJlIGJlY2F1c2UgaXQg YXNzdW1lcyBhIHNwZWNpZmljIHNvbHV0aW9uLCB0aGVuIHNvIGRvZXMgdGhpcw0KPj4gZG9jdW1l bnQuDQo+DQo+SXQgbWlnaHQgYmUgaGVscGZ1bCBpZiB5b3UgYWxzbyBzdGF0ZSB0aGUgY29udGV4 dCBvZiB0aGlzIHNlbnRlbmNlLiBUaGlzDQo+cmVmZXJzIHRvIHRoZSBleGNoYW5nZWQgbWVzc2Fn ZXMgYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgc2VydmVyIHdoaWNoDQo+aXMgc3RhdGVkIGlu IHRoZSBuZXh0IHNlbnRlbmNlLg0KPg0KPj4NCj4+DQo+PiA2LjINCj4+DQo+PiDigKIgIlRoZSBy ZWFzb24gZm9yIHVzaW5nIGFuIGF1dGhvcml6YXRpb24gc29sdXRpb24gaXMgdG8gdmFsaWRhdGUg dGhhdA0KPj50aGUNCj4+IGVudGl0eSB0aGF0IHNlbnQgdGhlIGluZm9ybWF0aW9uIHVzZWQgZm9y IHByb2Nlc3NpbmcgaXMgYXV0aG9yaXplZCB0bw0KPj4gcHJvdmlkZSBpdC4gVG8gdmFsaWRhdGUg aWYgYSBzZW5kZXIgaXMgYXV0aG9yaXplZCB0byBzZW5kIGEgcmVjZWl2ZWQNCj4+cGllY2UNCj4+ IG9mIGluZm9ybWF0aW9uLCB0aGUgcmVjZWl2ZXIgbXVzdCBkZXRlcm1pbmUgdGhlIHNlbmRlcuKA mXMgYXV0aG9yaXphdGlvbi4NCj4+IENvcnJlc3BvbmRpbmdseSwgdG8gdmFsaWRhdGUgaWYgYSBy ZWNlaXZlciBpcyBhbGxvd2VkIHRvIHJlY2VpdmUgYQ0KPj4gbWVzc2FnZSwgdGhlIHNlbmRlciBt dXN0IGRldGVybWluZSBpdHMgYXV0aG9yaXphdGlvbi4gVGhpcyBjYW4gb25seSBiZQ0KPj4gYWNo aWV2ZWQgd2l0aCB0aGUgaGVscCBvZiBhbiBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20uIg0KPj4N Cj4+IEkgdGhpbmsgdGhpcyBpcyBhbGwgdmVyeSBjb21wbGljYXRlZCwgYW5kIGlzIG92ZXJ1c2lu ZyB0aGUgdGVybQ0KPj4gImF1dGhvcml6YXRpb24iLiBUaGUgc2VydmVyIHNob3VsZCBkZXRlcm1p bmUgaWYgdGhlIGNsaWVudCBpcyBhdXRob3JpemVkDQo+PiB0byBhY2Nlc3MgYSByZXNvdXJjZSwg YW5kIHBlcmZvcm0gYWNjb3JkaW5nbHkuIFRoZSBjbGllbnQgc2hvdWxkIHBlcmZvcm0NCj4+IGFz IGNvbmZpZ3VyZWQgKHBvdGVudGlhbGx5IGR5bmFtaWNhbGx5IHVzaW5nIGEgQ0FNLXR5cGUgbm9k ZSkuIFRoYXQncw0KPj5pdC4NCj4NCj5XaXRoICJjb25maWd1cmUiIHlvdSBtZWFuIHRoZSBjb25m aWd1cmF0aW9uIG9mIGF1dGhvcml6YXRpb24gb24gdGhlDQo+Y2xpZW50IHNpZGUsIEkgZ3Vlc3Mu DQo+DQo+Pg0KPj4NCj4+IDYuNA0KPj4NCj4+IGl0ZW0gMTogSSB0aGluayB0aGlzIGlzIG91dCBv ZiBzY29wZSBmb3IgQUNFDQo+DQo+VGhlIHByb2Nlc3Mgb2YgY29uZmlndXJhdGlvbiBtaWdodCBi ZSBvdXQgb2Ygc2NvcGUgYnV0IGl0IGlzIHN0aWxsIGENCj5uZWNlc3NhcnkgcHJvY2Vzcy4gSW4g Y29uc3RyYWluZWQgZW52aXJvbm1lbnRzIGl0IGlzIG5lY2Vzc2FyeSB0bw0KPmNvbnNpZGVyIGhv dyB0aGlzIGNvbmZpZ3VyYXRpb24gY2FuIG9jY3VyIHNpbmNlIGNvbnN0cmFpbmVkIGRldmljZXMN Cj5vZnRlbiBkb24ndCBoYXZlIHVzZXIgaW50ZXJmYWNlcyBvciBkaXNwbGF5cy4NCj4NCj4+IGl0 ZW0gMjogYWdyZWUuIEkgdGhpbmsgd2Ugc2hvdWxkIGFkZCBzb21ldGhpbmcgYW5hbG9nb3VzIGFi b3V0DQo+PiBjb25maWd1cmF0aW9uIG9mIGNsaWVudA0KPg0KPk5vIG5lZWQgZm9yIHRoYXQuIFRo aXMgYWxyZWFkeSBhcHBsaWVzIHRvIGJvdGggdGhlIGNsaWVudCBhbmQgdGhlIHNlcnZlci4NCj4N Cj4+IGl0ZW0gMy00OiB0aGlzIGlzIGFzc3VtaW5nIGEgcGFydGljdWxhciBzb2x1dGlvbi4gV2Ug Y2FuIG9idGFpbg0KPj4gZ3JhbnVsYXJpdHkgd2l0aG91dCB0aGUgYXR0cmlidXRlIGV4ZXJjaXNl IGJ5IGFzc29jaWF0aW5nIGNlcnRhaW4ga2V5cw0KPj50bw0KPj4gY2VydGFpbiBwZXJtaXNzaW9u cywgYXMgbWVudGlvbmVkIGFib3ZlLg0KPg0KPkkgZ3Vlc3MgeW91IGFyZSByZWZlcnJpbmcgdG8g aXRlbSAzLiBJIHdpbGwgdHJ5IHRvIHJlcGhyYXNlIGl0IHRvIGJldHRlcg0KPmluY2x1ZGUgdGhv c2Ugc29sdXRpb25zLg0KPg0KPlRoZSBhdXRob3JpemF0aW9uIHdpbGwgc3RpbGwgbmVlZCB0byBi ZSBlbmZvcmNlZCBhcyBkZWZpbmVkIGluIGl0ZW0gNC4NCj4NCj4+DQo+Pg0KPj4gNy4xDQo+Pg0K Pj4gIkMgcGVyZm9ybXMgdGhlIGZvbGxvd2luZyB0YXNrczoNCj4+IOKAoiBOZWdvdGlhdGUgbWVh bnMgZm9yIHNlY3VyZSBjb21tdW5pY2F0aW9uIChUYXNrIFRTZWN1cmVDb21tLCBzZWUNCj4+QXBw ZW5kaXgNCj4+IEEuMi4zKS4iDQo+Pg0KPj4gTm90IG5lY2Vzc2FyeSBpZiB0aGVyZSBpcyBhIFRU UCwgc3VjaCBhcyBhbiBBdXRob3JpemF0aW9uIFNlcnZlciwNCj4+IHByb3ZpZGluZyBzZWN1cml0 eSBjb250ZXh0DQo+DQo+SWYgYSBkZXZpY2Ugd2FudHMgdG8gY29tbXVuaWNhdGUgc2VjdXJlbHks IGl0IHNvbWVob3cgaGFzdCB0byBvYnRhaW4gdGhlDQo+bWVhbnMgKGUuZy4ga2V5aW5nIG1hdGVy aWFsKSBmb3IgdGhhdC4gSWYgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyDQo+cHJvdmlkZXMgdGhp cyB0byB0aGUgZGV2aWNlIHRoaXMgZnVsZmlsbHMgVFNlY3VyZUNvbW0uDQo+DQo+Pg0KPj4g4oCi ICJWYWxpZGF0ZSB0aGF0IGFuIGVudGl0eSBpcyBhbiBhdXRob3JpemVkIHNvdXJjZSBmb3IgUiAo VGFzaw0KPj4gVFZhbFNvdXJjZUF1dGh6LCBzZWUgQXBwZW5kaXggQS4yLjIpLiINCj4+DQo+PiBJ IHdvdWxkIHBocmFzZSB0aGlzIHRoYXQgQyBpcyBjb25maWd1cmVkIHRvIHJlcXVlc3QgUi4NCj4N Cj5Zb3UgbWVhbiB0aGF0IHlvdSBjYW4gbWFrZSBzdXJlIHRoYXQgYW4gUyBpcyBhbiBhdXRob3Jp emVkIHNvdXJjZSBmb3IgUg0KPmJ5IGNvbmZpZ3VyaW5nIEMgdG8gYWNjZXNzIFIgb24gUz8gVGhh dCB3b3VsZCBiZSBvbmUgc29sdXRpb24uDQo+DQo+Pg0KPj4gIlMgcGVyZm9ybXMgdGhlIGZvbGxv d2luZyB0YXNrczoNCj4+IOKAoiBOZWdvdGlhdGUgbWVhbnMgZm9yIHNlY3VyZSBjb21tdW5pY2F0 aW9uIChUYXNrIFRTZWN1cmVDb21tLCBzZWUNCj4+QXBwZW5kaXgNCj4+IEEuMi4zKS4iDQo+Pg0K Pj4gTm90IG5lY2Vzc2FyeSBpZiB0aGVyZSBpcyBhIFRUUCwgc3VjaCBhcyBhbiBBdXRob3JpemF0 aW9uIFNlcnZlciwNCj4+IHByb3ZpZGluZyBzZWN1cml0eSBjb250ZXh0DQo+DQo+SWYgdGhlIGF1 dGhvcml6YXRpb24gcHJvdmlkZXMgdGhpcyB0byB0aGUgZGV2aWNlLCB0aGlzIGlzIFRTZWN1cmVD b21tLg0KPg0KPj4NCj4+DQo+Pg0KPj4gNy4yDQo+Pg0KPj4gIkNPUCBtdXN0IGZ1bGZpbGwgdGhl IGZvbGxvd2luZyB0YXNrOg0KPj4g4oCiIENvbmZpZ3VyZSBmb3IgQyBhdXRob3JpemF0aW9uIGlu Zm9ybWF0aW9uIGZvciBzb3VyY2VzIGZvciBSICINCj4+DQo+PiBJIHdvdWxkIHJlcGhyYXNlIHRo aXMgYnVsbGV0IGFzICLigKIgQ29uZmlndXJlIGZvciBDIHJlc291cmNlcyBSIHRvIGJlDQo+PiBh Y2Nlc3NlZCINCj4+DQo+Pg0KPj4gNy4zDQo+Pg0KPj4g4oCiICBXaHkgZG9lcyB0aGUgQ0FNIGhh dmUgdG8gYmUgaW4gdGhlIHNhbWUgc2VjdXJpdHkgZG9tYWluIGFzIEMgYW5kIENPUC4NCj4+IENv dWxkIGl0IG5vdCBiZSBvdXRzb3VyY2VkPyAoU2VlIGUuZy4gSGVhbHRoY2FyZSBzY2VuYXJpbw0K Pj4gDQo+Pmh0dHA6Ly9rYW50YXJhaW5pdGlhdGl2ZS5vcmcvY29uZmx1ZW5jZS9kaXNwbGF5L3Vt YS9VTUErVHJ1c3QrTW9kZWwrVXNlcisNCj4+Z3UNCj4+IGlkZSkNCj4NCj5XaGF0IGRvIHlvdSBt ZWFuIHdpdGggb3V0c291cmNlZD8gVGhhdCB0aGUgcHJpbmNpcGFsIGNvbnRyb2xsaW5nIEMgaXMN Cj5kaWZmZXJlbnQgZnJvbSB0aGUgcHJpbmNpcGFsIHRoYXQgY29udHJvbHMgQ0FNPw0KPg0KPj4N Cj4+DQo+Pg0KPj4g4oCiIFRoZSBzZXR0aW5nIHdpdGggQ0FNIGFsd2F5cyBiZWluZyBpbnRlcm1l ZGlhcnkgYmV0d2VlbiBDIGFuZCBTQU0NCj4+ICg9QXV0aG9yaXphdGlvbiBTZXJ2ZXIpIGlzIHBy b2JsZW1hdGljLiBDIG5lZWRzIHRvIGJlIGF1dGhvcml6ZWQgKGFuZC9vcg0KPj4gcHJvdmUgdGhh dCBpdCBpcykgdG8gYWNjZXNzIFMuIEluIGEgZmVkZXJhdGVkIHNldHRpbmcgaXQgY291bGQgd29y aw0KPj50aGF0LA0KPj4gYXMgQ0FNIGJlY29tZXMgYXV0aG9yaXplZCBzbyBkb2VzIGFsbCBpdHMg YXNzaWduZWQgQ3MuIEJ1dCBpbiB0aGUNCj4+Z2VuZXJhbA0KPj4gY2FzZSwgU0FNIG5lZWRzIHRv IGNvbW11bmljYXRlIHNlY3VyZWx5IHdpdGggQyBhbmQgcHJvdmlkZSB0aGUgbmVjZXNzYXJ5DQo+ PiBrZXlzIG9yIGNyZWRlbnRpYWxzLiBJbiB0aGlzIGNhc2UgQ0FNIGhhcyBubyBzZWN1cml0eSBm dW5jdGlvbi4gQnV0IHRoZQ0KPj4gYXJjaGl0ZWN0dXJlIHByZXNjcmliZXMgdGhhdCBpbnRlcmFj dGlvbiBiZXR3ZWVuIEMgYW5kIFNBTSBpcyBuZXZlciBkb25lDQo+PiBkaXJlY3RseSwgYnV0IHZp YSBDQU0uIEluIHRoaXMgY2FzZSBDQU0gZG9lcyBub3QgaGF2ZSBhIHJvbGUgYXQgYWxsLCBzbw0K Pj4gdGhlcmUgaXMgbm90IG9ubHkgYSBkaWZmZXJlbmNlIHdoZXJlIENBTSBpcyBob3N0ZWQsIGJ1 dCBpbiBpdHMgZnVuY3Rpb24uDQo+DQo+SSBkb24ndCBxdWl0ZSB1bmRlcnN0YW5kIHdoYXQgeW91 IGFyZSBnZXR0aW5nIGF0LiBUaGVyZSBtYXkgYmUgY2FzZXMNCj53aGVyZSB5b3UgZG9uJ3QgbmVl ZCBhIGRpc3RpbmN0IENBTS4gWW91IGNhbiBoYXZlIGEgc2luZ2xlIG1hY2hpbmUgb3IgYQ0KPnNp bmdsZSBwaWVjZSBvZiBzb2Z0d2FyZSB0aGF0IHBlcmZvcm1zIENBTSdzIGFuZCBTQU0ncyB0YXNr cy4gVGhhdCdzIHdoeQ0KPnRoZSBkcmFmdCBzdGF0ZXM6ICJUaGUgYXJjaGl0ZWN0dXJlIG9mIGFu IGFjdHVhbCBzb2x1dGlvbiBtaWdodCBkaWZmZXINCj5hcyBsb25nIGFzIHRoZSBzZWN1cml0eSBy ZXF1aXJlbWVudHMgdGhhdCBkZXJpdmUgZnJvbSB0aGUgcmVsYXRpb25zaGlwDQo+YmV0d2VlbiB0 aGUgaWRlbnRpZmllZCBhY3RvcnMgYXJlIGNvbnNpZGVyZWQuIFNldmVyYWwgYWN0b3JzIG1pZ2h0 IHNoYXJlDQo+YSBzaW5nbGUgZGV2aWNlIG9yIGV2ZW4gYmUgY29tYmluZWQgaW4gYSBzaW5nbGUN Cj5waWVjZSBvZiBzb2Z0d2FyZS4gSW50ZXJmYWNlcyBiZXR3ZWVuIGFjdG9ycyBtYXkgYmUgcmVh bGl6ZWQgYXMNCj5wcm90b2NvbHMgb3IgYmUgaW50ZXJuYWwgdG8gc3VjaCBhIHBpZWNlIG9mIHNv ZnR3YXJlLiINCj4NCj4+DQo+Pg0KPj4NCj4+IDguMQ0KPj4NCj4+IOKAoiBOZXh0IHRvIGxhc3Qg cGFyYWdyYXBoOiBBbHRob3VnaCBjb25maWRlbnRpYWxpdHkgYW5kIGludGVncml0eQ0KPj4gcHJv dGVjdGlvbiBhcmUgdGhlIHNlY3VyaXR5IG9iamVjdGl2ZXMgY29uc2lkZXJlZCBpbiB0aGlzIGRv Y3VtZW50LA0KPj50aGVyZQ0KPj4gaXMgbm8gY29uc2lkZXJhdGlvbiBvZiBlbmQtdG8tZW5kIHNl Y3VyaXR5IGluIHRoZSBwcmVzZW5jZSBvZg0KPj5pbnRlcm1lZGlhcnkNCj4+IG5vZGVzICh3aGlj aCB3b3VsZCBpbmR1Y2UgRFRMUyBob3AgYnkgaG9wKQ0KPg0KPldoYXQgZG8geW91IHRoaW5rIGlz IG1pc3NpbmcgaGVyZT8NCj4NCj4+DQo+PiA4LjINCj4+DQo+PiDigKIgSW4gY2FzZSBPQXV0aCBp cyBhcHBsaWVkIHRvIHRoZSAibGVzcyBjb25zdHJhaW5lZCBsZXZlbCIsIHdoYXQgYXJlIHRoZQ0K Pj4gcHJvdGVjdGVkIHJlc291cmNlcyBhdCBTQU0gYWNjZXNzZWQgYnkgQ0FNPyAoQWNjZXNzIHRv a2Vucz8pDQo+DQo+SSB0aGluayBmaW5kaW5nIG91dCBob3cgY29uc3RyYWluZWQgbGV2ZWwgYW5k IGxlc3MtY29uc3RyYWluZWQgbGV2ZWwNCj5wcm90b2NvbHMgY2FuIHdvcmsgdG9nZXRoZXIgaXMg b25lIG9mIHRoZSBjaGFsbGVuZ2VzIGluIEFDRS4gSSBob3BlIHdlDQo+d2lsbCBmaW5kIG91dCBo b3cgd2Ugd2lsbCBkbyB0aGlzIGV4YWN0bHkgYnV0IEkgZG9uJ3QgdGhpbmsgdGhpcyBpcyBpbg0K PnNjb3BlIGZvciB0aGUgYWN0b3IncyBkcmFmdC4gVGhlIGRyYWZ0IGp1c3Qgc3RhdGVzIHRoYXQg dGhlcmUgYXJlDQo+ZGlmZmVyZW50IHJlcXVpcmVtZW50cyBmb3IgdGhlIGRpZmZlcmVudCBsZXZl bHMuDQo+DQo+QmVzdCByZWdhcmRzLA0KPlN0ZWZmaQ0KPg0KPg0KPj4NCj4+DQo+Pg0KPj4NCj4+ IEJlc3QgcmVnYXJkcw0KPj4gR8O2cmFuDQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+IE9uIDIwMTUt MDMtMTAgMTQ6MjUsICJTdGVmYW5pZSBHZXJkZXMiIDxnZXJkZXNAdHppLmRlPiB3cm90ZToNCj4+ DQo+Pj4gSGkgYWxsLA0KPj4+DQo+Pj4gUGxlYXNlIGZpbmQgYXR0YWNoZWQgdGhlIG5ldyB2ZXJz aW9uIG5vdGlmaWNhdGlvbiBmb3IgdGhlIGFjdG9ycyBkcmFmdC4NCj4+Pg0KPj4+IFRoZSBtYWlu IGNoYW5nZXMgYXJlOg0KPj4+IC0gVG8gYWRkcmVzcyBjb21tZW50cyAoZS5nLiwgaW4gdGhlIEFD RSBzZXNzaW9uIGluIEhvbm9sdWx1KSBPQXV0aA0KPj4+IHRlcm1pbm9sb2d5IHdhcyByZW1vdmVk IHRvIGF2b2lkIG1pc3VuZGVyc3RhbmRpbmdzLg0KPj4+IC0gVGhlIHRlcm0gIm93bmVyIiB3YXMg cmVwbGFjZWQgc2luY2UgY29tbWVudHMgb24gdGhlIGxpc3QgaW5kaWNhdGVkDQo+Pj4gdGhhdCBv d25lciBtaWdodCBub3QgYmUgYSBzdWl0YWJsZSB0ZXJtLg0KPj4+IC0gQSBzZWN0aW9uIGFib3V0 IGF1dG9ub21vdXMgY29tbXVuaWNhdGlvbiB3YXMgYWRkZWQgdG8gcG9pbnQgb3V0IHRoYXQNCj4+ PiB0aGVyZSBpcyBub3QgYWx3YXlzIGFuIGFjdGl2ZSB1c2VyIGluIGNvbnN0cmFpbmVkIGVudmly b25tZW50cywgYW5kDQo+Pj4gZGV2aWNlcyBuZWVkIHRvIGJlIGFibGUgdG8gZW5mb3JjZSB0aGUg dXNlcidzIHNlY3VyaXR5IHBvbGljaWVzDQo+Pj4gYXV0b25vbW91c2x5Lg0KPj4+DQo+Pj4gQ29t bWVudHMgYXJlIHZlcnkgd2VsY29tZS4NCj4+Pg0KPj4+IFRoYW5rcywNCj4+PiBTdGVmZmkNCj4+ Pg0KPj4+DQo+Pj4gLS0tLS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2UgLS0tLS0tLS0NCj4+PiBTdWJq ZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWdlcmRlcy1hY2UtYWN0b3Jz LTAzLnR4dA0KPj4+IERhdGU6IE1vbiwgMDkgTWFyIDIwMTUgMTY6NDk6MjAgLTA3MDANCj4+PiBG cm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj4+PiBUbzogU3RlZmFuaWUgR2VyZGVzIDxn ZXJkZXNAdHppLm9yZz4sIFN0ZWZhbmllIEdlcmRlcyA8Z2VyZGVzQHR6aS5vcmc+DQo+Pj4NCj4+ Pg0KPj4+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1nZXJkZXMtYWNlLWFjdG9ycy0wMy50 eHQNCj4+PiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFN0ZWZhbmllIEdlcmRl cyBhbmQgcG9zdGVkIHRvIHRoZQ0KPj4+IElFVEYgcmVwb3NpdG9yeS4NCj4+Pg0KPj4+IE5hbWU6 CQlkcmFmdC1nZXJkZXMtYWNlLWFjdG9ycw0KPj4+IFJldmlzaW9uOgkwMw0KPj4+IFRpdGxlOgkJ QWN0b3JzIGluIHRoZSBBQ0UgQXJjaGl0ZWN0dXJlDQo+Pj4gRG9jdW1lbnQgZGF0ZToJMjAxNS0w My0wOQ0KPj4+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+Pj4gUGFnZXM6CQkyNg0K Pj4+IFVSTDoNCj4+PiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1n ZXJkZXMtYWNlLWFjdG9ycy0wMy50eHQNCj4+PiBTdGF0dXM6ICAgICAgICANCj4+Pmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWdlcmRlcy1hY2UtYWN0b3JzLw0KPj4+IEh0 bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nZXJkZXMtYWNl LWFjdG9ycy0wMw0KPj4+IERpZmY6DQo+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3Vy bDI9ZHJhZnQtZ2VyZGVzLWFjZS1hY3RvcnMtMDMNCj4+Pg0KPj4+IEFic3RyYWN0Og0KPj4+ICAg ICBDb25zdHJhaW5lZCBub2RlcyBhcmUgc21hbGwgZGV2aWNlcyB3aGljaCBhcmUgbGltaXRlZCBp biB0ZXJtcyBvZg0KPj4+ICAgICBwcm9jZXNzaW5nIHBvd2VyLCBtZW1vcnksIG5vbi12b2xhdGls ZSBzdG9yYWdlIGFuZCB0cmFuc21pc3Npb24NCj4+PiAgICAgY2FwYWNpdHkuICBEdWUgdG8gdGhl c2UgY29uc3RyYWludHMsIGNvbW1vbmx5IHVzZWQgc2VjdXJpdHkNCj4+PnByb3RvY29scw0KPj4+ ICAgICBhcmUgbm90IGVhc2lseSBhcHBsaWNhYmxlLiAgTmV2ZXJ0aGVsZXNzLCBhbiBhdXRoZW50 aWNhdGlvbiBhbmQNCj4+PiAgICAgYXV0aG9yaXphdGlvbiBzb2x1dGlvbiBpcyBuZWVkZWQgdG8g ZW5zdXJlIHRoZSBzZWN1cml0eSBvZiB0aGVzZQ0KPj4+ICAgICBkZXZpY2VzLg0KPj4+DQo+Pj4g ICAgIER1ZSB0byB0aGUgbGltaXRhdGlvbnMgb2YgdGhlIGNvbnN0cmFpbmVkIG5vZGVzIGl0IGlz IGVzcGVjaWFsbHkNCj4+PiAgICAgaW1wb3J0YW50IHRvIGRldmVsb3AgYSBsaWdodC13ZWlnaHQg c2VjdXJpdHkgc29sdXRpb24gd2hpY2ggaXMNCj4+PiAgICAgYWRqdXN0ZWQgdG8gdGhlIHJlbGV2 YW50IHNlY3VyaXR5IG9iamVjdGl2ZXMgb2YgZWFjaCBwYXJ0aWNpcGF0aW5nDQo+Pj4gICAgIHBh cnR5IGluIHRoaXMgZW52aXJvbm1lbnQuICBOZWNlc3Nhcnkgc2VjdXJpdHkgbWVhc3VyZXMgbXVz dCBiZQ0KPj4+ICAgICBpZGVudGlmaWVkIGFuZCBhcHBsaWVkIHdoZXJlIG5lZWRlZC4NCj4+Pg0K Pj4+ICAgICBJbiB0aGlzIGRvY3VtZW50LCB0aGUgcmVxdWlyZWQgc2VjdXJpdHkgcmVsYXRlZCB0 YXNrcyBhcmUNCj4+PmlkZW50aWZpZWQNCj4+PiAgICAgYXMgZ3VpZGFuY2UgZm9yIHRoZSBkZXZl bG9wbWVudCBvZiBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbg0KPj4+ICAgICBzb2x1 dGlvbnMgZm9yIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy4gIEJhc2VkIG9uIHRoZSB0YXNrcywg YW4NCj4+PiAgICAgYXJjaGl0ZWN0dXJlIGlzIGRldmVsb3BlZCB0byByZXByZXNlbnQgdGhlIHJl bGF0aW9uc2hpcHMgYmV0d2Vlbg0KPj4+dGhlDQo+Pj4gICAgIGxvZ2ljYWwgZnVuY3Rpb25hbCBl bnRpdGllcyBpbnZvbHZlZC4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gUGxlYXNlIG5v dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YN Cj4+PiBzdWJtaXNzaW9uDQo+Pj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4+Pg0KPj4+IFRoZSBJRVRGIFNlY3Jl dGFyaWF0DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4+IEFjZSBtYWlsaW5nIGxpc3QNCj4+PiBBY2VAaWV0 Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZQ0KPj4N Cj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBB Y2UgbWFpbGluZyBsaXN0DQo+PiBBY2VAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vYWNlDQo+Pg0KPj4NCj4NCj4tLSANCj5TdGVmYW5pZSBHZXJkZXMJ CQlUZWw6ICs0OSA0MjEgMjE4IDYzOTA2DQo+VFpJIFVuaXZlcnNpdMOkdCBCcmVtZW4JCUUtTWFp bDogZ2VyZGVzQHR6aS5kZQ0KPkJpYmxpb3RoZWtzdHIuIDEsIE1aSCA1MTUwDQo+MjgzNTkgQnJl bWVuLCBHZXJtYW55DQoNCg== From nobody Tue Mar 24 14:54: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 DFEAA1A1A4A for ; Tue, 24 Mar 2015 14:54:48 -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 ISO5swOD_RT4 for ; Tue, 24 Mar 2015 14:54:47 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 602C71A8ADF for ; Tue, 24 Mar 2015 14:54:47 -0700 (PDT) X-AuditID: c1b4fb3a-f79146d0000070a3-59-5511dd25f777 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 4F.02.28835.52DD1155; Tue, 24 Mar 2015 22:54:45 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.196]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0210.002; Tue, 24 Mar 2015 22:54:45 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Carsten Bormann , Stefanie Gerdes Thread-Topic: [Ace] Fwd: New Version Notification for draft-gerdes-ace-actors-03.txt Thread-Index: AQHQYKF6eNCV1PF07k29OLhbkWWtbJ0rwDSAgAADRACAABD0gA== Date: Tue, 24 Mar 2015 21:54:44 +0000 Message-ID: References: <20150309234920.12025.44848.idtracker@ietfa.amsl.com> <54FEF0C9.30005@tzi.de> <551185DD.2030804@tzi.de> <5511889A.7040704@tzi.org> In-Reply-To: <5511889A.7040704@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: <264156210A888742B11EEB3BB50BF953@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyM+Jvja7qXcFQg5vTdS2+f+thtjgy5S6r xcaLdxkdmD2WLPnJ5LHt7Vdmj2mLMgOYo7hsUlJzMstSi/TtErgy7h55ylpwh7Wi6eRtpgbG E6xdjBwcEgImEh1zJLsYOYFMMYkL99azdTFycQgJHGGUONJxkhnCWcIo8XDFPmaQKjYBF4kH DY+YQGwRAWeJ/ysugNnMAooSu2edZQexhQVCJfbOWcsOskBEIEyicwEjRLmTxMMl81hAbBYB VYnVEy+BxXkFLCRe3O9mgti1n1Gi4dUVsCJOAXWJp9/XsILYjEDXfT+1BmqXuMStJ/OZIK4W kFiy5zwzhC0q8fLxP7B6UQE9iZXXm9gg4koSaw9vZwG5h1lAU2L9Ln2IMdYSx659ZoQ5f0r3 Q3aIewQlTs58wjKBUWIWkm2zELpnIemehaR7FpLuBYysqxhFi1OLi3PTjYz0Uosyk4uL8/P0 8lJLNjECo/Lglt9WOxgPPnc8xCjAwajEw2twWSBUiDWxrLgy9xCjNAeLkjivnfGhECGB9MSS 1OzU1ILUovii0pzU4kOMTBycUg2M4WdWfI183j2HJdx6U3K8ftTcnN3c3ub6mRPX9pm/iZKZ tvallQ9TjdrPVFV2nv0Rb65/6zv856L9RG45jYuBgbtmeW6RYi6XmdzCwj6rJUD0rZXI3/aI XX8m6bDLbptyRPJTylVhtw7WNeyfjt0QKpu5ep4Ak5zis63zDq1cseBSxiNrjlfWSizFGYmG WsxFxYkA+zZhyqsCAAA= Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Fwd: New Version Notification for draft-gerdes-ace-actors-03.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, 24 Mar 2015 21:54:49 -0000 DQpIaSBDYXJzdGVuDQoNCk9uIDIwMTUtMDMtMjQgMTA6NTQsICJDYXJzdGVuIEJvcm1hbm4iIDxj YWJvQHR6aS5vcmc+IHdyb3RlOg0KDQo+DQo+U3RlZmFuaWUgR2VyZGVzIHdyb3RlOg0KPj4gSSBk b24ndCBrbm93IHdoYXQgeW91ciBpbnRlcnByZXRpb24gb2YgYXV0aG9yaXphdGlvbiBpcy4NCj4N Cj5ZZXN0ZXJkYXkgaW4gdGhlIHNpZGUgbWVldGluZywgaXQgc2VlbWVkIEfDtnJhbiB3YW50cyB0 byB1c2UNCj5hdXRob3JpemF0aW9uIGFzIGEgc3lub255bSBmb3IgInRoaW5ncyB5b3UgY2FuIGRv IHdpdGggYW4gYWNjZXNzIGNvbnRyb2wNCj5saXN0IiwgaS5lLiBhY2Nlc3MgY29udHJvbCB0byBy ZXNvdXJjZXMgb24gYSBDb0FQIHNlcnZlci4NCg0KVGhpcyBmb3JtdWxhdGlvbiBkb2VzbuKAmXQg cmluZyBhIGJlbGwuIEFuZCB3ZeKAmXZlIGhhZCB0aGUgdGVybWlub2xvZ3kNCmRpc2N1c3Npb24g Zm9yIHF1aXRlIGEgd2hpbGUgbm93LCBsZXTigJlzIG5vdCByZW9wZW4gaXQuDQoNCkJlc3QgcmVn YXJkcywNCkfDtnJhbg0KDQoNCg== From nobody Tue Mar 24 16:31: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 884D31A00E7; Tue, 24 Mar 2015 16:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 JcotKfrZKk_W; Tue, 24 Mar 2015 16:31:38 -0700 (PDT) Received: from out4133-98.mail.aliyun.com (out4133-98.mail.aliyun.com [42.120.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id A36E51A00CD; Tue, 24 Mar 2015 16:31:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1427239897; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=vkbe5g9xDElfFMUWucfQQSlkAqanckkx80DUEiRUxKY=; b=wBA9vthLoDpxLMhgUwRsgvMMIe9JJlMzRgii+QQhhcbzd0SOnxU9UEZ945o+UuxUEMeZf/4vbXmkclnQqW1nfcbWf5oMJjDc9BxungQsHXoTqykMuU95VQ/JnFXGzFu1RukPHGWjchKv3IBWaZUs3xreRkCpvkZ6lD/+OEWokEo= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R661e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41g06010; MF=kepeng.lkp@alibaba-inc.com; PH=DW; RN=3; RT=3; SR=0; Received: from WS-web (kepeng.lkp@alibaba-inc.com[31.133.161.253]) by r41g03017.xy2.aliyun.com at Wed, 25 Mar 2015 07:31:33 +0800 Date: Wed, 25 Mar 2015 07:31:33 +0800 From: "Kepeng Li" To: "saag" , "Ace" Message-ID: <7a940fc9-72a2-4503-a453-f8e2bae9cc51@alibaba-inc.com> X-Mailer: Alimail-Mailagent revision 2687495 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=ALIBOUNDARY_15072_4a2f1940_5511f3d5_2e58" Archived-At: Cc: Hannes Tschofenig Subject: [Ace] =?utf-8?q?ACE_Report?= X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Kepeng Li List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 23:31:39 -0000 ------=ALIBOUNDARY_15072_4a2f1940_5511f3d5_2e58 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ACE WG Meeting=0AIETF 92 - Dallas=0ATuesday 24 March 2015, 13:00 - 15:00 CDT=0A= Chairs: Kepeng Li, Hannes Tschofenig=0A=0A* Use Cases (Sandeep S. Kumar)=0A - = No open issues. Next step is to initiate WGLC. Five people volunteered to revi= ew the draft.=0A=0A* Problem Description (Goeran Selander)- The term "Configur= ation Server" needs to be checked.=C2=A0=0A- There was consensus to use proble= m description and terminology as a starting point to work on.=0A=0A* Actors (C= arsten Bormann, 20 mins)=0A - There was preference to reuse OAuth terminologie= s (e.g. Resource Server, Authorization Server).- Action: Design team is reques= ted to merge Problem Description draft and Actors draft, and provide a combine= d draft.=0A=0A* Delegated CoAP Authentication and Authorization Framework (Car= sten Bormann)=0A - No time for the detailed discussion.=C2=A0It is recommended= to provide feedback in the mailing list.=0A=0A* Object Security (Goeran Selan= der)=0A - There was comment that part of the work should be done in CORE.- The= re was comment that it depends on COSE work.- No consensus to adopt it this ti= me. More time is needed.=0A* Use Oauth and UMA (Hannes Tschofenig)=0A - No tim= e for the detailed discussion. It is recommended to provide feedback in the ma= iling list.=0A=0A* Wrap-up- Chairs will request 2.5 hours for the next F2F mee= ting.Thanks,Kind RegardsKepeng ------=ALIBOUNDARY_15072_4a2f1940_5511f3d5_2e58 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
ACE WG Meeting
IETF 92 - Da= llas
Tuesday 24 March 2015, 13:00 - 15:00 CDT
Chairs: Kepeng Li, Hannes = Tschofenig

* Use Cases (Sandeep S. Kumar)
- No open issues. Next st= ep is to initiate WGLC. Five people volunteered to review the draft.

* = Problem Description (Goeran Selander)
- The term "Configuration Se= rver" needs to be checked. 
- There was consensus to use problem descr= iption and terminology as a starting point to work on.

* Actors (Carste= n 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.

* Delegated CoAP Authentication and Authorization Fra= mework (Carsten Bormann)
- No time for the detailed discussion. It is= recommended to provide feedback in the mailing list.

* Object Security= (Goeran Selander)
- There was comment that part of the work should be don= e in CORE.
- There was comment that it depends on COSE work.
=
- No consensus to adopt it this time. More time is needed.
=
* Use Oauth and UMA (Hannes Tschofenig)
- No time for the detailed dis= cussion. It is recommended to provide feedback in the mailing list.
<= div class=3D"__aliyun_signature_wrap">
* Wrap-up
- Chairs will r= equest 2.5 hours for the next F2F meeting.

Thanks,

=
Kind Regards
Kepeng
------=ALIBOUNDARY_15072_4a2f1940_5511f3d5_2e58-- From nobody Tue Mar 24 17: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 2755E1A1BBC for ; Tue, 24 Mar 2015 17:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJimEeExoMHm for ; Tue, 24 Mar 2015 17: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 6D3581A1DBC for ; Tue, 24 Mar 2015 17:19: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 [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t2P0JOAo026597 for ; Wed, 25 Mar 2015 01:19:24 +0100 (CET) Received: from aung.tzi.org (p57A63B56.dip0.t-ipconnect.de [87.166.59.86]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3lBVSD4b4tz2nn2 for ; Wed, 25 Mar 2015 01:19:24 +0100 (CET) From: Olaf Bergmann To: "Ace" References: <7a940fc9-72a2-4503-a453-f8e2bae9cc51@alibaba-inc.com> Date: Wed, 25 Mar 2015 01:19:23 +0100 In-Reply-To: <7a940fc9-72a2-4503-a453-f8e2bae9cc51@alibaba-inc.com> (Kepeng Li's message of "Wed, 25 Mar 2015 07:31:33 +0800") Message-ID: <87fv8uvshg.fsf@tzi.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ace] ACE Report 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, 25 Mar 2015 00:19:32 -0000 "Kepeng Li" writes: > ACE WG Meeting > IETF 92 - Dallas > Tuesday 24 March 2015, 13:00 - 15:00 CDT > Chairs: Kepeng Li, Hannes Tschofenig [...] > - Action: Design team is requested to merge Problem Description draft > and Actors draft, and provide a combined draft. After thinking a while about this I doubt that this is a good idea. Both documents have a completely different focus: draft-seitz-ace-problem-description lists a few design considerations and makes assumptions to lay the ground for a preferred solution, while draft-gerdes-ace-actors analyzes the entire problem space on a theoretical level and derives a reference model that takes *all* aspects of authorization into account. I recommend aligning the documents with respect to their terminology and otherwise let them stay separate. I would love to see progress on the solution side soon instead of more exhausting discussions whether or not the existence of real world problems shall be denied by the ACE WG. Gr=C3=BC=C3=9Fe Olaf From nobody Tue Mar 24 22:51: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 51E201ACDC3 for ; Tue, 24 Mar 2015 22:51:43 -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 HDeqIk7XN58o for ; Tue, 24 Mar 2015 22:51:38 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 671F01ACDC2 for ; Tue, 24 Mar 2015 22:51:38 -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 t2P5pVmH017441; Wed, 25 Mar 2015 06:51:32 +0100 (CET) Received: from [192.168.1.109] (p57A63D77.dip0.t-ipconnect.de [87.166.61.119]) (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 3lBdqR4gD8z2pRb; Wed, 25 Mar 2015 06:51:31 +0100 (CET) Message-ID: <55124CE3.6030509@tzi.de> Date: Wed, 25 Mar 2015 06:51:31 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= , "Ace@ietf.org" References: <20150309234920.12025.44848.idtracker@ietfa.amsl.com> <54FEF0C9.30005@tzi.de> <551185DD.2030804@tzi.de> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] Fwd: New Version Notification for draft-gerdes-ace-actors-03.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, 25 Mar 2015 05:51:43 -0000 Hi Göran, I would still like to know your answers to the questions that are not about C, RS, Authorization Managers and Owner Terminology. Best regards, Steffi On 03/24/2015 10:49 PM, Göran Selander wrote: > Hi Steffi, > > I interpret the outcome of the meeting that Ludwig, you and I should > collaborate on drafting a document containing the architecture, terms and > problem statement according to the side meeting results from yesterday and > document that together with parts of the actors draft and the problem > description draft. > > I propose we take the continued discussion offline to save the poor ears > of the ACE members. > > Best regards, > Göran > > > On 2015-03-24 10:42, "Stefanie Gerdes" wrote: > >> Hi Göran, >> >> Thank you for your comments. >> >> On 03/17/2015 11:59 AM, Göran Selander wrote: >>> >>> Hi Steffi, >>> >>> I've finally got around to read the "actors" draft as a whole. I've >>> listed >>> some comments below. >>> >>> >>> General: >>> >>> • The draft introduces one new node in the architecture (compared to >>> e.g. >>> UMA) called COP, supporting a constrained client. I think this kind of >>> "support node" is useful, but its functionality needs to be further >>> elaborated (see detailed comments). >> >> In fact there are two supporting nodes called CAM and SAM. They both >> help their respective constrained device with authentication and >> authorization since the constrained devices might be too constrained to >> perform complex security tasks on their own, e.g. storing a large number >> of keys or interpreting complex authorization policies. Moreover, CAM >> and SAM provide user interfaces which the constrained devices might not >> have. >> >>> >>> • There is lots of innovation of terminology; both new terms >>> (authenticated authorization, binary authorization, unrestricted >>> authorization, authorized representation, authorized resource, >>> endorsement >>> information, complexity levels, etc.); new names for roles in the >>> authorization architecture (Client Overseesing Principal, Server >>> Overseeing Principal, Client Authorization Manager, Server Authorization >>> Manager, Attribute Binding Authority); and also the meaning of existing >>> terms (e.g. authorization) is being changed. I disagree with how some >>> terms are used and moreover I think it would be much better to use less >>> terminology and try to reuse existing terminology. Here are a few >>> reasons: >> >> I find it surprising that you seem to think that the actors draft >> redefines authorization. The common understanding is that authorization >> is about allowing entities to do or be something. Do you question that? >> >> I agree that we should use exisiting terminology where applicable. I am >> not aware that there are definitions for the levels of granularity for >> the authorization such as "binary authorization", "device authorization" >> etc. elsewhere. If there is, please point it out to me. >> >>> >>> - Access control is not a new problem. Although the constrained >>> environment motivates some new functionality, that does not warrant a >>> completly new terminology. >> >> People found the OAuth terminology in the draft confusing which is why >> it was removed. I think it will be more damaging to use a terminology >> that doesn't really fit. >> >>> >>> - At the end of the day we want people approaching this work to be able >>> to reuse gained knowledge from other contexts to quickly understand what >>> this work is good for. The sheer amount of new terms is discouraging. >> >> Not being able to understand the underlying problems because the >> terminology indicates a different solution will only make things worse. >> >>> >>> - Taking existing terminology as a basis doesn't necessarily imply >>> restricting the solution (as has been iterated many times on this list, >>> see also detailed comment below). Besides, in our case it is mainly a >>> question of *adding* a few terms such as describing the functionality of >>> the above mentioned support node. (Of course, for that purpose, one new >>> term will be needed.) >> >> True, existing terminology not necessarily implies restricting the >> solution and I am a fan of reusing terminology where it fits. I didn't >> get the impression that the existing terminology fits so well with the >> architecture proposed in the actor's draft and from earlier comments I >> got the impression that other people share this impression. >> >>> >>> • There is an ambition to symmetrize the problem statement and remove >>> the >>> intrinsic assymmetry of the access control problem. However aesthetic >>> this >>> architecture looks in all its symmetry and matching terminology, this >>> ambition is misguided and hides part of the problem. I suspect it is >>> this >>> ambition which is behind the re-interpretations of existing terms, such >>> as >>> "authorization". For example only confidentiality and integrity aspects >>> of >>> authorization are considered ("The security objectives that can be >>> addressed by an authorization solution are confidentiality and >>> integrity") >>> since those can be handled more symmetrically than other aspects of >>> authorization. More below. >> >> I don't understand what you refer to with "symmetrize". I agree that >> there are different security objectives on the both sides (client side >> and server side). That's why we need to modelize them. Only then will we >> be able to see all the problems. If we only model the server side, >> client side problems will be difficult to see. >> >> It would be really nice if you could state which kind of problems are >> hidden in the actor's draft. I was already asking you to point them out >> to me for the use cases document. But unfortunately, you were not able >> or willing to do so until now. It will be difficult to address your >> comment if you are not explaining it. >> >>> >>> • The end-to-end security setting as described in e.g. >>> draft-selander-ace-object-security, is missing from in this draft. (See >>> below) >> >> The tasks address the use of proxies (entities that are authorized to >> speak for ..). Is that what you are aiming at? >> >>> >>> >>> >>> Detailed comments: >>> >>> Section 1.1 >>> — >>> >>> • "Actor" >>> >>> I would call this "role". There is a common use of the terms "actor" and >>> "role", wherein a "role" characterizes certain functionality and an >>> "actor" is some entity that may or may not have the functionality >>> characterised by the role. >> >> The term "role" is quite confusing for authorization solutions since it >> will easily be mixed up with the roles in role based authorization. >> There was already so much confusion about the term "resource" that I >> would rather not use the term "role". >> >>> >>> "Resource Overseeing Principal (ROP): >>> Client Overseeing Principal (COP): >>> Server Authorization Manager (SAM):" >>> >>> These terms have >>> >>> >>> Section 2 >>> — >>> >>> • "authorized representation" >>> >>> This term is not defined in the terminology section but supposedly >>> means a >>> representation the client is configured to send in a particular request >>> >>> >>> • "authorized resources" >>> >>> This term is not defined in the terminology section but supposedly >>> means a >>> resource that a client is configured to request >> >> I don't get what you are trying to tell me with these comments. >> >>> >>> >>> >>> • "Req.0.2 C is exchanging status updates of a resource only with >>> authorized resources." >>> >>> That the use of the term authorization on the client side is misleading. >>> Every task a client performs is on behalf of its control node (COP). If >>> all these tasks are called authorization, then there is nothing that >>> isn't >>> authorization. There is no system resource on the client side to which >>> access is authorized. >> >> I don't know what your interpretion of authorization is. The handbook of >> applied cryptography defines it as the "conveyance, to another entity, >> of official sanction to do or be something". >> >> To achieve the security objectives of the client overseeing principal, >> the client must be able to enforce them. It needs to be able to answer >> the question "Does my principal think that this resource on this server >> is an authorized resource or not". Otherwise the security objectives >> integrity and confidentiality are threatened. >> >> The authorization problems on the client side won't go away if we >> pretend that they are not there or try to define them away. >> >>> >>> Section 3 >>> — >>> >>> • "The security objectives that can be addressed by an authorization >>> solution are confidentiality and integrity. Availability cannot be >>> achieved by authorization solutions. However, misconfigured or wrongly >>> designed authorization solutions can result in availability breaches: >>> Users might no longer be able to use data and services as they are >>> supposed to. " >>> >>> I agree that confidentiality and integrity protection can be used as one >>> component to enforce an authorization decision, but characterizing >>> authorization only as that is misleading. Generally speaking, >>> authorization is about restricting access to (system) resources, which >>> include restricting the right to initiate processing on a server, which >>> in >>> turn provides some resistance against attacks/overload and thus is >>> related >>> to availability. >> >> It might be useful to point out that authorization might also be used >> for load control. >> >> Integrity and confidentiality have a direct dependency to authorization. >> If the authorization solution is broken, the integrity and >> confidentiality of data likely is compromised. I agree that you might >> also use authorization for load control, but availablity is not >> necessarily breached if the authorization solution fails. >> >>> >>> • "In many cases, one participating party might have different security >>> objectives than the other. However, to achieve a security objective, >>> both >>> parties must participate in providing a solution. E.g., if COP requires >>> the integrity of sensor value representations S is hosting, Both C and S >>> need to integrity-protect the transmitted data. " >>> >>> Why does C need to integrity protect transmitted data? Isn't it >>> sufficient >>> that S integrity protects the sensor value representation it is hosting? >> >> The integrity-protection won't work if C doesn't check the protection of >> the received data. I will rephrase this part to make it easier to >> understand >> >>> >>> Section 4 >>> — >>> >>> • "To determine if an entity is authorized to access a resource, an >>> authentication mechanism is needed. According to the Internet Security >>> Glossary [RFC4949], authentication is “the process of verifying a claim >>> that a system entity or system resource has a certain attribute value.” >>> Examples for attribute values are the ID of a device, the type of the >>> device or the name of its owner. " >>> >>> Authentication, in the sense of verifying a claim about a attribute >>> value, >>> is not necssary. A server may encrypt a resource representation with a >>> specific key only possessed by authorized clients (cf. OSCAR, >>> http://arxiv.org/abs/1404.7799). >> >> This is an example for authentication and authorization working closely >> together. You can do authorization and authentication together if you >> bind authorization information to a key. But you will still need to make >> sure that the key is given to the right entity. You can't do >> authorization if you are not sure who you are authorizing and if you >> cannot decide if the one you are talking to really is the one who is >> authorized. >> >>> >>> >>> • "We use the term authenticated authorization to refer to a synthesis >>> of >>> mechanism for authentication and authorization. " >>> >>> The term "Authenticated authorization" is quite vague. >> >> Can you elaborate that? I think the paragraph shows why authentication >> and authorization mechanism need to work together. >> >>> >>> >>> • "unrestricted authorization" >>> >>> This is defined as "no authorization". Why not just say so? >> >> If unrestricted authorization is used, no authorization mechanism is >> used. Therefore everyone is authorized. "no authorization" might be >> misinterpreted. >> >>> >>> • "For all cases where an authorization solution is needed (all but >>> Unrestricted Authorization), the authorizing party needs to be able to >>> authenticate the party that is to be authorized. Authentication is >>> therefore required for messages that contain representations of an >>> accessed item. More precisely, the authorizing party needs to make sure >>> that the receiver of a message containing a representation, and the >>> sender >>> of a message containing a representation are authorized to receive and >>> send this message, respectively. To achieve this, the integrity of these >>> messages is required: Authenticity cannot be assured if it is possible >>> for >>> an attacker to modify the message during transmission." >>> >>> I find a several things confusing here: >>> - What party is the authorizing party? A server or a SAM / >>> Authorization >>> Server? >> >> The client or the server. If the term "authorizing party" is confusing I >> can try to rephrase the section without using it. >> >> Summarizing, the section states that the receiver of a resource >> representation needs to make sure that the sender of the resource >> representation is allowed to send it and that the sender of a resource >> representation must make sure that the receiver of a resource >> representation is allowed to receive it. >> >>> >>> - "Authentication is therefore required for messages that contain >>> representations of an accessed item. " The next sentence claims to make >>> precise, but does so in terms of authorization. >> >> I don't understand this comment. >> >>> >>> - "the authorizing party needs to make sure that (- - -)the sender of a >>> message containing a representation are authorized to (- - -) send this >>> message". I think this had better be rephrased as the CAM enables >>> configuration of the client. >> >> I think configuration is a very vague term and can mean everything in >> this context. The problem that we need to solve here is an authorization >> problem. >> >>> >>> >>> • "The security objectives of one side can often only be achieved with >>> the >>> help of the other side. E.g., if the server requires the confidentiality >>> of a resource representation, the client must make sure that it does not >>> send resource updates to parties other than the server. Therefore, the >>> client must at least use binary authorization." >>> >>> The formulation indicates that the decision whether a client that makes >>> a >>> request is needs to take into account server policies before encrypting >>> the request. I think this should be configured in the client. >> >> I think it will be difficult to configure in the client what a server >> that belongs to someone else wants. I think it will be useful to assume >> that in some scenarios you will always need at least binary >> authorization on the client side. >> >>> >>> Section 6 >>> — >>> >>> 6.1 >>> >>> • "This document does not assume a specific solution." >>> >>> This is two-edged sword. If you claim that we can't use OAuth/UMA >>> architecture because it assumes a specific solution, then so does this >>> document. >> >> It might be helpful if you also state the context of this sentence. This >> refers to the exchanged messages between the client and the server which >> is stated in the next sentence. >> >>> >>> >>> 6.2 >>> >>> • "The reason for using an authorization solution is to validate that >>> the >>> entity that sent the information used for processing is authorized to >>> provide it. To validate if a sender is authorized to send a received >>> piece >>> of information, the receiver must determine the sender’s authorization. >>> Correspondingly, to validate if a receiver is allowed to receive a >>> message, the sender must determine its authorization. This can only be >>> achieved with the help of an authentication mechanism." >>> >>> I think this is all very complicated, and is overusing the term >>> "authorization". The server should determine if the client is authorized >>> to access a resource, and perform accordingly. The client should perform >>> as configured (potentially dynamically using a CAM-type node). That's >>> it. >> >> With "configure" you mean the configuration of authorization on the >> client side, I guess. >> >>> >>> >>> 6.4 >>> >>> item 1: I think this is out of scope for ACE >> >> The process of configuration might be out of scope but it is still a >> necessary process. In constrained environments it is necessary to >> consider how this configuration can occur since constrained devices >> often don't have user interfaces or displays. >> >>> item 2: agree. I think we should add something analogous about >>> configuration of client >> >> No need for that. This already applies to both the client and the server. >> >>> item 3-4: this is assuming a particular solution. We can obtain >>> granularity without the attribute exercise by associating certain keys >>> to >>> certain permissions, as mentioned above. >> >> I guess you are referring to item 3. I will try to rephrase it to better >> include those solutions. >> >> The authorization will still need to be enforced as defined in item 4. >> >>> >>> >>> 7.1 >>> >>> "C performs the following tasks: >>> • Negotiate means for secure communication (Task TSecureComm, see >>> Appendix >>> A.2.3)." >>> >>> Not necessary if there is a TTP, such as an Authorization Server, >>> providing security context >> >> If a device wants to communicate securely, it somehow hast to obtain the >> means (e.g. keying material) for that. If the Authorization Server >> provides this to the device this fulfills TSecureComm. >> >>> >>> • "Validate that an entity is an authorized source for R (Task >>> TValSourceAuthz, see Appendix A.2.2)." >>> >>> I would phrase this that C is configured to request R. >> >> You mean that you can make sure that an S is an authorized source for R >> by configuring C to access R on S? That would be one solution. >> >>> >>> "S performs the following tasks: >>> • Negotiate means for secure communication (Task TSecureComm, see >>> Appendix >>> A.2.3)." >>> >>> Not necessary if there is a TTP, such as an Authorization Server, >>> providing security context >> >> If the authorization provides this to the device, this is TSecureComm. >> >>> >>> >>> >>> 7.2 >>> >>> "COP must fulfill the following task: >>> • Configure for C authorization information for sources for R " >>> >>> I would rephrase this bullet as "• Configure for C resources R to be >>> accessed" >>> >>> >>> 7.3 >>> >>> • Why does the CAM have to be in the same security domain as C and COP. >>> Could it not be outsourced? (See e.g. Healthcare scenario >>> >>> http://kantarainitiative.org/confluence/display/uma/UMA+Trust+Model+User+ >>> gu >>> ide) >> >> What do you mean with outsourced? That the principal controlling C is >> different from the principal that controls CAM? >> >>> >>> >>> >>> • The setting with CAM always being intermediary between C and SAM >>> (=Authorization Server) is problematic. C needs to be authorized (and/or >>> prove that it is) to access S. In a federated setting it could work >>> that, >>> as CAM becomes authorized so does all its assigned Cs. But in the >>> general >>> case, SAM needs to communicate securely with C and provide the necessary >>> keys or credentials. In this case CAM has no security function. But the >>> architecture prescribes that interaction between C and SAM is never done >>> directly, but via CAM. In this case CAM does not have a role at all, so >>> there is not only a difference where CAM is hosted, but in its function. >> >> I don't quite understand what you are getting at. There may be cases >> where you don't need a distinct CAM. You can have a single machine or a >> single piece of software that performs CAM's and SAM's tasks. That's why >> the draft states: "The architecture of an actual solution might differ >> as long as the security requirements that derive from the relationship >> between the identified actors are considered. Several actors might share >> a single device or even be combined in a single >> piece of software. Interfaces between actors may be realized as >> protocols or be internal to such a piece of software." >> >>> >>> >>> >>> 8.1 >>> >>> • Next to last paragraph: Although confidentiality and integrity >>> protection are the security objectives considered in this document, >>> there >>> is no consideration of end-to-end security in the presence of >>> intermediary >>> nodes (which would induce DTLS hop by hop) >> >> What do you think is missing here? >> >>> >>> 8.2 >>> >>> • In case OAuth is applied to the "less constrained level", what are the >>> protected resources at SAM accessed by CAM? (Access tokens?) >> >> I think finding out how constrained level and less-constrained level >> protocols can work together is one of the challenges in ACE. I hope we >> will find out how we will do this exactly but I don't think this is in >> scope for the actor's draft. The draft just states that there are >> different requirements for the different levels. >> >> Best regards, >> Steffi >> >> >>> >>> >>> >>> >>> Best regards >>> Göran >>> >>> >>> >>> >>> >>> On 2015-03-10 14:25, "Stefanie Gerdes" wrote: >>> >>>> Hi all, >>>> >>>> Please find attached the new version notification for the actors draft. >>>> >>>> The main changes are: >>>> - To address comments (e.g., in the ACE session in Honolulu) OAuth >>>> terminology was removed to avoid misunderstandings. >>>> - The term "owner" was replaced since comments on the list indicated >>>> that owner might not be a suitable term. >>>> - A section about autonomous communication was added to point out that >>>> there is not always an active user in constrained environments, and >>>> devices need to be able to enforce the user's security policies >>>> autonomously. >>>> >>>> Comments are very welcome. >>>> >>>> Thanks, >>>> Steffi >>>> >>>> >>>> -------- Forwarded Message -------- >>>> Subject: New Version Notification for draft-gerdes-ace-actors-03.txt >>>> Date: Mon, 09 Mar 2015 16:49:20 -0700 >>>> From: internet-drafts@ietf.org >>>> To: Stefanie Gerdes , Stefanie Gerdes >>>> >>>> >>>> A new version of I-D, draft-gerdes-ace-actors-03.txt >>>> has been successfully submitted by Stefanie Gerdes and posted to the >>>> IETF repository. >>>> >>>> Name: draft-gerdes-ace-actors >>>> Revision: 03 >>>> Title: Actors in the ACE Architecture >>>> Document date: 2015-03-09 >>>> Group: Individual Submission >>>> Pages: 26 >>>> URL: >>>> http://www.ietf.org/internet-drafts/draft-gerdes-ace-actors-03.txt >>>> Status: >>>> https://datatracker.ietf.org/doc/draft-gerdes-ace-actors/ >>>> Htmlized: http://tools.ietf.org/html/draft-gerdes-ace-actors-03 >>>> Diff: >>>> http://www.ietf.org/rfcdiff?url2=draft-gerdes-ace-actors-03 >>>> >>>> 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. Based on the tasks, an >>>> architecture is developed to represent the relationships between >>>> the >>>> logical functional entities involved. >>>> >>>> >>>> >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> The IETF Secretariat >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Ace mailing list >>>> Ace@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ace >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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 Mar 25 01:00:42 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C991ACE0A for ; Wed, 25 Mar 2015 01:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 W9dMD0qDVWDb for ; Wed, 25 Mar 2015 01:00:38 -0700 (PDT) Received: from outbox.sics.se (outbox.sics.se [193.10.64.137]) by ietfa.amsl.com (Postfix) with ESMTP id 64F461ACE06 for ; Wed, 25 Mar 2015 01:00:38 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [192.36.171.201]) by outbox.sics.se (Postfix) with ESMTPS id 813D61089E for ; Wed, 25 Mar 2015 09:00:37 +0100 (CET) Received: from norm.sics.se (norm.sics.se [193.10.64.192]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id t2P80bpc006646 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 25 Mar 2015 09:00:37 +0100 Received: from [192.168.0.108] (unknown [85.235.11.178]) by norm.sics.se (Postfix) with ESMTPSA id 186E022F for ; Wed, 25 Mar 2015 09:00:37 +0100 (CET) Message-ID: <55126B1D.1030007@sics.se> Date: Wed, 25 Mar 2015 09:00:29 +0100 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: ace@ietf.org References: <7a940fc9-72a2-4503-a453-f8e2bae9cc51@alibaba-inc.com> <87fv8uvshg.fsf@tzi.org> In-Reply-To: <87fv8uvshg.fsf@tzi.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000200040203090206060607" X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sics-se:default, sics-se:default, base:default, @@RPTN) X-p0f-Info: os=Linux 2.2.x-3.x, link=Ethernet or modem X-CanIt-Geo: =?UTF-8?Q?ip=3D85.235.11.178; _country=3DSE; _region=3DSk=C3=A5ne; _city=3DLund; _latitude=3D55.7028; _longitude=3D13.1927; _http://maps.google.com/maps=3Fq=3D55.7028,13.1927&z=3D6?= X-CanItPRO-Stream: outbound-sics-se:outbound (inherits from outbound-sics-se:default, sics-se:default, base:default) X-Canit-Stats-ID: 09O7I0BNz - 71ac2d45a571 - 20150325 X-Antispam-Training-Forget: https://canit.sunet.se/canit/b.php?i=09O7I0BNz&m=71ac2d45a571&t=20150325&c=f X-Antispam-Training-Nonspam: https://canit.sunet.se/canit/b.php?i=09O7I0BNz&m=71ac2d45a571&t=20150325&c=n X-Antispam-Training-Spam: https://canit.sunet.se/canit/b.php?i=09O7I0BNz&m=71ac2d45a571&t=20150325&c=s X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 85.235.11.178 is neither permitted nor denied by domain ludwig@sics.se) receiver=e-mailfilter01.sunet.se; client-ip=85.235.11.178; envelope-from=; helo=norm.sics.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: Subject: Re: [Ace] ACE Report 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, 25 Mar 2015 08:00:41 -0000 This is a cryptographically signed message in MIME format. --------------ms000200040203090206060607 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 03/25/2015 01:19 AM, Olaf Bergmann wrote: > "Kepeng Li" writes: > >> ACE WG Meeting >> IETF 92 - Dallas >> Tuesday 24 March 2015, 13:00 - 15:00 CDT >> Chairs: Kepeng Li, Hannes Tschofenig > > [...] > >> - Action: Design team is requested to merge Problem Description draft >> and Actors draft, and provide a combined draft. > > After thinking a while about this I doubt that this is a good idea. > Both documents have a completely different focus: > draft-seitz-ace-problem-description lists a few design considerations > and makes assumptions to lay the ground for a preferred solution, while= > draft-gerdes-ace-actors analyzes the entire problem space on a > theoretical level and derives a reference model that takes *all* aspect= s > of authorization into account. > I recommend aligning the documents with > respect to their terminology and otherwise let them stay separate. It is quite natural to have a bias for one's own proposal, but claiming=20 that the actors draft is more solution neutral than the problem=20 description draft is hardly an objective stance. For the sake of making progress in ACE I'd suggest we do not go into a=20 discussion about this and instead try to capture the good points from=20 both drafts into one combined document. > I would love to see progress on the solution side soon instead of more > exhausting discussions whether or not the existence of real world > problems shall be denied by the ACE WG. > Now that was hardly a very constructive contribution Olaf. If we are to=20 make progress in ACE I suggest you refrain from snarky comments about a=20 discussion we discontinued without coming to an agreement. /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 --------------ms000200040203090206060607 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVDCC BhgwggUAoAMCAQICAwyGmDANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTE1MDEwODA4MzkwNloXDTE2MDEwOTIyNDEzMFowODEXMBUGA1UE AwwObHVkd2lnQHNpY3Muc2UxHTAbBgkqhkiG9w0BCQEWDmx1ZHdpZ0BzaWNzLnNlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxUHisC6rgXFsBHHBGo8ulz/cLX3gX5Ufhcwo rp+7djzMMuKPM1KOHq0bjWhmFe8ly8CzWdk2NS600t7IEBQWJiHLsdc12UqmNswQUpD7oqkR 1nRGT6leAHYTWapkR+nczZ2NxD+H7u4ZWVIZg0DFiTqtY8ghYHHYYy8BBoc/jHG78X4+JJAg s5XOa0gVl7W38vDvVpo14xhWEBGjzPk9WxWirqAF66PF+JEu2JD9LzFbpEq829SRXJMFB9wp oQNlH0UQ01/2sWCIBxPpHuEjxEF/V3Z/F2VsNTy4zvYrd+/MYO3w30F+bWQNZsMHEkTW1pEh iz7rQPWTBXoO8Fv0wQIDAQABo4IC1DCCAtAwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTqvKspqEm0E4R1sgsABYKk 6xDJqDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZBgNVHREEEjAQgQ5sdWR3 aWdAc2ljcy5zZTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcC AjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0 aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5 aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQEFBQADggEBAGXwFsbSfv4mMWqIk64CoxuR6ozo7J37igca7d9tpKIzVIp6xp7Zt+a+J9X3 1r4zgMRFnZJWQ5hy82W/fVDeG9i3NGMM6p7DNUrGjTbVHd11BQtbUOG9MSlyWKQbmt3Q1ElC f4SRLAQot5SPryLR2FTxQuFkMOrcDzVxNxnMgatOM2fAO8KS0H+wX+I7gC3pEnbg/eMqNgU+ Ktbc2y9naDNmLNLN65s8TT9xZyoQEn9S1oU8Xnh596OMu49Eccws8Ny+vAGESIHG4bqhMSjj rmDilL1Wj9nQahmBnID5oZD5g9s9KyqxiZIGNnowYYOpCrSeITZ1b7wg50dC8ySojnYwggY0 MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEw MjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0d Lep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiU fsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5Dp IpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuC YKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/ MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0j BBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzAB hhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nm c2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9 eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukD FUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyi kfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8Cnykh ExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b 970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCD z+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqA SfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNb BIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBth HSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+ UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAwyGmDAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTAzMjUwODAwMjlaMCMGCSqGSIb3DQEJBDEW BBS870gSboPWF/oFEkyoTULwhx+UFjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDDIaYMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJKoZIhvcNAQEBBQAE ggEAECYZsw1WefQWMEW/98n2ndUSz4DzXfsJd8/BEpYtIgoODcz+sR4Z6m2tFiPgJT/egYi/ A59p94DDOgSOpbBPeNhE2uTQRzeB2lemvwwu4FMq//4Jo2CD1OZpdr9xmmEgQzixNbhSp47e CBaKIZoO0IT/J4ZQeBn9aiUfzzG4u9DbcO5WsNso89thooVX8VsabE4Mv64KkUtwak0N2f/W PSbqk0Dj5VTJQniJA/AyXe+RUjdWZ/Y/xk9HPIgrxCYqEyhzPmHuFJnfHe0wxqmlDGLTT/ha ZNI6LPpx8SMDYiPNx3C5T4hDxkR8EtAqP4NlqjIbhOFhIGPm9OqwPyLfTgAAAAAAAA== --------------ms000200040203090206060607-- From nobody Wed Mar 25 01:17: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 342951ACE14 for ; Wed, 25 Mar 2015 01:17: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 naj1q3_0cGN3 for ; Wed, 25 Mar 2015 01:17:22 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3CF91ACE12 for ; Wed, 25 Mar 2015 01:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t2P8HItf012810; Wed, 25 Mar 2015 09:17:18 +0100 (CET) Received: from aung.tzi.org (unknown [IPv6:2001:638:708:30da:edad:685c:f675:5b64]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3lBj3f5Bzzz2p91; Wed, 25 Mar 2015 09:17:18 +0100 (CET) From: Olaf Bergmann To: Ludwig Seitz References: <7a940fc9-72a2-4503-a453-f8e2bae9cc51@alibaba-inc.com> <87fv8uvshg.fsf@tzi.org> <55126B1D.1030007@sics.se> Date: Wed, 25 Mar 2015 09:17:18 +0100 In-Reply-To: <55126B1D.1030007@sics.se> (Ludwig Seitz's message of "Wed, 25 Mar 2015 09:00:29 +0100") Message-ID: <877fu5wkxd.fsf@tzi.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: ace@ietf.org Subject: Re: [Ace] ACE Report 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, 25 Mar 2015 08:17:29 -0000 Ludwig Seitz writes: > On 03/25/2015 01:19 AM, Olaf Bergmann wrote: >> "Kepeng Li" writes: >> >>> ACE WG Meeting >>> IETF 92 - Dallas >>> Tuesday 24 March 2015, 13:00 - 15:00 CDT >>> Chairs: Kepeng Li, Hannes Tschofenig >> >> [...] >> >>> - Action: Design team is requested to merge Problem Description draft >>> and Actors draft, and provide a combined draft. >> >> After thinking a while about this I doubt that this is a good idea. >> Both documents have a completely different focus: >> draft-seitz-ace-problem-description lists a few design considerations >> and makes assumptions to lay the ground for a preferred solution, while >> draft-gerdes-ace-actors analyzes the entire problem space on a >> theoretical level and derives a reference model that takes *all* aspects >> of authorization into account. >> I recommend aligning the documents with >> respect to their terminology and otherwise let them stay separate. > > It is quite natural to have a bias for one's own proposal, but > claiming that the actors draft is more solution neutral than the > problem description draft is hardly an objective stance. The actors draft is not my proposal. But I have reviewed it and provided some feedback to the author. I am indeed bias in the sense that I see that every solution proposal on the table is covered by the actors draft, including dcaf, while draft-seitz-ace-problem-description explicitly removes certain tasks from the problem space. Again: It is ok for me if a solution is designed skip these tasks (in dcaf, e.g. the client/CS/Rqp side is free not to make use of these features, being rewarded with less code and memory complexity) , but the abstract model should document them. > For the sake of making progress in ACE I'd suggest we do not go into a > discussion about this and instead try to capture the good points from > both drafts into one combined document. > >> I would love to see progress on the solution side soon instead of more >> exhausting discussions whether or not the existence of real world >> problems shall be denied by the ACE WG. >> > Now that was hardly a very constructive contribution Olaf. If we are > to make progress in ACE I suggest you refrain from snarky comments > about a discussion we discontinued without coming to an agreement. Please accept my apologies for that. Gr=C3=BC=C3=9Fe Olaf From nobody Wed Mar 25 03:11: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 618671A896C for ; Wed, 25 Mar 2015 03:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtTlsyqcDem9 for ; Wed, 25 Mar 2015 03:11:04 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E65E01A0151 for ; Wed, 25 Mar 2015 03:11:03 -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 t2PAAtH5007589; Wed, 25 Mar 2015 11:10:56 +0100 (CET) Received: from aung.tzi.org (unknown [IPv6:2001:638:708:30da:edad:685c:f675:5b64]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3lBlZl5yM2z2pZ0; Wed, 25 Mar 2015 11:10:55 +0100 (CET) From: Olaf Bergmann To: Eve Maler References: <59F1C792-B108-4DEC-8B5F-94CA8DC19BF8@xmlgrrl.com> Date: Wed, 25 Mar 2015 11:10:55 +0100 In-Reply-To: <59F1C792-B108-4DEC-8B5F-94CA8DC19BF8@xmlgrrl.com> (Eve Maler's message of "Tue, 10 Mar 2015 10:53:05 -0700") Message-ID: <87vbhpv13k.fsf@tzi.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: ace@ietf.org Subject: Re: [Ace] New doc: draft-maler-ace-oauth-uma-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 10:11:05 -0000 Eve, Eve Maler writes: > http://tools.ietf.org/html/draft-maler-ace-oauth-uma-00 Thanks for sharing this. One question: draft-hardjono-oauth-umacore-12 specifies that when a client attempts to access a protected resource, the resource server must register a requested permission with its authorization server to get an RPT that the client must present to the authorization server. From reading Section 5 of draft-maler-ace-oauth-uma, it is unclear to me whether or not this step is required in this profile. Can you clarify how this is supposed to work? Thanks Olaf From nobody Wed Mar 25 04:42: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 2A67A1ACE33 for ; Wed, 25 Mar 2015 04:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xd2cmKZ69o_4 for ; Wed, 25 Mar 2015 04:42:38 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::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 72A911A8A73 for ; Wed, 25 Mar 2015 04:42:38 -0700 (PDT) Received: by oicf142 with SMTP id f142so9574724oic.3 for ; Wed, 25 Mar 2015 04:42:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=V39PxTsHLPtIfNCWKgO9JvlaPVoeuXpPuVqso1d6nYc=; b=q+14NZxaqlUs3riLIW4Jc1z/DkkaIEDVCqjxzeNSJZUF5ahMmJWwW4TUl60POqvpjb nb3NP8CBnZC6UtJNxczW8lY3sl7Kr/om7POinwa6aspP2CK6PgfkNKq5BCRjZEZipK0o ysm3XZ6XWW79+/1QvCVI0dfR9reetbdHRA7sWuzNF6APe7tHPn1YxAbFsTQO/zABvUJW ScMX8qoXjW2V4rJj9f3fLPGXUusaPvqm6fA/6EBqmxlq2Wz8MOV9SIawI2QBDWQM03VK h01jGRIUW73P9IR0GlQuEJIjCVtnBTqzMO7LMZv61imHdUU6s6xFaiB6oq0opmohfitY 88ow== MIME-Version: 1.0 X-Received: by 10.60.131.206 with SMTP id oo14mr7225976oeb.30.1427283757767; Wed, 25 Mar 2015 04:42:37 -0700 (PDT) Sender: robert.cragie@gmail.com Received: by 10.202.80.18 with HTTP; Wed, 25 Mar 2015 04:42:37 -0700 (PDT) In-Reply-To: <87fv8uvshg.fsf@tzi.org> References: <7a940fc9-72a2-4503-a453-f8e2bae9cc51@alibaba-inc.com> <87fv8uvshg.fsf@tzi.org> Date: Wed, 25 Mar 2015 11:42:37 +0000 X-Google-Sender-Auth: flQenZqJambDIO1yEF2Mn-CCTKI Message-ID: From: Robert Cragie To: Olaf Bergmann Content-Type: multipart/alternative; boundary=047d7b4724ac60217605121b6576 Archived-At: Cc: Ace Subject: Re: [Ace] ACE Report X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 11:42:40 -0000 --047d7b4724ac60217605121b6576 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I disagree. Cherry picking a few design considerations on its own is not going to result in a best-for fit solution. Exhaustively analysing the entire problem space isn't either as it throws out too many options. However, this bottom up/top down approach used together in an intelligent manner may do and is likely to converge quicker than the zig-zag path it has been taking up to now. It is clear that there are already a considerable number of common areas as was clearly demonstrated in the presentations yesterday. There seems to be agreement not to get into an academic debate over the terms and I think there are only 2 or 3 terms (out of a total of probably less than 10) which differ. Robert On 25 March 2015 at 00:19, Olaf Bergmann wrote: > "Kepeng Li" writes: > > > ACE WG Meeting > > IETF 92 - Dallas > > Tuesday 24 March 2015, 13:00 - 15:00 CDT > > Chairs: Kepeng Li, Hannes Tschofenig > > [...] > > > - Action: Design team is requested to merge Problem Description draft > > and Actors draft, and provide a combined draft. > > After thinking a while about this I doubt that this is a good idea. > Both documents have a completely different focus: > draft-seitz-ace-problem-description lists a few design considerations > and makes assumptions to lay the ground for a preferred solution, while > draft-gerdes-ace-actors analyzes the entire problem space on a > theoretical level and derives a reference model that takes *all* aspects > of authorization into account. I recommend aligning the documents with > respect to their terminology and otherwise let them stay separate. > I would love to see progress on the solution side soon instead of more > exhausting discussions whether or not the existence of real world > problems shall be denied by the ACE WG. > > Gr=C3=BC=C3=9Fe > Olaf > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --047d7b4724ac60217605121b6576 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I disagree. Cherry picking a few design considerations on = its own is not going to result in a best-for fit solution. Exhaustively ana= lysing the entire problem space isn't either as it throws out too many = options. However, this bottom up/top down approach used together in an inte= lligent manner may do and is likely to converge quicker than the zig-zag pa= th it has been taking up to now. It is clear that there are already a consi= derable number of common areas as was clearly demonstrated in the presentat= ions yesterday. There seems to be agreement not to get into an academic deb= ate over the terms and I think there are only 2 or 3 terms (out of a total = of probably less than 10) which differ.

Robert

On 25 March 2015 at 00:= 19, Olaf Bergmann <bergmann@tzi.org> wrote:
"Kepeng Li" <kepeng.lkp@alibaba-inc.com> writes:
> ACE WG Meeting
> IETF 92 - Dallas
> Tuesday 24 March 2015, 13:00 - 15:00 CDT
> Chairs: Kepeng Li, Hannes Tschofenig

[...]

> - Action: Design team is requested to merge Problem Description draft<= br> > and Actors draft, and provide a combined draft.

After thinking a while about this I doubt that this is a good idea.<= br> Both documents have a completely different focus:
draft-seitz-ace-problem-description lists a few design considerations
and makes assumptions to lay the ground for a preferred solution, while
draft-gerdes-ace-actors analyzes the entire problem space on a
theoretical level and derives a reference model that takes *all* aspects of authorization into account. I recommend aligning the documents with
respect to their terminology and otherwise let them stay separate.
I would love to see progress on the solution side soon instead of more
exhausting discussions whether or not the existence of real world
problems shall be denied by the ACE WG.

Gr=C3=BC=C3=9Fe
Olaf

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

--047d7b4724ac60217605121b6576-- From nobody Wed Mar 25 09:15:15 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0A91A8894 for ; Wed, 25 Mar 2015 09:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9lHRhKlEkru for ; Wed, 25 Mar 2015 09:15:12 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F9991B2A7B for ; Wed, 25 Mar 2015 09:14:57 -0700 (PDT) X-AuditID: 1209190e-f79a76d000000d1b-11-5512df006d4d Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 0B.BD.03355.00FD2155; Wed, 25 Mar 2015 12:14:56 -0400 (EDT) Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t2PGEslr022109; Wed, 25 Mar 2015 12:14:55 -0400 Received: from W92EXEDGE6.EXCHANGE.MIT.EDU (w92exedge6.exchange.mit.edu [18.7.73.28]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id t2PGEYkk007059; Wed, 25 Mar 2015 12:14:54 -0400 Received: from W92EXHUB11.exchange.mit.edu (18.7.73.20) by W92EXEDGE6.EXCHANGE.MIT.EDU (18.7.73.28) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 25 Mar 2015 12:13:54 -0400 Received: from OC11EXPO24.exchange.mit.edu ([169.254.1.184]) by W92EXHUB11.exchange.mit.edu ([18.7.73.20]) with mapi id 14.03.0158.001; Wed, 25 Mar 2015 12:14:37 -0400 From: Thomas Hardjono To: Olaf Bergmann Thread-Topic: [Ace] New doc: draft-maler-ace-oauth-uma-00 Thread-Index: AQHQZuQD9/2bq6MAyUqCPahRYFita50tX8pM Date: Wed, 25 Mar 2015 16:14:35 +0000 Message-ID: References: <59F1C792-B108-4DEC-8B5F-94CA8DC19BF8@xmlgrrl.com>, <87vbhpv13k.fsf@tzi.org> In-Reply-To: <87vbhpv13k.fsf@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIKsWRmVeSWpSXmKPExsUixG6nrstwXyjU4PUOOYvv33qYLZoWNzJZ vLuwlNGB2WPJkp9MHtMWZXrsa7nKFsAcxWWTkpqTWZZapG+XwJXxcu4qloInHBX/l/5namDs Y+9i5OSQEDCRePhkKyuELSZx4d56NhBbSGAxk8S1vZxdjFxA9gFGidn7djJDJI4xSmx9kwOR 2M4o0Tr1ESuEs5pR4urvpWBVbAIaEm0/esFWiAioSGzofsYEYjML2EnsunIAqIGDQ1jAQuLO qgCIEkuJ129WQJUbSXw6uxTsIhYBVYmeZXvALuIVsJJY03+YCeKIcIkrX1+C2ZxANTd+bwer ZwT64PupNVCrxCVuPZnPBPGZoMSi2XuYYb78t+shG0SNjsSC3Z+gbG2JZQtfM0PsEpQ4OfMJ ywRGiVlIRs1C0jILScssJC0LGFlWMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Rrr5WaW6KWmlG5i BMUkpyTfDsavB5UOMQpwMCrx8P6QEAoVYk0sK67MPcQoycGkJMq7/wxQiC8pP6UyI7E4I76o NCe1+BCjBAezkgjvzk1AOd6UxMqq1KJ8mJQ0B4uSOO+mH3whQgLpiSWp2ampBalFMFkZDg4l Cd6eu0CNgkWp6akVaZk5JQhpJg5OkOE8QMO3gNTwFhck5hZnpkPkTzEqSonzbgBJCIAkMkrz 4HphKfMVozjQK8K8b0GqeIDpFq77FdBgJqDB5/L5QAaXJCKkpBoYw6PvTN13tpeP8br2izYj /mfJq+cKFK4Lrp4RdJRFwJ9LZMlFgfSP9WJyiZ9cts75u8k/RVa5Xct+csKxkwdCr95dXer7 f9nOFY/EP4s7KrLPOv/bJP9uj9lbhds9R3Rvn97qc+DTyapvBjW8ygXWizQ+aqVsKvzvcn/X tBP75imXa3Y2tLqaK7EUZyQaajEXFScCAMXebCh0AwAA Archived-At: Cc: Eve Maler , "ace@ietf.org" Subject: Re: [Ace] New doc: draft-maler-ace-oauth-uma-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 16:15:14 -0000 Hi Olaf, In order to use UMA in a given IoT scenario, you will need to create a prof= ile of UMA that defines the "missing parts", such as the contents of the pe= rmission ticket. This is what the HEART WG is doing in the OIF.=20 /thomas/ > On Mar 25, 2015, at 06:11, Olaf Bergmann wrote: >=20 > Eve, >=20 > Eve Maler writes: >=20 >> http://tools.ietf.org/html/draft-maler-ace-oauth-uma-00 >=20 > Thanks for sharing this. >=20 > One question: draft-hardjono-oauth-umacore-12 specifies that when a > client attempts to access a protected resource, the resource server must > register a requested permission with its authorization server to get an > RPT that the client must present to the authorization server. From > reading Section 5 of draft-maler-ace-oauth-uma, it is unclear to me > whether or not this step is required in this profile. Can you clarify > how this is supposed to work? >=20 > Thanks > Olaf >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Wed Mar 25 12:45: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 13CA41B2AF8 for ; Wed, 25 Mar 2015 12:45:31 -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 2qgUxnU_Nf0P for ; Wed, 25 Mar 2015 12:45:29 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D94B21B2B03 for ; Wed, 25 Mar 2015 12:45:28 -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 t2PJjFpn012845; Wed, 25 Mar 2015 20:45:15 +0100 (CET) Received: from [IPv6:2001:638:708:30da:9b4:90a1:dc19:41f9] (unknown [IPv6:2001:638:708:30da:9b4:90a1:dc19:41f9]) (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 3lC0KR2J8PzCt0R; Wed, 25 Mar 2015 20:45:15 +0100 (CET) Message-ID: <5513104B.30600@tzi.de> Date: Wed, 25 Mar 2015 20:45:15 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: robert.cragie@gridmerge.com, Olaf Bergmann References: <7a940fc9-72a2-4503-a453-f8e2bae9cc51@alibaba-inc.com> <87fv8uvshg.fsf@tzi.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Ace Subject: Re: [Ace] ACE Report 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, 25 Mar 2015 19:45:31 -0000 Hi Robert, I agree that there are already a considerable number of common areas. The actors draft already covers the architecture proposed in the problem description. Moreover, the problem description uses the actors draft as input, so this is not really surprising. Can you elaborate what you are missing in the actors draft? That would be helpful for me. Best regards, Steffi On 03/25/2015 12:42 PM, Robert Cragie wrote: > I disagree. Cherry picking a few design considerations on its own is not > going to result in a best-for fit solution. Exhaustively analysing the > entire problem space isn't either as it throws out too many options. > However, this bottom up/top down approach used together in an intelligent > manner may do and is likely to converge quicker than the zig-zag path it > has been taking up to now. It is clear that there are already a > considerable number of common areas as was clearly demonstrated in the > presentations yesterday. There seems to be agreement not to get into an > academic debate over the terms and I think there are only 2 or 3 terms (out > of a total of probably less than 10) which differ. > > Robert > > On 25 March 2015 at 00:19, Olaf Bergmann wrote: > >> "Kepeng Li" writes: >> >>> ACE WG Meeting >>> IETF 92 - Dallas >>> Tuesday 24 March 2015, 13:00 - 15:00 CDT >>> Chairs: Kepeng Li, Hannes Tschofenig >> >> [...] >> >>> - Action: Design team is requested to merge Problem Description draft >>> and Actors draft, and provide a combined draft. >> >> After thinking a while about this I doubt that this is a good idea. >> Both documents have a completely different focus: >> draft-seitz-ace-problem-description lists a few design considerations >> and makes assumptions to lay the ground for a preferred solution, while >> draft-gerdes-ace-actors analyzes the entire problem space on a >> theoretical level and derives a reference model that takes *all* aspects >> of authorization into account. I recommend aligning the documents with >> respect to their terminology and otherwise let them stay separate. >> I would love to see progress on the solution side soon instead of more >> exhausting discussions whether or not the existence of real world >> problems shall be denied by the ACE WG. >> >> Gre >> Olaf >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >> > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > -- Stefanie Gerdes Tel: +49 421 218 63906 TZI Universitt Bremen E-Mail: gerdes@tzi.de Bibliothekstr. 1, MZH 5150 28359 Bremen, Germany From nobody Wed Mar 25 14:34: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 85A211B2B77 for ; Wed, 25 Mar 2015 14:34:23 -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 PowzHDB81q4g for ; Wed, 25 Mar 2015 14:34:21 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 934401B2B72 for ; Wed, 25 Mar 2015 14:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t2PLYHuE016871 for ; Wed, 25 Mar 2015 22:34:17 +0100 (CET) Received: from alma.local (unknown [IPv6:2001:67c:370:152:688d:231c:b24:24b0]) (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 3lC2lD5stfzCtc2; Wed, 25 Mar 2015 22:34:16 +0100 (CET) Message-ID: <551329D7.7010003@tzi.org> Date: Wed, 25 Mar 2015 16:34:15 -0500 From: Carsten Bormann User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: "ace@ietf.org" References: <20150325213103.19039.85000.idtracker@ietfa.amsl.com> In-Reply-To: <20150325213103.19039.85000.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-actors-04.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, 25 Mar 2015 21:34:23 -0000 I have submitted a first version of a merged actors/problem description draft, as discussed yesterday in the WG meeing. Since there are still some requirements in the latter, as well as material that already was written up previously in the actors draft, there is some more trimming required. But I think the raw merged version is a good basis to see how the merged document might look like. Comments, preferably about the content, but also about things to strike, are welcome -- to the list or to me. Gruesse, Carsten -------- Original Message -------- Subject: New Version Notification for draft-gerdes-ace-actors-04.txt Date: Wed, 25 Mar 2015 14:31:03 -0700 From: internet-drafts@ietf.org To: Goeran Selander , Dr. Carsten Bormann , Ludwig Seitz , Goran Selander , Stefanie Gerdes , Stefanie Gerdes , Carsten Bormann , Ludwig Seitz A new version of I-D, draft-gerdes-ace-actors-04.txt has been successfully submitted by Stefanie Gerdes and posted to the IETF repository. Name: draft-gerdes-ace-actors Revision: 04 Title: Actors in the ACE Architecture Document date: 2015-03-25 Group: Individual Submission Pages: 30 URL: http://www.ietf.org/internet-drafts/draft-gerdes-ace-actors-04.txt Status: https://datatracker.ietf.org/doc/draft-gerdes-ace-actors/ Htmlized: http://tools.ietf.org/html/draft-gerdes-ace-actors-04 Diff: http://www.ietf.org/rfcdiff?url2=draft-gerdes-ace-actors-04 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. This document gives an overview of the necessary terminology and introduces the actors in an architecture as guidance for the development of authentication and authorization solutions for constrained environments. The actors represent the relationships between the logical functional entities involved. We also present a problem description for authentication and authorization in constrained-node networks, i.e. networks where some devices have severe constraints on memory, processing, power and communication bandwidth. 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 Thu Mar 26 04:11: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 79C701B2C5E for ; Thu, 26 Mar 2015 04:11:26 -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 8d1uCMmoBO01 for ; Thu, 26 Mar 2015 04:11:26 -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 9CB7A1ACE40 for ; Thu, 26 Mar 2015 04:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t2QBBMjZ001809; Thu, 26 Mar 2015 12:11:22 +0100 (CET) Received: from aung.tzi.org (unknown [IPv6:2001:638:708:30da:dcd:4e1d:d7ed:34b6]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3lCNt21HwGzCtT2; Thu, 26 Mar 2015 12:11:22 +0100 (CET) From: Olaf Bergmann To: Thomas Hardjono References: <59F1C792-B108-4DEC-8B5F-94CA8DC19BF8@xmlgrrl.com> <87vbhpv13k.fsf@tzi.org> Date: Thu, 26 Mar 2015 12:11:21 +0100 In-Reply-To: (Thomas Hardjono's message of "Wed, 25 Mar 2015 16:14:35 +0000") Message-ID: <87sics57za.fsf@tzi.org> 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: Eve Maler , "ace@ietf.org" Subject: Re: [Ace] New doc: draft-maler-ace-oauth-uma-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 11:11:26 -0000 Hi Thomas, Thomas Hardjono writes: > In order to use UMA in a given IoT scenario, you will need to create a > profile of UMA that defines the "missing parts", such as the contents > of the permission ticket. This is what the HEART WG is doing in the > OIF. Thank you for the clarification, maybe it would be good to include this as a note or so in draft-maler-ace-oauth-uma. Can you provide a pointer to the HEART WG's docs? Gr=C3=BC=C3=9Fe Olaf From nobody Thu Mar 26 04:27: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 3E9991B2C79 for ; Thu, 26 Mar 2015 04:27: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 IJ2jNyN-Jc9m for ; Thu, 26 Mar 2015 04:27:53 -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 67DBA1B2C6D for ; Thu, 26 Mar 2015 04:27:52 -0700 (PDT) X-AuditID: c1b4fb2d-f79a46d0000006b4-07-5513ed35a6a0 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 35.21.01716.53DE3155; Thu, 26 Mar 2015 12:27:50 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.196]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0210.002; Thu, 26 Mar 2015 12:27:49 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Carsten Bormann Thread-Topic: [Ace] Fwd: New Version Notification for draft-gerdes-ace-actors-04.txt Thread-Index: AQHQZ7fjuJdjEGLpqE6XL6nhDmH/5w== Date: Thu, 26 Mar 2015 11:27:48 +0000 Message-ID: References: <20150325213103.19039.85000.idtracker@ietfa.amsl.com> <551329D7.7010003@tzi.org> In-Reply-To: <551329D7.7010003@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.154] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGfG3RtfsrXCoQe9RJovv33qYLY5Mucvq wOSxZMlPJo9pizIDmKK4bFJSczLLUov07RK4Mvbd7WMteKZV8XHvD5YGxhuaXYycHBICJhIn L3xkh7DFJC7cW8/WxcjFISRwhFHi8vktYAkhgSWMEoePKoDYbAIuEg8aHjGB2CICShIXLq5h A7GZBRQl1s3pA4pzcAgLhEocvakFYooIhEnc/s8KUa0nsWH1QxYQm0VAVWLXkg3MIDavgIXE helP2CA2xUlcbP8LVs8poC5xZutFsBpGoNO+n1rDBLFJXOLWk/lMECcLSCzZc54ZwhaVePn4 H1ivKNCuldeb2CDiShKLbn8Gu4xZQFNi/S59iDHWEv/vNDLCHD+l+yE7xDmCEidnPmGZwCgx C8m2WQjds5B0z0LSPQtJ9wJG1lWMosWpxcW56UbGeqlFmcnFxfl5enmpJZsYgdF3cMtv3R2M q187HmIU4GBU4uEtWCccKsSaWFZcmXuIUZqDRUmc1874UIiQQHpiSWp2ampBalF8UWlOavEh RiYOTqkGxqY8R6kKlVl9927+SHwwd6+hBEvs1UOWdwz2ztpd8tRUcotNvfdvgZBrvsWfDP6s ble8fLfs6J9ldQ3MdxeXtz+O7Ofd4vyV88aKT62GwrsXreqy6k1wWL1ZyaQ9w5h1x60V224K HCysd2Bruc3rrtx/8M+GA1vva3w/oBwYqavCKOz9xqv2nRJLcUaioRZzUXEiAEuTiV6fAgAA Archived-At: Cc: "ace@ietf.org" Subject: Re: [Ace] Fwd: New Version Notification for draft-gerdes-ace-actors-04.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 11:27:55 -0000 SGkgQ2Fyc3RlbiwNCg0KQ29udGVudHdpc2UsIHdoYXQgaXMgbWlzc2luZyBpcyB0aGUgaHlicmlk IHByb2JsZW0gc3RhdGVtZW50IGluIHRlcm1zIG9mDQp0aGUgZW5kcG9pbnRzIGFzIHdhcyBhZ3Jl ZWQgZHVyaW5nIHRoZSBtZWV0aW5nOg0KaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85 Mi9zbGlkZXMvc2xpZGVzLTkyLWFjZS01LnBkZi4gU2luY2UgdGhpcw0KaW5jbHVkZXMgYSBjb21i aW5hdGlvbiBvZiB0aGUgYXJjaGl0ZWN0dXJlIG9mIG9uZSBkcmFmdCBhbmQgdGhlIHByb2JsZW0N CnN0YXRlbWVudCBmb3JtdWxhdGlvbiBvZiB0aGUgb3RoZXIsIHRoZXJlIGlzIG5vdCB5ZXQgYW55 IHRleHQvZmlndXJlcw0KY292ZXJpbmcgdGhhdCwgYnV0IEkgY2FuIG1ha2UgYSBmaXJzdCBkcmFm dC4NCg0KSW4gdGVybXMgb2Ygc3RydWN0dXJlLCBJIHRoaW5rIGEgbWVyZ2luZyBvZiB0d28gZG9j dW1lbnRzIHdpdGggb3ZlcmxhcHBpbmcNCmNvbnRlbnQgYnkgbWVhbnMgb2YgY29uY2F0ZW5hdGlv biBpcyBub3QgaWRlYWwsIGJ1dCB3ZSBjYW4gd29yayBvbiB0aGF0Lg0KDQpJIHNlbmQgbW9yZSBk ZXRhaWxzIGRpcmVjdGx5IHRvIHRoZSBlZGl0aW5nIHRlYW0uDQoNCg0KQmVzdCByZWdhcmRzLA0K R8O2cmFuDQoNCg0KDQpPbiAyMDE1LTAzLTI1IDE2OjM0LCAiQ2Fyc3RlbiBCb3JtYW5uIiA8Y2Fi b0B0emkub3JnPiB3cm90ZToNCg0KPkkgaGF2ZSBzdWJtaXR0ZWQgYSBmaXJzdCB2ZXJzaW9uIG9m IGEgbWVyZ2VkIGFjdG9ycy9wcm9ibGVtDQo+ZGVzY3JpcHRpb24gZHJhZnQsIGFzIGRpc2N1c3Nl ZCB5ZXN0ZXJkYXkgaW4gdGhlIFdHIG1lZWluZy4gIFNpbmNlDQo+dGhlcmUgYXJlIHN0aWxsIHNv bWUgcmVxdWlyZW1lbnRzIGluIHRoZSBsYXR0ZXIsIGFzIHdlbGwgYXMgbWF0ZXJpYWwNCj50aGF0 IGFscmVhZHkgd2FzIHdyaXR0ZW4gdXAgcHJldmlvdXNseSBpbiB0aGUgYWN0b3JzIGRyYWZ0LCB0 aGVyZSBpcw0KPnNvbWUgbW9yZSB0cmltbWluZyByZXF1aXJlZC4gIEJ1dCBJIHRoaW5rIHRoZSBy YXcgbWVyZ2VkIHZlcnNpb24gaXMgYQ0KPmdvb2QgYmFzaXMgdG8gc2VlIGhvdyB0aGUgbWVyZ2Vk IGRvY3VtZW50IG1pZ2h0IGxvb2sgbGlrZS4NCj4NCj5Db21tZW50cywgcHJlZmVyYWJseSBhYm91 dCB0aGUgY29udGVudCwgYnV0IGFsc28gYWJvdXQgdGhpbmdzIHRvDQo+c3RyaWtlLCBhcmUgd2Vs Y29tZSAtLSB0byB0aGUgbGlzdCBvciB0byBtZS4NCj4NCj5HcnVlc3NlLCBDYXJzdGVuDQo+DQo+ DQo+LS0tLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0tLQ0KPlN1YmplY3Q6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZ2VyZGVzLWFjZS1hY3RvcnMtMDQudHh0DQo+RGF0 ZTogV2VkLCAyNSBNYXIgMjAxNSAxNDozMTowMyAtMDcwMA0KPkZyb206IGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZw0KPlRvOiBHb2VyYW4gU2VsYW5kZXIgPGdvcmFuLnNlbGFuZGVyQGVyaWNzc29u LmNvbT4sICAgICAgICBEci4gQ2Fyc3Rlbg0KPkJvcm1hbm4gPGNhYm9AdHppLm9yZz4sIEx1ZHdp ZyBTZWl0eiA8bHVkd2lnQHNpY3Muc2U+LCAgICAgICAgR29yYW4NCj5TZWxhbmRlciA8Z29yYW4u c2VsYW5kZXJAZXJpY3Nzb24uY29tPiwgICAgICAgIFN0ZWZhbmllIEdlcmRlcw0KPjxnZXJkZXNA dHppLm9yZz4sIFN0ZWZhbmllIEdlcmRlcyA8Z2VyZGVzQHR6aS5vcmc+LCAgICAgICAgQ2Fyc3Rl bg0KPkJvcm1hbm4gPGNhYm9AdHppLm9yZz4sIEx1ZHdpZyBTZWl0eiA8bHVkd2lnQHNpY3Muc2U+ DQo+DQo+DQo+QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWdlcmRlcy1hY2UtYWN0b3JzLTA0 LnR4dA0KPmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgU3RlZmFuaWUgR2VyZGVz IGFuZCBwb3N0ZWQgdG8gdGhlDQo+SUVURiByZXBvc2l0b3J5Lg0KPg0KPk5hbWU6CQlkcmFmdC1n ZXJkZXMtYWNlLWFjdG9ycw0KPlJldmlzaW9uOgkwNA0KPlRpdGxlOgkJQWN0b3JzIGluIHRoZSBB Q0UgQXJjaGl0ZWN0dXJlDQo+RG9jdW1lbnQgZGF0ZToJMjAxNS0wMy0yNQ0KPkdyb3VwOgkJSW5k aXZpZHVhbCBTdWJtaXNzaW9uDQo+UGFnZXM6CQkzMA0KPlVSTDoNCj5odHRwOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1nZXJkZXMtYWNlLWFjdG9ycy0wNC50eHQNCj5TdGF0 dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZ2VyZGVz LWFjZS1hY3RvcnMvDQo+SHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWdlcmRlcy1hY2UtYWN0b3JzLTA0DQo+RGlmZjogICAgICAgICAgIA0KPmh0dHA6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWdlcmRlcy1hY2UtYWN0b3JzLTA0DQo+DQo+ QWJzdHJhY3Q6DQo+ICAgQ29uc3RyYWluZWQgbm9kZXMgYXJlIHNtYWxsIGRldmljZXMgd2hpY2gg YXJlIGxpbWl0ZWQgaW4gdGVybXMgb2YNCj4gICBwcm9jZXNzaW5nIHBvd2VyLCBtZW1vcnksIG5v bi12b2xhdGlsZSBzdG9yYWdlIGFuZCB0cmFuc21pc3Npb24NCj4gICBjYXBhY2l0eS4gIER1ZSB0 byB0aGVzZSBjb25zdHJhaW50cywgY29tbW9ubHkgdXNlZCBzZWN1cml0eSBwcm90b2NvbHMNCj4g ICBhcmUgbm90IGVhc2lseSBhcHBsaWNhYmxlLiAgTmV2ZXJ0aGVsZXNzLCBhbiBhdXRoZW50aWNh dGlvbiBhbmQNCj4gICBhdXRob3JpemF0aW9uIHNvbHV0aW9uIGlzIG5lZWRlZCB0byBlbnN1cmUg dGhlIHNlY3VyaXR5IG9mIHRoZXNlDQo+ICAgZGV2aWNlcy4NCj4NCj4gICBEdWUgdG8gdGhlIGxp bWl0YXRpb25zIG9mIHRoZSBjb25zdHJhaW5lZCBub2RlcyBpdCBpcyBlc3BlY2lhbGx5DQo+ICAg aW1wb3J0YW50IHRvIGRldmVsb3AgYSBsaWdodC13ZWlnaHQgc2VjdXJpdHkgc29sdXRpb24gd2hp Y2ggaXMNCj4gICBhZGp1c3RlZCB0byB0aGUgcmVsZXZhbnQgc2VjdXJpdHkgb2JqZWN0aXZlcyBv ZiBlYWNoIHBhcnRpY2lwYXRpbmcNCj4gICBwYXJ0eSBpbiB0aGlzIGVudmlyb25tZW50LiAgTmVj ZXNzYXJ5IHNlY3VyaXR5IG1lYXN1cmVzIG11c3QgYmUNCj4gICBpZGVudGlmaWVkIGFuZCBhcHBs aWVkIHdoZXJlIG5lZWRlZC4NCj4NCj4gICBUaGlzIGRvY3VtZW50IGdpdmVzIGFuIG92ZXJ2aWV3 IG9mIHRoZSBuZWNlc3NhcnkgdGVybWlub2xvZ3kgYW5kDQo+ICAgaW50cm9kdWNlcyB0aGUgYWN0 b3JzIGluIGFuIGFyY2hpdGVjdHVyZSBhcyBndWlkYW5jZSBmb3IgdGhlDQo+ICAgZGV2ZWxvcG1l bnQgb2YgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gc29sdXRpb25zIGZvcg0KPiAg IGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy4gIFRoZSBhY3RvcnMgcmVwcmVzZW50IHRoZSByZWxh dGlvbnNoaXBzDQo+ICAgYmV0d2VlbiB0aGUgbG9naWNhbCBmdW5jdGlvbmFsIGVudGl0aWVzIGlu dm9sdmVkLg0KPg0KPiAgIFdlIGFsc28gcHJlc2VudCBhIHByb2JsZW0gZGVzY3JpcHRpb24gZm9y IGF1dGhlbnRpY2F0aW9uIGFuZA0KPiAgIGF1dGhvcml6YXRpb24gaW4gY29uc3RyYWluZWQtbm9k ZSBuZXR3b3JrcywgaS5lLiBuZXR3b3JrcyB3aGVyZSBzb21lDQo+ICAgZGV2aWNlcyBoYXZlIHNl dmVyZSBjb25zdHJhaW50cyBvbiBtZW1vcnksIHByb2Nlc3NpbmcsIHBvd2VyIGFuZA0KPiAgIGNv bW11bmljYXRpb24gYmFuZHdpZHRoLg0KPg0KPg0KPg0KPg0KPg0KPlBsZWFzZSBub3RlIHRoYXQg aXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+c3VibWlz c2lvbg0KPnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQgdG9vbHMuaWV0Zi5vcmcuDQo+DQo+VGhlIElFVEYgU2VjcmV0YXJpYXQNCj4NCj4NCj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPkFjZSBtYWlsaW5n IGxpc3QNCj5BY2VAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2FjZQ0KDQo= From nobody Thu Mar 26 04:46: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 438201B2C76 for ; Thu, 26 Mar 2015 04:46:18 -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 tNfKe453RZsn for ; Thu, 26 Mar 2015 04:46:16 -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 41E311B2C95 for ; Thu, 26 Mar 2015 04:46:15 -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 t2QBkB8i019810; Thu, 26 Mar 2015 12:46:11 +0100 (CET) Received: from [192.168.1.109] (p57A63CC9.dip0.t-ipconnect.de [87.166.60.201]) (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 3lCPfC4SSGzCt0V; Thu, 26 Mar 2015 12:46:11 +0100 (CET) Message-ID: <5513F183.5010908@tzi.de> Date: Thu, 26 Mar 2015 12:46:11 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= , Carsten Bormann References: <20150325213103.19039.85000.idtracker@ietfa.amsl.com> <551329D7.7010003@tzi.org> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "ace@ietf.org" Subject: Re: [Ace] Fwd: New Version Notification for draft-gerdes-ace-actors-04.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 11:46:18 -0000 Hi Göran, The problem statement in the referred slideset states: "Overall goal of ACE is to control and protect interaction between potenially constrained endpoints." This is already covered in problem statement of the actors draft. The various possibilities how actors can be assigned to endpoints are also covered. I am looking forward to the details you are going to send. Best regards, Steffi On 03/26/2015 12:27 PM, Göran Selander wrote: > Hi Carsten, > > Contentwise, what is missing is the hybrid problem statement in terms of > the endpoints as was agreed during the meeting: > http://www.ietf.org/proceedings/92/slides/slides-92-ace-5.pdf. Since this > includes a combination of the architecture of one draft and the problem > statement formulation of the other, there is not yet any text/figures > covering that, but I can make a first draft. > > In terms of structure, I think a merging of two documents with overlapping > content by means of concatenation is not ideal, but we can work on that. > > I send more details directly to the editing team. > > > Best regards, > Göran > > > > On 2015-03-25 16:34, "Carsten Bormann" wrote: > >> I have submitted a first version of a merged actors/problem >> description draft, as discussed yesterday in the WG meeing. Since >> there are still some requirements in the latter, as well as material >> that already was written up previously in the actors draft, there is >> some more trimming required. But I think the raw merged version is a >> good basis to see how the merged document might look like. >> >> Comments, preferably about the content, but also about things to >> strike, are welcome -- to the list or to me. >> >> Gruesse, Carsten >> >> >> -------- Original Message -------- >> Subject: New Version Notification for draft-gerdes-ace-actors-04.txt >> Date: Wed, 25 Mar 2015 14:31:03 -0700 >> From: internet-drafts@ietf.org >> To: Goeran Selander , Dr. Carsten >> Bormann , Ludwig Seitz , Goran >> Selander , Stefanie Gerdes >> , Stefanie Gerdes , Carsten >> Bormann , Ludwig Seitz >> >> >> A new version of I-D, draft-gerdes-ace-actors-04.txt >> has been successfully submitted by Stefanie Gerdes and posted to the >> IETF repository. >> >> Name: draft-gerdes-ace-actors >> Revision: 04 >> Title: Actors in the ACE Architecture >> Document date: 2015-03-25 >> Group: Individual Submission >> Pages: 30 >> URL: >> http://www.ietf.org/internet-drafts/draft-gerdes-ace-actors-04.txt >> Status: https://datatracker.ietf.org/doc/draft-gerdes-ace-actors/ >> Htmlized: http://tools.ietf.org/html/draft-gerdes-ace-actors-04 >> Diff: >> http://www.ietf.org/rfcdiff?url2=draft-gerdes-ace-actors-04 >> >> 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. >> >> This document gives an overview of the necessary terminology and >> introduces the actors in an architecture as guidance for the >> development of authentication and authorization solutions for >> constrained environments. The actors represent the relationships >> between the logical functional entities involved. >> >> We also present a problem description for authentication and >> authorization in constrained-node networks, i.e. networks where some >> devices have severe constraints on memory, processing, power and >> communication bandwidth. >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace > > _______________________________________________ > 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 Thu Mar 26 07:18: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 44F721ACECF for ; Thu, 26 Mar 2015 07:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvnyWllaske7 for ; Thu, 26 Mar 2015 07:18:29 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 0C85D1ACEC7 for ; Thu, 26 Mar 2015 07:18:28 -0700 (PDT) X-AuditID: 12074422-f79cb6d000000d7b-6f-55141534a246 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 16.9C.03451.43514155; Thu, 26 Mar 2015 10:18:28 -0400 (EDT) Received: from outgoing-exchange-3.mit.edu (outgoing-exchange-3.mit.edu [18.9.28.13]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t2QEIRDe008045; Thu, 26 Mar 2015 10:18:28 -0400 Received: from W92EXEDGE5.EXCHANGE.MIT.EDU (w92exedge5.exchange.mit.edu [18.7.73.22]) by outgoing-exchange-3.mit.edu (8.13.8/8.12.4) with ESMTP id t2QEIKIx026118; Thu, 26 Mar 2015 10:18:26 -0400 Received: from W92EXHUB14.exchange.mit.edu (18.7.73.25) by W92EXEDGE5.EXCHANGE.MIT.EDU (18.7.73.22) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Mar 2015 10:17:30 -0400 Received: from OC11EXPO24.exchange.mit.edu ([169.254.1.20]) by W92EXHUB14.exchange.mit.edu ([18.7.73.25]) with mapi id 14.03.0158.001; Thu, 26 Mar 2015 10:18:07 -0400 From: Thomas Hardjono To: Olaf Bergmann Thread-Topic: [Ace] New doc: draft-maler-ace-oauth-uma-00 Thread-Index: AQHQZ7WW9/2bq6MAyUqCPahRYFita50uzMDf Date: Thu, 26 Mar 2015 14:18:06 +0000 Message-ID: <5E393DF26B791A428E5F003BB6C5342A92C612A6@OC11EXPO24.exchange.mit.edu> References: <59F1C792-B108-4DEC-8B5F-94CA8DC19BF8@xmlgrrl.com> <87vbhpv13k.fsf@tzi.org> ,<87sics57za.fsf@tzi.org> In-Reply-To: <87sics57za.fsf@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [18.111.17.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPKsWRmVeSWpSXmKPExsUixCmqrGsiKhJq0L5FweL7tx5mi6bFjUwW 7y4sZXRg9liy5CeTx7RFmR77Wq6yBTBHcdmkpOZklqUW6dslcGUcu9vJUvCMp+LIs2XMDYwz uboYOTkkBEwkVjztZ4KwxSQu3FvP1sXIxSEksJhJ4umu94wQzgFGiR07+thBqoQEjjFK3F+k C5HYziix5vkFJghnFVDi1WtGkCo2AQ2Jth+9YB0iAioSG7qfge1gFsiXWNj2gRXEFhawkOjc v5IVosZS4vWbFVD1RhJtlxvB5rAIqEqs/X8XyObg4BUIkni6OxrqPEaJ21NusoDUcALVnJxx EKyeEeiH76fWQO0Sl7j1ZD7Ub4ISi2bvYYb589+uh2wQtoLE/5uHWSHq9SRuTJ3CBmFrSyxb +Bqsnheo9+TMJywTGCVnIRk7C0nLLCQts5C0LGBkWcUom5JbpZubmJlTnJqsW5ycmJeXWqRr qpebWaKXmlK6iREUr+wuSjsYfx5UOsQowMGoxMP7o184VIg1say4MvcQoyQHk5Iob5mwSKgQ X1J+SmVGYnFGfFFpTmrxIUYJDmYlEd4dDEA53pTEyqrUonyYlDQHi5I476YffCFCAumJJanZ qakFqUUwWRkODiUJXh4RoEbBotT01Iq0zJwShDQTByfIcB6g4fogNbzFBYm5xZnpEPlTjIpS 4rziIAkBkERGaR5cLyydvmIUB3pFmNcGpIoHmIrhul8BDWYCGnwunw9kcEkiQkqqgTHz0eXJ z33kmXOL2fIU68T0+1YKbPU9kbwj7llij/tcke3fvCKvfpds11E6yfma/WJm96RnzW4J84Qi K15VpLNZarsktEiIJAdr3/z//pHPnP53s/5cKDbsd2a//Ex93bE7IVlJn+OWe/UIy2VouCyZ F7j7o7D0wdgtsReOTb+f5h/celjpkRJLcUaioRZzUXEiAK4h7zaCAwAA Archived-At: Cc: Eve Maler , Thomas Hardjono , "ace@ietf.org" Subject: Re: [Ace] New doc: draft-maler-ace-oauth-uma-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 14:18:32 -0000 Hi Olaf, The need to create profiles is kind of expected (i.e. no need to call it ou= t). This was true also of the SAML2.0 specs where there is a core-spec and then a bunch of profiles (the most oft-used being the Web Browser SSO profile), bindings, etc. This allows the core spec to remain stable, and for new prof= iles (use-case specific) to be developed later. As Eve correctly noted (in previous UMA WG meetings), the UMA permission ti= cket is an opaque structure, so it may not need to be profiled. However, IMO if = there are use-case deployments where multiple ASs are used and Federation is thus= needed, then the permission ticket may need to be profiled (at least for that use-c= ase). The HEART WG is specifically addressing the Healthcare vertical (not IoT pe= r se). They've just started, so it is early days yet. Their site is here: http://openid.net/wg/heart/ /thomas/ ________________________________________ From: Olaf Bergmann [bergmann@tzi.org] Sent: Thursday, March 26, 2015 7:11 AM To: Thomas Hardjono Cc: Eve Maler; ace@ietf.org Subject: Re: [Ace] New doc: draft-maler-ace-oauth-uma-00 Hi Thomas, Thomas Hardjono writes: > In order to use UMA in a given IoT scenario, you will need to create a > profile of UMA that defines the "missing parts", such as the contents > of the permission ticket. This is what the HEART WG is doing in the > OIF. Thank you for the clarification, maybe it would be good to include this as a note or so in draft-maler-ace-oauth-uma. Can you provide a pointer to the HEART WG's docs? Gr=FC=DFe Olaf= From nobody Thu Mar 26 09:33: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 604061A883C; Thu, 26 Mar 2015 09:33:11 -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_20=-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, 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 O-aOxZKQWhBl; Thu, 26 Mar 2015 09:33:04 -0700 (PDT) Received: from out4133-66.mail.aliyun.com (out4133-66.mail.aliyun.com [42.120.133.66]) by ietfa.amsl.com (Postfix) with ESMTP id EE7201A8788; Thu, 26 Mar 2015 09:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1427387580; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=m842CL/OWrmNZUvmTlGyGvcmw8KxpON52t1PgQkN8hA=; b=r7ySFMI1T58JnP/Ip4LlqDWak5WFTqW7HQQyc7r8X7xuqd6YhJWw1JinbD/pdwhP4AfetlX4u8PnyeFRbu6rQJiI7rvaUekTP7+UXQkgayGch0hFMvpcB02rdwBe90M3y2c0aNWc7FmELvN8uZh5CONPr9ozE3Sh63jS1ZRE0EE= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R121e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r46d02002; MF=kepeng.lkp@alibaba-inc.com; PH=DW; RN=3; RT=3; SR=0; Received: from WS-web (kepeng.lkp@alibaba-inc.com[31.133.161.253]) by r46d02001.xy2.aliyun.com at Fri, 27 Mar 2015 00:32:58 +0800 Date: Fri, 27 Mar 2015 00:32:58 +0800 From: "Kepeng Li" To: "core" , "Ace" Message-ID: <5c3d857d-4ce4-404e-8803-e0eb443387f7@alibaba-inc.com> X-Mailer: Alimail-Mailagent revision 2687495 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=ALIBOUNDARY_8544_459d3940_551434ba_23ac4" Archived-At: Cc: Karen O'Donoghue Subject: [Ace] =?utf-8?q?COSE_mailing_list_has_been_created?= X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Kepeng Li List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 16:33:11 -0000 ------=ALIBOUNDARY_8544_459d3940_551434ba_23ac4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello all,FYI that a new mailing list has been created:https://www.ietf.org/ma= ilman/listinfo/cose=0AThis mailing list will be used to discuss COSE (CBOR Obj= ect Signing and Encryption) related topics and working group charter proposals= .Please refer to RFC7049 for more information about CBOR (Concise Binary Objec= t Representation):http://tools.ietf.org/html/rfc7049Please subscribe to the ma= iling list if you have interests.Thanks,Kind RegardsKepeng ------=ALIBOUNDARY_8544_459d3940_551434ba_23ac4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all,

FYI that a new mailing list has been created:
https://www.ietf.org/mailman/listinfo/cose

This mailing list will be used to discuss COSE (C= BOR Object Signing and Encryption) related topics and working group charter pr= oposals.

=
Please refer to RFC7049 for more = information about CBOR (Concise Binary Object Representation):
ht= tp://tools.ietf.org/html/rfc7049

Pleas= e subscribe to the mailing list if you have interests.

Thanks,
Kind Regards<= /div>
Kepeng
------=ALIBOUNDARY_8544_459d3940_551434ba_23ac4-- From nobody Thu Mar 26 11:21:40 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFAA01A90C5; Thu, 26 Mar 2015 11:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Wz-DrtnKoyd; Thu, 26 Mar 2015 11:21: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 D39E11A90BF; Thu, 26 Mar 2015 11:21: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 t2QILSN4013902; Thu, 26 Mar 2015 19:21:28 +0100 (CET) Received: from alma.local (unknown [IPv6:2001:67c:370:152:2439:cd6a:2689:cdb6]) (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 3lCZQH3nkFzCsgK; Thu, 26 Mar 2015 19:21:26 +0100 (CET) Message-ID: <55144E22.9080002@tzi.org> Date: Thu, 26 Mar 2015 13:21:22 -0500 From: Carsten Bormann User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Kepeng Li Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Karen O'Donoghue , core , Ace Subject: [Ace] CBOR mailing list (Re: [core] COSE mailing list has been created) 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, 26 Mar 2015 18:21:38 -0000 At this point I probably should point out that, aside from the COSE mailing list that focuses on porting the JOSE security object spec over to CBOR, there is now also a general CBOR discussion mailing list: cbor@ietf.org https://www.ietf.org/mailman/listinfo/cbor Discussion of issues, usage, implementation, etc, about Concise Binary Object Representation (CBOR), RFC 7049. The discussion over there will probably start about a few tags that people want to have defined, but any other topics about CBOR except COSE itself fits there well. Grüße, Carsten Kepeng Li wrote: > Hello all, > > FYI that a new mailing list has been created: > https://www.ietf.org/mailman/listinfo/cose > > This mailing list will be used to discuss COSE (CBOR Object Signing and > Encryption) related topics and working group charter proposals. > > Please refer to RFC7049 for more information about CBOR (Concise Binary > Object Representation): > http://tools.ietf.org/html/rfc7049 > > Please subscribe to the mailing list if you have interests. [...] From nobody Tue Mar 31 05:42: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 63EFB1A6FEA for ; Tue, 31 Mar 2015 05:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 YwBeE67s9bKq for ; Tue, 31 Mar 2015 05:42:47 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B1AF1A6F0A for ; Tue, 31 Mar 2015 05:42:47 -0700 (PDT) Received: from [192.168.131.145] ([80.92.114.249]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Mh6lB-1YqS9M2F8r-00MNnJ for ; Tue, 31 Mar 2015 14:42:45 +0200 Message-ID: <551A9644.9050608@gmx.net> Date: Tue, 31 Mar 2015 14:42:44 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Ace@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="eaqx7b5RePwRIG2twMXtVbrsIRPPGd5Pw" X-Provags-ID: V03:K0:fNDr1Bt+gafNGdMlvzF+q9IJvbHfgD2csQqVwfJdokKQwfvmQ4P 44kOtPDQUfbds4Jj24uu1lBD/9R8K7FrsIL8FZjlP0qDD3tNxfHVXkNXnvjIMdJaQIA24GP lzPaRemQqp4IzzPkvz7F8Ujj/uWH/7ja30ugdCyJe4vleL+eU8RsVKVYA2L4rcZSOpk8Wi3 3F1a05GuUw+LiqvaNOVZw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [Ace] WGLC for draft-ietf-ace-usecases-03 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 12:42:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --eaqx7b5RePwRIG2twMXtVbrsIRPPGd5Pw Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, at the IETF meeting in Dallas last week we received feedback that the use case document is ready for a working group last call. Hence, we would like to start a WGLC on draft-ietf-ace-usecases-03. This will be a 2-week last call, so it will end on Tuesday, April 14. Please send comments to the list. Thanks! Ciao Hannes & Kepeng --eaqx7b5RePwRIG2twMXtVbrsIRPPGd5Pw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVGpZEAAoJEGhJURNOOiAt+pMH/3uk/7XHxaWTzw7Mz6UXptNi iGpK5n487BUzOffHLmuUNARB18B3bczTzmQZUShN0UNA8hfRHkdX16w/KYKURuQW qnAUdG0/xdfmXaaQqOGe8fkSxF6H/zkvlQ4TxbJ99SZhyhB/SX8EpcEmiRcqGcGD OD/ikVax2Cu18L23aNAT2SkwrIXG+7NERVLp1BL8DocfDADoc5uOVyC1r1Y7tTkz opkXLbdsfFcgEn62hpaZkPTsyFIAFngYgT5lSWQIaPfvbEkVzvXWkUY6GRWNGJlh OW93KhPJ2t79/wuSNJVrA7cM6idSDOtgNFxcpUKS9g+m4rbQWomSrbRiOap1UTk= =L30t -----END PGP SIGNATURE----- --eaqx7b5RePwRIG2twMXtVbrsIRPPGd5Pw--