From nobody Sun Nov 1 05:07: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 6D4161B2A7A for ; Sun, 1 Nov 2015 05:07: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 44m0RrnDL_Im for ; Sun, 1 Nov 2015 05:07:53 -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 DA5AB1B2A76 for ; Sun, 1 Nov 2015 05:07:52 -0800 (PST) X-AuditID: c1b4fb30-f79626d000006adf-6e-56360ea6516b Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 9B.AF.27359.6AE06365; Sun, 1 Nov 2015 14:07:51 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.162]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0248.002; Sun, 1 Nov 2015 14:07:49 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Hannes Tschofenig , Rafa Marin Lopez , "ace@ietf.org" Thread-Topic: [Ace] My comments about draft-seitz-ace-oauth-authz-00 Thread-Index: AQHRE9Q73c2r3tECNUC67YXL64oxC56HqwsA Date: Sun, 1 Nov 2015 13:07:48 +0000 Message-ID: References: <33297FDC-BAA8-402B-80B8-B9CE19991D02@um.es> <5634AE1B.5010609@gmx.net> In-Reply-To: <5634AE1B.5010609@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-ID: <32E272628C1D9D4BA632EDC0B54FCD05@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsUyM2K7ou5yPrMwg9+v2Sy+f+thtli68x6r xYYfP1gdmD0Wb9rP5rFkyU8mj3Mv21gCmKO4bFJSczLLUov07RK4Mua1bGUp+FZRsXN1VgPj i9IuRk4OCQETif7DH5kgbDGJC/fWs3UxcnEICRxmlLjzZQ8rhLOYUaLl7F12kCo2AReJBw2P wDpEBAoltp1dAWYLCzhLnL+8DKiGAyjuInFrgj5EiZHE+ccrWUBsFgEVifOrv7GAlPAKWEh8 XRwEEhYSCJW4uWsp2BROAXWJ041HWUFsRqB7vp9aAxZnFhCXuPVkPtSdAhJL9pxnhrBFJV4+ /gdWLyqgJ7HyehMbRFxJYtHtz0wgq5gFNCXW79KHMK0l+g5xQkxUlJjS/RDsJ14BQYmTM5+w TGAUn4Vk2SyE5lkIzbOQNM9C0ryAkXUVo2hxanFSbrqRkV5qUWZycXF+nl5easkmRmDcHdzy 22AH48vnjocYBTgYlXh4N/CbhgmxJpYVV+YeYpTgYFYS4b2yHijEm5JYWZValB9fVJqTWnyI UZqDRUmct5npQaiQQHpiSWp2ampBahFMlomDU6qB0eXiMSWmrQxlUXP/rdj24PJx32ObNn+d wfX3gdT6GR0qzVUMAvPZ3Zbd0a/+WLMthL/BW+Xm8mnFsb4XnwvcXvWqSN3XYKmv7KaEmyta Duj9UFk8YWealmLKney5jVz3btUe2TLtceiPQNWOZRuC/sasr6x82Mfy8mRlxddVyQ9TZ0X7 NE97I6nEUpyRaKjFXFScCAACWsuAtwIAAA== Archived-At: Subject: Re: [Ace] My comments about draft-seitz-ace-oauth-authz-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2015 13:07:56 -0000 SGkgUmFmYSwNCg0KVGhhbmtzIGZvciBnb29kIGNvbW1lbnRzLiBUaGVyZSB3ZXJlIHNvbWUgb3V0 c3RhbmRpbmcgcXVlc3Rpb25zIEhhbm5lcw0KZGlkbuKAmXQgcmVwbHkgdG8sIGlubGluZS4NCg0K T24gMjAxNS0xMC0zMSAyMTowMywgIkhhbm5lcyBUc2Nob2ZlbmlnIiA8aGFubmVzLnRzY2hvZmVu aWdAZ214Lm5ldD4gd3JvdGU6DQoNCj5IaSBSYWZhLA0KPg0KPnRoYW5rcyBmb3IgeW91IHJldmll dy4gU2luY2UgeW91IGhhdmUgY29udHJpYnV0ZWQgdGhlIEVBUC1iYXNlZCBzb2x1dGlvbg0KPnRv IHRoZSBncm91cCBJIHdhcyBvYnZpb3VzbHkgdmVyeSBpbnRlcmVzdGVkIHRvIGhlYXIgeW91ciBv cGluaW9uLg0KPg0KPlJlc3BvbnNlcyBpbmxpbmU6DQo+DQo+T24gMTAvMzAvMjAxNSAwMjo0NiBQ TSwgUmFmYSBNYXJpbiBMb3BleiB3cm90ZToNCj4+IERlYXIgYXV0aG9ycywgYWxsOg0KPj4gDQo+ PiBIZXJlIHlvdSBjYW4gZmluZCBteSByZXZpZXcgYWJvdXQgZHJhZnQtc2VpdHotYWNlLW9hdXRo LWF1dGh6LTAwLg0KPj4gDQo+PiBUaGUgZG9jdW1lbnQgaXMgdmVyeSBkZXRhaWxlZCwgd2hpY2gg aGVscHMgdG8gdW5kZXJzdGFuZCB0aGUNCj4+IHByb3Bvc2FsLiBJbiBteSBvcGluaW9uLCB1c2lu ZyBhIHdlbGwta25vd24gcHJvdG9jb2wgc3VjaCBhcyBPQXV0aA0KPj4gMi4wIHdoZXJlIG1hbnkg cGVvcGxlIGFyZSB3b3JraW5nIGFuZCBoYXZlIHdvcmtlZCBnaXZlcyBtYXR1cml0eSBhbmQNCj4+ IG1ha2VzIGNvbXByZWhlbnNpYmxlIHRoZSBwcm9wb3NhbCB0byBhIGJyb2FkZXIgYXVkaWVuY2Uu IEkgYWxzbyB0aGluaw0KPj4gaXQgd291bGQgYmUgZ29vZCB0byBoYXZlIHNvbWUgcGVyZm9ybWFu Y2UgZGF0YSAoaWYgYXZhaWxhYmxlKSBzdWNoIGFzDQo+PiBtZXNzYWdlIHNpemUsIHByb2Nlc3Np bmcgdGltZSAsIGV0Y+KApiAuIEluIGFueSBjYXNlLCBJIGJlbGlldmUgdGhlDQo+PiB1c2FnZSBv ZiBPQXV0aCAyLjAgaXMgYSByaWdodCBhbmQgcmVhc29uYWJsZSBwYXRoIGZvciBhY2hpZXZpbmcg YW4NCj4+IEFDRSBzb2x1dGlvbi4NCj4NCj5UaGFua3MgZm9yIHRoZSBwb3NpdGl2ZSBmZWVkYmFj ay4NCj4NCj5SZWdhcmRpbmcgdGhlIHBlcmZvcm1hbmNlIGRhdGEgd2UgY2FuIHB1dCBzb21lIGZp Z3VyZXMgdG9nZXRoZXIgYmFzZWQgb24NCj53aGF0IHdlIGhhdmUgYmVlbiBwbGF5aW5nIHdpdGgu IEluIGZhY3QsIHdlIChFcmlrL1NhbXVlbCBmcm9tIE5leHVzDQo+VGVjaG5vbG9neSBhbmQgQVJN KSBhcmUgZ29pbmcgdG8gc2hvdyBhIGRlbW8gb2YgT0F1dGggZm9yIGEgaG9tZQ0KPmF1dG9tYXRp b24gc2NlbmFyaW8gYXQgdGhlIHVwY29taW5nIEFSTSBUZWNoQ29uIGV2ZW50LiBGb3JnZXJvY2sg d2lsbA0KPmFsc28gc2hvdyBPQXV0aC1iYXNlZCBzY2VuYXJpb3MgYXQgdGhlIHNhbWUgZXZlbnQu DQo+DQo+V2hhdCBpcyBkaWZmaWN1bHQgd2l0aCB0aGUgcGVyZm9ybWFuY2UgZGF0YSBpcyB0aGF0 IGl0IGRlcGVuZHMgYSBiaXQgb24NCj50aGUgYXNzdW1wdGlvbnMgbWFkZSBmb3IgdGhlIHNjZW5h cmlvLiBGb3IgZXhhbXBsZSwgaW4gb3VyIGNhc2Ugd2UgYXJlDQo+dXNpbmcgQmx1ZXRvb3RoIFNt YXJ0IHdpdGggYSBjdXN0b20gQkxFIHNlcnZpY2UgZm9yIHRoZSBjb21tdW5pY2F0aW9uDQo+YmV0 d2VlbiBhbiBBbmRyb2lkIHBob25lIGFuZCBhbiBJb1QgZGV2aWNlLiBUaGUgY3VzdG9tIEJMRSBz ZXJ2aWNlIHVzZXMNCj5KT1NFLCB3aGljaCBpcyBxdWl0ZSBuYXR1cmFsbHkgbW9yZSBoZWF2eSB0 aGFuIHRoZSBDT1NFIHNvbHV0aW9uDQo+Y3VycmVudGx5IGJlaW5nIGRldmVsb3BlZC4gV2hpbGUg d2UgZGlkbid0IHNlZSBwcm9ibGVtcyB3aXRoIHRoZSBKT1NFDQo+c29sdXRpb24gc28gZmFyIHdl IGNvdWxkIHJlcGxhY2UgaXQgd2l0aCBDT1NFIHJlZHVjaW5nIHRoZSBudW1iZXIgb2YNCj5iaXRz IG9uIHRoZSB3aXJlLiBGb3IgdGhlIGRhdGEgZXhjaGFuZ2VkIGJldHdlZW4gdGhlIHBob25lIGFu ZCB0aGUNCj5hdXRob3JpemF0aW9uIHNlcnZlciBpdCBhZ2FpbiBkZXBlbmRzIHdoYXQgdXNlciBl eHBlcmllbmNlIGlzIG9mZmVyZWQNCj5hbmQgd2hhdCBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20g aXMgdXRpbGl6ZWQuDQo+DQo+SW4gYSBudXRzaGVsbCwgdGhlcmUgaXMgbW9yZSB0aGFuIGp1c3Qg Y291bnRpbmcgYml0cyBvbiB0aGUgd2lyZSB0aGVyZS4NCj4NCj4+IA0KPj4gSGVyZSBzb21lIG1v cmUgZGV0YWlsIGNvbW1lbnRzL3F1ZXN0aW9uczoNCj4+IA0KPj4gSW4gcGFnZSAzOg0KPj4gDQo+ PiAiVGhpcyBtZW1vIGRlc2NyaWJlcyBob3cgdG8gcmUtdXNlIE9BdXRoIDIuMCBbUkZDNjc0OV0g dG8gZXh0ZW5kDQo+PiBhdXRob3JpemF0aW9uIHRvIEludGVybmV0IG9mIFRoaW5ncyBkZXZpY2Vz IHdpdGggZGlmZmVyZW50IGtpbmRzIG9mDQo+PiBjb25zdHJhaW5lZG5lc3MuICBBdCB0aGUgdGlt ZSBvZiB3cml0aW5nIE9BdXRoIDIuMCBpcyBhbHJlYWR5IHVzZWQNCj4+IHdpdGggY2VydGFpbiB0 eXBlcyBvZiBJb1QgZGV2aWNlcyBhbmQgdGhpcyBkb2N1bWVudCB3aWxsIHByb3ZpZGUuLi4iDQo+ PiANCj4+IFtSYWZhXSAgV2hhdCB0eXBlcyBvZiBJb1QgZGV2aWNlcyBhbHJlYWR5IHVzZSBPQXV0 aCAyLjA/IEEgcmVmZXJlbmNlDQo+PiB3aXRoIHRoaXMgdXNhZ2Ugb2YgT0F1dGggMi4wIHdvdWxk IGJlIGhlbHBmdWwuDQo+PiANCj4NCj5UaGVyZSBhcmUgYSBudW1iZXIgb2YgZGlmZmVyZW50IGNv bW11bmljYXRpb24gc2NlbmFyaW9zLCBhcyBvdXRsaW5lZCBpbg0KPnRoZSByZWNlbnQgSVNPQyBw dWJsaWNhdGlvbjoNCj5odHRwOi8vd3d3LmludGVybmV0c29jaWV0eS5vcmcvc2l0ZXMvZGVmYXVs dC9maWxlcy9JU09DLUlvVC1PdmVydmlldy0yMDE1MQ0KPjAyMi5wZGYNCj4NCj5Gb3IgdGhlICJC YWNrLUVuZCBEYXRhLVNoYXJpbmcgTW9kZWwiLCBkZXNjcmliZWQgb24gcGFnZSAxNiwgT0F1dGgg aXMNCj51c2VkIHF1aXRlIGZyZXF1ZW50bHkuIFRoaXMgaXMgYWxzbyBwcmV0dHkgcmVhc29uYWJs ZSBzaW5jZSBtYW55DQo+Y29tcGFuaWVzIHNlZWsgdG8gc2hhcmUgZGF0YSB0aGV5IGNvbGxlY3Qg ZnJvbSBJb1QgZGV2aWNlcyAod2l0aCB0aGUNCj5wZXJtaXNzaW9uIG9mIHRoZSB1c2VyKS4gSGVy ZSBpcyBhbiBleGFtcGxlIGZyb20gdGhlIHZlaGljbGUgZW52aXJvbm1lbnQ6DQo+aHR0cHM6Ly9k ZXZlbG9wZXIuY2Fydm95YW50LmNvbS9pby1kb2NzDQo+DQo+SSBoYXZlIHNoYXJlZCBvdGhlciBl eGFtcGxlcyBmcm9tIHRoZSBmaXRuZXNzIC8gd2VhcmFibGUgc2VjdG9yDQo+cHJldmlvdXNseS4N Cj4NCj5BbHNvIGZvciBkZXZpY2VzIHRoYXQgaGF2ZSBhIHVzZXIgaW50ZXJmYWNlIGJ1dCBsaW1p dGVkIGlucHV0DQo+Y2FwYWJpbGl0aWVzIE9BdXRoIGhhcyBiZWVuIHVzZWQuIEhlcmUgYXJlIHR3 byBleGFtcGxlczoNCj5odHRwczovL2RldmVsb3BlcnMuZmFjZWJvb2suY29tL2RvY3MvZmFjZWJv b2stbG9naW4vZm9yLWRldmljZXMNCj5odHRwczovL2RldmVsb3BlcnMuZ29vZ2xlLmNvbS95b3V0 dWJlL3YzL2d1aWRlcy9hdXRoL2RldmljZXMNCj4NCj5UaGlzICJEZXZpY2UtdG8tQ2xvdWQgQ29t bXVuaWNhdGlvbnMiIHNjZW5hcmlvIGlzIGRlc2NyaWJlZCBvbiBwYWdlIDE0DQo+aW4gdGhlIElT T0MgcGFwZXIuDQo+DQo+SW4gZ2VuZXJhbCwgaW4gdGVybXMgb2YgZGVwbG95bWVudCBpdCBpcyBt b3JlIGNvbW1vbiBmb3IgSW9UIGRldmljZXMgdG8NCj5jb21tdW5pY2F0ZSB3aXRoIHNvbWUgZ2F0 ZXdheSBvciBhIGNsb3VkLWJhc2VkIHNlcnZpY2UgcmF0aGVyIHRoYW4NCj5oYXZpbmcgSW9UIGRl dmljZXMgY29tbXVuaWNhdGUgZGlyZWN0bHkgd2l0aCBlYWNoIG90aGVyLg0KPg0KPj4gDQo+PiAi RmlndXJlIDE6IE92ZXJ2aWV3IG9mIHRoZSBiYXNpYyBwcm90b2NvbCBmbG93DQo+PiANCj4+IFJl cXVlc3RpbmcgYW4gQWNjZXNzIFRva2VuIChBKTrigJ0NCj4+IA0KPj4gW1JhZmFdIElzIHRoZXJl IGFueSBhc3N1bXB0aW9uIGZvciB0aGUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGhlcmU/DQo+DQo+ WWVzLCB0aGUgY2xpZW50IGhhcyB0byBiZSBhdXRoZW50aWNhdGVkIHByaW9yIHRvIGdldCBhbiBh Y2Nlc3MgdG9rZW4uDQo+VGhlcmUgaXMgYWxzbyB0aGUgY29uc2VudCBhc3BlY3QgaGVyZSwgd2hp Y2ggbWF5IHJlcXVpcmUgYXV0aGVudGljYXRpb24NCj5vZiBhIGh1bWFuLg0KPg0KPlRoZSBjbGll bnQgY3JlZGVudGlhbHMgYXJlIHByb3Zpc2lvbmVkIHRvIHRoZSBkZXZpY2UgZWl0aGVyIHVwZnJv bnQgKGZvcg0KPmV4YW1wbGUgZHVyaW5nIG1hbnVmYWN0dXJpbmcpIG9yIHRoZSBjbGllbnQgaXMg cmVnaXN0ZXJlZCBkeW5hbWljYWxseQ0KPih3aGljaCBpcyB3aGF0IHdlIGhhdmUgdGhlIGR5bmFt aWMgY2xpZW50IHJlZ2lzdHJhdGlvbiBmb3IpLg0KPg0KPldoZW4gd2Ugd3JvdGUgdGhlIFVNQSBm b3IgSW9UIGRvY3VtZW50IHRoZXJlIHdlIGFsc28gaGFkIHNwb2tlIGFib3V0IHRoZQ0KPm5lZWQg dG8gY29uc2lkZXIgY2FzZXMgd2hlcmUgdGhlIGNvbnNlbnQgY29tZXMgdXAtZnJvbnQuIEZvciB0 aGlzDQo+ZG9jdW1lbnQgd2UgZGlkbid0IHdhbnQgdG8gZ28gaW50byB0aGF0IGxldmVsIG9mIGRl dGFpbCBzaW5jZSB0aGVzZQ0KPnNjZW5hcmlvcyBhcmUgYSBiaXQgbW9yZSBzb3BoaXN0aWNhdGVk IGFuZCB3ZSBhbHJlYWR5IGhhdmUgdGhpcyBvdGhlcg0KPmRvY3VtZW50IGF2YWlsYWJsZS4NCj4N Cj5Gb3IgdGhpcyB3cml0ZS11cCB3ZSBoYXZlIHRha2VuIHRoZSBhcHByb2FjaCB0aGF0IHRoZSBy ZWFkZXIga25vd3MgdmVyeQ0KPmxpdHRsZSBhYm91dCB0aGUgT0F1dGggbGFuZHNjYXBlLg0KPg0K Pg0KPg0KPg0KPg0KPj4gDQo+PiAiVGhlIC90b2tlbiByZXNvdXJjZSAoY2FsbGVkICJlbmRwb2lu dCIgaW4gT0F1dGggMi4wKSwgZGVmaW5lZCBpbg0KPj4gU2VjdGlvbiAzLjIgb2YgW1JGQzY3NDld LCBpcyB1c2VkIGJ5IHRoZSBjbGllbnQgdG8gb2J0YWluIGFuIGFjY2Vzcw0KPj4gdG9rZW4uICBS ZXF1ZXN0cyBzZW50IHRvIHRoZSAvdG9rZW4gcmVzb3VyY2UgdXNlIHRoZSBIVFRQIFBPU1QNCj4+ IG1ldGhvZOKApiINCj4+IA0KPj4gW1JhZmFdIE1tbW1t4oCmIGlmIGNsaWVudCBpcyBjb25zdHJh aW5lZCDigKYgd2lsbCBpdCB1c2UgSFRUUCBQT1NUPw0KPg0KPkluIHRoaXMgZG9jdW1lbnQgd2Ug b2ZmZXIgdGhlIGNob2ljZSB0byBlaXRoZXIgdXNlIEhUVFAgb3IgQ29BUC4NCj5XZSBhcmUgZXhw bG9yaW5nIHRoZSB1c2Ugb2YgSFRUUC8yIGFuZCBRVUlDLg0KPg0KPkJ1dCBrZWVwIGluIG1pbmQg dGhhdCBpbiBtb3N0IHNjZW5hcmlvcyBub3QgZXZlcnl0aGluZyBpcyBjb25zdHJhaW5lZC4NCj5G b3IgZXhhbXBsZSwgeW91IG1pZ2h0IGhhdmUgYSBwZXJzb24gaW4gYSBzbWFydCBob21lIHVzaW5n IGhpcyBwaG9uZSBvcg0KPnRhYmxlIHRvIGNvbnRyb2wgbGlnaHRzIGFuZCBvdGhlciBkZXZpY2Vz LiBUaGVpciBwaG9uZSBjYW4gdmVyeSB3ZWxsIHVzZQ0KPkhUVFAgd2l0aG91dCBhbnkgcHJvYmxl bXMuDQo+DQo+DQo+PiANCj4+IOKAnDYuMSBDbGllbnQgYW5kIFJlc291cmNlIFNlcnZlciBhcmUg T2ZmbGluZSINCj4+IA0KPj4gW1JhZmFdIEkgcmVhbGl6ZSB0aGF0IG9mZmxpbmUgaXMgc29tZXRp bWVzIGNvbmZ1c2luZy4gY2xpZW50IGFuZA0KPj4gcmVzb3VyY2Ugc2VydmVyIGNhbiBjb21tdW5p Y2F0ZSBlYWNoIG90aGVyLiBUaGUgQVMgaXMgb2ZmbGluZSBzaW5jZQ0KPj4gaXQgaXMgbm90IHJl YWNoYWJsZS4gQnV0IGFueXdheSwgdGhpcyBpcyBhIG1pbm9yIHRoaW5nLg0KPg0KPlRoYXQncyBh IGdvb2QgcG9pbnQsIHdoaWNoIHdlIG1heSBuZWVkIHRvIGRlc2NyaWJlIGEgYml0IG1vcmUuDQo+ V2l0aCB0aGUgcmVxdWlyZW1lbnRzIG91dGxpbmVkIGluIG91ciBncm91cCBpdCBpcyBvYnZpb3Vz bHkgbm90IHBvc3NpYmxlDQo+dG8gaGF2ZSBhIHNjZW5hcmlvIHdoZXJlIGV2ZXJ5dGhpbmcgaXMg ZnVsbHkgb2ZmbGluZSBhbmQgd2Ugd291bGRuJ3QNCj5yZWFsbHkgYmUgdGFsa2luZyBhYm91dCBJ b1QgdGhlbiBhbnl3YXkgKGJ1dCByYXRoZXIgYWJvdXQgZW1iZWRkZWQNCj5kZXZpY2VzKS4NCj4N Cj5IZXJlIHRoZSBkaXN0aW5jdGlvbiBpcyB3aGV0aGVyIHRoZSByZXNvdXJjZSBzZXJ2ZXIgaXMg YWJsZSB0byBjb250YWN0DQo+dGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGF0IHRoZSB0aW1lIG9m IHRoZSByZXNvdXJjZSByZXF1ZXN0LiBUaGUgY2xpZW50DQo+c3RpbGwgaGFzIHRvIGJlIGFibGUg dG8gb2J0YWluIHRoZSBhY2Nlc3MgdG9rZW4gYXQgc29tZSBwb2ludCBpbiB0aW1lLg0KPlRoZXJl IGlzLCBvZiBjb3Vyc2UsIGFsc28gYSB0cmFkZW9mZiBiZXR3ZWVuIHRoZSBhYmlsaXR5IHRvIHJl dm9rZQ0KPmdyYW50ZWQgcGVybWlzc2lvbnMgaW4gcmVhbC10aW1lIHZzLiBiZWluZyBvZmZsaW5l Lg0KPg0KPg0KPg0KPg0KPj4gDQo+PiAiQTogVGhlIGNsaWVudCBmaXJzdCBnZW5lcmF0ZXMgYSBw dWJsaWMtcHJpdmF0ZSBrZXkgcGFpciB1c2VkIGZvcg0KPj4gY29tbXVuaWNhdGlvbiBzZWN1cml0 eSB3aXRoIHRoZSBSUy4iDQo+PiANCj4+IFtSYWZhXSBJbiB0aGUgc2FtZSBzZWN0aW9uIDYuMSwg eW91IGRlc2NyaWJlIHRoZSBjYXNlIHdoZXJlIGNsaWVudA0KPj4gYW5kIHJlc291cmNlIHNlcnZl ciBjYW5ub3QgY29udGFjdCB0aGUgQVMuIEhvd2V2ZXIgeW91IGRlc2NyaWJlIHRoZQ0KPj4gY29t bXVuaWNhdGlvbiB3aXRoIHRoZSBBUy4gVGhpcyBtaWdodCByZXN1bHQgY29uZnVzaW5nIGlzIHNo b3duLg0KPj4gUGVyaGFwcyB0aGUgaW50ZXJhY3Rpb24gd2l0aCB0aGUgQVMgc2hvdWxkIGJlIHBs YWNlZCBvdXQgb2YgdGhpcw0KPj4gc2VjdGlvbi4NCj4NCj5JIGd1ZXNzIHRoaXMgaXMgdGhlIHNh bWUgaXNzdWUgYXMgd2l0aCB0aGUgcHJldmlvdXMgY29tbWVudC4gSSBiZWxpZXZlDQo+d2UgbmVl ZCB0byBkZXNjcmliZSBtb3JlIGNsZWFybHkgd2hhdCB3ZSBtZWFuIGJ5IG9mZmxpbmUuIEkgdGhp bmsgdGhlDQo+cXVhbGlmaWNhdGlvbiAib2ZmbGluZSBkdXJpbmcgdGhlIHRpbWUgb2YgdGhlIHJl c291cmNlIGFjY2VzcyIgbWlnaHQNCj5kZXNjcmliZSBpdCBiZXR0ZXIuDQo+DQo+PiANCj4+IFBh Z2UgMTYNCj4+IA0KPj4gIkZpZ3VyZSA1OiBBY2Nlc3MgVG9rZW4gaW5jbHVkaW5nIFB1YmxpYyBL ZXkgb2YgdGhlIENsaWVudC4NCj4+IA0KPj4gTWVzc2FnZXMgQyBhbmQgRiBhcmUgc2hvd24gaW4g RmlndXJlIDYgLSBGaWd1cmUgNy4NCj4+IA0KPj4gQzogVGhlIGNsaWVudCB0aGVuIHNlbmRzIHRo ZSBQb1AgdG9rZW4gdG8gdGhlIC9hdXRoei1pbmZvIHJlc291cmNlIGF0DQo+PiB0aGUgUlMuICBU aGlzIGlzIGEgcGxhaW4gQ29BUCByZXF1ZXN0LCBpLmUuIG5vIERUTFMvT1NDT0FQIGJldHdlZW4N Cj4+IGNsaWVudCBhbmQgUlMsIHNpbmNlIHRoZSB0b2tlbiBpcyBpbnRlZ3JpdHkgcHJvdGVjdGVk IGJldHdlZW4gQVMgYW5kDQo+PiBSUy4iDQo+PiANCj4+IFtSYWZhXSBJIHRoaW5rIEkgYW0gbWlz c2luZyBzb21ldGhpbmcgaGVyZS4gQSBQb1AgdG9rZW4gcHJvdmVzIHRoYXQNCj4+IHRoZSBjbGll bnQga25vd3MgYSBrZXkgKGtleSBjb25maXJtYXRpb24pLiBCdXQgdGhlIHJlYXNvbiB5b3UgZ2l2 ZQ0KPj4gZm9yIG5vdCB1c2luZyBEVExTL09TQ09BUCBpcyB0aGF0IHRoZSB0b2tlbiBpcyBpbnRl Z3JpdHkgcHJvdGVjdGVkIEFTDQo+PiBhbmQgUlMuIFRoZSBjbGllbnQgc2hvdWxkIHByb3ZlIHRo YXQgaXQgb3ducyB0aGUga2V5IGFueXdheSwgbm8/DQoNCltHU10gWWVzLCB5b3UgYXJlIHJpZ2h0 IHRoYXQgdGhlIGNsaWVudCBuZWVkcyB0byBwcm92ZSBwb3NzZXNzaW9uIG9mIHRoZQ0Ka2V5IGlu IHRoZSBQb1AgdG9rZW4sIGJ1dCB0aGUgUG9QIHRva2VuIHByb3Zpc2lvbmluZyBuZWVkcyBub3Qg YmUNCmludGVncml0eSBwcm90ZWN0ZWQgYnkgdGhlIGNsaWVudC4gSXQgc3VmZmljZXMgaW4gcHJp bmNpcGxlIHRoYXQgaXQgaXMNCnNpZ25lZCBvciBNQUNlZCBieSB0aGUgQVMgKHlvdSBjb3VsZCBh bHNvIGNvbnNpZGVyIHJlcGxheSBwcm90ZWN0aW9uKS4gVGhlDQpwcm9vZiBvZiBwb3NzZXNzaW9u IHN0ZXAgY29tZXMgaW4gdGhlIGFjY2VzcyByZXF1ZXN0LCB3aGljaCBtYXkgYmUNCnNlcGFyYXRl ZCBvdXQgZnJvbSB0aGUgdG9rZW4gcHJvdmlzaW9uaW5nIHN0ZXAsIHJlbGF0aW5nIHRvIHlvdXIg bmV4dA0KcXVlc3Rpb24uDQoNCj4+IA0KPj4gIlRoZSBSUyB2ZXJpZmllcyB0aGF0IHRoZSBQb1Ag dG9rZW4gd2FzIGNyZWF0ZWQgYnkgYSBrbm93biBhbmQNCj4+IHRydXN0ZWQgQVMsIGlzIHZhbGlk LCBhbmQgcmVzcG9uZHMgdG8gdGhlIGNsaWVudC4gVGhlIFJTIGNhY2hlcyB0aGUNCj4+IHNlY3Vy aXR5IGNvbnRleHQgdG9nZXRoZXIgd2l0aCBhdXRob3JpemF0aW9uIGluZm9ybWF0aW9uIGFib3V0 IHRoaXMNCj4+IGNsaWVudCBjb250YWluZWQgaW4gdGhlIFBvUCB0b2tlbi4iDQo+PiANCj4+IFtS YWZhXSBUaGlzIGlzIHJlbGF0ZWQgdG8gbXkgcHJldmlvdXMgY29tbWVudC4gSXMgaXQgcG9zc2li bGUgZm9yIGFuDQo+PiBhdHRhY2tlciB0byByZXBseSB0aGUgUG9QIHRva2VuPyBJdCBzaG91bGQg bm90IGR1ZSB0byBQb1AgdG9rZW4NCj4+IG5hdHVyZSBidXQgbm90aGluZyBpcyBtZW50aW9uZWQg YWJvdXQgaXQsIGp1c3QgdGhlIHZlcmlmaWNhdGlvbiB0aGF0DQo+PiBpdCB3YXMgY3JlYXRlZCBi eSBhIHRydXN0ZWQgQVMuIE1heWJlIG15IHVuZGVyc3RhbmRpbmcgb2YgUG9QIHRva2VuDQo+PiBp cyB3cm9uZy4NCj4+IA0KDQpbR1NdIEFzIHlvdSB3cml0ZSwgYSBzZWNvbmQgUE9TVCB1c2luZyB0 aGUgc2FtZSBQb1AgdG9rZW4gd291bGQgbm90IGxlYWQNCnRvIGEgdmlvbGF0aW9uIG9mIHByaXZp bGVnZXMsIGJ1dCBtYXkgYmUgdXNlZCBpbiBhIERvUyBhdHRhY2sgd2hpY2ggaXMgb25lDQpyZWFz b24gdG8gaGF2ZSBzb21lIGZvcm0gb2YgcmVwbGF5IHByb3RlY3Rpb24uIEp1c3QgdG8gYmUgY2xl YXIsIHRoZQ0KaW50ZW50IGhlcmUgaXMgdG8gbWluaW1pemUgdGhlIHRyYW5zcG9ydCBzbyB0aGF0 IHRoZSBQb1AgdG9rZW4gaXMNCnRyYW5zcG9ydGVkIG9uY2UgYnV0IG1heSBiZSB1c2VkIG11bHRp cGxlIHRpbWVzIChpZiBzdXBwb3J0ZWQgYnkgdGhlDQpjbGFpbXMpLg0KDQo+DQo+VGhpcyBpcyBh IHZlcnkgZ29vZCBjb21tZW50IHNpbmNlIEkgaGFkIHRvIGZpZ2h0IHdpdGggdGhpcyBpc3N1ZSBh cw0KPndlbGwuIEhlcmUgaXMgdGhlIGlzc3VlLiBJZiB5b3UgbG9vayBhdCB0aGUgd2F5IGhvdyB0 aGluZ3Mgd29yayBpbiBIVFRQDQo+dGhlbiB5b3Ugd291bGQgaW5jbHVkZSB0aGUgdG9rZW4gd2l0 aCB0aGUgKGluaXRpYWwpIHJlc291cmNlIHJlcXVlc3QuDQo+DQo+V2UgaWRlYWxseSB3YW50IHRv IGhhdmUgdGhlIHNhbWUgcGF0dGVybiBhbHNvIGluIENvQVAgYW5kIENvQVAgaXMNCj5zdXBwb3Nl ZCB0byBiZSBkZXNpZ25lZCBsaWtlIEhUVFAuIEhvd2V2ZXIsIGFzIGl0IHR1cm5zIG91dCB0aGVy ZSBhcmUNCj5zb21lIGlzc3VlcyBpbiB0ZXJtcyBvZiBzaXplIGxpbWl0YXRpb25zLiBIZW5jZSwg aXQgbWF5IGJlIG5lY2Vzc2FyeSB0bw0KPnNlbmQgdGhlIHRva2VuIHRvIGEgc3BlY2lhbCBhdXRo b3JpemF0aW9uIGVuZHBvaW50IGZpcnN0IGJlZm9yZSBtYWtpbmcNCj50aGUgcmVzb3VyY2UgcmVx dWVzdC4gV2hpbGUgSSBkbyBub3QgcXVpdGUgbGlrZSB0aGF0IGRlc2lnbiBJIGJlbGlldmUgaXQN Cj5pcyBhIHNpZGUtZWZmZWN0IG9mIHRoZSBDb0FQIGRlc2lnbi4NCg0KW0dTXSBKdXN0IHRvIGFk ZCB0byB3aGF0IEhhbm5lcyB3cm90ZSwgd2UgY29uc2lkZXIgdGhlIG9wdGltaXphdGlvbiBvZg0K Y29tYmluaW5nIHRva2VuIHByb3Zpc2lvbmluZyB3aXRoIGFjY2VzcyByZXF1ZXN0IHRvIFJTIGlu IEFwcGVuZGl4IEIuDQoNCkfDtnJhbg0KDQo+DQo+PiANCj4+ICI2LjMuICBUb2tlbiBJbnRyb3Nw ZWN0aW9uIHdpdGggYW4gT2ZmbGluZSBDbGllbnQiDQo+PiANCj4+IFtSYWZhXSBBbHRob3VnaCB0 b2tlbiBpbnRyb3NwZWN0aW9uIG1heSBiZSBhbiBpbnRlcmVzdGluZyBmZWF0dXJlLCBJDQo+PiBh bSB0aGlua2luZyB0aGF0IHNlbmRpbmcgYWRkaXRpb25hbCBtZXNzYWdlcyBmcm9tIHRoZSBSUyB0 byB0aGUgQVMgaXMNCj4+IG5vdCBnb29kIHdoZW4gUlMgaXMgY29uc3RyYWluZWQuIEkgdW5kZXJz dGFuZCBpdCBpcyBhIHRyYWRlb2ZmDQo+PiBiZXR3ZWVuIOKAnGF1dGhvcml6YXRpb24gZnJlc2hu ZXNz4oCdIHZzIGFkZGl0aW9uYWwgc2lnbmFsaW5nLg0KPg0KPlllcywgdGhlcmUgaXMgYSB0cmFk ZW9mZiBoZXJlIGFuZCB3ZSBhbGxvdyB0aG9zZSB3aG8gZGVwbG95IHRoZSBwcm90b2NvbA0KPnRv IGRlY2lkZSB0aGVtc2VsdmVzIGFib3V0IHRoaXMgdHJhZGVvZmYuDQo+DQo+DQo+PiANCj4+IFBh Z2UgMjU6ICJJbiBjYXNlIDIuLCB0aGUgUlMgZG9lcyBub3QgbmVlZCB0byByZWNlaXZlIGFueSBt ZXNzYWdlDQo+PiBmcm9tIHRoZSBjbGllbnQsIg0KPj4gDQo+PiBbUmFmYV0gSSBkbyBub3QgdW5k ZXJzdGFuZCB3aHkgdGhlIFJTIGRvZXMgbm90IG5lZWQgdG8gcmVjZWl2ZSBhbnkNCj4+IG1lc3Nh Z2UgZnJvbSB0aGUgY2xpZW504oCmIGNvdWxkIHlvdSBjbGFyaWZ5Pw0KPg0KPkkgbGV0IEdvZXJh biByZXNwb25kIHRvIHRoaXMgY29tbWVudCBzaW5jZSBpdCByZWxhdGVzIHRvIHRoZSBwdWJsaXNo DQo+c3Vic2NyaWJlIG1vZGVsLg0KPg0KPkNpYW8NCj5IYW5uZXMNCj4NCj4+IA0KPj4gSG9wZSB0 aGlzIGhlbHBzLg0KPj4gDQo+PiBCZXN0IFJlZ2FyZHMuDQo+PiANCj4+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gUmFmYWVsIE1hcmluDQo+ PiBMb3BleiwgUGhEIERlcHQuIEluZm9ybWF0aW9uIGFuZCBDb21tdW5pY2F0aW9ucyBFbmdpbmVl cmluZyAoRElJQykNCj4+IEZhY3VsdHkgb2YgQ29tcHV0ZXIgU2NpZW5jZS1Vbml2ZXJzaXR5IG9m IE11cmNpYSAzMDEwMCBNdXJjaWEgLQ0KPj4gU3BhaW4gVGVsZjogKzM0ODY4ODg4NTAxIEZheDog KzM0ODY4ODg0MTUxIGUtbWFpbDogcmFmYUB1bS5lcw0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gDQo+PiANCj4+IA0KPj4gDQo+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBBY2UgbWFp bGluZyBsaXN0DQo+PiBBY2VAaWV0Zi5vcmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9hY2UNCj4+IA0KPg0KDQo= From nobody Sun Nov 1 12:04: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 2AC6A1B2D68 for ; Sun, 1 Nov 2015 12:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 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, 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 3erpOiueaMbE for ; Sun, 1 Nov 2015 12:04:05 -0800 (PST) Received: from xenon23.um.es (xenon23.um.es [155.54.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id 74E101B2D61 for ; Sun, 1 Nov 2015 12:04:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon23.um.es (Postfix) with ESMTP id 3FA60411B; Sun, 1 Nov 2015 21:04:04 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon23.um.es Received: from xenon23.um.es ([127.0.0.1]) by localhost (xenon23.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ZqeaZmlKsOi9; Sun, 1 Nov 2015 21:04:04 +0100 (CET) Received: from [192.168.1.35] (130.Red-83-38-57.dynamicIP.rima-tde.net [83.38.57.130]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon23.um.es (Postfix) with ESMTPSA id 8DE383974; Sun, 1 Nov 2015 21:04:01 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Rafa Marin Lopez In-Reply-To: <2D596355-C89B-4162-943C-E049B301D83F@nexusgroup.com> Date: Sun, 1 Nov 2015 21:04:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <33297FDC-BAA8-402B-80B8-B9CE19991D02@um.es> <2D596355-C89B-4162-943C-E049B301D83F@nexusgroup.com> To: =?windows-1252?Q?Erik_Wahlstr=F6m_neXus?= X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: Rafa Marin Lopez , "ace@ietf.org" Subject: Re: [Ace] My comments about draft-seitz-ace-oauth-authz-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2015 20:04:08 -0000 Hi Erik, Thanks for your clarifications. See my comments inline: > El 31 oct 2015, a las 12:25, Erik Wahlstr=F6m neXus = escribi=F3: >=20 > Thanks for the review. It's very valuable. >=20 > See comments below. >=20 > Sent from my iPhone >=20 > On 30 Oct 2015, at 14:46, Rafa Marin Lopez wrote: >=20 >> Dear authors, all: >>=20 >> Here you can find my review about draft-seitz-ace-oauth-authz-00. >>=20 >> The document is very detailed, which helps to understand the = proposal. In my opinion, using a well-known protocol such as OAuth 2.0 = where many people are working and have worked gives maturity and makes = comprehensible the proposal to a broader audience. I also think it would = be good to have some performance data (if available) such as message = size, processing time , etc=85 . In any case, I believe the usage of = OAuth 2.0 is a right and reasonable path for achieving an ACE solution. >=20 > Yes. I also thinks that would be valuable and we should add that going = forward. >=20 >>=20 >> Here some more detail comments/questions: >>=20 >> In page 3: >>=20 >> "This memo describes how to re-use OAuth 2.0 [RFC6749] to extend >> authorization to Internet of Things devices with different kinds of >> constrainedness. At the time of writing OAuth 2.0 is already used >> with certain types of IoT devices and this document will = provide..." >>=20 >> [Rafa] What types of IoT devices already use OAuth 2.0? A reference = with this usage of OAuth 2.0 would be helpful. >=20 > I personally have been working on two but can't show them yet. Hope to = be able to show more in 2 weeks. You could also argue for that the API = economy is also good examples where machines talks to machines where I = would say that oauth2 have become the standard way to protect the = communication. [Rafa] Let=92s wait for two weeks then. No problem! >=20 >=20 >>=20 >>=20 >> "Figure 1: Overview of the basic protocol flow >>=20 >> Requesting an Access Token (A):=94 >>=20 >> [Rafa] Is there any assumption for the client authentication here? >=20 > Vanilla Oauth2 supports many types of grant flows. The draft uses = client credentials (could be pre provisioned either manually or using = something like dynamic client registration specs from oauth wg). There = is no reason for not using other types of credentials for authentication = against the AS. [Rafa] Yes, I am aware you=92re using client credentials. I was = wondering if it would be useful to mention what choices could be = considered as client authentication. >=20 >=20 >>=20 >> "The /token resource (called "endpoint" in OAuth 2.0), defined in >> Section 3.2 of [RFC6749], is used by the client to obtain an access >> token. Requests sent to the /token resource use the HTTP POST = method=85" >>=20 >> [Rafa] Mmmmm=85 if client is constrained =85 will it use HTTP POST?=20= >=20 > No. It's just bad wordings. Good catch. If the client would not be = constrained then http post would do, but otherwise there are coap = examples of it in Figure 2. >=20 >>=20 >> =936.1 Client and Resource Server are Offline" >>=20 >> [Rafa] I realize that offline is sometimes confusing. client and = resource server can communicate each other. The AS is offline since it = is not reachable. But anyway, this is a minor thing. >=20 > Yes I see the point. We tried our a couple of namings of the examples = of different deployment models using the oauth framework but I guess it = still can be worked on a bit more. >=20 >>=20 >> "A: The client first generates a public-private key pair used for >> communication security with the RS." >>=20 >> [Rafa] In the same section 6.1, you describe the case where client = and resource server cannot contact the AS. However you describe the = communication with the AS. This might result confusing is shown. Perhaps = the interaction with the AS should be placed out of this section. >=20 > We state in the intro text that it's done priori of the real access = requests. It's still a mandatory step to initialize C and RS. >=20 > "This access procedure involves > steps A, B, C, and F of Figure 1, but assumes that step A and B have = been carried out during a phase when the client had connectivity to AS.=94= [Rafa] Yes I noticed that but my point is that the interaction between C = and AS could be placed out of the that section. In 6.1 you could just = mention that C already has the access token. >=20 >=20 > That could be done in factory, installation or one minute or a lot of = years before depending on the scenario. >=20 >>=20 >> Page 16 >>=20 >> "Figure 5: Access Token including Public Key of the Client. >>=20 >> Messages C and F are shown in Figure 6 - Figure 7. >>=20 >> C: The client then sends the PoP token to the /authz-info = resource >> at the RS. This is a plain CoAP request, i.e. no DTLS/OSCOAP >> between client and RS, since the token is integrity protected >> between AS and RS." =20 >>=20 >> [Rafa] I think I am missing something here. A PoP token proves that = the client knows a key (key confirmation). But the reason you give for = not using DTLS/OSCOAP is that the token is integrity protected AS and = RS. The client should prove that it owns the key anyway, no? >=20 > That's done later when the real GET request is sent. In the first = request the access token is sent to the RS. The token is, as stated, = integrity protected by the AS and then verified and stored by the RS. In = the later get request the pop key is used by the client to prove to the = RS that the client really have access to the key. [Rafa] Fig. 7 with the DTLS negotiation, right? >=20 >>=20 >> "The RS verifies that the PoP token was created >> by a known and trusted AS, is valid, and responds to the client. >> The RS caches the security context together with authorization >> information about this client contained in the PoP token." >>=20 >> [Rafa] This is related to my previous comment. Is it possible for an = attacker to reply the PoP token? It should not due to PoP token nature = but nothing is mentioned about it, just the verification that it was = created by a trusted AS. Maybe my understanding of PoP token is wrong.=20= >=20 > The token could include a "cti" claim defined in appendix D that talks = about cbor web tokens (CWT). That could be used to prevent replays but = there are also features in the object security drafts for he same. We = should add more details about replays in the security considerations = section. [Rafa] Yes that would be good.=20 >=20 >>=20 >>=20 >> "6.3. Token Introspection with an Offline Client" >>=20 >> [Rafa] Although token introspection may be an interesting feature, I = am thinking that sending additional messages from the RS to the AS is = not good when RS is constrained. I understand it is a tradeoff between = =93authorization freshness=94 vs additional signaling.=20 >=20 > Yes. There will be different needs for different deployments. >=20 >>=20 >> Page 25: "In case 2., the RS does not need to receive any message = from the >> client,"=20 >>=20 >> [Rafa] I do not understand why the RS does not need to receive any = message from the client=85 could you clarify? >>=20 > "Messages" is actually tokens in this scenario. [Rafa] Oh I see. Thanks! >=20 >> Hope this helps. >=20 > It did. Thanks! >=20 > / Erik >=20 >>=20 >> Best Regards. >>=20 >> ------------------------------------------------------- >> Rafael Marin Lopez, PhD >> Dept. Information and Communications Engineering (DIIC) >> Faculty of Computer Science-University of Murcia >> 30100 Murcia - Spain >> Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es >> ------------------------------------------------------- >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From nobody Sun Nov 1 12:05: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 A2E521B2CFE for ; Sun, 1 Nov 2015 12:05:31 -0800 (PST) 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 VTBSA9yq1A5E for ; Sun, 1 Nov 2015 12:05:24 -0800 (PST) Received: from xenon23.um.es (xenon23.um.es [155.54.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA831B2D82 for ; Sun, 1 Nov 2015 12:05:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon23.um.es (Postfix) with ESMTP id E49BF410F; Sun, 1 Nov 2015 21:05:22 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon23.um.es Received: from xenon23.um.es ([127.0.0.1]) by localhost (xenon23.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xhEZBtDq5CQN; Sun, 1 Nov 2015 21:05:22 +0100 (CET) Received: from [192.168.1.35] (130.Red-83-38-57.dynamicIP.rima-tde.net [83.38.57.130]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon23.um.es (Postfix) with ESMTPSA id D58393782; Sun, 1 Nov 2015 21:05:21 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Rafa Marin Lopez In-Reply-To: <5634AE1B.5010609@gmx.net> Date: Sun, 1 Nov 2015 21:05:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <33297FDC-BAA8-402B-80B8-B9CE19991D02@um.es> <5634AE1B.5010609@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: Rafa Marin Lopez , ace@ietf.org Subject: Re: [Ace] My comments about draft-seitz-ace-oauth-authz-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2015 20:05:31 -0000 Hi Hannes: > El 31 oct 2015, a las 13:03, Hannes Tschofenig = escribi=C3=B3: >=20 > Hi Rafa, >=20 > thanks for you review. Since you have contributed the EAP-based = solution > to the group I was obviously very interested to hear your opinion. [Rafa] Thank for your answer. I think EAP-based solution can be used as = bootstrapping and as a choice of client authentication with the AS to = bootstrap security between both entities. =46rom that point , an ACE = solution as the one based on OAuth 2.0 will happen. See my comments inline >=20 > Responses inline: >=20 > On 10/30/2015 02:46 PM, Rafa Marin Lopez wrote: >> Dear authors, all: >>=20 >> Here you can find my review about draft-seitz-ace-oauth-authz-00. >>=20 >> The document is very detailed, which helps to understand the >> proposal. In my opinion, using a well-known protocol such as OAuth >> 2.0 where many people are working and have worked gives maturity and >> makes comprehensible the proposal to a broader audience. I also think >> it would be good to have some performance data (if available) such as >> message size, processing time , etc=E2=80=A6 . In any case, I believe = the >> usage of OAuth 2.0 is a right and reasonable path for achieving an >> ACE solution. >=20 > Thanks for the positive feedback. >=20 > Regarding the performance data we can put some figures together based = on > what we have been playing with. In fact, we (Erik/Samuel from Nexus > Technology and ARM) are going to show a demo of OAuth for a home > automation scenario at the upcoming ARM TechCon event. Forgerock will > also show OAuth-based scenarios at the same event. [Rafa] It is fine. I will looking forward to seeing those results. >=20 > What is difficult with the performance data is that it depends a bit = on > the assumptions made for the scenario. For example, in our case we are > using Bluetooth Smart with a custom BLE service for the communication > between an Android phone and an IoT device. The custom BLE service = uses > JOSE, which is quite naturally more heavy than the COSE solution > currently being developed. While we didn't see problems with the JOSE > solution so far we could replace it with COSE reducing the number of > bits on the wire. For the data exchanged between the phone and the > authorization server it again depends what user experience is offered > and what authentication mechanism is utilized. >=20 > In a nutshell, there is more than just counting bits on the wire = there. [Rafa] That=E2=80=99s for sure. But having some preliminary is always = useful to have an initial approximation.=20 >=20 >>=20 >> Here some more detail comments/questions: >>=20 >> In page 3: >>=20 >> "This memo describes how to re-use OAuth 2.0 [RFC6749] to extend=20 >> authorization to Internet of Things devices with different kinds of=20= >> constrainedness. At the time of writing OAuth 2.0 is already used=20 >> with certain types of IoT devices and this document will provide..." >>=20 >> [Rafa] What types of IoT devices already use OAuth 2.0? A reference >> with this usage of OAuth 2.0 would be helpful. >>=20 >=20 > There are a number of different communication scenarios, as outlined = in > the recent ISOC publication: > = http://www.internetsociety.org/sites/default/files/ISOC-IoT-Overview-20151= 022.pdf >=20 > For the "Back-End Data-Sharing Model", described on page 16, OAuth is > used quite frequently. This is also pretty reasonable since many > companies seek to share data they collect from IoT devices (with the > permission of the user). Here is an example from the vehicle = environment: > https://developer.carvoyant.com/io-docs >=20 > I have shared other examples from the fitness / wearable sector = previously. >=20 > Also for devices that have a user interface but limited input > capabilities OAuth has been used. Here are two examples: > https://developers.facebook.com/docs/facebook-login/for-devices > https://developers.google.com/youtube/v3/guides/auth/devices >=20 > This "Device-to-Cloud Communications" scenario is described on page 14 > in the ISOC paper. >=20 > In general, in terms of deployment it is more common for IoT devices = to > communicate with some gateway or a cloud-based service rather than > having IoT devices communicate directly with each other. [Rafa] Thanks for the pointer. Maybe it is worthy including this = reference. =20 >=20 >>=20 >> "Figure 1: Overview of the basic protocol flow >>=20 >> Requesting an Access Token (A):=E2=80=9D >>=20 >> [Rafa] Is there any assumption for the client authentication here? >=20 > Yes, the client has to be authenticated prior to get an access token. > There is also the consent aspect here, which may require = authentication > of a human. >=20 > The client credentials are provisioned to the device either upfront = (for > example during manufacturing) or the client is registered dynamically > (which is what we have the dynamic client registration for). >=20 > When we wrote the UMA for IoT document there we also had spoke about = the > need to consider cases where the consent comes up-front. For this > document we didn't want to go into that level of detail since these > scenarios are a bit more sophisticated and we already have this other > document available. >=20 > For this write-up we have taken the approach that the reader knows = very > little about the OAuth landscape. [Rafa] I see. Nevertheless, I think this should be clarified this aspect = in some point in the evolution of the I-D. >=20 >=20 >=20 >=20 >=20 >>=20 >> "The /token resource (called "endpoint" in OAuth 2.0), defined in=20 >> Section 3.2 of [RFC6749], is used by the client to obtain an access=20= >> token. Requests sent to the /token resource use the HTTP POST >> method=E2=80=A6" >>=20 >> [Rafa] Mmmmm=E2=80=A6 if client is constrained =E2=80=A6 will it use = HTTP POST? >=20 > In this document we offer the choice to either use HTTP or CoAP. > We are exploring the use of HTTP/2 and QUIC. >=20 > But keep in mind that in most scenarios not everything is constrained. > For example, you might have a person in a smart home using his phone = or > table to control lights and other devices. Their phone can very well = use > HTTP without any problems. [Rafa] Yes I know that but the text seems limiting the case to not = constrained case. That is why I mentioned it. >=20 >=20 >>=20 >> =E2=80=9C6.1 Client and Resource Server are Offline" >>=20 >> [Rafa] I realize that offline is sometimes confusing. client and >> resource server can communicate each other. The AS is offline since >> it is not reachable. But anyway, this is a minor thing. >=20 > That's a good point, which we may need to describe a bit more. > With the requirements outlined in our group it is obviously not = possible > to have a scenario where everything is fully offline and we wouldn't > really be talking about IoT then anyway (but rather about embedded > devices). >=20 > Here the distinction is whether the resource server is able to contact > the authorization server at the time of the resource request. The = client > still has to be able to obtain the access token at some point in time. > There is, of course, also a tradeoff between the ability to revoke > granted permissions in real-time vs. being offline. [Rafa] My point is that in 6.1 it is assumed precisely that at some = point in the past the client already got an access token but when using = the access token the AS is offline for both the client and the resource = server. >=20 >=20 >=20 >=20 >>=20 >> "A: The client first generates a public-private key pair used for=20 >> communication security with the RS." >>=20 >> [Rafa] In the same section 6.1, you describe the case where client >> and resource server cannot contact the AS. However you describe the >> communication with the AS. This might result confusing is shown. >> Perhaps the interaction with the AS should be placed out of this >> section. >=20 > I guess this is the same issue as with the previous comment. I believe > we need to describe more clearly what we mean by offline. I think the > qualification "offline during the time of the resource access" might > describe it better. [Rafa] What I suggested that in the interaction of the AS should be = placed out of this section. >=20 >>=20 >> Page 16 >>=20 >> "Figure 5: Access Token including Public Key of the Client. >>=20 >> Messages C and F are shown in Figure 6 - Figure 7. >>=20 >> C: The client then sends the PoP token to the /authz-info resource at >> the RS. This is a plain CoAP request, i.e. no DTLS/OSCOAP between >> client and RS, since the token is integrity protected between AS and >> RS." >>=20 >> [Rafa] I think I am missing something here. A PoP token proves that >> the client knows a key (key confirmation). But the reason you give >> for not using DTLS/OSCOAP is that the token is integrity protected AS >> and RS. The client should prove that it owns the key anyway, no? >>=20 >> "The RS verifies that the PoP token was created by a known and >> trusted AS, is valid, and responds to the client. The RS caches the >> security context together with authorization information about this >> client contained in the PoP token." >>=20 >> [Rafa] This is related to my previous comment. Is it possible for an >> attacker to reply the PoP token? It should not due to PoP token >> nature but nothing is mentioned about it, just the verification that >> it was created by a trusted AS. Maybe my understanding of PoP token >> is wrong. >>=20 >=20 > This is a very good comment since I had to fight with this issue as > well. Here is the issue. If you look at the way how things work in = HTTP > then you would include the token with the (initial) resource request. >=20 > We ideally want to have the same pattern also in CoAP and CoAP is > supposed to be designed like HTTP. However, as it turns out there are > some issues in terms of size limitations. Hence, it may be necessary = to > send the token to a special authorization endpoint first before making > the resource request. While I do not quite like that design I believe = it > is a side-effect of the CoAP design. [Rafa] So the PoP token is first presented without client authentication = because it may not fit in the resource request, correct? According to = Goran=E2=80=99s comment key confirmation happens, for example, during = the establishment of the DTLS connection just after sending the PoP = token (Fig. 7). Am I right? Thanks! >=20 >>=20 >> "6.3. Token Introspection with an Offline Client" >>=20 >> [Rafa] Although token introspection may be an interesting feature, I >> am thinking that sending additional messages from the RS to the AS is >> not good when RS is constrained. I understand it is a tradeoff >> between =E2=80=9Cauthorization freshness=E2=80=9D vs additional = signaling. >=20 > Yes, there is a tradeoff here and we allow those who deploy the = protocol > to decide themselves about this tradeoff. >=20 >=20 >>=20 >> Page 25: "In case 2., the RS does not need to receive any message >> from the client," >>=20 >> [Rafa] I do not understand why the RS does not need to receive any >> message from the client=E2=80=A6 could you clarify? >=20 > I let Goeran respond to this comment since it relates to the publish > subscribe model. >=20 > Ciao > Hannes >=20 >>=20 >> Hope this helps. >>=20 >> Best Regards. >>=20 >> ------------------------------------------------------- Rafael Marin >> Lopez, PhD Dept. Information and Communications Engineering (DIIC)=20 >> Faculty of Computer Science-University of Murcia 30100 Murcia - >> Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es=20 >> ------------------------------------------------------- >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ Ace mailing list=20 >> Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace >>=20 >=20 ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From nobody Sun Nov 1 12:17: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 892131B8C3C for ; Sun, 1 Nov 2015 12:17:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 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, 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 Xe5y39zfqiuo for ; Sun, 1 Nov 2015 12:17:33 -0800 (PST) Received: from xenon23.um.es (xenon23.um.es [155.54.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id EAE361B8C3B for ; Sun, 1 Nov 2015 12:17:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon23.um.es (Postfix) with ESMTP id 3DFEE415E; Sun, 1 Nov 2015 21:17:32 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon23.um.es Received: from xenon23.um.es ([127.0.0.1]) by localhost (xenon23.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id jhz-VaCWjYsX; Sun, 1 Nov 2015 21:17:32 +0100 (CET) Received: from [192.168.1.35] (130.Red-83-38-57.dynamicIP.rima-tde.net [83.38.57.130]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon23.um.es (Postfix) with ESMTPSA id A6CD83782; Sun, 1 Nov 2015 21:17:29 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Rafa Marin Lopez In-Reply-To: Date: Sun, 1 Nov 2015 21:17:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <65AD75BF-D8EB-4032-B467-B0946779EEA9@um.es> References: <33297FDC-BAA8-402B-80B8-B9CE19991D02@um.es> <5634AE1B.5010609@gmx.net> To: =?utf-8?Q?G=C3=B6ran_Selander?= X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: Hannes Tschofenig , Rafa Marin Lopez , "ace@ietf.org" Subject: Re: [Ace] My comments about draft-seitz-ace-oauth-authz-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2015 20:17:35 -0000 Hi G=C3=B6ran: >>=20 >>>=20 >>> Page 16 >>>=20 >>> "Figure 5: Access Token including Public Key of the Client. >>>=20 >>> Messages C and F are shown in Figure 6 - Figure 7. >>>=20 >>> C: The client then sends the PoP token to the /authz-info resource = at >>> the RS. This is a plain CoAP request, i.e. no DTLS/OSCOAP between >>> client and RS, since the token is integrity protected between AS and >>> RS." >>>=20 >>> [Rafa] I think I am missing something here. A PoP token proves that >>> the client knows a key (key confirmation). But the reason you give >>> for not using DTLS/OSCOAP is that the token is integrity protected = AS >>> and RS. The client should prove that it owns the key anyway, no? >=20 > [GS] Yes, you are right that the client needs to prove possession of = the > key in the PoP token, but the PoP token provisioning needs not be > integrity protected by the client. It suffices in principle that it is > signed or MACed by the AS (you could also consider replay protection). > The > proof of possession step comes in the access request, which may be > separated out from the token provisioning step, relating to your next > question. [Rafa] You mean the Fig. 7 where the DTLS is established that proves the = possession of the key , right? >=20 >>>=20 >>> "The RS verifies that the PoP token was created by a known and >>> trusted AS, is valid, and responds to the client. The RS caches the >>> security context together with authorization information about this >>> client contained in the PoP token." >>>=20 >>> [Rafa] This is related to my previous comment. Is it possible for an >>> attacker to reply the PoP token? It should not due to PoP token >>> nature but nothing is mentioned about it, just the verification that >>> it was created by a trusted AS. Maybe my understanding of PoP token >>> is wrong. >>>=20 >=20 > [GS] As you write, a second POST using the same PoP token would not = lead > to a violation of privileges, but may be used in a DoS attack which is = one > reason to have some form of replay protection. Just to be clear, the > intent here is to minimize the transport so that the PoP token is > transported once but may be used multiple times (if supported by the > claims). [Rafa] Do you mean creating a state related with the PoP token in the = resource server before accessing the service? Is this correct? >=20 >>=20 >> This is a very good comment since I had to fight with this issue as >> well. Here is the issue. If you look at the way how things work in = HTTP >> then you would include the token with the (initial) resource request. >>=20 >> We ideally want to have the same pattern also in CoAP and CoAP is >> supposed to be designed like HTTP. However, as it turns out there are >> some issues in terms of size limitations. Hence, it may be necessary = to >> send the token to a special authorization endpoint first before = making >> the resource request. While I do not quite like that design I believe = it >> is a side-effect of the CoAP design. >=20 > [GS] Just to add to what Hannes wrote, we consider the optimization of > combining token provisioning with access request to RS in Appendix B. [Rafa] Thanks for the pointer! >=20 > G=C3=B6ran >=20 >>=20 >>>=20 >>> "6.3. Token Introspection with an Offline Client" >>>=20 >>> [Rafa] Although token introspection may be an interesting feature, I >>> am thinking that sending additional messages from the RS to the AS = is >>> not good when RS is constrained. I understand it is a tradeoff >>> between =E2=80=9Cauthorization freshness=E2=80=9D vs additional = signaling. >>=20 >> Yes, there is a tradeoff here and we allow those who deploy the = protocol >> to decide themselves about this tradeoff. >>=20 >>=20 >>>=20 >>> Page 25: "In case 2., the RS does not need to receive any message >>> from the client," >>>=20 >>> [Rafa] I do not understand why the RS does not need to receive any >>> message from the client=E2=80=A6 could you clarify? >>=20 >> I let Goeran respond to this comment since it relates to the publish >> subscribe model. >>=20 >> Ciao >> Hannes >>=20 >>>=20 >>> Hope this helps. >>>=20 >>> Best Regards. >>>=20 >>> ------------------------------------------------------- Rafael Marin >>> Lopez, PhD Dept. Information and Communications Engineering (DIIC) >>> Faculty of Computer Science-University of Murcia 30100 Murcia - >>> Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es >>> ------------------------------------------------------- >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ Ace mailing list >>> Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace >>>=20 >>=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From nobody Sun Nov 1 15:06:07 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBEB1ACE0E for ; Sun, 1 Nov 2015 15:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.007 X-Spam-Level: X-Spam-Status: No, score=-0.007 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, 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 k2ne31mUG01A for ; Sun, 1 Nov 2015 15:06:02 -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 22C221ACE0C for ; Sun, 1 Nov 2015 15:06:01 -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 tA1N5qlT014039; Mon, 2 Nov 2015 00:05:52 +0100 (CET) Received: from aung.tzi.org (pD9F61E6C.dip0.t-ipconnect.de [217.246.30.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nptJv5qTcz2GC1; Mon, 2 Nov 2015 00:05:51 +0100 (CET) From: Olaf Bergmann To: "Kepeng Li" Date: Sun, 01 Nov 2015 14:18:20 +0100 References: Message-ID: <87k2q1e2wg.fsf@aung.informatik.uni-bremen.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Solution comparison X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2015 23:06:05 -0000 "Kepeng Li" writes: > I uploaded the chairs slides for the ACE session tomorrow morning. > > The last slide is the solution comparison table: Thanks for collecting this. Adhoc, I have a few addtions (more are likely to follow soon):=20 * "Architecture" * "Have CAS"/"No CAS" is not that catchy. Maybe it would be better to describe the consequences: DCAF supports cross-domain multi-owner scenarios, while the OAuth-profile only supports cross-domain or multi-owner, but not both at the same time. * Another consequence of having a CAS is that DCAF protects both sides of the communication between C and S, not only the resource side as done by the single-AS models such as the OAuth-profile. * "Fit into Constrained Environments" * OAuth-interoperability has been demonstrated, token introspection is not covered by DCAF itself because it is another protocol; but nothing in DCAF precludes doing that * it should be noted that both, the client and the server can be constrained (for "OAuth-Profiling", the client can be constrained only in the single-domain scenario, though) * "Security" * The constrained C and RS get a dynamically created symmetric session key. All other communication, especially between CAS and RAS can be asymmetric, of course. This includes the OAuth-typical scenario, where C and CAS are combined (as in "OAuth-Profiling"). * DCAF can be used with DTLS or COSE (even intermixed) * I suggest to add an additional item "Privacy" * DCAF does not need identifiers on the constrained-level that could be tracked =20=20=20=20 * "Communication Models" * in addition to the client-initiated ticket request model and the server-initiated ticket request model (Selander/Seitz call them "push" and "pull"), DCAF also supports the "client-pull" model. RS can be offline in the client-initiated ticket request model and in the "client-pull" model; C can be offline in the server-initiated ticket request model * "Implementations" * Do "Less" and "More" mean the number of implementations? Given that draft-seitz-ace-oauth-authz has been submitted two weeks ago, and draft-ietf-cose-msg is not that old either, while the core of DCAF is stable for over two years now, I doubt that there will be a significant difference in the number of implementations.=20=20=20 Gr=C3=BC=C3=9Fe Olaf From nobody Sun Nov 1 20:12:32 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77CD21B3F5D for ; Sun, 1 Nov 2015 17:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, 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 CQPUkHdVRt4W for ; Sun, 1 Nov 2015 17:17:42 -0800 (PST) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (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 9FCA41B3F5A for ; Sun, 1 Nov 2015 17:17:41 -0800 (PST) Received: from smtp1.sunet.se (smtp1.sunet.se [192.36.171.214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id tA21Hd6P012912 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 2 Nov 2015 02:17:39 +0100 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.9/8.14.7) with ESMTP id tA21HabJ008843 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 2 Nov 2015 02:17:39 +0100 (CET) VBR-Info: md=sunet.se; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1446427059; bh=3yiUYOyiNpvB7WHJYWOFNL0PB85uodY4sz0jvRCMgk4=; h=To:From:Subject:Date; b=BUbyk7rp5lz7WbTHfl/8vjVn8CpJZ5sbT5B4nCa/rm+dy2dPCng4792lOPe/Cg7Df zivCTXvpiiPZsyoRhwiyhcdMp7qM91vkkpAbwL4gvlPlRWU9XFfEqaP+OdCWkyAakM 7ZYZCzak1k0Pvfbm3+K87yLPuH6r0usydXr5p8qc= X-Footer: c3VuZXQuc2U= Received: from [133.93.34.15] ([133.93.34.15]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.5.2) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits)) for ace@ietf.org; Mon, 2 Nov 2015 02:17:34 +0100 To: ace@ietf.org From: Leif Johansson Message-ID: <5636B9AA.5000804@sunet.se> Date: Mon, 2 Nov 2015 02:17:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09PAphDs1 - 7ffd2af8d680 - 20151102 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 192.36.171.210 is neither permitted nor denied by domain leifj@sunet.se) receiver=e-mailfilter01.sunet.se; client-ip=192.36.171.210; envelope-from=; helo=smtp1.sunet.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: X-Mailman-Approved-At: Sun, 01 Nov 2015 20:12:30 -0800 Subject: [Ace] chacha20 as prng X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 02 Nov 2015 01:17:44 -0000 As I mentioned at the mic just now there is quite a lot of experience with this approach over at cryptech.is. Specifically reach out to the engineers (of which I am not one) on the tech @ cryptech.is list for pointers to analysis etc. Cheers Leif From nobody Sun Nov 1 21:39: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 032181B4743 for ; Sun, 1 Nov 2015 21:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmCJ6KYreOQ5 for ; Sun, 1 Nov 2015 21:39:37 -0800 (PST) Received: from out4133-66.mail.aliyun.com (out4133-66.mail.aliyun.com [42.120.133.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4991B4681 for ; Sun, 1 Nov 2015 21:39:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1446442775; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=JbQyy9/zz/LqnRx2Wo0jN70dRwl8zrbCwD6oDO5VXTU=; b=GIzdbFMqgTXZsLOq9tLgtSmtbi5EwaOMI8vzmDZZ3cf/7lB7PDZrDRyGwCk6n1wDEO+FniUQQ+bhOm1rXIPWXsyraSoz0a6pzcKOZTp0jkac1Ycby34oUjELQ6dYHgmn370lcLOU8EdYMK42kLgwwAaSJzREIISQKHI3cnUcMXM= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R131e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03285; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=4; SR=0; Received: from 10.22.59.223(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.208) by smtp.aliyun-inc.com(127.0.0.1); Mon, 02 Nov 2015 13:39:28 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Mon, 02 Nov 2015 13:39:21 +0800 From: "Kepeng Li" To: "Ace@ietf.org" Message-ID: Thread-Topic: Solution direction Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3529319968_13101542" Archived-At: Cc: Kathleen Moriarty , Hannes Tschofenig , Stephen Farrell Subject: [Ace] Solution direction X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 02 Nov 2015 05:39:40 -0000 > ´ËÓʼþʹÓà MIME ¸ñʽ¡£ÓÉÓÚÓʼþÔĶÁ³ÌÐò²»ÄÜʶ±ð ´Ë¸ñʽ£¬Òò´Ë£¬¿ÉÄÜÎÞ·¨Ê¶±ð¸ÃÓʼþµÄ·Ö²¿»ò²¿·ÖÄÚÈÝ¡£ --B_3529319968_13101542 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: 7bit At the face-to-face meeting of the ACE working group in Yokohama, the participants in the room decided to accept the OAuth profiling draft as a starting point for future work of the solution charter item: http://datatracker.ietf.org/doc/draft-seitz-ace-oauth-authz/ For those who weren't present in the room, please let us know whether you accept or object to this decision, before 17th Nov, 2015. Thanks, Kind Regards Kepeng --B_3529319968_13101542 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable
At the face-to-face meeting of t= he ACE working group in Yokohama, the participants in the room decided to ac= cept the OAuth profiling draft as a starting point for future work of the so= lution charter item:

For those who weren't present = in the room, please let us know whether you accept or object to this decisio= n, before 17th Nov, 2015.

Thanks,

Kind Regards
Kepeng 
--B_3529319968_13101542-- From nobody Sun Nov 1 23:09: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 C40EF1B334F for ; Sun, 1 Nov 2015 23:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u72lS7BXygoY for ; Sun, 1 Nov 2015 23:09:16 -0800 (PST) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56B061B3348 for ; Sun, 1 Nov 2015 23:09:16 -0800 (PST) Received: by pacfv9 with SMTP id fv9so145779756pac.3 for ; Sun, 01 Nov 2015 23:09:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics_se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=nKy5kuPmZPB/z5r9ZRaSVJK2POq5QtG8SjKPFc5l2Z8=; b=wqzaKqs97f9xbCNNLgZHMLgJPbRsBvoOSKsgFrzJKF3yxydvHvkIImcdLruD2XOame /OLn63tQ7x/ANweavGysrKQqAnCQh/mw3zuJl21UOoE0+XmoXKvtscrXUkfATxCuXdny +S/0H0z9SBCx42bA4g9VAWeNChMbq+Fn1f8vlehjsRIxFh0RVG9ttN39zY5Q+htzIN11 bRyVRbECycvhEe352JfJA4fu4t1SeXgkJBcoDACriUT2/qVY9PcBVTjnDM4m53o+M3RL UFL+xPDcWCjxY4xwa+fhO90bROGATqZmmsEBYF0rMaf6LNYmi6o9dsiLA+ymn1Xe6cAm g8fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=nKy5kuPmZPB/z5r9ZRaSVJK2POq5QtG8SjKPFc5l2Z8=; b=c7BYNuc4OOGBOHToqF0oAFembNmnr9TZheSFk0ZbMukHu7w1++KTC64PYtz5WFeo5X MfBTRUCjJvlm67qy8YEMyaaXm6G4AXQo7aW62t2WrxiZTJk9s8ond7m9nDm1/fkbNUu4 TUC5OiOJojACaWx/eMhGhNyBHgX3x/lY87dpPhby/KSohKez70BdWk3Tz+FMyP4GcWAN vAQsX42mxx09DoLcP7vsF5DI3sTM39QhdyMAh+8Q5kkPnaZJktEeCVsXFfLc7BVspEmy rPLRNkiRw+0FpeujjY6+b2/7bpwOk2aQ1PY8JGNJTMq+2c6RnRzsIkW+xxSL4hU607bl D9dQ== X-Gm-Message-State: ALoCoQnQIcCotqH5jy5aGvfxMs4zZ5oKJaisWy2DaS9SciHA+HOdDWqm+VpuwDRlM2UAn9YRH9tv X-Received: by 10.68.252.73 with SMTP id zq9mr25835974pbc.130.1446448155994; Sun, 01 Nov 2015 23:09:15 -0800 (PST) Received: from ?IPv6:2001:c40:0:3040:952d:6078:3b7e:d48f? (t20010c4000003040952d60783b7ed48f.v6.meeting.ietf94.jp. [2001:c40:0:3040:952d:6078:3b7e:d48f]) by smtp.gmail.com with ESMTPSA id in6sm21929973pbd.86.2015.11.01.23.09.13 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Nov 2015 23:09:14 -0800 (PST) To: ace@ietf.org, Rafa Marin Lopez References: <33297FDC-BAA8-402B-80B8-B9CE19991D02@um.es> <2D596355-C89B-4162-943C-E049B301D83F@nexusgroup.com> From: Ludwig Seitz Message-ID: <56370C17.4030901@sics.se> Date: Mon, 2 Nov 2015 08:09:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010702080504060902050407" Archived-At: Subject: Re: [Ace] My comments about draft-seitz-ace-oauth-authz-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 07:09:18 -0000 This is a cryptographically signed message in MIME format. --------------ms010702080504060902050407 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 2015-11-01 21:04, Rafa Marin Lopez wrote: >>> >>> Page 25: "In case 2., the RS does not need to receive any message fro= m the >>> client," >>> >>> [Rafa] I do not understand why the RS does not need to receive any me= ssage from the client=85 could you clarify? >>> >> "Messages" is actually tokens in this scenario. > > [Rafa] Oh I see. > Actually the client might actually not be sending any messages to the RS = here. The example we are looking at is a publish-subscribe scenario with = a message broker as suggested in draft-koster-core-coap-pubsub-02. So=20 the RS would send (encrypted and signed) sensor readings to the broker=20 and the client would get those readings directly from the broker without = ever sending messages to the RS. It would also get the necessary keys=20 from the AS if it is allowed access. /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 --------------ms010702080504060902050407 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DFQwggYYMIIFAKADAgECAgMMhpgwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTAxMDgwODM5MDZaFw0xNjAxMDkyMjQxMzBaMDgxFzAV BgNVBAMMDmx1ZHdpZ0BzaWNzLnNlMR0wGwYJKoZIhvcNAQkBFg5sdWR3aWdAc2ljcy5zZTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVB4rAuq4FxbARxwRqPLpc/3C194F+V H4XMKK6fu3Y8zDLijzNSjh6tG41oZhXvJcvAs1nZNjUutNLeyBAUFiYhy7HXNdlKpjbMEFKQ +6KpEdZ0Rk+pXgB2E1mqZEfp3M2djcQ/h+7uGVlSGYNAxYk6rWPIIWBx2GMvAQaHP4xxu/F+ PiSQILOVzmtIFZe1t/Lw71aaNeMYVhARo8z5PVsVoq6gBeujxfiRLtiQ/S8xW6RKvNvUkVyT BQfcKaEDZR9FENNf9rFgiAcT6R7hI8RBf1d2fxdlbDU8uM72K3fvzGDt8N9Bfm1kDWbDBxJE 1taRIYs+60D1kwV6DvBb9MECAwEAAaOCAtQwggLQMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6ryrKahJtBOEdbIL AAWCpOsQyagwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwGQYDVR0RBBIwEIEO bHVkd2lnQHNpY3Muc2UwggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYB BQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqBvlRo aXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDEgVmFs aWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUg cmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEF BQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEvY2xpZW50L2NhMEIG CCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNs aWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqG SIb3DQEBBQUAA4IBAQBl8BbG0n7+JjFqiJOuAqMbkeqM6Oyd+4oHGu3fbaSiM1SKesae2bfm vifV99a+M4DERZ2SVkOYcvNlv31Q3hvYtzRjDOqewzVKxo021R3ddQULW1DhvTEpclikG5rd 0NRJQn+EkSwEKLeUj68i0dhU8ULhZDDq3A81cTcZzIGrTjNnwDvCktB/sF/iO4At6RJ24P3j KjYFPirW3NsvZ2gzZizSzeubPE0/cWcqEBJ/UtaFPF54efejjLuPRHHMLPDcvrwBhEiBxuG6 oTEo465g4pS9Vo/Z0GoZgZyA+aGQ+YPbPSsqsYmSBjZ6MGGDqQq0niE2dW+8IOdHQvMkqI52 MIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcN MDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxwmDzM4t2BqxKaQu E6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESip7vMz39ScLpNLbL1QpOlPW/t FIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9ftTyhxvxWkf8KW37iKrueKsxw 2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsWoTb7q8hmgv6Nv3Hg9rmA1/VP BIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/43Yksq60jExipA4l5uv9/+Hm 33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IBrTCCAakwDwYDVR0TAQH/BAUw AwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8G A1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsGAQUFBwEBBFowWDAnBggrBgEF BQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0GCCsGAQUFBzAChiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQwUjAnoCWgI4YhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcBAgEwZjAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDov L3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjANBgkqhkiG9w0BAQUFAAOCAgEA CoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHbWNaPeQn3oBSU8KgQZn/Kck1J xbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4OxK9QPoSjCMxM3HbkZCDJgnl E8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0KAkXCzeQNLeA5LlYUzFyM7kP Ap8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL04qYK/zu+Qg1Bw0RwgigVZs/0 c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0IFiNu9IPuTGAPBn4CPxD0+Ru 8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6fDEPme+1Nbi+03pVjuZQKbGw KJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVtjYsv0L1TSm2+NwON58tO+pIV zu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm48ZCYfAWLb/Xj7F5JQMbZvCex glAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BIXRsF1du4qESm4/3CKuyUV7p9 DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJ bnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJYIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MTEwMjA3MDkxMVowLwYJKoZI hvcNAQkEMSIEINqX/TyWKf2YNVoPC2AD3M9DZfFOQYN4mFptZKADwy7OMGwGCSqGSIb3DQEJ DzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQB gjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwgacG CyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC AwyGmDANBgkqhkiG9w0BAQEFAASCAQAWfgEpAIo3rRlEi+VKOtP1ojCpkDdvpzkNfFX/Wilx LDg8JsIiiGILdkzaUUaHj91yPC588LMWj6L1oWGpYZIfwmJHwrLq4nzX8lsYBjJbIOclRjoY lSK6Wdv9JSeZjEw6vbaPfQxyCIPqfXYzKBkLS7QWPtESHtCklQOaP5L4JXrcTmarQFmPtKMT KMjSJlZXtfTXoovdYadfGfpvaolxW7/efX0Yl4bCF+uj1LoOscyGnj3E7dgSfa88lZUVKK8F C4qw6X9mvwDUD+kFsOCZwRq6lPndTHRtHbiFs0EJ++s/9bPFyERXxHjMCFFQJU+YSs8e5HkK ARZ/3yZuMq34AAAAAAAA --------------ms010702080504060902050407-- From nobody Mon Nov 2 01:11: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 0260A1B355A for ; Mon, 2 Nov 2015 01:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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 6nTIbB0ra1vh for ; Mon, 2 Nov 2015 01:11:48 -0800 (PST) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0E191B3528 for ; Mon, 2 Nov 2015 01:11:47 -0800 (PST) Received: by lfbn126 with SMTP id n126so58516233lfb.2 for ; Mon, 02 Nov 2015 01:11:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics_se.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=5Kl1jvPEJzSYcEDhR8PzChZByQl/9kl2h1TJIAOESbo=; b=uyaDZZ4DOj1ODubv+KJhRzVkqKJy1kTZ+WFVijzD5A3MEn6a2cm6CaRUrDzk0fodIR Jt2OA+jJ6u/vs3iuHPyNMTSjUD6Z24EpE6h6dIoWbtawu2w9+z6xDQmRoujz4hLgvZhJ ByAl6EZrELraKvaYymqhcywTt1mwrgsh6vQrzlr0unyG1YNUNBi2KI7tjMJhTs7vVtPD 4Z3tLhG0h8Wy3HEMEEppDRmaCN731V1H44vFMKPx/9YhVI6hVOSwbDx/suFFp/bNaXl1 RelQKzT98K/nCXxOcnab8dsU0YKm6rwjBLrt8N8PjcNZCjVuqw+5WnpM4y2BggqmFVIi MH3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=5Kl1jvPEJzSYcEDhR8PzChZByQl/9kl2h1TJIAOESbo=; b=B6UZrIpYrYznPyjxGF4t5p6F6itVAczYupZQ+SaYJ0+yRkH5Ukg1ObHRWJHpo8ifEN g07vniWIA2X4lfCGuWUWn6JbyQMg5oTfyusJD6gxMR3yffcuDQf2PhiHPenzgSBc8qcR fHfi0eIUV8ylF/N4IsmA2vfY6kBDyxyzu6aTTyxFSqFmMGWp02xVcZt8Mscuo8EtdBfF OEhWIHpfSW2mlHEMrzC5qJtH41/HMDlBJcZLD3n/CjLEkkCKZqvroZbYCKt0z9XjILrS FfA6Amz5BNLi4yexV8A0Cu5Q4ktwwBD5AZI9lDxCOZIa0BAnerXu1hWC5KE4NKcF5uS9 5FlQ== X-Gm-Message-State: ALoCoQmlbMv/HiIQs0TxQbCsasBTvfkUZUoU56Aytj/UTFNzAhVlOJ2Tq+4UqoNWbVjeBf8RTRTI X-Received: by 10.25.169.199 with SMTP id s190mr6587125lfe.78.1446455505946; Mon, 02 Nov 2015 01:11:45 -0800 (PST) Received: from [192.168.0.15] (c83-250-218-128.bredband.comhem.se. [83.250.218.128]) by smtp.gmail.com with ESMTPSA id h7sm3751722lbk.8.2015.11.02.01.11.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Nov 2015 01:11:44 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_1DB2F244-6F62-49D0-B9E1-E2C79DABD064" From: Shahid Raza In-Reply-To: Date: Mon, 2 Nov 2015 10:11:43 +0100 Message-Id: References: To: Kepeng Li X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: Stephen Farrell , Kathleen Moriarty , Hannes Tschofenig , "Ace@ietf.org" Subject: Re: [Ace] Solution direction X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 02 Nov 2015 09:11:50 -0000 --Apple-Mail=_1DB2F244-6F62-49D0-B9E1-E2C79DABD064 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I accept this decision. /Shahid > On 02 Nov 2015, at 06:39, Kepeng Li = wrote: >=20 > At the face-to-face meeting of the ACE working group in Yokohama, the = participants in the room decided to accept the OAuth profiling draft as = a starting point for future work of the solution charter item: > http://datatracker.ietf.org/doc/draft-seitz-ace-oauth-authz/ = =20 >=20 > For those who weren't present in the room, please let us know whether = you accept or object to this decision, before 17th Nov, 2015. >=20 > Thanks, >=20 > Kind Regards > Kepeng=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --Apple-Mail=_1DB2F244-6F62-49D0-B9E1-E2C79DABD064 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I accept this decision.

/Shahid

On = 02 Nov 2015, at 06:39, Kepeng Li <kepeng.lkp@alibaba-inc.com> wrote:

At the = face-to-face meeting of the ACE working group in Yokohama, the = participants in the room decided to accept the OAuth profiling draft as = a starting point for future work of the solution charter item:
http://datatracker.ietf.org/doc/draft-seitz-ace-oauth-authz/ 

For = those who weren't present in the room, please let us know whether you = accept or object to this decision, before 17th Nov, 2015.

Thanks,

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

= --Apple-Mail=_1DB2F244-6F62-49D0-B9E1-E2C79DABD064-- From nobody Mon Nov 2 04:29: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 2D0DB1A8826 for ; Mon, 2 Nov 2015 04:29:39 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 mRJs0d39qdX3 for ; Mon, 2 Nov 2015 04:29:37 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BA991A8825 for ; Mon, 2 Nov 2015 04:29:37 -0800 (PST) Received: by igpw7 with SMTP id w7so47309962igp.1 for ; Mon, 02 Nov 2015 04:29:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=U1T45NEsizykWpjr00Jjxf/7ZThq8mFdlEqSXWW2p3o=; b=UC6IkFXG0jYBODILtm5PqBGhCwJ/RvbYmSCufYXNMzdp5rZj8WnW4YGQYQ50iSr33z w5NtU2Wyyt8t3EHa2PC+f0yUZp2Iq7HVLkN9wxWmphhAQsmdQFEWoSD7MvKiJ9p8JPg1 veRjPEGTtTqHGeOSiaSadXQh5kMbGQQaDBRwVqfbDaX4c7eEJp9fLrLAmOsOwH+T+Hud ZYtpRDRDqm/osoYJLFBoe3KWpVv+XLSz0tFp/7hNAkV8A1xZvMfhhJXwt2P1Q+kl8EJI N+5z9mH8YSRayHDKP+yNZkrDyqCgVmgOXq2m3oryK7ybcIGtRn4BQD2wvJ5ctbznvoDD PKlQ== X-Received: by 10.50.111.170 with SMTP id ij10mr11043854igb.88.1446467376814; Mon, 02 Nov 2015 04:29:36 -0800 (PST) Received: from [192.168.1.65] (CPE84948c5cbf81-CM84948c5cbf80.cpe.net.cable.rogers.com. [99.224.83.138]) by smtp.googlemail.com with ESMTPSA id p95sm7675975ioi.23.2015.11.02.04.29.35 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2015 04:29:35 -0800 (PST) To: ace@ietf.org References: From: Paul Madsen Message-ID: <5637572E.7060407@gmail.com> Date: Mon, 2 Nov 2015 07:29:34 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------080102070007070902020603" Archived-At: Subject: Re: [Ace] Solution direction X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 02 Nov 2015 12:29:39 -0000 This is a multi-part message in MIME format. --------------080102070007070902020603 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit accept On 11/2/15 12:39 AM, Kepeng Li wrote: > At the face-to-face meeting of the ACE working group in Yokohama, the > participants in the room decided to accept the OAuth profiling draft > as a starting point for future work of the solution charter item: > http://datatracker.ietf.org/doc/draft-seitz-ace-oauth-authz/ > > For those who weren't present in the room, please let us know whether > you accept or object to this decision, before 17th Nov, 2015. > > Thanks, > > Kind Regards > Kepeng > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --------------080102070007070902020603 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit accept

On 11/2/15 12:39 AM, Kepeng Li wrote:
At the face-to-face meeting of the ACE working group in Yokohama, the participants in the room decided to accept the OAuth profiling draft as a starting point for future work of the solution charter item:

For those who weren't present in the room, please let us know whether you accept or object to this decision, before 17th Nov, 2015.

Thanks,

Kind Regards
Kepeng 


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

--------------080102070007070902020603-- From nobody Mon Nov 2 05:40:08 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266971B368E for ; Mon, 2 Nov 2015 05:40:08 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 15gmSJAkj5dK for ; Mon, 2 Nov 2015 05:40:06 -0800 (PST) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BE641B3691 for ; Mon, 2 Nov 2015 05:40:06 -0800 (PST) Received: by oifu63 with SMTP id u63so95505080oif.2 for ; Mon, 02 Nov 2015 05:40:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=9hS+mb8SXVjyaoPLQatKlef5f1HROJB+iS02wc0L6p0=; b=j9onwRbM4VegKQjtPg8EDZH47CMUymNQXVKZUuSPGPbrRtKliEyBpVq+eHrtHRjgwz De8TGCCAoGT00xMolQEohIA92pVvNYNpMvREJuwcAT+Vl+Lk70WWOFUJYPPoqvjf/5UA nzI8Psf1wZtgt6KGNl605LT6PJX3QwT6ABCvG2DWrga/Wyp9mZAljqF9adcZmbWSy7MB dHxYzk3Lw56ue6UU07fY+ee4HU6SBjJJjFi0gPCbUW3+a7FUwtEMnP0p33mZhWzpazLu uK1QcOsh5qOjRTtRbzQkz2BcjPpxgh01wyOb57sPc6EC+ksYjADFAZYGJ0wIqReY+KIV DYoQ== MIME-Version: 1.0 X-Received: by 10.202.46.207 with SMTP id u198mr12468723oiu.66.1446471605584; Mon, 02 Nov 2015 05:40:05 -0800 (PST) Received: by 10.202.197.76 with HTTP; Mon, 2 Nov 2015 05:40:05 -0800 (PST) In-Reply-To: References: Date: Mon, 2 Nov 2015 08:40:05 -0500 Message-ID: From: Stephen Moore To: "Ace@ietf.org" Content-Type: multipart/alternative; boundary=001a1137a2163a9fbd05238eeaae Archived-At: Subject: Re: [Ace] Solution direction X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 02 Nov 2015 13:40:08 -0000 --001a1137a2163a9fbd05238eeaae Content-Type: text/plain; charset=UTF-8 Accept -steve On Mon, Nov 2, 2015 at 12:39 AM, Kepeng Li wrote: > At the face-to-face meeting of the ACE working group in Yokohama, the > participants in the room decided to accept the OAuth profiling draft as a > starting point for future work of the solution charter item: > http://datatracker.ietf.org/doc/draft-seitz-ace-oauth-authz/ > > For those who weren't present in the room, please let us know whether you > accept or object to this decision, before 17th Nov, 2015. > > Thanks, > > Kind Regards > Kepeng > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > --001a1137a2163a9fbd05238eeaae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Accept

-steve

On Mon, Nov 2, 2015 at 12:39 AM, Kepe= ng Li <kepeng.lkp@alibaba-inc.com> wrote:
At the fac= e-to-face meeting of the ACE working group in Yokohama, the participants in= the room decided to accept the OAuth profiling draft as a starting point f= or future work of the solution charter item:

For those who weren't present in the room, please let = us know whether you accept or object to this decision, before 17th Nov, 201= 5.

Thanks,

Kind Regards
Kepeng=C2=A0
<= /font>

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


--001a1137a2163a9fbd05238eeaae-- From nobody Mon Nov 2 19:08: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 24CBD1AD06E for ; Mon, 2 Nov 2015 19:08:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EnvTML9mQtU for ; Mon, 2 Nov 2015 19:08:12 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0762.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::762]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC38E1AD06C for ; Mon, 2 Nov 2015 19:08:09 -0800 (PST) Received: from DB4PR06CA0048.eurprd06.prod.outlook.com (10.160.40.176) by DB3PR06MB204.eurprd06.prod.outlook.com (10.141.2.26) with Microsoft SMTP Server (TLS) id 15.1.312.18; Tue, 3 Nov 2015 03:07:47 +0000 Received: from AM1FFO11FD054.protection.gbl (2a01:111:f400:7e00::141) by DB4PR06CA0048.outlook.office365.com (2a01:111:e400:9851::48) with Microsoft SMTP Server (TLS) id 15.1.312.18 via Frontend Transport; Tue, 3 Nov 2015 03:07:47 +0000 Authentication-Results: spf=pass (sender IP is 146.108.200.10) smtp.mailfrom=tridonic.com; alibaba-inc.com; dkim=none (message not signed) header.d=none;alibaba-inc.com; dmarc=bestguesspass action=none header.from=tridonic.com; Received-SPF: Pass (protection.outlook.com: domain of tridonic.com designates 146.108.200.10 as permitted sender) receiver=protection.outlook.com; client-ip=146.108.200.10; helo=ATBRAGMSX01.itiso.net; Received: from ATBRAGMSX01.itiso.net (146.108.200.10) by AM1FFO11FD054.mail.protection.outlook.com (10.174.65.73) with Microsoft SMTP Server (TLS) id 15.1.318.9 via Frontend Transport; Tue, 3 Nov 2015 03:07:47 +0000 Received: from ATBRAGMSX02.itiso.net ([169.254.2.210]) by ATBRAGMSX01.itiso.net ([146.108.41.69]) with mapi id 14.03.0248.002; Tue, 3 Nov 2015 04:07:46 +0100 From: Somaraju Abhinav To: Kepeng Li , "Ace@ietf.org" Thread-Topic: Solution direction Thread-Index: AQHRFTDij3HGto8HtE2QJZ9IGLIdTJ6JnyUb Date: Tue, 3 Nov 2015 03:07:45 +0000 Message-ID: <0E9A48AB39AF3547ACD28A6DE3E2906A0ED6F88E@ATBRAGMSX02.itiso.net> References: In-Reply-To: Accept-Language: en-US, de-AT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.108.8.124] Content-Type: multipart/alternative; boundary="_000_0E9A48AB39AF3547ACD28A6DE3E2906A0ED6F88EATBRAGMSX02itis_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD054; 1:e6LA5CGJvBPNGUZuUyZr0qPSDOi4R2qsLOZEaWy8AhpJVEF+EYbURGVL4wn/1iJj6W+E3sUrinZToHCZS9bWOajOdURbQiixcNq0x16un+KKLQNPzk91BpMGjxBb7MVySj+8kdfMaV/JLA3ZigHhD2NlzSs8vRSA1c6JGED+JrUiqg5R9Dxe5XUOqhCXFVyS0D3T+IsdvxvGdS6swxeK/ASsawBb1qzMXue38+mJwUpS4pkYHvIWnyeFucmL3W77bg4DpzfDjBaXuCcu/3GDIuTcGB5wRRGe2gA1HvdutSghf/itX8s+megAKBwrWfsP74rCDcfa+noFZsnQO0RvrchULRNyeKLFnxrDQap/am0= X-Forefront-Antispam-Report: CIP:146.108.200.10; CTRY:AT; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(2980300002)(438002)(199003)(377454003)(71364002)(189002)(164054003)(84326002)(55846006)(2920100001)(92566002)(76176999)(5007970100001)(2900100001)(5001960100002)(106116001)(5004730100002)(221733001)(11100500001)(102836002)(26826002)(15975445007)(87936001)(2950100001)(50986999)(33656002)(86362001)(54356999)(5008740100001)(5003600100002)(512934002)(53416004)(16236675004)(19580395003)(5890100001)(189998001)(66066001)(104016004)(5001770100001)(81156007)(19617315012)(69596002)(6806005)(106466001)(2501003)(19580405001)(300700001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR06MB204; H:ATBRAGMSX01.itiso.net; FPR:; SPF:Pass; PTR:unknown.zgrp.net; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DB3PR06MB204; 2:LhAhHO/J1OMMegaQpEd3093xFLGxNeZD6q9Rz9VU3s8jmB2VxUdJftagp7tyZughno+UjO81mUn24uGGK8VcFBL1vS/Q3Vah9Kap0WjWW2a8ftz3AoQGBey41DKGCIHGnfuJqaRv9XfpBL9DZStIWHl/VhtXZuNEBEZOijX3Cfo=; 3:P5+NMaM2sqEJVrpYbnL6Mkw0m/dtgdlz6Y5WmCy/vinsT8+wdoiVbQh/ZbofkURkdH3Hmcbr7iS2EJ2LfCT3V78wSrg9imt7Z9c8dysJhvVOVX1GCtkXn33Emk1pKXUq04RRGjni+rwTiRC66C61lAn7ONB7GZrkqNovhDwFXIiAnLzW58uxJzTKugWq2+S4gydzo8+IJfpySSiDeXDjYzhGqYqz5/QDx74dK/emjq0YdOh7TQ3lVhdlxDyPYFoeh+fyHmhI3r8OjV15LCDq3w==; 25:oE3eiEtsFmO3ragEhWfzLccz7NmtFzM+O5kkgANL7l71ZbEt1i3aKeEdxBG2VwrSpY5lKOk1lZ1A1JRdtaI2Y8DWheEYAiXRmI2sr+ZE4N5RiKDejqu+Ma3olG+/F6OR3iFA1CQ/Aur+WVGOnKUWV6xlAZHknQok6OuCCtIF7K+cH87N5OhWltpBYU3Ryd1UOuxldNHbciCc+kmaiyi2DhIYBNgwrDvHzJzIAdedvtprsfKmta26wuN7lE3un6ZfiVvqZWCyKKIt4kzfnUCD9A== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501001); SRVR:DB3PR06MB204; X-Microsoft-Exchange-Diagnostics: 1; DB3PR06MB204; 20:6dgFj2y2uqn+15SUw37n/aiL4lHiYQ61914QoSaZh6oORmgsqgcHwwpfAVpc6LD0aVt6pMsMRe+j1u4TJAYW2G4gsgqkvTFMe2pKJY0IdYgS+Z1EWhVJtd09/1c1D68z0L7h/5p4LRHohmTljAF2zFH6wAdlr6P+MJweArLGrKBgVC6SiBqdwHrRVee+AhO+GUjMii28NiJdyscH81E7cOPYLJ+HwzP7NJgslhP+qqVFOuI6u8B8jznKwTNL/pG2TFpZM5XChWEusZdIpGmXzgFMUKLp9gtDguoVGA1/4J8Vf81TscaYUlCXBhS5npLMNOMNEFGyyn114lA7HAtWu1k1naBhg/0g8Qk4JDZkyRZTVQ9+UVqOdIo0C0BfmtlwBu3L8o7/WSS85Q39U73sGI3aXQ/FLI6rQlCZu6Zb2oAj40CsinfnRrd1wjtiSHRI5iJ+r5Aib33bhPWdjT4vmvs9e3Ghf+zJhFgc7nvR1VpkXFfR9jvK2Lmjxk/hIsB9; 4:GjP54ZKEfG7gREsRX3UU4e3jvUEWDUnoWE43+OSNnuHKmJWjHf/+UoLs2pe608OTBfVfZRQzl0kJOjGpBEsYsurVcI4liMiYGetTDDUdJv6G36v+DPb3ZrW2tSj4S9bQbIvLiQS9ktPQVpqkIAsikrtFphsZabscAL0XF9ALwAMDOWcT/vo0XGfb/CQkQfoWOhPOQ7wOWE2QrBacfRzrj8a9UEGrqEH7LnsATqP7jTWU9OXHtI3AZoz0H1NwRmkofTaN851y0PTbCevfWg9M6JBrLHaHg5y0REMKGSwtPhJxV9csBEssttKyWhPyWH8vXQlZr961W5HS33hdW/Zw05WZkxW252OOdJtvPEgMMiWgPdocvavQcKrlHz0Su2/cnqpIP3DIAyhj4n6egJnElA== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:DB3PR06MB204; BCL:0; PCL:0; RULEID:; SRVR:DB3PR06MB204; X-Forefront-PRVS: 0749DC2CE6 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DB3PR06MB204; 23:gMbUsy5U4pw0JO0cYYa9MKLcII8ZJnB1jrkhJUhSlU?= =?us-ascii?Q?AQ6prmterOfg7NZcjj2NWl7qhpWdUM0nw1PZIi4oyLynEhAilpY775Yrtswm?= =?us-ascii?Q?3SsX2q6gfzKLrE9Gl/X6gbDULi+PKxIKOPmAsvB9L8jhA4CKNTWIiNy9jvrT?= =?us-ascii?Q?V29fw91XMFqUzzTWOcPeTPVcrxct2uteuNUSXKNqkBXloSoIy2pziNZxM6/G?= =?us-ascii?Q?hytXpHcF9g0FDJnK4ujZec2guqi8vhLsFXFRULAdIztxAdarQ/PG5gm+M6i1?= =?us-ascii?Q?h0dct1p/ap+LptsXXvi3oC3mbmk87Jif0/DC1nzqE+qRwGcLq5WdbvaogJrH?= =?us-ascii?Q?GuW0iUSkQ3h22Ti9Q1UkGhmqvgza+WOh+sPCYTd0mqOFOQE6fr8a90DefKHl?= =?us-ascii?Q?zRCT0wLNELJMXNK0IVFU7/H0rlnkcg7KU2mIZv8jyJtmF7xfgq2zKs4zczg3?= =?us-ascii?Q?FolH18NY9T22h3bhe63jm28rS+FCya913L7Ha5zzeMyZW9nU44i59/AYDyFp?= =?us-ascii?Q?8sY5HqWUeTr38HfonzynJ7XQq42XvIUN0z97GoLYK3ybWNp3Uzm4k/MNUP/Y?= =?us-ascii?Q?1l3mU2+3eURYxkYOXCZHG4S+K+CkpAkk/CUhZImQbY+XhmFd5f9V/z2B5It5?= =?us-ascii?Q?aobjwbdFTqU5iCt1Vz3JAd2ovsgQQ46fAs0WjTpDB9qBIQVAKS7YlmTE90uV?= =?us-ascii?Q?vTOjDwCHbHcGq1cthn59a2wRREZ3MQ7bqgpPomIOoh4p1GrhhTz40KS2H33x?= =?us-ascii?Q?1FM0qD5mzNF0b8gdigHIDvtp157hU0WGPL5aHUQqXJkRqeIKT9JB3EUslM+s?= =?us-ascii?Q?OolxFnE3PKKIEk1QjMeim6OLvgWYlNQp0DHIXDickV9fJsU7nOSzUTO6s1lb?= =?us-ascii?Q?+GBDjgsDQu6eZxFHHC2alT4D7f/6lc4S9560L/JrlxZVcnQdoUeXRToidC9W?= =?us-ascii?Q?vqtRyWEbC9wLg4ovg3VDDffnaOfvnOgPliQOXnIopXKIfTt02x2vtG6YrHEL?= =?us-ascii?Q?X1HCtmPHvZwz4998vskpg6WQhm3aU0F+/PWl2pNVHlcx6yhMHAlxIXPS+wzs?= =?us-ascii?Q?+Dy8cO6cRHDKVwUqMQArGF+ln1MOiMPmoItzI00TwqpsSDL1wDiyW76OjWuo?= =?us-ascii?Q?YzijiutlQ8+Lfw9ghbybaGb1QQB2DzyHTNmafxGA24oqeJZw9QknVxZJscCZ?= =?us-ascii?Q?zmYl4SHyCVi40k8w9Q0MLID/WvGCVdTkfGz9aD7nGmLNDTepHCqysQmHb9W4?= =?us-ascii?Q?cqTBaPUigWXytXKtvUQdKrMPygh7BnZYOKmOU/pC0VZXsY3CLq/OLEJh7RhQ?= =?us-ascii?Q?=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB3PR06MB204; 5:XOGcEziK+j73WTni8dIXDA+l1ln+77EKL74qY9+pVIWZNINa61pRolKzVmDoPKCjh9oSKNBrzl2ElbXVU6F5IaPvxTJHGYvESZgu5BvHAUIZV7LUoOLa2eg7eNwTMonfVRdMF4psM1MPlL9a1NU/DQ==; 24:setjMyj1CV+ubswJQ59G275cuqk4Ga7STa7tWJCOALUnnaG1e8EXIOhTeyEXgq26UKXEb2ibkuLD1alBTCTaKAs2YS2uOjawSwnCLZS3MEw=; 20:QoCcjPLWudI7SSkoEMof2JOL0x27QoSs9Wu2PXw5lxURFWxZELb6isMorUemC/J4JfMw62mG1vzZAmp/6g1v1g== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: tridonic.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Nov 2015 03:07:47.3865 (UTC) X-MS-Exchange-CrossTenant-Id: 8b206608-a593-4ace-a4b6-ef1fc83c9169 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8b206608-a593-4ace-a4b6-ef1fc83c9169; Ip=[146.108.200.10]; Helo=[ATBRAGMSX01.itiso.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR06MB204 Archived-At: Cc: Kathleen Moriarty , Hannes Tschofenig , Stephen Farrell Subject: Re: [Ace] Solution direction X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Nov 2015 03:08:15 -0000 --_000_0E9A48AB39AF3547ACD28A6DE3E2906A0ED6F88EATBRAGMSX02itis_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Accept. -Abhinav ________________________________ From: Ace [ace-bounces@ietf.org] on behalf of Kepeng Li [kepeng.lkp@alibaba= -inc.com] Sent: Monday, November 02, 2015 6:39 AM To: Ace@ietf.org Cc: Kathleen Moriarty; Hannes Tschofenig; Stephen Farrell Subject: [Ace] Solution direction At the face-to-face meeting of the ACE working group in Yokohama, the parti= cipants in the room decided to accept the OAuth profiling draft as a starti= ng point for future work of the solution charter item: http://datatracker.ietf.org/doc/draft-seitz-ace-oauth-authz/ For those who weren't present in the room, please let us know whether you a= ccept or object to this decision, before 17th Nov, 2015. Thanks, Kind Regards Kepeng ________________________________________________________ The contents of th= is e-mail and any attachments are confidential to the intended recipient. T= hey may not be disclosed to or used by or copied in any way by anyone other= than the intended recipient. If this e-mail is received in error, please i= mmediately notify the sender and delete the e-mail and attached documents. = Please note that neither the sender nor the sender's company accept any res= ponsibility for viruses and it is your responsibility to scan or otherwise = check this e-mail and any attachments. --_000_0E9A48AB39AF3547ACD28A6DE3E2906A0ED6F88EATBRAGMSX02itis_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Accept.
-Abhinav

From: Ace [ace-bounces@ietf.org] on behal= f of Kepeng Li [kepeng.lkp@alibaba-inc.com]
Sent: Monday, November 02, 2015 6:39 AM
To: Ace@ietf.org
Cc: Kathleen Moriarty; Hannes Tschofenig; Stephen Farrell
Subject: [Ace] Solution direction

At the face-to-face meeting of the ACE working group in Yokohama, the = participants in the room decided to accept the OAuth profiling draft as a s= tarting point for future work of the solution charter item:

For those who weren't present in the room, please let us know whether = you accept or object to this decision, before 17th Nov, 2015.

Thanks,

Kind Regards
Kepeng 
________________________________________________________ The contents of th= is e-mail and any attachments are confidential to the intended recipient. T= hey may not be disclosed to or used by or copied in any way by anyone other= than the intended recipient. If this e-mail is received in error, please immediately notify the sender and= delete the e-mail and attached documents. Please note that neither the sen= der nor the sender's company accept any responsibility for viruses and it i= s your responsibility to scan or otherwise check this e-mail and any attachments. --_000_0E9A48AB39AF3547ACD28A6DE3E2906A0ED6F88EATBRAGMSX02itis_-- From nobody Fri Nov 6 09:22: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 D149F1B2B83 for ; Fri, 6 Nov 2015 09:22:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42bhLx8YivGw for ; Fri, 6 Nov 2015 09:22:08 -0800 (PST) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (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 33CB81B2C8E for ; Fri, 6 Nov 2015 09:20:21 -0800 (PST) Received: by qgeb1 with SMTP id b1so43537258qge.1 for ; Fri, 06 Nov 2015 09:20:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman_se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LfbGnhe86/37WuTAs+yLBn4PLoiihBtbPdtcGUupekM=; b=csiXUUyhQ/X3F67xmhPDv3IsYWi1NpTA+unDkU1MhFR+4dvZEq+E9DgIqmjjAqDRD2 tfi2N/qLDbqKpQihyACHJ+8uBw2cLjwvzraxx8qkYwdjS0La/T64aHAcrAjRe70RpMFa W//YiI7RiB9Veqwpv8RqsjZz3pnXWH3PrJ8nHVfcXvUK8ZoMcdoVCC/opDCm0pSlxdAR P7xoj46GHyiNvrOQNo3L3rlCRYtFmHi0lV3ayX3KTuvCaZGX9HxczgIAyEQfNv5GeArl S6imga2RfxYjKq0dnpmivhfZM4JUCJdUMtXerVGsjWlxK55JT9EMSSh6yiT6v1XwYREs nnPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LfbGnhe86/37WuTAs+yLBn4PLoiihBtbPdtcGUupekM=; b=EP4sG175U7zte+KBrHtFSGvsN5dR2vH8nupqkt+WFr0Cs3FU7tGUWD70g4O/RF7ywU wf3hXq2v6EI5VpgsH+xKMLxSVrob+gOwHSG4LHAw6ezB1ckYsPGkBSrOd2hC1ZJuCm5S QYjjZONsNBKtDwKeVAdajqzcuav9xVhVC4Q4vmMJwJZD3huAfjvBiiFApN7GYI0LENpe XJejUAauFUOORQ6/1qCs+R5Ui7Vv81EXc6NXDDLZIdzJa/4x+AQgS9othlG29blbvuKB iBE1dctZfN1L1uc2hZ1Nl9ovCFs2r2m7zFtshyEYH4VdGdbvKkWDZvgFuV4mk4gnlKe9 i2zQ== X-Gm-Message-State: ALoCoQkGW9/oYSu+aP8yjM6MAFSuTg5b7Fp4nEWO4ggdjT45WlS7BW3VUyIa5CvBCxYfoj82Vnnp MIME-Version: 1.0 X-Received: by 10.140.171.197 with SMTP id r188mr15658618qhr.93.1446830420121; Fri, 06 Nov 2015 09:20:20 -0800 (PST) Received: by 10.55.181.69 with HTTP; Fri, 6 Nov 2015 09:20:20 -0800 (PST) In-Reply-To: References: Date: Fri, 6 Nov 2015 18:20:20 +0100 Message-ID: From: Samuel Erdtman To: Kepeng Li Content-Type: multipart/alternative; boundary=001a113a7dfa3df92c0523e27537 Archived-At: Cc: Stephen Farrell , Kathleen Moriarty , Hannes Tschofenig , "Ace@ietf.org" Subject: Re: [Ace] Solution direction X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Nov 2015 17:22:11 -0000 --001a113a7dfa3df92c0523e27537 Content-Type: text/plain; charset=UTF-8 Accept! Best Regards //Samuel Erdtman On Mon, Nov 2, 2015 at 6:39 AM, Kepeng Li wrote: > At the face-to-face meeting of the ACE working group in Yokohama, the > participants in the room decided to accept the OAuth profiling draft as a > starting point for future work of the solution charter item: > http://datatracker.ietf.org/doc/draft-seitz-ace-oauth-authz/ > > For those who weren't present in the room, please let us know whether you > accept or object to this decision, before 17th Nov, 2015. > > Thanks, > > Kind Regards > Kepeng > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > --001a113a7dfa3df92c0523e27537 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Accept!

Best Regards
//Samuel Erdtman

On Mon, Nov 2, 2015 at 6:39 AM, Kepeng Li <kepeng.lkp@alibaba-inc.com> wrote:
At the face-to-face meeti= ng of the ACE working group in Yokohama, the participants in the room decid= ed to accept the OAuth profiling draft as a starting point for future work = of the solution charter item:

For those who weren't present in the room, please let us know whether= you accept or object to this decision, before 17th Nov, 2015.
Thanks,

Kind Regards
Kepeng=C2=A0
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace


--001a113a7dfa3df92c0523e27537-- From nobody Thu Nov 12 10:31: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 5FC491B2D65; Thu, 12 Nov 2015 10:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKNhgYgXgzbh; Thu, 12 Nov 2015 10:30:47 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E19871B2BF3; Thu, 12 Nov 2015 10:30:47 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id B868D880E4; Thu, 12 Nov 2015 10:30:47 -0800 (PST) Received: from clemson.jhuapl.edu (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id DD167328081A; Thu, 12 Nov 2015 10:30:44 -0800 (PST) References: <20151110200512.31690.50934.idtracker@ietfa.amsl.com> To: "6lo@ietf.org" <6lo@ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org>, "ipv6@ietf.org" , ace@ietf.org, core@ietf.org, lwip@ietf.org, "int-area@ietf.org" From: Brian Haberman X-Forwarded-Message-Id: <20151110200512.31690.50934.idtracker@ietfa.amsl.com> Message-ID: <5644DAD3.30904@innovationslab.net> Date: Thu, 12 Nov 2015 13:30:43 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151110200512.31690.50934.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="trg4vLsdRRleRJ6mNX2lSlQg4MIMxuxps" Archived-At: Subject: [Ace] Fwd: New Non-WG Mailing List: lp-wan -- Low-Power Wide Area Networking (LP-WAN), also known as LPWA or Low-Rate WAN (LR-WAN) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 12 Nov 2015 18:30:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --trg4vLsdRRleRJ6mNX2lSlQg4MIMxuxps Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable All, This new mailing list may be of interest. It is hosting discussion on deploying IP on very constrained wireless systems. Regards, Brian -------- Forwarded Message -------- Subject: New Non-WG Mailing List: lp-wan -- Low-Power Wide Area Networking (LP-WAN), also known as LPWA or Low-Rate WAN (LR-WAN) Date: Tue, 10 Nov 2015 12:05:12 -0800 From: IETF Secretariat Reply-To: ietf@ietf.org To: IETF Announcement List A new IETF non-working group email list has been created. List address: lp-wan@ietf.org Archive: https://mailarchive.ietf.org/arch/search/?email_list=3Dlp-wan To subscribe: https://www.ietf.org/mailman/listinfo/lp-wan Purpose: An LP-WAN has unique constraints, not seen until now - operation in the ISM bands (unlicensed spectrum), very low throughput (300 bps - 50 kbps), very high density (10 000-100 000 nodes per Access Point (AP)), infrastructure networks (star topology, no need for routing), AP diversity (several APs can receive the same signal), coexistence of public networks (country-wide) and private networks (city, building, campus). Asymmetric links are also common, with at least one major technology providing exclusively unidirectional data services. LP-WANs will form the backbone of major IoT applications related to many domains, such as Smart City, Smart Metering, ITS and are expected to connect 3 billion devices by 2020. There are several such LP- WAN radio technologies (Semtech LoRa, SigFox, Qowisio, others), each having a proprietary, locked-in, non-standard solution for addressing, localization, security, provisioning, AAA, etc. This is the case because the stringent LP-WAN constraints do not allow for classical approaches to be used as-is. The goal of this mailing list is to discuss the problems that arise in LP-WANs and how the IETF-based solutions apply to them. This is the place to identify the candidate LP-WAN technologies, their specific constraints and limitations, consider the corresponding IETF approaches, and discuss the need for profiles or adaptations of the existing solution= s. For additional information, please contact the list administrators. --trg4vLsdRRleRJ6mNX2lSlQg4MIMxuxps Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJWRNrTAAoJEBOZRqCi7goqpCMH/AxkhQOfVmCb3kFawBqNTAOb /sbMFYyh3glVxOsQersJAbvaXIFrx4qnJAj7nh35NmVm4d1YQO5zuocJRfUg6NSk 74+sZAGKYaheJz3QDhf6sd8bceS7gNlkhFvgT327SKslSVEqCWyCHSFRBtdMhchk oPrfuAmrmmk/TTEFHLYVoBX+eViEnGxCwMu+Jq/bQLTc9XFPRn7WQ7LRN/p/rbHR u7MODoBAYxRZ2ItnYuMaaUFp421G65HZkkRra63kCw6BXE9sc6vtvwlmsuOFzGcl o94gi6ZbTTYJj3CKoAu43eZxiTzq9eXeBCiAyELIO6vcbpIy7/+rMZ5s5uDeCo8= =ETmP -----END PGP SIGNATURE----- --trg4vLsdRRleRJ6mNX2lSlQg4MIMxuxps-- From nobody Thu Nov 12 11:10: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 478C61B3151; Thu, 12 Nov 2015 11:10:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1e_UILfDlpT; Thu, 12 Nov 2015 11:10:20 -0800 (PST) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 945821B3150; Thu, 12 Nov 2015 11:10:19 -0800 (PST) Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX01.ad.nexusgroup.com (10.75.28.40) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 12 Nov 2015 20:10:17 +0100 Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0995.032; Thu, 12 Nov 2015 20:10:17 +0100 From: =?utf-8?B?RXJpayBXYWhsc3Ryw7ZtIG5lWHVz?= To: "" , "ace@ietf.org" , "cose@ietf.org" Thread-Topic: A draft on CBOR Web Tokens (CWT) Thread-Index: AQHRHX3DyXQEi0Hb60mPSXqbnVxSew== Date: Thu, 12 Nov 2015 19:10:16 +0000 Message-ID: <53BB1987-979C-4945-9C7D-CDB6619AEFFC@nexusgroup.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2104) x-originating-ip: [37.247.26.197] Content-Type: multipart/alternative; boundary="_000_53BB1987979C49459C7DCDB6619AEFFCnexusgroupcom_" MIME-Version: 1.0 Archived-At: Cc: Mike Jones , Hannes Tschofenig Subject: [Ace] A draft on CBOR Web Tokens (CWT) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 12 Nov 2015 19:10:23 -0000 --_000_53BB1987979C49459C7DCDB6619AEFFCnexusgroupcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkluIHRoZSBBQ0UgV0cgYSBzdHJhdyBtYW4gcHJvcG9zYWwgb2YgYSBDQk9SIFdlYiBU b2tlbiAoQ1dUKSB3YXMgZGVmaW5lZCBpbiB0aGUgZHJhZnQgIkF1dGhvcml6YXRpb24gZm9yIHRo ZSBJbnRlcm5ldCBvZiBUaGluZ3MgdXNpbmcgT0F1dGggMi4w4oCdIFsxXS4gV2UganVzdCBicm9r ZSBvdXQgdGhlIENCT1IgV2ViIFRva2VuIGludG8gYSBzZXBhcmF0ZSBkcmFmdCBhbmQgdGhlIG5l dyBkcmFmdCBpcyBzdWJtaXR0ZWQgdG8gdGhlIE9BVVRIIFdHLiBJdCBjYW4gYmUgZm91bmQgaGVy ZToNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd2FobHN0cm9lbS1v YXV0aC1jYm9yLXdlYi10b2tlbi8NCg0KQWJzdHJhY3Q6DQoiQ0JPUiBXZWIgVG9rZW4gKENXVCkg aXMgYSBjb21wYWN0IG1lYW5zIG9mIHJlcHJlc2VudGluZyBjbGFpbXMgdG8gYmUgdHJhbnNmZXJy ZWQgYmV0d2VlbiB0d28gcGFydGllcy4gIENXVCBpcyBhIHByb2ZpbGUgb2YgdGhlIEpTT04gV2Vi IFRva2VuIChKV1QpIHRoYXQgaXMgb3B0aW1pemVkIGZvciBjb25zdHJhaW5lZCBkZXZpY2VzLiBU aGUgY2xhaW1zIGluIGEgQ1dUIGFyZSBlbmNvZGVkIGluIHRoZSBDb25jaXNlIEJpbmFyeSBPYmpl Y3QgUmVwcmVzZW50YXRpb24gKENCT1IpIGFuZCBDQk9SIE9iamVjdCBTaWduaW5nIGFuZCBFbmNy eXB0aW9uIChDT1NFKSBpcyB1c2VkIGZvciBhZGRlZCBhcHBsaWNhdGlvbiBsYXllciBzZWN1cml0 eSBwcm90ZWN0aW9uLiAgQSBjbGFpbSBpcyBhIHBpZWNlIG9mIGluZm9ybWF0aW9uIGFzc2VydGVk IGFib3V0IGEgc3ViamVjdCBhbmQgaXMgcmVwcmVzZW50ZWQgYXMgYSBuYW1lL3ZhbHVlIHBhaXIg Y29uc2lzdGluZyBvZiBhIGNsYWltIG5hbWUgYW5kIGEgY2xhaW0gdmFsdWUuIg0KDQovIEVyaWsN Cg0KDQpbMV0gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNlaXR6LWFjZS1vYXV0 aC1hdXRoei0wMA0KDQoNCg== --_000_53BB1987979C49459C7DCDB6619AEFFCnexusgroupcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGksDQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JbiB0aGUgQUNFIFdHIGEgc3RyYXcg bWFuIHByb3Bvc2FsIG9mIGEgQ0JPUiBXZWIgVG9rZW4gKENXVCkgd2FzIGRlZmluZWQgaW4gdGhl IGRyYWZ0ICZxdW90O0F1dGhvcml6YXRpb24gZm9yIHRoZSBJbnRlcm5ldCBvZiBUaGluZ3MgdXNp bmcgT0F1dGggMi4w4oCdIFsxXS4gV2UganVzdCBicm9rZSBvdXQgdGhlIENCT1IgV2ViIFRva2Vu IGludG8gYSBzZXBhcmF0ZSBkcmFmdCBhbmQgdGhlIG5ldyBkcmFmdCZuYnNwO2lzIHN1Ym1pdHRl ZCB0bw0KIHRoZSBPQVVUSCBXRy4gSXQgY2FuIGJlIGZvdW5kIGhlcmU6Jm5ic3A7PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YSBocmVm PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13YWhsc3Ryb2VtLW9hdXRo LWNib3Itd2ViLXRva2VuLyIgY2xhc3M9IiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtd2FobHN0cm9lbS1vYXV0aC1jYm9yLXdlYi10b2tlbi88L2E+PC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5BYnN0cmFjdDom bmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+JnF1b3Q7Q0JPUiBXZWIgVG9rZW4gKENXVCkgaXMg YSBjb21wYWN0IG1lYW5zIG9mIHJlcHJlc2VudGluZyBjbGFpbXMgdG8gYmUgdHJhbnNmZXJyZWQg YmV0d2VlbiB0d28gcGFydGllcy4gJm5ic3A7Q1dUIGlzIGEgcHJvZmlsZSBvZiB0aGUgSlNPTiBX ZWIgVG9rZW4gKEpXVCkgdGhhdCBpcyBvcHRpbWl6ZWQgZm9yIGNvbnN0cmFpbmVkIGRldmljZXMu IFRoZSBjbGFpbXMgaW4gYSBDV1QgYXJlIGVuY29kZWQgaW4gdGhlIENvbmNpc2UgQmluYXJ5DQog T2JqZWN0IFJlcHJlc2VudGF0aW9uIChDQk9SKSBhbmQgQ0JPUiBPYmplY3QgU2lnbmluZyBhbmQg RW5jcnlwdGlvbiAoQ09TRSkgaXMgdXNlZCBmb3IgYWRkZWQgYXBwbGljYXRpb24gbGF5ZXIgc2Vj dXJpdHkgcHJvdGVjdGlvbi4gJm5ic3A7QSBjbGFpbSBpcyBhIHBpZWNlIG9mIGluZm9ybWF0aW9u IGFzc2VydGVkIGFib3V0IGEgc3ViamVjdCBhbmQgaXMgcmVwcmVzZW50ZWQgYXMgYSBuYW1lL3Zh bHVlIHBhaXIgY29uc2lzdGluZyBvZiBhIGNsYWltIG5hbWUNCiBhbmQgYSBjbGFpbSB2YWx1ZS4m cXVvdDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPi8gRXJpazwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+WzFdJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNlaXR6LWFjZS1vYXV0aC1hdXRoei0wMCIgY2xhc3M9 IiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNlaXR6LWFjZS1vYXV0aC1hdXRo ei0wMDwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_53BB1987979C49459C7DCDB6619AEFFCnexusgroupcom_-- From nobody Thu Nov 12 11:45: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 EC1EF1B32EE; Thu, 12 Nov 2015 11:45:13 -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 ZAZlbFix0uNu; Thu, 12 Nov 2015 11:45:12 -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 1FBDC1B32F0; Thu, 12 Nov 2015 11:45:10 -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 tACJj54u003493; Thu, 12 Nov 2015 20:45:05 +0100 (CET) Received: from nar.local (p5DC7F6AE.dip0.t-ipconnect.de [93.199.246.174]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nxYL94qc1z2GC8; Thu, 12 Nov 2015 20:45:05 +0100 (CET) Message-ID: <5644EC40.4010002@tzi.org> Date: Thu, 12 Nov 2015 20:45:04 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: =?UTF-8?B?RXJpayBXYWhsc3Ryw7ZtIG5lWHVz?= References: <53BB1987-979C-4945-9C7D-CDB6619AEFFC@nexusgroup.com> In-Reply-To: <53BB1987-979C-4945-9C7D-CDB6619AEFFC@nexusgroup.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Hannes Tschofenig , Mike Jones , "cose@ietf.org" , "" , "ace@ietf.org" Subject: Re: [Ace] [COSE] A draft on CBOR Web Tokens (CWT) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 12 Nov 2015 19:45:14 -0000 Hi Erik, having this draft is a good thing. One thing I'm still wondering is what WG is the best place to progress this. We probably don't need to spend too much time on this because, regardless of the WG chosen, the people in another WG can look at it. Still, getting this right might provide some efficiencies. What is the technical content of this draft? Is it a new token that OAuth needs specifically for the new COSE-based applications of OAuth? Is it a new token that is specifically there for addressing ACE needs? Or is it essentially the same substance as JWT, but phrased in and profiled for CBOR? Depending on the answer, CWT should be done in OAuth, ACE, or COSE. (I'd rather hear the answer from the authors than venture a guess myself.) Grüße, Carsten Erik Wahlström neXus wrote: > Hi, > > In the ACE WG a straw man proposal of a CBOR Web Token (CWT) was defined > in the draft "Authorization for the Internet of Things using OAuth 2.0†> [1]. We just broke out the CBOR Web Token into a separate draft and the > new draft is submitted to the OAUTH WG. It can be found here: > > https://datatracker.ietf.org/doc/draft-wahlstroem-oauth-cbor-web-token/ > > Abstract: > "CBOR Web Token (CWT) is a compact means of representing claims to be > transferred between two parties. CWT is a profile of the JSON Web Token > (JWT) that is optimized for constrained devices. The claims in a CWT are > encoded in the Concise Binary Object Representation (CBOR) and CBOR > Object Signing and Encryption (COSE) is used for added application layer > security protection. A claim is a piece of information asserted about a > subject and is represented as a name/value pair consisting of a claim > name and a claim value." > > / Erik > > > [1] https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00 > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Thu Nov 12 12:01:48 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B441B339A; Thu, 12 Nov 2015 12:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiIJZOOvm9Ct; Thu, 12 Nov 2015 12:01:42 -0800 (PST) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B19D71B33AC; Thu, 12 Nov 2015 12:01:27 -0800 (PST) Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX02.ad.nexusgroup.com (10.75.28.43) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 12 Nov 2015 21:01:25 +0100 Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0995.032; Thu, 12 Nov 2015 21:01:25 +0100 From: =?utf-8?B?RXJpayBXYWhsc3Ryw7ZtIG5lWHVz?= To: Carsten Bormann Thread-Topic: [COSE] A draft on CBOR Web Tokens (CWT) Thread-Index: AQHRHX3EcFviJsoC2k6K5CeJemK0A56YuYEAgAAEkAA= Date: Thu, 12 Nov 2015 20:01:24 +0000 Message-ID: <73929C18-A3E7-4ACA-A6DC-5A7AD7576C9B@nexusgroup.com> References: <53BB1987-979C-4945-9C7D-CDB6619AEFFC@nexusgroup.com> <5644EC40.4010002@tzi.org> In-Reply-To: <5644EC40.4010002@tzi.org> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2104) x-originating-ip: [37.247.26.197] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Hannes Tschofenig , Mike Jones , "cose@ietf.org" , "" , "ace@ietf.org" Subject: Re: [Ace] [COSE] A draft on CBOR Web Tokens (CWT) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 12 Nov 2015 20:01:45 -0000 SGkgQ2Fyc3RlbiwNCg0KVGhhbmtzLCBhbmQgSSBhZ3JlZS4gSeKAmXZlIGhlYXJkIGFyZ3VtZW50 cyBmb3IgYWxsIHRocmVlIHdvcmsgZ3JvdXBzLg0KDQpCb3Jyb3dlZCBzb21lIG9mIHlvdXIgd29y ZHMgdG8gZGVmaW5lIHRoZSBjb250ZW50IG9mIHRoZSBkcmFmdCA6KQ0KSXTigJlzIGl0IGVzc2Vu dGlhbGx5IGEgSldULCBwaHJhc2VkIGluIGFuZCBwcm9maWxlZCBmb3IgQ0JPUiB0byBhZGRyZXNz IEFDRSBuZWVkcywgd2hlcmUgT0F1dGggbmVlZHMgQ09TRSBmdW5jdGlvbmFsaXR5LCBmb3Igb2Jq ZWN0IHNlY3VyaXR5Lg0KDQpJ4oCZbSBvcGVuIGZvciBsZXR0aW5nIHRoZSBBROKAmXMgbW92ZSBp dCBhcm91bmQsIGJ1dCBoYXZpbmcgaXQgcmlnaHQgbmV4dCB0byBKV1Qgc2VlbXMgcmlnaHQgdG8g bWUuIEFsc28gb3BlbiBmb3IgdGhlIEFDRSBXRy4gRmVlbCBpdCBoYXMgbGVzcyBwbGFjZSBpbiBD T1NFIGZvciB0aGUgc2FtZSByZWFzb25zIEpXVCBpcyBub3QgaW4gdGhlIEpPU0UgV0cuDQoNCi8g RXJpaw0KDQoNCj4gT24gMTIgTm92IDIwMTUsIGF0IDIwOjQ1LCBDYXJzdGVuIEJvcm1hbm4gPGNh Ym9AdHppLm9yZz4gd3JvdGU6DQo+IA0KPiBIaSBFcmlrLA0KPiANCj4gaGF2aW5nIHRoaXMgZHJh ZnQgaXMgYSBnb29kIHRoaW5nLg0KPiANCj4gT25lIHRoaW5nIEknbSBzdGlsbCB3b25kZXJpbmcg aXMgd2hhdCBXRyBpcyB0aGUgYmVzdCBwbGFjZSB0byBwcm9ncmVzcw0KPiB0aGlzLiAgV2UgcHJv YmFibHkgZG9uJ3QgbmVlZCB0byBzcGVuZCB0b28gbXVjaCB0aW1lIG9uIHRoaXMgYmVjYXVzZSwN Cj4gcmVnYXJkbGVzcyBvZiB0aGUgV0cgY2hvc2VuLCB0aGUgcGVvcGxlIGluIGFub3RoZXIgV0cg Y2FuIGxvb2sgYXQgaXQuDQo+IFN0aWxsLCBnZXR0aW5nIHRoaXMgcmlnaHQgbWlnaHQgcHJvdmlk ZSBzb21lIGVmZmljaWVuY2llcy4NCj4gDQo+IFdoYXQgaXMgdGhlIHRlY2huaWNhbCBjb250ZW50 IG9mIHRoaXMgZHJhZnQ/ICBJcyBpdCBhIG5ldyB0b2tlbiB0aGF0DQo+IE9BdXRoIG5lZWRzIHNw ZWNpZmljYWxseSBmb3IgdGhlIG5ldyBDT1NFLWJhc2VkIGFwcGxpY2F0aW9ucyBvZiBPQXV0aD8N Cj4gSXMgaXQgYSBuZXcgdG9rZW4gdGhhdCBpcyBzcGVjaWZpY2FsbHkgdGhlcmUgZm9yIGFkZHJl c3NpbmcgQUNFIG5lZWRzPw0KPiBPciBpcyBpdCBlc3NlbnRpYWxseSB0aGUgc2FtZSBzdWJzdGFu Y2UgYXMgSldULCBidXQgcGhyYXNlZCBpbiBhbmQNCj4gcHJvZmlsZWQgZm9yIENCT1I/DQo+IA0K PiBEZXBlbmRpbmcgb24gdGhlIGFuc3dlciwgQ1dUIHNob3VsZCBiZSBkb25lIGluIE9BdXRoLCBB Q0UsIG9yIENPU0UuDQo+IChJJ2QgcmF0aGVyIGhlYXIgdGhlIGFuc3dlciBmcm9tIHRoZSBhdXRo b3JzIHRoYW4gdmVudHVyZSBhIGd1ZXNzIG15c2VsZi4pDQo+IA0KPiBHcsO8w59lLCBDYXJzdGVu DQo+IA0KPiANCj4gDQo+IEVyaWsgV2FobHN0csO2bSBuZVh1cyB3cm90ZToNCj4+IEhpLA0KPj4g DQo+PiBJbiB0aGUgQUNFIFdHIGEgc3RyYXcgbWFuIHByb3Bvc2FsIG9mIGEgQ0JPUiBXZWIgVG9r ZW4gKENXVCkgd2FzIGRlZmluZWQNCj4+IGluIHRoZSBkcmFmdCAiQXV0aG9yaXphdGlvbiBmb3Ig dGhlIEludGVybmV0IG9mIFRoaW5ncyB1c2luZyBPQXV0aCAyLjDigJ0NCj4+IFsxXS4gV2UganVz dCBicm9rZSBvdXQgdGhlIENCT1IgV2ViIFRva2VuIGludG8gYSBzZXBhcmF0ZSBkcmFmdCBhbmQg dGhlDQo+PiBuZXcgZHJhZnQgaXMgc3VibWl0dGVkIHRvIHRoZSBPQVVUSCBXRy4gSXQgY2FuIGJl IGZvdW5kIGhlcmU6IA0KPj4gDQo+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC13YWhsc3Ryb2VtLW9hdXRoLWNib3Itd2ViLXRva2VuLw0KPj4gDQo+PiBBYnN0cmFjdDog DQo+PiAiQ0JPUiBXZWIgVG9rZW4gKENXVCkgaXMgYSBjb21wYWN0IG1lYW5zIG9mIHJlcHJlc2Vu dGluZyBjbGFpbXMgdG8gYmUNCj4+IHRyYW5zZmVycmVkIGJldHdlZW4gdHdvIHBhcnRpZXMuICBD V1QgaXMgYSBwcm9maWxlIG9mIHRoZSBKU09OIFdlYiBUb2tlbg0KPj4gKEpXVCkgdGhhdCBpcyBv cHRpbWl6ZWQgZm9yIGNvbnN0cmFpbmVkIGRldmljZXMuIFRoZSBjbGFpbXMgaW4gYSBDV1QgYXJl DQo+PiBlbmNvZGVkIGluIHRoZSBDb25jaXNlIEJpbmFyeSBPYmplY3QgUmVwcmVzZW50YXRpb24g KENCT1IpIGFuZCBDQk9SDQo+PiBPYmplY3QgU2lnbmluZyBhbmQgRW5jcnlwdGlvbiAoQ09TRSkg aXMgdXNlZCBmb3IgYWRkZWQgYXBwbGljYXRpb24gbGF5ZXINCj4+IHNlY3VyaXR5IHByb3RlY3Rp b24uICBBIGNsYWltIGlzIGEgcGllY2Ugb2YgaW5mb3JtYXRpb24gYXNzZXJ0ZWQgYWJvdXQgYQ0K Pj4gc3ViamVjdCBhbmQgaXMgcmVwcmVzZW50ZWQgYXMgYSBuYW1lL3ZhbHVlIHBhaXIgY29uc2lz dGluZyBvZiBhIGNsYWltDQo+PiBuYW1lIGFuZCBhIGNsYWltIHZhbHVlLiINCj4+IA0KPj4gLyBF cmlrDQo+PiANCj4+IA0KPj4gWzFdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1z ZWl0ei1hY2Utb2F1dGgtYXV0aHotMDANCj4+IA0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gQ09TRSBtYWlsaW5nIGxpc3QNCj4+IENP U0VAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29z ZQ0KDQo= From nobody Thu Nov 12 13:02: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 630B01B2DAB; Thu, 12 Nov 2015 13:02:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 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, 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 aJhmDWatyTR7; Thu, 12 Nov 2015 13:02:12 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05B0E1B2CB2; Thu, 12 Nov 2015 13:02:10 -0800 (PST) X-AuditID: 1209190f-f79d06d000004b20-b5-5644fe5131c3 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-4.mit.edu (Symantec Messaging Gateway) with SMTP id 07.69.19232.15EF4465; Thu, 12 Nov 2015 16:02:09 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id tACL28Ag017398; Thu, 12 Nov 2015 16:02:08 -0500 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tACL255e013631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Nov 2015 16:02:06 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_C6D98A78-6AB4-405D-80A6-BB4D661F8B40" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: <53BB1987-979C-4945-9C7D-CDB6619AEFFC@nexusgroup.com> Date: Thu, 12 Nov 2015 16:02:05 -0500 Message-Id: <519F98B0-E02B-4827-9862-8F7AAF87FEA2@mit.edu> References: <53BB1987-979C-4945-9C7D-CDB6619AEFFC@nexusgroup.com> To: =?utf-8?Q?Erik_Wahlstr=C3=B6m_neXus?= X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDKsWRmVeSWpSXmKPExsUixCmqrRv4zyXM4N1uWYvv33qYLaZtncpq cWzXYjaLmzNOMVnsnfaJxeLk21dsDmwea+atYfRYsuQnk0frjr/sHlvv/2YMYInisklJzcks Sy3St0vgyvg0bQNzQbd2xcJVbWwNjHNVuxg5OCQETCQmbTPrYuQEMsUkLtxbzwZiCwksZpL4 8KC4i5ELyN7IKHHr6V9WCOchk8SFI+1MIFXMAgkSS/vmsoDYvAJ6Eq9uXWYFGSoMNPTX51yQ MJuAqsT0NS1g5ZwCThLXt60GW8ACFF9xYyk7xJjbjBKLOgUgxlhJvLw/lQniCEeJxmW3mEFs EQFPiZsn/7NAHCorsfv3I6YJjAKzkFwxC8kVEHFtiWULXzND2JoS+7uXs2CKa0h0fpvIuoCR bRWjbEpulW5uYmZOcWqybnFyYl5eapGuiV5uZoleakrpJkZwpEjy72D8dlDpEKMAB6MSD++O Fy5hQqyJZcWVuYcYJTmYlER5pd4AhfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwLn4GlONNSays Si3Kh0lJc7AoifNu+sEXIiSQnliSmp2aWpBaBJOV4eBQkuDN/wvUKFiUmp5akZaZU4KQZuLg BBnOAzQ8CaSGt7ggMbc4Mx0if4pRUUqctwYkIQCSyCjNg+sFJbKEt4dNXzGKA70izBsBUsUD TIJw3a+ABjMBDf4i4QQyuCQRISXVwOjS/nK//sNG6VnZPxUrXx4znyHd/+jYC9mzfku+iz16 Yyo9xd726a2IrU88LgXJLmDoL7VvPLleWPOnJOutUmv7SwwlKabyK4Ua/tgFZFz6r3DswMmF h96f79meJbXbdtv+eZHf/ryfeYn1lfry8pnl3e8T/6+Pvqc9z3b/zaS2c75bwrsSrjIqsRRn JBpqMRcVJwIAxjqTyj8DAAA= Archived-At: Cc: Hannes Tschofenig , Mike Jones , "cose@ietf.org" , "" , "ace@ietf.org" Subject: Re: [Ace] [COSE] A draft on CBOR Web Tokens (CWT) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 12 Nov 2015 21:02:14 -0000 --Apple-Mail=_C6D98A78-6AB4-405D-80A6-BB4D661F8B40 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks very much, Eric. As we promised in Yokohama, the chairs of the COSE working group are = currently running a consensus call thread about this very topic, and = I=E2=80=99d encourage others to join that discussion. The thread starts = here: http://www.ietf.org/mail-archive/web/cose/current/msg00747.html =E2=80=94 Justin > On Nov 12, 2015, at 2:10 PM, Erik Wahlstr=C3=B6m neXus = wrote: >=20 > Hi, >=20 > In the ACE WG a straw man proposal of a CBOR Web Token (CWT) was = defined in the draft "Authorization for the Internet of Things using = OAuth 2.0=E2=80=9D [1]. We just broke out the CBOR Web Token into a = separate draft and the new draft is submitted to the OAUTH WG. It can be = found here:=20 >=20 > = https://datatracker.ietf.org/doc/draft-wahlstroem-oauth-cbor-web-token/ = >=20 > Abstract:=20 > "CBOR Web Token (CWT) is a compact means of representing claims to be = transferred between two parties. CWT is a profile of the JSON Web Token = (JWT) that is optimized for constrained devices. The claims in a CWT are = encoded in the Concise Binary Object Representation (CBOR) and CBOR = Object Signing and Encryption (COSE) is used for added application layer = security protection. A claim is a piece of information asserted about a = subject and is represented as a name/value pair consisting of a claim = name and a claim value." >=20 > / Erik >=20 >=20 > [1] https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00 = >=20 >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose --Apple-Mail=_C6D98A78-6AB4-405D-80A6-BB4D661F8B40 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks very much, Eric.

As we promised in Yokohama, the chairs = of the COSE working group are currently running a consensus call thread = about this very topic, and I=E2=80=99d encourage others to join that = discussion. The thread starts here:

http://www.ietf.org/mail-archive/web/cose/current/msg00747.html=

 =E2=80= =94 Justin

On Nov 12, 2015, at 2:10 PM, = Erik Wahlstr=C3=B6m neXus <erik.wahlstrom@nexusgroup.com> wrote:

Hi,

In the ACE WG a straw man proposal of a CBOR Web Token = (CWT) was defined in the draft "Authorization for the Internet of Things = using OAuth 2.0=E2=80=9D [1]. We just broke out the CBOR Web Token into = a separate draft and the new draft is submitted to the OAUTH WG. It can be found here: 

https://datatracker.ietf.org/doc/draft-wahlstroem-oauth-cbor-we= b-token/

Abstract: 
"CBOR Web Token (CWT) is a compact means of representing = claims to be transferred between two parties.  CWT is a profile of = the JSON Web Token (JWT) that is optimized for constrained devices. The = claims in a CWT are encoded in the Concise Binary Object Representation (CBOR) and CBOR Object Signing and Encryption = (COSE) is used for added application layer security protection.  A = claim is a piece of information asserted about a subject and is = represented as a name/value pair consisting of a claim name and a claim value."

/ Erik


[1] https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00<= /div>


_______________________________________________
COSE = mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

= --Apple-Mail=_C6D98A78-6AB4-405D-80A6-BB4D661F8B40-- From nobody Thu Nov 12 19:25: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 A0FB31B3F45 for ; Thu, 12 Nov 2015 19:19:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 jKfecQ6zWkkS for ; Thu, 12 Nov 2015 19:19:48 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22A051B3F46 for ; Thu, 12 Nov 2015 19:19:47 -0800 (PST) Received: by qkcl124 with SMTP id l124so36030225qkc.3 for ; Thu, 12 Nov 2015 19:19:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=OhV0MalIias2AhIT5ewNpHwULukXJA02/rJAmtrfKXY=; b=Ejo3ZFe3UZuRL13WEm1+NAtdeS5na43uIKZGA/4iZyBrdL4t5POuXT6Uk1PaZmDzzW 3t9ZxNuvs1ocFgiH2H5i7fnGxJfKgMVy7v+UECkI6C3TIxs3uTIjwaaYTA+mqaSYV+mr KPzNZJuB+c3ZkhA0Mz7EDmssHORbT8Wa4817pyDE8nfr3kVcKs2fgXHIB95HRY/vE4tJ K0d52PrOjNID4eOWmH6dsiS0+cvuSflri3q6PT9Ku45IBvWtAr+P8vbO2xzrVaP07moE R6mujkY8ikvER5wNGZ1yttlJJq/b3HUz6z76vNHqjo96ahoVAiNGTpYrmozn6Vlv8jkS Hc0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=OhV0MalIias2AhIT5ewNpHwULukXJA02/rJAmtrfKXY=; b=VBgYP5bxIm2YOwW68Gd/az1fYardE5vyGjRr0kQc8ElQr/5nun7tgyRvNiTYarOJKF k60QAREtGoQa9SWN+Bz0G+ll5triUtEDnU92Uf90vjyIsvsDontQbIQmYwETAlQ1POfn nGjQlGg/WW2TEZLFgtckQkyGgLz1tHTMRIuFZxfejRvyuz4QO5HzCKgaX+jdcE9oOn5C 6yRPRXfwy9dSeMHsJDFGcbzaDQkH4gBtiJEYuKKcm6aayU+CkD+sQjmdb3/GWK7+wriI ofLGlWZoUocXhulok7QOQuzLlvioDu/oiwQdNHZ7mbeVws5q//CCbttOn9/h9/M2EuUS dRSw== X-Gm-Message-State: ALoCoQkQi8pyybFoMa1rlmajA2cfPJDxB51nT/YwnN2/p51zU8ScYO0D3TG8QOvpiv131oDvTTws X-Received: by 10.55.55.82 with SMTP id e79mr18970471qka.59.1447384786307; Thu, 12 Nov 2015 19:19:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.29.68 with HTTP; Thu, 12 Nov 2015 19:19:26 -0800 (PST) In-Reply-To: <73929C18-A3E7-4ACA-A6DC-5A7AD7576C9B@nexusgroup.com> References: <53BB1987-979C-4945-9C7D-CDB6619AEFFC@nexusgroup.com> <5644EC40.4010002@tzi.org> <73929C18-A3E7-4ACA-A6DC-5A7AD7576C9B@nexusgroup.com> From: William Denniss Date: Thu, 12 Nov 2015 19:19:26 -0800 Message-ID: To: =?UTF-8?Q?Erik_Wahlstr=C3=B6m_neXus?= Content-Type: multipart/alternative; boundary=001a114900f40ad79205246388f8 Archived-At: X-Mailman-Approved-At: Thu, 12 Nov 2015 19:25:57 -0800 Cc: Mike Jones , "ace@ietf.org" , Carsten Bormann , Hannes Tschofenig , "" , "cose@ietf.org" Subject: Re: [Ace] [COSE] A draft on CBOR Web Tokens (CWT) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Nov 2015 03:19:50 -0000 --001a114900f40ad79205246388f8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Regarding the draft itself, a few comments: 1. Can we unify the claim registry with JWT? I'm worried about having the same claims defined twice in CWT and JWT with possibly conflicting meanings (and needless confusion even when they do match). Comparing https://tools.ietf.org/html/draft-wahlstroem-oauth-cbor-web-token-00#sectio= n-3.1.2 and https://tools.ietf.org/html/rfc7519#section-4.1.2 which are nearly identical, I just don't see the value in re-defining it. We may add new standard claims to JWT in the future (I proposed one in Yokohama on the id-event list ), it would be good if this didn't need a separate entry in CWT too, but could just apply directly (separately, I think you should consider this claim, as it helps prevent tokens from being re-used in the wrong context). 2. Is Section 4 "Summary of CBOR major types used by defined claims" normative ( https://tools.ietf.org/html/draft-wahlstroem-oauth-cbor-web-token-00#sectio= n-4)? What is the intention of this section? I feel like it could probably be fleshed out a bit. 3. Add a xref to draft COSE spec in section 6 Add xref to RFC7519 On Thu, Nov 12, 2015 at 12:01 PM, Erik Wahlstr=C3=B6m neXus < erik.wahlstrom@nexusgroup.com> wrote: > Hi Carsten, > > Thanks, and I agree. I=E2=80=99ve heard arguments for all three work grou= ps. > > Borrowed some of your words to define the content of the draft :) > It=E2=80=99s it essentially a JWT, phrased in and profiled for CBOR to ad= dress ACE > needs, where OAuth needs COSE functionality, for object security. > > I=E2=80=99m open for letting the AD=E2=80=99s move it around, but having = it right next to > JWT seems right to me. Also open for the ACE WG. Feel it has less place i= n > COSE for the same reasons JWT is not in the JOSE WG. > > / Erik > > > > On 12 Nov 2015, at 20:45, Carsten Bormann wrote: > > > > Hi Erik, > > > > having this draft is a good thing. > > > > One thing I'm still wondering is what WG is the best place to progress > > this. We probably don't need to spend too much time on this because, > > regardless of the WG chosen, the people in another WG can look at it. > > Still, getting this right might provide some efficiencies. > > > > What is the technical content of this draft? Is it a new token that > > OAuth needs specifically for the new COSE-based applications of OAuth? > > Is it a new token that is specifically there for addressing ACE needs? > > Or is it essentially the same substance as JWT, but phrased in and > > profiled for CBOR? > > > > Depending on the answer, CWT should be done in OAuth, ACE, or COSE. > > (I'd rather hear the answer from the authors than venture a guess > myself.) > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > > > > > Erik Wahlstr=C3=B6m neXus wrote: > >> Hi, > >> > >> In the ACE WG a straw man proposal of a CBOR Web Token (CWT) was defin= ed > >> in the draft "Authorization for the Internet of Things using OAuth 2.0= =E2=80=9D > >> [1]. We just broke out the CBOR Web Token into a separate draft and th= e > >> new draft is submitted to the OAUTH WG. It can be found here: > >> > >> https://datatracker.ietf.org/doc/draft-wahlstroem-oauth-cbor-web-token= / > >> > >> Abstract: > >> "CBOR Web Token (CWT) is a compact means of representing claims to be > >> transferred between two parties. CWT is a profile of the JSON Web Tok= en > >> (JWT) that is optimized for constrained devices. The claims in a CWT a= re > >> encoded in the Concise Binary Object Representation (CBOR) and CBOR > >> Object Signing and Encryption (COSE) is used for added application lay= er > >> security protection. A claim is a piece of information asserted about= a > >> subject and is represented as a name/value pair consisting of a claim > >> name and a claim value." > >> > >> / Erik > >> > >> > >> [1] https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00 > >> > >> > >> _______________________________________________ > >> COSE mailing list > >> COSE@ietf.org > >> https://www.ietf.org/mailman/listinfo/cose > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > --001a114900f40ad79205246388f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Regarding the draft itself, a few comments:
=

1.=C2=A0
Can we unify the claim registry with= JWT? I'm worried about having the same claims defined twice in CWT and= JWT with possibly conflicting meanings (and needless confusion even when t= hey do match).=C2=A0

Comparing=C2=A0https://tools.ietf.org/html/draft-wahlstroem-oauth-cbor-web-token= -00#section-3.1.2 and=C2=A0https://tools.ietf.org/html/rfc7519#section-4.1.2 whi= ch are nearly identical, I just don't see the value in re-defining it.<= /div>

We may add new standard claims to JWT in the futur= e (I=C2=A0proposed o= ne=C2=A0in Yokohama on the=C2=A0id-event list), it would be good if this didn't= need a separate entry in CWT too, but could just apply directly (separatel= y, I think you should consider this claim, as it helps prevent tokens from = being re-used in the wrong context).

2.
= Is Section 4 "Summary of CBOR major types used by defined claims"= normative (https://tools.ietf.org/html/draft-wahlstroem-oa= uth-cbor-web-token-00#section-4)? What is the intention of this section= ? I feel like it could probably be fleshed out a bit.

<= div>3.=C2=A0
Add a xref to draft COSE spec in=C2=A0
On Thu, Nov 12, 2015 at 12:01 PM, E= rik Wahlstr=C3=B6m neXus <erik.wahlstrom@nexusgroup.com>= ; wrote:
Hi Carsten,

Thanks, and I agree. I=E2=80=99ve heard arguments for all three work groups= .

Borrowed some of your words to define the content of the draft :)
It=E2=80=99s it essentially a JWT, phrased in and profiled for CBOR to addr= ess ACE needs, where OAuth needs COSE functionality, for object security.
I=E2=80=99m open for letting the AD=E2=80=99s move it around, but having it= right next to JWT seems right to me. Also open for the ACE WG. Feel it has= less place in COSE for the same reasons JWT is not in the JOSE WG.

/ Erik


> On 12 Nov 2015, at 20:45, Carsten Bormann <cabo@tzi.org> wrote:
>
> Hi Erik,
>
> having this draft is a good thing.
>
> One thing I'm still wondering is what WG is the best place to prog= ress
> this.=C2=A0 We probably don't need to spend too much time on this = because,
> regardless of the WG chosen, the people in another WG can look at it.<= br> > Still, getting this right might provide some efficiencies.
>
> What is the technical content of this draft?=C2=A0 Is it a new token t= hat
> OAuth needs specifically for the new COSE-based applications of OAuth?=
> Is it a new token that is specifically there for addressing ACE needs?=
> Or is it essentially the same substance as JWT, but phrased in and
> profiled for CBOR?
>
> Depending on the answer, CWT should be done in OAuth, ACE, or COSE. > (I'd rather hear the answer from the authors than venture a guess = myself.)
>
> Gr=C3=BC=C3=9Fe, Carsten
>
>
>
> Erik Wahlstr=C3=B6m neXus wrote:
>> Hi,
>>
>> In the ACE WG a straw man proposal of a CBOR Web Token (CWT) was d= efined
>> in the draft "Authorization for the Internet of Things using = OAuth 2.0=E2=80=9D
>> [1]. We just broke out the CBOR Web Token into a separate draft an= d the
>> new draft is submitted to the OAUTH WG. It can be found here:
>>
>> https://datatracker.= ietf.org/doc/draft-wahlstroem-oauth-cbor-web-token/
>>
>> Abstract:
>> "CBOR Web Token (CWT) is a compact means of representing clai= ms to be
>> transferred between two parties.=C2=A0 CWT is a profile of the JSO= N Web Token
>> (JWT) that is optimized for constrained devices. The claims in a C= WT are
>> encoded in the Concise Binary Object Representation (CBOR) and CBO= R
>> Object Signing and Encryption (COSE) is used for added application= layer
>> security protection.=C2=A0 A claim is a piece of information asser= ted about a
>> subject and is represented as a name/value pair consisting of a cl= aim
>> name and a claim value."
>>
>> / Erik
>>
>>
>> [1] https://tools.ietf.org/html/d= raft-seitz-ace-oauth-authz-00
>>
>>
>> _______________________________________________
>> COSE mailing list
>> COSE@ietf.org
>> https://www.ietf.org/mailman/listinfo/cose
_______________________________________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

--001a114900f40ad79205246388f8-- From nobody Fri Nov 13 08:31: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 113031ADBFB for ; Fri, 13 Nov 2015 08:31:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhwQz_jQZ-OK for ; Fri, 13 Nov 2015 08:31:19 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 161511B2850 for ; Fri, 13 Nov 2015 08:31:11 -0800 (PST) Received: by qkao63 with SMTP id o63so52164623qka.2 for ; Fri, 13 Nov 2015 08:31:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=G6F1UtRcow7OHQeV3nMBLQaExEx3gXinVCeP3VPTWQQ=; b=RzMOzJsspzAVNfdkwqx02xiP3hh1JoSBxKiV9zOR0CVVOF9em517OpCR+G17hShxs2 XQFbkfYZHJn9GulGBAItGt7x7xhx4l4HLVogLi9CWCjjTEA3G0qtVwasfvwCFkhOv5q8 eagYd9ZjgHof1m3YonlBYhqZkmtmA+y8kyLnn3aGplSMwiVUDEvyTJ4xAQ+xVa/BGIZs CNthwvTQibUrysfOZ+2lWu3KupOQgiHkFH3xe/baGI/fSE2Z7gXk517FJ0qNoG3EDWLa Lpe9hvFy5f8+zyJCCU6/37v5iLoo2rCIr5yav5yjrIUoNHhkBFIFCpBYkFtKF8dVnP3b a/+g== X-Received: by 10.140.252.130 with SMTP id x124mr23440944qhc.48.1447432270213; Fri, 13 Nov 2015 08:31:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.148.198 with HTTP; Fri, 13 Nov 2015 08:30:50 -0800 (PST) From: Renzo Navas Date: Fri, 13 Nov 2015 17:30:50 +0100 Message-ID: To: ace Content-Type: multipart/mixed; boundary=001a1139bb704df92305246e96f1 Archived-At: Subject: [Ace] Authenticated Key Establishment, OAut PoP Token and Time Requirements for Constrained Devices X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Nov 2015 16:31:21 -0000 --001a1139bb704df92305246e96f1 Content-Type: text/plain; charset=UTF-8 Good Evening ACE ML, Reading draft-seitz-ace-oauth-authz-00 (thanks to the authors for easy to read doc) I was very interested by the PoP token that offers an authenticated fresh key to be used for further secure the comm., but I saw a very strong requirement for the RS to have a Time Sync. mechanism. I preview the objective of my mail, is to raise the question: * Do we want to have a strong requirement for the constrained device (RS) on an AA Architecture to have a Time Synchronization mechanism? * Are we interested on offering non-time -nonce- based solution for an OAuth PoP Token approach (for example when the token does not expire)? (those interested on those concerns can read the rest of the mail, that is rather long) Regards ------------------------------------------------------- (Long version) I've been working lately on the Authenticated Key Establishment problem (The are two very good reference books [1][2]), focusing on solutions with a Trusted Third Party, Symmetric Crypto, and not using Time-stamps but Nonces (To avoid having to deal with time synchronization).I have no strong Crypto background. First I want to thank the authors of draft-seitz-ace-oauth-authz-00 , very enlightening for the oauth neophytes. I'm mostly interested on the authentication problem (auth. key establishment), so the Proof-of-Possesion Token is a great tool/concept, I took the time to read draft-ietf-oauth-pop-architecture-05 and draft-ietf-oauth-pop-key-distribution-02 to try to have all the background possible. So from the Authenticated key establishment mechanism point of view a new fresh key between C and RS obtained by means of a PoP Token mechanism -I think- will be similar to a Denning-Sacco shared key protocol ( http://www.lsv.ens-cachan.fr/Software/spore/denningSacco.html . Client is A, AS is S, and RS is B), with the difference that the PoP Token Timestamp have a start and end value that will make the "mutiplicity attack" of Denning-Sacco limited on time. My concern is that we will always need Time sync on the RS, that some (most) times will be the constrained node (I think that the Client does not need to be Time-aware), is that a MUST requirement? So no-time aware devices will not be able to use OAuth PoP Token (or will have to use token introspection, a good fallback solution btw) Will be of interest offering a PoP Token generation and transport mechanisms that offers an authenticated fresh key without the need of Time-awarenness at the RS? Time awareness at the RS offers great advantages, and maybe also Time is always needed in all authorization solutions (to make easy token expiration and freshness claims). But I'm thinking about nonce-based authenticated key establishment. Of course without time information embedded on the token, token expiration will be more difficult: * we will need token introspection, or * the AS will contact the RS to revoke tokens, or * we will need on a non-time based solution for revocation that does not involve the AS, for example: a pop token/key is valid for use only for one (or N) Resource Requests (of course if the response message get lost we are screwed...) So maybe we cannot avoid to have Time-awareness at the RS, for Authorization purposes.. But for Authentication certainly we can avoid Time, the three most recommended by [2] nonce-based protocols are: * Bellare-Rogaway (3PKD) [a Choo modified version It has been proven provably secure on the strongest model to test auth. key establishment protocols ] [3] * Yahalom [a modified version has been proven secure on a weaker model -bellare rogway- than 3PKD] [4] * Boyd [Key Agreement: RS, C and AS contribute inputs to generate the key] [proof idem yahalom ][5] The message flows on that three of protocols do not respect OAuth flows (I attach an image with the high level message flows, A is the initiator always), so that take us apart a bit from OAuth... This mail is starting to get long so I will try to conclude it, but hopefully raise the question: ** Are we interested on offering non-time -nonce- based solution for an OAuth PoP Token approach (for example when the token does not expire)**? If NO, I guess that will need token introspection for RS that cannot support time (That mechanism will map to other authenticated key establishment protocol and not Denning-Sacco-based ) if YES, are we interested in adapting a nonce-based auth. key establishment protocol to OAuth PoP Token? I hope this questions are useful, Best regards Renzo [1] Colin A. Boyd and Anish Mathuria. 2003. Protocols for Key Establishment and Authentication. Springer-Verlag New York, Inc., Secaucus, NJ, USA. [2] Kim-Kwang Raymond Choo. 2008. Secure Key Establishment (1ed.). Springer Publishing Company, Incorporated. [3] 3PKD - http://eprints.qut.edu.au/1230/1/ACISP_Full_Version_-_03_May_2005.pdf [4] Yahalom - https://eprint.iacr.org/2007/188.pdf [5] Boyd - http://eprints.qut.edu.au/4421/1/4421_1.pdf --001a1139bb704df92305246e96f1 Content-Type: image/png; name="Auth-Key-Establishmen-MsgFlows.png" Content-Disposition: attachment; filename="Auth-Key-Establishmen-MsgFlows.png" Content-Transfer-Encoding: base64 X-Attachment-Id: f_igxuisjp0 iVBORw0KGgoAAAANSUhEUgAABIEAAAKQCAIAAACHDv2SAAAAA3NCSVQICAjb4U/gAAAAEHRFWHRT b2Z0d2FyZQBTaHV0dGVyY4LQCQAAIABJREFUeNrsnWdAE1kXhieQ0JHepEsHRZAiVRQ7IoqIsmIv 2Mu667p+q2vbteHaK/aGgiJYKaKCKEWKKFKkCNIE6S0QUub7gSQTCBAggQDn+UWGyc3Muffcc99b cSiKIgAAAAAAAAAAAECfwAcmAAAAAAAAAAAAAA0GAAAAAAAAAAAAGgwAAAAAAAAAAAAADQYAAAAA AAAAAAAaDAAAAAAAAAAAAAANBgAAAAAAAAAAABoMAAAAAAAAAAAANBgAAAAAAAAAAAAAGgwAAAAA AAAAAAA0GAAAAAAAAAAAAND/Goz0ebcOjgnN7R+aeNQmKKmukcr6X3Xhc8UY7yCzNKphiJefTmxV //oXCYatJD0j6gf3+/IOtaGzhBmWV9mS0NjztBreLpfFuK3wrNDa7ibRnO+3WA3XBrVFd/OaB61b 1L2cJ47jIPyTntQM8nJe+9xJgPHCSuvjiL1Okvb92liMEfX/zWju92oKIgjU5z2hMXGrKouKQWTm owq0F82yv7XbJQllEgs564gRp2pxW98ytPsVFAAajAMQP1y4lM18Ke/y8bc1KK+ZA23IuP+Ho6Fr YAUKZQNsBWWj970vubeXWHncKmC6qLv2Uey1XzQEwDxQzgEAynmPpVm4T2SPn78p486tHCgIADDY NRha8+70ne9tr1b6H3leSuOhKrk+w3+bo4bBPO+Ir0RofYCtoGz0mqbsa55Wi+4x+T6/yR/h7067 DMeDeaCcAwCU815VsS8vRZT37BWaUm/eyYPCAAD9Sh+0hGhlYccfVre/TnrhfTd37q9aBB4wA7Xk 4aIxbne/Q4EAW0HZ4AyNGT4edqsfV2CvCdvuf/X0f1aSsAwVyjkAQDnvNaRXl16XzZkn3+0qlfjx +r0CKA4AMNg1GLXo8YlQ+tKvkStn/bj86EfLhw8nL6asPTJGqP/NQKvL/giND7AVvC9nQImp5+ba bQhm6nqRmHI8MmDzaDHc0Ktlx+6++aeJcM8TIChZikI5BwAo521pfn3pVdlcD4VuirCG5Gv3i6E0 dBe1lRePzZDn71EUkLeUwIEFgb7WYOScuyej6VMOR7gs31T+5JFPacvHb5ePRf11azKUzMGIqNWJ D5l7KS3zJHAECRVRsMnQEGANH0/Otv81vA57UX7OpTe3V+oJD0mLCKnZO8+eKA5FA6opAOAEgghC am1iRV56+WPeAsVuibD6hMsBpWDGbiMzZtrs2Wr8YAiAU3B7UlBT6tXzn+mf5BydjK2WuirSL1Td P/KshAbZMBjBCSuM0NH9iY6mgjAo7aEgwOqSjjrbtBFgaovvvr87VAUYANUUAHAUZWdPHfoH8ptL 4d1cWl8bdymovLUNOMJcFiwKAINSg9XHn7uWR/80bIL7SFERk2XzlOmXmsO9734lQz4AwCAQYLXv D0y3/SOCaVtxvfVPYq94qMMmiAAAAJyAoDFnhQn9EyXqUli3urJrYi49qfr5t8jkNY5yYFEAGIQa DK2KPHXvB/2jqONii2EIImy8fJEG46bkkxc+NUJGAMDAhlYdvXeK/c532GP/8KbbX7496awEmyAC AABwTISpzVppRv9EfXsp9Dvb55yhVW99nrUe8yg+fe04aRj7BYB+gpuNI1pp8PHHjDlJ4tNW2Uji EAQRMliyyuDQX+k/r+dfPRa18/YUyYFeD6CkH2kx7+JTsgrK6yj8IsPkVHVHmluP1ZcV6HGCZV8S 4pLSsgtKquqbEQExaSV1nZHmVmba0r3cSxJt+p4SHZ2YmlNUXkfCCUkqqOkYj7W10JXhgcEKWmNJ RmJC0ufs4vLqOhIiJCGnrKk/2sLSWE2cvweJlWYmf/iclVfwvby2oYmMEIRExKUVlNV1Rpqa6g8X 5e+DUsGFTCRX5XyIjUvKyC+rJtIEJZW0RlmOsx+tJNR/LkSrfLNr8sQDSRTMNWG7f14/3TFWgo/H rDdIoTYUpyfEJabl/6isqiXhBEUl5IaraxuZmhtrSOC577VcdDRqXV5CZFRi+rfSelRcXllZRXOU ta2RvABukNmZ4xEEQRBy5ZfYqNjkLwUV9WR+UWmlEYZmNnYmyh3NuKQRCz9ERSWk5n6vakSEJBXU 9Uys7Sy0JPG85ry8HML6RoSpzlxluSHx/c98i74U8n3xChV2/AytfHMxpPUkcknn1bZSH/rdBcjV uZ/ev0/KyP9RWdfMLyqrqjvaapy1vgzU8qyg1H5LeZ/w8UtucXltI4VPaJjscHWdkeZjTUZI8r7B +jVO8aZy4Brk3DMWmB+S8gyvwfzLHPMvgYm3iqlspEgtvmqJ+ZreP+mkLr9TE+KC2XdRbtW7BswT fj1h3LWFJBdG1LV+o/aFG2bJtvSSN/UoitIa818cW2E3nGVYwynZLvcOyWukdcNypOJ3l3+fbSLT wQPhlKwW7PH7WEXpNBGmRzU49KUZRVGURsx5emChBevp3/yq9iv+C+3gUbtvq7pXHsMY/5FY8Lqu 0+elEXPDz2x0MpLsIGkhrUlrT73Mb2LHkNT67LBzW90sVTqtkYQ1HZYdDEyrpXLmfbmRie0TfXN2 /WRtljuJKo9f7xNXTmlX5pU3xxN77sX1UcuwryDkElLT7h5KWfg24zbRX2LqyY/1tB7/bK+sRysL nCmCuXv4htgGdn83da8uxiPsrhRQevL4teHuYpgHEHMPr+VaPUupSLq729NGtcOyjlMY4/rbxYh8 lo7du3LOAUejV9TPpmMSUVwX24CiaFN+2BFPMykWafINt5y7/Vrsj+bexgu2q6ne2ZmbEYQpzdGn cskoiqLUmo+3/5ihw7KqULRfdym+ktrG416fWG7NclKaqOGcvU9y2Q9hnKr6OBnCel2f9zPEhF9V MA+q8WdyI6Xgsg2mxFhdzGerrqL+uD9NsPVLMkte15IyDxsi7cok91yAuax8f3N2/RQdEVapCYyY uuVqQgUFRVHajzs2jH/o7E0l9ZHdm5mNg5ie+0bhWOLdbdBSqj75719sp9ZRPwOf0liPv30Ty8kd /Nz3O+MxKkd0zvOqTn+u4Z2XPNa5HO6UdFqFNyb9oY6twmMauFx4Bgfc02CktP36GAMrrcfmCLX4 1gRsXhh7ZzYPSA1WW59yaaFO1x2ymp5X0xvYKFuUinf/uWmypZ5Fxqy5k9Fxmu0CGK3243l3ta7T 1VxwJa19stzUYLT69Dsbxg5j663V555OqO6kJqDVp95YY9GdLeiG2f0vtITMyZjNuUzEFv6aD+c9 RnT5Mg57Isor+1KDUX6EbDZs4wDyblcyG3uuKXpvvZrwRdKY+2SXRbCngRoTf8d4iND0+z+oPXqH vtJgpG+Bm83Y3epEecbBN+UUTpVzTjlaRxospjr/4fpRXXWM4g2WXEmpo3Fbg/XeztyMIO00GKX8 zT+TZLp6zPk3cn7ag1QQtNGkiwEkvOkfL8uofRe/OBzCBqEGQylF1+0xXV+W59mRB9QS34l0R5P3 elvfVmZ0oME45wL0GqT2o4+ndpclf9i4XeGlzaVDXINRqxMvLh0pyJb1BQwXnU9k1UiiFF6zxWHD YodqG0VRtDH5Tw3mvpg5wdWdBaPPe3QwbQCvd/VcLDygwdioM+KZ6gytnZ+amPyv/NFs7CbAqr+y 0VDkNQ0mOevgbxZsz32QmnM7n9y5zTIuz1Xq1igm3mTbix8UNgLYgYSYAzaC7CYr436viNxHGoxS GvyrcbemKvEZ//G6gmVrgFoe/vuonkx9M9geU8uhmM3RTGQIndDNBuymZ+i1w16gbzQY5fvTdbpt VfISv289jpCcsl5D3CZlbByfF1zFhtCtf+ulgCmy80Oqetgl1ycajFzo94tiNwu6zqbwcmrvyzkH HY21BpNx+dWV3XJAMN/1rorKPQ3GETtzM4Iwa7Dj759t0mMvQe1tsXW05rzb8xTYul14kk8uua/i F4dD2GDUYCj1++0JmF4K87O55C7bUEU3xtGj7fCNcQ0oOxqMoy7wswZ5+ftIticTayzzOWo5dDVY U/bNBWrdNL/6ojtfm9q1I/IvYn9Q5deExk7e/IhRmzTlV0d3PKGk+QvWUrLL39RxrfAMLrg1AbM2 9vTNQsw419ol+kzVJ05mwiZ3maDrFT8/F1w79ubvO1P7dlEYn7Td5n/3FJARhFr+5tSZVzWt/1CY /fsak59nyfJJmGl2UPNXP9rxH6adZzjFdZqdsZa8CLWuNCfp9aP7kXnY5TFVD9duDJr0cG4HhymS 828vtFn5sJLpoorDIs9Zk6wM1eTFcXU/CjPfhwXeu/s6l76RJCXZe+pkoeg3e8cO69RyP56td3oX R6I/qv4Ep0nWRmpy4nz1xRnvwwKfJFdgb6+4v2br4km+zjJ8HLNVBzNh6+P3TXE6/gllmlCiMX6B h+uUsXqq8sNw9cUZsSF3fS5HFNH/T/t0ZOYig9RHS9WYSy8594rHzKMp2P2hCJqOC+ZNtzPVU1eU FhNASHXlhVmfYsMD7wZ9YDJ0+uFVZ5Yk7jAQ6OX7cicTm1L/c3Y6mc7cWjCds8zTxc5ITZZALM39 +Drw9o3n6S37Eab5HOwT96EUB62zd730lamNveHpq+MzFHu4KIBz1hMZ7bVS59TerNbq6MnZ1xVT XWU7r15q3p31Z5yZo+Cx0Y6HF6lSvt1YsuRuCbbxZDZ38dzJVqO0lWXFBWhNtT9yU2LD7l+9E8PY FgnJOrXgj5lfLk+iv1hPyjlHHY01FY+PBzKEkYnr8kWu40ZpyAs0fM9ODPO/di0sh7GZLjlh/zTP EZ/b1Qc8Zec+iCA/I+ntJXMSv9DjrLKtm5OlgZaaDF91bvKrh/eiCjDZlu297oSJo+9CeqkX1hrn Mt1ulLq8KK3ya2LYff9Y7Is3hm//66X7bdZRmqvxq/chjDvxq5/hk5+0erzA6/Dmlo8JV54UeG3U 7MwLqMXBF6NaN+9QW7DUWARByH3vAk3pJ1ymHf3MFPZFjZyXLpw93lhTXphU9i317ZO7Nx8m/SxO ede8fkeGKJTCe4utF/uXMQ91aU34Zf5sxzHaKnLCzRVFOR9eP/LzfZGJ2Q/r2y1PGyoh4Ya7MqY8 8CtNXmSKvG9d/1f47HnuITPWlTG1NDIgta0Phgd/JVmzHo2jFIXdS2MUEKdFJmLcrz8HB1xRdrSy QBfMDF8+28ssllUQ32/B9uwQHG8WUfp2HKzD3g7r26VszPpgvJ/ewlNvikntR4/Pug1nvtP8TAc9 VY2fD5kxR1ZNj7NxrCb2Usrjzi/UYrp1uNeLSip7j4o3XHru7fe2j0oqCt8/sc1CLMvzeWS0N7bq uoOZVvtus0abDq9fzsaUtf/dprygLcyDZeKuAaVM70wtDZjNNDNKcurRuKoO+lJIhaF/j2M2T4d9 Quy+LzcyEUVRtCllP3MPLs7A61Zqu/lXlMqECwtYzQLizjhYc77/0rZdc8Nm3y/peecVh61Hzjkx hql6uf2982ejlTOtIlP/40OPp1P2wTgYMW4jtm6RdjnHekoejZh9bwWTrXBWrD2b3XLOJUdjHgej P6z+iuuf2i0kay6JODSNea6d0ORr7caIODEOxmk7cyOCsE5TeuLOwPQaZtM1Fz5ep8O6ISBuvyMo s80KTlLBs99MmZr0Qk6B5bS+qvq4E8LYr895fhwMRWk/HkzDtG9MTuR0OhJGzjvPWKM/4n8fm1gY pN04GMermsaUf0Yz55TusivJ7SbP0RoyA36zZLWgcQiNg5EyT1gzi2o+wxWXEyspLGYrJl9fY8x8 L8HmeAbzYFhz1n+jsK9zuoMGKe2H/2QW9XGH91MKLlthQsKC1s0fOB+nYC4iO1AKr43DNJiFpt8v ZVXFklL3Ms2ZGHXkS/PA02DCDkc/dLQgAW3KODYWKx34HO6ySpmce94W6zx4893RnS16opa/+oNp IF/rzyRi148q4eyT0WFznJi8j6mpj7O7ybrRyjEN1px1zIzp+Yx+Dy+jdPzOwSuY2iMjD2U0MzW5 TZmq6W0dTXpqdfqql15MI+SjjmWTe/O+3MhEFKWW+Dsz5aPh768qOkqVUvp8g04faDBSrq+nMovY KGB7PL2phxPrOG49StF1B0yKOGufTtesU4tvY5eoGhxI70WYb6PBeoWIa1h7Ace8/Fli3tOKTgo7 KfOEFbYWsrjAqh3BZjnnlqOx0GB8o/+M6LCsN2Vfc8Wu+UMUVkXWclyDcdzO3IggLNKUcr2Zy7r8 NsRv02g/y9H1xldSB22r65OxzWCZZVH1fVT1cSmEDSoNhtLKA50xC22M/8vqpA1F/nqS4bu6+34K mS40GKddgFJ8Zxp2aRBu5LZXHc47o9WnnJoizkMarCeMe1DZwwYtpfDWVKZlVMLjDr2v6dizaLVJ /01kijyCjleY+6aaMw5gVjXw2d1gvR1edehcVmt98RNYNmBR6vfbDox8HzYvtJprcQo0GDvFNvuY Cbba9OhoWQX56ymmRrjKlvcNA0yDic28V9xpOal5uRjbUlBaH9s+hNRHr8NOoxedfqOgyw4A0pf/ sLYTnRXUpn+y3aNKzA3qdIcBWuXTOVj3VVgT0ytbdaXBiO83Y9vx/FYnMjvPTmpZ0BxsvaC7P43E aBkex3atSbg/Ke8ysjZ92onteFFcF0vsxftyJRNRcs4JrC8hJgfTOhc5TakHTbiqwYJ/5NyY1/H0 boMdsbU9aNNww3q08iAXrAuYHM8md9JDfGEstvpnY2lFf2qwmqdTsQtBLhVSOpdBzzERVUB7DYt2 NJvlnGuO1k6DCU7wye20T45WGbYMu2+X4JR7zMOwHNBgHLczNyJIuzTFZz8o7bCqb844oM9cwsRc Ohu/rnqKndOCWF5t12jjTtXHrRA2uDQYSqt4jF1ZP7KT3c2as44yxkCMDrf2eHehwTjsAk2f92BX EONtTmd10fNeHrxUfmhqsKZPu7SxCckufNLlJlHUitCVTOFZdStz/GfeOkNwOsuB7YZ3q+g2FzS0 YdhfbG5oDYtcL3swlTFDUYyx4SIX4tSggwtnNJMyrp9NxtSDHhs6WlaBV3PbjN0ss/Daf2+q0IE0 k1N11W4XpU43lBg2xt0aIwLLsn6Q2t5SG3P6zneMtNjmPV+ly5UNAjpL985lNB4anp95Wd6p6VSX /zlFrrPsxkmaz8E236sLqyhcNB3x4zU/xhovRH754eU6na8S4ZOd/JsnffW4kLxQfmFD6ytTycMm LJg5wcJAVUoAQWTnbBgv0+VMYkE1K13MLzZWN1J7/jrcyURybsBljC8Nc/93tX7nCxYEDdYeXSzD tVxrzrm2wGqJf0mHN6QfnPNrSDmNF6yHk5mw2Q3TfE2+eC+ruYO0yLn+Z+MwExc3uarx9lklfARM tZMdnlzTmfPjJOz2+Qc8i0zIKKwi0UhZ5+1Ee/q7feZoI347tkij0y3vcVITdu7EnHFCennuRSlt gNmZIxGkDUqLtk+X77CqJ6jYWDDt9i/nsW16J0vMRHVs1LGu+r2G0h/xiwdDGE+Ak7L3ms5ouH6+ /jC3gwVezV8fXE2hd0itdBtB6AcXaEq7cS0TMw11zX/LtDt/Dj6ZyfsO2A/Fk6Oa0m7eyMY0l+0P /jtNrqsWO5/0xH3HpmIqjIKb5xMasJ6nPXsuY80CKdrvQ137X858/KJ1dRZh3LZfp9ArjPq3QWnE trej1XG3oui1ksjEpVYS/R2nBhCc12ANSReu5GA6bJatNe/QkPxKTlucMP+teXj4yXfqwLGezKQ5 +l3tuCmsNhrTSUiprSa1aSYQU+69qGF8NFzxiy4764JxUtYL7RiuRo7xS6rr7FEnunb1qDgxdR1M 651U18jFrCDlPAvDtOSV5q4w73qfaxHzv/yfhEZ/zq8i0RpLP/pMlmpt/wnqLT9+5/Gr92n5lSQa ucjHnp1hCH5RKYxJKCRyz/U/dzKRVvYu8DOmNTZtpa1UVy1enIT16rkK3Mo2Wqp/OHZ1sM6aoC/v djD1qxdf8Vhxp4DS/9ZDkGHWGxZheo8zrtxKJ3XQb3TrYgqj1em0eboiH0/XPEIaYzEN42o/z/mH Iks7XlyPEzeYNsdpnJmesmQvTzbuK0cbuXapkVBXN+HVXVdjRi+p7+8l1AwsO3MkgrRB3N7VSKQz q8loYAfWhKxcR3XW1MFLqmDXWZGbKGg/xC8eDGG8IsIkbVbNoLd5kdQbATkse5qas/2u0TdNMF81 Wx3fDy7QnPvs0TfGR/WFK0y6bmbzq7hsmiiIDDWa84Kf5mOqgam/uqqyk2f8Sk5bZzEKBFIe9jC9 kakKnztHldHmfh2Q2lZUkQtePMmjq3W3CbbOJnQlVRIemtu2fNUl3o6gpyE8YakNfdCl3+LUAILT 3Qto9btTvt+xoXSZYSfe09JV/fhm625K5AjvW9m/bNcbIMejj7Ab0eWhB3wiUtiA2ExsZg5h5MK3 MeWYQDPWRpm9t8eJG4zTRJ63bpfXkPz2G2nqKMFePCq/mJwYgtC3l6KSqSiCcMcV0JqUCIxSF7F0 1hdh42sCKuOcVbo0DF6g62JNIxYlh4Wm1WKuUHsuwbiUicSMkM/YdqmzMTvnMYkYzbISufiIyPX+ G+PfQsIPT5bjn3L/YNjoHYn0lmHt4xXzT5m/2mog1K/WQxBEePSqlbon97R2vObeuPJx1ynLdo7Q +OnKNUZplHbbxMbgTrdqWet9vv8zFe7Rd3GCKmPau4aA1pxFBrt20ffKrAn/33jFY2Nme8ydPdN5 msNIBcE+CGFcdDSNGZNU2SgD/PLW07SRuNbO4qaPr782zjQT5twrctvOnIggbdG07jxNPkExbJRQ MVXr1E9xBBGBfnFeHg9hvIOE1UpnqXt3qlo+pd94kPPbznab3ZG++N5orQdxNmtcVPH94AJodXJY FuOjpN10bXZiBE7aym0UEprAA7ZWXX7Wu+vBKCYISjY9mZiO1qW+woyCIabzrKTYtPQws/lWAn6h rVKpMCqxnGquSpdRQgbzZin9d+ZnM7005HFWk/VoTD5QSyMD6Gpdb5aDkiz/ND3k9c9LWU/elOw0 UsMMb9Un32H0wgg6LLOTxvFUnBpaGoxW9uJ4UDXDd6w3emh1XiMPs96wSOXmSfo+9p9Pn/uw8aSl yEAwnpCSsnjX3ojjwxYzlNYmgDZ9e4/pGEIqX22f4yTB1nlZKKkwD/Ox+GMRCekohgkpqXT9qDi8 ILY80GjcmxdKKvqA6eJB1Cw1hbmZU2hzbWn+1+ysL+lpqZ8/JSfFx8Wm/+DgNBXuZCK18ksmpm9Y cbTOMLYqfxFtGw3kURpXy77g2L9fBu+2leJDEER45NZ7p0JGboikDzKRY36bs8fm/UErcVy/Wa8l Bugt2jBmz6ak1hvuXow/YDmuTUisj79wh3GQhrLneqthHK4oVGymOU8U52SSAvprjy07M/1aKeZa eVLQmaSgM/9DEHFtu6nTpk6bNn3qeFMV0T4c0uOQo+F1rNXZEvACymbaAkh2M70AfGtEOKnBuGxn jkSQdrpUU7o7YV1MXrzz2/n4cP3jvLwdwlrfov7jFe+72SQ2CrXipA0bJilyYVbdsLGrZsncaT3o 58ut+9l//G3ILMKa0m7fbj1FhH/c6unD+fvDBUgF8bmYHFG3ZM/LEX5pQxM5JKGs/9t8subOc93V +Pvgl8gln/MxNafKWCMpdisYnLierQYSSp/zWfSpmISoMtrUwkYezvJnLv2cbZj3OCR/32hdejsd rYzxS6JHw2lT1QUIqMN4RSTt57ylTw/jKteoydErhcZUvxB6rwfBfqm9NI7n49Tg1WDUwqDjoZgz CtCY1er41d1Lo+j60Yg9fk5SA0AfC4n3XsXT6osKsbN10W/RYd96pgNKv9fTkA5a6ULDhLpfwrkY v8gVediTZKQ1ZTg69Emp+vI2JPR1TEJySlpGZvbX4hqurgvgUiaSy3PKsUbSYNNIBFkdBT4kjca1 9xUdfyTy8e9mDIEloL36lk+w0ZJnDMmYcXjOJvuPV2Z03WfIVRfAq7ttGb91ccTP/C8POPfuP3um E47QqqgzDxh21lq2avRA6AHik5l6Kvho/vjfX9a2/2dd9tsHZ94+OLMLQUS17GfOnjN3nruThbIw xytVLjmatKY8m3OPBOQ0pBCkNcLTKgprKIg0fqDYmRMRpF0PjLRYt96fn8DPe1XfAAhhrb/Q8OnK vsOx7NyqgXNfwxUNhoiZr3CVu375p0bJvOWXuX0v0zFOjZ9v+rZmi8CENVO7NdWacy5ArsjFnOKG k1aVZNMaeBlNGQThAQ3Wd5Ar87An3snryrHfRCLI6cghCF2DVeW3WRcpOtpzusylGz/TTwt4/f13 XbqwrE3yj22dLig5fpaeMIIgBrPHiZ/zb4nu5PcByXXuk1v7KZvSHzylryrB2y1zkOXjvTjF05Gc o6Um++6pmF7XerWBRx4VD4hp3Hx4/t5rMGJVI4ceh1TX8UIBPn4+nirXtMZqzGvzi4pxaPov2vAl cK+7sYy0/oQFm/edvvU4IjGTywKMe5lIa6zBdGggwhLsNkLw4jLckxFSTmfinmEFWMtPqnpeueHB tBnI9+u/LLuVT+lnF+BXctoyg7HmoObJ2chKbB1FK395+gkjPBivW6I/QJYe4MRMfwvOCD/kbtDZ AzfkRN3779e5Y1XE1MavORNR3IwMAEcTYruo8wlJYIe9SA3NtAFkZ05EkHbOL0Tow6q+j+IXD4Yw nkJ0zPK5jN3wsm/f+8I0MEf8eM2vdaRfaNLaSfJ8/eMCVGI1JqIRhAXZlf98QuJDbUEYrakWm4ci UiLsZxpOQEwUo27bT18WM104hbFk7INfdAXd9YifAyLrf/4taOVmLIYgCCJu6m5Fl4C1bx5n0J2e lP0oiD6lic9m6YR2Zatf49QQ02BNn6+eT+VAOpTIo7eyhkoWoDQKlWNJochQhlaTcHyWtv6cPQ9S ajtXEdrWs9fsvRQU8NPKAAAgAElEQVQSe89FlJczEaWRmZJluwmC4xfg1mwJU+93AeuNRFg8Cr/C rLN3vZiODat7tnLe8dSm/nUBnIzj5rkMcUgMOR2G2T2P+v3Z6bAmRgzZ6K5JGEBlnqA0cbt/atW3 qFv7V00b1el+mLTCyIsbJ2hYbHpcROZ1R6M2s784E8XeiRfgxw0aO/dQMuL6UqpA/OINREyWujOO z/zqey8D04BvSLr6oHWRvui0NT1b7coJF8Dx43E983IalTb0MhXlkDPxta8Uh5kvmkSfkk+Ju/u+ dUFXU+aTF/TxRlN3y5YpIzgpK3fG0XLfw8LyfjbQyd+ePaCvWsNZLZ3IWt4PoPpzIGuw+vhz175x JqnU0+c+EDlURikknt6ets0CaYlfXtX19JyBj1tGDJgdXJlfm0qsb+5t/CWmHHWy3fqk/a7pIspG NtPmrdyyy/viveCY9JIGamVWdOD5v1dONeTUpCUuZSKfsCS2j7+xupHNOIQ2N3CpD0NIdZRyh1P4 +aQnefv/xnSiCSXujzm73tWi/eoC4lbY7RHJr88+o4+zU/IDz7yhNyIFJ292UeZHBho4YTW7hTt9 gj+VNZWmhN088tvCycYdTXkifzo9a/Ku2DqUpx2NVNfEZlGnEbED6oiIjCj/ILHzQKzIh0z84j2E jZfMZ1Ryub6+6fSepbr4yw9bdxofNmMN03qdvnUBflEZTGcMtba8gU03p9b9qB9iGconJI6NtMSq RvZVKK2xqh7TNSIsIdyuoS8xdvEEeuuCGOX/scW+5IIwxpaIhq528j+rU36Fca6Ms50zH0eVUhEE QSiFIfcYC88tl05S5If6s780GFoZcdIPM19XetHLWvarX1p16C/YDXCLbxx9XdmV+WmUrgslSm5o 4GkNxj9suCymGNbk5tcNhQ4fvJQa9oyairzK3uVS06cjHtujm5k6Bhf+e/dtdhW5ofDzu2C/S8f3 /e41f5qVvgJjSB9tJjbzciYSZLRkMR/Ls8vZ6xhCiT9KG/slW3HDbPbd32vMdC3zqNvGpz+o/ekC wsarvPQY9ca7C49/7p1Pzg24mMjoG3TZPFluIC8MxgnKj5y8aNvRW2Efv5PqCxKfXfln3awx8m1v Sz+85nxmMy87WnVhJZt9oE2lXzELS0VUlMX4BoWdBwpDNH5hWlAKi2LYbOXkHhwtxL0HETJatICx D/i3e7fTfoqw2rhLj1pXFkm5rLaW7D8XICjoY49NKUkrZdM9SKUZpUNMgxGkmY6QKMv6wf6wELks 8wfmo5SaVLvJHTgpmyUO9O6Tqpct+9dTf0QF0jWVmtMkNfr3COpTnBg72ic/iKtCEYT6/cUdxvml 5kumKPFzr/CAButCD5UEn3iM2cNNYe7qsd3YBwwnYbvxF+zp3rWBRx4VtWu3MW8Q1Uwkd1ndU5gW gfIiQiqjlLAt1tdZjUOgghEYPmo45mNB4jf23pqUefOffUfP33wY+vZDZnE1qUWnoxVhu49i9wFU 9PT/8v7W/zxstTpZ9EurL63AVmsoymOZiJczMsDs0PfjQ2olW/N+mgoSC/otZ0VMtvsft2Gq8ktv Llh6I4/cjy4goLtwA+Y034RLj/IpCIKQvwZcY2z+Lzdvo73UoFlywieqMsZp+V9ngxK/12UG7bBl mgz48eqDrz0Jbn3laJT8zyVsPV/Tt5gsTO+Nxlh1ocFg5wHE0IxfPJkThp6ejMN38/1905oQBEGr o32etm5VLTfHy3JYP7qAoMpYQ8zUjvyYlCq2FDsp/10KcYhlJ0FxFPYIt8L36dXs9m6gtRkx2G2n h48a3v54CZy0/RI7epwuDn6aQ0LQmsQAuqaSnjBTF1ObCum5TKRPIiTHBSTXI7QfEXcYBwaYLp6m jOdi4QEN1nnM/BZw4iUmzKosWDWmeysARMesWT4C85n6xvtmWw3cZuNZYmXXI9nErzHfeDsHhEY4 YDfkrXzxIJXN2oZa9ubS8XM3HjyPTEjPrxhYp1HyS4+2xiwdangfmtXExtfIeQ8P7dq9bd0St2n2 Y/SUx537SkEQBKlLvPkCszmXyMyzx91UulzW0/QtDls2aNSer0fgUiaKGEw3xoiClIDYSjYekfL9 7euifsxbQb31d85PYdoUpD7Ya95/KY395wJ4dbfNExglIvnKw1wy0pz94DpDUKgtXmshNnA8iEaq yv8cHXr/6rmb8Z03ZPjEdGb9+zhgEXZM9evbnJ40lfvM0TLDEtlpnZELXgZjkpa1ZvdwKh6380Bq +Q/J+MWTCOotWMyYCV7gfye1CUGr3/kEt67aVJy7wkysX11AfPScMZiIlnAvmp2IRs4PeZg91HIT J240QQujq5L846rYbKDUJN5PwG5rbz1SkkVDn0/WYbEV/Xp2UHghhZgaFNfaDhO2cWM+u110lJst ParXvnmU3lARdSuGXh6MFzmp4KH+7C8N1px5+wz2AD3NxUtHdfeQFkGDpWtHYS+knz2b1MBcKgWG DcOE2MqvJY1dFMr6T/ffsRcRcP3WAS5h4TEWkw3Ft469ZqdeQkjpZ1d5bV2/1H3GeAtDdVkRg72p fdRlwAlbCevPcsBMiijwv5PStbNRCsPup2O6d8bbDscjCEIpS83ElpRRbtYyXRfsxoyHIdgB+45X CLPxvtzJRD45hwWY4RvSyzNPi7psqpC/PrjyqX9rFYLG0uvX3JjmvFDjd8zZGVWD9pcL8ClOx26P mHL7eQHx29O7X+hX9FetGCmEDAyqQzwU+YWk1UfZTpu3Yv0G7/gu10rgpK08LDF9oeQGIqX75Zzb joaJ3DHXXpR0WdSb0m9ewBxiPsxx3ijRAWDnwcXQjF+8KcJ05i9hzLkuuH83jVj19lJoa6lV8Vhu ItK/LsCnMGmlHWO+GinE2y+vSwdpSDp36vPQk9QCGtOd1RgfiSEnnhSx01FBKwk5idnpF5Ec56zL sjXOJ++4ZCz90yf/N98yQyJap43hxribSzA7ioS5uznd04vDQj5E3HpLH3gxWuisRoD6s780WONH H58vmM/6Kxb2YH9nwoj5G22wmV58s+2iMIKMJmZLFWrSww+d7stFLXywz7ecrVqZ+ZAUajOl79YC 8ilM3TAF0/qr9tt8sOu1iNRCv9+OZGIu6HrO1RbokwjGGVuJW3i5Yno8Ci/selDYRQ1D/HjxRBLj o4KLh5EwgiAI2mbfFZSN7ZYo+b5/nMlnutJMRnv8vlzKRLzKrI2OjAuUyL/2RVR3miqtPGzv4f4P WPxKcy/cWabIdC37mNv6x6XUfnIBnMyEze6MAvfxbljyi/uMbVzN1nvqCCADBFFtCznGp7rnZ8LL uho0ohHLqjFNXAlVWcHul3PuOhpzt97LXf/F16Odp3z39/9yGJ/l52+wkeB9Ow+6JsTQjF+82WzX dl9myBBhD+5Gh19+0doJrb5gyUjh/nYB/uEu2+cyvBSN27HJt6CzZjZan3Bk5YkCZAgiZLR0KWaH K3LEn7vDK7uyPloTtX9bCGZSkaxrh/NP+RUnLWL08SbeDgx6ltv6aeQc27Zro/lkbd0Ya70zb3p7 v6T3mxt4uqgToP7sLw1WG3P6ViHm82iv+T2qTfmVZ22egrV4XdDhQKZ2uZCmvQGm/qy+++fFtI6m sKF1iUfmrw5vYuuncQIi2AJUU1TTh+qbT95pz1p1zIWcoy5Lr3c6N68x/czC1WGYgSOBif9b2Ufn GnHKVuLWv/86EvNKoV6eJz523OpC6+IPLz/8FaP0120wa+n1xsuMUMAW5I93X3Xeh06rertnltfL NhYmNZDQHr8vlzKRf7jrv+swnWHfL7kvuZLZYapNWVeXefpW8kTNIjv9uN8mDaZrZXcWLL6aS+4n FxAfu34xY1Xx+5MHTtPH7vHjN81RGzibshHUZy7GzBloeLLhz9DyTqNbU+qVo9GYBMycDUW6X865 62htyDvmvuVZh3u50Kqj/3HzesHIf5z5jj+sxAaAnQdfG2Joxi/erBlGuC1nlNhvV7b9+axVgmkt XmQg1P8ugJOevHenGaOvve7pEgcv/2+sh0BptfHesxz3sd2niJKqSr8zKClvGNB5K2iwevdUjGwu vTrX41QnbSQEbcy4tNj1HLY1bvrHdusOd2bAK09dOJre7fVqz6GPrR80nSe2n1mIH+7owhCFOY/j 6R6s+8ssTQGoP3sG2ltoZQ9nMpnJ8nweuadpVQXPY+7J1N+fRsLcQCm4YsssGxVdT8dXUdokQ8x7 ddJTj4W+lFv1roHlL1cGOmJvH7HlVQWVxW21L9wwk12kl7yp7/KdmrP/G4l1iXPfKO1vopYHtxk0 QIStfn+QUU9rfy+pMGzP+DZeNfqflMbeP2pTyi7MBGTE5s4PWi9sVffKA9P9IrHgdV373TAjN6gx 9/xYbgvMbmj/q81FIX/ZMU0zkl0UzPhVcs4JE6Z0hjldSGtg+fAouSzmtMcIVq5gfOIruRfvy41M RFEUpf544inL/HYT9oYVktolWfxy/0QW4wDKm+OJPXfv+qhl2NM8hFxCarrhz/Xxfxm2bbGZ/ZPc 0HfWY/5e2n59VjkvMjOwjIZykNpwd6wcwI/d7RvYOx69TK/BlDrq93szmGpdPqN197NYF3laXcol d+y+CYjUguBKWk/KORcdrebZdBZLubSWXE+to7UrVhn31o9i3oHLYGdiu1JFLb5qiblF7590Uner KY7bmRsRpJtpNmcexjql2cUCSqf3VweNx+bIrpSmPnJeLoUwdutznoKY8KsK5qE1/kzuoLZr56Kt Lal/WZV+FuWhrZ25UNUQk/eObqM2jBb+F5xRxagWaI1Fcbf/mKTIstGqszeV9btUP3Jkmj6nvftz U+/s3sY4HbTfeggbFRTpy3FrZi0kMGajb2otlUWwzQzYZt1GsRj8Fd9VZXDEiIWF5Va8Zfk9Yuw6 VlnCslLgVpwabPRag1EKr9ljoyH/uOtFvSikdVFeCky5q7T2HbYw0CqCF0i36y7Qmrhk28HTl65c PPHvjo2eE5gUuZbzJLmuNVhDu7IlpGExYerUiXYWtute13Jbg6EorSb6r9Ht5qmLjZy59p9LD4Jf x8THx0Q8u3Pqf4tsldoNWTucSG/qqwDGvq261mAoSqt9v9u0rVaWMZ+79ejNoLCouPjYyBC/s38v G9f2ndW8QsuxtRC1xH9m2z5wDedt55/EZZXWNlEozQ2VhWnvHvvsXuagwlSfYZt9Kr8mEHvxvtzI xJ9vVxWxWbutlFF3XLHvUkBYVFxcVNjDy/tWTdLA2BHPGxoMRdHGz4ct2u5XO2JzRBWtD1yARQMl 94xF+wgi5fmimrPVahsNxgnatrpImafs2vY8Spq4bjp46UHIm7ik5A+JcW9C7l86sGm2cZsGr5jT 9XxyD8s59xyNWYNhi4HEGI8/T98LiXqfEBsZ7HfmTw/Ltmd8ijiezmjsUROn62qKw3YenBqMO87L pRDGfn0+EDUYSs49a96++hjlndnMXnlob2fOVzUoKdtnOovRGYK81igLGytTA9U2s+cEmG7W3Zc2 VDQYijZ/uz1Xtp1jGc1Y+8/lB8ERMfGxkSEPrx3aONuk3ZkD4tMuZHb5+qS0/XrtOyVnP6tifXvN i/ntJzZq7kju8He4UHhAgzEXkKz/mHo0BKbcK+1Vp1Ljhz/UmXPC9VE5th6lFN+fL8tuw0XR486X hL9GdK3BaBWPXToa9NRljMVxT4OhKEopC99u1t1JnIJWu6MqqX0XwNi3FTsaDEVRyo/QrcbdOldV we1KVjuXJxfcmSPdLcupuZ2OTTyCzRvra0XUnr8vNzKRUYoK7i9TZzM16TlnTtvjeESDoWhzznnH tnNgZH8J+E7huguwjHq3HdsOtyitj2ngcLXaBxoMRSnFD5epdTcZ/tHbOur2Z6+cc8vRmDSYwpJL ++zZnDglM+PUxzpaj5s4XVdTHLXzYNVg3HBeLoWwbtXnA0+DoZRvF8a2fa8xp76S2SwPrOzM6aoG RVFa3cdTM2TYSkhzyY2Q3VihYOSd1TxkNBiKosSMK+5K3bS+ouv5lHp2BpGaPjG5DIIgCL/DnZIO Mo5W9mBKWx9X25bU2RQULhSeQUUv14OR0q+f/YjVz9PWTerdKadChsvXMBX6+kdHmBaF8Su5XYu+ tUy/y18Rsfz9aeLNBepsRQWc9OQDu8eyXhGSH5/XhPQB/LITD75Nf7DVVorNL4hZbPT7/Gq3nVTf nivLWVvxy005Gp1y08uEreXCshP/Dku+t1y73dIBvMovt976uKuw12yz2+KbnnZ/w1h9ezvMsGv8 jZeltF6+L5cykaAy93Jy3AlX1a6SG+528e0tTzUCwjMQRqy8cdmFufOs/O7ChZdzmvveBfgUp29x ZpZHI5Z5mQ7IOef8Sq4+8eF/O8qw+wW8wZJLiVGHJkjz9cKvueho2JlsI399+sZ7SldiT8rut6AP Dzcai+EGkJ0HK0MzfvFgPijPWGXD7BBjvWb1arkrF1wAJ2a88VHG2xMLjDrraxEwXHgu4cNVD1U+ 7CIogjBhSLmWsN7yu59jjs/TZu+tBQwXnolLu79mpCg71aKgjqtbm+7dTva7xUmNdTdlvqTiNl9f COrPntMrBVcfvZZpVH/YvJCqXs/fJOedb9ONo7ev/fRfUlHkuY3TjVie+Y7XmLTRJ7aM/FPmszMO 1jLlK+7kfF0WrVf9AxnNfTAOxpjYmxV8Yt00w473+BJQH7f034epNZ31E3BvHIxNW7E5DkbvLan8 cG/3L2OVOqg2cErWiw48+lLXefGi1aU/+Hvu6A4bAZJGThtPv/jKmI/cELsBe1a0wf4O+s3YeF9u ZGL7LCp4eWLVeHVW8ZRPffKvN5OrqW27A/t7HAxFUZRS+shTrm2Omuz70MBVF+jAMSKWYcfRO5mk w+PjYHRbZT719pqk28kP4lVsPHf7JlV03YPLbjnnvKMxj4OtiWlAUZRSEXdxrT3LNSFypnP+55fW eXXAoXEwjtp5EI+Dcdx5uRjCul2fD6BxMBSlFl0fh5lawmd3tZDCdnnoxM4crWroD1uX8/Ly3ytn Wukpibc+tLCCvp3bpv+CPv9c6t+YxDQ7yuZ2KW0ojYPRH6Y09sYOd3OFjowvqj1h+aFHad0NisT4 zcoI2y7e/IXZIsM3xLHVvuBK4RkM4FB0QO/MSiMWfoiK+ZxbWFxS2cQvLqumazLW3kpfpsfjAGhj 0YfIyPepuSXVRAqfiJSimpb+aCvrUYpCfX6oCNr040tS/Ie0nPySyvpGMkIQkZRX0dQ3NrcwVhPn 5wHjc8VW5MrspLjEz1l5xRV1TTS8qKSCmq6xhbWFrqwA26nSGos/x8Z9SMspLKsmUvgERaUUNXSN TC3M9OR782g9eV+uZCLaXJ4ZHx2bnFlYVtOEE5YermNs7WBnJC842A6+4YL10OrQXzSm+dX8FILW F/OivNT4B4WtyjI/JH7KyMn/XlFDJNH4BEUkZFVG6I8y666x2C/nXHK0tj9SlBwZGff5a0ktRUha SVl1hLGN/WglIdxAt/Ng794dkvFraORsH7tAw7uVGnZXWo8ZEp8XXuw3UWzo2p9cmf3hfVJrG4kg KiE7XMvQxMx8pKoYPxSegcZA12AAAADsR4DyhzPV3J793FRXcKpf/vN58nxgFwAAAN6stCsCJinM fdW6IkXzfx/T/zUWBLsAgwE8mAAAgCECtfjZqVD6qSaSc36dIgcCDAAAoC+gFNz8Zc65KhVdPT09 PT0ja2dnC7kuG6ENn599YmwJIGhgpQYCDAANBgAAMKBozrrpHUk/tlNl6a/2kjDtCAAAoE/gE8AV JcTFJMS9RBAEQfQPZHzcodf5tmnUkmdH/csZnw2mjRQDQwKDxiXABAAADAkFlnN90z+p9I+mW9eb iIBVAAAA+qjBOUx3DGab9Yxz5+LrOl0NQyn037DuaQPjgsWqmaowdACABgMAAOBdaHX5+ZXNP+M7 pTr98W5nq9UviK3/HjZ3z6IRBDATAABAXyFsNN9ZnvGx8NRMd++oH2SW91KrEs7MH7sgoJJxSXrB 7vlqIMGAwQPsyQEAwCCEGO2lYXupTEhSRpRWV1HLfBgZzvxoxrvfdAXATAAAAH0HOefMBP2N7yjY 6ljZxsNj1gRLI01FKTECtaHye25qfMQz/3tv8qnYryoteZx8ZaY8bD4KgAYDAADg6VB/bIz2b59Z /YvP7N/kqP+NEgYjAQAA9HHVnO+70NLTv7R731Jw9Ym8s0oPam1gUAFzEQEAGIQQZLSHs5y0orzw btA2EGAAAAD9UTWrLbj9IWTXRDm2v6E+63Bkij8IMAA0GAAAwEBAUElfvs0lfq05hyI+XJunAgvB AAAA+kuGKU3d9+Lb17BTG6YbSnR8m4DK2Pk7b70vzQr6Y5wcLAMDBiEwFxEAgMEJpebr+9cRCRkF 5U0EaTUjq4mTLNVFodsJAACAV0BJZZlJiR/Ts78Vl9c2khEBEXEJWWUtg5GjTUeqicPiLwA0GAAA AAAAAAAAAMARoFMYAAAAAAAAAAAANBgAAAAAAAAAAABoMAAAAAAAAAAAAAA0GAAAAAAAAAAAAGgw AAAAAAAAAAAAADQYAAAAAAAAAAAAaDAAAAAAAAAAAIDBTzeOHo+IiKioqJCUlASrAQAAAP0LkUhs bGyUkZEBUwAAAAD9S1NTU319/fz589n/SjfGwerq6pqbm8HKAAAAQL9DJpNJJBLYAQAAAOh3qFQq kUjs1le6MQ4mKSmJx+MnTpwIhgYAAAD6l+Tk5MzMTAhJAAAAQL+TlZX19u3bbn0F1oMBAAAAAAAA AAD0HaDBAAAAAAAAAAAAQIMBAAAAAAAAAACABgMAAAAAAAAAAABAgwEAAAAAAAAAAIAGAwAAAAAA AAAAAECDAQAAAAAAAAAAgAYDAAAAAAAAAAAADQYAAAAAAAAAAACABgMAAAAAAAAAAAANBgAAAAAA AAAAAIAGAwAAAAAAAAAAAA0GAAAAAAAAAAAAGgwAAAAAAAAAAAAADQYAAAAAAAAAAAAaDAAAAAAA AAAAAAANBgAAAAAAAAAAABoMAAAAAAAAAAAANBgAAAAAAAAAAAAAGgwAAAAAAAAAAAA0GAAAAAAA AAAAANBT8GACAGhPdXV1UVFRUVFRRUUFmUwmEokNDQ2ioqIEAkFERERGRkZZWVlZWVlSUhJsBQAA AECEAgAANBgA9AQymfz+/fuUlJTMzMySkhIEQfB4vLi4uLCwsIiICIFAqKmpIRKJFAqlsrKSQqEg CCIjI6Ojo2NsbGxiYgLRDgAAAOBqhEpMTMzOzi4vL+9WhLK0tBQREQEbAgBoMADgLeLj42NiYhIS EigUiry8vJGR0bRp0xQVFVVVVVneT6FQampqysvL09PTc3NzfXx88Hi8oaGhvb29ra0t2BMAAADg FO/evUtMTIyNjcXj8fLy8iYmJpqamoqKioqKip1EqIKCguzs7K9fv8bGxl69enX06NFWVlYQoQAA NBgA9D9kMjk6OjogIKC8vFxeXt7Jycnc3FxGRqZrt8HjZWRkZGRk9PT0EASpra1NSEhISEg4e/Zs QECAi4uLra0tgUAACwMAAAA9jlCRkZGPHz9uiVBubm7m5ubDhg1jP0KZmJggCFJRUfHx48fExMSW COXm5mZpaQkRCgD6HRyKomzeGhUVVV9fP336dLAaMAhITU29ePFieXn5mDFjpkyZ0tGQV7coKSl5 9uxZUlKSoqLi3LlzbWxswM4AwCWSk5MzMzPnzZsHpgAGZfG+evVqS4SaMWNGR0NeEKEAgEfIysp6 +/btsmXLQIMBQIcQicTLly/HxsZqa2svXryYnYGvnsW5kSNHrlq1Sk5ODmwOAKDBAIAdqqurL1y4 8OnTJwMDg19++YV7EcrU1HTp0qUQoQCgvzQY/549e9i8NT8/v7m5WUdHBwwNDFwyMzMPHDhQUlKy YMECNzc3bixTFhMTGzNmjIaGRkxMzJMnTyQlJTU1NcHyAMDxpmRFRYWRkRGYAhg0pKam7tu3j0gk Lly40MXFhXsRSllZOSYmJjQ0VElJSVlZGSwPAL2ksrIyPz/f1NSU/a/AejBgCPHo0SM/Pz89Pb1V q1YJCwtz9beMjIx2797t6+t76dKl79+/L1iwAOwPAAAAdISvr+/Tp09NTU09PT25HaFMTExGjhzp 6+t7+vTpmTNnuru7g/0BoI8BDQYMFS5fvvzq1SsXF5epU6f2kXfh8YsXL9bU1Lx3715RUdGWLVtg GTQAAADQnvPnz0dFRbm5uTk6OvZlhFJRUQkICCguLl63bh1EKADoS/jABMAQCW9v3rxZuHBhnwkw Ovb29uvWrUtJSfH29iaTyZAXAAAAAJaTJ0/GxMQsXLiwzwQYHUdHx3Xr1iUmJkKEAgDQYADAeQHW Et6sra375QGMjIzWrVuXk5Pj7e0N2QEAAABgI1RiYqKXl1c/RigvL6+MjIwTJ05AdgAAaDAA4Ay+ vr5RUVEeHh4WFhb9+Bh6enrLli3LyMg4f/48ZAoAAACAIMiNGzeioqIWLlzYv7vLtMiwlJSUGzdu QKYAAGgwAOgtycnJT58+dXNz66/+xTZBzsPDIyoqKiwsDLIGAABgiNOyM6Gbm1v/dhFiI1RoaGh0 dDRkDQCABgOAnlNWVnbmzBlTU9O+n2HfEdbW1ra2trdv3y4qKoIMAgAAGMoR6sqVKzwYoS5cuAAR CgBAgwFAz7ly5YqQkJCnpydPPdW8efNUVFROnToFGQQAADBkOX/+vLi4OA9GKBkZmQsXLkAGAQBo MADoCTExMZ8+ffLw8OD2KSvdBY/He3h4FBQUPHv2DLIJAABgCBIZGZmRkTF//nwejFCLFi3KycmB OfMAABoMALoNmUy+efPmmDFj+neVc0eoqqqOHz/ez8+PSCR2+8soMdN/u/NIWX4cDoeX1p+89lxM BRWyHAAAYJ1pIgoAACAASURBVIBAJBJv3rw5duxYPT09Hnw8TU1NW1vbHkYoAABAgwFDmcjIyJqa Gnd3d559QmdnZwKBEBQU1M3vUb5dn2s2/0gYbfzvR86c/sdT5fOF9Tb2O9/XQ6YDAAAMCJ49e0Ym k2fPns2zT+jq6oogyPPnzyGzAAA0GAB0g4CAACsrq2HDhvHsEwoLC0+YMCEkJKR7HY3ERO+/gutV N0fE3T+8bf2GP08HRx0bjaSf/DeqBnIdAACA5yGTya9evRqcEQoAANBgwFDm9evXNTU1kydP5vHn dHR0xOPx3ZtzL6i/5WHoc/8dluK4lgt4ieHS/AilsQmmIwIAAPA+b9++rampmTFjBo8/p5WVFY1G e/v2LWQZAIAGAwC2iIqKMjQ0VFRU5PHnFBYWNjExefPmTTe+wy+hbTVlupUCHqE11/3IjvbduWDd a6qm147xUpDxAAAAPM+rV68MDAx4eRCsBRkZGUNDw6ioKMgyAAANBgBdU11dnZGRYWxsPCCe1tLS sqSkJDMzs9vfrHvlOVxBx9bzQHi9+V/X9zlI4SDvAQAAeD5C5eTkmJmZDYintbKyysnJycvLg4wD ANBgANAFycnJCIJYW1tzIjFqbfqTk7/9MtFUS0FaWlpaWlpew9jBbf3Bu/E/mjnytFpaWsLCwgkJ Cd3+poDuBr+wl89u7HFVSvjXYYzX0x8wGREAAIC3iY6ORhDEwsJiQEQoPT09ISGhjx8/QsYBAGgw AOiCT58+aWtr4/H43iZEq3x3yGWk7ZK910I/fKsit1yk1BamvL7rvX6qgc26ezlNvX5aPB5vYGDQ kwgnqObgNNnRafFu/6grjoLfrmw+lUqC3AcAAOBlEhISBlaE0tXVTU9Ph4wDAG6ABxMAg4n09HRL S8teJ0Mp9F3lfiSmCUFw6pNWLZtlN0pdVoSPVFWYFv30hs/TzOav99a5CCq9+89BspfdGNra2p8+ fSISiSIiIj3yYOXpi02QV3FRX+oRY0EoAAAAADxLdnb2rFmzBlCE0tDQeP78ec8jFAAMGVAU7e5X YBwMGDyUlZXV1NTo6Oj0NqGmlHMHXzchCMFib1S036FNns4T7KzG2jhMm7d238038RdnSiEI8v3G jms5vZ7xMWLECAqFUlhYyM7NzZknJyqKG+z4gOngpBIrGhBESEKMAAUAAACAZykqKqJQKMrKygMo QhkaGlIolB8/fkD2AQDHAQ0GDB5a4kTvd0SklL6P+o4giNj0P5caCrfd7UJAdc6B3RY4BEEyHr4s pvTyt5SUlBAEYXPRs4CSqQatPuPS0RdltJYrtMo3x058RoQdPceIQQEAAADgWcrKyuh1/kCJULKy si3qEbIPADgOzEUEBg95eXl4PF5GRqa3CdGoNARBECqVQmP1b375CV6rZqvUSOqoEtDeeiAeLyUl VVPD3hnL4jZ7T7o9WuDrYlq+cb2zLi7n+fmTwQWSzpdPuyrwIQhSGzbfaO4rlR2RETsMYWIiAAAA 7/Dt2zchISEO7ErfhxFKWFhYXFy8uLgYsg8AQIMBQIc0NTVJS0tzwCsULazkkPSyxmf/OxBssG+6 Sls5Q1B1O3TVjVOPLSMjU1FRweajqfxyJ0nC+Pdd5y78L4yMiKhaeR70ObR1qooAgiAIgjaVF9WV 42vJKJQGAAAAXoJIJHKgi7DPI5S0tHRtbS1kHwBwHJiLCAweGhoaCAROLIsSNt2yy1EYQZCcS57G ujbzfj1yMzgxr4bMnccmEAjNzexP2xdUc/rbP7GkGUVRtCE/5vafrQIMQRAJl5c0FM09OFoISgMA AACPabABGqHIZDJkHwCABgOAziKcsLAwJ1LCq3peCz7sooYgCFKXEX7j0BbPyWM0FdTMpi7+3ft2 ZHYtJ0/jkpCQKCkpgewDAAAYxDQ0NAzECCUiItLQ0ADZBwCgwQCgT8CJG6+6/j7jhc//Fk80aJ09 Up8b//TqwU2ulhom8w6+KOLQiVy1tbV5eXnnz58HqwMAAAxWBAQEODag1IcRCgAA0GAA0AUiIiKN jY2cDJnyZnN/P3H/XVZpbmLYnZN/ec221mw5I6Uo3Hv+uOV3vnEinuLxeC0trZiYmAMHDsCUDwAA gEEJgUCgUCgcTLBvIhSZTObMFEoAAECDAYM4whGJRK6kLKFpPn3Rb4euPkvMy3lzeaOVGIIgVcG/ //a4tPdzPohEorKy8tatW3Nycg4cONCyfzEAAAAAEarfI1RjY6OoqChkHwCABgOADpGQkODAOBit Ieft0/u3r/snVLCKXnipkXP2Pghar4ogCCnyZkxVr7cgrKiokJCQMDEx2bVrV0VFxcGDB0GGAQAA DDJkZWUHYoSqqakRERGB7AMA0GAA0CHDhw9vampie5/3jiLcj9A/F6/etHXz0fe1HUUvEX0neykE QahlBTW9nlpSV1fXcmqnhobGrl27KBTK/v374UxMAACAwYScnFxdXV1v93nv2whFoVCqqqrU1NQg +wAANBgAdIiGhgaCIAUFBb1KBa9oYSmHIAjp9dknhR2EL2p1TnY1giD8cqoSvTtjr6CggEKhDB8+ nB6k9+3bJyUltWPHjtTUVMhTAACAwUFLPV9eXj6AIlR+fn5LYILsAwDQYADQIaKioiIiIoWFhb1L RnjUiqVaCIKQo7d67Hya39S2qxFtzPLd9vd7FEEE7DytpHC91WAIgmhqatKvSEpK7ty5U19f//Dh w/Hx8ZCtAAAAgwB5eXkREZHe9hL2bYRqmZGBjVAAAHAKPJgAGDQQCAQDA4OsrKxepiNkuOHclsdT T3yhpfssNrlv7OTm7GimO1xGiFpbkp0Y8eR+UFI5giD8pjsOuijy9+63vn37pq+v32bXKQKBsG3b ths3bpw+fXrOnDmzZ8+GzAUAABgEESojI8PBwWGgRKi0tLT2EQoAANBgANAWbW3tgICAxsbGXh2F iRO3+OtxoMCKZUfeViNVn55f/vT8cptbJOy2376+QV+otw+clpZma2vLMlovWbJEQkLC39+fTCa7 u7tD5gIAAECE6ssIlZWVNWnSJMg4AOAGMBcRGFTY2NhQKJQPHz70NiF+OYc/H31ODDi6aa7DKFUp gVZpJKVp5rTyn7vvPwdtt5XuZQ8j8uXLl8rKSjMzM5b/JRAI7u7u8+fPDwwMPHnyJBwdBgAAMAgi FAfW+vZJhEpNTW1sbLS2toaMAwBuAONgwKBCTk5OX18/Li7Oxsam14nhRDQnLN8zYfkebj1tUlKS rKysrq5uJ/fMmjVLXV392LFj3t7e27ZtgzkhAAAAAz1CmZubD4gIpaWl1bLZFQAAHAfGwYDBhr29 fV5eXm/3/+U+jY2NiYmJ06ZN6/JOExOTrVu3fv36de/evXB0GAAAwMDF3Nw8MzOT9yNUbW1tQkIC DIIBAGgwAGAXOzs7UVHR0NBQHn/Oly9f4nC48ePHs3OziYnJ3r17a2tr9+/fDzIMAACg30CJmf7b nUfK8uNwOLy0/uS152JYHpfMmsmTJwsICAyICCUgIMBmhAIAADQYACAEAmHmzJlv377l5Y7GxsbG iIgIR0dHERERNr+irKy8a9cuBEH+/vvv3u/9CAAAAHQfyrfrc83mHwmjjf/9yJnT/3iqfL6w3sZ+ 5/v6wRShamtr3717N3XqVPYjFAAAoMEAAJk8ebKoqGhQUBDPPmFISAiCIE5OTt36lpyc3KFDh5SU lPbv35+cnAwZDQAA0KcQE73/Cq5X3RwRd//wtvUb/jwdHHVsNJJ+8t+oGrbTcHJyIhAIvByhWobp ZsyYARkOAKDBAKAbEAgEDw+PuLg4Dmw/xQUKCgrCw8NdXFwkJSW7+10REZEdO3bo6+sfO3bs9evX kNcAAAB9h6D+loehz/13WIr/PPwYLzFcmh+hNDaxPx2RQCAsXrw4MTHxy5cvPPiKubm5ERERbm5u MAgGAKDBAKDbODg4GBsbP3jwoLGxkdee7d69e2pqarNmzeqxwty2bdvEiROvXbt2//59yGsAAIA+ gl9C22rKdCsFPEJrrvuRHe27c8G611RNrx3jpbqTjI2Njba29oMHDygUCk+9H4VCuXv37ogRI7o7 TQMAANBgAPCTRYsW1dfX85pKuX//fmFh4Zo1a3qTSMsJzjNnzgwMDPT19YW8BgAA6FPqXnkOV9Cx 9TwQXm/+1/V9DlK4btbhK1asqK6u5rUKPDAwsLS0dOXKlZDDAAAaDAB6iLKy8urVq+Pi4iIjI3nk kRITEyMiIjw8PDhy4oq7u/vq1aufPn3q7e0NJzgDAAD0HQK6G/zCXj67scdVKeFfhzFeT39Qu5eA srLyokWLeDBCrVixAs4EAwDQYADQKywsLJydnR8+fMgLO1h8/fr17t279vb2HJzj4eDg8Mcff6Sk pHh7exOJRMhxAACAvkBQzcFpsqPT4t3+UVccBb9d2XwqldSDCtzR0fHhw4e8sHT5y5cvV69etbe3 d3BwgOwFANBgANBb3N3dzczMrl271r9BrqCg4Ny5c1paWmvXruVsyiYmJtu3by8pKdmzZw8cHQYA ANCn4JWnLzZBkK9RX+p78O0lS5aMGjXKx8en3yPUpUuXTE1NOR6hAAAADQYMUQgEwrp16/T19X18 fPprNOzLly8nT54UExNzdnbmRvpGRkbbt29vamqCE5wBAAC4R3PmyYmK4gY7PjQxrlGJFQ0IIiQh RuhZhDIzM6NSqRcvXuwvGZaamnry5EkpKampU6dCFgMAaDAA4KQM27Zt27hx465du9ZyMFdfkpiY eOrUKX19/bVr1x46dGjLli1hYWEcnzfYcoIzgUCAE5wBAAC4hICSqQatPuPS0RdltJYrtMo3x058 RoQdPceI9SBBX1/fy5cvOzg4mJub+/j4vHz5so/fKCoq6ty5c8bGxkuWLKFHqOrqashrAOA2/Hv2 7GHz1vz8/ObmZh0dHbAaMPAKOj//qFGjUBR99OhRfn6+np6eoKAgt3+UQqEEBAQEBgY6Ojpu3LhR Vlb269evOTk5ycnJz549KykpERERkZeX59TPiYqKOjo6JicnBwUFaWpqKioqQr4Dg5iSkpKKigoj IyMwBdB3CCqbqaTdvO1/1Te2klSd8+7u3pXr7xZIOl8I2m0vzY8gtWHztU3X3UecF9nL4TtNiUwm +/j4hIeHL1++vGXOPIqigYGB379/NzAwIBAI3H4VCoVy+/bt0NDQqVOnrl69WkFBoSVCffz4MSQk JCcnR0BAQFlZGfIcANihoqKioKDA1NQUNBgAsJBhRkZGWlpaUVFRcXFxkpKSXFUpubm5Z8+e/fLl y/r16+lHgenq6r548QJFURRFi4qKIiMj37x509zcrKioKCQkxJF3tLGxyc3NffTokaioqJaWFuQ7 ABoMADgH37BRszwsCUXvn96+/eDpyxSSwbwdlx+ecFcXQBAEQZpSL/x1IxVv4bV+kmInGoxIJB48 eDAlJWXz5s329vbYCBUeHh4XFycnJ8fBHjqWEerEiRPFxcW//vrrtGnTsBGKRqOhKFpeXh4dHR0e Hl5bWystLT1s2DDIewDgrAbDoSjK5q1RUVH19fXTp08HQwMDmrKysps3byYmJpqamrq6usrIyHDc D4OCgpKSkrS0tDZt2iQnJ4f9740bN8LDw6nUn9sY8/Hx4XA4BEGMjY3Hjx9vYWHR+wcgk8n3798P CQmZOXOmu7s75DgwKElOTs7MzJw3bx6YAhhwMejQoUM1NTU7d+5svwt8WVnZlStXPn361C8RytfX Nzg4mB6hWoIUgiDa2tpTpkwxMTERERGBHASA9mRmZr57927ZsmXsfwXGwYAhh6ioqI2NjZKSUnR0 dGhoaFlZmYKCgpiYWO9TLikpCQwMvHXrFplMXr58+ZIlS0RFRdvco6urGxoaSqFQWj6irZSVlUVH R79+/drCwqL9t7pFy8RLCoUSGBhYX19vYmICmQ4MPmAcDBiI5OXl/f3330JCQnv27GE5009UVNTO zo4eoaqqquTk5DgVofz8/Hx9fTuJUFpaWtgIRQ9SVVVVcXFxz58/t7Oz62WEAoBBCcxFBAB2UVVV nTRpkqSkZGxsbHh4eEZGBoIgsrKyPZiFT6FQ4uLiwsLC/Pz8mpqa5syZs3bt2o7OuGxJPy0trc31 lhHp/7N333FNXW0cwJ9LEqZsgigqKKIIVVkqoBZX3Whbxb1fV+3Q0qLSolZw1pbaat1ata0LEAfu iSI4QEGKKKAgGgEDyAwj6/0jioiKISTM3/eP9/MWw+XmnOfc5z53nDNkyBCl3AojIjs7OxMTk+Dg 4ISEBBcXFxaLhU4H1GAAdSgqKiogIKBly5ZLly41MDCQJ0PJHghUVoYSCoXjxo2bPXt2FRmKw+HE xcW9M0NNmzatc+fO6EcApdRgeBYRmjqhUBgTExMZGXn9+nU2m21paWlpaWlra2tiYlLFQyD5+fnp 6elJSUlJSUnJyclE1KVLl969e/fs2VOev/jll18WFlZeTKZ3795KX5slJiYmICDAxsZm3rx5Vad8 gIYFzyJCw3L+/Pldu3b16NFj/vz51cpQN2/evH79enR0dMUM1aJFiyre0ZJlqISEhJSUlOTkZDab 3bVrVxcXFzkzlLe3N5/Pr3R+2K9fv5kzZ6IfAd5JgWcRUYMBvMTn82NjY5OTk2NjY/Py8ohIQ0PD 2NiYw+Ho6+vLMpNQKBQIBDk5OSUlJUSkra3dqVOnzp07Ozg4VHqqvmphYWHbt2+XSF7ObqympmZi YrJ+/XpVfK+kpKQNGzaw2WwfH59q7SQAajAApdizZ49sBsKpU6fWWobS09OztrZWIENFRERs3Lix /D9VmqEAUIOhBgN4I9s9f/788ePHWVlZAoGgqKhIKBRyOBwdHR19fX1tbW0LCwsul6vwvL1CoXDx 4sWZmZkSiURNTU1XVzcvL693794zZ85UxZTEfD7f39+fiBYtWoS5hgE1GECtEQqFmzZtunHjxowZ MwYMGKCUDebm5laRofT09MzNzWuYoVauXJmcnCyRSFgslr6+fn5+vo2Njbe3dy1Mmg+AGgw1GIBq zyB//vlnhmEMDAzWrVt379492VLOKkpyfD5/48aNKSkpixYtwis0gBoMoBYIBAI/P79nz555eXk1 rOmRkpKSli1bVp6hEhMTt27dqqur6+3tjecpAJRSg6mh1QDqhL29vWyp6B9++EFbW9vZ2dnLy+vJ kyc//vgjn89X+p/jcrm+vr42NjZr166NiYlB+wMAqBSPx1uyZEleXp6fn1+Dm5/W2trawcFBXV1d lqHs7e19fX1LSkr8/f15PB46F6DmMC8iQJ0xNzfv169fmzZtZP9pZmbm4OAgW7jZ2dlZ6fP/slgs FxcXPp8fGBjIMIyNjQ26ABouzIsI9VlSUtKKFSt0dXV//PHHBvoEuKWlZe/evcszlJ6enrOzc1xc XFBQUNu2bc3MzNDLAOUwNz1AQ2JsbFxprkJZkouKigoODu7QoYOpqanSyzB7e3upVBocHCyRSHD+ CqjBAJQuMjLyjz/+aNmypa+vb8OdkFZPT6/SzsvWLktMTDx+/LiBgUHbtm3R1wCowQAaCR0dHXd3 98TExKNHj7Zq1UrpF1BZLJadnR2bzQ4KCnr+/LmyliMDQA0GQETnz5/funWrk5OTj49P45vBQvY8 RVlZWVBQkEgkwgAEQA0G0NiSXG5ubmBgoIqSnI2NjYWFBVZwBtRgAEq0Y8eOw4cPDx8+fNasWY04 Q3Xu3FkkEoWEhDx//tze3h4ZBAA1GECjSnJSqTQkJKS0tLRz585K/xMtW7Zs27btmTNn7t69a2dn p/TXzwBQg0HTIRQKAwICbt26NWvWLA8Pj0b/fe3s7GQX8hITE52cnDBnPaAGq24NhnkRAeopDofj 6ek5Z86c0NDQdevWCYVCpf8J2VRX2dnZq1evVsVkjAAATYFAIFiyZMmDBw+8vLzc3d2byLeWTeeb kZHh6+uLDAJQXajBAOo1d3f3hQsXxsXFrVu3Ljc3V+nbt7S0XLJkiUgkwozDAAAK4PF4ixcvzsvL 8/X1bXBz0NeQvb39okWLkEEAUIMBNM4k5+vrm5GR4efnp6Klw/z8/AwNDX18fLB0GACA/GRrGWtr a/v5+VlaWjbBFjA3N/fz8zMxMUEGAUANBtDYdOjQofxuVWpqqtK3b2BgIFvBWfY+AxocAOCDIiMj ly1b1rp166VLl3K53CbbDgYGBj4+PrIMcvbsWQQGgDwwJwdAw6Cjo+Pq6hoXFxccHKyK9TErTsaI FZyh/sOcHFC3Tp48uWPHjt69e3///feYkaJ8zvpDhw5h8UlogjAvIkBjpqmp6ebmJlsfU0dHx8rK SulJVDYZI1ZwBtRgAFXYsWPH0aNHP//886lTp6I1KmYQ2eKTT58+dXJywpz1gBoMNRhA40lysmuN hw8fVsXSYbIVnLW0tA4dOoQkCqjBACoRCoXr1q2LioqaNWvW0KFD0SCV2NjYWFlZHT58ODExsXPn zpqammgTQA32TngfDKCB4XA4EyZM8PDwCAkJ2bx5syr+xNChQxcuXBgdHa2iOfEBABqi3NzcJUuW JCcnL1q0qOnMQV9dsskSVTePFEDjgBoMoEHy9PT8+uuvIyMjV61apaKlw7y8vJ48ebJ8+XIkUQCA 1NTUpUuXCgQCX19f3ICtmp2dXfk8UklJSWgQANRgAI2Hq6url5fXo0ePVFQmyebEz8/P9/f3RxkG AE1ZUlLSihUrmvIc9NUlW/XExMTE398fc9YDoAYDaFRUXSaZm5svWbKEw+EsXboU1zIBoGmSzUHf sWPHpUuXGhgYoEHkJJuzvnPnzgEBASdOnECDAKAGA2g8LC0ty8uk+Ph4pW+fy+WuWbOmRYsWuJYJ AE3Q0aNHN2zY0Lt3b29vb21tbTRItXA4nAULFnh4ePz777+BgYFoEADUYACNR3mZtHbtWlWUSRwO p3z9zUuXLqHBAaApEAqFmzdvPnjw4NixY7/44gs0iMIZxNPTc9KkSSEhIZjnCaAc5qYHaBQjmcVy c3Pj8XiHDx9WxQrL5XPiBwUFqWJOfIDqwtz0oFICgWD9+vV37tyZNWvWoEGD0CA1ZG1tbWVldfTo 0cTERBsbGx0dHbQJNCZYHwygSZdhTk5OqlthWbb+pkgkCgkJKS0t7dy5M9ocUINBo5Sbm7ty5cqn T5/+8MMPjo6OaBClMDMz++ijjy5evBgREeHo6IgyDFCDoQYDaDxlmJ2dHZvNDgoKUtEKy3Z2diYm Jvv373/06FH37t2xgjOgBoNGJjU1Vbbmh6+vL6ZAVC5jY2NnZ+fLly9fuHChY8eOxsbGaBNosjUY 3gcDaGxGjhxZvsKyQCBQ+vbd3d0XLlwYFxenou0DANSV+Ph42Rz0a9asMTc3R4MoHZfL/fXXXzHP EwBqMIBGyN7eftGiRRkZGT/99JOKlg5T6fYBAGpfWFjYypUrZXPQYwpE1ZHN8+Tk5BQQEHDkyBE0 CKAGA4DGw87ObtGiRSUlJf7+/jweT6XbRxkGAA1dUFDQ1q1b+/Xrhznoa6cMmzdvnoeHx6FDh/bt 24cGAdRgANB4yFZYNjQ09PHxUcXSYRVXcFbF9gEAaoFsDvrDhw9PmjRp5syZaJBaK8M8PT1nzJgR GhoqewEPbQKowQCgkeByub6+vjY2NmvXro2IiFDF9lW6NBkAgEoJBILVq1dHRkZ+9dVXQ4cORYPU sgEDBixcuPD+/furVq3CIxXQpGBeRIDGPshZLBcXl9zc3ODgYFUs7SVbmiwlJeXo0aM6OjpWVlZo c6gFmBcRao7P569ZsyY9PX3ZsmVYb6OumJmZOTg4YM56aNAwNz0AvLtMcnR0lC3tVVhYaG9vr/Tt d+/evays7PDhw1jBGVCDQYOQmpq6YsUKiUTi6+vbpk0bNEgdMjAwcHZ2vnbt2tmzZ9u2bWtqaoo2 gUZfg+FZRICmwtPTc86cORcuXFDFk/ccDmfChAkeHh4hISF79uxBawNAfRYVFbVixQoTExPMQV9P VHyy/datW2gQaPRwHwygCbG0tGzbtu3x48fj4+Pt7OyU/siHnZ1dy5YtDx06lJCQ4OLighWcQXVw HwwUFhYWtnHjRkdHx/nz52MKxHp0Sspiubm58fl8FT05D6A6uA8GAB9gb2/v5+eXnZ29evVqVbwA 7erq6uXldf/+/XXr1uXm5qLBAaBe2bdvn2wOehRg9RCHw5k5cyYeqYCmADUYQJNjaWm5ZMkSkUjk 7++flJSkijJvyZIlGRkZfn5+mOcKAOoJ2Rz0oaGhM2bMwBz09bkMU+mT8wCowQCgzsievDcxMfH3 91fFnPLW1tblZZ4qVogGAKgWgUCwYsWKyMjIb7/9dsCAAWiQes7d3d3Ly+vRo0fLly/HtTxADQYA jYe2traPj0/nzp0DAgLOnj2rijLPz89PdStEAwDIic/nL1myhMfj+fn5devWDQ3SINjb2/v6+ubn 5/v7+6MMA9RgANB4cDicBQsWDB48ePfu3YGBgUrfvoGBQfkK0VjBGQDqRGpqqo+PDxGtXr3a0tIS DdKAyJ6c53A4uJYHjQ/mRQRo2ocAFqtz585sNjsoKOj58+f29vbKncxQtkI0n88PDAxkGMbGxgZt DkqBeRFBHlFRUQEBAS1atFi6dKmBgQEapMHR0dHp169fQkLC0aNHmzdv3rp1a7QJ1ENYoxkAFGFj Y2NhYREcHJyYmKj0OeVZLJa9vb1UKg0ODpZIJDhpBtRgUDvOnz+/adMmR0fH77//XlNTEw3SQMmu 5eXm5mLOekANBgCNTcuWLdu2bXvx4sXw8HB7e3vlLh3GYrHs7Oxkd9syMzMrvY+RlJRkbGyMLgDU YKBEe/bsCQoKGjRo0Jw5c7BWYSMowxwdHUUiUUhIyIsXLxwdHdEm0NBrMLwPBgAvyV6ALikpUdEL 0CNHpTSECAAAIABJREFUjvTy8rp+/XrF6YZTU1NXr16tiklBAKBpEgqFv//++5kzZ2bMmDF16lQ0 SKPh6en59ddfX7lyBXPWQyOAGgwAXjM3N1fpC9DOzs6y6YZXrVrF5/P5fL6fn19JSUlISIhAIED7 A0ANCQSCJUuWREdHL1y4EHPQNz6urq5eXl5Pnjz58ccfMVki1B8Mw1T3V/AsIgC8oeIL0K1atTI3 N1fu9s3MzLp06XLx4sVr165dunSpqKhIKpWWlZWx2WxbW1u0P8gJzyLC2/h8vr+/f2Fh4ZIlSzAD UGNlZmbm4OAQFhZ25cqVLl266OnpoU2gzuXk5KSlpeFZRACoEQ6H4+3t7erqumHDhpCQEKVv39LS 0sfHJycn58WLFxKJhIikUumJEydwKwwAFJaUlOTj48PhcPz8/DAHfeMme2RDtsol5qyHBgo1GAC8 uwybOXOmh4dHYGDgvn37lL793bt3i8ViWQEmIxKJjhw5gpYHAAVERkauXbtWNgc9l8tFgzR6XC7X 399ftv7k5cuX0SCAGgwAGk8Z5unpOWPGjNDQ0HXr1inxBejNmzf/999/FQswIhKLxadOncrNzUXL A0C1nD9/fsOGDZ07d/b399fW1kaDNJ0k5e3t3b9//127dgUGBqJBADUYADQIJY9D/cZ2b63DMAyj ZmDdd86m6zniyh8aMGDAwoUL4+Li1q1bp5QC6ezZs1evXn3f26tBQUHoGACQ344dO3bt2jV8+PD5 8+ejNZpakuJwOFOnTvXw8AgJCdm8eTMmS4QGBHNyADRN4mcHJ9qP2hSl3nOu91eThzhoJx3ZvXPz 8dLBU/q30nizPjIzM+vQoUNYWNjVq1cdHR1ruHSYlZWVi4tLSUlJZmamWCxWU3t9JUgqlaalpfXo 0QPvWMMHYU4OEAqFAQEBt27dmjVrloeHBxqkySYpOzs7CwuL4ODgxMREJycnDoeD5oNapsCcHIxU KpXzo1evXi0sLBwyZAgaGqDBK7n9fQenX8tmnLm3faCRGhFRacI6N9uFMb33PLk8peU77pDLJhwj okWLFillskShUBgWFnbp0qWUlBQWiyUWi+nVQpzffvstugiqFhMTk5iYOGbMGDRFU8Dn83Nzcyte BRYIBH5+fs+ePfPy8rK3t0cTIUnFxMTs2rVLU1PT29sb7wRCLUtKSgoPD58+fbr8v4JnEQGaIknu wzQNU9uxs3oZvToIaFgN/7wjSR7dflb6zl/hcrl+fn4mJiY+Pj4xMTE13wcOhzNgwICVK1euW7fO 1dVVQ0ODYRixWBwdHY15rgCgor179/7yyy/l60HxeLzFixfn5eX5+fmhAEOSkrG3t1+0aFFJSYm/ vz+Px0MbQj2HGgygSY58M89DSZnxv7u8fntdWpAU9ZSoeQfue5/iMDAw8PHxsbGxCQgIUOI8VObm 5vPmzdu2bdv06dPbtGkjkUiCg4PRRwAgEx8fHx0dXVhYuGLFCoFAkJSUtGzZMm1tbcxBjyT1djbx 8/MzNDRU1rVCANVhownqudzcXB6P9/jx46ysLKFQKBQKi4qKdHR0OByOtra2sbGxubm5qakpbrtD zUjzwld5HSnSGjh/RKuqDguyeagCAwN37drF5/M9PT2VGOdlZWW2trYtW7ZMSUnx8/MzNTWtGOcG BgZKXzAaAGohSdVw8AYGBqqpqUkkkhcvXvj6+mZlZVlZWXl7e2MKRCSptxkYGPj6+q5bty4gIGDS pEkDBw5Ubpzn5eUJBAJVxDmgBoO6JxQKIyIiYmNjk5OTs7KyiIjNZhsZGWlpaclGe1ZWVm5urkgk ysnJEYlERGRsbGxtbd2lSxd7e3sDAwO0IVQrtxXc/vWzIQEPTcce2DWhFesDn+ZwOBMmTOBwOCEh IXl5eTNnzlR6nOvq6qqrqyPOARpukioqKiouLq754L1161ZiYqLs/4tEoszMTGNj42XLlqEXkKSq SFKya4W7d+/Oy8tT+FphbcY5oAaDOs5qN2/ejI6Ovn79OpvNNjU1tbe3b9u2rZmZmZmZ2Tt/RSQS 5eXlZWVlJSQkpKSkbNu2jc1m29ra9u7du2fPnmhSkIMo/dTiYSN/vcMduzts91hzeY8Jnp6erVq1 2rx58/Pnz729vas1D9W1a9cQ5wANUe0P3t27dzPM6/nDpFJpVlbWvn37JkyYgO5AkqqiDJswYYKO js7BgwefPXs2b948JCmobzAvYn2pvsLCwo4dO5aVlWVqajpw4EA7OzsFpufOz8+PioqKiop6/Pix mZnZqFGjunfvjkla4b0keVHrxw/+7lS+g9fRk2uHmFX7okxMTMzGjRtbt249b968Dz4Qq6I4HzFi RM+ePRHnTQ3mRWy4SUp2Y0GewXvy5Ml//vnnnf80bdo0ZT1mBo07SQUEBNjY2CxYsOCDD68qK86L i4sjIyPL43zw4MF9+/ZFkmrcFJgXETVYvTiT2LVrV25urrOz8yeffPK+qyzVkpGRceLEidu3b5uZ mY0ePdrNzQ3tDJWJ+ecW9h8cENfCc9vZv2ba6jCKbSY1NTUgIICIlixZUkUZhjgH1GBIUtUavAKB 4KuvviopKXnjrIVhiEgqlWpqaq5duxbvQiNJfVB8fPzWrVvZbLaPj88Hk1RWVpaLiwuSFKAGa+T4 fP7OnTvv3r3bqVOn8ePHGxsbK3f75YP/o48+mjVrFnIVVFD839o+Dotvtv/mdFjAIFNWTSN5zZo1 shOmt9fMRZwDajAkKQUG7759+06dOiVbOVBGtpCgqanpmDFjunXrhhsLSFJy4vF4a9euJSIvL6+3 59LMzc3dsmULkhSgBmsqIiMjd+7cqampOW7cuLdPW5V7phIcHFxSUjJnzpxu3bqh5YGIRCmbPm7/ ZaSkZb9xA1qpV/gHFnfAD6smt1fPPzvWbvTFVj5hl31sNeTYoFAoXL16dXJycqX1UmstzuPj4w8c OJCfnz937lxca0QNBg0oSb1z8PL5fC8vL1kBJnsfTFdX183NbcCAAZh6DklKgSSVm5v7xx9/vJ2k ZE/U12acT58+vW/fvuhi1GCowerGnj17zpw54+DgMHHiRC0tLZUfy0Siffv2RUdHe3h4KGsycWjI JLxdrq3+d/Nd/2Q8/erjXb108o71Nxx50WJxTMLqrprybVQoFG7atCk6Ovrzzz//9NNPiWjfvn2h oaG1HOc3btwYPnw43tdHDQY1UeeDd8OGDZGRkQzDqKmpOTk5de/eHddWkKRqnqTWr18fFxc3duzY YcOGIUlB3dZgmBextgmFwh07dly9enXUqFH9+vWrnT/KZrOnTJnStm3bAwcOKDBBEDQ6auYzbkhn VPUJ/REXJNLqbZTD4cybN+/IkSOHDh0qLS3Nycmpwzjn8XgLFixAnAM0uCTF4/GGDx8eGRnJ5XJ7 9+7t7u6OZ7eQpJSVpBYsWHDkyJF///1XIBBkZWUhSUEdYv30009yfjQtLa2srMza2hqtVpPctmnT pps3b06ZMqVXr161/NctLCwsLS1DQ0MTExNdXFxYLBZ6BJR8QGGx7OzsGIY5cuQIj8erwzg/deoU 4rxxy8jIyM7OVumzQ0hSdTV4k5KSpk+fPmvWLFtbWx0dHfQLKDdJaWlpBQYGPn36dOLEiR9//DGS FNRcTk5OWlqag4NDNa40oNVq044dO6Kjo+fPn19X72XZ2dnNnj37/v3769evR3eAimRmZrJYrLqN 83nz5t2/f3/dunXoDoCGlaTmzZuXmZl58eJFdAeoyOPHj1ks1pw5c1xdXZGkoK6gBqs9e/bsuXr1 6qRJk9q1a1eHuyErw+Li4vbs2aOcLUrzI75vz7b68W4pOhnqS5x37NhRdrlh8+bN6BSAJj14kaTg XXFet3fRkaQANVgtiYyMPHPmzKRJk+rDzIR2dnbjxo07c+ZMREREzXPb7fWjB//6UCxFJ0N9jPOr V6+ePXsWXQPQRAcvkhS8FeejRo1CkgLUYE1Camrqzp07e/ToUVd3vd/m6uras2fPLVu28Hg8hTci zLz2x3h7J69zBehjeLWUkIODQ32L83/++acmcQ6AwdtABy+SFLwzzmttEg4kKUANVsf27t1raGhY 3yaFHzNmjLGx8ZYtWxT8/YJz49r3mn+wdNjy7d4d0clAmzdv1tXVnThxYqOKcwAMXiQpQJyrMs5b tWqFJIUaDJTv/Pnz9+/fHzVqVC0sPVEtbDZ78uTJDx8+VPAmuJq+45zfzj1+eNzH3QST+iDOz5+/ f//+2LFj622cnzhxAt0E0IQGL5IUVBAZGVlv43z06NFIUqjBQMkEAsH+/ft79uzZsWN9vArXtm3b nj17Hjx4UCAQVPuXdbr/+MuCAW00GXQz4lwg2L9/f48ePeptnPfp0+fw4cOKxDkABm8DHbxIUlAh znfs2OHo6Fif41zBkzFADQbvdOLECaFQ+Nlnn9XbPZTt28mTJ9FZUMM4//TTT+vtHg4fPhxxDoDB C03T5cuXi4uL69srIZXinMPhHDlyBJ2FGgyUQCAQnDlzplevXvXtxndFWlpaPXr0OH36NK6+gGKE QuGZM2dcXFz09PTqc5z37dsXcQ6AwQtNMM6PHz/eq1ev+h/nFy9eRJyjBgMliIiIEAgEgwYNquf7 2a9fv7KysvDwcHQZKCAsLEwgEAwbNqye72fv3r0lEgniHACDF5qU8PDwvLy8+h/n/fr1k0gkly5d QpehBgMlpLdOnTrV5+suMsbGxl26dLl69Sq6DBpxnOvp6dna2iLOARro4L1w4QK6DBRw9erVBhHn WlpaiHPUYKAEubm5Dx8+7Nu3b4PYWxcXl4cPH6ampqLjQIE4rz9rCiHOARrr4H3y5AkGLygQ5/fv 3+/atWtDifOMjIzExER0HGowUFxYWJiWlpZyZ+ApvbfKycjIyMjIqOtPd0uUubcdO3bU1NS8d++e sjaYf3Zsaz2u6+p7pQiFRi0iIoKIapjeypJ/62H0bi2snT6Z/MPO8PRSJcW5lpZWbGwsOg5AKYO3 NpOUlpbWrVu3kKSgWqKiooiohtcaajlJyfYZUIOBgmJjY83NzdlstvI2WXLvn30psv/7ZN+O20VK 3Fs2m92hQ4e7d+8qa4PSkixeQVZGvlCKUGjs6a19+/ZKjfM3T+myU6JPbPEe4ThiXXSBVAlxbm1t nZCQgI4DUMHgVW2Ssra2fvjwIZIUNPoklZycjI5rCthoAhVJTk4ePXq0MrdYdGd30DOi5u7OgrCo rJAtV5e7DjZU3ronlpaWJ0+eFAqFHA6ner/JsV4YL1345s/0R1yQILM1jTgfOXKksrZm/1PQ6h46 L8+QxGUlhS+ePrh+dNuWC7zSW6un+PW68bNrM0YZcS4QCLS1tdF9gMHb4JKUIoMXSappx/mAAQMa UJKytrY+evQoklRTgPtgKpGamioSiUxNTZW4zfybO49lERn2m/e9hxFR0elNZzPFSty+ra2tSCTi 8XjoPpATj8cTiUTm5uZK2h7byMa5xysubr37DBwx6etVBy7s9tAjovR/1oe9kConzp8/f47uAwxe 5Q3e2ktSGLxQrTgXCASWlpYNKElZW1sjzlGDgeL4fD4RtWnTRmlblOaE7ziVR6TrPrqH24QhxkSi 8M1H0oTK22d9ff3yPYcmLiYmZt++fR98/V0WLS1atFDpzrBM+88cqEdEpQk3ntb4iXsTExNZYkYv A5KUMgev6pMUBi9USlJJSUnyxLkschpKkpKNSkw/gxoMFPTs2TM9PT0lLs0s4V/afr6YqFmfCY66 zRymftaciO5u35+kvLeJ9fT0dHV1nz17hu6D3Nzc0NDQH374YcGCBSdOnMjNzX3nxx4/fqypqan6 CX/VtHQ1iIjUtdVr/FyTlpYW4hxA6YO3FpKUlpaWoaEhBi+UJ6lly5bJk6SMjY0bUJJis9mGhoa4 II4aDBSUl5enq6urvO2J089svyIkMhg6o4c+Q1ofTRrbmohS9u6KVeZ66rq6ullZWeg+kEpfPk7B 5/MPHDjw9ddfr1y5UrbmeMWPCQQC1ec2opJH56/wici0T38LDSVsz8jIKD8/H70MTZmyB28tJSk9 PT0MXqhWkqqNZcGUnaSMjY2zs7PRy6jBQMH0psSbYCR6cnznTSkRd+T0brpERJo24ye1J6LngVsi cpX3VrG2trZQKET3QcU8JxaLxWLxvXv3Nm7cOGfOnE2bNsXExJTHebVncKkGSVlRVkrUkTVTR/38 kEhv2AovB6UMKg6HgzgHJCllDt7aSlIYvPDOJCUSiRISEhpTkiorK0PnNnqYF1ElioqKlDjsyx4F /3WXiMxHT+36cpYc9Xajp3202ve/gpObLvD7jTJVTi2tra1dVFRERDt27MjLy0M/Nllv3w6VXXQU i8WRkZHh4eH6+vq9e/d+/vy5Mq81kOjiOEujd/0Dq8PEP/b+PKolW7lxDtCUk5QSBy+SFNRtkmIY RiKRvJ2kXrx40RCTlJaWVqUbetAo4T6YSij1uktJ4oG/k4io7fiJnTTL/0KbEf9zZojKLm86/lSk 7P3HhUaomkQikS1jUDuhIk48vXv70cQizCQNoBzq6urKG7xIUlCPyK4YlpaW1maQKDdJiUQi9GNT gPtg9T69Fcf/fSCNiDpOGWNd4TljVsshs3ovjLoivLP14MPJ3h3VlfCnBAJBy5YtieiLL75AJzZl ly9f3rZtW8WfMAwjlUpZLFa3bt2cnZ3d3NyIaOfOnTk5OUr8u/ZLDvh313mVSMWi0sKsJw9unvpn 17mUWzvn9UnIvRI817rGT9sLhUKsuwJNHIfDUdp5Xi0mqfLBiySFJNW4k5RsqmpADQbVpq2traz7 yIXRfwVnEBE9WN69+fJ3fSJ59+7/vlrtqIS77cXFxTg3hUpkic3S0nLYsGH29vYVI4TD4Sj1eQm2 kZ1Lz56V3p8eOmrq3KkbR/ZZFlUa8dPCY58FeTZn1TjOZdcaAJpyDdZAkxQGL7wzSVlYWAwfPhxJ ChoQPIuoqhqsoKBACRuS5l3fefxD13DSD269qZSJooqLi1X59io0GOVTTnG53M8+++z3339fuXKl m5tbpRLdxMSkuLhY9QlWy3bGsjFGRFQWcSCq5qGen5+Paw3QxClt8NZuksrLy8PghXcmqVWrVr0z SdXGRJrKTlKI8yYC98FUwsLCoqCgoLi4uIYvg0pzrmw/U0BEXVdGHpnSqnJvSQsjvVzHBOXmHt90 eWXvESY1qqiLi4tzcnLat2+P7gMNDY1Bgwa5u7tbWlpW8TEul1tQUJCfn6/yyX81zO3MiHJImJVe KCbDGlxjFIlEOTk5ylw/HaABUtbgrc0kJRKJXrx4gcEL1UpSJSUlDS5JIc6bCNwHU1V6I6L09PSa bUby/Pz2SyVEZD95uJW+zluaNXf730gTIiq5sOlkurhmf0y2t7I9hybOzc1t6tSpVec2IpJ9oDbW lCtLT8gkImIZmerU7KCVlpZGRObm5uhlaMqUNHhrNUlh8EJ1k5S1tTURPXnypAElKZyMoQaDGjE3 N9fW1q7psBfxTu0IFxGR45SB75nwVLvrlNEtiEhyc0tQSs0mAUlNTUV6g2oxMDBQQpx/WEnyPysO ZRMRdfVw0GNqtC0ej4c4B1DO4K3dJIXBC9Wlo6Ojra2dkpLSgJKUbFS2bdsW3dfo4VlEleBwOJ06 dbp//767u7vCGxGmHdsZTUTkNPmTFu+7r63ZacLYNlvWp9H9nXvvzfHrqqnwn4uNjbWxscH7YFDL cV7xhC4n/vo1HZ3y/5ZKhAJ+8o3Q3ZuO3CsjouZTl41qVcNjFuIcAEkKmlScP378WEnbq40kFRcX hzhHDQY10r59++Dg4BpsoOxh4O54IiLnyQPM3v9osWaHsROs1q95SE/3b49auLFXM0X/Xmpq6rhx 49BxoECc1/zVR5kY/3Ee7/s3bbel+/176TM1/BOpqakjRoxAxwHUePDWQZIaPHgwOg4afZJS0mVN qO/wLKKqODs7i0SiqKgoBX+/5P6+fx8SEdN9SlXZjUi93agpnYiIso9suZKj4PqA8fHxIpGoa9eu 6DioFjc3N5FIFB8fr6o/oG7YpkvfCQu3Xog9ssC+WQ2TW3x8fHFxMeIcQAmDt9aTVHFxcbdu3dBx 0LiTVH5+vqurKzquKcB9MFUxNze3srK6ceOGs7OzIr+v2cXvbo6fPJ/kWH19Lefrmu3tpUuXbGxs 8Jw9VBeXy7WxsVE8zmUprP23N3K+rYW9vXHjhpWV1Qdf4wbA4K1vSer27dsYvNDok9Tdu3cR500H 7oOpkKura2JiYm2sTVEz+fn5SUlJskXlAarL2dm5ocR5bGwsri8CNMTBGxUVhcELinFzc2socX79 +nXEOWowUIJPPvlEXV39zJkz9Xw/z5w5o66ujhoMGnecX7hwQV1dvU+fPugyAAxeaDrc3d11dHQQ 54AarAnhcDgeHh7h4eHFxcX1difz8/Nv3LgxaNAgLMoONYzz+nyVMT8//9q1a4hzAAxeaIJxPnjw 4Hoe58XFxYhz1GCgTJ988gmHwwkMDKy3exgaGkpEw4YNQ2eBwoYOHcrhcI4cOVJv91B2BRRxDoDB C00zznV0dOpznONkDDUYKJm2tvaUKVOio6MfPHhQD3cvJSXl2rVr48ePx3UXqAkOhyOLcxXOPVWz OL98+fKoUaMQ5wAYvNA043zcuHGIc0AN1rS4ubm1b98+KChIJBLVqx0TiUR///13u3btBgwYUOmf hELhrVu3YmNj0X0gf5zb2toGBQXVtydvRSLR/v3727VrN3ToUHQTAAYvNG4xMTHXrl1DnANqMCAO h/O///0vNzd337599WrH9u3bV1BQ8MUXX1T8IY/H27t371dfffXbb78lJyej+0D+OJ88eXJhYWF9 e/I2JCQkMzNz5syZ6CMADF5o9Hg83p9//vnFF1/s2bMnMTERcQ71FtYHqw3m5uaTJ0/eunWrhYVF PVn+PDIy8saNG3PmzJGtCcbj8aKioi5cuJCVlcViscRiMYvFQsdBQ4/z6Ojoy5cvz5kzB8utAGDw QhPBMExeXt65c+fOnDnD5XJ79OjxySefcLlcc3PzOXPm/Pbbb4hzQA3WhLi7uyclJR0+fNjExMTO zq5udyY2Nvaff/4ZNGiQm5tbWFhYREREXFwcwzBSqZRhGLFYLDuEoddAgTjn8Xj1JM4fPHiwa9eu 3r1715NcC4DBW63B269fPwxeUICamppYLJZIJESUnZ196tSpkydPtm/fvk+fPt27dx8+fPjhw4f1 9fXt7e2RpAA1WJMwderUFy9ebNu2bfbs2XWY4R48ePD333936NDhxYsXM2bMkB2kiEgqlZb/r+z/ JCYmnjhxAh0H1dKsWbOWLVtu2bJl7ty5dRjnT5482b59e48ePSo9bQsA7+Pp6cnn8+s8ST158mTz 5s1t2rRp0aIFchBUV0JCQvmZDBHJTnIYhklKSkpMTNy5c2eXLl0sLS3/+uuvOo/z7du3Ozg4IEk1 WUzFSK3a1atXCwsLhwwZglZTmFAoXLdu3f379+tq5MfGxv7999+GhoZ6enr379+XHZjeGQMsFoth GA6Hg15rNOQf7G8cIxS6IyoSiaRSad3GeZs2bX744QfEcGMVExOTmJg4ZswYNEXjS1ISiURNDe+r I/somH3Kb4K9vRuybbZr146I0tLSpk+fXid3w8qTlLe3N+ZCbBySkpLCw8OnT58u/6/gPlit4nA4 3t7emzZt2rZt24gRI/r371+bf/3ixYvBwcE9evSYP38+EfH5/IiIiCtXrqSnp8veAat07Bs5cuSo UaPQa6DYmdyOHTu2bds2ZMiQwYMH1+afvnr16oEDB8rjHACqm6QweKHhOnHixIEDByr9UHaSY2pq Knvwj8vlCoXCPXv2/PXXX3UY5/PmzcNVwqYMNVgdZLh58+YdOXLk8OHDKSkpEydO1NLSUvUfLS4u 3rlzZ0JCwqBBg6ZOnSr7IZfLHTly5MiRI3k83vHjx+/cuVNQUCB7ihovg0HN43zmzJkmJiYhISGy ONfT01P1HxWJRNu3b//vv/8qxjkAYPBCk1J+2032pA+LxXJ3dx8wYEDFeS84HM7UqVP19fVDQkIS ExOnTZtWO3G+e/fuO3fuIM6BiFg//fSTnB9NS0srKyuztrZGq9W00VksOzs7Kysr2XwYXC7X1NRU dX8uPj5+8+bN2dnZ33777Tsv9ujp6Tk7Ow8ePLhDhw5lZWXZ2dkSiUQikdja2tra2qK/oIZxfvXq 1Rs3bhgYGJiZmanuzz148GDDhg18Pv99cQ6NTEZGRnZ2dp3PHoHBi8EL9UpSUlJcXJwsjLt37/7p p5/Onz/f0dHRwMDgfXEeERFx7do1IyOjWojzzMxMxHmjlJOTk5aW5uDggBqsATAzM3N2dk5KSgoN DU1PT7ewsFD6M8EZGRn//vtvaGiotbW1t7e3lZVV1UnXzMzMxcVl2LBhhoaGxcXFpqamqMFAKXGe mpqqujjPzs7ev3//kSNHLCwsFi9eXHWcA2owwOCFxl2DZWZmTp8+fdasWb169WrdurU8cZ6WlhYa GvrkyZO2bduqLs5btGjx448/Is5Rg8lgTo66FxERceDAgdzcXCcnp4EDByrlMkxGRsaJEydu375t YmIyefLkbt26KbARoVCIJ5WhocT5uHHj3Nzc0M5NB+bkwOAFUFGc9+3b94PFG+IcKhX/1Z2TAzVY vSAUCsPCwo4dO5abm2tpaeni4mJvb6/Ae2IikejWrVvXr19PTk42MzMbOXKkm5sb6ij4IEGMn6vD ssy5kY82u2g3kDiPjo5OSEgwMTEZNWoU4hw1GDSgJIXBC/U/zlu1atWrVy/EOaAGayqDPyYmJjIy 8vr162w229LS0tLS0tbWVl9fv4rrjvn5+enp6QkJCfHx8c+ePWOz2V27dnVxcenZsyeaFOQhLbz6 9hbwAAAgAElEQVTh4+SyNpGaq7gGU0qcp6SkJCcnI84BNViDS1IYvIA4B9RgqMHqNT6fHxsbm5yc HBsbm5eXR0RsNtvIyEhLS0tbW5vD4QiFQqFQmJ+fn5OTIxKJiEhPT8/W1tbJycnOzu7tF08B3l+B 5V7+xr7vxmdEwtqpwWoY59bW1i4uLohzQA3W4JKUtbW1k5OTvb09Bi80CLm5uVFRUQrEeefOnbt3 7444Rw2GGqzBp7rnz58/fvw4KytLKBQWFRXJXtNSV1fX19fX09MzNzfncrnm5uZoK6g+SfbpWZ2H HOv9+5f35y/PrN0aDHEOqMGQpBRQO89OAyBJgUprMKwPVt9xuVwul4u5v0AVxJnHvp60Szrj1B8e KUPmI84BoL4PXmnhDb+xy+4SNUfTA5IUNGRqaAKAJkrEOzh76n7teft+HWTCQnMAQL0nzQ3zGbs2 EXMbAABqMABokISpu6fNOmby7f7VfQwYNAcA1HuS7DPfTdhYNOb3H7qgMQAANRgANDhliZsnf3W+ 9eL9fm56qMAAoP579ez03394NMedewBo6PA+GEDTI8kImucdXtpqeP7Bn7wPEZEkLzqFqODK7z7e pxxn/jC1owYaCQDqkVfPTl/8dZBJ/ha0BwCgBgOABleDCZ4/LyN6GropILTiz+8d+OMee1AfL9Rg AFCfvHp2Onx1HwNGko8GAYAGD88iAjQ97HYL7korEj3e5EDUfG5kkVR4epg+WggA6g88Ow0AjfBc DE0AAG/LPzvWbvTFVj5hl31scVMMAOoMnp0GANRgANBESEuyeAVZ7HyhFG0BAHVZg+HZaQBADQYA jRGrzRe3pV9U/In+iAsSlF8AUPfnKe0W3JUuqPADcdrmbhbzns2NfLTZRRvtAwANE94HAwAAgIYt /+zY1npc19X3StEWANAQ4D4YAAAANGx4fBoAUIMBAAAAqMTbz04THp8GgIYGzyICAAAAAACgBgMA AAAAAEANBgAAAAAAAKjBAAAAAAAAUIMBAAAAAAAAajAAAAAAAADUYAAAAAAAAKjBAAAAAAAAADUY AAAAAAAAajAAAAAAAABADQYAAAAAAIAaDAAAAAAAADUYAAAAAAAAoAYDAAAAAABADQYAAAAAAACo wQAAAAAAAFCDAQAAAAAANG1s+T8qFArLysrS09PRagAAULcKCgrEYjFSEgAA1Lm8vDwV1mA5OTkF BQWnT59GQwMAQH2AlAQAAA1RNWowY2NjDQ2NPn36oNUAAKBu3bt3LyUlZdiwYWgKAACoW6mpqVFR UaqqwdhsNpvN1tXVRUMDAEDd0tDQUFNTQ0oCAIA6p6mpWd1fwZwcAAAAAAAAtQc1GAAAAAAAAGow AAAAAAAA1GAAAAAAAACAGgwAAAAAAAA1GAAAAAAAAKAGAwAAAAAAQA0GAAAAAACAGgwAAAAAAABQ gwEAAAAAAKAGAwAAAAAAANRgAAAAAAAAqMEAAAAAAABQgwEAAAAAAABqMAAAAAAAANRgAAAAAAAA 0BhqsLIHqzsx76bFbe/y2YJNl3mlDb8DmsjXlJcgYrYp80Ftvr9dUs0N55/20GQYRmPYqXyl73Tp 07N//HE9v7baSPT0Hw89Rmfov8/EioaQIlFXza4pjvHtyDDtv7uWL61WW8b/ZM0w6gMD+fL9mpAf fWDl7OHdrUw0ZTugYWzVfficVQeis0T1pL+UIS90ILuKVtcytnQYOG35obh8CXIaQH0myTo5hcsw DMPoDNn79L1HKZLmXf6iFcMwDGM65USW3AM778RgDsMw2p+dLVDWHkuzDvRiGIYxnna1CP0H0DRq sCqUZD28ceT3L/u27+t/o3pnePiaoOSC6MnB6V0sBs0/lFpWO10kerx7+uzQAvtlv3m2ZKkghJQV dVpdv9sw1eRhwHifK3nyb0bEO38kmchprKsR88FzmbzoP8fbmjmP991+4taj7Jc1Y1nOo1sntv04 3tm0o+dvkTniuu6v2jlU5DyOObfnp7Fd7GcfyxBjVALU33Muk8G/7BhnSESC019/E/Ke8SotiPhp 2hYeEXGn7A4YYoInlgAaI3b930XntafX92z28sAkLisuyH5yLzxww++nn5RELh3l0ydhY29dpuH3 RBP5mnLSH7EleOFHmu9JYtqtO2pUc4Oc5j0/GyrO1+tlxlHqjpY9uXAisfZuPojTg+d7nS82m7N+ bgd1JYSQAr8ib9cwhv2Wr+r97+xNM1dPj1njrCPP15M8vxp4l+ij0e7NP1BfSrIveLt/EhAvJSJq 3X/OnPFDXO1aG3GK0+/fOHNgy6bQJOGjIC+32wlHwjeNbMGuq/5SNmvfyMvfWFUMYalQkJ0Wd/nA L76/h+VQys5J84YmB31uilM2gPpahZkO/23b56c8D+flh8z1OtnnHw9u5fFaFLVy+vrHRGQ6dc+v g1GBATRWUrlduXLl5MmT0tpSen+VDRERe1Bo7tv/KkoP/FyfiEhzaEiWRNpwNZGvKa+ia7O4RETN 50YWNagd7rmfXwv9k39lbgsiNdctqcIahZAiUadI1xRe+7IlkVqPDQ+F8nxcknV4sAZRux9jS6r+ YFnK9k+0iYhIp+ePZ5+VVf534fPL/n10ZcW3a8D9krrqL6XJPf4Ji4io05oHZe9pkoeb+8iqX8eN KUJpk3Dnzp2DBw9KARocEW+fh+wI1XzGmWzxm/8oiFlmR0REptNOZomreagIHcQmIq1Pz+Qra18l /P09iYiMpl4pRM8BvFdiYuKuXbuq9SsN9foKy2zwV8P0iajkv2tpjfd9qSbyNUEuotR/F29PJ62h 349qw1ZhCCkv6nS6ff2NHUlu+K8Ol+e5xoI7hyJLyWzQ8PZV3uaU8EO9vM4JiNQcV4Sf8f+kxVu3 Ntlc9x9DLy3tTETCyB++CeQ1/ufzOO0mLhllQET038l4vLUBUL9Te0vPPzcM1iaizF0zl4ZXfF67 JH79tOXxRNR8+p5fBhnjHhhA49Vwx7ealp4mEZG6jvobD0tJ8uMPr5k91MnSgCN7X51tYNnt02+3 hmcKX9/8e+87prIpARimc8BDYaUbhiWPzwbMHdK1hQ7DMAyjbdZ54My1oclFFU8t8471V2MYxu3f Z5nnl3zSRoNhWPrt3L8JeSZS+teUa3+q3iVJ7p1/fCe423DVGYZhGHXj9m5jFu6MfC58+6Q3L+7Q 8sl9bLiaDMMwLN3Wjh5fbbj09I3T85evAvf465kw58a2+cO6mGkzDMPomDt9+t3Om9mqPAmWpyne NydHDbr138OzzBidntv5RETXxnPVGEZr5Jn8asThy10oTjm5ZtrH7Q1ZDMOwDNq7z/j1Unp+9Pdt GIbhzrxWHqGl97avixCT3vAv+5kwygghpf7KeyoDqzFzHIie/7P29PMPPgEouBd8KY/0+3xuq11l KZp2aFVIARG1nr/lW3ud9+wgo+O0cNs3rYio5OzqvUllRILrX7zVX0M3LvmIYRim5dc3iyt2CT/w E3XZEeJKxSOENPvIUE2GYVotuFUs9wFHlLqpO8MwDKffvxlvtUFp3BIrhmGYLr8kCWs4DNRNrYyJ iMpy80qlihwr5P+k/IcOAHgnduuJW37vr0lET/6cvuJm4csflyVu/t+SGCIym7Fn3cDXFZj8CeXV WBa/iN61YHhXMy2GYRh1085Dv9l+860XZKu9WcVPDEozwjZ8MaCDMYdhGJZRp8Fe/94rlBJR2dMz a6b0tNBTYxhGy9x5jN/JJ2UID2gqGuiziNLi2KUdiIjMvoio8GRUceK2T03f802NPvv3ifBD99ZL /lvWnojoo1+TKz7zU/Y05Aub1yd7Fd5VsZq2L6W0/DGAo/0YInJa9qPr6/sURlMu5Sv5a8q7P1Xs Ui7/1Nx2r8+5Oa83oTfwzwcVHt6S5N/+bdg725TV+Zvjz4SVHoFw9Pt1TIu3P2s591y2PM9UVP+B NzmbIu/UcA0iUh96Mk9Z3XoqfEW/jpZmL1/LMrJo16599/nXCqsRh1KpVJx9ebHj26+o6X08fYgJ EZn8L/xVhBZdn9eCiDSGVH4qVYEQUiTqFHxMtOzBmk5ExLjtfCqq+pMlsT+0fdf3q/wQz9OdLkRE 1M737gceWSy959+RiIg++iWpTFoc+47+uhi5xIqIqKP/vQrDJv/CeP2XgbCk4h/JOzdOn4hM/ne1 sBoHHBFv98csIlLrtatyGxRHf9eaiKjbplRhzZ5FlEqyDg/TJCLSHXO+QKFjhZyfFMt76MCziABV Hx0f/vmx7IDU2T+uWCqVClO39dUgIjL7X8UnFOVPKK8SMavrpCFmb3/YYtbJ59Xe7DvPl6p5YtD1 h5+GGFb+pPbA7fdifh+gW/nnZlNDn4sRHdAUnkVscDWYuLTgeXLkwWVDzYiI9D+tePgpS/zViSEi Mvv8t0spBSKpVCoVvnhwes0I2aGi1YJbAkVqsKLopR8REVH78b+df5gvkkqlovzkcwFj2xIRUcfF NwvfOFknIqLWA79YunLZN57Dv7+ar9yvKf/+vH+XMiK/bEFE1Gri9luZpVKpVCopSj3r31+XiEhr aGDmyyOgKOPwWCPZIbm/7+G47DKpVCJIu7pp2stzta5+MYI3DrVERGodJ/16Iu5ZXmH2o/Bd8+xl FYbdqoRS5ddgcjfFO2owpXTru94vkjsOpaKM4NEGsoJi4p/hvGKJVJyfeGL5QKNXf+51DVYc/X0b IqIeO5+KaxxCCkWdgq/qCa5/2YKIWH3+zagyrZYlrfuIiOm1+1nV2bfg0gR9IiK9sRcKPhgekXOb ExFxBh998ea3KO8vwc355kRE3bellddHxVFerV/1QLetr39eFDG3ORHpjT2bV62OFj8PGqJJRNR9 85ulVlHkvBZExPp4N6/qAvWDNZgkL9Knk+y8xiO4wvmL/McKeT9ZJOehAzUYwIfPcxLXy67scXpv TinJCPpMj4ioxcyzFSow+RPKm4mY2o1eGXLnaX5xYfqdg991lz3g3b780lVNzpcUOjFQd5iz+eKD 5/l5vJs7p1jIHlcwUCcyHbo8JIaXV8C/f3LlQFk+7PprUhmCA1CD1YMa7L1YnabvvldU4ZJ58Z2F FkRELb6oVPVIso+N1CEictj0WFTtGkyUtuNjNhEZjQvJePNEScT7d5gOEXH67JGdQpWfrJtMDuWL VfQ1q7E/792l0oQVHYmIuu3kVdxN8bO9fdSJ9Lt+d6Po5Ym/twUREdvtt4Q3LnCLs07PbElEpN5v 78vv/upQazLpeMVrWKLHW10YIiLnbU9Ectdg72ex8E6xAk3xVg2mpG59Rw0mfxyWxC21JiLSHfHv GzdIiv9b66z2Zg0mSv3TgYiotVdUcY1DSJFfqWbXVPjWWUH9WESkP+FiVTWT6Mn2HkRk//ujqieU kGTsld0Gs14e/8GiXvR4k+PrG2Hv7q/CK9NNiEh90OFX99/KktbZEZF2Gx0i0hx2LOfVwSFmsSUR aXkcy5FU84CTc3K0HhGRw+8VZycpCJthQkQagw59qHB5VYNZfHM0KraimOjrl0P/CVgw1OLl9Q/H VXHFChwr5P6kvIcO1GAA8ii597PsaG8w1NvTjIio5axzOWJFTmzeSMRG449kit44b+jFIiJy3Cz7 cE3OlxQ5MeBOPf26rpTkhH72cj5eh7X3Xm9CzPvLlYiIPSAkB6EBTaAGa8Dve4oTjm/dGJRQWP6q grrVrAOng3bv/sunx5s3t5lm7RxaEhEVZRdV+70kMe/k1isiolZTvx9UacJsVsvh84fpEgnD9157 UfGNiRbjvuqnrOlkK39NRfbnrV1S09TTIiK6+9c/0Xmv31FRazHhTIFYmhvzS3dtIqKShP0HHxMR d9qamTZvTJOgZjxgmV9PNaKyS1vPvfGmT6tJ8/tXnGmX1dxtoBURUU7aC5GSI0CxplB1t8odh6UP DvyTRESW85Z/bl5xHzTt5qwaZ/DG7xanRKQQEbVyaKVR45Gikl95H0bH0r4lEeXFxWRWsSBpTuTB 20TWn/Y3r3q6EXFxruxVLC0DrQ/2hZqWgWwS/ZL8kve9jqbTZWwfXaKym4fjZK9+SbIjj94jMh31 3cRWRCW3Qu8LiIhI+PjMsVQijtvEHgZM9Q44jGGvr0aZENGdbUGPyt+zyIvccjiLqNnQr/pz5Txa PP5jpHPXiuydXPoMn+S1/uRjItLp/n3oCe/X6wbIH+Tyf1LOQwcAyEWj09d/+XclotyT6wIziFrO 3ru2v6GaAgnlDW2mfz/ItMJQZpn1Ht6BiIifnCWs4fmSIicG5hO++tio/Fsxup3cZQ80uy2YXGGl GTUDG3szIhLlZBZioUNoAhrA+mBOq0J/dWv26lRNLCwp4D++F3Fs5+aTDyM3TXX678Wds/NtNIhI Tbe9y6D2LuVndWV56SlJCfGxt69fObkviYhIXCau9kmlIPHcPSKip7+5GW+pvGiRVFRcQkSih7d5 ZZ4mr44kTIePrd5YP0ny4u7pc/F5bx5T2Nzuw/pbsav7NRXYn7d3iW0+bFZPry+vlYYv6m70m+NQ D4/hw4cN6e/URke9wqpTkrz4iDQi0ug+snOzt+6UNP94hA1duye9H5ZcPLVF+fJP7dzaar35PXWb 6xIRiUpE0g+1Rvnpm97wjYe+f9ciVGo6ltYaineNUrv1fSf+csah5EXsxUdEpO86qH3l7eo5jLRX 23e5PIdJBbyUXCJq1qqFNlPjkVKjX5Gra97oWuO2xkRPKPPB8zKyes8RJz/64HUhmQ8Z2k79A62r riP7hKhU9MHBLCktkL0frqGr+d4qR895Qi+NoFMvwkITS/o4alLBnZA7UtLq4enhkbt429PnYRcf l7l2UhdnXA66R8R0m9jLmKlWRxMR6XabM77lXxuexe88mLRgia06kfRF+JbjuUSGn375sREj57h4 z13Ltn3Hjf5s/PSpQzrpqSkU5BryDwe5Dh0AIC/Nj77ds2yf/fJ4Imo5Z++afoaMIgnlzeOklZvl mwdpVjOuLhGRUFAmUXizip8YtHV9Y3/UNHU1iIi4du311d74uWw6KIlIIkVkAGqwerCHJl16ubvr v/nDkeNnz5/9S3/HhddLriz8OmjM6YktWC/PVR+d3vLLpgNnI2MfZitjch2pIOPZy5nRyoqL3/ep krziCqdOzcyMNd44iJY+2j1n7G9PK/2S/cbUW1+2qObXVFNgf96xS5x2swOPPfac8PO1XEnG7dDt t0O3LydqZt139OTZ33zl6WDIIiJx7tMXRETGbU3fcW7NMbbiEhHl8fIq3N7Q1NetPMMEi61GRCSV Sj/YGhav/kurlVNvdxdtpXeNUru1yn37cByKsh/yiYiMLI3empSD0TKzMCDKefXfYsELARGRloEW SzkjRdFfkatr3ux/bUMtIiJBjuC9VzaL4oLCCsnws886aX2wwm1j2YxuFdLz+5llZF31ittl6fcy iIg45tbG7/0kY+g6oYfaqStPTl94strRWphwLKKIqMdIR3P7EV3o+I0HJ29m+3Rqnn3t4B0ish/f t+KNIrkPONr2M6e13bAqJXH3vgcLV3TWkGZd3HSykKj5mLkuenKPi05rHsQu6sAhIqmo8Nnt41uW f7fiZLo4JTG/eY+eHfXUFAzy6gwHDXkOHQAgP62OI4e0WR6fRnofj+1hyCiWUN6grqtT+YjHyLYr ldZgs7JspMCJgYaB/jvn2FXXrvRjhkE4QBPSYJ9FZLQ7f7FmkjERlYXtvZEnO6nlBc/sbDX0u82h tx5ml6kZtrX/eMSUBf5bQq6c+cFazu1KKl19kUrEsotG/Q5X8Xxy+qaKJ6VqLDWVfU1F9uedu8Ru MWTt1XTejUO/LPDsaSW7mlWYdGn30vGO1p/vfFT21uH67bQgke0Jh1XhqMmw1GrrGKpgU6i+W+WM w1f7IBFLP3jFj2FkzSqt/sXBd40U5f9K1R0lJSJi1N6bXksSj57LIq3eY7rqfHBr2jaDPiIiygq/ lPaBswYh7+pFHhGRdf9Ozao4CHI/Hu9IRPeORPAlZannLmYSdRjqylU3dRvWgYhij8YWSPNvHbwu IrIdO/D1w5LVOuBodJoy25aIHv29N76EJJnnNp0rIWo9cZajjkJHBnYz8+7j/Y9GBU9uQcQ7/n3v IaujCqSKBXn1hoNchw4AUA5FTmyYD+fhGpwvVf/EQI2thuIKoPHUYESk2bprSyIi4XNegZhI/OzQ zMm7HhGxu3659yZPIMp5dCfs6J7ffOd82r259OUVGekbF1skosr32iXFsvsNrxtIx5SrQUSS1NtP FV6uVssp4Mk73ij/0oJd7a+plP0pP05rtuzu+d1vh8KT80sy/zu3e/kkB20iyj624PuzOVJiGbQ2 IiLKSeW/40+V8ZP4REQG5gbs2msNJXWNUpux0kVCeeOQbWTxsnmz31qKRVrCf1qx9lHTNtQmIirO LRbXeKSo6Ffe2yAv3+DSMdJ+z+Gm7PHp0DRi9RjbTf/DeZpl9sl0V4aIErdtuV3lYsQl8X9tiiMi 6jhuuGVVN8xYLfqPsSOS3gm+nfM88kQikWmfAZbqpG45oG9zoqLrJx5kxQZeERBZfT7UglPdjn6J YzVunjMRpR38N74o89y2MCFR++nTP9Kqybhgt/xs8/ElHxFR2XXfEfNPZUkUCfLqD4cPHDoAoJYT Sq1tVkUnBgCowRqUUt5/6URELGOzZmokzY3Yea6YiDos2x8wuVtLrddnc9LCh3eeyS7QyI4pDFtT XU12Rvvmm/qS3Pt30itVDNbu7YmIHgUfT6l8hVfM2zOQa9iqUx+vS7nS2vmaStkfSe7t/b8umT93 2ZlXb80yGqZ2A6Yu3Xvp2BRjIiq8E55WSmr6tm5tiKjk5tH/Ct86hGdeDX1ARNS+8nPntaYmTaGy bpU/DlnGDh+3JqKCm+cflVTaStG9U3crlj6MdusOxkRU9ORpoaSmIaSiX3kfIT+ZT0RkZmv27jeG xBmXDt8nsh/TU66JbNitR/uONySip3/MXH2z4H09VBz3++y1D4lIY8APMzpW/a4Sp83gz9oRFUeG XI88Fkek1d2jkzYRaXca4aJNlH7x5NmD53OIWnmMbK9R7Y5+veOffvkxi+hJ8IGrp3aFi4k+mjWx o0YNRwGj4/TDgTVODBGl/zXpy6OZYgWCXO5PynnoAAClqP5xRuWbre8nBgCowVSv5MGuH//OIiJy GuWsz5BUWCSbxEfHSJtV6WRss9/pUiIi0at3TNVN2hkTUWnMqfiKV9IFd7f9fK3y6ZnFiGldiIgS 1iwKfFpxYjdpfsTPS85l5fIeFFtZNmNq52sqZX8YcereH1f8sXXFT0GP35iqjmEY2aWvZqa6bCJN 2/FjLYjo+W6fvxLfOLGS5FxauTxSSqTmOrUvt46iqCZNobRuZcnWqBWWCGWhVY041LSbPLEtEaVu WXEio2LFJXx80O9f/hu/rGnp2o6IKO1Wtc9w3wohlfzK+5N94cPYDCIy7NKF+87ropKsawfvENl8 3reFfK8SMUYD1/w+XJeI4lf2GbjkQuZbtxHFOZFrPXovviUmYrus2jC2wqyTlftLRqP9iOEtibJO rv/jqoCoy6cOsne09Ow/tSeiexv99/GIuINHv35frVoHnJd/u8XQrz7RJHr8z4qfw8VEznPHtOMo YSBo2i3Yu9qRIaIXh2Z9d5IvqXaQy/1JeQ8dAKCUGqz6xxmVb7aenxgANKQRXu/XB3NaFXq5gksX z4bu3+gzpvPLaywtZl988XK1nsWWRETE9dz5X75sIYrSjFv/fNerfObV5nMiZIvXSF6cHC37qfmo X88mZhUVZSVe2va1a/lLIxXXaJa8uPjFyyVb23j+djG1SCyVivITj/l+LPt4m6/C8iQVF+PSn3Cp QGVfszr7895dkuSen84lImI6zdp1I71EIpVKJcW8axvHtiIiYrr//vLri9KDPGWr25sMXn78fp5I KpWUpF/fObuz7Dyr46IbBZKKy5JofXomv/LCT1udiIhafxddLPf6YHIuBCx/U7y9RrNyurUkbml7 IiKtj1eEXr916162qDpxKEoP/FyfiIixmbH9enqJRCoRpF1eP6bNq09yZ4YXvfpDS6yIiBz+TBXV OIQU+BWF12h++XucTwL5knd+IOf4CG2iNvKER4V1aHLCfBxenuuzrIZ+s+6f0+HRd+NuXzt7YP33 n9m+ugDb9n8hz4RV91f5Wl3TjF+1eoWlx8oqrKSmP/58xdiuTke/XhbnxOhX/6rWa9dTkZxf94Nr NEuL767oKtuu6dSTWeJqB7m8n5T70IH1wQDkVXz7+zZERHrj3lpFsZrHmfcmYvGzXd0rHMCrsdl3 rdFc0xMDMW9nNyIi8/kV1peWSqXFskUYyX5jqhBhAY1/fbAGvEYzEZHOx6uj8l+d2Ykyj00zL7+w bWzW3ODlA0hmw/3WTzAlInb/8vPA0sQNfd+eq0Fv4OotnoaVajCpVCp4sGtcqwp3D19f3zEasiGu fC3bmtRgcn/NauxPFbsk5p+b3+mtuzmyY/Kn25NeL5ooyYv6ZaDhO++cWs84kFr6wUO/Kmsw+Zvi 7RpMSd2ae25ChZW8HP5MFVUrDsU5YYu7vn25kNu7X3MiohZfXheUZ2lvCyJi9z/4XFLTEFIk6hSs wUr+z96dB8ScP/4Df03NpEt3KYnSIRLpUpFIFq1jUdhcq8222JUdkmzjmGxJZG1Wog376xtJKnLn qChHMdgcpYSG1pQOmeg9zfz+mF3rYy1ppprq+fiLaXrPe16v1/Sa5/v9Om6G9CWEMNwTnr5/H+IX 5+dqEaLjm1P/iX8hhHU3f5s/8L+H8plM23ShUvDx+vr7Byf+Tkd6Cy7+8w75l7/7a+1S5UlHnv9P yX9SRf+t7tw8cdbr9lnSn03Nfa8fz2AiEZ+zxuqv1//61D97vDb/b0Uzn9nsPx3IYAASZ/xJHaYA ACAASURBVLBP/DvT3Az2CYd9TwaT+IsBMhggg3XcDNZNy3jIZ1+tSbjKe+djSv2Z/Yu/R38d8QAf ZYNBYxdsPFr8UiisTP1ckRCiOjntn+9EDWXHN/q6W2jRCSHyGqZuvpsynzS+yJr7ngwmEomE9ffS w30/s/5rfyY5NWPHqYG7r/zPlzwpZ7D/fJvNPZ8Pn5Kw/l7qT/NHD/xrCw+asl5/93lr/u/a8399 bxU8v5awauZwM00GIYQoahs7TF0ee+5Rw9tfL9srgzWzKN6bwaRSrYLKrPApA8Tf65VsfrzW8Knt UMi/n86ePbyvujwhhKZmOuqbbRefFkfbEEKIKevmm++0r/9Ya0EIUfRM+d/v9S1oQi1pdS3LYK9v h/YjhChPSHn2/sDBvxpgSIjq1OM1LfozIai+dShy8WQnc52/bn0paJk6Tvw2LOla5X904e+rL5FI JBJWpozrRgghihMOv704YM2JaaqEEMIYc+DZv27kfVJF/90Sv1AmhKh8cbhK2Oy32ZwMJhK9LPjx r2o1/PafG5jN/lvR/Gc2/08HMhiAZBns0/7ONDuDNf+w781gEn4xQAYDZDCRSCSiiUTNHUick5NT X18/fvx4DOAEkM5IYKHo/WsIv7oR3N9mQxlx+f1pzhz9vy4xNpXvdjfxzZYb/X8PT/nod4ix9q9v /NjfJuyBwaKLxb+6qKDCCXl50d90+M4/NWedLkvwUEN5SILD4RQVFU2fPh1FAQAA7au4uPjChQvz 589v/q9g0iRAeyUw3gF3Fbp6b7d119/ZF5dfmJRcRggxHT1E85+PqHwvr5++6Ukaz2xMKKE6xDus u7hl5wMi78Ja7ogARgghwmcnN+37k5Ces793QQADAADoupDBANoJTX3QGOOmusfZ63y+/y2PyxcS QkTU89sZ673Gh5cQwnBdPt/yf+Y7dXf+caOnMrkRGXGhVvY3YRI83L/2/yqJyQ9b5pp07aXyGh+f Sjp4OC1xy0LPWWkvCBnC/N5WGR8AAAAAZDAAaGsKlot3BtvIE9Hd3/xceqnI0+RpcgraVhNZx3mE 9PM/sN/v3ewi33N69KYRCs/iV8Tfl/FbYaLanJ9W5wh6fhP3o0NXvwkm4KYGeE+eMou5s+AVIQNW 7fzWnIHmDwAAgAwGAG2PpjE87NKDzF++m2jXR12eECEhRMVw8Hj/zcdLr8d80fM9d48Yff1+jxmn nM/64eCTJhl+aw03oxbt+tNkSWLEKA1aV6/nbkauw43ohNA0BnzBPn12nT1GZgIAAHTxL4FYkwMA ADocrMkBAAAyAmtyAAAAAAAAyDRkMAAAAAAAAGQwAAAAAAAAZDAAAAAAAABABgMAAAAAAEAGAwAA AAAAAGQwAAAAAAAAZDAAAAAAAABkMAAAAAAAAEAGAwAAAAAAQAYDAAAAAAAAZDAAAAAAAADZQG/+ U+vr6+vq6i5fvoxSAwCA9sXj8RobG9ElAQBAu6upqWnFDPbq1SuKoioqKlDQAADQvhoaGpqamtAl AXRoIpEIhQCtjUajtfZLvH79+lNf5RMymI6OjqKi4vjx41GXAADQvjgcTlFR0eTJk1EUAADQvoqL iy9cuPBJv4L5YAAAAAAAAG0HGQwAAAAAAAAZDAAAAAAAABkMAAAAAAAAkMEAAAAAAACQwQAAAAAA AAAZDAAAAAAAABkMAAAAAAAAGQwAAAAAAACQwQAAAAAAAJDBAAAAAAAAABkMAAAAAABANtBRBAAt Q1FUTU0Nl8t9+fIlRVEvX75kMBgqKioKCgo9e/bU09NjMBgoJQAAAABABgNoOR6PV1xcnJ+fz+Vy Hz9+/PaPFBUVX7169c9Hi05XV1c3Nze3tra2sLAwNDRE6QEAAAAAMhhAs1AUlZWVdfr06cePH9Pp dD09vX79+jk7O+vr6xsYGCgrK9Ppf32UGhoaKIp6+vRpXV0dl8t98ODBrl27CCH6+vouLi4eHh4a GhooTwAAAABkMAB4Py6Xe+TIkdzcXELIoEGDRo8ePXDgQCUlpf96vpKSkpKSkpqaGiHEwcGBECIQ CO7du3fp0qXjx48fPnzY2dl5/PjxxsbGKFsAAAAAZDAA+Aefz//999+zs7O1tLQ8PT2dnZ3FyeqT P2N0upWVlZWVlUAgyMvLO3XqVF5enp2dnY+Pj66uLsoZAAAAABkMAEhmZub+/fuFQuHMmTOdnZ3f DDWU6MNGp7u6ujo7O1+5cuX48ePLli0bPXq0j48Plu4AAAAAQAYD6Lpqamp27Nhx8+bNYcOGTZky 5QPDDlucxFxcXBwdHc+cOXPs2LEbN24EBwfjhhgAAABA14H9wQD+UVRUFBwcXF5evmTJEh8fH6kH sLeT2NixY4ODgxsbG5ctWyaebwYAAAAAyGAAXUheXt7atWuNjIxWrVrVr1+/NnhFfX39NWvW2NnZ 7dixIzk5GVUAAAAA0BVgLCIAIYRkZWXFxsYOHTp07ty5bfoJpNPnzp2rpaWVmppKUZSPjw/qAgAA AAAZDKBLBLCRI0d6e3u3ywlMmDBBWVk5JSWFwWC01zkAAAAAADIYQFvIz88X3wFr3/Dj7u5OUVRq aqqysvLnn3+OegEAAABABgPohHg83o4dO4YMGdLGQxDfa+zYsRRFJSUlGRsbW1lZoXYAAAAAOiWs yQFdF0VRmzdv1tTUnDVrloyc0rhx48zNzbdt28bj8VBBAAAAAJ0S7oNB15WcnPzs2bOlS5e23hr0 n/yBpNPnzp0bGRm5Z8+ewMBA1BEAALQARVFcLpfH4z169KixsZGiKD6fz2AwlJWVlZWV1dTU9PT0 TExMlJWVUVYAyGAAbaesrCwjI2PSpElGRkYydWJqamrTpk3btWsXh8OxsbFBTQEAQDNzF4fDuX// PofDefz4sfhBVVVVZWVlOp2urKzM5/MFAgFFUdXV1eKfamtr29jYmJqaOjo6Io8BIIMBtLq4uDhD Q8OxY8fK4LnZ2Nj079//t99+i4iIQKcIAAAfVlZWdvjw4Rs3bjQ0NOjp6fXt29fNza1Hjx4GBgbv HeghEAgqKysfP358//79O3funDlzJj4+fvDgwU5OTsOGDUN5AiCDAbQKDodTWlq6ZMkSmT3DL7/8 ks1mnzt3DmskAgDAf8nNzT1+/HhJSYment6oUaOcnJy0tbU//uWPTtfX19fX13dwcCCEVFVV3bhx o6Cg4Ndff01JSfHy8nJwcGAwGCheAGQwAGlKSUkxMzPr16+fzJ6htra2vb39iRMnRo0ahVthAADw juLi4r1795aWlvbp02fBggWSjF3X1tZ2d3d3d3evqKg4evTotm3b9PX1vby8XFxcUM4ArQTrIkJ7 E/GLDgRNGKgjT6PR6FqWYxZuz6tqas0XLCwsLCkp8fT0lPGC8fT0rKqqunLlitTKs/HuT5Y0mvna wtdodgAAHRVFUXFxcWvWrBEKhcuWLVuxYoW0Jg/r6+t//fXXLBarZ8+e27Zti4yMxCK9AK0E98Gg fQke7vGy8z3+uv+05RtHGTXdTdu6bbFL1uPLV8IdVVvpJS9duqSmpibLN8HEtLW1+/fvn52dPXLk SFkuTwAAaDNFRUXbtm2rr6+fOXOmq6tra7yEOInZ2dmlpKQEBwfPnz8fk8QAkMGgc+EXRP54vN4o 4OLlLS7daYQQf6++DubMrT/lrEwfr94KL0hRVF5enoeHR4conuHDh+/evZvL5RoaGspmeQIAQJvJ ysqKjY01NjZesmRJc+Z9ScLGxmbgwIGJiYmxsbEPHz708fFB+QNIEcYiQrvqZrn00MljB4Idu9P+ uiqg3lNLnggaXv01fE5YnR+3dKJtL1UajUajyWtaeHy3++YLUYtfkMPh8Pl8e3t7aZx9U92dI1uX fTl6iGkPLS0tLS0tPeNBbtMWh++7+qxRKsUzcOBAOp2en58vtfIkhIj49/7ve7feijQaTbXvqIW7 CmqEaIgAALJOHIeGDRsWGBjY2gHsrx6ETp87d66Xl1dGRkZkZCRFUagFAKl9vlAE0J7k1c2cPjMj hBBh44vKR7cyd6/5/lyTyeLgkZqEEPK6MGK046rr2m7fBEYN0hFWFKRu3/2rr0eDyf3fRqq16AVv 3rypp6cnhd5L+Pzixjlfbsyrf/tBQV35rXP7bp3bt2nzzF+TomaaKkrc/1lYWNy5c2fy5MnSKE9C CCElkdO+Vhs6lxlu8frq/9u64xun69Wc8yusFNEaAQBkVUxMTE5OTuuNP/wAV1dXLS2tnTt3RkZG BgYGYr1EAGQw6ERenJ3Vc8zBekKIgv2PqWw3TRohpD5v46bron5rz5xYM0gcERZ9od3fftOpw8UN I+2UWvI6HA6nf//+Ep+uoDxxgffGvFeE0Pp4LJg/ebh1Hx1ludfV5bdzM/buzChqLN2/aFI3g4ub 3TQkvNdsbGx87NgxPp//aasjvrc8/6LquftG6lfGCoSIlsxgOQ79ae2KjPlHvHRxVxwAQBYlJibm 5OTMnj3b2dm5XU7Ayspq0aJFu3btioyMXLVqFWoEQHL41gWyQcHiu6RTZ47uXTvFIP8nN9tvMp41 EaLq9lvZ00dZK6z/ukcjaqxvVFEipKGmoUXD5/h8flVVlbm5uaRn++rW9vBzrwhhOKzLyU3asGTW hFHDnYa6uI2bvpD9e/bV2ImahJCne4N3l0g8JnHAgAECgeDZs2dSKE8x/bms6cYKhBBCaN3tvmU6 kIZzCVdfoA0CAMigzMzMjIyMdgxgYv369Zs/f/7du3djYmJQKQDIYNBZdOvt5jnG3XPumgM5v7l3 e/hbwC+Frwmh0VVU6q/sCvbzGjtsUF8dhW56LuvuEiIStmxCWHl5OSGkR48eEp6s4M8rOU8JIarj V341QIn2bvwxmhq2xoFGCLl76MwTgYSvZWBgQAgpKyuTRnkSQggxcTb55xaivKallRZpKLv/XIBG CAAgY4qLi+Pj4z08PNo3gIlZWVnNnTs3Jyfn1KlTqBoAZDDoXOiG4+faEFKac6+eCMr3+1gMmBSw 6XipqJfTtB9+OXD27KYhLT/2kydP3qQaiQibhIQQ0tQkeO/9OHm9Ud8s+GLKjK8+N2KIJC0POl1T U7OyslIK5fnX2Sm8PQSZJkeXJ0SOIU9D2wMAkCV8Pj86OtrY2HjKlCkyckp2dnbDhg1LSEjgcrmo IABkMOioGou2jtbv3j/4+qt/HmviV70kRFFdldFQsIGZVKE18xD30bVTSTsjf1zoPUzvxQtCiKhl yaa2trZ79+50uqTTIOn6Dk66hJCGo6vCjpe/Z8NjhtG0DfG/xUSt/NxQCnOXtbW1m5nBPlyefz1Q eZ/3z9JWovpHRVWku7m5pjyaIwCALImLi2tsbPzuu+9k6qymT5/eq1evX375BRUEgAwGHZWCwRBj Yf3dXZtO8/66oSR8nh318x9EyX2WrSpVWVJJSE97a62/8oGo7mr87/cJEVBNLQphfD5fSUlJCuet NGQpy12JEFKya9YgC5fpP2z8/XhBWW0rrdqrrKz88uVLycvzryfd/b+DRX9nNMHDQ7/mCtXGzrXF Ds4AADKksLDw0qVLXl5e0um2pIdOp8+cOfPx48dHjx5FNQEgg0HH1N1l3dZp2lWJk4aMXxIevW3D 0glDPLY/1pgQHT2lh5zK4Bmu3cgfITMXb9p7YH/8ZuYk29HbXqgRwq+q/3v2Ut2pGUZqus7ht183 49Xq6+slvwkm7oOMZu0+HjGpNyGEvLibuXfD0lljbE169LYbO3d5ZELW/bom6Waw+vp6ycvz7yfd Zo33iTh86dqFQxEzXBdeVP78502fadFaUJ4AANBKYmNjzczM7OzsZPDcjIyMRo4cmZSUVFNTg5oC QAaDjoje68v/u3Z0nXePGztWLfk+eNcfPWeFn7iV8nVfBULke83ZfzzMy+JhfOBXM74M2HZF2//I vYthtkRw89jtv+4LiV5Vcl9UVtRRH70xVlhYePHiRTk5KbV5WvdBC/ZcuXt656q5o/v/vdtY/YOr GfHhS6Y4GttMDz/NlVKOaWhoKCkpad4c6A+V518cIn//umnvXGc712nhtwetPHgt+as+b0ZMNr88 AQCglWRlZVVWVnp5ecnsGU6YMIHBYBw7dgyVBdDCL5KiZs+sycnJqa+vHz9+PEoNOpy8vLzo6Ghd XV1CyNq1a6V+fKr2wY3cC1lZ586ePpX3gC9+UHN89Nk9s/pIPCNsx44dFRUV1dXVU6dO/eKLL1Cb AIQQDodTVFQ0ffp0FAV0PkFBQZqamv7+/rJ8kkePHj116tSOHTs+bftKgM6ouLj4woUL8+fPb/6v 4D4YdH6ZmZnR0dGurq5OTk4CQauswc5QN7EfP2fZhvijBWUl2XHfO6kSQqqPL192+E/JRyUKBILe vXtPnDjxwIEDycnJqFAAgM59feHx48eenp4yfp7u7u50Oh23wgBaBhkMOrnExMT4+PgJEyYsXLhQ XV2dz+dLekThy5ILGckJew7kV70vX9E1B05ddzBtsREh5HXW73nVEo/q4/P5Ghoa3t7eM2bMSE1N TUxMRLUCAHRWZ86cMTY2NjIykvHzVFJSsrGxyc3NRZUBIIMB/I+YmJiMjAxfX18fHx9CiK6u7uvX r+vq6iTLYM9Orpzrv4QZsOlK3X/lK2VLT1dNQkgT73GtxDfeuFyueE+zyZMnf//99xkZGZGRkRRF oX4BADqZmpqaGzduyOZSHP/m6OhYUVFRVFTUjOe+epjBnuFopEKj0WhyGuaj/Ldfet6ECgdkMIDO haKorVu35uXl+fv7e3h4iB80NzcnhDx+/FiiQ9P1HRx1CSGvz/16pPw/AlZTTcn9GkKIvK6RumQL MVZVVQkEgp49e4r/6+zsvGLFilu3biGGAQB0PhwORyAQODs7S+NgTXV3jmxd9uXoIaY9tLS0tLS0 9IwHuU1bHL7v6rNGqZytqampkpJSfn7+R8/kSdIc24lrDvCsv/7p5+jIlRPU8ncudh7+46UXWAAK kMEAOg0+n79+/fqCgoKgoCA3N7c3j6uoqCgpKTVzv+P/pmT99VemhBAqlzkzJOPRq3d7EFFDcWLg 6isiQhSGz3LSpEn0YuKzNTQ0fPOIjY0Nk8ksKSmJjIyUwtBKAACQGSUlJWZmZlLYE0z4/OKGSQOH zVu3++T1h9V/XbET1JXfOrcvcvHY/i6L9pe8kvhs6XT64MGDb9y48ZHnvboRFXjweQ/fkwUZv6wK +G55WELulY225E7kitSnQlQ6IIMBdAY1NTVsNpvL5bLZbCsrq7d/xGAwBgwYcPfuXQlfQnHAd9uX 9iOECO/snGtjNWr2ik3xSYdPZJ46euj3rT/6jhk8NOB4DSHyQ4LDJ+nLS/Za165dU1dXF6/o+HYM CwoKqqioWLt2LY/HQ6UDAHQOHA7HxMRE4sMIyhMXeG/MqyeE1sfjm7XRv6ccPnY8IzVxx0/fTbBQ IERUun/RpOCsGskDUP/+/Z8+ffrhC4LCmpJH3fQGzFgwXOvvr53dTCdM7UeEpdeeYDdK6KLoKALo TLhcbkREBCFk3bp1b987esPMzCwlJUXSl6F1d/jxcKrC1/M3Xqgh1TePxd08FvfOU9SHByXs+c5S UdKXKioqGjx48L8ft7CwCAoKioiICA0NZbFY74Q0AADocPh8flVVlbGxsaQHenVre/i5V4QwHNad S/tugNI/4zHcxk3/ekHygpH+R6qf7g3evej8D+YKEr2UiYmJQCB48ODBOxc93yan732g2Pt/HhK9 KM4vJ6SfhS4D9Q5dE+6DQedRVla2evVqZWVlNpv93gBGCLG3txcIBIWFhZK+mLyu28r0PwpSNi3x crM20vy7D2Nomth5+q3fd+WPtKBhWhLeAyN1dXXPnj1zdXV9708NDQ1ZLBYhJDQ0lMvlogEAAHRo 5eXlhBB9fX0JjyP480rOU0KI6viVX70dwMQUjKaGrXGgEULuHjrzRNJlo9TV1el0+if2QaLaC2HM tJdKnwVM6oWbAdBFoelDJ8HhcKKjo3v37h0YGPiB/SINDQ1NTU0vXLjwgSt2zUZTNhnlu3aU79rW elNnzpxRV1e3sLD4ryfo6uqy2ewtW7asX7+eyWSKFx0BAICO6MmTJ4QQHR0dSQ8kbBISQkhTk+C9 gw3l9UZ9s+CLXrUa5kYMSdfEoNPpenp6FRUVzQ9gL65tnjI+qkRvxv54n17yqHboonAfDDqDrKys jRs3Dho0aM2aNR8IYGL29va3b99uaGiQ/fd15coVe3t7BuNDQzU0NDRCQkIMDAxCQ0M5HA4aAwBA B1VbW9u9e3c6XdLr43R9ByddQkjD0VVhx8vfM+GKYTRtQ/xvMVErPzeUwlBAdXX1mpqa5j1X8PR4 oJtT4Dn1GXsu7plhiDsBgAwG0GFlZmbGxsa6uroGBAQ05/ljxoxRUFA4c+aMjL8vDodTV1c3evTo jz6TwWAEBwdbWlpGRUUhhgEAdFACgUAKKyISQpSGLGW5KxFCSnbNGmThMv2Hjb8fLyirbaX9TJSU lJq1SK+wNj9qkrXn5j8GMo8VJMwzU0SNAzIYQEeVmJgYHx8/derUhQsXNvNXlJWVx40bd/78eRm/ FXb06FE7O7tmTs5mMBiBgYHOzs5RUVGnTp1CwwAA6HBevnwp+U0wQgghdKNZu49HTOpNCCEv7mbu 3bB01hhbkx697cbOXR6ZkHW/Tpq7IysoKDQ2fmzDsSbe6UDXocuOK3rv5ORsGq+PO2CADAbQMVEU FRMTk5GR4e/v7+Xl9Um/6+HhQaPRTpw4IbPvLi8v78mTJ9OmTWv+rzAYDD8/v3HjxiUkJCQnJ6OF AAB0OAoKCtI5EK37oAV7rtw9vXPV3NH9tf96sP7B1Yz48CVTHI1tpoef5kpvWfiPZbCGPzZN8Iy6 ZbHkxLV9Cwao0FDRALgOAR01gG3evPn27dvfffedi4vLp/66hobGxIkTU1JSnJ2dJV+BSuoaGhpS UlJcXV0/dYViBoPh4+PDYDBSU1MJId7e3mgqAAAdBYPBqK2tlWai07PzWm7ntfxnqvbBjdwLWVnn zp4+lfeATwg3M3LGiD+iz+6Z1UfiGWF8Pl9VVfUDTxA82P3NqisC0rPns8RA38R/fiCv67EqbI6Z Qt2pGVZeZ3sFZ50PHtAN7QCQwQBkE5/PZ7PZlZWVLBarxSsBenp6ZmdnJyYmMplMWXuD4gQ1b968 lv26t7e3goJCUlJSbW2tn58fGgwAQIegoKAgEAha48gMdRP78Sb24+cs2yCo/uPwzyuWRl+qrz6+ fNlhj6RpPSRcm5CiqA+uhiX889zePCEh5MnZ/b//74+05X3XzTFTEL2q5L6opNdRIjQC6DIwFhE6 mJqaGjabXVtbGxISIslS7AwGw9fXt6SkRBx4ZEdBQcHFixf9/Pw+usDjB0yePJnJZGZnZ0dGRlIU hWYDACD7unfvLoWJysKXJRcykhP2HMivet+sL7rmwKnrDqYtNiKEvM76Pa9a4txTW1uroaHxga+a hr6XRe9XGT9chRCiPumMUCR6ED4Yy3QAMhiALCorKwsODqYois1mf+o4vX+zsrKaMWPG+fPnpbBl s5Q8fvx43759Q4cOdXZ2lvBQ9vb2TCbz1q1biGEAAB2CoaGhQCD4lL223pvBnp1cOdd/CTNg05W6 /8pXypaerpqEkCbe41qJb7w9e/bMwMAA1QeADAadU3Fx8fr169XV1UNDQ3V1daVyTE9PT2tr6927 d0va50lDQ0PD7t27dXV1FyxYIJUD2tjYMJnM0tLSsLCwZm/eAgAA7ZbBCCGS9kd0fQdHXULI63O/ Hin/j4DVVFNyv4YQIq9rpC7ZrJSqqiqBQNCnTx9UHwAyGHRC+fn5ERERRkZGq1evlmSQ3jsYDMbS pUt79er166+/VlVVtW8A27JlS1NT08qVK6X4Bm1sbEJCQqqqqsLCwng8HhoSAIDM0tDQUFZWfvDg gWSHUbL++itTQgiVy5wZkvHo1bs3w0QNxYmBq6+ICFEYPstJU7JFCu/du/cmPQIAMhh0KllZWVFR UdbW1mvWrJFiPnkTw3744Ydu3br9/PPP7RXD6urqtmzZUlVVtWzZsg+Oqm8JY2NjFov16tWr0NBQ xDAAAFlmb29/+/ZtCQ+iOOC77Uv7EUKEd3bOtbEaNXvFpvikwycyTx099PvWH33HDB4acLyGEPkh weGT9CVckOPhw4e9e/eWes8FgAwG0M7S09NjY2Pd3d0DAgJa6SU0NDRYLJa2tjabzRZf0mtLFRUV kZGRr1+/njp1amRkZGJiotSTkq6uLovFIoSEhoZyuVw0KgAA2dS3b99nz55JujIHrbvDj4dTVwzX IISQ6pvH4sKWL/zKZ/rMOX5L18WkXaskhKgPD0pL/s5S4kUwCgsLBwwYgIoDQAaDTiUuLi4pKWnG jBmtvca6hoZGSEiIpaXl9u3bMzIy2uwNFhQUbNq0SVVVlc1mjx07Vk1NLSMjg8lkhoeHX716Vbox jM1ma2pqBgcHFxcXo2kBAMggR0dHgUBw/fp1SQ8kr+u2Mv2PgpRNS7zcrI00/975maFpYufpt37f lT/SgoZpSXgPjDx48KC6utrOzg4VB/CpsD8YyCiKouLi4nJycvz9/d3c3NrgFRkMRmBgYFpaWmpq amlp6axZs7S1tVvv5RoaGlJTUy9evOjq6jpv3jzxGMvp06dv3Lixqanp9u3bt27d0tXV/fzzz4cP Hy6VEZjinBkZGRkaGspkMm1sbNDMAABkioaGxqBBgy5fvuzi4iLxwWjKJqN8147yXdtaZ5ufn6+u rm5lZYWKA/hU8mvXNvej+ejRo8bGRkl2ZAJofgDbvHnz9evXAwICpNEPNfvzIC9vZWVlamqam5t7 8uRJOTk5Y2NjOTnp3y7OycmJi4vjcrkLFy6cMmUKg8EQP66vr3/r1q3q6mqhUCjOse23HwAAIABJ REFUaTdu3Dh69Ojz58+7d+8ueSaUl5d3cnIqKio6cuRIr169MIsaOq6Kioqqqip8+YPOp1u3bqdO nRoyZIiqqqosn6dAIEhMTHRxcRk8eDBqDbq458+fP3r0aMiQIchg0IHx+fy1a9eWl5evWbOmXb5g 6evre3h4NDY2Hj9+PD8/n0aj9erVSypJTCAQXL58OT4+/vLly8OGDfvhhx/+/YHS1dXNzs5++xGR SPTo0aOzZ8/m5eWpqKgYGBjIy7d8AIk4htXU1CQnJ9NoNEtLSzQ5QAYDkB16enpnzpx5+fKltbW1 LJ/n+fPnORwOk8lUVMTWyoAMhgwGHRyPxwsNDa2vr1+1apXkuzBLElSsra0dHR0rKipOnjx5+fLl 2tpaVVVVdXX1Fn9fvHjx4v/7f//v8uXL1tbWfn5+Y8aMeW+/paenV1RU9M6yHCKRiBDy4sWLiooK V1fXN/fNJHl3IpEoPT1dIBDgWywggwHIDnl5eTk5uZMnTw4bNqxbt26yeZICgSAuLm748OFtOVYF oDNlMMwHAxlSVlYWERGhrKzMZrOltQuzJAwNDZcsWTJt2rTjx49fvXo1MzNTT09v0KBBAwYM6N27 t5KS0ke7qJKSkjt37ty7d+/Ro0d0Ot3FxWXixIkfHQHo5eV169atdx6Uk5PT1dWV1ur8DAbD29ub EJKamkoIEf8bAABkwZgxY44cOZKWljZ37lzZPMOTJ0/W1dVNmjQJlQXQMshgICuKi4sjIiIMDAyC g4OlvgmYhEnMz89v3rx5hYWFly5dEocxOp0unqClr6+vpqYmvqMlEAgEAkFDQ0NFRUVtbe2TJ08I IWpqaubm5pMmTXJwcGjm/Stzc/MhQ4bcuHFDPCuMEEKj0ZSUlFatWiXdkvH29lZRUUlISKisrFy4 cCEaIQCALGAwGHPmzNm2bZudnZ0M3uytqqo6d+7c1KlTZeFqKQAyGEDL5eXlxcTEWFtbL168WKYC 2Ns9oo2NjXgtQR6PV1RU9OjRIx6P9+jRo5cvXzY2NlIURQhRUVFRV1fX1NQ0MzP77LPPLCwsWjai 0tvb+83axOLZX6004N7T01NPT++XX36prq4ODAyUcJQjAABIhYuLS3Z29sGDB/v27fvRYRdtbN++ fSoqKp6enqgmAGQw6MCysrJiY2NdXV07yq0YXV1dXV3dYcOGtd5LGBsbDxky5ObNm+KZYEwmc/fu 3aGhoUFBQVJfzNDe3p7JZEZFRUVGRiKGAQDIiDlz5qxZsyY5OVmmRiSePHnyzp07K1askM0LpgAd BfZohnaWnp4eGxvr7u6OsXDv8Pb2bmpqotFoy5YtGzJkCJvNVlZWXr9+fWvssGxjYxMUFFRaWhoW FvbOciAAANAuDA0N/f39L1++nJWVJSOnVFpaevjw4RkzZmCHSQBkMOjA4uLikpKSfH19/fz8UBrv MDY2HjFihJ+fn7ir09DQCA0NNTIyCg0N5XA4Un85KyurkJCQqqqq8PBwxDAAAFng4OAwYcKEQ4cO tcaf/U/1+PHj7du3DxkyZPLkyagaAGQw6JAoitq6dWt2dra/v7+HhwcK5L2+/fZbNze3N/9lMBiB gYGWlpZRUVFXr15tjdTHYrEEAkFoaChiGACALPD29razs9u9e3dhYWE7nkZFRcXWrVt1dXUXL16M SgFABoMOic/nr1+/vqCggMlkvp0x4KPEMWzEiBHR0dFpaWlSP76uri6LxWIwGKGhoVwuFwUOANDu f/a/+OILPT29nTt3tlcMe/z48aZNmxobGwcNGoRpYABSgT2aoR0CGJvN/vPPP9esWWNpaYkC+eQP 7d87LKekpAiFQqkvW6yiouLq6lpQUHDw4EELCws9PT2UOcgg7NEMnR6Xyz137tz27duPHDmyYMEC OTm59PR0Go1mZmbWlqdRWFi4Y8cOAwODkSNHpqen37t3z8nJSbxgLwCIYY9m6AA9SlRUFEVR69at k/r6fl3H2zssUxTl4+Mj3eMrKyuHhIRERkZGREQwmUzMvQYAaDMURWVlZZ0/f760tFT8SL9+/ezt 7QcPHqyjo5OamlpeXj5r1qw2WLBeIBCkpqaeP39+6NChixYtYjAYZmZm0dHRQUFBwcHB2BwMQBK4 DwZtp6ysjM1md+/encVi4e6K5KysrHR0dPbt21daWuro6Cjdq5Ly8vJOTk4PHjxIT0/v1asXAjPI GtwHg84XvS5fvpySkvLrr79yOJzq6moajSb+0cqVK9XU1OTl5a2srExNTbOysnJzc3V1dVu1J62o qNi2bdudO3d8fHzmzJkj7mL09fXt7e1zcnLOnDljYmKCrhxArAX3wZDBoI0UFhZu3LjRwMAgJCSk e/fuKBCpMDY2NjU1TU9PLyoqkvrgEHl5eUdHx5cvX+7fv59Go2HgKCCDAbRG9Lp27VpycvKOHTsu X7785MkTGo0m3hmSECInJ/f555+/vR2lOAUVFxdnZGQ8ffq0T58+Up+gJRAI9u/fn5CQoKKisnLl SgcHh7d/qqam5uHhweFwjhw5oqKiYmpqikoEQAYDGZWXl7dp06aBAwcymUxM55UufX19ExOTkydP 3rx508rKSkVFRboxzMrKqvXmngEggwG+um3evLm0tPRN7nqbqqrq0qVLGQzG2w+qqKgMHz7cwMAg Nzf35MmT1dXVurq6qqqqkp9MVVXVyZMnd+7cyeVyv/rqq4ULF2poaLy3a3BxcWlsbDxw4EB1dbWt rS3qEfBBRgYDmZOZmRkbG+vq6hoQEPBORwLSimGDBg06e/Zsbm6ura1ta8QwoVCYmpr6+vVra2tr FDgggwFIi4qKiomJSW5u7nszmL+/f9++fd/7i0ZGRh4eHhoaGrm5uZmZmaWlpU1NTTo6Oi3oZwUC wbVr144fP37gwIGysrJx48YtWbJkwIABH+4arK2t1dXVDx8+fOfOHUtLS+l2PQDIYMhgIJHExMSk pKQJEyb4+vqiNFqPhoaGvb39+fPns7Oz7e3tpd4Xvpl79uzZs3fGpQAggwFIQk9PT1tbu6Cg4O0H 5eTkzM3N58yZ8+Eg1LdvX3ESe/To0dmzZ8+ePXv37t26urqmpiYVFZUP5DGBQMDlcgsKCs6ePbtv 3778/HyRSDRp0qQffvjBxsZGUVGxOWfet29fExOTnJyc1rgCCNC5Mxjtvddd3isnJ6e+vn78+PEo aGimmJiYnJwcX19f7MLcNng83oYNG/h8PpPJbI3LJRwOJyoqytLSMjAwELc0oX1xOJyioqLp06ej KKATKCsrCw0NffXq1dvfysLCwoyNjT+pC8jNzb1///6dO3f4fD4hRFVVVVtbW1lZWUlJSUFBobGx saGhgaKoioqK+vp6QgidTjczMxs8eLC9vX2L117i8XibN29+8uQJ1tGFLqu4uPjChQvz589HBoN2 RlHU9u3bCwoKvv76a+zC3MYlHx4efv/+/VbqC9/EsKVLl2JqHyCDAUguPz9/x44d2traDAajrKxM KBTKycmNHDnSz8+vxR3Bs2fPysrKnjx5UldX9/LlS4qiXr58SQhRUVFRUVExMDBQU1MzNDS0sLCQ bqc/ceJE8dYpAMhgyGDQ1vh8fkREBJfL/eGHHzBSqF1iWGRk5N27d7///vvWGDdYWFgYGxurra29 aNEi7A8DyGAAkjh27FhCQsLQoUMXLFhACAkMDKyurlZUVNy2bVvHus5FUVRaWlpqauqbzcRQuYAM 9gGYDwZSVlNT89NPP/35558hISHSusAGn0S8tVdNTU1ycrKCgoLUa0FPT69///6ttAQIQDNhPhh0 dBRF7dy5MyMjY+rUqb6+vgwGg8Fg2NjY5OTkeHl5fXhJDNnsesTblx06dIjD4VhbW6N3gK4Da3JA O+NyuevXr6coKiQkpHfv3iiQduwLra2tRSLRoUOHBAKB1L+ntvYSIADIYNC51dTUhIaG3rlzJyAg YMyYMW8eV1NTMzMze3tDsI5FX1/f0dHx7Nmz2dnZvXv3xibOgAz2X+RQaiAtZWVla9asUVZWZrPZ LZ7aC9LCYDC8vb0nTpyYmpqamJgo9ePr6uqyWCwGg7F69eqysjIUOABAMxUVFa1evZrP57PZ7H+P GO/oVxYMDQ3ZbLaOjk5ERMS5c+dQ3QDvhftgIB0cDmfTpk1GRkarVq3q3r07CkRGvFlTvry83MnJ SboHV1FRcXd353A4KSkpFhYWuN4JbQn3waCDysvL27Ztm46Ozrp16zrrlFpFRUUXF5eampqUlBRs LAldAcYiQvvIysr65ZdfbG1tg4KCMA1X1hgbG4sH6N+5c8fJyUleXl6KB5eXl3dxcSkqKkpPTzcx MdHX10eBAzIYwH9JTk7eu3evra1tcHBw5+4u5eXlbW1t1dXVk5KS7t27Z2dnh68HgAz2NoxFBEll ZmbGxsa6uroGBASgNGSTjY0Nk8ksLS2NjIwUbxojRQwGIzAw0NraOioqCsNOAADei6KoTZs2paam zp49u+t0lx4eHitWrKioqAgJCeHxeGgGAMhgIB2JiYnx8fFTp05duHAhSkPGY1hQUFBFRcXatWul 3hEyGIylS5eOGzdu9+7daWlpKG0AgLfxeDwWi3X37t0VK1Z4enp2wd5HIBAsW7assLAQjQFADGMR oYXEi+pmZmb6+/t3tR6lg9LW1h40aFBWVlZrLGYoXolRIBCkpKQIhUKMEIPWhrGI0FEUFRWx2WxC SJfdskVNTc3Dw0M8ap1Go1laWqJVQCeD+WDQdgFs8+bN169fX7RokaurKwqkA3WE9vb2eXl5586d GzRokJqamnSPb2VlRafTDx48iEnYgAwGQAjJzMzcsmVL375916xZo62t3WXLQbxxpUgkSklJqa6u tra2lu7kZABkMOj8+Hz+2rVry8vLV61aZWNjgwLpWFRUVFxdXQsKCg4ePNgaixlaWlqKV2IsLS11 dHRELwvIYNBl7d279+DBg2PHjg0ICMCKFOJNnHv27JmSklJUVGRpaYm9JaErZzDMB4NPU1NTw2Kx amtrQ0JCEMg7KGVl5ZCQEEtLy4iICA6HI/Xju7m5rVix4tatW5GRkRRFocABoKvh8/kbNmw4c+aM r6/vvHnzUCBvODs7s1isioqK0NBQ7C0JXRkyGHyCsrKy4OBgQgibzTY2NkaBdFxvL2Z46tQpqR9f vBLj3bt3W2MlRgAAWcblclks1v3791ksloeHBwrkHebm5iwWS0dHZ/Xq1bm5uSgQ6JowFhGaq7i4 ODw8XEtLa926dRoaGiiQDv/hl5d3dHRsbGw8dOiQQCCQ+pgufX19CwuLrKysCxcu2NjYYMwJSBfG IoJs4nA4Gzdu7N69O4vFMjIyQoG8l4qKiouLC4/HS0tLa40OCKCNYT4YtJb8/PytW7caGRmtWrVK WVkZBdJpYph4McPU1NTWWMxQT09PvBJjbm6ura0tYhggg0HnduzYsZiYGFtbWyaTiYuVH+2AHBwc 5OTkDh48eO/ePScnJ8wfhi6VwTAWET4uKysrKirK2tp6zZo1CGCdj7e394wZM1JTU2NiYqR+cEND QxaLJRAIQkNDsUEnAHRWFEXFxMQkJCRMmDAhICAAfWUzTZ48ecWKFY8fPw4KCkIfAV0KMhh8RHp6 emxsrLu7e0BAAEqjE/eCTCYzLy8vLCxM6qto6OrqstlsZWXl1atXFxcXo7QBoJPh8/nr16/Py8vz 9/f38fFBgXwSGxubkJAQgUCwevVqbOIMyGAAhBASFxeXlJQ0Y8YMPz8/lEbnZm9v33qraGhoaISG hhoYGISGhrbGSowAAO2lrKxs5cqVz549Y7PZbm5uKJAWMDQ03Lx5s5GRUURERGssEwUggzAfDN6P oqidO3dmZWX5+/uPHTsWBdIVtOoqGvLy8i4uLkVFRUeOHDExMdHX10eBgyQwHwxkQV5e3tatW3V0 dFgsFv6sSdhHODk5NTY2HjhwoLq62tbWFmUCHQjW5ACpBbDNmzdfv349ICDAxcUFBdJ1vFlFIzs7 297eXuoxzMnJicfjJScnq6iomJqaosABGQw6rvT09Pj4eFtb2+XLl2PNIan0EdbW1urq6ocPH75z 5w42cYbOncEwFhHexefzWSxWcXExm812cHBAgXQ14lU0CCGhoaFcLle6B2cwGH5+fuPGjUtISEhO TkZpA0BHRFHU1q1bk5KSZs+eHRAQwGAwUCbS4uHhwWQyKyoqwsPDsUoHdGLIYPA/eDwei8Wqra1l sVjYhbnLEq+ioampGRwcLPUZ0gwGw8fHZ+LEiampqYhhANDh1NTUsFisgoKCFStWeHp6okCkzsbG hsViKSgoLFu2DFOIobPCWET4R1lZ2fr16xkMBovFMjQ0RIF0ZYqKisOHDy8qKkpPT2+N6VtWVlZ0 Ov3gwYP19fU2NjYocPhUGIsI7aK4uHj9+vVCoXDVqlWWlpYokFaioqLi5ubG5XIPHTqETZxB9mE+ GEjUr4SHh/fo0WP16tXYWRLI39O3Hjx4kJ6e3qNHDyMjI+ke39LSsk+fPgkJCQ8ePHBwcMDunIAM BjIuLy8vIiKiV69e69at09XVRYG0dh9kZ2cnEolSU1PLy8vt7OzQTQAyGHTCfmXz5s0DBgxgMpnY WRLe7gIdHR0bGxv3799Po9GkftG3Z8+epqamaWlpRUVFTk5O6F8BGQxk1t69exMTE93d3ZcvX44J YG3WB1lZWZmamh46dIjD4VhbW2OVDug0GQzzwYBkZWVFR0c7OTkFBgYigME7GAyGt7f3xIkTDxw4 0BrTt2xsbJhMZmlpaWvsSwYA7UlUl7vcjG76483XHft98Pn8DRs2nDlzZvbs2dgts+3Z2NiEh4fX 1dWFhoZiE2foNJDBurr09PTY2Fh3d/dFixahNOADMWzGjBmpqalxcXGt0b+GhIRUVFSsXbsWq2AB dJoAdu1nr3GbS5pEHft9iJequn//flBQEFbgaC+GhoZsNltHRyciIuLcuXMoEEAGg44tLi4uKSnJ 19cXF/bgoyZPnsxkMrOzsyMjIymKku7BjY2Ng4KCXr16FRoaihgG0NFRf1785UsbO+bpFx38jRQX FwcHBxNCwsPDMfC1fWloaAQHB48ePXrXrl2JiYkoEEAGg47hndv34r1NsrOz/f39PTw8UD7QHPb2 9kwm89atW60Rwz6wL1lZWZnUdyoDgNby4vRMs+EBSa8/X7crsF8Hfh+ZmZlr1qzp169faGgoVuCQ BQwGY968eb6+vidOnAgLC8PwdUAGA1l37NixiIiI4uJi8X/5fP769esLCgqYTKabmxvKB5rvzfSt sLAwqd+werMv2erVq980Vy6XGx4efvDgQRQ+QAf5ZqFu67/l9MOSI8FuOh1znR2KouLi4uLj48eO HYuZ0rLmzSbOISEhGDcByGAg031Jenq6QCCIjIzk8Xg1NTVsNpvL5bLZbOzLBC2LYSEhIVVVVeHh 4VLv/zQ0NEJCQkxNTUNDQzkcTk1NTWRkZH19/dWrV8vKylD4AB2AiuOPm5Z69FakdczT5/P54eHh 4nEi8+bNQ33KZjcUFBQkEAiWLVuGVToAGQxkVFpaWn19vbhfWb169dq1a/l8/rp164yNjVE40DLG xsYsFksgELTG9C0GgxEYGGhpaRkVFcVisaqqqkQiEY1GO3DgAEoeAFpVWVnZypUrnz59ymazMU5E lhkaGm7evNnS0jIiIiI1NRUFAshgIFv4fP6xY8dEIhEhRCgUvnjxoq6uLjg42NDQEIUDkhCPG2Qw GG+PG5RiDFu6dKmiomJ1dXVTUxMhpKmp6ebNm1J/IQCAN/Lz89evX6+srMxms3GZUvaJL9hNnDgx OTk5Li5O6rOUAZDBoOXS0tIEAsGb/wqFQoFAsGPHDvypAslpaGhs2LDBwMBAPG5QikcWrxnD5/OF QuGbB2k02v79+1HsANAajh07FhUVZW1tvXr1aqzA0YFimLe39/fffy9esxfTwwAZDGRCTU3N6dOn xbcR3hAIBKWlpRs3bkT5gFT6v+DgYPG4watXr0rrsDt37vzjjz/eDmDiKwh37tzB0H8AkC6KomJi YhISEqZOnRoQEIAVODocZ2dnFotVUVERGhqKmcOADAbtT7wUx78fF4lEhYWF2OUQPubVwwz2DEcj FRqNRpPTMB/lv/3S86b3xLDAwMARI0ZER0dLZVB+cXHxrVu3CCFycnLvtFs5Obnk5GRUDABIS01N DYvFysvL++GHH7y8vFAgHZS5uTmLxdLR0Vm9evXFixdRIIAMBu2Gx+NlZma+uQlGo9FoNBohRF5e fsyYMVu3bh01ahRKCf5b05OkObYT1xzgWX/908/RkSsnqOXvXOw8/MdLL0TviWHz5s0TD8qXPCOZ m5tHR0cvWLCgd+/e4hb75kdCobCoqAi3wgA6tLpTM4zUdJ3Db79u7zMpLi5evXo1n89ns9kODg6o mg5NV1c3ODjY2dk5NjYWV+tA9tFRBJ1VSkrKm3/Ly8s3NTUZGhpOmTLFxcUFhQMf9+pGVODB5z18 Txbs+kxLjhDy3fdzBrsMWBG5InXJ+bk95f4dw7y9vQkhqampFEX5+PhI8uIMBmPkyJEjR44sKytL S0srKCgQCoXipWXEt8KsrKxQRQAdlOhVJfdFJb2OErXraeTl5f32228GBgbBwcEYf9g5MBiMhQsX 9uzZMykpqbi4ODAwkMFgoFgAGQzaDpfLzc7OfhPA3Nzcxo8fj7UQofmENSWPuukNmLJguNbfcaub 6YSp/VZcK7325PXcnkrv/S1vb289Pb3Y2Fgul7t06VLJOz9jY+OlS5fyeLzc3NxTp05VV1eLRKKi oiIOh4Pd7QBk/hux+YpC0Yp/Paw+6YxQ1M6nlpiYmJGRMXTo0ICAAFRUJzN58uQ+ffrExsYGBQUF BwdjhRWQTRiL2DmJl4/T09NbvHhxfHy8n58fAhh82p8Gfe8DxX8WbnX65+Kw6EVxfjkhPSx0P5Ss 3NzcVqxYcevWrcjISGktv6mrqzt58uSff/55xYoV4uj19m1eAIDmoyhqw4YNGRkZs2fPRgDrrGxs bEJCQgQCwerVqzF8HWQT7oN1eHw+v7y8vLKy8unTpy9fvqQoqqqq6unTp8OHDzc0NKQoqqioyMTE BAMtQDKi2gthzLSXSp8FTOpF/2jnx2Qyt23bFhYWFhAQoKGhIa12zufz+/btq6Ki8uDBg40bN6qp qSkrK6urq6urq+vq6hoaGkrltQCgs+LxeJs3b66srHxzQQc6K/EmzpGRkREREbNnz/7ss89QJoAM BpKiKIrD4dy8ebOwsLCiooIQQqfTFRUVxV9JKYpSVFQsLS0tLCysrq4W/4q2traNjY2pqamjoyPy GHxqAHtxbfOU8VElejP2x/v0kv/4L4ivQUZFRYWFhQUGBrZsKMibdn7v3r3y8vJ32nl1dXV1dTVF UQ0NDWjnAPBRxcXFERER6urq69atw9iQrkC8bG9ycvKePXsePXrk5+eHMgHZQRNPc2+OnJyc+vr6 8ePHo9Ta0dWrV/Py8vLz8wUCgZ6enpWVlbGxcY8ePYyMjN77fIFAUFlZ+fjx4/v375eWlj558oRO pw8ePNjJyWnYsGEoT2gGwdPjKz+fvPm67ow9WXvmmSk2/zd5PF5oaCghhMVifVIMa1k7Ly8vLysr Ky0tffjwIdp5p8fhcIqKiqZPn46igObIzMyMj48fOHDg0qVLcYGmC9b+77//bmlpuWDBAkwPg9ZQ XFx84cKF+fPnI4N1NhRF5ebmpqenV1RU6OnpOTk52dvba2trf+pxqqqqbty4UVBQUFZWpq+vP23a NEdHR6waBP9JWJv/85fjlh2vG8JMPxYxXv+T75zzeLwNGzbw+fygoCBjY2O0c0AGg7a3d+/ekydP jh07dt68eSiNLvsXIz4+nk6nY5UOQAaD5iosLIyNja2srLS1tXV3dzcxMZH8mBUVFUePHr127Zq+ vv6XX36JfVHgPZp4p1eMHhd1y8B756ndfgNUaC2+ghAeHn7//n0mk/mBCRjFxcXR0dGt1869vLyw MQMyGHQ1fD7/l19+uX379ty5cz08PFAgXZl4NuCTJ08+3BkBtE0Gk1+7dm0zn/ro0aPGxkZzc3MU dFt2HjExMfv27evZs+fSpUuHDRumqakplSOrqqra2tra2dmVl5enp6eXl5ebmpqqqKigzOFvDX9E fjYi9Lr5khOXdk037kZr8YHk5eVdXFyKioqOHDliYmKir6//3naekJCgp6f3/fffjxgxojXa+ZEj R0pLSy0sLNDOO4eKioqqqirsFAcfwOVyw8LCnj59umrVKlxqBBUVFTc3Ny6Xe+jQIYFA8M5fj7S0 NEtLS5QStMzz588fPXo0ZMgQZLDOoKioKCwsrKKiwsfHZ9q0aa0xfl1VVdXe3r5Hjx65ubknT57s 3bv3v78fQ9ckeLBr6uRdj0Q9B5m8vJyR9o8jF+utRg7Wkq87NcNsyKJkMmGOq+5HRyjKy8s7OTnx eLzk5GQVFRVTU9P3tnNvb29VVdVWaueGhoZ5eXknT540MDDAdHxkMOj0OBzOxo0bu3fvzmKx/msq KXQ18vLydnZ2IpEoNTW1vLzczs5OXl6eEJKenn7gwAFFRUULCwuUErRNBsO6iDIqPT09KSmpX79+ CxYsUFJSatXXsre3t7GxSUxMjIqKmjhxore3N8q/yxP+eW5vnpAQ8uTs/t//90fa8r7r5pgpiF5V cl9U0uuoZo5mZjAYfn5+6urqCQkJtbW14mYmbudmZmbffvtta7dzGxubgQMHJiYmRkdHo50DdG7H jh1LSEgYOnToggULsAIHvNMZeXt7m5ubR0VFrVu3LiAg4P79+0lJSYSQgwcPDhs2DHucQNtABpNF MTExOTk5kyZNGjt2bBu1Azp97ty5vXr1SklJefLkyaJFi7CAQdcmZ+h7WeRRcZ2VAAAgAElEQVT7 oWeoTzojFH3aQRkMho+PD4PBSE1NJYTU1taePXu27du5iYnJ/v370c4B2oZ4cz8ej1dRUSHexJKi KAaDoaysrKysrKampqenJ8VNLCmKiouLy8nJmTBhgo+PD8of3svGxiY8PDwiImLNmjUvX74UPygQ CPbt27dw4ULZb+eADAatEsDy8vJmz57t7Ozcxi/t7u7eo0ePnTt3RkZGBgYG4usptAZvb29NTc09 e/bQaLR2aeeurq5aWlpo5wCt59+b+xFCVFVVlZWVlZSUGAyG+Buq1Df34/P5ERERDx488Pf3d3Nz Q0XABxgaGgYHBwcHBwsEAvEjTU1NFy9eHDFiRDMHObdXO4fOAesiymgAa8fZw4WFhTt37rS2tg4M DESNANo5yCasiyibCgsLz5w58+/N/QwMDOj091z2leImlmVlZVFRURRFNWcnDACKotauXfvw4UOh UPjmQTk5uT59+vz0008f/t2ioqITJ060SzsH2YS16Ts28QYm7XJn4N+d6Pbt26W2lYqoLjfQdkTq jGu3fxrUDfXc1SUmJmZkZMhIO9+5c+eIESP8/PxQL8hgIKGsrCypb+7n5eXl4ODQnJvVeXl5v/32 m4GBwbJlyzCfB5ojJibmwoUL7/0a/NVXX3322Wfv/a3c3NyDBw+K27m9vb2Tk1NbtnPoTBkMYxFl hXjFtmnTprX7F1NCiJWV1ezZsxMSEszNzSXdUklUd+1nr3GbS5pMUMlAOBxORkaG7LTzmTNnJiQk mJqajho1CrUD0OIvH28295s+fXq/fv1afChtbW13d3d3d3fx5n7btm1rziaW4tV9hg4dikme0EyF hYU5OTk0Gk1OTu7t+2CEEDk5uf379w8fPvydsYLFxcU7dux4+vRp//79p06dKsmirC1r59DJYG16 mcDj8SIjIwcOHDht2jQZOSUjI6Pa2tr09HRHR0c1NbWWHYT68+KvfmOnRBU0EkI0XRd+N7oHUn/X bufh4eEy2M4zMjIkaefQLrA2vSz49+Z+Ojo6UjlyMzexpCgqKioqMzNz9uzZc+bMEa8zDvBRenp6 o0eP1tTUfPXqVVVVFY32zx6YIpFIKBS+ePHC1tb2nXauo6Pz7bffjhkzRk9PrzXaOTax7LiwP1hH tXnz5tevXy9evFimLuD179+/oKDg5s2b7u7uLfn9F6en9xm15bry5+uivnh6JLcJGayri46O5vP5 na2dAzJYV9Vmm/v91yaWPB7vp59+KikpWb58uaurK2oEPomioqK5ufnIkSNHjBihpqb2/Pnz+vp6 Op0uFApFItHDhw9tbW01NDTE7fzRo0dz5szx9vZWV1dvvXZ++fJlbGKJDIYM1nby8vKOHTu2YMEC WdsfWU5Ornfv3kePHu3evfvbm+o2l6Dq/gur4P3/78fxmpyd0ZkCZLCu3s6PHDkyf/78nj17ymY7 x+6cyGDQfOnp6b/++mvPnj2XLFliYtK6Y8179uw5YsSIZ8+eHTp0SCAQiCu9uLg4LCxMKBSuWrXK 0tISNQItpqKiYmlpOXbsWCcnJw0NjT///JPP54tEopKSEpFItGXLFj09vSVLlpiZmbVNO09LS3vT zqETZzB8I25n4p1MbG1tJRlA33pMTEyGDRuWlJT074HRzfir5vjjJkdCCKFQz2jn1O+//25rayub nYqJicnIkSMPHTo0atQoLBYM8FFxcXHtsrnfm00s7ezstm/fbmpqGhwcjM8sSIuhoaGhoaGnp+eD Bw/Onj176dKl+Ph4T0/Pzz//vC3buXgTy7KysqVLl2J+YycmhyJoX6dPn25oaPD29pbZM5wyZQoh 5NixY6gskKSd19bWynI7nzBhAto5QHPExMScPXt29uzZbRbA3nB3d1+0aFFBQUFMTMzIkSNDQ0MR wEDqGAyGhYWFSCRqbGxsywD2hqur66JFi27duhUZGUlRuIyNDAatgKKoI0eODB8+XJYXA1BSUho1 atSJEyf4fD6qDFoG7Ryg0wSwnJycr776qr2WNrWysvrmm2/k5eVra2tRHdDa7bztA9ibdr5o0aK7 d+9GRkaiOpDBQPouXrxYW1vbXp/w5nNychIKhRcuXECVQQucP3++trb2v/ZakR3u7u5o5wAfkJiY mJOT0767q7+JYbdu3dq7dy8qBQghRMQvOhA0YaCOPI1Go2tZjlm4Pa+qqaUHO3jwoCy08379+n3z zTd3796NiYlBDSODgZRlZ2f3799f9lfE1tbWHjBgQE5ODqoMWtzOW7CLZRtTUlIaMGDAiRMnUGUA /yaDm/udPHkyNzcXVdPlCR7u8bKbsfGUcOTyjdui18/q9ceOxS6uIVfqW3CswsLCQ4cOyVQ7z8nJ OXXqFKoZGQykpqam5u7du4MHD+4QZ+vk5FRSUlJWVoaKg87dzisqKoqKilBxAG/j8Xjbtm0bMmSI 7Gzh4OzsPGzYsB07dnC5XFRQl8YviPzxeL1RwPnLyRGBi79bGX08J2owubP1p5zaT2/nW7Zs6d+/ v6y184SEBLRzZDCQmvz8fPGnS4rHfH07zE5LS0tLS2vw2puvpHm2/fr1U1RUvHr1qrQOWHdqhpGa rnP47ddoCp0ah8ORvJ033t8yVOv9DMztxsxZ9duFp6+l187Fn00AeOO3335TVFScNWuWTJ3V9OnT tbW1d+zYgQrq0rpZLj108tiBYMfuf+2zTFfvqSVPBA2vmlrUzr/++mtZa+c9evRAO0cGA2lmMDMz MzpditsDvLqdkPhA/M/HiXHXXkrxbOl0uoWFRUlJibQOKHpVyX1RWVFHidAUOrWCggJpt/P/ve5Q 9aDg6I7ASbaTIgteiKTTzu/fv4+KA3jj6tWrN2/enDlzppKSkkydGJ1OnzNnTklJydGjR1FNXZe8 upnTZ+OdetCJsPHFs/u5iSE+i841mXwTPFLzUw7D4XBktp1/+eWXaOfIYCA19+/fHzBggDSP+PL6 noNPCOnhZt+dkMrUHTnVUs03xsbGt2/fbsmqcQzzFYUiUelPg7r985j6pDNCkehB+GBFNIXO3s6l uH+rzdqDx/92LCP90P49v6z7drQhIeT11fC57Ev1kjf5/9/efcdFcbRxAJ/luKNJ76AIAgo2rIiI UuxYULFgF3tv0bxqjD1qjMaShNijWMGGJVZEmthAsIBSBKRI7+3gyr5/HHccRUI5FPH3/cOP3O3t LTMPu/PszM6YmprGxMRgdkQAAQ6Hc/Lkya5duzbzxf3wNwukwGeqnrZpv6k7vQt7/XRqm60qVZ9P HzlyxNzcvDnHuYeHB+IcORg0VnJycnFxsaGhoQT3mf/8xI1MQlQdFq8ZpUZI0V23+2k8Ce6/Y8eO XC43PT0d1Qd1lJGRkZeXZ25uLqH9SauZ9eojZGXd327I6GnLdl58eGqUEiEk5ewBv8bfdzA1NUWc A4j4+fnl5eVNnjy52R4hFveDcqz2Sz3uP/z39JaxusG/2PaYfyu9zo0gb2/v5h/nTCbTy8sL9Ywc DBrbNiWEaGhoSGyPdHbg8Tt5hCjaju9jPWW4OiHcwL+9EiS4tp/gaDEtBxBCwsLCzp8//5+PCAs2 kGSc14ShNXDuECVCSOm7Z0mNfixMV1cXcQ4gcuXKFSsrKyzuB98AGQNbx8EOjjM2ewaccJD5eGLF ofDSesV5c56/VxDnPj4+iHPkYNAoHz9+lJWVleBfOz/j0THvEkJa2U3podiq+8yx2oSQ18cuRJdK 8u9fVVU1MzMT1Qe5ubm3bt1au3btmjVrHj16lJub+7k4l5aWbvqrmpScogwhhLDkWVRj9yUtLa2q qiq4SwLwnRMs7jd48OBmfpxY3A8qn8f1h8/oRkhsQGSdpqd/8eJFXl6enZ3dNxHnmKceORg0SnFx sUQbpryUe8f8OYSoOM7uo0wRuc7TJrUhhMS5n3wlyfslSkpKyMFAXEpKyvHjx5ctW7Zr166goCAO p1LPK5fLVVNTa/KDYMd6+2cQQrTsBraVkcD+1NXVs7KyULkA/v7+JiYmOjo6zfw4sbjf96ws6uBA HUXz9aFis0HzirOKCJFVbsWsyx7u3LljYmLSpk2b5h/n3bp18/f3R6UjB4NG5WCS3B038eaJ5zQh mk6uvRUJIUTWbPI0E0JI+qXDQbmSm5lDQUGhrKwM1Qc0TYv+Q9M0j8d7+/btn3/+OXv27NOnT4eH hwveLSoqYjKZTXYU/LKizLhgr90znfd8IERpxI7V3SUymxWTyUScAwgW9+vVq9c3cbRY3O+7xdLt bsgvfH9s74MMfvm1Idv/9wNviZzD1B6tWlicW1paIs5bDGkUwVdRVFQkwclPy2Kv/POaEKI/fqaF fPk5qd34WZ13bXxbcNvtYYaDs5Zkkm1ZWVlB9nj+/Pn8/HzU43crNTW1xqyMx+N5e3vfu3dPRUXF xsYmMzNTopP8cn1cDGvsVmO0n3rIfY+znmROaHJychhwDyCRxf2qKI3YaW2zN44Q0ma577MtXSU3 Ma5gcb9Xr161b98edfd9UbTeetD5+pTzo7tnLlsysj314fbfB+8kqow8/sdYbSlCSP79SZ3G+7Re 7+e7vqPMZ+K8kTlYWcz+/pbbo2t6S0bdqLPVUJcFy6bZ6DZ+oIaxsbGcnFxwcDDiHDkYNBCLxZLc zthRF89EE0KMJk81F13QmAaj5/T6eVVwma/bzSSnOQYSqWkulyvo1hDMd4d6/G7VkoHzeDxCSEFB QX5+/hfrTeJF3T11rF+PLZM6KFASiXNUMcDr16+beBHLtYesFSTWmpGWbt++/bt371Bx32FTtvXk cy+Vu6752e3whvscIt/Gauquo7tXD20taGkJ1iOV/sx6pB8+fDAxMWm6NcEEi1iG/PuP5/pbl9f0 VKQaG+fm5uavXr2aMmUKKh45GDQEk8mUWDuvJPzMxQRCSIcZE03F7rEw9IbP6/9jsD8n9IjHh+lr O0gi6eNwOPLy8oSQFStWoBK/Z76+vkePHhX9SFEUIYSmaQaD0bt37169ellbWxNC3N3d379/L8Hv 7fbzxe2WwkYbzeOWFmYmRj6/c/bkg7gXJxbbvcv1v7LQVEZicQ7wPXv37p2lpaUk91ixiGWxX3Dm tcMBW/sOU6UktntDQ8Pbt28XFxfj7/f7I2PguMnTcVON7ymPfsj//EMZoaGhPXv2lNhFasvlXX0U hNeoMnZhTlLk0+tHDz9MLn2xa8Y2m2d7+rZqZMgbGRm9fv0acY4cDBqeg0lqsFNhyD9XUgkhJHKr pfbWmraIOXXq7dJdPSRwj6ekpERPTw/VB+KkpKT4fL6WltbIkSN79eqloqIiHucS7S+VVutk1a9f lTmyHZ1nLpz5p5Pd5uDSoC0/3hh7eYI2o9E5mIKCAmoWvmeCwQ6mpqYS3KfYIpbUG5fz2Xfd7qcN nqTDkNT+O3bseOPGjfT0dMmuvQktO86zs7MlF+eCRSwrX6SGjJ48yWq25ayb+SlnD/ittxqh1rgk TLSIJeL8m28+oQi+Cg0NjZKSEgnsiM57euJm9n9slOJx5LlEHt7Ky8vDfRcgYnNyaGpqjhkz5rff fjtw4MCgQYPEEzBCiLKysmTivHaUXMfZmyeqEULKgi4GNz7Us7KylJWVUcvwPRMs7ifJGRGbfhHL Oi7ul5ycfP36dT8/P9QypKenSzjOa9IUi1hiWo4WAP1gX4empqbggZlGLnxJZ/sfu1dACLH45YnX jNZVq5MufLK678TLubk33Xx/6T9ao1EpN5fLzcnJMTAwQPWBjIzMgAED+vfv36lTp9rjnM1mNz7O 63BA+p10CMkmnMyUQh5RbdyN9ZycHMFFDuB7zsEku7hf5UUsWTPHap87nvb62IVo1w0dZSTzFbUv 7sfhcIKCgoKCgt68eUMIcXZ2Ri2D4F7Dt7iIJZ7JRw4GDSToQU5JSWlc25Sf7n3sEZsQ0m36SGNl heq1qWA9x0nj8ulM9kO32ykjZug3pmmakpIiaFWj+sDa2lrwxFftBAM8EhMTa0/VJKAs5V0aIYQw 1LQUGte7n5iYSAjBmFv4zrHZbIku7ldlEUvSedqkNscPJca5n3y1cq+lxIZXVF/cj8PhhIWFPX78 OCQkhM/nE0IoimIwGKhiIIQUFBRoaWk1/Z8TFrGEmlJzFMFXoaKiIi8vX32C7/rhJt85HsglhPSY MeQzs3LLW8wYr0sI4T8/fDmucWM+BG1TIyMjVB/UkYKCgry8fFJSUlNf32LO7vDMIoQQi1HdlSjE OUBjSXhxvy+1iKX44n7Jycnu7u5Lly7dv39/SEgIj8ejhVC/0CRxXlVTLWIpLy9fVFSE6vvWoR/s 62Aymebm5u/fv7e1tW3wTjgJN06EEEJIz+mDdT93U0/WfMokg8MHEsj7E+4RC7ZZNHw1lnfv3pmZ mTXl2QpaZpzHxMQMHTpUIu247PCnj8Vmy6D5nOKMmGe3Trl5RZQRQrRnbnZu3ciT2ocPHxDnAMXF xd/iIpZycnLZ2dnXr19/+PBhZmYmg8EQrJYh+Lfi1EHTwcHBnxu1CN+PyMhIWVnJrVL3pRaxlJeX z83NRfUhB4MGMjExuXLlSklJSUOvc2UfLp0KJ4SQXtMH1TKxlGz7SVOMD+z+QJIuHAv+8U+bVg09 4JiYmMZkjIA4b/zewra7jPrsRcl604XtNsqNHWsfERGBOAeQqC+6iCVN0ykpKWw2m4jNHlRdUVGR YD4G+K5Dk83+MrPgSnYRy7KyMokuMwvIwb4z1tbWHh4e4eHhDVydnf3+/LkPhBDKcsagWuf2ZbVz nmG+e/M7kuV12H9bP8cGzYoaHh6en58vwTU0AHEuGSxVA7NuNsNc5swb2129sSc0xDlA+T0NeXmJ TWr6BRexJIQoKSktXLiQw+GEh4f7+voKHgOjKEp8FCJFUba2tpiWA9zd3QVztEjKl1nEksvlYrAG cjBoOE1NTTMzs2fPnjWwbSrbddvr7G112ZJpvOxx9rLGHe3r16/btGnTvn17VBx80TgX5Fkmq55l r/oCR/v69WtdXV3EOcA3uohlcXGxYEIdJpPZrVu3bt26cTicBw8evHjxIjIyUpCJoXKhKeJc0Kj+ MotYiuIcvmmYk+Nr6tWrV1RUVH5+fjM/zvz8/KdPn2KAFrTsOC8pKXn69OnAgQNRZQDKysqSaZt+ 2UUsqy/ux2QyHR0dN2/efPDgwYkTJwqm9uVyuahikGSc1w6LWAJysOZm8ODBLBbr3r17zfw4/f39 WSyWnZ0dqgxacJw/fPgQcQ4goKmpWVpa2vhbJ+KLWMYlVpPwznO8CiEk96abbya/8Yddy+J+mpqa Tk5OBw8e3LJly4ABAyQ44wh8u/T09EpLS7/EPO+CRSxJ+SKWjVRQUIBFLJGDQaMwmcxRo0YFBgY2 5y6CkpISX1/foUOHysvLo8oAcQ7wPRAt7te43VRZxLKaVtrWc5w0CCHsh263UxrZNK3j4n7t27df uHCho6MjahkEi7U2Os7rQHKLWKampnK5XCzWihwMGsvR0ZHJZHp5eTXbI7x79y4hZMSIEagsaPFx PnjwYFQWAJHU4n5YxBK+hzj/b5JcxDI2NlZwKwHVhxwMGoXJZM6YMSMkJCQyMrIZHl5iYqK3t/fo 0aPROQASifPw8PDmHOcqKiqoLAAitrhfY3ZS90UsCSHk/Qn3CHZjvu7jx49Y3A8aEOfR0dES2h83 O/zpYzGBAb73rx7fPntQ/3VPJLWIJeK8xcC8iF+ftbW1n5/f5cuX//e//0lLN6Ma4XK5Fy9eNDAw cHJyQjVB4+P8yZMnXl5eHTp0aFZxTghBnANU980tYhkREdGvXz9UHHzZOK/kyyxiiThvGdAP9vUx mcw5c+bk5uaeP3++WR3YtWvXkpKSFi5ciDoCicT59OnTm2GcX7p0CXEOUJ21tTWXy21433X9FrEk hJAsr8P+2Q2cOz4yMjI7OxuL+8GXjvP/xFI16Go/5ccjD195rezWqpEZGOK8JUE/WLOgr68/ffr0 I0eOtG3btplMAR8SEuLr6ztt2jTBE6sAiHOA78q3tYjly5cvNTQ08JAMfOk4F+RZX2oRy5cvXyor KyPOWwb0gzUXtra2Dg4OV69ebQ4PzMTGxl64cKF///6YOQokHudDhw5tVnHep08fxDlAjb6hxf1C QkKGDRuGKoMGsLa2RpwDcrDv2syZM7t06XL06NGvOz9HYmKim5ubsbHxokWLUCkgcVOmTBHE+ddN wwRxbmBgsGLFClQKQI2+ocX9KIrC4n7QMLa2tgoKCt9EnHM4nGYyigSQg7UoTCZz5cqVZmZmbm5u X6t5GhkZefDgQV1d3ZUrV6JGoEnj/CumYYI419TUXLt2LWoEoJa/1m9lcb/+/ftj/l5ocJwPGzbs m4jzgQMHYv5e5GDQVCeCtWvXCnoJ/Pz8vvC3h4SEHDp0yMzMbMOGDbiYQVPHec+ePY8ePfrw4cOv FeebNm1CnAPU7ptY3I/D4WBeU2hknCsoKCDOATnY9948Xbly5bBhwzw9Pc+fP8/lcr/Al3K53EuX Lp08edLBwWHt2rVomMIXiPPFixePGjXq6tWr7u7uJSUliHOA5vmn2pwXsUxNTfX29nZ2dkbnADQy zl1cXJrtIpapqam+vr6I8xaGsWXLljpumpCQUFZWZmpqilJr8lphMLp06WJgYHDr1q1nz55pampq aWk13dfFxcX99ddfkZGRS5YswS0W+JJx3qlTJwMDgwcPHnyZOD9y5Mi7d+/mzZs3btw4lP+3LjU1 NSsrq1OnTiiKpqavrx8REREaGmptbS0l1bxu3f79999ycnLLly9HNUEdxcfHJycnV7/c6Ovrx8TE PH/+vE+fPs1tBeRjx44xmcxFixYxGAzUYPOUnZ2dkJDQvXt35GAt5LLXs2fP2NjYW7duZWZmtmnT RuK37bOysi5cuHDlyhUdHZ1NmzZ16NABxQ5fPs779OkTHR1969atlJSUtm3bNl2ca2lprVu3rkuX Lih25GBQj4YCg2FiYnL37t309HQLC4vmc2CXLl16+/btunXr0DkAdff48eO//vrL29s7Pz9fUVFR FDwMBsPIyOj+/fuZmZnNLc5fvny5Zs2aJr1NCcjBoBIlJSUbGxs1NbUnT57cu3cvJydHT09PIi3U 1NTUa9euXbhwobCwcN68eTNnzlRQUECBw1ehoKBgY2Ojq6sbFBQkiHNNTc1WrVpJNs5nzZrl6uqq pKSEAkcOBg24GCkrK1+/fr1Vq1bNZDG9sLCwq1evTpkypXfv3qggqLvo6Oi3b9+y2eyYmBhvb++A gABZWVkVFRVZWdlmG+fTpk2zsrJC3bWwHAxrNH8D7O3tbWxs/Pz8bty48ezZs/bt2/fo0aNbt25y cnL13RWXy33x4kVERIRgOUtnZ2fB89YoZPjqrK2te/fuLYpzQ0NDKyurBsd5WFjYq1evEOcAkmJr axsdHX316lUNDY2vnvrGxsaePXsWi/tBw0hJSfF4PD6fTwjJyMg4ceIEIcTMzMze3r53797x8fHN JM4TExMR5y0YRdN0HTcNCAgoLCwcPnw4Su1r4XA4fn5+wcHBr1+/lpaWNjQ0NDU1NTU11dXVreXu fklJSUpKSkRERHx8fHR0NJfLbdeu3fDhwy0tLdEqheYZ548fP3769Kkozg0NDTt27FiXOI8WQpy3 eGFhYVFRURMnTkRRfMm/zQMHDrx582bx4sVfcex6YmLi77//rqysPGTIEMEr+vr63bp1E/w/Nzf3 8ePH4ttbWlpqamoK/h8eHh4fHy96i8lkinZCCPn333/FP9i+fXvR2J/k5OSwsDDxd+3t7UXDUl68 eJGeni56S1VV1draui67jY+PrzIJxJAhQ0SnrKCgoJycHNFbWlpaok6/4uLiR48eiX+wW7du+vr6 gv9HR0dHRUWJvztixAjR/+/fv8/hcEQ/GhoaipKNjIyM58+fi3+wX79+otF6YWFhycnJorcUFBTE 12Sr169Zx9LjcDj3798X/2CnTp1EPVS1/5q+vr5FRUWiH0VB8u+//168eJHH41VtEFMUTdMMBqN/ //5paWnR0dHz58//imlYYmLiwYMHDQwMNmzYgKtY8xcdHR0YGOjq6lr3j6Af7FvCZDIHDRo0aNCg jIyMoKCglJQUPz+/O3fuEEJkZGTU1dVVVFSkpaXl5eWLi4uLi4s5HE5aWhqbzSaESEtLW1hYODs7 W1tbi65GAM0zzu3s7Ozs7DIyMl68eJGQkBAUFOTt7Y04B/jqf5srV6787bff3NzcvlbzNDY21s3N jRBSUFBw9epVQghN09bW1qIcLD09XfC6AE3ThoaGorPBkydPnjx5InpLQ0NDPAer8kEnJyfxLKLK u5aWlqIswtfX9/3796K3TExMRFlEcXFxlQ+6uLiIdhsVFVXlXXt7e1GD+8GDBwkJCaK3LCwsRDlY Tk5OlQ9qaWmJcrAXL16Ilv2gaVpeXl48Oblx44ZoKlqapgcNGiSqyuTk5Cq77dSpkygHe/LkSXBw sOgtPT09UQ5W31+zjqWXm5tb5YOqqqqiHCwiIuLGjRuityiKEv8179y5k5mZKXpXPEhqJOiT4PF4 vr6+2traurq6R48e/bpxLljEEglYS4V+sG8bh8NJT0//9OlTRkZGSkoKh8MpKiricDhMJlNBQYHJ ZGpoaOjp6WlqajaTkc0ADYvz3Nzc+Pj4KnFOCFFRUUGcf5/QD/YV/x4FvWHjxo2ztbX9kl8dEhLi 7u5uZma2cuVKrC0BDVNjPxiDweDxeBoaGlZWVra2tvr6+hwOx83NLSQkZPTo0QMHDvzycW5sbIw1 VL4h6Af77jCZTH19fdGtL4CWGueampro1wJoJn+PK1eu9PLy8vT0TE5OnjhxorR0k7cluFzutWvX fH19+/fvv2jRItQCNIao+0FKSorP5zMYjH79+nXt2lV8BKlgEUsvL6mDFlYAACAASURBVK+rV68m JydPmDChAQ8nNzjO+/Tps2LFCtRUy4YcDAAAAOqXhk2YMMHQ0PDIkSPR0dHjx49v0vFacXFxFy5c SEtLmzZtGiYnAInkYBRFSUlJCfKuzz02LIrzkydP7tmzB3EOyMEAAADgK+vdu7eent6ZM2fc3Nws LS1Hjhyprq4u2a8oKSm5fPny06dPjY2Nd+3ahUEfIBFaWlp2dnZ1fGy4d+/ehoaGJ06ccHNz6969 +9ixY5sizq9du/b48WPE+XcFz4MBAMC3B8+DNR+PHj26du1abm5unz59hg4dKpEWalZW1u3bt4OD g1kslouLy6BBg1DOIBGCZ+Yb8MGgoKCLFy8K4tzBwUFHR0cicX7v3r1nz54hzr91eB4MAAAAvijJ LmIpWtxPXl5+9OjRjo6OmJYAJKjB0wxWWcQScQ6NhH4wAAD49qAfrBkSLGIZFBT0/v17weJ+HTt2 NDQ0NDAwqKWdKlrcLz4+PiIigsvl6ujoODs7S3Bxv+KwbX27b05b+CT2b6t6tXPLYtyG9vnD+kHI Lz3QPoZKcS6+WGt94zwqKorNZuvo6Dg5OVlbW2P2+RYA/WAAAADwdVRZxDImJsbb27u4uJgQ0qpV K3V1dXl5eSaTKVjcj8PhcDicpKSkpl7cjy58tm3S5teEaNe7rR17bNbad6OuXe2OBAw+G+cfP36s b5wLUi9M9vudQw4GAAAAkqSpqenk5ESEi1jGx8dnZmZmZmYKVvbLzc1lsVjKysosFqtnz55Nu7gf neu3ftKvUUxCOPX8JD/9xur1T813uDuoUoSQ/HtO2sPidn14ubKdNJ3/fJfzmJ+9U+jOW18Hb+os I/hEoe/U1vbBP0S8+dmcJfjy/Oc7hvTfFN7/98fXV3ZVoBr3q/Dz33ju/WX/6TvBCfl8Gd2eoxdu 3fu/EQYyDSgU0fF3WrpO1u1PkwefLjq0kmy5F0Zcu/DR0nV4a0bGeRudhW0a9hUlLzf2W0Ad893e U+GbiPO8vLyUlJSvEOeAHAwAAABA4GsvYsnPuvfDlD+LJh7c8H7F1rR6fbTs3eGN18scLkwyrN5S yvXZuMVbbv6puy6dOpuwPpeFFL3e72S/6W2/vY+9Gp+A8dJvL7EecSTPbtnGo1u7avISH7vv2DKy e9iZMM9pberblhM7fiPZ562Yqm1ZEi74sshDzhNPTgibMby1tHynaT+uUmnYV8h1W7m1XY/5hyYH re8ogzgH5GAAAAAAzRsv7cayaSfp2XcOjYobXs8Fb4tD/z78XrrfZgdNqeqZHTs3j69uO3X8UJvP 9s6UvD88YcAPz3vvCbyx2qJVIxMwQmc/WDX9SPZ4jzcXJuoLWm4Ow4d2ps3GLV/nM/LsEJV6fUHl 4++1q09TFH7FbAMKFot2WTR0N1Iag9dPWTX4pztzr4ypoSoAvl2IZwAAAGhxuMke82dekF98ft9Q DUZ9P8x+f/lmCuk0po9a1XZSSfBKAz3X57ysf/q3oqxOp/Jr+HRZ3OnpAxb7dtnlf3NN94oEjJcV uG9KD20mRVEKRg4rL0QV06Tg0SwNymzHu7LybfJ9pmvIO5xLqbRbOvPh75ey26/aOka/4ta5lPbI /VevXFhrIUdIWdKdLWM7q0lRFNXKeODKC1ElNCF0xvl+8iZLf187zKQVRVHy7YZuuJPCrXz8p96c 7cdQcvEpJITwU09bybdfssnFXIGSMlrgF3u+n7zJkt9WDzaSoyhKucu0oyEvjrn20mRQlExbx51P cvmEEH5+6NGF9qYqUhRFUQqGDquvfCzjJR21Nt8YyfuwvYtspz1Rn86LvqLG4ySfO1TB7ylrPmWS 8r09Xkk8xDQgBwMAAABovjjxp2bNu6Gx6sIuO5X690Lxs8P8E4iqhYVWteFCcj33Rsce6SWlPvNh Zon/dJ1q7ShOouec/rOu5Nod9ljbU7Hiu0sjfhs6cHOc/T7fiJjwW2t0rk3rv/BOlkKfBRN1Ik97 RJcSQgidG3TkVqndkiGVd8uO8w/nqPW1rTKej6lvP25oN22Zoifr7Rx3xg7Y5/sm4tmpybyTU/rN uZnOJ4SQkg9/HUyd6BlbXPjhjEP4LpeVD8tqPf6SaLdT1CKPu9f+WN69FSElH9z+yHG9ncrOeDSn 6NyCXkPOm+wNzc+P+Ktz4E/zjsZw6Fyf5UMW3ND+4UZEfFzEo9/6ROyfsexunv5c37At7aXarQ/O Df3BRDTnX+Hnj7PGQ80TvCFjPMRaLtjdN52PsAbkYAAAAADNVFnU39OXerdZd2GbtVJDxgGWpb1P I0TDWKOGOcMpaRlZphRFScvIyrKqt6KiDoye7qlgZcDx3bjDL6di+Z+iZ3v2hnXd67FnWj9z4472 S9yOjGNf2HkrTbb7vGkGMe7nI0sJoXP8D9+lBy+216h80Lzi7CKipKNUY3cene3zy9+xPfd5HXId 0Nnccvz2y+5O7IvbLicK+pH6bv11Vg8tOYV2IxZNbF3wKjiFU/vx9/xpz5KRQ51GdhKkj5abd0wy V5bRsJw4VJtou+xaZddaQdFszPSuUgkhiaV8jmy/1X9c+HPeALO2huZ2rmtd9NkfIrO4UiwZaYqi pGVkWQyqbsdZ06GWdw7KGvVty414FFOCwAbkYAAAAADNEj/18uK1gaWtTfM9tqxds2bNmrXbPeMI yfQ/uH7t5tORpXXYQ2kBmxAZBVYDEriSLj8/euZz99deyX9PWX03s7zzhpsWGprFC17UVpoSUB1+ OZ/7MSy5VLbTLFfT+HNnI9h0ps/hh9IjFvdXq/K10kq6SqQgvaDG0XiclJeR7NZ2/XTLu+wo1Z7D 25PYp/GlhBApJcO2SoKmnpScihzFYXNqXRWWUjQ2Ua1I9aQUDQ2VGYQQIsVSYEmpG6oxCSGEYsox KR6HTzM0beYsdii8svvHRdPHOHTvMOBgMp/P5dP1Ps5aD5WhpKdK5cRnliG0oSXBnBwAAADQknKw 4vT0MkKSbrn9fkv89YiLhyKkh9qtntnhv6bYk5JVliOEXVBK1/vLjdef/MlaRYascN99ufOP05aO ijg3TptBaJrHJwojzz492LdisTGKqaInS1jtp87vvOPQmdeLLQ/7KYy9Y6VcdZ8yRnbd5PYF+SWU 9TcXG45Y+nan4+yXw9aaEFIpaaP5hBCKIoQQSopR+Wb7f/xCFIMl/fkfy3dagZt8cXL3yTdUh013 shk0e8qa5TdcnH0/s2uapj9/nLUfKiUlRRGMRIQWBv1gAAAA0IJIt1v5mhbH/ejWnRDthU+KaM7d Ecr/vQeWTkddQjKi0+vf9cJgSlOEECJjvtx9j2Weh+t8j2QuIUzNrp2Uit6+KdNt165du3btjNQS jqxa7RZaSBPCNBq/sHv61SPH3J6pTZjXq/oqWpSKzbLx6pG/b7mRUtEVxkv9d/ten0jSoVvfDrJJ /s/Sysf00bmh96Potr3aNP1c7tyka79eLhh+Mej28T0/LZ02rAMnNpNPC7rBKKpKxsfS69nA4+Tl JWXz1Yw0WAhtQA4GAAAA8K3Kvz+pjZJm310RNQ9MlFLtZm9E8l6FpHIa/h0yZkvd9/QpujHP9VQ8 hyhZ/7jMPP5X5zl/PgyPe+/317zJe7yL25sqSxFCpNs4LbFMPrkzQHPKbAv5GnZFqTj8emSqjOcE i4FLfr9w+6H39WMbxlg6e5LRh/YNN3HYMN/gxarxa88/jYwJvbHdZZYXY9yG8QZNP9JJSl5Lk8V+ e8c3KisvLeL2zhmL7peSsuIymjDkVOR4yX7XbwfFFpUnYpSqfQOPsyQ2KE7a3N5UDnELyMEAAAAA vlU0OzO5IDM1/3NPR8mYjh3TmkRcf5zZmCFwMh2Wnv7NquzBkhlHosvke2zxebCjZ/iWIZ3bmQ/a ET/40COPmeUJCEN3+GJbJjGdMaOjbM27Yug6/xPqs28E/962qSMGDR6z9FSK1daboZ4z2zIpRes9 /jfX6Nxd3NfMtMf0cwzXc0/cx+symr4UpbSc/j45X9drgpmGisHgbdHD3M+MVkx5/i6Pz9AbtsRZ J+jncS773wqn0mjocbKjbgWU9Jphh+XBoGWhaLqug50DAgIKCwuHDx+OUgMAgK8rLCwsKipq4sSJ KApoEmXvfunecbP6Px8fzdJv+nSGE7WnZ7dzM14FrzFlouwrKX6+stOolD8jLo5Qp1Aa0FxFR0cH Bga6urrW/SO4qQAAAABQGavD3G1O8gH7zsY07XR8vMyXd66e2rLgl1jrHya3QwJWBT/zwZ7Lqis2 D0ICBi0NcjAAAACAqg0k7VG/bbeK2bfjUQ7dhF/Dz/HdNMl1X/LIv466fIEOt29MyeuD2xPmnFjZ UQZlAS0N5qYHAAAAqIZluvCfXZetV+0LC9nRvakmhGCarn7BWY3Crplct+3Bz1EMgBwMAAAA4Hsh Y7YyIHslygEAJA5jEQEAAAAAAJCDAQAAAAAAIAcDAAAAAAAA5GAAAAAAAADIwQAAAAAAAAA5GAAA AAAAAHIwAAAAAAAA5GAAAAAAAACAHAwAAAAAAAA5GAAAAAAAACAHAwAAAAAAQA4GAAAAAACAHAwA AAAAAACQgwEAAAAAACAHAwAAAAAAAORgAAAAAAAAyMEAAAAAAACQgwEAAAAAAAByMAAAAAAAgJZG uu6b8vl8LpdbUFCAUgMAgK+rtLSUz+fjkgQAAF8dm82u70comqbruOnly5dxtQMAAAAAAKjC1dW1 7hvXox9MTU2NyWRaWlqiiAEA4OuKiYlJSkqys7NDUQAAwNeVnJz85s2ben2kHjkYk8lksVi6uroo aAAA+LrS0tIYDAYuSQAA8NUVFhbW9yOYkwMAAAAAAODLQQ4GAAAAAACAHAwAAAAAAAA5GAAAAAAA ACAHAwAAAAAAQA4GAAAAAAAAyMEAAAAAAACQgwEAAAAAACAHAwAAAAAAAORgAAAAAAAAyMEAAAAA AAAAORgAAAAAAAByMAAAAAAAAORgAAAAAAAAgBwMAAAAAAAAORgAAAAAAAAgB2v5yiJ3mVOfJSWn ZmAxxHX71feFdIO/ovTNRmPhDvueSeN//sVvqGQohoKGoYW9y9qjASllCCNJ4CaeHq5AURRltC6U LR4/SY/+WjW2d1sVFkVRlJx2p8Fz996NL6HrWlkMebU2nWynbvZ4my8eZryEv3sIN5Fzupdf9XA4 H8+O1xDbjeZ497gyUhaxrf3nvkhWzaCL/ZT1J4NSq0YEnXtviipFUVTrRY9yaVQ1ADTra5ycponV 2JVuvsmlX+vgSsO3mFIURXX5/QMHVQWAHOw7RLNzEl8/OLXJ2dxivlcKFwVSgV+c9fG1r8feBQOM HXaGFKBh3djyTPNavuxuMSHEcs2CLrLCV3MCfrIxdlh6wCs4IY9DCCHs9AjvE2uHm1r/6J3Jq9ue S3KSIvzPb3Pp0sXVM6lul3N+lveawdOvZAl/bjXokN+ZGUas2hsNOYlvfS/sntOvdY9FVxLE8zBK xXbtAkNCSPJh163PClHbANCcsTM/PPM6uMTexH77s3xc3QCQg8HXFHt8ykz3BGRhNSh5/JPzpmdF KIjGKHz6yyqvAkKIzNAfJrSVLs+Esu8tH7szuKZ+Rm7YXqfp55PqF5AJ7lPG/xX9n92WdNGrvaNH HIoW/szss93n6tKOcnX+Hl744fG2K72zxbrdZDvPXWZBCCEfDyw9EoX7ugDQbPT69W6gUICfz/1b l07sWTGsDSGE/WST8/pA3GMEQA4GTUze8XRoZGRkZOT79+/fRYS/fhl449DcLtLCVOPBzuPvSr/P kpEb/Ld/cLkXL54/fex3+/Rmpzai9z8e3eWTjctUg/ESPTccTiKEEMVRywdrlp9OeEmXt50r74pS GrjDO76QU5Jw/6feTMFLxXe3HXtfQ0AqDD8aEBwcHPzi2ZPAR3c8/1o7oqKieM92/fai9nSZ8/Hc zIH/CxJlah1/uHd7Q29FqvqWiqOOBwYHBwe/eP4kwOfO5eO/LLDTEb0Z//e0//nlVcQE02jiMmsp QggJ2fWLHwYkAkAzIa3eyaqfkM0A+8Ejxs9ee+DW80vjlAkhySd3P8TVDaBZ/w2jCFpCLSq1MWnf vpXYK1269+lMQtotDyWEEBLrH1lEush8hyXDVO/QvWdP8ZIh1gMG9mZ16/jTO0E+8PJRHHuUmhyC qCFK3x3f7cchhBBlx3n9VMvTHTr/zZ0IwaVfyubA6XUD9RmEKAxe9+vEvxzO5RJCSOzjDyWkc9WA ZGl26N6zp4LwR7th48ZbTzUb65FDCCEk3edeXGm/zp+J4qpjEA3meD3cba9W8z0mGS2zbmJfZD/M 2XXxtPXW/fcIYiLtxE8Xf/ZfYFB+cmToDZ/fjxEUwCNZ57Z77bSfpc9AzQNAM8XQGbZ0hPLV83ns t48TSseoy6JIAJop9IO12LxMs0tHFWEtS0tX6g3g57+9uHGyjbEqk6IoSlbd1MZl3emQbF6jvpBm J3gfXDKql5Eaq/zpYBk1w56OC3+/n8CuuBeX9+8wZvm7I25nfLyyyra1DEVRLHWzMYeEfSNNcnji bf021t2VhT+U5JZUnVeEm/HcfeM0O3NtOcGMDeom1uNXH/b/VMNYOF5uqPvaMT30FCiKohQN+k7Z fiueXeg3XbW8CKxOp/LrUUTcj3/3Kn+HNeRypqjYyt7/YiZ85rrN6pAS0Q5zbo6WL3/ddPPb0rp9 C5113UlBuLseh2IrjwvMuzdRufw9pt2ZlNomXSl5dfS4YOCfgv0MS1GRUqojruWUZMSE+Fy/vn+0 jjBjoWm+8BeSV1WoSx7D0Bq0YJiS8KeM6IzPDAWsOgZRc7y7n5uTTj1uMEmp2Gw6sVRPuL8nx24l V5SKlPbAGT0F1e1/6PJHjOsFgGbdrpNTkiWEEJYCq/I4AH7eG8+t0+3MNGUpiqIYim16jFr6x6Mk 0agEbrybJUVRFNPhXGq1U3/pm5+NKYqiuu6NFp6J6ZK4e/vnO5jrKFAUJaPVdfSPZ1/n81ABAHVu OdeZv7//7du3aWgeSt/vNBNWopKLT0HV99nhO0Tvd/o1skz4Or8o4shY7ZpCQdF+97NcnvguXv/U TvimlXsq7/Mv0vyC4B19P9fRJmO9K6yofJ+5t4aWN42l+/4wzaBiI7kR1zL59Tq8hpYMzYn/q6do t2a/vCsVe68s+eaqnp+5b2g6+3xMiXj5xJyepFc9w7Ncs3uUMHHocypFeMh1KqKy6L2dhb/vxPt5 5R/lJZ/sW7Ft1wMfOOVvFDyarlr+qsHalyV1rojc+1OE+TnpflC0O5qm6bz7LsJkSmaoR1ptBV78 fLl++SV/wLnU2quGl/dil7VwZgy1qXez+dUrS3WGX2GVj+V7T1QUvq08RVCX3I9u3YWvyY6+m1cW f8ZZveKXbDXkj4jiGqIifKupcBONOYGF1bcoCflBFI/MoV7Z4lFRcZQ9/ozj4OzTPISGhnp4eKAc 4Hu9+ksPvZVbw9slrza1J4QQnUVBRRWv8vNf7h+hVePNri7Lb34SnNa4yacGMAghUjYnk7jVTpBt CCGkt1t8+bbp91Z2rn4b33iYvQYhhHTeF1OGqoLvSVRU1MmTJ+v1EfSDtQTc/MSYqHKR7yNeB/tc 2DZp6Mb35XnI2M0zjMsfxeFn3V3qsOBamqjHwsBQS9hiL3i0btAMj+SG3MQqebl94sYnwptpLG3j DqYGqqIbcKVBm364UW0We+6TfWcTKtKDAa42alQTHZ7wHiCnJD899vmF/01YHSJ8zWjMCEPRpHl0 wdOfB43aH8Ku+fPRJ6f0db2cUn4ExSHbRsz0+CR6V16vnaG6FCFlz/euu5nfwCJiGgyf0L789/W/ FlEs+G9+qFdYxZ4iboaUP5VU8s7LRzBQj+iOHm8mW+eKULZePFGY6Iae+jexomsn/8Xpu3mC/yoM WzxQs5YTBCfB+35y+VXXwUJV6rObXVzq2NtIq/f68ke1Oiy7sH+QKlWXuE66cfBOgfAn3U661ac3 5GVWHoNIWe07tsi8QUNLZQ37Ggt/CU7cK/GVC5it+1mWJ7thnkF4xAIAmh9+WWHGh6eeW5yHbosi RHnMvg295UVnyjSveYNW/ZtOiNrAjVffZJXRNL84IcBtlhlFeG8OjRq+61UJIYSh47h8iCwh/MDD NyvPnFQcduJ8IiGMAUucWksTQnifPOc4H3jLJ6S967HnaaU0zc2NuLa+f6sPdx9loi4A0A/23fSD 1UKuz0++WaIuipKwn4xF3QqOf4bm82iaLkt58JOlsHWrv/xZUb37wQqDFukLe2+GH3lfzKdpmuYX vtzRVbil1vzHRVX6wQRdS1N/PXfV4++fZq++ncGr5+E1smQIIUR7xg2xnh72m63mFS3yPj94vM4q o3kFsQ9+HV3RM6c84XoGj6Z5KecHi7qbmL03+qRxaJrmF0Wdm9lW7AtE/WB1LqKS0P8ZCu8n/vyG TdM0XRS0sFLPoOoM38IqXTuacwIK61URJSFrRJ0+3Q/FCrt28n2mqwl/0Ul3c2srZn7GJYfyAYWs 4TdzPrtd/oPxYs/jmS64kcL9TGXJD/njQWBgYGCgv6/37Sun9y0fKP5rG/4YKuiEFO8HIwz5qnWq v+hRLr8h/WB0gc9k0XhKzXmPxQONG/+X8DvVZ/kX4vSDfjCA5nv1Z5i7nooo4ot3Yq1tSwgh0tb7 37ErjVDIvDtXjxBCWA7uyVyapvnZt8crVR8hUeA3W4MQIjPUU3DJZL/a0I4QQlqNPCfeYcYveLau /C4i+sEA/WD/CTlYy87B1G1XnHieKTxFlgSvai3sL7A+kVhx5ix9u0XYQNVZ9KSovjkYTdO84rTI Z/c8L/gkV5x22a82GAm7uUbczqueg3XcWWkcYD0Pr5E5WKveSz0+iF+NCgPmaopSldn3s8UG15W8 3SnKYojV0QQuP/PyYKbwBYu9UWLXmoKgZfrVc7C6F1HxM9FzSRYHYzk0XRqxvUPlQ2+38TWbpjlx fwjzApUpD/PrWRGl4VvbV0vCCnxnCUf1qc98lF9rMbPf/CxMmNusDi753GbcxCM9Kx+9Ut8f76Zy 6pkwq066JsyWK+VgNTFa/aSA34AcrDDAVb3qwEdRJnnXSdi5ZnkimYfzD3IwgGZ89dfou/h0uOg8 WPJScM9Nc65/QfVT9PF+UoQQqt+pTzyapul8X1eNqs8w5N6frEIIaTX2ZhZfcPrfZEIIIbqLq16Q eSnnHJjIwQA5WJ1gLGLLluV3cI6l+fgTMaWEEF7my4AkYRO7DYl6+ljoxSdl4Tiv1CfB6Q2YdUBK Tqu95ZAJLvY63LT3QbdO7f2f67De9jvjhKPKyrjVB3CZTR3bjiU+rKzuh1cWc3rVjKlVzN39vE6r 6LYZ94vH06SMZ39MbCf25FRpzO2HGcI+l9nLB4gPrpM1d11jIxw999LrVUHpxyfvhY8ld5gwoi1T LLezmDxSqxFFJNdp4jANwUtvLj/O5PMzn/4bKeja6t5bMCAu9t6TdB4/M/DSq/KvHDith2I9K4Jl OnWhhXA44j+3ErmEkKLQM7fKR/VpT5jfW7HWUuRkfBCOOFHWV/nsFBtSaiMvfswqKkh5eX6phTQh hOQ/2eM4cn99VktQtNt178horVpOVoYzdi8T9WHG/T57T1hxA8YEcEpFkc9gVZ7GhqGsJ+wjy/yQ iWXCAODr67nzlq/Io4cP7nidP7xzqaMxg2Q+cZvZc0T5RFf8vPCgBEKIjKVTl1bV+sy0B4w2I4TQ 7/1iSgghRLH3gsl6hJDwEx7lizLSOYGHb+YSojpmyQA1ihBCF773jyWEMLsO6VBlKIKURp8RHVAz AHWCuelbAiUXn+QL9q0IIYTmcznsopzUDyE3D65e5R5JE0IyvOZPO2oXsKx1VpzouZlMjzkDPWrc WVpkOocY1jswSpN8jv124KTnndDUGlI4Sqp6A5qh30lH/AEfbj0Oj58WcPbM+aqjzvuN2v0/y0qX GKVJ9z+620hlxz/3/GXhinMfCCGEJF79+4rjuFGWlT9clv5e9ByaYW+DyvNaSCm376pNAlMJIaQs OTaHLZeYK7rhaKzBFN+WpW2mTUh6g4tIwWLyIOWTF/MI4QdfCs4dQXkJUi052zVr5BZOulRAyJub r/LG054vBM/YydpOq5iUsM4VwTQcv6TvD/Of0OVJ2KJlWmFnbpYXaespc7or1F7hfHaucH5GmVYy n82PKHk9EwNCCOk+ef/1vGCjRU9pQvjBu3YGLTxjr1h7Wq+qZ9TZxmnOD2um9VKrZR5FnckX/I5P Unny8Yrt34Ln895tn3PI5cm6jvVbjoGTmybK4VX0lCv9CUjJKgp3VpLP5uOcAwBfvf2m0dXG1la5 8otOk+evmL93YI8fn7L9f1x2eeLdqbr83KQcQghRN9Kq4ZzIVDfWJISQvOQ8wSVDvtvcWUZ/7IyL OnU+8scdXWToTB+324WEaE9caCWYboqXm5DJJ4Qot9aotkNpdWMtKUJwkgT4b+gHa2EoKWmWvLJ2 ux6OK07cPtBD2F5+5ubxoaxue2DXv4lJF73caW8ycNmhm+XtfpZuV4dJSzetH6UhOiyq2iQM8hqK DbgFUM/Do6SlWXJKOuaDlp8O8JwgfNYpyXNu/5meydzKJcespZ1P02L9eBRFKCnR78Pn8atsyqcb VUSKPafZCe4tljy+8jz45jNBrmMxtn//cT0ZhBDCfvFvyNNLgYLXmTbTrcunuKhXRTD0Ry0bWJ4E h/5zKzHv9dkb5Zmj0fSZXf57XguK1FK7NTUYdAcMNyn/f87zgMSqAVllXkRecXZiuP+FnTNrTcBU Rx0L+MfFgEkp9du0f7QoAQ/9ee6RmPp1V5UmhcQJZ3xhGHbXqzIBSEW5SeOsCQDNtxUg32XR7mnq hJAyP/dneYKrUm0XcD6fEEKkmIzyk5yM+Yz5HQkhsWfcw9mEvFt+dwAADnJJREFUn/bA7QGbkDZT 5/Wofmeu+o6lpFlYQhEAOdh3Tlq7Rzdh05t8epNSJq3SWjQjuenW8NKah6dmnx6gUL8v4nw4Ou+n 8sn4VIb9+iC2oOTTq4cX/9jg0kU0Qo5RvZHOkq+8dklTHZ6w6azr7HZmhuiJr8xLM6cdjxVrpTO1 TIVv0vEvEioPlePnRb1OLf+/rIGxqqzYsaa8+VRp49LEsORGFRGl0meajSADyLpzyO2OoHuu/Yi+ 2pqWTp0IIYSk3fn70F3BlIhSVtMHaEg1pCKktIcsG64gTMI8b5+6Xt4R2GH2dPP/7EJiyKsp1JwX cz49OvPH7p9XL5jqssrrk9hEljS3VPQTp5QrgekFmUNOnJpjIjhWhs7Yvdt6C3897pP/LThdn7W8 yj54XY4V/tB5dA+VykvqsfOFs2Uqaiti+AAANGOybSz0CCGEk55cwCMMlTZqhBCSHZ9Rwxjwsozo DEIIUdFXEZ7ZmMYui3sRQhI8zoUXpT046schxMTVtbPwzhxDxUBTihCSm5BeWvU8zi9IzcJobQDk YN+5sqTHz0Wj9RQ0FBgMzR59hDPNxdwJTK1oHZfFemzf9OvhC7eDwpPy6vs0GJ3z4urL8v+brNi7 YpBRK0FYlWXGZwvTiho6ShjSUpUfuanH4Sn0O55RPT8LdNGorT9GSmPYvpNTRWlpqe+q+e4Jot9W xtDBSphXxf/zh3+OWFrBfndq32PhYfZ27tZKxtCmkzBLife8GFFScQHKeOh2I6dxRUSp9ZtmJVWe bHkJJvDXdhjYliWtZztEMJ3hx2v3yh9e6zXNvvxJqXpXBKVut3RM+ZzroZuXn0wR/LfLvEkmrP9O f7Q7CB97y03KFb/mcuIvrlm+fsf+o+c9Dv16o2Li+7L4OzeFWY60kYUuq/ExzpCVF3tui2k6/8/V hqJK81m1xLOuaxlwEjzW7Y0UlovVwjEGlfMsbk5CjjCXN9Vk4uwCAM1XafLbFEIIYajrtJIiUsod rQ0IIezn199We2aalxZwK5IQQkysDUVLY0q3GbNkAIOQxCsXA+6cDOQR0nne1A6iO3OUYueBpoQQ 7ssbr6vskM5/c/c9KgAAOdh3g5MT8+a1yKvQkKe+N47+b7TturfCLRT7ObaXJfJdZ00sn3OPfrpm /l+vCmhCCCmNcV86b9P2dYumjOjXud+OVyX1TcJ4ooZuYsDT8qeQeNmPf1/nmSc8QnYNvR5V87Im OrxKWdjwfUcniHqw2A9Xr/QS5XqKfZZNF85omHbCyfF/l95mcwm/KP7hby6DNrwuf0d96sbRugxK xXrOIOE9wbhfx80/+SqXR/hFH279PGbypbzGFpGUlt203pV2INdnpLk8IbKmjv1VKr1hMWWQLqPB FaHUd/EknfKLdmZ5stRrgbNRHZIMlm4Ps/KnsdPfVeoJlO86dVR5lyL/6bLRy04/T8jN//Tin8Wj 170R/jqDF9iqU5L/S1Dote7QJOGy1aTw3yWrb6RXH7pamv4+LEQg+Pnjh9f/2T6zb6cZokXdtGf/ MrlqCpYZKewZNbAyVcApBwCaLXbkyZ/OZBJCSE/nXsoUIbIdJ09qSwhJP7X+n6hKXWH87Ee/bH1C EyLVd6a92HqQDF3HpYNlCfl4dseeQB4hvRZObCd2WWAZj5/dhRCSdW7jqWjxUeVl0ae2XitAFQDU sf2Muelb8tz05TpsDC0WTEObfH6k2KQVrDbdrHp3UBNrk4/x+CSaE76uc9OXhm8VmwdJvuPQSVPG 9jeq3IgVTtIuNje91vygqtPM1+vw6lIySi4+Vafi5X7yGKNUsUvtud45wgl8eRm35+jXWpD6rjfT yg+g5NWWzv9Z8MJfuz5FRNM0TXM+HLAQf7PvScGE6PwMz0HiH+u4u2L64Pp/C03TJS/Xtq2Uplof T+TWKQK5H92Es84LVzITHX388cG1PE8mM+BQVGn1yqryPFgt3yuam1529N28Km9z4g73F2sraM68 k8mrMjd9rdouvJ9Zbe75gocu5TGjOOF+Hs4+mJseoBlc/SvNi+jr+8jn/q0Lf66f2KW8P0t3vo/w 6sZNuTxBcHdKY9jWm+/zuDTNZ6c8PTG/i+AC0eF/z6qs6MHP/ne8aAy7zcmkKpcFfrb3PMEtUx2n vT4JJXyaX5L4aN9YXeGZFHPTA+am/0/IwVp+DqY67I/w4oqZDrL8NvaRrblpbLkxQHxVrDqvD8bL vL/IsPr+mJ1GDRQ+YiVc16v2HKxeh9fAHIymuUlnR4hlesY/Pq9o+rNjL87rWPPjPoxOi698FH9K rfTD8dEa1TZrP/e3haLC6HsmVXBdq0cR1VS/Zr8IV1LjxP3RreJ1k81vxY+o3t9C03RpxHaxL2I6 nE2p6+pXpRE7ylM+yuZMlU/xMn039q2xv0jRdltAxarhks/BaLo47GfxuZH1F/nm8uuWg8l0W1K5 iivKqHwxNWmH86lYHQw5GEBzv/orDNgVnC+WVvHzgvcOUa1xEJTp7IvxNZz38h/NFKyYKDPEI636 aY9fGPb7YOVq+zOYML8TcjBADlYnGIvYYlFyGiZWzmuOP426ubRjRaeElNqA7f5xAUd+GGfVTlWQ bFCKbXqMXPbno9iA7TaqDYkIKfXBf7x4/NfCgR0EM9ixNDsOXrDf+0PIhR3jy0e6pXq5hxXVZVdN cHjVkin9SW6HhoiK5MOeBX+KVquSMZp0NOxTsMeu+UO7tlGTIYQQlmq7vuN/OBKYFPrXOAPxZ5hY 7eZciQj4Y9FgM3UmIYSp3slx9elXwYeGagiPUkpWoXzekXoXEctwpLMo2dVxGCj8Zmnd/sONRH02 45yMWY2sCJaR40gDUU4zaNEQ7bqWMct4jIsgr6Hf/FvlMQMpddvtfh8Cj64e07utohQhhDCUDK3G //jPs1jvn23UmvS8I9d19Z+uoslXSPLfs7c/K6xtAhAZdaNeI+bv9Az9FPxn5SouH66T+fxOtCB0 +rnaaeKkCQDNlIyaYfchszaffRH/cF1PRfHHf5V6/nD7w8uzG1xsTFSZhPCJrLph73FrjjxKeH18 UtsaHs9V7OHSX54QojB86aAaTnuUgsWq2zHP/lk7ultrRSnCpxQN+88+EBjiNkwD1QBQt4Y6Tdd1 drKAgIDCwsLhw4ej1OC7xy+KC32b10pXX19XoxWz0pNNxU8WtbM+nEYIIeqz/D/+0795Pz7Efr2p q8V2QYqh4HQ94dpotTo/qMWJ3tur/drXhBCt+Y/jjljLt8i6prO8RrUe+y+bEDlHz/ibE7SQhDUP YWFhUVFREydORFEASF7R4wXGNkfTVKc+iD87SAnlAVC76OjowMBAV1fXun8ErQmABuAmnJtq1d2s rZYiS4rSGn48tvyxZLo40nOfZ/kc71Id7U3kmufxly9qVvbpwebpO6LLX1Qdu9RWtT4zZTCNp60b IksIIem3Lr4tbplVTWcHnnzEJoQQzSk/DkMCBgDfAX76vb0X0gjRm7bMGgkYQJNAgwKgAVhtBw8V Td+RcXeesaqeaUdzE31lBTPXK+UTwSuNWztCp3n+hRU9nteaKSPPktEfsue1sCfcfMX/+ivXb7JC KZ3R2xYZEELIp/N/Pc1viTXNS7l96G4xIYSy3LjeWhGhDwAtV1nifY/LN7zO71/kONWrgJDuq5f1 kEexACAHA2g25HtvOfejBUP0c3FKzLv3Hz5VTMprPO/cn45NMf+6JDA1jZW4ZSViq3pRXdafXNVJ pt57Uuj1497RrQghWR67b6XwW16LJPr0bh8OIaT1kn2u7bAwGAC0ZNzkaysmOI2duvpoCJuQjhuO LjTFaQ8AORhAs/rTUbXd/fTDgz9Wju9vrqcoSsaYqoY9HRf8div61ZGR2ozmevBM7V7WHTUFdzcV 2vQa++OZ0MAdVkoNyRgZOmMP7rVjEVL64JeTkezcXPE3aTabZrPFX+F/UxvQ+Y9/2x9BCFGfdmSL tSKFsAeAlkymTX+bNtKEUCodx2x74LO1F5ZDBEAOBtDsULJtBy3df8k/IjlftHZKWXZc8L+H14ww UWjODXZKdejJ8HTBJPWFCS+u/jrNQqnB5wJpwwWPSmmapsN/Ms9fsqT49m1RbpMxZ06as7Mowynx 8Unu0aPKBulTp4pv8MnauvYNqu/hP7+ivhtkzJkj+JFSsj+RTtM0nXnGUR0nSwBo4Rj6Uy4ncGia nxN+7edB2tIoEYCmgz8wAJAYzRMn0pydCSFyDg6Zc+cqL13Ky8lJc3bWvnKFHRRUePJk64iIKhvw S0rSp07VOndOsIH+y5eZc+d+boO8fft0Hz/OWbtWtIH8iBEMHR3JbqB17hwlK4vaBAAAAORgANDc UbKy2leupDk75+3fr7Ztm0zfvoLXUwYPlm7bVuvsWUJIjRukjhrF0NYWbKBx/Hjm3Lk1b3DunJSK imgDRVfXVlOmiDagWCxJbYCqBAAAgCZsMmF9MACQLJrN5rx7x+reXfQKOyhI1tq6lg3KQkPFf6TZ bG5cHNPcvJYNSl++FN9nWWiotJGRKH1q/AbQzGF9MAAAaCYasD4Y+sEAQMIoWVnxfIkQIp7q1LhB lR8pWVnxBKzGDarsU+IbAAAAADQRPGYOAAAAAACAHAwAAAAAAAA5GAAAAAAAACAHAwAAAAAAQA4G AAAAAAAAyMEAAAAAAACQgwEAAAAAACAHAwAAAAAAAMmpxxrNJSUlRUVFb9++Rak1HYqiUAh1R9M0 CgHg+5Sens7hcHBJAgCAry4zM7MJc7CioqLCwsKwsDAUNAAAfF18Pp/P5+OSBPBNo2kad59RYi3j klTfj1DoSQAAAAAAAPhi8DwYAAAAAAAAcjAAAAAAAADkYAAAAAAAAIAcDAAAAAAAADkYAAAAAAAA IAcDAAAAAABADgYAAAAAAIAcDAAAAAAAAJCDAQAAAAAAfIv+DzoxOSXVkInQAAAAAElFTkSuQmCC --001a1139bb704df92305246e96f1-- From nobody Sun Nov 15 23:15:29 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1891A0093; Sun, 15 Nov 2015 23:15:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FrID0aTctJT; Sun, 15 Nov 2015 23:15:26 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCA111A0094; Sun, 15 Nov 2015 23:15:26 -0800 (PST) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 13FD62CA1B; Sun, 15 Nov 2015 23:15:26 -0800 (PST) From: "Jim Schaad" To: Date: Sun, 15 Nov 2015 23:12:30 -0800 Message-ID: <001601d1203e$2a919460$7fb4bd20$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdEgOw8gVsXNCFnCS9SjCitCtQEMVA== Content-Language: en-us Archived-At: Cc: cose@ietf.org Subject: [Ace] How COSE items are identified X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Nov 2015 07:15:28 -0000 We seem to have a potential problem for how COSE items are identified. Initially, we used an integer inside of the structure to identify it. That is how the current ACE documents are written. This uses a single byte. At the request of Carsten, we moved from doing this to using a tag at the front of the structure. Carsten believes that this can be done with a tag that is in the two byte range when encoded (tag, length=1, tag value). Part of the reason that I agreed was that this was not really being used at the time by the ACE documents. If one is almost always doing encrypted, then one could encode that structure w/o the tag and do the other three structures with the tag. This would probably be ok as it would mostly use the smallest tagging (none) when needed the most and use larger tagging (2 bytes) for the rest of the structures. Alternatively, we could modify the document to request the assignment of tags in the one byte range for the most common structures and two bytes for the less common structures (and have arguments about which is which). Alternatively, we could revert back to putting an integer tag inside of the array structure. Comments on this are requested. Jim From nobody Mon Nov 16 00:23: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 3D4521B2EB4 for ; Mon, 16 Nov 2015 00:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_AFFORDABLE=1, 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 neYC3r_B0erf for ; Mon, 16 Nov 2015 00:22:58 -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 DD3FC1B2EAF for ; Mon, 16 Nov 2015 00:22:57 -0800 (PST) X-AuditID: c1b4fb25-f79a26d00000149a-cd-5649925fb771 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id A3.2A.05274.F5299465; Mon, 16 Nov 2015 09:22:56 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.32]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0248.002; Mon, 16 Nov 2015 09:22:55 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Renzo Navas , ace Thread-Topic: [Ace] Authenticated Key Establishment, OAut PoP Token and Time Requirements for Constrained Devices Thread-Index: AQHRHjC/YzwwStYt6U6wDHPv6QMXDJ6eU5+A Date: Mon, 16 Nov 2015 08:22:55 +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.149] Content-Type: text/plain; charset="utf-8" Content-ID: <962D74E27B248240B82384B8B3141001@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyM+JvrW7CJM8wg937OC2+f+thtnj6poPR gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4faKXpWBVcMW+a8fYGhhnBHYxcnJICJhI vPo4iRXCFpO4cG89WxcjF4eQwBFGiRnL1rJDOIsZJXrvvWQEqWITcJF40PCICcQWEbCU+Hlk KzOILSxQJPGq4RZUvFhi7+VLQJM4gGwjiScrYkHCLAKqErPbz4KV8ApYSCy6+o4FxBYSCJB4 8nAe2BhOgUCJdfs2soPYjEAHfT+1BqyeWUBc4taT+UwQhwpILNlznhnCFpV4+fgf2AOiAnoS K683sUHElSTWHt7OAnICs4CmxPpd+hBjrCUOTF/OAmErSkzpfsgOcY6gxMmZT1gmMIrPQrJt FkL3LCTds5B0z0LSvYCRdRWjaHFqcVJuupGxXmpRZnJxcX6eXl5qySZGYKwd3PJbdQfj5TeO hxgFOBiVeHgNvrqHCbEmlhVX5h5ilOBgVhLh/cHiGSbEm5JYWZValB9fVJqTWnyIUZqDRUmc t5npQaiQQHpiSWp2ampBahFMlomDU6qBkXliytp5Xz+sZ+y5d1Dtxd/jrEtaAn9d+2E/ke11 23GW+X+FjLTW2x48Vdm8Yu8BEUZr3ymdPRYs1+SfT9yRz/SecUXp78DTW0P1H6rFV53+K1mw zOf6ktYjb84seP7lfQzf5nlue3k9+Epcvdqea9m7HxEIiz0UcMDs+cKzfypaXPXmXPp3/J0S S3FGoqEWc1FxIgDUl8qWsQIAAA== Archived-At: Subject: Re: [Ace] Authenticated Key Establishment, OAut PoP Token and Time Requirements for Constrained Devices X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Nov 2015 08:23:01 -0000 SGVsbG8gUmVuem8sDQoNClRoYW5rcyBmb3Iga2luZCBmZWVkYmFjayBhbmQgZ29vZCBxdWVzdGlv bnMuIEkgdGhpbmsgeW91ciBxdWVzdGlvbnMNCmRlc2VydmVzIGZ1cnRoZXIgYW5hbHlzaXMgYmV5 b25kIHdoYXQgaXMgaW5jbHVkZWQgaW4gdGhpcyBmaXJzdCB2ZXJzaW9uIG9mDQp0aGUgZHJhZnQu IFRoZSBwdXJwb3NlIG9mIHRoaXMgdmVyc2lvbiBvZiB0aGUgZHJhZnQgaXMgdG8gZGVtb25zdHJh dGUgdGhlDQpmZWFzaWJpbGl0eSB0byB1c2UgT0F1dGggMi4wIHdpdGggc29tZSBtb2RpZmljYXRp b25zIGluIGEgbGFyZ2UgdmFyaWV0eSBvZg0KY29uc3RyYWluZWQgbm9kZSBkZXBsb3ltZW50IHNj ZW5hcmlvcy4gTGFjayBvZiBzeW5jaHJvbml6ZWQgdGltZSBpcyBvbmUNCmNoYXJhY3RlcmlzdGlj IHRoYXQgbmVlZHMgdG8gYmUgZnVydGhlciBkZXRhaWxlZC4gSGVyZSBhcmUgc29tZSBmaXJzdA0K YW5zd2VycyBmcm9tIG1lLCBvdGhlcnMgbWF5IGFsc28gd2FudCB0byBjb21tZW50Og0KDQoqIEFz IHlvdSBhbHJlYWR5IG5vdGVkLCB0aW1lIHByb3ZpZGVzIGZyZXNobmVzcyBpbiBhdXRoZW50aWNh dGlvbiBvZiBrZXkNCmVzdGFibGlzaG1lbnQgYXMgd2VsbCBhcyBkZWZpbmVzIHZhbGlkaXR5IG9m IGF1dGhvcml6YXRpb24gaW5mb3JtYXRpb24uIFNvDQppbiBzZXR0aW5ncyB3aGVyZSB0aGUgUlMg bWF5IG9jY2FzaW9uYWxseSBsb29zZSB0aW1lIGJ1dCBjYW4gY29tbXVuaWNhdGUNCndpdGggYSB0 cnVzdGVkIG5vZGUgdG8gc2V0IHRpbWUsIHRoYXQgbWF5IGJlIHByZWZlcmFibGUgcmF0aGVyIHRo YW4NCnJ1bm5pbmcgYSBub25jZS1iYXNlZCBrZXkgZXN0YWJsaXNobWVudCBwcm90b2NvbCB3aXRo IGEgVFRQLg0KDQoqIEluIGNhc2VzIHdoZXJlIGJvdGggQyBhbmQgUlMgYXMgb2ZmbGluZSAoZXhh bXBsZSBpbiBzZWN0aW9uIDYuMSkgdGhlcmUNCmlzIG5laXRoZXIgdGhlIG9wdGlvbiB0byBzeW5j aHJvbml6ZSB0aW1lIG5vciBydW5uaW5nIGEgVFRQLWFzc2lzdGVkIGtleQ0KZXN0YWJsaXNobWVu dCBwcm90b2NvbC4gSW4gdGhpcyBjYXNlIEkgYmVsaWV2ZSB0aGUgYmVzdCB3ZSBjYW4gaG9wZSBm b3IgaXMNCnJlcGxheSBwcm90ZWN0aW9uIG9mIGFjY2VzcyB0b2tlbiwgc28gdGhlIFJTIGF0IGxl YXN0IGtub3dzIHRoYXQgdGhpcyBrZXkNCmhhcyBub3QgYmVlbiB1c2VkIGJlZm9yZS4NCg0KKiBJ biBjYXNlIHRoZSBhY2Nlc3MgdG9rZW4gaXMgcmVwbGF5IHByb3RlY3RlZCBhbmQgVExTL0RUTFMg aXMgdXNlZA0KYmV0d2VlbiBDIGFuZCBSUywgYWRkaXRpb25hbCBhc3N1cmFuY2UgaXMgcHJvdmlk ZWQgYnkgdGhlIGhhbmRzaGFrZSwgYnV0DQp0aGUgcmVzaWR1YWwgdGhyZWF0cyBuZWVkcyB0byBi ZSBhc3Nlc3NlZC4NCg0KKiBJbiBhIHNldmVyZWx5IGVuZXJneSBjb25zdHJhaW5lZCBzZXR0aW5n IChleGFtcGxlIGluIHNlY3Rpb24gNi41KSBrZXkNCmVzdGFibGlzaG1lbnQgaW4gdGhlIFJTIG1h eSBub3QgYmUgYWZmb3JkYWJsZSBpbiB3aGljaCBjYXNlIHRoZSBjdXJyZW50DQprZXkgdG8gdXNl IGlzIG9idGFpbmVkIGJ5IHRoZSBDIGZyb20gdGhlIEFTICh3aGljaCByZXF1aXJlcyBhcHByb3By aWF0ZQ0Kc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMpLg0KDQoNCkhhdmluZyBzYWlkIHRoaXMgSSBi ZWxpZXZlIHRoZXJlIGFyZSBzZXR0aW5ncyB3aGVyZSBhIG5vbmNlIGJhc2VkDQphdXRoZW50aWNh dGVkIGtleSBlc3RhYmxpc2htZW50IG1ha2VzIHNlbnNlLiBUaGVyZSBhcmUgc2V2ZXJhbA0KYWx0 ZXJuYXRpdmVzIHRvIGVtYmVkIHN1Y2ggYSBwcm90b2NvbCBpbiBPQXV0aCAyLjAsIGUuZy4gT3R3 YXktUmVlcyB3aGVuDQp1c2luZyB0aGUgdG9rZW4gaW50cm9zcGVjdGlvbiBmbG93LCBvciB0aGUg dmVyc2lvbiBvZiBCb3lkIHlvdSByZWZlcmVuY2VkDQppbiB0aGUgZmxvdyB3aXRob3V0IHRva2Vu IGludHJvc3BlY3Rpb24uIEluIHRoZSBmb3JtZXIgY2FzZSwgdGltZQ0Kc3luY2hyb25pemF0aW9u IG1heSBiZSBwcmVmZXJyZWQgYXMgbm90ZWQgYWJvdmUuIEJ1dCBpbiB0aGUgbGF0dGVyIGNhc2Us DQpSUyBvZmZsaW5lIChleGFtcGxlIGluIHNlY3Rpb24gNi4yKSwgdGhpcyBtYXkgYmUgdGhlIHJp Z2h0IHRoaW5nIHRvIGRvLg0KVGhhdCB3b3VsZCB0aGVuIGUuZy4gcmVxdWlyZSBhIG5vbmNlIHRv IGJlIHRyYW5zcG9ydGVkIGluIHRoZSBhY2Nlc3MNCnRva2VuLCB3aGljaCBpcyBvbmUgZXhhbXBs ZSBvZiBub24tSldUIGNsYWltIHdlIHdvdWxkIG5lZWQgdG8gYWRkIGluIG91cg0KQUNFIGFjY2Vz cyB0b2tlbiBwcm9maWxlLg0KDQpZb3UgYXJlIG1vc3Qgd2VsY29tZSB0byBjb250cmlidXRlIHRv IHRoaXMgd29yazsgaWRlbnRpZnlpbmcgdW5kZXIgd2hhdA0KY29uZGl0aW9ucyBzdWNoIGEgcHJv dG9jb2wgbWF5IGJlIHJlbGV2YW50IGFuZCB3aGljaCBpbmZvcm1hdGlvbiBlbGVtZW50cw0KdG8g ZW1iZWQgaW4gdGhlIG1lc3NhZ2UgZmxvdy4NCg0KUmVnYXJkcw0KR8O2cmFuDQoNCg0KT24gMjAx NS0xMS0xMyAxNzozMCwgIlJlbnpvIE5hdmFzIiA8cmVuem9lZnJhQGdtYWlsLmNvbT4gd3JvdGU6 DQoNCj5Hb29kIEV2ZW5pbmcgQUNFIE1MLA0KPg0KPlJlYWRpbmcgZHJhZnQtc2VpdHotYWNlLW9h dXRoLWF1dGh6LTAwICh0aGFua3MgdG8gdGhlIGF1dGhvcnMgZm9yIGVhc3kNCj50byByZWFkIGRv YykgSSB3YXMgdmVyeSBpbnRlcmVzdGVkIGJ5IHRoZSBQb1AgdG9rZW4gdGhhdCBvZmZlcnMgYW4N Cj5hdXRoZW50aWNhdGVkIGZyZXNoIGtleSB0byBiZSB1c2VkIGZvciBmdXJ0aGVyIHNlY3VyZSB0 aGUgY29tbS4sDQo+YnV0IEkgc2F3IGEgdmVyeSBzdHJvbmcgcmVxdWlyZW1lbnQgZm9yIHRoZSBS UyB0byBoYXZlIGEgVGltZSBTeW5jLg0KPm1lY2hhbmlzbS4NCj5JIHByZXZpZXcgdGhlIG9iamVj dGl2ZSBvZiBteSBtYWlsLCAgaXMgdG8gcmFpc2UgdGhlIHF1ZXN0aW9uOg0KPg0KPiogRG8gd2Ug d2FudCB0byBoYXZlIGEgc3Ryb25nIHJlcXVpcmVtZW50IGZvciB0aGUgY29uc3RyYWluZWQgZGV2 aWNlDQo+KFJTKSBvbiBhbiBBQSBBcmNoaXRlY3R1cmUgdG8gaGF2ZSBhIFRpbWUgU3luY2hyb25p emF0aW9uIG1lY2hhbmlzbT8NCj4qIEFyZSB3ZSBpbnRlcmVzdGVkIG9uIG9mZmVyaW5nIG5vbi10 aW1lIC1ub25jZS0gYmFzZWQgc29sdXRpb24gZm9yIGFuDQo+T0F1dGggUG9QIFRva2VuIGFwcHJv YWNoIChmb3IgZXhhbXBsZSB3aGVuIHRoZSB0b2tlbiBkb2VzIG5vdCBleHBpcmUpPw0KPg0KPg0K Pih0aG9zZSBpbnRlcmVzdGVkIG9uIHRob3NlIGNvbmNlcm5zIGNhbiByZWFkIHRoZSByZXN0IG9m IHRoZSBtYWlsLA0KPnRoYXQgaXMgcmF0aGVyIGxvbmcpDQo+DQo+UmVnYXJkcw0KPg0KPi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj4o TG9uZyB2ZXJzaW9uKQ0KPg0KPkkndmUgYmVlbiB3b3JraW5nIGxhdGVseSBvbiB0aGUgQXV0aGVu dGljYXRlZCBLZXkgRXN0YWJsaXNobWVudA0KPnByb2JsZW0gKFRoZSBhcmUgdHdvIHZlcnkgZ29v ZCByZWZlcmVuY2UgYm9va3MgWzFdWzJdKSwgZm9jdXNpbmcgb24NCj5zb2x1dGlvbnMgd2l0aCBh IFRydXN0ZWQgVGhpcmQgUGFydHksIFN5bW1ldHJpYyBDcnlwdG8sIGFuZCBub3QgdXNpbmcNCj5U aW1lLXN0YW1wcyBidXQgTm9uY2VzIChUbyBhdm9pZCBoYXZpbmcgdG8gZGVhbCB3aXRoIHRpbWUN Cj5zeW5jaHJvbml6YXRpb24pLkkgaGF2ZSBubyBzdHJvbmcgQ3J5cHRvIGJhY2tncm91bmQuDQo+ DQo+Rmlyc3QgSSB3YW50IHRvIHRoYW5rIHRoZSBhdXRob3JzIG9mIGRyYWZ0LXNlaXR6LWFjZS1v YXV0aC1hdXRoei0wMCAsDQo+dmVyeSBlbmxpZ2h0ZW5pbmcgZm9yIHRoZSBvYXV0aCBuZW9waHl0 ZXMuDQo+SSdtIG1vc3RseSBpbnRlcmVzdGVkIG9uIHRoZSBhdXRoZW50aWNhdGlvbiBwcm9ibGVt IChhdXRoLiBrZXkNCj5lc3RhYmxpc2htZW50KSwgc28gdGhlIFByb29mLW9mLVBvc3Nlc2lvbiBU b2tlbiBpcyBhIGdyZWF0DQo+dG9vbC9jb25jZXB0LCBJIHRvb2sgdGhlIHRpbWUgdG8gcmVhZA0K PmRyYWZ0LWlldGYtb2F1dGgtcG9wLWFyY2hpdGVjdHVyZS0wNSBhbmQNCj5kcmFmdC1pZXRmLW9h dXRoLXBvcC1rZXktZGlzdHJpYnV0aW9uLTAyIHRvIHRyeSB0byBoYXZlIGFsbCB0aGUNCj5iYWNr Z3JvdW5kIHBvc3NpYmxlLg0KPg0KPlNvIGZyb20gdGhlIEF1dGhlbnRpY2F0ZWQga2V5IGVzdGFi bGlzaG1lbnQgbWVjaGFuaXNtIHBvaW50IG9mIHZpZXcgYQ0KPm5ldyBmcmVzaCBrZXkgYmV0d2Vl biBDIGFuZCBSUyBvYnRhaW5lZCBieSBtZWFucyBvZiBhICBQb1AgVG9rZW4NCj5tZWNoYW5pc20g LUkgdGhpbmstIHdpbGwgYmUgc2ltaWxhciB0byBhICBEZW5uaW5nLVNhY2NvIHNoYXJlZCBrZXkN Cj5wcm90b2NvbCAoIGh0dHA6Ly93d3cubHN2LmVucy1jYWNoYW4uZnIvU29mdHdhcmUvc3BvcmUv ZGVubmluZ1NhY2NvLmh0bWwNCj4uIENsaWVudCBpcyBBLCBBUyBpcyBTLCBhbmQgUlMgaXMgQiks IHdpdGggdGhlIGRpZmZlcmVuY2UgdGhhdCB0aGUgUG9QDQo+VG9rZW4gVGltZXN0YW1wIGhhdmUg YSBzdGFydCBhbmQgZW5kIHZhbHVlIHRoYXQgd2lsbCBtYWtlIHRoZQ0KPiJtdXRpcGxpY2l0eSBh dHRhY2siIG9mIERlbm5pbmctU2FjY28gbGltaXRlZCBvbiB0aW1lLg0KPg0KPk15IGNvbmNlcm4g aXMgdGhhdCB3ZSB3aWxsIGFsd2F5cyBuZWVkIFRpbWUgc3luYyBvbiB0aGUgUlMsIHRoYXQgc29t ZQ0KPihtb3N0KSB0aW1lcyB3aWxsIGJlIHRoZSBjb25zdHJhaW5lZCBub2RlIChJIHRoaW5rIHRo YXQgdGhlIENsaWVudA0KPmRvZXMgbm90IG5lZWQgdG8gYmUgVGltZS1hd2FyZSksIGlzIHRoYXQg YSBNVVNUIHJlcXVpcmVtZW50PyBTbw0KPm5vLXRpbWUgYXdhcmUgZGV2aWNlcyB3aWxsIG5vdCBi ZSBhYmxlIHRvIHVzZSBPQXV0aCBQb1AgVG9rZW4gKG9yIHdpbGwNCj5oYXZlIHRvIHVzZSB0b2tl biBpbnRyb3NwZWN0aW9uLCBhIGdvb2QgZmFsbGJhY2sgc29sdXRpb24gYnR3KQ0KPg0KPldpbGwg YmUgb2YgaW50ZXJlc3Qgb2ZmZXJpbmcgYSBQb1AgVG9rZW4gZ2VuZXJhdGlvbiBhbmQgdHJhbnNw b3J0DQo+bWVjaGFuaXNtcyB0aGF0ICBvZmZlcnMgYW4gYXV0aGVudGljYXRlZCBmcmVzaCBrZXkg d2l0aG91dCB0aGUgbmVlZCBvZg0KPlRpbWUtYXdhcmVubmVzcyBhdCB0aGUgUlM/DQo+DQo+VGlt ZSBhd2FyZW5lc3MgYXQgdGhlIFJTIG9mZmVycyBncmVhdCBhZHZhbnRhZ2VzLCBhbmQgbWF5YmUg YWxzbyBUaW1lDQo+aXMgYWx3YXlzIG5lZWRlZCBpbiBhbGwgYXV0aG9yaXphdGlvbiBzb2x1dGlv bnMgKHRvIG1ha2UgZWFzeSB0b2tlbg0KPmV4cGlyYXRpb24gYW5kIGZyZXNobmVzcyBjbGFpbXMp Lg0KPg0KPkJ1dCBJJ20gdGhpbmtpbmcgYWJvdXQgbm9uY2UtYmFzZWQgYXV0aGVudGljYXRlZCBr ZXkgZXN0YWJsaXNobWVudC4gT2YNCj5jb3Vyc2Ugd2l0aG91dCB0aW1lIGluZm9ybWF0aW9uIGVt YmVkZGVkIG9uIHRoZSB0b2tlbiwgdG9rZW4NCj5leHBpcmF0aW9uIHdpbGwgYmUgbW9yZSBkaWZm aWN1bHQ6DQo+ICogd2Ugd2lsbCBuZWVkIHRva2VuIGludHJvc3BlY3Rpb24sIG9yDQo+ICogdGhl IEFTIHdpbGwgY29udGFjdCB0aGUgUlMgdG8gcmV2b2tlIHRva2Vucywgb3INCj4gKiB3ZSB3aWxs IG5lZWQgb24gYSBub24tdGltZSBiYXNlZCBzb2x1dGlvbiBmb3IgcmV2b2NhdGlvbiB0aGF0IGRv ZXMNCj5ub3QgaW52b2x2ZSB0aGUgQVMsIGZvciBleGFtcGxlOiBhIHBvcCB0b2tlbi9rZXkgaXMg dmFsaWQgZm9yIHVzZSBvbmx5DQo+Zm9yIG9uZSAob3IgTikgUmVzb3VyY2UgUmVxdWVzdHMgKG9m IGNvdXJzZSBpZiB0aGUgcmVzcG9uc2UgbWVzc2FnZQ0KPmdldCBsb3N0IHdlIGFyZSBzY3Jld2Vk Li4uKQ0KPg0KPg0KPlNvIG1heWJlIHdlIGNhbm5vdCBhdm9pZCB0byBoYXZlIFRpbWUtYXdhcmVu ZXNzIGF0IHRoZSBSUywgZm9yDQo+QXV0aG9yaXphdGlvbiBwdXJwb3Nlcy4uDQo+QnV0IGZvciBB dXRoZW50aWNhdGlvbiBjZXJ0YWlubHkgd2UgY2FuIGF2b2lkIFRpbWUsIHRoZSB0aHJlZSBtb3N0 DQo+cmVjb21tZW5kZWQgYnkgWzJdIG5vbmNlLWJhc2VkIHByb3RvY29scyBhcmU6DQo+KiBCZWxs YXJlLVJvZ2F3YXkgKDNQS0QpIFthIENob28gbW9kaWZpZWQgdmVyc2lvbiBJdCBoYXMgYmVlbiBw cm92ZW4NCj5wcm92YWJseSBzZWN1cmUgb24gdGhlIHN0cm9uZ2VzdCBtb2RlbCB0byB0ZXN0IGF1 dGguIGtleSBlc3RhYmxpc2htZW50DQo+cHJvdG9jb2xzIF0gWzNdDQo+KiBZYWhhbG9tIFthIG1v ZGlmaWVkIHZlcnNpb24gaGFzIGJlZW4gcHJvdmVuIHNlY3VyZSBvbiBhIHdlYWtlciBtb2RlbA0K Pi1iZWxsYXJlIHJvZ3dheS0gdGhhbiAzUEtEXSBbNF0NCj4qIEJveWQgW0tleSBBZ3JlZW1lbnQ6 IFJTLCBDIGFuZCBBUyBjb250cmlidXRlIGlucHV0cyB0byBnZW5lcmF0ZSB0aGUNCj5rZXldIFtw cm9vZiBpZGVtIHlhaGFsb20gXVs1XQ0KPg0KPlRoZSBtZXNzYWdlIGZsb3dzIG9uIHRoYXQgdGhy ZWUgb2YgcHJvdG9jb2xzIGRvIG5vdCByZXNwZWN0IE9BdXRoDQo+Zmxvd3MgKEkgYXR0YWNoIGFu IGltYWdlIHdpdGggdGhlIGhpZ2ggbGV2ZWwgbWVzc2FnZSBmbG93cywgQSBpcyB0aGUNCj5pbml0 aWF0b3IgYWx3YXlzKSwgc28gdGhhdCB0YWtlIHVzIGFwYXJ0IGEgYml0IGZyb20gT0F1dGguLi4N Cj4NCj5UaGlzIG1haWwgaXMgc3RhcnRpbmcgdG8gZ2V0IGxvbmcgc28gSSB3aWxsIHRyeSB0byBj b25jbHVkZSBpdCwgYnV0DQo+aG9wZWZ1bGx5IHJhaXNlIHRoZSBxdWVzdGlvbjoNCj4NCj4NCj4q KiBBcmUgd2UgaW50ZXJlc3RlZCBvbiBvZmZlcmluZyBub24tdGltZSAtbm9uY2UtIGJhc2VkIHNv bHV0aW9uIGZvcg0KPmFuIE9BdXRoIFBvUCBUb2tlbiBhcHByb2FjaCAoZm9yIGV4YW1wbGUgd2hl biB0aGUgdG9rZW4gZG9lcyBub3QNCj5leHBpcmUpKio/DQo+DQo+DQo+DQo+SWYgTk8sIEkgZ3Vl c3MgdGhhdCB3aWxsIG5lZWQgdG9rZW4gaW50cm9zcGVjdGlvbiBmb3IgUlMgdGhhdCBjYW5ub3QN Cj5zdXBwb3J0IHRpbWUgKFRoYXQgbWVjaGFuaXNtIHdpbGwgbWFwIHRvIG90aGVyIGF1dGhlbnRp Y2F0ZWQga2V5DQo+ZXN0YWJsaXNobWVudCBwcm90b2NvbCBhbmQgbm90IERlbm5pbmctU2FjY28t YmFzZWQgKQ0KPg0KPmlmIFlFUywgYXJlIHdlIGludGVyZXN0ZWQgaW4gYWRhcHRpbmcgYSBub25j ZS1iYXNlZCBhdXRoLiBrZXkNCj5lc3RhYmxpc2htZW50IHByb3RvY29sIHRvIE9BdXRoIFBvUCBU b2tlbj8NCj4NCj4NCj5JIGhvcGUgdGhpcyBxdWVzdGlvbnMgYXJlIHVzZWZ1bCwNCj4NCj5CZXN0 IHJlZ2FyZHMNCj4NCj5SZW56bw0KPg0KPg0KPg0KPlsxXSBDb2xpbiBBLiBCb3lkIGFuZCBBbmlz aCBNYXRodXJpYS4gMjAwMy4gUHJvdG9jb2xzIGZvciBLZXkNCj5Fc3RhYmxpc2htZW50IGFuZCBB dXRoZW50aWNhdGlvbi4gU3ByaW5nZXItVmVybGFnIE5ldyBZb3JrLCBJbmMuLA0KPlNlY2F1Y3Vz LCBOSiwgVVNBLg0KPlsyXSBLaW0tS3dhbmcgUmF5bW9uZCBDaG9vLiAyMDA4LiBTZWN1cmUgS2V5 IEVzdGFibGlzaG1lbnQgKDFlZC4pLg0KPlNwcmluZ2VyIFB1Ymxpc2hpbmcgQ29tcGFueSwgSW5j b3Jwb3JhdGVkLg0KPg0KPlszXSAzUEtEIC0gDQo+aHR0cDovL2VwcmludHMucXV0LmVkdS5hdS8x MjMwLzEvQUNJU1BfRnVsbF9WZXJzaW9uXy1fMDNfTWF5XzIwMDUucGRmDQo+WzRdIFlhaGFsb20g LSBodHRwczovL2VwcmludC5pYWNyLm9yZy8yMDA3LzE4OC5wZGYNCj5bNV0gQm95ZCAtIGh0dHA6 Ly9lcHJpbnRzLnF1dC5lZHUuYXUvNDQyMS8xLzQ0MjFfMS5wZGYNCg0K From nobody Mon Nov 16 07:17: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 6B1421A044E; Mon, 16 Nov 2015 07:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.786 X-Spam-Level: X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, 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 V7CXVOuFBOzQ; Mon, 16 Nov 2015 07:17:13 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3B7F1A0423; Mon, 16 Nov 2015 07:17:12 -0800 (PST) X-AuditID: 12074424-f79216d00000156e-72-5649f377f047 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-7.mit.edu (Symantec Messaging Gateway) with SMTP id 05.1A.05486.773F9465; Mon, 16 Nov 2015 10:17:11 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id tAGFH5wl032127; Mon, 16 Nov 2015 10:17:06 -0500 Received: from [192.168.0.104] (ip-53-040.atvci.net [209.240.53.40]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tAGFH2OO030677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Nov 2015 10:17:04 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: <001601d1203e$2a919460$7fb4bd20$@augustcellars.com> Date: Mon, 16 Nov 2015 09:17:02 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <82992675-FEB2-43B8-8DA4-C0B2915AB2C1@mit.edu> References: <001601d1203e$2a919460$7fb4bd20$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDIsWRmVeSWpSXmKPExsUixCmqrFv+2TPM4NhMEYvv33qYLaZtncpq sXr6dzYHZo+Nc6azeSxZ8pMpgCmKyyYlNSezLLVI3y6BK2PmsX+sBfMFK771LGFuYLzD28XI ySEhYCLx6udBVghbTOLCvfVsXYxcHEICi5kk3v45xAzhbGSU6Nx2iBHCOcgk0fH6CgtIC7OA usSfeZeYQWxeAT2JV7cug40SFjCU2HfyARuIzSagKjF9TQsTiM0p4CCxvL2VvYuRg4MFKL7r vz6IySwgL3HkfyXERG2JZQtfQ020kjj2divYJiEBe4nDDefYQWwRoK1bV99kgjhaVmL370dM ExgFZyE5aBaSg2YhGbuAkXkVo2xKbpVubmJmTnFqsm5xcmJeXmqRrrlebmaJXmpK6SZGUCCz u6jsYGw+pHSIUYCDUYmH98QT9zAh1sSy4srcQ4ySHExKoryPP3mGCfEl5adUZiQWZ8QXleak Fh9ilOBgVhLh7ToNlONNSaysSi3Kh0lJc7AoifNu+sEXIiSQnliSmp2aWpBaBJOV4eBQkuDd BDJUsCg1PbUiLTOnBCHNxMEJMpwHaPhFkBre4oLE3OLMdIj8KUZFKXFeHpCEAEgiozQPrheU aC5+MNV4xSgO9Iow7/+PQFU8wCQF1/0KaDAT0OATDWCDSxIRUlINjH78Msprcj9s/rUs32L2 gm/Ne/8tcdlcsGOvvcu/ZkUbGeY5H4NvvnlxxTdAbMOXDRV7PX8ysgn5rv8+0/31478Vp51D 5Z3eiRRMvcHtMb+c03zvvhl7uL6y/ur/u36Py+PDb+9v2Lu+2P1KxfUmyYOsyp9SVl4/kmSg kreYQVDwXkVt6W3+dHslluKMREMt5qLiRADIdiq3DwMAAA== Archived-At: Cc: cose@ietf.org, Ace@ietf.org Subject: Re: [Ace] [COSE] How COSE items are identified X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Nov 2015 15:17:14 -0000 I think it=E2=80=99s premature to assume one structure is used =E2=80=9Cmo= st of the time=E2=80=9D as opposed to other structures and to optimize = COSE for that case. Though if we take a cue from JOSE, it=E2=80=99s = asymmetric signing, then MAC. Those might be reversed as I don=E2=80=99t = have concrete numbers on this. Public keys are probably next. Encryption = is far behind in my experience with JOSE. My point is that I don=E2=80=99t think we can pick any one structure as = =E2=80=9Cmost common=E2=80=9D yet as we=E2=80=99re extrapolating from = exactly zero real-world examples. =E2=80=94 Justin (as non-chair) > On Nov 16, 2015, at 1:12 AM, Jim Schaad = wrote: >=20 > We seem to have a potential problem for how COSE items are identified. >=20 > Initially, we used an integer inside of the structure to identify it. = That > is how the current ACE documents are written. This uses a single byte. >=20 > At the request of Carsten, we moved from doing this to using a tag at = the > front of the structure. Carsten believes that this can be done with a = tag > that is in the two byte range when encoded (tag, length=3D1, tag = value). Part > of the reason that I agreed was that this was not really being used at = the > time by the ACE documents. =20 >=20 > If one is almost always doing encrypted, then one could encode that > structure w/o the tag and do the other three structures with the tag. = This > would probably be ok as it would mostly use the smallest tagging = (none) when > needed the most and use larger tagging (2 bytes) for the rest of the > structures. >=20 > Alternatively, we could modify the document to request the assignment = of > tags in the one byte range for the most common structures and two = bytes for > the less common structures (and have arguments about which is which). >=20 > Alternatively, we could revert back to putting an integer tag inside = of the > array structure. >=20 > Comments on this are requested. >=20 > Jim >=20 >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Tue Nov 17 01:07: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 E806D1B2D0D for ; Tue, 17 Nov 2015 01:07:52 -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 PqOufnCyQu3d for ; Tue, 17 Nov 2015 01:07:51 -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 E76981B2D0B for ; Tue, 17 Nov 2015 01:07:50 -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 tAH97XWH029030; Tue, 17 Nov 2015 10:07:33 +0100 (CET) Received: from [192.168.1.109] (p5B0DDA49.dip0.t-ipconnect.de [91.13.218.73]) (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 3p0LyF4hJyz2FwJ; Tue, 17 Nov 2015 10:07:33 +0100 (CET) To: Kepeng Li , "Ace@ietf.org" References: From: Stefanie Gerdes Message-ID: <564AEE51.30407@tzi.de> Date: Tue, 17 Nov 2015 10:07:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: Kathleen Moriarty , Hannes Tschofenig , Stephen Farrell Subject: Re: [Ace] Solution direction X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Nov 2015 09:07:53 -0000 Hi all, I think we should continue working on DCAF in ACE. It provides valuable concepts and mechanisms which is why many solutions in ACE draw heavily from DCAF. I think one aspect did not really become clear during the ACE session in Yokohama: A solution with only one supporting less constrained device will not be able to fully support communication between constrained nodes as DCAF does. One main question that is only partly solved by other solutions is: How can a constrained client authenticate the other party? A constrained device is not able to establish security associations as easily as a less constrained device. The keying material that is used for authorization and secure communication must securely be obtained. It can either be provisioned manually to the constrained device or a security association with a less constrained device is required that can then provide the keying material. An Authorization Server can provide session keys to the constrained devices, but the constrained device must have a security association with the AS to authenticate the origin of the session key. In a scenario where we have only a single AS and two constrained nodes, both need a security association with that AS. For cross-domain scenarios this might be difficult. We will need to manually provision the keying material to one of the devices which makes the dynamic setup of secure communication impossible. That's why we need two less-constrained devices in this scenario. You may think that this has nothing to do with authorization and therefore is not a topic for ACE. Well, it has, but another terminology-discussion might not be that useful. However, the important thing is that developing an additional solution to solve this problem will very likely add more overhead. The result will be more complex and more difficult to implement. Until such a solution is developed we will need to use complex workarounds (e.g. manual provisioning), may have security problems or are not able to address certain scenarios at all. But we have never done this before, why now? Because other than the general purpose computers that we are using today, constrained devices will communicate autonomously without the help of their user. They often will not even have user interfaces. Until now this was true for servers which is why existing protocols protect them. In a true Internet of Things this will also be true for clients. We therefore need to reconsider how clients can be protected and how their actions can be controlled by their owners. DCAF supports scenarios with a single less-constrained device (AS) as well as scenarios where both the Client and the Server have their own. It works with OAuth and may even transport OAuth tickets if that is necessary. It has a built-in key distribution mechanism and therefore is very efficient. The main fault of DCAF seems to be that we didn't call it OAuth. I think DCAF should be one of the building blocks (one of the tools in our toolbox) that ACE is working on. Best regards, Steffi From nobody Tue Nov 17 03:01: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 026F21A9172 for ; Tue, 17 Nov 2015 03:01:56 -0800 (PST) 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_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_38=0.6] 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 DE1nIYRscSXc for ; Tue, 17 Nov 2015 03:01:53 -0800 (PST) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E43E91A9071 for ; Tue, 17 Nov 2015 03:01:52 -0800 (PST) Received: by lbbsy6 with SMTP id sy6so3100550lbb.2 for ; Tue, 17 Nov 2015 03:01:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics_se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=kA/G6TfG+6i9PoXry0caAyOPW0j1QufejOzpnfEUbq8=; b=MDbja4/4bOOX1o+Fkmh6cveM7viXPywvV7eXIP/v1EaSH6FrhEJPIDlGqsKbJvJ+Ti xf9nBhoN30aMeXQxcXHz5p9IwWi8O748HyVIoREd5BDOhajo3muQFgpKgoNZ15ntbkk7 Oi9VfmRS0n/Ma8PHfzXaQzOvJ5suyxoEulKvEEaEm+IKPU2sE+J+J4jJdKN8QZnmxu5D x1+EzhX0vKIz774N+E+COXb+zM0O9iZ1zQlQt65OQCmFA93xC4qzpK59DKw/XUpS3Con +7F2grWJtfg9pwjhNzGgHZrP8Szsml+sq9QdEqyQoufPSQHPk3vhDzyqgU57mCpYeeg0 MQYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=kA/G6TfG+6i9PoXry0caAyOPW0j1QufejOzpnfEUbq8=; b=K9jrUImZnanyI2MKHp9VdPLPSsGhBxQ5TkiVCVBcJAYevJt+F0uRGz4lNrRllFUVdA SccvV2sMLREvlvadXwBAxZYbtDalxRf3JHxEF3XA4TuludyNZxxqZ+vS6UmgDjMp7Py2 JDyos09CrELrQfaWu+PB66VzQc39sbLFIDKdSnjYCcMCvPL02axDKG3WmH/CEdUJjqcw 7N01F4R5gAaZnO1j4vTtOg+n0jMkVM7rbSMGat/fv/CzkrhHeW0REcfgprI74kn32173 PcehvQ5EJDJXBErVNDA3vubuF8G7qr3W9KFXFEinuzXNmvL0mVPsQLqj7KYU6MRP0yG8 F9wA== X-Gm-Message-State: ALoCoQmPdDcpDKiNQqp/cZvqyRyGIpWFf3cTuXF/KWfDW0z5ngxDKOi8g19tM+8P+nuXFmYtDFNb X-Received: by 10.112.62.196 with SMTP id a4mr5771749lbs.91.1447758111022; Tue, 17 Nov 2015 03:01:51 -0800 (PST) Received: from [192.168.0.108] ([85.235.10.186]) by smtp.gmail.com with ESMTPSA id iy6sm6247278lbc.16.2015.11.17.03.01.49 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Nov 2015 03:01:49 -0800 (PST) To: Madjid Nakhjiri , "ace@ietf.org" References: From: Ludwig Seitz Message-ID: <564B091D.7010204@sics.se> Date: Tue, 17 Nov 2015 12:01:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000105090006040704020406" Archived-At: Subject: Re: [Ace] comments on draft-seitz-ace-oauth-authz-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 11:01:56 -0000 This is a cryptographically signed message in MIME format. --------------ms000105090006040704020406 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello Madjid, sorry for the long delay in answering, I had to tie up numerous loose=20 ends from other projects after IETF 94. Answers inline. /Ludwig On 2015-10-30 22:05, Madjid Nakhjiri wrote: > Hi Ludwig, > > Regarding > > "You seem to have experience with specific issues in that matter, could= > you describe those issues in more detail?=E2=80=9D > > I appreciate your inquiry for me to be frank, so let me provide a coupl= e > of broad answers: > > 1) I am involved with at least 3 standards who either are struggling or= > working hard to solve the onboarding/ provisioning problems or IOT type= > environments. [...] ACE has not considered this issue so far. One assumption I overheard was = that the device would come with some barcode or other printed id that=20 would identify a key to be used for bootstrapping. Another assumption=20 was that proximity based mechanisms might be used for a leap-of-faith=20 like onboarding procedure. There is some scientific work on that problem by Frank Stajano and Ross=20 Anderson (start here=20 https://www.cl.cam.ac.uk/~fms27/papers/1999-StajanoAnd-duckling.pdf), on = a cursory glance they seem to propose contact (such as connecting to the = device with a cable) as one solution (which seems close to the proximity solution I overheard). > 2) I am interested in figuring out what sort of support HW vendors like= > Mediatek need to provide for supporting authorization mechanisms such a= s > OAUTH. > For OAuth, I would guess that support for proof-of-possession tokens is=20 a good start. This can be done both with symmetric and asymmetric crypto.= This would mean that hardware AES would be a priority. SHA-2 or SHA-3 for HMAC, signature algorithms and key derivation=20 functions is probably also a good idea. Elliptic curve crypto support is propably what you want if the use cases = require asymmetric cyrpto (e.g. for signatures). Access to reliable time measurements impacts a lot how expiration,=20 replay-protection and freshness can be provided, so a RTC is also nice=20 to have. I guess mostly it's a question of pricing for mass deployments, how much = can the HW cost vs. what (crypto-)functions does it provide. Anyone spotting something obvious I missed here? [...] >> NOTE: ACE is explicitly not chartered to work with key management and >> the word has been shunned from any document, therefore I do not expect= >> that ACE will work on that issue. > > Madjid>>fair enough. Is there any other place in IETF that deals with i= t? > None that I'm aware of. >> >> >>> 2. Same thing for RS to AS registration. RS is many times a constra= ined >>> device itself. Also I am not clear how the AS will get the >>> authorization policies (scope/claim?) from RS. Is it that it is = the >>> AS that decides?? >> >> >> Actually it was never planned that the itself RS should provide and >> manage the authorization policies at the AS. The resource owners are >> expected to do this at the AS directly, when they enroll a RS they own= =2E > > Madjid>>Ok, makes sense. Are the policy definitions standardized? Or up= to > each vendor? > No the policies are not standardized in ACE. I don't think that would=20 make much sense unless policies need to be exchanged between several=20 federated AS. In that case there are policy standards that could be used = such as XACML, but that is definitely not an ACE matter since the AS are = expected to be unconstrained. [...] >>> 4. Restrospection of the tokens can be expensive and unscalable for= the >>> AS (if there are many RS nodes), but verification of self-contai= ned >>> tokens by the RS also sounds expensive, plus the verification ke= ys >>> need to be provisioned in the RS. Would be nice to have guidance= on >>> which makes sense taking device capabilities/class into account.= Any >>> network simulators out there? >> >> I'm guessing you meant Introspection here right? >> >> The AS is not expected to be a constrained device, thus it should be >> able to serve a significant number of introspection requests from >> different RS. Introspection works best if the RS has a good connectivi= ty >> to the AS while the client has intermittent connectivity or simply >> connectivity for the client is expensive (e.g. costs a lot of battery)= =2E >> Of course the number of AS has to be scaled up with the number of RS, >> but I don't think that is any different for non-constrained scenarios.= > > Madjid>>Yes, Introspection, sorry. > You are assuming that AS is in the cloud? Or within the =E2=80=9Clocal=E2= =80=9D > environment? I guess, if in the cloud, then scalability should be no > issue. > If local, then the volume should be low, which also ok. No specific assumptions on the AS here. The sole assumption for this=20 usecase is that the client has no connectivity after being deployed. > Either way, the assumption of introspection is that the cost of sending= a > token back to AS is lower than verifying it locally. The question is ho= w > do know the verification actually came from AS? Are you assuming a > persistent TLS/ DTLS (if there is such a thing) connection to avoid > message integrity verification costs? Since the client has no connectivity in this case, it needs a long-lived = token. This means that you do not want to bind specific rights to that=20 token when it is issued (such as e.g. a specific scope). This means that the RS _can not_ verify the token locally. There is a cost saving aspect here as well since the token can be made=20 very compact (it's just a reference that the AS uses to look up the=20 client's access rights in the introspection). This saves transmission=20 volume in the communication between client and RS. > >> >> Verifying a self-contained token certainly can be expensive, but the >> alternative is to be connected to the network in order to get a >> real-time access control decision from an AS. >> >> We assume roughly the following "hierarchy" of costs (from most >> expensive to least): >> >> 1. Network traffic (sending/receiving/listening for incoming messages)= >> 2. Crypto operations >> 3. Matching requests against permissions granted by access tokens > > >> Several experiments I conducted have shown that 3. is almost negligibl= e >> when compared to the cost of 2. and 1. When you add the overhead of >> running a security protocol when doing network communication, this mak= es >> both 2. & 3. very cheap compared with 1. > > Madjid>>Interesting. So what is the metric for cost? CPU cycles? Time > spent in a task lock? What sort of OS you have in mind? OS or RTOS? > I would love to see any paper or info on the experiments you conducted.= I think it's not very surprising, since matching the requests to tokens=20 will usually just require a few comparisons (strings, integers, binary,=20 and perhaps regexp at worst), while crypto involves some heavy=20 calculations (AES takes 10 rounds of transformations for 128 bit keys=20 for example). I have supervised two masters thesis projects that have some results to=20 that effect. *http://soda.swedish-ict.se/5684/1/NiklasHjern_JonasVistrand_Master_Thesi= s_EIT.pdf This is a project using a token-based authorization approach (not OAuth) = and TLS. From the figures in section 6 you can see that transmitting the = token is by far the most expensive part (red parts of the figures) while = processing TLS vs TLS+matching requests against tokens is almost=20 indistinguishable. * http://soda.swedish-ict.se/5681/1/Thesis._AC_in_the_IoT._Final.pdf This is a project using a key derivation method to provision pre-shared=20 keys via a trusted third party (based on=20 draft-seitz-core-security-modes-00). Here it is shown that a key=20 derivation (including some Base64 decoding and SHA-2 calculations) is=20 almost negligible in comparison to a DTLS handshake. If you want to=20 extend this to generic message exchanges, the key derivation is roughly equivalent to sending a ClientHello message (compare tables 7.1 and 7.2|)= =2E http://soda.swedish-ict.se/5681/1/Thesis._AC_in_the_IoT._Final.pdf --=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 --------------ms000105090006040704020406 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DFQwggYYMIIFAKADAgECAgMMhpgwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTAxMDgwODM5MDZaFw0xNjAxMDkyMjQxMzBaMDgxFzAV BgNVBAMMDmx1ZHdpZ0BzaWNzLnNlMR0wGwYJKoZIhvcNAQkBFg5sdWR3aWdAc2ljcy5zZTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVB4rAuq4FxbARxwRqPLpc/3C194F+V H4XMKK6fu3Y8zDLijzNSjh6tG41oZhXvJcvAs1nZNjUutNLeyBAUFiYhy7HXNdlKpjbMEFKQ +6KpEdZ0Rk+pXgB2E1mqZEfp3M2djcQ/h+7uGVlSGYNAxYk6rWPIIWBx2GMvAQaHP4xxu/F+ PiSQILOVzmtIFZe1t/Lw71aaNeMYVhARo8z5PVsVoq6gBeujxfiRLtiQ/S8xW6RKvNvUkVyT BQfcKaEDZR9FENNf9rFgiAcT6R7hI8RBf1d2fxdlbDU8uM72K3fvzGDt8N9Bfm1kDWbDBxJE 1taRIYs+60D1kwV6DvBb9MECAwEAAaOCAtQwggLQMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6ryrKahJtBOEdbIL AAWCpOsQyagwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwGQYDVR0RBBIwEIEO bHVkd2lnQHNpY3Muc2UwggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYB BQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqBvlRo aXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDEgVmFs aWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUg cmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEF BQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEvY2xpZW50L2NhMEIG CCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNs aWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqG SIb3DQEBBQUAA4IBAQBl8BbG0n7+JjFqiJOuAqMbkeqM6Oyd+4oHGu3fbaSiM1SKesae2bfm vifV99a+M4DERZ2SVkOYcvNlv31Q3hvYtzRjDOqewzVKxo021R3ddQULW1DhvTEpclikG5rd 0NRJQn+EkSwEKLeUj68i0dhU8ULhZDDq3A81cTcZzIGrTjNnwDvCktB/sF/iO4At6RJ24P3j KjYFPirW3NsvZ2gzZizSzeubPE0/cWcqEBJ/UtaFPF54efejjLuPRHHMLPDcvrwBhEiBxuG6 oTEo465g4pS9Vo/Z0GoZgZyA+aGQ+YPbPSsqsYmSBjZ6MGGDqQq0niE2dW+8IOdHQvMkqI52 MIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcN MDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxwmDzM4t2BqxKaQu E6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESip7vMz39ScLpNLbL1QpOlPW/t FIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9ftTyhxvxWkf8KW37iKrueKsxw 2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsWoTb7q8hmgv6Nv3Hg9rmA1/VP BIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/43Yksq60jExipA4l5uv9/+Hm 33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IBrTCCAakwDwYDVR0TAQH/BAUw AwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8G A1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsGAQUFBwEBBFowWDAnBggrBgEF BQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0GCCsGAQUFBzAChiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQwUjAnoCWgI4YhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcBAgEwZjAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDov L3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjANBgkqhkiG9w0BAQUFAAOCAgEA CoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHbWNaPeQn3oBSU8KgQZn/Kck1J xbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4OxK9QPoSjCMxM3HbkZCDJgnl E8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0KAkXCzeQNLeA5LlYUzFyM7kP Ap8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL04qYK/zu+Qg1Bw0RwgigVZs/0 c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0IFiNu9IPuTGAPBn4CPxD0+Ru 8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6fDEPme+1Nbi+03pVjuZQKbGw KJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVtjYsv0L1TSm2+NwON58tO+pIV zu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm48ZCYfAWLb/Xj7F5JQMbZvCex glAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BIXRsF1du4qESm4/3CKuyUV7p9 DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJ bnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJYIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MTExNzExMDE0OVowLwYJKoZI hvcNAQkEMSIEIGPJF04rVfja5uhyYirkL0L5OHdh9ITAC2zJtNE/yPjhMGwGCSqGSIb3DQEJ DzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQB gjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwgacG CyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC AwyGmDANBgkqhkiG9w0BAQEFAASCAQCkBH3afUvBw6Xw3El88YiSpUiF64xksNrkY5qOZw07 1e8xd+dOV7IFVZWwu97CAl6XLi/EOhmWK7N/4AKw+Bs8dEdgPsnj11qCH1EW/E/6CryHW1Jl nGbXjOv4C5P6hLjMuIO5IODkn1z3IvK44wZLWxNmmkMsuVI9psSA1wJK4ZoxcuEv1BYbDEe9 ZFmYqQc8Dc8p+iniGT2w1l9eopTE5XkHIRp5Xrs9sfa8s7wuIZx4E3fCJWIG85+VQzxUuYWS VaN6e1WpoCkNxjGKFceQUZi4SFikibm8IxKrolGzI0Xv6Mc1nrK3JyNU600H2Lu1nlN2n+X2 4qbXN/JOQTHvAAAAAAAA --------------ms000105090006040704020406-- From nobody Tue Nov 17 03:05: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 DC1D41AD08F for ; Tue, 17 Nov 2015 03:05:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxyet91blGCP for ; Tue, 17 Nov 2015 03:05:48 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0717.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::717]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C09531B2A03 for ; Tue, 17 Nov 2015 03:05:44 -0800 (PST) Received: from DB5PR06CA0012.eurprd06.prod.outlook.com (10.162.165.22) by AM4PR06MB1476.eurprd06.prod.outlook.com (10.164.80.30) with Microsoft SMTP Server (TLS) id 15.1.325.17; Tue, 17 Nov 2015 11:05:38 +0000 Received: from AM1FFO11FD024.protection.gbl (2a01:111:f400:7e00::164) by DB5PR06CA0012.outlook.office365.com (2a01:111:e400:52c2::22) with Microsoft SMTP Server (TLS) id 15.1.331.20 via Frontend Transport; Tue, 17 Nov 2015 11:05:38 +0000 Authentication-Results: spf=pass (sender IP is 146.108.200.10) smtp.mailfrom=tridonic.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=tridonic.com; Received-SPF: Pass (protection.outlook.com: domain of tridonic.com designates 146.108.200.10 as permitted sender) receiver=protection.outlook.com; client-ip=146.108.200.10; helo=ATDOAGMSX01.itiso.net; Received: from ATDOAGMSX01.itiso.net (146.108.200.10) by AM1FFO11FD024.mail.protection.outlook.com (10.174.64.213) with Microsoft SMTP Server (TLS) id 15.1.325.5 via Frontend Transport; Tue, 17 Nov 2015 11:05:37 +0000 Received: from ATBRAGMSX02.itiso.net ([169.254.2.220]) by ATDOAGMSX01.itiso.net ([146.108.41.67]) with mapi id 14.03.0248.002; Tue, 17 Nov 2015 12:05:36 +0100 From: Somaraju Abhinav To: "ace@ietf.org" Thread-Topic: [ACE] Review of draft-ietf-ace-actors-02 Thread-Index: AdEhJ54fHBfZq3gtSOStJGChP7bmYA== Date: Tue, 17 Nov 2015 11:05:36 +0000 Message-ID: <0E9A48AB39AF3547ACD28A6DE3E2906A0F1ABF6C@ATBRAGMSX02.itiso.net> Accept-Language: en-US, de-AT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.108.41.149] Content-Type: multipart/alternative; boundary="_000_0E9A48AB39AF3547ACD28A6DE3E2906A0F1ABF6CATBRAGMSX02itis_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD024; 1:9zhr1/cJx44S9XWZwmAKeXinA4je0nFmMCcXDoZQ2/TjeWDPrisBOIvW1Xha0r/EQnlZRPocqeU7fy/h5Ok6g61K41BpyQfrlgwUlrwyawvgq6v+qULM0UBrglzeDfOETtbiI36QDHVp4/K5xvqqXWztruC5t27vx1FUqOUrc2ZTM9EKL+9ObMIh4y+Eg0n00WxjmjHNPEkGtxwOYUUHHHpaH4l1VaaS/PcMEQPCEcPKT1haFO6mxLRAB5CMmimz3ZBR6dF1ejU4apIm6IsAffvrZ/o0DeMmqf2R+12VR9rx7QBUy5louhQ0OBLysdOnO5QUpQRWjzNYY3TLX3WKToIvf9G6w5Ir823uDqtEc/g= X-Forefront-Antispam-Report: CIP:146.108.200.10; CTRY:AT; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(199003)(189002)(57704003)(53754006)(19625215002)(26826002)(229853001)(6806005)(55846006)(2920100001)(561944003)(19580395003)(86362001)(2351001)(106466001)(54356999)(2930100002)(16236675004)(5890100001)(50986999)(66066001)(11100500001)(102836002)(107886002)(69596002)(5001920100001)(300700001)(230783001)(92566002)(81156007)(84326002)(2900100001)(260700001)(104016004)(5007970100001)(5003600100002)(87936001)(450100001)(53416004)(33656002)(5001960100002)(15975445007)(110136002)(2501003)(5004730100002)(5008740100001)(586003)(19300405004)(512954002)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR06MB1476; H:ATDOAGMSX01.itiso.net; FPR:; SPF:Pass; PTR:unknown.zgrp.net; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AM4PR06MB1476; 2:l5XOLx8GLEOcqIhLwlC4SJoNG4m+7DWGKqAhE7fMvreoj/Iuh7DPY3LwAGSCp7+d547hUxJpEwUjU456qnPSpF4F+ACtQ0mQ2eiHSdczIjNAoA3u1wo2I3MNBa+oVwiXycpKxJq3XwTqaPH2DpfF2phKYX5X+mFlsHyDRMPgl3Y=; 3:9krMX+YcwwH/AkvmfXRSciDH9NfyeeMGw9iz0hza2eNKv4pK86x1ZjXe+WiN0bH8Xv3F4ZHm7HPbB0YbdE6bMbJFMA0G/jSc3fe7lP80u3Nq1pzYMWmqFYnC67RuuRVqRGVQoXG8cw5BtB3MFTMq7L/FapzLqXu3/Skzws0SOP4xuiwqQX+eSXM45hWvH3sVKT+z9GvhHJLxmtVAigVMOdlXZB8/fcPfmK+oku/MsJQ9jN+RKi45ad0IVP9D7YSIxHFTc1ob2xbL1yY6NEtgCg==; 25:r+JE8NmuVV9cFD/tRYXMjFFYzTa5JAscLN8hs1vAooXhAddo/Kz+gY7pu+ZZwjjPMzDxEgn3Dxg0tk8a2LfI4XkEVZaGMCq67k8d1RcmeOHf555yIy95JzCm4WHU2QLblk04tES3hIWgisBIgbjvsOOKOemACSIisPs6rwMFjLsRC+JKV68bXiqQndPbeEJUin/Ce7HxVChGM2Ec3n7Fr5IeSvzM3nXkE22xzMKCxo9gKecqgg7FhXWQ/IUzmBDBcINRSIG/Nhz1QtEdlXukPw== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501001); SRVR:AM4PR06MB1476; X-Microsoft-Exchange-Diagnostics: 1; AM4PR06MB1476; 20:MU/OsKvcauqxHcaW1jFDicmMhK8ehyDpBXbeDESCH3tNgOWO8ww9BV+9eMOdYddJt6HVGZJgA085F+Uq511aWXwWfr4OSAwx7Yw+GP8RHmkoOx/A37wBAFgmtKjymWaPvO0UwDzU+WmyAjZdwnFDrJAz2bhgAeOS6rBpZIIa+8VHKrH2QBIv/sjPm31fbMPICpVjWR9SoU3t3mJoEBbuuVjjnqCKleqgeyjILZl5F1PnDWJI304Y1dQK2N1s1nWPQBnqnQIMgxF5KsLwXLUW1Xn9odsn1rPOhyqnL4ebfVBje6AEEwfagksWXvRDKtZE8kAaHDraP05LRjLxM/rk+82OlrUzPAwsUM+ecQGAo2URtl0bva6Y4Qw2t6sdA13u7521TvQpZnCLtuJoNy524LJ7NngxSM49PS63yg3xhH82ugTASfwpCufDvu92ltGJO6kfs7hAK0oJBI/9ALCB8ZIjnpynhy/VKZg95XY3sfuaDqQeWozRGiEkwZkR581R; 4:/mk4cT5nqtouLB6n2PN4gpNqcJz8L0YcInqfvvIiKueWCxVRX4HKl/jNaVIHGjbV+vY6u6OodWp8lK2TdjVtzw2w5jmLcbaFlpfPsLP+DslboleAwk24GXrSTytSr0++6MiFUxYi4WP1X4vp49paAc/BDq5ZedU77DvDNdB05vMnMHeoZEQbtiBo2qT4cwgnBpVuUpVJrPZbAatgIKBOW/5GPYPKXEEtEIca5lMFeC2yjLKiXTUwrPUHwpCxx2PcpO1oF+DnbqvxNi1bEGb7Un8lmZqwxaAqylqKCd7BOHU7GeNoGvQukzj0U2IZ1F4FIeJBVvNLxfyXD/Zr8hgMAusgW3T/b8GNudvgd90f2YF4oE3yS5NIp7cI7K2BM8vY X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(108003899814671); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(10201501046)(3002001); SRVR:AM4PR06MB1476; BCL:0; PCL:0; RULEID:; SRVR:AM4PR06MB1476; X-Forefront-PRVS: 07630F72AD X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; AM4PR06MB1476; 23:8Pr1qLqzpsXrvP4TiF5L4H221prAmJG7/vfuoJeHT?= =?us-ascii?Q?n8HGyraxGL/cLZvTDqIPo+tsMKJE73bFiHgyRoAf0PrRk2uATU9QjLYQmZ9D?= =?us-ascii?Q?+X3hUHD0FnpVIdw7e42ZsVuhrqYtpTYWshwZFAo8GWZoJqBLyWq25r1U1qxI?= =?us-ascii?Q?a5S/NDBt9h7Si+O86JU0XQ8KA5YCWWGr7twc4M3LTYb2HInZJ4rlB5es7F/X?= =?us-ascii?Q?RSRbOaJ3g5alHB/+QpwgFrK1ukQMTMsSEqA9+SwD9H9t01nlOpFCSistAC7p?= =?us-ascii?Q?I4h6X0oOJ+Lb2nCSpmz53IgPlRMP0Ub9J5+ho14xteMzBk9B3x86bStCpEVO?= =?us-ascii?Q?TUQT03hbbwyTjRq19dkrPwSSJQBGVmM8iSJ7Dy5qjpd9SKvmxO0dPcj0KyEo?= =?us-ascii?Q?SWA8aOc0XZiGmd1tpCpiLn1m6MsaKDPDMJChPLNNVUxVfHcppyuEYkgTdx8q?= =?us-ascii?Q?fTL21hp2Hwp8z+zVDuRWjNqmS/aZZ8p7SFjY66FSKeTtkdfhDCILpZ7uS9u7?= =?us-ascii?Q?2OgcfQjuglI6D/xUgXM5f4pF1P+3PT3qiLmCW6XFlA5ZNOyqC3DDrmkSabst?= =?us-ascii?Q?qbWzBL1Huzwy5TE1F/rDsN8ZcwraQONyh/sAHdEUMSUyS3VImQRfBotDWNU8?= =?us-ascii?Q?wKxKTtdnvYtQAEz4r5/wHtC3sDNiN0Yv0oOzPoaakBPDoRdW1XWBppM0R7BH?= =?us-ascii?Q?mYEsg5fNHNYjJmVP7m1fgpIkMGttQN+4ajXUFc2xYkMkV9zQHhy3kYVDA8si?= =?us-ascii?Q?tRV59HdF9Y6QKXQ47EcfmhIvIu7ZwDCOWyBeVarZT7tVrQ99ZnOlc944YF5N?= =?us-ascii?Q?eHpY4ZiXDQJdI9cvs5pUyibm0bu7yEYwc1nFKxbnKigM3BxgGDzfJdx7VrWQ?= =?us-ascii?Q?j9Uoruo2QoTf8AWV6Ug5QMb5kXAEGWEO3OQzSIAEJjLTPgz21sDrrx4Agfg1?= =?us-ascii?Q?xeSDSo0buCibU8S1NQ9VvADddWfh4bHQt0DeTXbnuQlEML2xES/U5shpDhvk?= =?us-ascii?Q?fZI3U9AhISF2Wj+t16cXi0qLsHOMbAT1+lhTqyldLiobR63OTE7l6QLN4noa?= =?us-ascii?Q?0kJuLXoximPXG6ceOageK/lwhVSkLjeAz3MbPmHKfb4Ozfn3IAkYzxRIjuNv?= =?us-ascii?Q?wMuR9vhc0vUZlryo+dFwkOse3qCjZWfLd6HPDpl+LEN/KeYiFWVwxtlGmRCb?= =?us-ascii?Q?SDeymBrhbuzJdBE6LRaMBdfb8AcuBgDUrhH93TskzPHhY0zmIemb+I7aoiMA?= =?us-ascii?Q?6oZqumcOuKYkOPkly3c3mHmINgvP8xE1kDoRabuaaPpzqOkv2b34MSrDnIih?= =?us-ascii?Q?zuXQytC9EtV3vowx25ZlwWPLGU0ksdzuBSpNxlBixVYLIOAd/e0cUEeqCNrZ?= =?us-ascii?Q?q9+ih7BvxUh/S43X+SvKYiYtJ4c3od2ysR7uOZA77RBbl2n?= X-Microsoft-Exchange-Diagnostics: 1; AM4PR06MB1476; 5:TkR0txyByOFXKOkRHyk1SIQLyqIKbokKYiy12WBA8PqmW2OmNlNP+raEMsJgoHBW/in7IF4Cs/wKCi/VxWWd1FGJBdYZf+9Ke4sgL2OZ4GvmOtLOPM2NwMtTKzAISMVmyGsDirlDRsgKA/Feq0c2cA==; 24:j/8TvbZj6ACRzmlbzjTAvciP5qg2dy0dCvPCzWQ4og1OcGSNqSycrMFPAgdffC/KXfyRRWHoJw/e/oRoQZLgjl+1D+lzyGPOzGWQt6ukWV0=; 20:ShTysoo6owt2/MEI+hq7u0tyzYk6UmlngM1GtZjCZUMQX27H2A6oR3tW8Xo/gqkr7va0YyZQfeC8eEFtlhkKWQ== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: tridonic.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Nov 2015 11:05:37.8217 (UTC) X-MS-Exchange-CrossTenant-Id: 8b206608-a593-4ace-a4b6-ef1fc83c9169 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8b206608-a593-4ace-a4b6-ef1fc83c9169; Ip=[146.108.200.10]; Helo=[ATDOAGMSX01.itiso.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR06MB1476 Archived-At: Subject: [Ace] [ACE] Review of draft-ietf-ace-actors-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Nov 2015 11:05:58 -0000 --_000_0E9A48AB39AF3547ACD28A6DE3E2906A0F1ABF6CATBRAGMSX02itis_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, Please see below for a review of the ace actors draft. Regards, Abhinav It is very difficult for me to understand what this document is trying to a= chieve and exactly what benefits the document provides. It feels like the d= ocument is trying to do a little bit of everything without doing a good job= of anything. The confusion begins with the title and abstract. Based on th= e title it seems to me that the authors are trying to address some or all o= f the following aspects: terminology, actors, elements (not sure what "elem= ents" means) the architecture is trying to address, a problem statement, so= me aspects of an architecture. I do not know understand what value such a d= ocument brings to the working group because I do not know how to judge it a= nd more importantly, I do not know how and when I should be using it. If the authors can give a simple answer to the question "how and when shoul= d I be using the contents of this draft", it would be very helpful. I will try to address each of these aspects as far as I understood in the d= raft Terminology - Resource, resource server, client is already defined in RFC7231/= RFC7252, why define it again - Constrained device is already defined, why do we need to define = constrained node? - Authenticated Authorization: A synthesis of mechanisms for auth= entication and authorization. The statement makes no sense to me. - I do not understand why the paragraph regarding "client-side asp= ect of Authorization" included in the terminology section? If you want to r= edefine the term authorization and include it in the terminology section th= en please give a proper definition. I think a large part of the confusion r= egarding the need for CAS could be fixed if the authors provide a simple de= finition for what is meant by "client-side aspect of Authorization" in the = terminology section. - Undefinded terms: controlling principal on P.5 (what is the diff= erence to principle) Elements of an architecture - The abstract says "the elements that an architecture needs to ad= dress" but Section 2.1 is titled "elements of an architecture". I do not kn= ow what each statement means and what is the relation between the two. - How should I judge only parts of an architecture if the whole th= ing is not present? - I do not understand "Objectives of type 2: C is exchanging info= rmation with (sending a request to, accepting a response from) a resource = only where it can ascertain that RqP has authorized the exchange with R." o The client always initiates any interaction with a server. So the "clie= nt authorization" is implicit in the design of restful protocols. It is onl= y server side authorization policies that need to be added additionally. I = can see a reason for the client to authenticate a server but I do not under= stand what client side authorization is required that is over and above wha= t already comes implicitly with RESTful protocols ala something/someone tri= ggers a client to access resources on a particular server. Authorization po= licies are required on the server side because they should be ready to acce= pt new requests. With this in mind, I do not understand what exactly the CA= S is supposed to accomplish other than help with authenticating the server. o In the introduction the authors say Authorization is about who can do wha= t to which objects. o Problem Statement - "The problem statement for authorization in constrained environm= ents can be summarized as follows" is not true. This document focuses on on= e problem in the set of all problems in the constrained networks. Missing p= roblems for example include secure bootstrap, group communication etc. Mayb= e the authors what to say that they are focusing on one problem statement i= n the constrained environment. - "The interaction between potentially constrained endpoint contro= lled by control information provided by less-constrained nodes on behalf of= the principals of the endpoints." Assumes one particular architecture. The= re are several options here and I do not understand how a working group dra= ft regarding the problem statements in the constrained network can assume o= ne architectural proposal. -architecture: How can I judge "elements of an architecture"? I do not see any benefit in = specifying only small parts of an architecture-I need the whole thing to un= derstand if it works or not. I do not understand o Objectives of type 2: C is exchanging information= with (sending a request to, accepting a response from) a resource only where it can ascertain that RqP has authorized the exchange with R. Actors - This section is the only Section that I found useful in the docu= ment and introduces terms such as CAS and AS which are less constrained. - I do not understand the role that CAS plays as far as authorizat= ion is concerned. However, CAS could play a role with regards to helping th= e constrained client authenticate the remote server. Other points: 4. Authentication and Authorization - The authors mention nothing about "client side authorization in = the section". The server side authorization and the link of authorization t= o authentication is well know. This Section would be a good place to explai= n the role of the CAS. 6. Kinds of Protocols - What is this section trying to achieve. There is absolutely noth= ing mentioned in the introduction or abstract regarding this Section and I = do not see any benefit of including it. 7. Elements of a Solution & 8. Assumptions and Requirements - In a document trying to identify a problem statement/actors I do= not see the need to also add a section that addresses some aspects of a so= lution - "Without anticipating specific solutions" is not an accurate sta= tement. Using a CAS already assumes a specific type of solution. ________________________________________________________ The contents of th= is e-mail and any attachments are confidential to the intended recipient. T= hey may not be disclosed to or used by or copied in any way by anyone other= than the intended recipient. If this e-mail is received in error, please i= mmediately notify the sender and delete the e-mail and attached documents. = Please note that neither the sender nor the sender's company accept any res= ponsibility for viruses and it is your responsibility to scan or otherwise = check this e-mail and any attachments. --_000_0E9A48AB39AF3547ACD28A6DE3E2906A0F1ABF6CATBRAGMSX02itis_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

Please see below for a review of the ace actors draf= t.

Regards,

Abhinav

 

It is very difficult for me to understand what this = document is trying to achieve and exactly what benefits the document provid= es. It feels like the document is trying to do a little bit of everything w= ithout doing a good job of anything. The confusion begins with the title and abstract. Based on the title it se= ems to me that the authors are trying to address some or all of the followi= ng aspects: terminology, actors, elements (not sure what “elements= 221; means) the architecture is trying to address, a problem statement, some aspects of an architecture. I do not know unders= tand what value such a document brings to the working group because I do no= t know how to judge it and more importantly, I do not know how and when I s= hould be using it.

 

If the authors can give a simple answer to the quest= ion “how and when should I be using the contents of this draft”= , it would be very helpful.

 

I will try to address each of these aspects as far a= s I understood in the draft

 

Terminology

-       = ;   Resource, resource server, client is already define= d in RFC7231/RFC7252, why define it again

-       = ;   Constrained device is already defined, why do we ne= ed to define constrained node?

-  &= nbsp;       Authenticated Au= thorization:  A synthesis of mechanisms for authentication and authori= zation. The statement makes no sense to me.

-  &=
nbsp;       I do not understand why the paragraph regarding “client-side aspect of Authorization” included in t=
he terminology section? If you want to redefine the term authorization and =
include it in the terminology section then please give a proper definition.=
 I think a large part of the confusion regarding the need for CAS could be =
fixed if the authors provide a simple definition for what is meant by “client-side aspect of Authorization=
221; in the terminology section. 
-  &=
nbsp;       Undefinded terms: controlling principal on P.5 (what=
 is the difference to principle)
 

 

Elements of an architecture 

-     =
     The abstrac=
t says “the elements that an architecture needs to address” but=
 Section 2.1 is titled “elements of an architecture”. I do not =
know what each statement means and what is the relation between the two.
-  &=
nbsp;       How should I judge only parts of an architecture if =
the whole thing is not present?
-  &=
nbsp;       I do not understand  “Obj=
ectives of type 2: C is exchanging information with (sending a  reques=
t to, accepting a response from) a resource only where it can ascertain tha=
t RqP has authorized the exchange with R.” <=
/pre>


o  
The client always initiates any interaction =
with a server. So the “client authorization” is implicit in the=
 design of restful protocols. It is only server side authorization policies=
 that need to be added additionally. I can see
 a reason for the client to authenticate a server but I do not understand w=
hat client side authorization is required that is over and above what alrea=
dy comes implicitly with RESTful protocols ala something/someone triggers a=
 client to access resources on a
 particular server. Authorization policies are required on the server side =
because they should be ready to accept new requests. With this in mind, I d=
o not understand what exactly the CAS is supposed to accomplish other than =
help with authenticating the server.=



o In the introduction the authors say Authorization is about who can do what to which objects.



o  
 


 


Problem Statement 

-  &=
nbsp;       “The problem statement for authorization in co=
nstrained environments can be summarized as follows” is not true. Thi=
s document focuses on one problem in the set of all problems in the constra=
ined networks. Missing problems for example include secure bootstrap, group=
 communication etc. Maybe the authors what to say that they are focusing on=
 one problem statement in the constrained environment.

-     =
     “The =
interaction between potentially constrained endpoint controlled by control =
information provided by less-constrained nodes on behalf of the principals =
of the endpoints.” Assumes one particular architecture. There are sev=
eral options here and I do not understand how a working group draft regardi=
ng the problem statements in the constrained network can assume one archite=
ctural proposal.


 


-architecture:


How can I judge “elements of an architecture&#=
8221;? I do not see any benefit in specifying only small parts of an archit=
ecture-I need the whole thing to understand if it works or not.



 


I do not understand  &nb=
sp; o  Objectives of type 2: C is exchanging information with (se=
nding a


      request to, ac=
cepting a response from) a resource only where it


      can ascertain =
that RqP has authorized the exchange with R.


 


Actors



-       =
;  
This section is the only Section that I found usefu=
l in the document and introduces terms such as CAS and AS which are less co=
nstrained.




-       =
;  
I do not understand the role that CAS plays as far =
as authorization is concerned. However, CAS could play a role with regards =
to helping the constrained client authenticate the remote server.



 


Other points:


4.  Authentication and Authorizati=
on


-  &=
nbsp;       The authors mention nothing about “client side=
 authorization in the section”. The server side authorization and the=
 link of authorization to authentication is well know. This Section would b=
e a good place to explain the role of the CAS.  

 


6.  Kinds of Protocols<=
b>


-  &=
nbsp;       What is this section trying to achieve. There is abs=
olutely nothing mentioned in the introduction or abstract regarding this Se=
ction and I do not see any benefit of including it.


7.  Elements of a Solution & 8=
.  Assumptions and Requirements


-     =
     In a document trying to identify a problem statement/actors I do not =
see the need to also add a section that addresses some aspects of a solutio=
n


-     =
     “With=
out anticipating specific solutions” is not an accurate statement. Us=
ing a CAS already assumes a specific type of solution. 

 


 
________________________________________________________ The contents of th= is e-mail and any attachments are confidential to the intended recipient. T= hey may not be disclosed to or used by or copied in any way by anyone other= than the intended recipient. If this e-mail is received in error, please immediately notify the sender and= delete the e-mail and attached documents. Please note that neither the sen= der nor the sender's company accept any responsibility for viruses and it i= s your responsibility to scan or otherwise check this e-mail and any attachments. --_000_0E9A48AB39AF3547ACD28A6DE3E2906A0F1ABF6CATBRAGMSX02itis_-- From nobody Tue Nov 17 05:45:45 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A8C1B2F6F for ; Tue, 17 Nov 2015 05:45:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4A6nZKPhVKi for ; Tue, 17 Nov 2015 05:45:38 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0764.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::764]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 065D11B2F67 for ; Tue, 17 Nov 2015 05:45:37 -0800 (PST) Received: from HE1PR06CA0030.eurprd06.prod.outlook.com (10.162.181.168) by DB4PR06MB158.eurprd06.prod.outlook.com (10.242.155.144) with Microsoft SMTP Server (TLS) id 15.1.325.17; Tue, 17 Nov 2015 13:45:16 +0000 Received: from AM1FFO11FD024.protection.gbl (2a01:111:f400:7e00::115) by HE1PR06CA0030.outlook.office365.com (2a01:111:e400:51fa::40) with Microsoft SMTP Server (TLS) id 15.1.325.17 via Frontend Transport; Tue, 17 Nov 2015 13:45:15 +0000 Authentication-Results: spf=pass (sender IP is 146.108.200.10) smtp.mailfrom=tridonic.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=tridonic.com; Received-SPF: Pass (protection.outlook.com: domain of tridonic.com designates 146.108.200.10 as permitted sender) receiver=protection.outlook.com; client-ip=146.108.200.10; helo=ATBRAGMSX01.itiso.net; Received: from ATBRAGMSX01.itiso.net (146.108.200.10) by AM1FFO11FD024.mail.protection.outlook.com (10.174.64.213) with Microsoft SMTP Server (TLS) id 15.1.325.5 via Frontend Transport; Tue, 17 Nov 2015 13:45:15 +0000 Received: from ATBRAGMSX02.itiso.net ([169.254.2.220]) by ATBRAGMSX01.itiso.net ([169.254.1.64]) with mapi id 14.03.0248.002; Tue, 17 Nov 2015 14:42:33 +0100 From: Somaraju Abhinav To: "ace@ietf.org" Thread-Topic: [ACE] Permanant client-server relations and draft-seitz-ace-oauth-authz-00 Thread-Index: AdEhN5xFUnXCzFUVReqBc2YQQmmyoA== Date: Tue, 17 Nov 2015 13:42:31 +0000 Message-ID: <0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC07D@ATBRAGMSX02.itiso.net> Accept-Language: en-US, de-AT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.108.41.149] Content-Type: multipart/alternative; boundary="_000_0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC07DATBRAGMSX02itis_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD024; 1:vJ4C6s3gyjVBMm1nvL9kfGYCqTGyDIOyA5MzTP6qhu/NCQnjJSul0uoHpkFQSwPsYCuHzg2WPO1z+ccZL3vnSq98lO9telWJThaCD77o2W/mXtO5+FrvE3CQmFiMAD2xSQ8/hvDiDDt2mTYBTMI1zkC6jaJqd70R/uKqk8fCkjq6dY4h5r1wkropYC5NtSG6w90j8enQRQi/1qHg7lZSL0l/sF8+/vXMB0W8n9WYR7namGUbKa2dbps3uJZNqB3mnRsM6p23rup+azp6/5kiPXfawh2E2sb/TFnSKCGNEOngy8ELTZK4p+b5o2DP5UnxtlXJWG/aaexgdTi3wLRWLgvfD/KxbMNC7uVQJEzz9gs= X-Forefront-Antispam-Report: CIP:146.108.200.10; CTRY:AT; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(979002)(6009001)(2980300002)(438002)(199003)(189002)(5007970100001)(586003)(50986999)(260700001)(300700001)(450100001)(86362001)(230783001)(2920100001)(2930100002)(19300405004)(54356999)(19580395003)(15975445007)(2900100001)(55846006)(26826002)(102836002)(53416004)(69596002)(66066001)(5004730100002)(107886002)(104016004)(33656002)(85806002)(81156007)(19625215002)(11100500001)(6806005)(16236675004)(5890100001)(87936001)(512954002)(2501003)(5003600100002)(5008740100001)(189998001)(110136002)(92566002)(84326002)(5001960100002)(2351001)(229853001)(106466001)(554374003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB158; H:ATBRAGMSX01.itiso.net; FPR:; SPF:Pass; PTR:unknown.zgrp.net; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DB4PR06MB158; 2:pHSM93avGvywBTKal1yQFoTrU+CI8Oq6Zcw8B0Kv5dGLU6hmpXytnfetPnqi+OknPMyPJoE22a8Q3Hbbd+i5jEsdL6vMAMW50fGrKLP5LmpxNvK5qSo2tg3AA7j5XplJzJilSQj5G9HbkfEFwNMDEGultcub8mZ2wjzhp7L8SSM=; 3:7GnGzoVFR1QvMchmkoTvQFGq2r2G7r5LR71hiaYeojiZ1nje7ara1eYHy38Q8LMmIXJ2xNL7pkcjb+fQvoUBJ315g9hutSAQG0+QKgM0qnDGuABqk3AjbJWh5j3jBYAQJ0U6/eBIqCT3HQ0hsAbjfrPPWeH0iUjFlKoKzQRWFHMhU/jq6BBMPxgZqzQuNVN76tMpgz1tScsHffVv3Tl4xihQ+xAkc63Gw8Ie2KoGP0OKe2e+FCYHcYTrK9gHRstZN2PwqT7kAb8etKuLGu3FrA==; 25:9Wn7xZEoko6vg7O5ruRTfPoadLIe2IIkclm1x4uFhoxYc4hA7D5TTF8Qf0J5o9FULx2ktS/dV8Zk4c+H+aBvct2CgA2LhCkFKHa1QrG5Cxq2K/79B3Yc7Uq4IgWGSoVM3Xe8eNssKA8zceVtx8TlQk6u4xH/Ld5HKINqIxZGrGHPhnLdCRiX3DObTRdNJf/FwDnYspTtfnxQJlybkV9K5kOJ0wDlJd4FU9kVLuKST8G38ksAXrG7cL8kXteH9kDdgBl1K0L/x2wu0Pwn1R7K7w== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501001); SRVR:DB4PR06MB158; X-Microsoft-Exchange-Diagnostics: 1; DB4PR06MB158; 20:dp3X6SlN8kd7bWjzaT27yHeqa0zrRw0F491RfucGwz4uM0yV06jWejBubd7cZ3J6CwRWdwtP7sE6sqW6DkE1OkPEjeLTHeCq/wLVoV6VoDpAiW9TAJU0my7ZPpsWt38mLQrSx2cFMWIzylaXBOB3VCHew99CodmO4pvsb0tn1LH9hEMWYKYH/8lMbqjrcpnKy59GghFp0p9FaXTHzYoedoC980EhaS9BviXS0o+MjwKO2C94KqjVpVlw02c0XgtfeBv9zIvtoxoDxOC9jsROk1RM2/LICZcjuTmqkKwaAidxTIYAi8ER3Stz/1pXGd50rWAkac2l8hRKctG6u4hplUM9pOPAxQhZRAqxccKRbCDQAHR90gHJPjMd7QK4YJjDB42vsSxmQJCmRspfzP9lN9p22oTjBcUr5HiY9dOzye9QjN8+aZ/ep3ArAXoZjXTBPCzwIdmN/l6TNo6wzVfbgPOGJfCoiyWZ3Sdft9Wui06WqNVUrvAfdAqOhIOZkHbi; 4:OOO+OctDNTxp3HLUQIKnyd00B5eXLVxGmhVR94JtTC6f7us94gGbnhuY3qBDidp37Qwyk10GT7stgE3+gCuz6A9oHCm38pZVqczx6/zPKdXj+hk0vMRFZ5C3kOdoleK5hZwrAgwkO8vgFZ6Evuq2SHpXU/c7IjFId55GcFEr9BUa8Xgb0a4Uf/7n/l19qcvUY6GajY2dlphXfqqJACqM5Wv9YS7LGO18uVPS/8dP1f/4KeEAN6oLECJmFVC7RWFqdg8GgLZHKmdT+5qQ+FLCC0oFd0fHHtZE8rQfRdbiSXnyPDnRERmuCw5uO5nsE29tijWN3MXfRNzdcsuMGEW0jrMdEFsMx5l40/erRAlAu3H5vtB5elCP1iBtHncJK1dp X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(108003899814671); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(10201501046)(3002001); SRVR:DB4PR06MB158; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB158; X-Forefront-PRVS: 07630F72AD X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DB4PR06MB158; 23:WrLoHlye0OkXQ/8pawbiMWmB9fl7PK9wWqCW1AKpSV?= =?us-ascii?Q?L+xc78KAfi6QMicvSchVXxfI5hQb8XRWmxcDirkB++GWrAlVxbwxb0+NZt9T?= =?us-ascii?Q?KtGpyaG2JBzNJWCi3ySTgYGMzRCEuvEzTArczCUaPfRvwNSL1Ts0Hv8olkPE?= =?us-ascii?Q?9A0oTUT89KAegQABSjKHtD9Z/VCyDJD79KTWoaBggh9rVq3LCfEG2e2wZznf?= =?us-ascii?Q?3Rpj7tJ+FI1BDT0jG9NpDCkESvLH8VlHMy1Qkp9NdNngGTBNKVJsJCw7b/oy?= =?us-ascii?Q?6YiHh12a1vBg1e+lxzyHawGXnhMsC8D3OPIkefoRu0c7B13xSB/5mdPEaa87?= =?us-ascii?Q?q/9kJiDzioU4CqoISa656H6Ld3rvWqo0DCtILn/Fzm1uRFcK5IFnEWvZ4QM/?= =?us-ascii?Q?XoVEHMt92pbQScXoMFHDca0l8TilQUyfQuZ0FX+P8LMZwFSK7CMI5fXxuIV7?= =?us-ascii?Q?hWR/CC1N4+B/CAa6CCEz+sbEXcqTnlQwiSXLwe+oG8m6BLsAE0vhcL59P/YJ?= =?us-ascii?Q?Ooe5WPvgRmPmvz5TGDjfRG4ISXfxhUq/e6lUfUcz3NH7qgQLUoF30NuvKfCt?= =?us-ascii?Q?SKC5Aqk2vkZwOqrYdIfkZrFZKkrCeU4mpdwgvFszouAO6GpSZoavsZWdGZ+v?= =?us-ascii?Q?0c7rbVU/mvpamCvIi+fg6nMMFw7wcDWQrIf7OHSOX5GB7ZP9wPapPCc/Kltg?= =?us-ascii?Q?dpXiCibP4r/YqB8hHlr5xUuQ/MOqDtF4p85nlJXaNGucbVPjaiv8FO34Qg/P?= =?us-ascii?Q?PS0FY0+1cC1fp44I4luA9jgzBn2yIwC29arYxMwEzmHeBa1YGh6wLrDtNT24?= =?us-ascii?Q?Tmlu9wPRbBG+9C4nQMga+IvtVPnAGkFhJ4fZhWwRaxi5Klnzj+sXEPFME+bN?= =?us-ascii?Q?iZblQ2jPiTdl5Hru3ML5IVOZb53db8Ey23UeNjiK5CUE+JE4ZSnT6HxEqiyn?= =?us-ascii?Q?i4iWgG5WKfzolx1caOp/o9Sr3SwSV6dWumL/oH/s16S0nilc53ZkSFGEzbix?= =?us-ascii?Q?HXbGGgmlnNU513EV74sz67My/SckRXTURU/UIG6y2x9yu0rkN7a4tvG9SvHR?= =?us-ascii?Q?dSFwY70EA7LdKGQdW97wmbFmXKN8RkHGamlYu4HNJMSizaH/Px+p7p57ue2i?= =?us-ascii?Q?ZqLOW11Qw6P2B7xv/sOVVRsWXP1j9FaTFirWXITjBJtw5OSEj8ww44q2cyi2?= =?us-ascii?Q?MW5UOrIfCo+5438NaNSHoD2aKqv2F3HVqJRLtOOrb9qCLsIZUio8V1tbSs0g?= =?us-ascii?Q?4uhXRwV2YUSFgqLGdvA7eFhP6C/j+Mcl4kIOYc2/xZ3WXTdw9E2+RZsPT0Qa?= =?us-ascii?Q?NhY0f/82oryJ9YfqqLX5VQBIxAhZmQZLiq+2/PXbrefjSH3fQ8rTsLn8SR93?= =?us-ascii?Q?A06GxMfM64rQJOjkX4YM76/Iuqx43N1VyroaBrKeBq10RJMbfd5sztTX/oE6?= =?us-ascii?Q?TBFDUNlz3B2djict8tICpPXnj3FPc=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB4PR06MB158; 5:aLoSVHqih0HNlLFs0NWROmHCCayfVZXnUTR7cMage/KB+EqJQ0pEYcS/zJe4fumkNu6Hnp6esvhlGKToufgvoSRKPmmioFMBu3o4leBHxxu4gEP4tUjGwamPgXPV/HUB1lQTkFf+z91uNLeNyyIcDQ==; 24:ivYFpfGoeCVobBc33/meXafTHkwQtbKBLf+Z6lnc1GFwoqb+VbW+u8ZQMsYybUu5D5mVQIun8T1IXdbpetWXuD657N+1dOmuqsBmeFLuft0=; 20:YXVimDVpc2FJCF/3grhDWTVNvC590G/bSVyrriWDUdgEuR8+GrmFMLr9RFP1DupC6ghUhEfzzTbFu4r0gAB1Rg== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: tridonic.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Nov 2015 13:45:15.1073 (UTC) X-MS-Exchange-CrossTenant-Id: 8b206608-a593-4ace-a4b6-ef1fc83c9169 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8b206608-a593-4ace-a4b6-ef1fc83c9169; Ip=[146.108.200.10]; Helo=[ATBRAGMSX01.itiso.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB158 Archived-At: Subject: [Ace] [ACE] Permanant client-server relations and draft-seitz-ace-oauth-authz-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 13:45:44 -0000 --_000_0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC07DATBRAGMSX02itis_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have reviewed the draft and find that is very nicely written and easy to = understand. It would be nice to see this document taken further and made in= to an RFC. I have a question regarding the usage of OAuth in constrained networks. In = web architectures, OAuth is used a lot. However, in the constrained world, = I am not sure if it applies to every situation. Typically, in constrained n= etworks we have three types of connections: constrained device<->central (m= anagement) server(s), constrained device<-> temporary devices (e.g. mobile = apps) and constrained device<->constrained device. For the constrained devi= ce<-> temporary devices (e.g. mobile apps) OAuth seems to work quite nicely= and probably even for constrained device<->central (management) server(s). I would like to focus on the constrained device<->constrained device to cas= e. In this case, we typically have permanent authorization rules that conne= ct e.g. sensors to actuators (pushbuttons connected to lights). For such pe= rmanent authorization rules that do not change, does it still make sense to= use OAuth. I would have thought that an access control list type solution = that is managed by a central server is more suitable for this situation. I = would like to understand from the authors exactly which type of communicati= on is being targeted in this draft and if it is also applicable to create "= permanent client-server authorization rules". Abhinav ________________________________________________________ The contents of th= is e-mail and any attachments are confidential to the intended recipient. T= hey may not be disclosed to or used by or copied in any way by anyone other= than the intended recipient. If this e-mail is received in error, please i= mmediately notify the sender and delete the e-mail and attached documents. = Please note that neither the sender nor the sender's company accept any res= ponsibility for viruses and it is your responsibility to scan or otherwise = check this e-mail and any attachments. --_000_0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC07DATBRAGMSX02itis_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have reviewed the draft and find that is very nice= ly written and easy to understand. It would be nice to see this document ta= ken further and made into an RFC.

 

I have a question regarding the usage of OAuth in co= nstrained networks. In web architectures, OAuth is used a lot. However, in = the constrained world, I am not sure if it applies to every situation. Typi= cally, in constrained networks we have three types of connections: constrained device<->central (manag= ement) server(s), constrained device<-> temporary devices (e.g. mobil= e apps) and constrained device<->constrained device. For the constrai= ned device<-> temporary devices (e.g. mobile apps) OAuth seems to work quite nicely and probably even for constrained device&= lt;->central (management) server(s).

 

I would like to focus on the constrained device<-= >constrained device to case. In this case, we typically have permanent a= uthorization rules that connect e.g. sensors to actuators (pushbuttons conn= ected to lights). For such permanent authorization rules that do not change, does it still make sense to use OAuth. I would h= ave thought that an access control list type solution that is managed by a = central server is more suitable for this situation. I would like to underst= and from the authors exactly which type of communication is being targeted in this draft and if it is also ap= plicable to create “permanent client-server authorization rules”= ;.

 

Abhinav

________________________________________________________ The contents of th= is e-mail and any attachments are confidential to the intended recipient. T= hey may not be disclosed to or used by or copied in any way by anyone other= than the intended recipient. If this e-mail is received in error, please immediately notify the sender and= delete the e-mail and attached documents. Please note that neither the sen= der nor the sender's company accept any responsibility for viruses and it i= s your responsibility to scan or otherwise check this e-mail and any attachments. --_000_0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC07DATBRAGMSX02itis_-- From nobody Wed Nov 18 00:11: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 62D471A21A0 for ; Wed, 18 Nov 2015 00:11:26 -0800 (PST) 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 8DL9RvGBAyYq for ; Wed, 18 Nov 2015 00:11:23 -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 1C01B1A1ACA for ; Wed, 18 Nov 2015 00:11:22 -0800 (PST) X-AuditID: c1b4fb25-f79a26d00000149a-08-564c32a95330 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 9E.DA.05274.9A23C465; Wed, 18 Nov 2015 09:11:21 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.32]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0248.002; Wed, 18 Nov 2015 09:11:20 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Somaraju Abhinav , "ace@ietf.org" Thread-Topic: [Ace] [ACE] Permanant client-server relations and draft-seitz-ace-oauth-authz-00 Thread-Index: AQHRIdi03eDj+Zzso062j6zBTSNW9g== Date: Wed, 18 Nov 2015 08:11:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_D271E6F13E196goranselanderericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM2K7pe5KI58wg3d7eC2OXOG0+P6th9mB yWPJkp9MHid+7mINYIrisklJzcksSy3St0vgythy6j1bwev6ipbdTSwNjBtquhg5OSQETCSO Lj7NDGGLSVy4t56ti5GLQ0jgMKPEke0d7BDOYkaJ599aGEGq2ARcJB40PGICsUUEQiXmrTgG VMTBISwQL3H7gx5EOEFiXccqFghbT+L9nV9sIDaLgKrE6SPrweK8AhYS8278BbMZgRZ/P7UG bCSzgLjErSfzmSAOEpBYsuc81HGiEi8f/2MFsUWBZq683sQGEVeSWHT7M1RvrMSj5m42iPmC EidnPmGZwCg8C8nYWUjKZiEpmwX0AbOApsT6XfoQJYoSU7ofskPYGhKtc+ayQ5RYS/ReDkBW soCRYxWjaHFqcVJuupGxXmpRZnJxcX6eXl5qySZGYEQd3PJbdQfj5TeOhxgFOBiVeHgLNnqH CbEmlhVX5h5ilOBgVhLhfa/rEybEm5JYWZValB9fVJqTWnyIUZqDRUmct5npQaiQQHpiSWp2 ampBahFMlomDU6qB0ZW11Ish6OA3q1XKUz1mxDQujqri8A1/9VXhxBflmKP3Hk8UNJje/HLv N+mF7YePT+As23H/++YN8iJL50iJ6cqJLExqPm/Y4MKqcnTFo7eb5HaWP+k8rnqJx0V2Zv+v cMbJ5/o3H3/rE6VY2GS2X0zZ71NCgbTmlahvHg5aGQu35p2af+HkAiWW4oxEQy3mouJEAFKc yDqkAgAA Archived-At: Subject: Re: [Ace] [ACE] Permanant client-server relations and draft-seitz-ace-oauth-authz-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 08:11:26 -0000 --_000_D271E6F13E196goranselanderericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWJoaW5hdiwNCg0KVGhhbmtzIGZvciBraW5kIGZlZWRiYWNrLg0KDQpPbmUgb2YgdGhlIGNo YWxsZW5naW5nIHRhc2tzIHRoYXQgdGhpcyBkcmFmdCBpcyB0cnlpbmcgdG8gYWRkcmVzcyBpcyB0 aGUgY2FzZSBvZiBkeW5hbWljIGFjY2VzcyBjb250cm9sLCBpbiB0aGUgc2Vuc2Ugb2YgYWNjZXNz IHJpZ2h0cyBub3QgYmVpbmcgc3RhdGljIGJ1dCBtYXkgZm9yIHNvbWUgcmVhc29uIGNoYW5nZSBv dmVyIHRpbWUuIEV4YW1wbGVzIG9mIHRoaXMgaW5jbHVkZSBuZXcgY2xpZW50cyBub3Qga25vd24g dGhlIHJlc291cmNlIHNlcnZlciAoc2Vuc29yL2FjdHVhdG9yKSBhcmUgYmVpbmcgZ3JhbnRlZCBh Y2Nlc3MsIG9yIGNoYW5nZXMgb2YgYWNjZXNzIHBvbGljaWVzIGJ5IHRoZSByZXNvdXJjZSBvd25l cnMgd2hpY2ggbmVlZHMgdG8gYmUgZW5mb3JjZWQgaW4gdGhlIHJlc291cmNlIHNlcnZlcnMuIFRo aXMgYXBwbGllcyBhbGwgc29ydHMgb2YgY2xpZW50cyBhbmQgcmVzb3VyY2Ugc2VydmVycywgY29u c3RyYWluZWQgb3Igbm9uLWNvbnN0cmFpbmVkLCBtb2JpbGUgb3IgZml4ZWQuICBPbmNlIHRoZSBp bmZvcm1hdGlvbiBhYm91dCB0aGUgYWNjZXNzIHJpZ2h0cyBpcyBjb21tdW5pY2F0ZWQsIGUuZy4g YnkgbWVhbnMgb2YgYW4gYWNjZXNzIHRva2VuIHRvIHRoZSByZXNvdXJjZSBzZXJ2ZXIsIHRoZSBh Y2Nlc3MgY29udHJvbCBkZWNpc2lvbiBjYW4gYmUgZW5mb3JjZWQgdGhlcmUgd2hlbiB0aGUgY2xp ZW50IG1ha2VzIGEgcmVxdWVzdC4gRGVwZW5kaW5nIG9uIGhvdyBsb25nIHRpbWUgdGhlIGFjY2Vz cyByaWdodCBpcyB2YWxpZCwgd2hpY2ggbWF5IGJlIGFyYml0cmFyaWx5IGxvbmcgdGltZSwgdGhl cmUgbWF5IGJlIG5vIG5lZWQgdG8gdXBkYXRlIHRoaXMgaW5mb3JtYXRpb24gYW5kIHRoZW4gdGhl c2UgcHJvdmlzaW9uZWQgYXV0aG9yaXphdGlvbiBydWxlcyB3aWxsIGdvdmVybiB0aGUgcmlnaHRz IHRvIGFjY2VzcyB0byB0aGlzIHNlbnNvciBvciBhY3R1YXRvci4gIEluIHRoaXMgc2Vuc2Ug4oCc cGVybWFuZW504oCdIGNsaWVudC1zZXJ2ZXIgcmVsYXRpb25zIG1heSBiZSB2aWV3ZWQgYXMgYSBz cGVjaWFsIGNhc2Ugb2YgdGhlIGR5bmFtaWMgYWNjZXNzIHJpZ2h0cy4gRm9yIGV4YW1wbGUsIGl0 IGlzIHBvc3NpYmxlIHRvIHVzZSB0aGUgcHJvdG9jb2wgZGVzY3JpYmVkIGluIHRoaXMgZHJhZnQg dG8gcHJvdmlzaW9uIOKAnHBlcm1hbmVudCIgYXV0aG9yaXphdGlvbiBydWxlcyBkdXJpbmcgYSBk ZXBsb3ltZW50IHBoYXNlIHdoaWNoIHRvIGJlIHN1YnNlcXVlbnRseSB1c2VkIHRocm91Z2hvdXQg dGhlIGxpZmV0aW1lIG9mIHRoZSBkZXZpY2VzLiBBcyBhbm90aGVyIGV4YW1wbGUgaXQgaXMgYWxz byBwb3NzaWJsZSB0byB1c2Ugb2YgcGVybWFuZW50IOKAnGFjY2VzcyBwcm9maWxlc+KAnSAoY29t YmluYXRpb24gb2YgYWNjZXNzIHJpZ2h0cyB0byBkaWZmZXJlbnQgcmVzb3VyY2VzIGdyb3VwZWQg aW50byBhIHByb2ZpbGUpIHByZWRlZmluZWQgZm9yIGEgZ2l2ZW4gZGV2aWNlLCBhbmQgY29tYmlu ZSB0aGF0IHdpdGggYSBkeW5hbWljIGFsbG9jYXRpb24gb2YgY2xpZW50IHRvIHJlc3BlY3RpdmUg YWNjZXNzIHByb2ZpbGUuIFRoZSBtYXBwaW5nIG9mIGNsaWVudCB0byBhY2Nlc3MgcHJvZmlsZSBj b3VsZCBlLmcuIGJlIHNlY3VyZWx5IGNhcnJpZWQgaW4gdGhlIGFjY2VzcyB0b2tlbi4gSWYsIGhv d2V2ZXIsIGFsbCBhY2Nlc3MgcmlnaHRzIGFyZSBwcmUtcHJvdmlzaW9uZWQgYW5kIHN0YXRpYywg dGhlbiBJIGRvbuKAmXQgc2VlIHRoZSBuZWVkIGZvciB0aGUgcHJvdG9jb2wgZGVzY3JpYmVkIGlu IHRoaXMgZHJhZnQgKGZvciB0aGUgcHVycG9zZSBvZiBhdXRob3JpemF0aW9uOyBpdCBtYXkgc3Rp bGwgYmUgdXNlZCBmb3Iga2V5IGVzdGFibGlzaG1lbnQpLg0KDQpJIGRvbuKAmXQga25vdyBpZiB0 aGlzIGFuc3dlcmVkIHlvdXIgcXVlc3Rpb24uIFBsZWFzZSBsZXQgbWUga25vdyBvdGhlcndpc2Uu DQoNCkfDtnJhbg0KDQoNCg0KRnJvbTogU29tYXJhanUgQWJoaW5hdiA8YWJoaW5hdi5zb21hcmFq dUB0cmlkb25pYy5jb208bWFpbHRvOmFiaGluYXYuc29tYXJhanVAdHJpZG9uaWMuY29tPj4NCkRh dGU6IFR1ZXNkYXkgMTcgTm92ZW1iZXIgMjAxNSAxNDo0Mg0KVG86ICJhY2VAaWV0Zi5vcmc8bWFp bHRvOmFjZUBpZXRmLm9yZz4iIDxhY2VAaWV0Zi5vcmc8bWFpbHRvOmFjZUBpZXRmLm9yZz4+DQpT dWJqZWN0OiBbQWNlXSBbQUNFXSBQZXJtYW5hbnQgY2xpZW50LXNlcnZlciByZWxhdGlvbnMgYW5k IGRyYWZ0LXNlaXR6LWFjZS1vYXV0aC1hdXRoei0wMA0KDQpIaSwNCg0KSSBoYXZlIHJldmlld2Vk IHRoZSBkcmFmdCBhbmQgZmluZCB0aGF0IGlzIHZlcnkgbmljZWx5IHdyaXR0ZW4gYW5kIGVhc3kg dG8gdW5kZXJzdGFuZC4gSXQgd291bGQgYmUgbmljZSB0byBzZWUgdGhpcyBkb2N1bWVudCB0YWtl biBmdXJ0aGVyIGFuZCBtYWRlIGludG8gYW4gUkZDLg0KDQpJIGhhdmUgYSBxdWVzdGlvbiByZWdh cmRpbmcgdGhlIHVzYWdlIG9mIE9BdXRoIGluIGNvbnN0cmFpbmVkIG5ldHdvcmtzLiBJbiB3ZWIg YXJjaGl0ZWN0dXJlcywgT0F1dGggaXMgdXNlZCBhIGxvdC4gSG93ZXZlciwgaW4gdGhlIGNvbnN0 cmFpbmVkIHdvcmxkLCBJIGFtIG5vdCBzdXJlIGlmIGl0IGFwcGxpZXMgdG8gZXZlcnkgc2l0dWF0 aW9uLiBUeXBpY2FsbHksIGluIGNvbnN0cmFpbmVkIG5ldHdvcmtzIHdlIGhhdmUgdGhyZWUgdHlw ZXMgb2YgY29ubmVjdGlvbnM6IGNvbnN0cmFpbmVkIGRldmljZTwtPmNlbnRyYWwgKG1hbmFnZW1l bnQpIHNlcnZlcihzKSwgY29uc3RyYWluZWQgZGV2aWNlPC0+IHRlbXBvcmFyeSBkZXZpY2VzIChl LmcuIG1vYmlsZSBhcHBzKSBhbmQgY29uc3RyYWluZWQgZGV2aWNlPC0+Y29uc3RyYWluZWQgZGV2 aWNlLiBGb3IgdGhlIGNvbnN0cmFpbmVkIGRldmljZTwtPiB0ZW1wb3JhcnkgZGV2aWNlcyAoZS5n LiBtb2JpbGUgYXBwcykgT0F1dGggc2VlbXMgdG8gd29yayBxdWl0ZSBuaWNlbHkgYW5kIHByb2Jh Ymx5IGV2ZW4gZm9yIGNvbnN0cmFpbmVkIGRldmljZTwtPmNlbnRyYWwgKG1hbmFnZW1lbnQpIHNl cnZlcihzKS4NCg0KSSB3b3VsZCBsaWtlIHRvIGZvY3VzIG9uIHRoZSBjb25zdHJhaW5lZCBkZXZp Y2U8LT5jb25zdHJhaW5lZCBkZXZpY2UgdG8gY2FzZS4gSW4gdGhpcyBjYXNlLCB3ZSB0eXBpY2Fs bHkgaGF2ZSBwZXJtYW5lbnQgYXV0aG9yaXphdGlvbiBydWxlcyB0aGF0IGNvbm5lY3QgZS5nLiBz ZW5zb3JzIHRvIGFjdHVhdG9ycyAocHVzaGJ1dHRvbnMgY29ubmVjdGVkIHRvIGxpZ2h0cykuIEZv ciBzdWNoIHBlcm1hbmVudCBhdXRob3JpemF0aW9uIHJ1bGVzIHRoYXQgZG8gbm90IGNoYW5nZSwg ZG9lcyBpdCBzdGlsbCBtYWtlIHNlbnNlIHRvIHVzZSBPQXV0aC4gSSB3b3VsZCBoYXZlIHRob3Vn aHQgdGhhdCBhbiBhY2Nlc3MgY29udHJvbCBsaXN0IHR5cGUgc29sdXRpb24gdGhhdCBpcyBtYW5h Z2VkIGJ5IGEgY2VudHJhbCBzZXJ2ZXIgaXMgbW9yZSBzdWl0YWJsZSBmb3IgdGhpcyBzaXR1YXRp b24uIEkgd291bGQgbGlrZSB0byB1bmRlcnN0YW5kIGZyb20gdGhlIGF1dGhvcnMgZXhhY3RseSB3 aGljaCB0eXBlIG9mIGNvbW11bmljYXRpb24gaXMgYmVpbmcgdGFyZ2V0ZWQgaW4gdGhpcyBkcmFm dCBhbmQgaWYgaXQgaXMgYWxzbyBhcHBsaWNhYmxlIHRvIGNyZWF0ZSDigJxwZXJtYW5lbnQgY2xp ZW50LXNlcnZlciBhdXRob3JpemF0aW9uIHJ1bGVz4oCdLg0KDQpBYmhpbmF2DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBUaGUgY29udGVu dHMgb2YgdGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRv IHRoZSBpbnRlbmRlZCByZWNpcGllbnQuIFRoZXkgbWF5IG5vdCBiZSBkaXNjbG9zZWQgdG8gb3Ig dXNlZCBieSBvciBjb3BpZWQgaW4gYW55IHdheSBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50LiBJZiB0aGlzIGUtbWFpbCBpcyByZWNlaXZlZCBpbiBlcnJvciwgcGxl YXNlIGltbWVkaWF0ZWx5IG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhlIGUtbWFpbCBh bmQgYXR0YWNoZWQgZG9jdW1lbnRzLiBQbGVhc2Ugbm90ZSB0aGF0IG5laXRoZXIgdGhlIHNlbmRl ciBub3IgdGhlIHNlbmRlcidzIGNvbXBhbnkgYWNjZXB0IGFueSByZXNwb25zaWJpbGl0eSBmb3Ig dmlydXNlcyBhbmQgaXQgaXMgeW91ciByZXNwb25zaWJpbGl0eSB0byBzY2FuIG9yIG90aGVyd2lz ZSBjaGVjayB0aGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzLg0K --_000_D271E6F13E196goranselanderericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <119AC83988D212478FC5EC39A7B61F68@ericsson.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBBYmhpbmF2 LDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmtzIGZvciBraW5kIGZlZWRiYWNr LiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+T25lIG9mIHRoZSBjaGFsbGVu Z2luZyB0YXNrcyB0aGF0IHRoaXMgZHJhZnQgaXMgdHJ5aW5nIHRvIGFkZHJlc3MgaXMgdGhlIGNh c2Ugb2YgZHluYW1pYyBhY2Nlc3MgY29udHJvbCwgaW4gdGhlIHNlbnNlIG9mIGFjY2VzcyByaWdo dHMgbm90IGJlaW5nIHN0YXRpYyBidXQgbWF5IGZvciBzb21lIHJlYXNvbiBjaGFuZ2Ugb3ZlciB0 aW1lLiBFeGFtcGxlcyBvZiB0aGlzIGluY2x1ZGUgbmV3IGNsaWVudHMgbm90IGtub3duIHRoZSBy ZXNvdXJjZQ0KIHNlcnZlciAoc2Vuc29yL2FjdHVhdG9yKSBhcmUgYmVpbmcgZ3JhbnRlZCBhY2Nl c3MsIG9yIGNoYW5nZXMgb2YgYWNjZXNzIHBvbGljaWVzIGJ5IHRoZSByZXNvdXJjZSBvd25lcnMg d2hpY2ggbmVlZHMgdG8gYmUgZW5mb3JjZWQgaW4gdGhlIHJlc291cmNlIHNlcnZlcnMuIFRoaXMg YXBwbGllcyBhbGwgc29ydHMgb2YgY2xpZW50cyBhbmQgcmVzb3VyY2Ugc2VydmVycywgY29uc3Ry YWluZWQgb3Igbm9uLWNvbnN0cmFpbmVkLCBtb2JpbGUgb3IgZml4ZWQuDQogJm5ic3A7T25jZSB0 aGUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGFjY2VzcyByaWdodHMgaXMgY29tbXVuaWNhdGVkLCBl LmcuIGJ5IG1lYW5zIG9mIGFuIGFjY2VzcyB0b2tlbiB0byB0aGUgcmVzb3VyY2Ugc2VydmVyLCB0 aGUgYWNjZXNzIGNvbnRyb2wgZGVjaXNpb24gY2FuIGJlIGVuZm9yY2VkIHRoZXJlIHdoZW4gdGhl IGNsaWVudCBtYWtlcyBhIHJlcXVlc3QuIERlcGVuZGluZyBvbiBob3cgbG9uZyB0aW1lIHRoZSBh Y2Nlc3MgcmlnaHQgaXMgdmFsaWQsDQogd2hpY2ggbWF5IGJlIGFyYml0cmFyaWx5IGxvbmcgdGlt ZSwgdGhlcmUgbWF5IGJlIG5vIG5lZWQgdG8gdXBkYXRlIHRoaXMgaW5mb3JtYXRpb24gYW5kIHRo ZW4gdGhlc2UgcHJvdmlzaW9uZWQgYXV0aG9yaXphdGlvbiBydWxlcyB3aWxsIGdvdmVybiB0aGUg cmlnaHRzIHRvIGFjY2VzcyB0byB0aGlzIHNlbnNvciBvciBhY3R1YXRvci4gJm5ic3A7SW4gdGhp cyBzZW5zZSDigJxwZXJtYW5lbnTigJ0gY2xpZW50LXNlcnZlciByZWxhdGlvbnMgbWF5IGJlIHZp ZXdlZA0KIGFzIGEgc3BlY2lhbCBjYXNlIG9mIHRoZSBkeW5hbWljIGFjY2VzcyByaWdodHMuIEZv ciBleGFtcGxlLCBpdCBpcyBwb3NzaWJsZSB0byB1c2UgdGhlIHByb3RvY29sIGRlc2NyaWJlZCBp biB0aGlzIGRyYWZ0IHRvIHByb3Zpc2lvbiDigJxwZXJtYW5lbnQmcXVvdDsgYXV0aG9yaXphdGlv biBydWxlcyBkdXJpbmcgYSBkZXBsb3ltZW50IHBoYXNlIHdoaWNoIHRvIGJlIHN1YnNlcXVlbnRs eSB1c2VkIHRocm91Z2hvdXQgdGhlIGxpZmV0aW1lIG9mIHRoZSBkZXZpY2VzLg0KIEFzIGFub3Ro ZXIgZXhhbXBsZSBpdCBpcyBhbHNvIHBvc3NpYmxlIHRvIHVzZSBvZiBwZXJtYW5lbnQg4oCcYWNj ZXNzIHByb2ZpbGVz4oCdIChjb21iaW5hdGlvbiBvZiBhY2Nlc3MgcmlnaHRzIHRvIGRpZmZlcmVu dCByZXNvdXJjZXMgZ3JvdXBlZCBpbnRvIGEgcHJvZmlsZSkgcHJlZGVmaW5lZCBmb3IgYSBnaXZl biBkZXZpY2UsIGFuZCBjb21iaW5lIHRoYXQgd2l0aCBhIGR5bmFtaWMgYWxsb2NhdGlvbiBvZiBj bGllbnQgdG8gcmVzcGVjdGl2ZSBhY2Nlc3MNCiBwcm9maWxlLiBUaGUgbWFwcGluZyBvZiBjbGll bnQgdG8gYWNjZXNzIHByb2ZpbGUgY291bGQgZS5nLiBiZSBzZWN1cmVseSBjYXJyaWVkIGluIHRo ZSBhY2Nlc3MgdG9rZW4uIElmLCBob3dldmVyLCBhbGwgYWNjZXNzIHJpZ2h0cyBhcmUgcHJlLXBy b3Zpc2lvbmVkIGFuZCBzdGF0aWMsIHRoZW4gSSBkb27igJl0IHNlZSB0aGUgbmVlZCBmb3IgdGhl IHByb3RvY29sIGRlc2NyaWJlZCBpbiB0aGlzIGRyYWZ0IChmb3IgdGhlIHB1cnBvc2Ugb2YgYXV0 aG9yaXphdGlvbjsNCiBpdCBtYXkgc3RpbGwgYmUgdXNlZCBmb3Iga2V5IGVzdGFibGlzaG1lbnQp LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSBkb27igJl0IGtub3cgaWYgdGhpcyBh bnN3ZXJlZCB5b3VyIHF1ZXN0aW9uLiBQbGVhc2UgbGV0IG1lIGtub3cgb3RoZXJ3aXNlLjwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+R8O2cmFuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NS Q19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1z aXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1l ZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47 IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0 ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0 Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+U29tYXJhanUg QWJoaW5hdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFiaGluYXYuc29tYXJhanVAdHJpZG9uaWMuY29t Ij5hYmhpbmF2LnNvbWFyYWp1QHRyaWRvbmljLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9 ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5UdWVzZGF5IDE3IE5vdmVtYmVyIDIwMTUg MTQ6NDI8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj4mcXVv dDs8YSBocmVmPSJtYWlsdG86YWNlQGlldGYub3JnIj5hY2VAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86YWNlQGlldGYub3JnIj5hY2VAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4N CjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+W0FjZV0gW0FD RV0gUGVybWFuYW50IGNsaWVudC1zZXJ2ZXIgcmVsYXRpb25zIGFuZCBkcmFmdC1zZWl0ei1hY2Ut b2F1dGgtYXV0aHotMDA8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1M RUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4N CjxkaXYgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29m dCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQovKiBGb250IERlZmlu aXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6 MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNw YW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjxkaXYgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhh dmUgcmV2aWV3ZWQgdGhlIGRyYWZ0IGFuZCBmaW5kIHRoYXQgaXMgdmVyeSBuaWNlbHkgd3JpdHRl biBhbmQgZWFzeSB0byB1bmRlcnN0YW5kLiBJdCB3b3VsZCBiZSBuaWNlIHRvIHNlZSB0aGlzIGRv Y3VtZW50IHRha2VuIGZ1cnRoZXIgYW5kIG1hZGUgaW50byBhbiBSRkMuDQo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SSBoYXZlIGEgcXVlc3Rpb24gcmVnYXJkaW5nIHRoZSB1c2FnZSBvZiBPQXV0 aCBpbiBjb25zdHJhaW5lZCBuZXR3b3Jrcy4gSW4gd2ViIGFyY2hpdGVjdHVyZXMsIE9BdXRoIGlz IHVzZWQgYSBsb3QuIEhvd2V2ZXIsIGluIHRoZSBjb25zdHJhaW5lZCB3b3JsZCwgSSBhbSBub3Qg c3VyZSBpZiBpdCBhcHBsaWVzIHRvIGV2ZXJ5IHNpdHVhdGlvbi4gVHlwaWNhbGx5LCBpbiBjb25z dHJhaW5lZCBuZXR3b3JrcyB3ZQ0KIGhhdmUgdGhyZWUgdHlwZXMgb2YgY29ubmVjdGlvbnM6IGNv bnN0cmFpbmVkIGRldmljZSZsdDstJmd0O2NlbnRyYWwgKG1hbmFnZW1lbnQpIHNlcnZlcihzKSwg Y29uc3RyYWluZWQgZGV2aWNlJmx0Oy0mZ3Q7IHRlbXBvcmFyeSBkZXZpY2VzIChlLmcuIG1vYmls ZSBhcHBzKSBhbmQgY29uc3RyYWluZWQgZGV2aWNlJmx0Oy0mZ3Q7Y29uc3RyYWluZWQgZGV2aWNl LiBGb3IgdGhlIGNvbnN0cmFpbmVkIGRldmljZSZsdDstJmd0OyB0ZW1wb3JhcnkgZGV2aWNlcyAo ZS5nLiBtb2JpbGUgYXBwcykNCiBPQXV0aCBzZWVtcyB0byB3b3JrIHF1aXRlIG5pY2VseSBhbmQg cHJvYmFibHkgZXZlbiBmb3IgY29uc3RyYWluZWQgZGV2aWNlJmx0Oy0mZ3Q7Y2VudHJhbCAobWFu YWdlbWVudCkgc2VydmVyKHMpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdvdWxkIGxpa2Ug dG8gZm9jdXMgb24gdGhlIGNvbnN0cmFpbmVkIGRldmljZSZsdDstJmd0O2NvbnN0cmFpbmVkIGRl dmljZSB0byBjYXNlLiBJbiB0aGlzIGNhc2UsIHdlIHR5cGljYWxseSBoYXZlIHBlcm1hbmVudCBh dXRob3JpemF0aW9uIHJ1bGVzIHRoYXQgY29ubmVjdCBlLmcuIHNlbnNvcnMgdG8gYWN0dWF0b3Jz IChwdXNoYnV0dG9ucyBjb25uZWN0ZWQgdG8gbGlnaHRzKS4gRm9yIHN1Y2ggcGVybWFuZW50IGF1 dGhvcml6YXRpb24NCiBydWxlcyB0aGF0IGRvIG5vdCBjaGFuZ2UsIGRvZXMgaXQgc3RpbGwgbWFr ZSBzZW5zZSB0byB1c2UgT0F1dGguIEkgd291bGQgaGF2ZSB0aG91Z2h0IHRoYXQgYW4gYWNjZXNz IGNvbnRyb2wgbGlzdCB0eXBlIHNvbHV0aW9uIHRoYXQgaXMgbWFuYWdlZCBieSBhIGNlbnRyYWwg c2VydmVyIGlzIG1vcmUgc3VpdGFibGUgZm9yIHRoaXMgc2l0dWF0aW9uLiBJIHdvdWxkIGxpa2Ug dG8gdW5kZXJzdGFuZCBmcm9tIHRoZSBhdXRob3JzIGV4YWN0bHkgd2hpY2gNCiB0eXBlIG9mIGNv bW11bmljYXRpb24gaXMgYmVpbmcgdGFyZ2V0ZWQgaW4gdGhpcyBkcmFmdCBhbmQgaWYgaXQgaXMg YWxzbyBhcHBsaWNhYmxlIHRvIGNyZWF0ZSDigJxwZXJtYW5lbnQgY2xpZW50LXNlcnZlciBhdXRo b3JpemF0aW9uIHJ1bGVz4oCdLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BYmhpbmF2PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fIFRoZSBjb250ZW50cyBvZiB0aGlzIGUtbWFpbCBhbmQgYW55IGF0 dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkIHJlY2lwaWVudC4gVGhl eSBtYXkgbm90IGJlIGRpc2Nsb3NlZCB0byBvciB1c2VkIGJ5IG9yIGNvcGllZCBpbiBhbnkgd2F5 IGJ5IGFueW9uZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQuIElmDQogdGhpcyBl LW1haWwgaXMgcmVjZWl2ZWQgaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSBub3RpZnkgdGhl IHNlbmRlciBhbmQgZGVsZXRlIHRoZSBlLW1haWwgYW5kIGF0dGFjaGVkIGRvY3VtZW50cy4gUGxl YXNlIG5vdGUgdGhhdCBuZWl0aGVyIHRoZSBzZW5kZXIgbm9yIHRoZSBzZW5kZXIncyBjb21wYW55 IGFjY2VwdCBhbnkgcmVzcG9uc2liaWxpdHkgZm9yIHZpcnVzZXMgYW5kIGl0IGlzIHlvdXIgcmVz cG9uc2liaWxpdHkgdG8gc2NhbiBvcg0KIG90aGVyd2lzZSBjaGVjayB0aGlzIGUtbWFpbCBhbmQg YW55IGF0dGFjaG1lbnRzLiA8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_D271E6F13E196goranselanderericssoncom_-- From nobody Wed Nov 18 00:14: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 C935F1A6FB9 for ; Wed, 18 Nov 2015 00:14:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.185 X-Spam-Level: X-Spam-Status: No, score=-3.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585, 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 XB2eisl8fJDG for ; Wed, 18 Nov 2015 00:14: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 A33C41A1B0C for ; Wed, 18 Nov 2015 00:14:38 -0800 (PST) Received: from [192.168.10.142] ([80.92.121.34]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LsTDk-1aNLNq3XpY-0124M2; Wed, 18 Nov 2015 09:14:35 +0100 To: Somaraju Abhinav , "ace@ietf.org" References: <0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC07D@ATBRAGMSX02.itiso.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <564C335F.4050404@gmx.net> Date: Wed, 18 Nov 2015 09:14:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC07D@ATBRAGMSX02.itiso.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="dID0IfhRUhf0P6TB2lfg2446MjUPfMLvG" X-Provags-ID: V03:K0:2aYnVHJnNiERWv+UKnIcc89xAXwsE3UrUTrDgg2e5N76W3stoLF 3ZpxMGFwPfNlOL4xM7Y0ceaA4CkQdl8aWrrM79me3KS3cXhY7ckNhgXUCM0k6Owi0qPhLj5 f2iuE7xP76QVeA+lzBH+rxXMl+eYgMt5cA6PALK1oLIcBJUTvIGogIgECu/lKN+LzRE4++z 8ET8UN2a6FDedaKEaVMfw== X-UI-Out-Filterresults: notjunk:1;V01:K0:tE6oKgs3X9Q=:CptPspISVxldbEIA8bG2yw tx9zVaQ6xh5N+DFgaO8aLRnRjt6lUxta4A3SGNFGtSTTDcOeZMJy1pNGXCu3qBMGn099pcPdI 8E2ZHFc0W+wY8z2IwrQr6uaoNuSD0niPChoWERwM9u1KWM1Eg6rH87N8T2+m9L3jhVd19RpfJ n8pBYD4lzRIafzkjvzVwpS51QxDtS0jqptcGEa4NTf5tH/z+koLgmOqR2lAgMNQRwthK7hhuD J+62ufj9irqxwDB4COcKO+rPiUrvCINlXPhpQ8oZV66SyjyW+g2M+iYDeOnGuDBAkMxBSEOpN 1CaXJXEwsNLMXiWaODbHMjsou6cSYNnsiSZ20to9R4uwOytG1KV5SbnxFvwhvFMXdGHtC01Sd W3q2sJzHmpVmDlSftPW6PobfYh6asSyHmlCGVucxsB4pN8my70hXdbgldaFz/t16/oPsXXgGX 9e5k/gozefBhbacAC745XYuvNjHl7HXLtYcf0ogBbmrWazH/54vNt3TmffLecV3X9LS7RT5yM uhopImsVW9MRQ+F6JAVgaAby7JinZCEs1X9bI5aXprW78u4no3Z+JZRg68b2hknXtWMZ5Jr6V NNRhlHaKcNzv6pwFpwBqzVY2Hqnjg59bBLLvq7dtB1NwhW8wl8QCYyBNlYSqkugnAtU4JLyun KsultBTAPqXIq0Cw3gyZSpNIYDxPkmDfh2TZZoSqVVZnlOV0Rw0Of1ozW/n9jg96ylhR1PtuS ebmPmntIZ3d0gB/YKN/I81p5A4dGPI5AEO6f7pJIu9odVAQBDBwnZjQLF9s= Archived-At: Subject: Re: [Ace] [ACE] Permanant client-server relations and draft-seitz-ace-oauth-authz-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 08:14:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dID0IfhRUhf0P6TB2lfg2446MjUPfMLvG Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Abhinav, > I have reviewed the draft and find that is very nicely written and easy= > to understand. It would be nice to see this document taken further and > made into an RFC. Thanks. ~snip~ > I would like to focus on the constrained device<->constrained device to= > case. In this case, we typically have permanent authorization rules tha= t > connect e.g. sensors to actuators (pushbuttons connected to lights). Fo= r > such permanent authorization rules that do not change, does it still > make sense to use OAuth. I would have thought that an access control > list type solution that is managed by a central server is more suitable= > for this situation. I would like to understand from the authors exactly= > which type of communication is being targeted in this draft and if it i= s > also applicable to create =93permanent client-server authorization rule= s=94. The constrained client to constrained server case is conceptually simpler than the other cases since the authorization step, as you noted, already happened out-of-band (by someone). This scenario motivated me to write this IoT credential grant, see draft-tschofenig-oauth-iot. In response to the draft submission I got comments that claimed I can get the same functionality already with base OAuth, which may need to be discussed. At that time it was, however, premature to have these detailed discussions. Another input to take into account is a document you might well be familiar with, namely . There we also had use cases where the authorization rules were pre-provisioned into the devices and, in addition to what you mentioned, the device may need to operate without having an authorization server to consult in real time= =2E Does this make sense to you? Ciao Hannes --dID0IfhRUhf0P6TB2lfg2446MjUPfMLvG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWTDNkAAoJEGhJURNOOiAtO1YIAJqC84g373/t53p3S+NWRHPe PV/Oyv5YUtbXFvISxcwMVZxzZ1c78GQu3b7TZkgZ2zUYVH1Ogn7+/LjaRsWnEEzV ewItgeDwO4UZeytGSor/I+4t2NpSVkBiyQtJ2cE8tqEr5lkRd1F823Ow94hI5mJI qb5eoP9hArZAcJYVLl1vUWj/SJ8Zl2+2ypxzZ23ALmXqDDjJgdwrT42Vwt1qGbhN TZKrghKgMvWxJtxhTDtvJd68HnVb5xCKb4wHlaTAdiX0opqv5ugn9pszQHRn2Zew SK4fYTvAGD5C5MeccXAvTqrQ3ud9SVjXx+IW0qab54icTGrxJ1W6SKiMfE18tP0= =aKCQ -----END PGP SIGNATURE----- --dID0IfhRUhf0P6TB2lfg2446MjUPfMLvG-- From nobody Wed Nov 18 01:02: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 1589B1B2A73 for ; Wed, 18 Nov 2015 01:02:09 -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_20=-0.001, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyA6i0Jp8Rdf for ; Wed, 18 Nov 2015 01:02:07 -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 5B42C1B2A70 for ; Wed, 18 Nov 2015 01:02:07 -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 tAI91wVb001020; Wed, 18 Nov 2015 10:01:59 +0100 (CET) Received: from aung.tzi.org (pd95b299e.dip0.t-ipconnect.de [217.91.41.158]) (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 3p0ynL2h7fz2NtZ; Wed, 18 Nov 2015 10:01:58 +0100 (CET) From: Olaf Bergmann To: Kepeng Li , "Ace\@ietf.org" References: <564AEE51.30407@tzi.de> Date: Wed, 18 Nov 2015 10:01:56 +0100 In-Reply-To: <564AEE51.30407@tzi.de> (Stefanie Gerdes's message of "Tue, 17 Nov 2015 10:07:29 +0100") Message-ID: <87d1v7r88r.fsf@aung.informatik.uni-bremen.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ace] Solution direction X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Nov 2015 09:02:09 -0000 As Carsten already said, it is difficult to object the decision to continue with the OAuth-based approach because that is clearly one thing needed to do short-term (therefore, we have presented the OAuth integration with our proposal during IETF-93 in Prague and asked for help from OAuth experts). Now, it seems that this work starts and needed specifications for using OAuth tokens in the constrained sphere will be developed. This is a good thing, and I really do not care whether a required field name is taken from the OAuth sphere or from our DCAF proposal. In the end, they will just be numeric identifiers in CBOR where you cannot really tell the difference. So, this part of the discussion so far was about coloring the bikeshed. Where I object is to drop the work on the cross-domain, multi-stakeholder scenario as this is what enabled constrained devices to be part of a global Internet of Things. Many of those who have been convinced to go the OAuth way currently do not see the urge to work on this as their current use cases do not need this or their business model could be negatively affected by first movers jumping on that train. Now, I am very sure that both will happen, either based on IETF standards or in the wild. Therefore, I vote for continuing work on the cross-domain, multi-stakeholder scenario based on existing proposals, including DCAF, because it already contains a lot of text and message format specifications that show how this can work. We still can argue whether the bits in the DCAF have the correct color of the day, but we should not drop the added value that DCAF has. Gr=C3=BC=C3=9Fe Olaf From nobody Wed Nov 18 02:15:05 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1376A1B2BBD for ; Wed, 18 Nov 2015 02:15:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrKVmy4MVQjm for ; Wed, 18 Nov 2015 02:15:02 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B2751B2A4D for ; Wed, 18 Nov 2015 02:15:02 -0800 (PST) Received: by qgad10 with SMTP id d10so24445036qga.3 for ; Wed, 18 Nov 2015 02:15:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=Gh9Pc1QPadOZp5VJvqC81ZzZkoLSLz4I6SGfXdwEnVA=; b=R+AW7dV0x/NoPvrcyP1GGxIvCKuVhF7KM9FMZv/dmGCpVHXuO+z3iA6J63KyNfOjpy dbsZ9nDY7t+KXnGjC/AgR276hPBp2OHL3hREyy6BxcMQyOyCLW7IQFinLQidxDxrwK3w u5uFg/fVbS600UfF6ZAx0LAzg/veA0MtGm0QBDXkNIJ95ZR1Hb9LBDlxCSEkAdsxmgTc 6Bq+txwdQWMMuHWWEUuRnetR0n/nzjWps7Iq1V+r6DyF5xE+LkMUZJPZP0TVBvEoDpiS Lj4hN06OmYTHtcRDZRDG042YTGicxsYI8r6G3PjMr9NJmQiPsAi2K/3wIpTQISeZ80ZR RpFw== X-Received: by 10.140.229.80 with SMTP id z77mr551052qhb.104.1447841701231; Wed, 18 Nov 2015 02:15:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.148.198 with HTTP; Wed, 18 Nov 2015 02:14:41 -0800 (PST) In-Reply-To: <87d1v7r88r.fsf@aung.informatik.uni-bremen.de> References: <564AEE51.30407@tzi.de> <87d1v7r88r.fsf@aung.informatik.uni-bremen.de> From: Renzo Navas Date: Wed, 18 Nov 2015 11:14:41 +0100 Message-ID: To: Olaf Bergmann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Kepeng Li , "Ace@ietf.org" Subject: Re: [Ace] Solution direction X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Nov 2015 10:15:04 -0000 Good Morning everybody, I do agree that we have to start focusing one one solution only, and OAuth seems to have more momentum than DCAF, I read both drafts and OAuth is clear and easy to understand. I do not oppose to have OAuth-profiling as a starting point. However I do agree with Olaf, that there are still some core issues that are not addressed with OAuth-based solution yet but yes with DCAF, Notably the CAS concept is not present on the OAuth solution yet, and CAS is an integral part of the Actors ACE document, so we will eventually arrive to the point that we have to take CAS in account, and then we will be doing some work DCAF is already doing. So as Olaf say I vote also for maintaining DCAF at least for the cross-domain CAS-needed case, and why not start merging it with the OAuth-based solution on the points that OAuth is missing. Saludos! Renzo On Wed, Nov 18, 2015 at 10:01 AM, Olaf Bergmann wrote: > As Carsten already said, it is difficult to object the decision to > continue with the OAuth-based approach because that is clearly one > thing needed to do short-term (therefore, we have presented the OAuth > integration with our proposal during IETF-93 in Prague and asked for > help from OAuth experts). Now, it seems that this work starts and > needed specifications for using OAuth tokens in the constrained sphere > will be developed. This is a good thing, and I really do not care > whether a required field name is taken from the OAuth sphere or from > our DCAF proposal. In the end, they will just be numeric identifiers > in CBOR where you cannot really tell the difference. So, this part of > the discussion so far was about coloring the bikeshed. > > Where I object is to drop the work on the cross-domain, > multi-stakeholder scenario as this is what enabled constrained devices > to be part of a global Internet of Things. Many of those who have been > convinced to go the OAuth way currently do not see the urge to work on > this as their current use cases do not need this or their business > model could be negatively affected by first movers jumping on that > train. Now, I am very sure that both will happen, either based on IETF > standards or in the wild. Therefore, I vote for continuing work on the > cross-domain, multi-stakeholder scenario based on existing proposals, > including DCAF, because it already contains a lot of text and message > format specifications that show how this can work. We still can argue > whether the bits in the DCAF have the correct color of the day, but we > should not drop the added value that DCAF has. > > Gr=C3=BC=C3=9Fe > Olaf > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Wed Nov 18 02:27: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 041521B2BE0 for ; Wed, 18 Nov 2015 02:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, 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 j-yxReRZab0H for ; Wed, 18 Nov 2015 02:27:39 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEB491B2BDD for ; Wed, 18 Nov 2015 02:27:38 -0800 (PST) Received: by qgec40 with SMTP id c40so24378068qge.2 for ; Wed, 18 Nov 2015 02:27:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=Wp5OgueAoEPntgyblDfQpEFNr/Tq+fpMaDDLCRH2YT8=; b=DfpZtC4ACB4A/sbkwuJVR1OFnHu30KhEFdtxk5DrRsNQZholq16tKNHhNAoNWHCmU/ CoRQmYxz2A8OF0EP5e/UZiQqqXiJL3SG82rD2CVx8uy/2HnVWlOhASxwuGZt9kdUxTa4 NgnCZTztbLP4T0iy+j5nTYgKeMejXMyg/Tat2n5WDjRsLKt0ig1/xZ4zrigMEcXaUWow NvZLrR4nxMyiw8DkDHJVXt1NaYKwwO7T7BDtqqCQUx8knVcGanijjtwpZOpMjeZTsbii pgGRKqfZ95YEZt7vHNBdZSbwYrWgxD3Cx1VJ/YraHTt24H7lo3nJb9d8QY2jYoyiDwdf 3heg== X-Received: by 10.140.91.109 with SMTP id y100mr623395qgd.20.1447842458045; Wed, 18 Nov 2015 02:27:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.148.198 with HTTP; Wed, 18 Nov 2015 02:27:18 -0800 (PST) In-Reply-To: References: From: Renzo Navas Date: Wed, 18 Nov 2015 11:27:18 +0100 Message-ID: To: =?UTF-8?Q?G=C3=B6ran_Selander?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: ace Subject: Re: [Ace] Authenticated Key Establishment, OAut PoP Token and Time Requirements for Constrained Devices X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Nov 2015 10:27:40 -0000 Hello G=C3=B6ran, thanks for your kind response, I doubted I will get any because my mail was a bit obscure, this time I will try to be brief. > The purpose of this version of the draft is to demonstrate the > feasibility to use OAuth 2.0 with some modifications in a large variety o= f > constrained node deployment scenarios. Indeed the document does achieves that. My opinion after reading it is that OAuth is flexible and powerful, provides a desirable solution, and can be further extended. > Having said this I believe there are settings where a nonce based > authenticated key establishment makes sense. I do think so too. Restricting the RS to either to be time-synchronized or to do always the token-introspection flow for me it's too severe. > You are most welcome to contribute to this work; identifying under what > conditions such a protocol may be relevant and which information elements > to embed in the message flow. As you said there may be use cases/scenarios when nonce-based pop tokens , with differentce messages flows, will make sense. So if other people think so too, I can try to work on that (I have null exprience on ietf writing). Thanks again for your response, Renzo From nobody Wed Nov 18 02:57:45 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0631B2C48 for ; Wed, 18 Nov 2015 02:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.884 X-Spam-Level: X-Spam-Status: No, score=-2.884 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585] 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 8cRfUGWjCNFq for ; Wed, 18 Nov 2015 02:57:41 -0800 (PST) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72EF81B2C47 for ; Wed, 18 Nov 2015 02:57:40 -0800 (PST) Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX01.ad.nexusgroup.com (10.75.28.40) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 18 Nov 2015 11:57:37 +0100 Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0995.032; Wed, 18 Nov 2015 11:57:37 +0100 From: =?utf-8?B?RXJpayBXYWhsc3Ryw7ZtIG5lWHVz?= To: Stefanie Gerdes Thread-Topic: [Ace] Solution direction Thread-Index: AQHRFTDl5UZ0bor0rkKLapy4GQJkbZ6f85+AgAGxGQA= Date: Wed, 18 Nov 2015 10:57:37 +0000 Message-ID: References: <564AEE51.30407@tzi.de> In-Reply-To: <564AEE51.30407@tzi.de> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2104) x-originating-ip: [213.113.163.201] Content-Type: multipart/alternative; boundary="_000_FF8707ABC9FC44AE88DC0FEA88FCF085nexusgroupcom_" MIME-Version: 1.0 Archived-At: Cc: Hannes Tschofenig , Stephen Farrell , Kathleen Moriarty , Kepeng Li , "Ace@ietf.org" Subject: Re: [Ace] Solution direction X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Nov 2015 10:57:44 -0000 --_000_FF8707ABC9FC44AE88DC0FEA88FCF085nexusgroupcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkR5bmFtaWMgY2xpZW50IHJlZ2lzdHJhdGlvbiAoUkZDNzU5MSkgYW5kIFVzZXItTWFu YWdlZCBBY2Nlc3MgKFVNQSkgUHJvZmlsZSBvZiBPQXV0aCAyLjAgKGh0dHBzOi8vZG9jcy5rYW50 YXJhaW5pdGlhdGl2ZS5vcmcvdW1hL3JlYy11bWEtY29yZS5odG1sKSBzb2x2ZXMgdGhvc2Ugc2Nl bmFyaW9zLg0KDQpUbyBtYWtlIHRoZW0gd29yayB3aXRoIGNvbnN0cmFpbmVkIGNsaWVudHMgYW5k IHNlcnZlcnMsIGJvdGggUkZDNzU5MSBhbmQgVU1BIG11c3QgdG8gYmUgcHJvZmlsZWQgaW4gdGhl IHNhbWUgd2F5IGFzIHRoZSBPQXV0aCBmb3IgSW9UIGRyYWZ0IGRpZCBmb3IgY29yZSBvYXV0aC4N Cg0KQm90aCBkeW5hbWljIGNsaWVudCByZWdpc3RyYXRpb24gYW5kIFVNQSB3aGVyZSBhZGRlZCBs YXRlciBvbiBhZnRlciBPYXV0aDIgKFJGQzY3NDkpIHdhcyBjb21wbGV0ZWQuIEkgdGhpbmsgdGhh dOKAmXMgYSBzb3VuZCBtb2RlbCB0aGF0IHdlIHNob3VsZCBmb2xsb3cuIEdldCB0aGUgY29yZSBj b25jZXB0cyBkb3duLCB0aGVuIGV4dGVuZCB0aGVtIHdoZW4gbmVlZGVkIGFuZCB3aGVuIHdlIGRv IHRoYXQgd2Ugc2hvdWxkIHJlLXVzZSB0aGUgY29uY2VwdHMgYWxyZWFkeSB0aGVyZS4NCg0KSGF2 aW5nIHR3byBkaWZmZXJlbnQgcHJvcG9zYWxzLCBib3RoIERDQUYgYW5kIE9BdXRoIGZvciBJb1Qs IHJ1bm5pbmcgYXQgdGhlIHNhbWUgdGltZSBjb25mdXNlcyBpbXBsZW1lbnRvcnMuIEkgZG9u4oCZ dCB0aGluayB3ZSB3YW50IHRvIGRvIHRoYXQuDQoNCi8gRXJpaw0KDQoNCg0KT24gMTcgTm92IDIw MTUsIGF0IDEwOjA3LCBTdGVmYW5pZSBHZXJkZXMgPGdlcmRlc0B0emkuZGU8bWFpbHRvOmdlcmRl c0B0emkuZGU+PiB3cm90ZToNCg0KSGkgYWxsLA0KDQpJIHRoaW5rIHdlIHNob3VsZCBjb250aW51 ZSB3b3JraW5nIG9uIERDQUYgaW4gQUNFLiBJdCBwcm92aWRlcyB2YWx1YWJsZQ0KY29uY2VwdHMg YW5kIG1lY2hhbmlzbXMgd2hpY2ggaXMgd2h5IG1hbnkgc29sdXRpb25zIGluIEFDRSBkcmF3IGhl YXZpbHkNCmZyb20gRENBRi4NCg0KSSB0aGluayBvbmUgYXNwZWN0IGRpZCBub3QgcmVhbGx5IGJl Y29tZSBjbGVhciBkdXJpbmcgdGhlIEFDRSBzZXNzaW9uIGluDQpZb2tvaGFtYTogQSBzb2x1dGlv biB3aXRoIG9ubHkgb25lIHN1cHBvcnRpbmcgbGVzcyBjb25zdHJhaW5lZCBkZXZpY2UNCndpbGwg bm90IGJlIGFibGUgdG8gZnVsbHkgc3VwcG9ydCBjb21tdW5pY2F0aW9uIGJldHdlZW4gY29uc3Ry YWluZWQNCm5vZGVzIGFzIERDQUYgZG9lcy4gT25lIG1haW4gcXVlc3Rpb24gdGhhdCBpcyBvbmx5 IHBhcnRseSBzb2x2ZWQgYnkNCm90aGVyIHNvbHV0aW9ucyBpczogSG93IGNhbiBhIGNvbnN0cmFp bmVkIGNsaWVudCBhdXRoZW50aWNhdGUgdGhlIG90aGVyDQpwYXJ0eT8NCg0KQSBjb25zdHJhaW5l ZCBkZXZpY2UgaXMgbm90IGFibGUgdG8gZXN0YWJsaXNoIHNlY3VyaXR5IGFzc29jaWF0aW9ucyBh cw0KZWFzaWx5IGFzIGEgbGVzcyBjb25zdHJhaW5lZCBkZXZpY2UuIFRoZSBrZXlpbmcgbWF0ZXJp YWwgdGhhdCBpcyB1c2VkDQpmb3IgYXV0aG9yaXphdGlvbiBhbmQgc2VjdXJlIGNvbW11bmljYXRp b24gbXVzdCBzZWN1cmVseSBiZSBvYnRhaW5lZC4gSXQNCmNhbiBlaXRoZXIgYmUgcHJvdmlzaW9u ZWQgbWFudWFsbHkgdG8gdGhlIGNvbnN0cmFpbmVkIGRldmljZSBvciBhDQpzZWN1cml0eSBhc3Nv Y2lhdGlvbiB3aXRoIGEgbGVzcyBjb25zdHJhaW5lZCBkZXZpY2UgaXMgcmVxdWlyZWQgdGhhdCBj YW4NCnRoZW4gcHJvdmlkZSB0aGUga2V5aW5nIG1hdGVyaWFsLg0KDQpBbiBBdXRob3JpemF0aW9u IFNlcnZlciBjYW4gcHJvdmlkZSBzZXNzaW9uIGtleXMgdG8gdGhlIGNvbnN0cmFpbmVkDQpkZXZp Y2VzLCBidXQgdGhlIGNvbnN0cmFpbmVkIGRldmljZSBtdXN0IGhhdmUgYSBzZWN1cml0eSBhc3Nv Y2lhdGlvbg0Kd2l0aCB0aGUgQVMgdG8gYXV0aGVudGljYXRlIHRoZSBvcmlnaW4gb2YgdGhlIHNl c3Npb24ga2V5LiBJbiBhIHNjZW5hcmlvDQp3aGVyZSB3ZSBoYXZlIG9ubHkgYSBzaW5nbGUgQVMg YW5kIHR3byBjb25zdHJhaW5lZCBub2RlcywgYm90aCBuZWVkIGENCnNlY3VyaXR5IGFzc29jaWF0 aW9uIHdpdGggdGhhdCBBUy4gRm9yIGNyb3NzLWRvbWFpbiBzY2VuYXJpb3MgdGhpcyBtaWdodA0K YmUgZGlmZmljdWx0LiBXZSB3aWxsIG5lZWQgdG8gbWFudWFsbHkgcHJvdmlzaW9uIHRoZSBrZXlp bmcgbWF0ZXJpYWwgdG8NCm9uZSBvZiB0aGUgZGV2aWNlcyB3aGljaCBtYWtlcyB0aGUgZHluYW1p YyBzZXR1cCBvZiBzZWN1cmUgY29tbXVuaWNhdGlvbg0KaW1wb3NzaWJsZS4gVGhhdCdzIHdoeSB3 ZSBuZWVkIHR3byBsZXNzLWNvbnN0cmFpbmVkIGRldmljZXMgaW4gdGhpcw0Kc2NlbmFyaW8uDQoN CllvdSBtYXkgdGhpbmsgdGhhdCB0aGlzIGhhcyBub3RoaW5nIHRvIGRvIHdpdGggYXV0aG9yaXph dGlvbiBhbmQNCnRoZXJlZm9yZSBpcyBub3QgYSB0b3BpYyBmb3IgQUNFLiBXZWxsLCBpdCBoYXMs IGJ1dCBhbm90aGVyDQp0ZXJtaW5vbG9neS1kaXNjdXNzaW9uIG1pZ2h0IG5vdCBiZSB0aGF0IHVz ZWZ1bC4gSG93ZXZlciwgdGhlIGltcG9ydGFudA0KdGhpbmcgaXMgdGhhdCBkZXZlbG9waW5nIGFu IGFkZGl0aW9uYWwgc29sdXRpb24gdG8gc29sdmUgdGhpcyBwcm9ibGVtDQp3aWxsIHZlcnkgbGlr ZWx5IGFkZCBtb3JlIG92ZXJoZWFkLiBUaGUgcmVzdWx0IHdpbGwgYmUgbW9yZSBjb21wbGV4IGFu ZA0KbW9yZSBkaWZmaWN1bHQgdG8gaW1wbGVtZW50LiBVbnRpbCBzdWNoIGEgc29sdXRpb24gaXMg ZGV2ZWxvcGVkIHdlIHdpbGwNCm5lZWQgdG8gdXNlIGNvbXBsZXggd29ya2Fyb3VuZHMgKGUuZy4g bWFudWFsIHByb3Zpc2lvbmluZyksIG1heSBoYXZlDQpzZWN1cml0eSBwcm9ibGVtcyBvciBhcmUg bm90IGFibGUgdG8gYWRkcmVzcyBjZXJ0YWluIHNjZW5hcmlvcyBhdCBhbGwuDQoNCkJ1dCB3ZSBo YXZlIG5ldmVyIGRvbmUgdGhpcyBiZWZvcmUsIHdoeSBub3c/IEJlY2F1c2Ugb3RoZXIgdGhhbiB0 aGUNCmdlbmVyYWwgcHVycG9zZSBjb21wdXRlcnMgdGhhdCB3ZSBhcmUgdXNpbmcgdG9kYXksIGNv bnN0cmFpbmVkIGRldmljZXMNCndpbGwgY29tbXVuaWNhdGUgYXV0b25vbW91c2x5IHdpdGhvdXQg dGhlIGhlbHAgb2YgdGhlaXIgdXNlci4gVGhleSBvZnRlbg0Kd2lsbCBub3QgZXZlbiBoYXZlIHVz ZXIgaW50ZXJmYWNlcy4gVW50aWwgbm93IHRoaXMgd2FzIHRydWUgZm9yIHNlcnZlcnMNCndoaWNo IGlzIHdoeSBleGlzdGluZyBwcm90b2NvbHMgcHJvdGVjdCB0aGVtLiBJbiBhIHRydWUgSW50ZXJu ZXQgb2YNClRoaW5ncyB0aGlzIHdpbGwgYWxzbyBiZSB0cnVlIGZvciBjbGllbnRzLiBXZSB0aGVy ZWZvcmUgbmVlZCB0bw0KcmVjb25zaWRlciBob3cgY2xpZW50cyBjYW4gYmUgcHJvdGVjdGVkIGFu ZCBob3cgdGhlaXIgYWN0aW9ucyBjYW4gYmUNCmNvbnRyb2xsZWQgYnkgdGhlaXIgb3duZXJzLg0K DQpEQ0FGIHN1cHBvcnRzIHNjZW5hcmlvcyB3aXRoIGEgc2luZ2xlIGxlc3MtY29uc3RyYWluZWQg ZGV2aWNlIChBUykgYXMNCndlbGwgYXMgc2NlbmFyaW9zIHdoZXJlIGJvdGggdGhlIENsaWVudCBh bmQgdGhlIFNlcnZlciBoYXZlIHRoZWlyIG93bi4NCkl0IHdvcmtzIHdpdGggT0F1dGggYW5kIG1h eSBldmVuIHRyYW5zcG9ydCBPQXV0aCB0aWNrZXRzIGlmIHRoYXQgaXMNCm5lY2Vzc2FyeS4gSXQg aGFzIGEgYnVpbHQtaW4ga2V5IGRpc3RyaWJ1dGlvbiBtZWNoYW5pc20gYW5kIHRoZXJlZm9yZSBp cw0KdmVyeSBlZmZpY2llbnQuIFRoZSBtYWluIGZhdWx0IG9mIERDQUYgc2VlbXMgdG8gYmUgdGhh dCB3ZSBkaWRuJ3QgY2FsbA0KaXQgT0F1dGguDQoNCkkgdGhpbmsgRENBRiBzaG91bGQgYmUgb25l IG9mIHRoZSBidWlsZGluZyBibG9ja3MgKG9uZSBvZiB0aGUgdG9vbHMgaW4NCm91ciB0b29sYm94 KSB0aGF0IEFDRSBpcyB3b3JraW5nIG9uLg0KDQpCZXN0IHJlZ2FyZHMsDQpTdGVmZmkNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkFjZSBtYWlsaW5n IGxpc3QNCkFjZUBpZXRmLm9yZzxtYWlsdG86QWNlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UNCg0K --_000_FF8707ABC9FC44AE88DC0FEA88FCF085nexusgroupcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGksDQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5EeW5hbWljIGNsaWVudCByZWdpc3Ry YXRpb24gKFJGQzc1OTEpIGFuZCBVc2VyLU1hbmFnZWQgQWNjZXNzIChVTUEpIFByb2ZpbGUgb2Yg T0F1dGggMi4wICg8YSBocmVmPSJodHRwczovL2RvY3Mua2FudGFyYWluaXRpYXRpdmUub3JnL3Vt YS9yZWMtdW1hLWNvcmUuaHRtbCIgY2xhc3M9IiI+aHR0cHM6Ly9kb2NzLmthbnRhcmFpbml0aWF0 aXZlLm9yZy91bWEvcmVjLXVtYS1jb3JlLmh0bWw8L2E+KSBzb2x2ZXMgdGhvc2Ugc2NlbmFyaW9z LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+VG8gbWFrZSB0aGVtIHdvcmsgd2l0aCBjb25zdHJhaW5lZCBjbGllbnRzIGFuZCBzZXJ2ZXJz LCBib3RoIFJGQzc1OTEgYW5kIFVNQSBtdXN0IHRvIGJlIHByb2ZpbGVkIGluIHRoZSBzYW1lIHdh eSBhcyB0aGUgT0F1dGggZm9yIElvVCBkcmFmdCBkaWQgZm9yIGNvcmUgb2F1dGguPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Cb3RoIGR5 bmFtaWMgY2xpZW50IHJlZ2lzdHJhdGlvbiBhbmQgVU1BIHdoZXJlIGFkZGVkIGxhdGVyIG9uIGFm dGVyIE9hdXRoMiAoUkZDNjc0OSkgd2FzIGNvbXBsZXRlZC4gSSB0aGluayB0aGF04oCZcyBhIHNv dW5kIG1vZGVsIHRoYXQgd2Ugc2hvdWxkIGZvbGxvdy4gR2V0IHRoZSBjb3JlIGNvbmNlcHRzIGRv d24sIHRoZW4gZXh0ZW5kIHRoZW0gd2hlbiBuZWVkZWQgYW5kIHdoZW4gd2UgZG8gdGhhdCB3ZSBz aG91bGQgcmUtdXNlDQogdGhlIGNvbmNlcHRzIGFscmVhZHkgdGhlcmUuPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5IYXZpbmcgdHdvIGRp ZmZlcmVudCBwcm9wb3NhbHMsIGJvdGggRENBRiBhbmQgT0F1dGggZm9yIElvVCwgcnVubmluZyBh dCB0aGUgc2FtZSB0aW1lIGNvbmZ1c2VzIGltcGxlbWVudG9ycy4gSSBkb27igJl0IHRoaW5rIHdl IHdhbnQgdG8gZG8gdGhhdC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPi8gRXJpazwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gMTcgTm92IDIwMTUsIGF0IDEwOjA3LCBTdGVmYW5pZSBH ZXJkZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpnZXJkZXNAdHppLmRlIiBjbGFzcz0iIj5nZXJkZXNA dHppLmRlPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdl LW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj5IaSBhbGwsPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KSSB0aGluayB3ZSBzaG91bGQgY29udGludWUgd29ya2luZyBvbiBEQ0FGIGluIEFDRS4g SXQgcHJvdmlkZXMgdmFsdWFibGU8YnIgY2xhc3M9IiI+DQpjb25jZXB0cyBhbmQgbWVjaGFuaXNt cyB3aGljaCBpcyB3aHkgbWFueSBzb2x1dGlvbnMgaW4gQUNFIGRyYXcgaGVhdmlseTxiciBjbGFz cz0iIj4NCmZyb20gRENBRi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJIHRoaW5rIG9u ZSBhc3BlY3QgZGlkIG5vdCByZWFsbHkgYmVjb21lIGNsZWFyIGR1cmluZyB0aGUgQUNFIHNlc3Np b24gaW48YnIgY2xhc3M9IiI+DQpZb2tvaGFtYTogQSBzb2x1dGlvbiB3aXRoIG9ubHkgb25lIHN1 cHBvcnRpbmcgbGVzcyBjb25zdHJhaW5lZCBkZXZpY2U8YnIgY2xhc3M9IiI+DQp3aWxsIG5vdCBi ZSBhYmxlIHRvIGZ1bGx5IHN1cHBvcnQgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIGNvbnN0cmFpbmVk PGJyIGNsYXNzPSIiPg0Kbm9kZXMgYXMgRENBRiBkb2VzLiBPbmUgbWFpbiBxdWVzdGlvbiB0aGF0 IGlzIG9ubHkgcGFydGx5IHNvbHZlZCBieTxiciBjbGFzcz0iIj4NCm90aGVyIHNvbHV0aW9ucyBp czogSG93IGNhbiBhIGNvbnN0cmFpbmVkIGNsaWVudCBhdXRoZW50aWNhdGUgdGhlIG90aGVyPGJy IGNsYXNzPSIiPg0KcGFydHk/PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQSBjb25zdHJh aW5lZCBkZXZpY2UgaXMgbm90IGFibGUgdG8gZXN0YWJsaXNoIHNlY3VyaXR5IGFzc29jaWF0aW9u cyBhczxiciBjbGFzcz0iIj4NCmVhc2lseSBhcyBhIGxlc3MgY29uc3RyYWluZWQgZGV2aWNlLiBU aGUga2V5aW5nIG1hdGVyaWFsIHRoYXQgaXMgdXNlZDxiciBjbGFzcz0iIj4NCmZvciBhdXRob3Jp emF0aW9uIGFuZCBzZWN1cmUgY29tbXVuaWNhdGlvbiBtdXN0IHNlY3VyZWx5IGJlIG9idGFpbmVk LiBJdDxiciBjbGFzcz0iIj4NCmNhbiBlaXRoZXIgYmUgcHJvdmlzaW9uZWQgbWFudWFsbHkgdG8g dGhlIGNvbnN0cmFpbmVkIGRldmljZSBvciBhPGJyIGNsYXNzPSIiPg0Kc2VjdXJpdHkgYXNzb2Np YXRpb24gd2l0aCBhIGxlc3MgY29uc3RyYWluZWQgZGV2aWNlIGlzIHJlcXVpcmVkIHRoYXQgY2Fu PGJyIGNsYXNzPSIiPg0KdGhlbiBwcm92aWRlIHRoZSBrZXlpbmcgbWF0ZXJpYWwuPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KQW4gQXV0aG9yaXphdGlvbiBTZXJ2ZXIgY2FuIHByb3ZpZGUg c2Vzc2lvbiBrZXlzIHRvIHRoZSBjb25zdHJhaW5lZDxiciBjbGFzcz0iIj4NCmRldmljZXMsIGJ1 dCB0aGUgY29uc3RyYWluZWQgZGV2aWNlIG11c3QgaGF2ZSBhIHNlY3VyaXR5IGFzc29jaWF0aW9u PGJyIGNsYXNzPSIiPg0Kd2l0aCB0aGUgQVMgdG8gYXV0aGVudGljYXRlIHRoZSBvcmlnaW4gb2Yg dGhlIHNlc3Npb24ga2V5LiBJbiBhIHNjZW5hcmlvPGJyIGNsYXNzPSIiPg0Kd2hlcmUgd2UgaGF2 ZSBvbmx5IGEgc2luZ2xlIEFTIGFuZCB0d28gY29uc3RyYWluZWQgbm9kZXMsIGJvdGggbmVlZCBh PGJyIGNsYXNzPSIiPg0Kc2VjdXJpdHkgYXNzb2NpYXRpb24gd2l0aCB0aGF0IEFTLiBGb3IgY3Jv c3MtZG9tYWluIHNjZW5hcmlvcyB0aGlzIG1pZ2h0PGJyIGNsYXNzPSIiPg0KYmUgZGlmZmljdWx0 LiBXZSB3aWxsIG5lZWQgdG8gbWFudWFsbHkgcHJvdmlzaW9uIHRoZSBrZXlpbmcgbWF0ZXJpYWwg dG88YnIgY2xhc3M9IiI+DQpvbmUgb2YgdGhlIGRldmljZXMgd2hpY2ggbWFrZXMgdGhlIGR5bmFt aWMgc2V0dXAgb2Ygc2VjdXJlIGNvbW11bmljYXRpb248YnIgY2xhc3M9IiI+DQppbXBvc3NpYmxl LiBUaGF0J3Mgd2h5IHdlIG5lZWQgdHdvIGxlc3MtY29uc3RyYWluZWQgZGV2aWNlcyBpbiB0aGlz PGJyIGNsYXNzPSIiPg0Kc2NlbmFyaW8uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KWW91 IG1heSB0aGluayB0aGF0IHRoaXMgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCBhdXRob3JpemF0aW9u IGFuZDxiciBjbGFzcz0iIj4NCnRoZXJlZm9yZSBpcyBub3QgYSB0b3BpYyBmb3IgQUNFLiBXZWxs LCBpdCBoYXMsIGJ1dCBhbm90aGVyPGJyIGNsYXNzPSIiPg0KdGVybWlub2xvZ3ktZGlzY3Vzc2lv biBtaWdodCBub3QgYmUgdGhhdCB1c2VmdWwuIEhvd2V2ZXIsIHRoZSBpbXBvcnRhbnQ8YnIgY2xh c3M9IiI+DQp0aGluZyBpcyB0aGF0IGRldmVsb3BpbmcgYW4gYWRkaXRpb25hbCBzb2x1dGlvbiB0 byBzb2x2ZSB0aGlzIHByb2JsZW08YnIgY2xhc3M9IiI+DQp3aWxsIHZlcnkgbGlrZWx5IGFkZCBt b3JlIG92ZXJoZWFkLiBUaGUgcmVzdWx0IHdpbGwgYmUgbW9yZSBjb21wbGV4IGFuZDxiciBjbGFz cz0iIj4NCm1vcmUgZGlmZmljdWx0IHRvIGltcGxlbWVudC4gVW50aWwgc3VjaCBhIHNvbHV0aW9u IGlzIGRldmVsb3BlZCB3ZSB3aWxsPGJyIGNsYXNzPSIiPg0KbmVlZCB0byB1c2UgY29tcGxleCB3 b3JrYXJvdW5kcyAoZS5nLiBtYW51YWwgcHJvdmlzaW9uaW5nKSwgbWF5IGhhdmU8YnIgY2xhc3M9 IiI+DQpzZWN1cml0eSBwcm9ibGVtcyBvciBhcmUgbm90IGFibGUgdG8gYWRkcmVzcyBjZXJ0YWlu IHNjZW5hcmlvcyBhdCBhbGwuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQnV0IHdlIGhh dmUgbmV2ZXIgZG9uZSB0aGlzIGJlZm9yZSwgd2h5IG5vdz8gQmVjYXVzZSBvdGhlciB0aGFuIHRo ZTxiciBjbGFzcz0iIj4NCmdlbmVyYWwgcHVycG9zZSBjb21wdXRlcnMgdGhhdCB3ZSBhcmUgdXNp bmcgdG9kYXksIGNvbnN0cmFpbmVkIGRldmljZXM8YnIgY2xhc3M9IiI+DQp3aWxsIGNvbW11bmlj YXRlIGF1dG9ub21vdXNseSB3aXRob3V0IHRoZSBoZWxwIG9mIHRoZWlyIHVzZXIuIFRoZXkgb2Z0 ZW48YnIgY2xhc3M9IiI+DQp3aWxsIG5vdCBldmVuIGhhdmUgdXNlciBpbnRlcmZhY2VzLiBVbnRp bCBub3cgdGhpcyB3YXMgdHJ1ZSBmb3Igc2VydmVyczxiciBjbGFzcz0iIj4NCndoaWNoIGlzIHdo eSBleGlzdGluZyBwcm90b2NvbHMgcHJvdGVjdCB0aGVtLiBJbiBhIHRydWUgSW50ZXJuZXQgb2Y8 YnIgY2xhc3M9IiI+DQpUaGluZ3MgdGhpcyB3aWxsIGFsc28gYmUgdHJ1ZSBmb3IgY2xpZW50cy4g V2UgdGhlcmVmb3JlIG5lZWQgdG88YnIgY2xhc3M9IiI+DQpyZWNvbnNpZGVyIGhvdyBjbGllbnRz IGNhbiBiZSBwcm90ZWN0ZWQgYW5kIGhvdyB0aGVpciBhY3Rpb25zIGNhbiBiZTxiciBjbGFzcz0i Ij4NCmNvbnRyb2xsZWQgYnkgdGhlaXIgb3duZXJzLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCkRDQUYgc3VwcG9ydHMgc2NlbmFyaW9zIHdpdGggYSBzaW5nbGUgbGVzcy1jb25zdHJhaW5l ZCBkZXZpY2UgKEFTKSBhczxiciBjbGFzcz0iIj4NCndlbGwgYXMgc2NlbmFyaW9zIHdoZXJlIGJv dGggdGhlIENsaWVudCBhbmQgdGhlIFNlcnZlciBoYXZlIHRoZWlyIG93bi48YnIgY2xhc3M9IiI+ DQpJdCB3b3JrcyB3aXRoIE9BdXRoIGFuZCBtYXkgZXZlbiB0cmFuc3BvcnQgT0F1dGggdGlja2V0 cyBpZiB0aGF0IGlzPGJyIGNsYXNzPSIiPg0KbmVjZXNzYXJ5LiBJdCBoYXMgYSBidWlsdC1pbiBr ZXkgZGlzdHJpYnV0aW9uIG1lY2hhbmlzbSBhbmQgdGhlcmVmb3JlIGlzPGJyIGNsYXNzPSIiPg0K dmVyeSBlZmZpY2llbnQuIFRoZSBtYWluIGZhdWx0IG9mIERDQUYgc2VlbXMgdG8gYmUgdGhhdCB3 ZSBkaWRuJ3QgY2FsbDxiciBjbGFzcz0iIj4NCml0IE9BdXRoLjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCkkgdGhpbmsgRENBRiBzaG91bGQgYmUgb25lIG9mIHRoZSBidWlsZGluZyBibG9j a3MgKG9uZSBvZiB0aGUgdG9vbHMgaW48YnIgY2xhc3M9IiI+DQpvdXIgdG9vbGJveCkgdGhhdCBB Q0UgaXMgd29ya2luZyBvbi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpCZXN0IHJlZ2Fy ZHMsPGJyIGNsYXNzPSIiPg0KU3RlZmZpPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+ DQpBY2UgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOkFjZUBpZXRm Lm9yZyIgY2xhc3M9IiI+QWNlQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_FF8707ABC9FC44AE88DC0FEA88FCF085nexusgroupcom_-- From nobody Wed Nov 18 09:39: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 A271A1A00E6 for ; Wed, 18 Nov 2015 09:39:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 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_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 dp5NpJeMQ4eS for ; Wed, 18 Nov 2015 09:39:27 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0134.outbound.protection.outlook.com [65.55.169.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB7471A00E5 for ; Wed, 18 Nov 2015 09:39:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=p4RMMEgdIMprSfrbolGQ1A6xwqPMSZOmG3WCsrsA6ZU=; b=G53angVChka/8wJQSnD4cgZVBUBmMgFr6CrsIgd3ORb/9F6zwzdXPAcR+V8uJ57xOjIupkuGU83TLkZRdFRDfxqhmQDSAr0P9I/hzPYlxJPL2GZnoq521bpdsozmF96zRpHwarrz6aRYucddKoDcasAZTTAs2cAqEFPU945s848= Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BN3PR0301MB1233.namprd03.prod.outlook.com (10.161.207.21) with Microsoft SMTP Server (TLS) id 15.1.331.20; Wed, 18 Nov 2015 17:39:23 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0331.019; Wed, 18 Nov 2015 17:39:23 +0000 From: Anthony Nadalin To: =?utf-8?B?RXJpayBXYWhsc3Ryw7ZtIG5lWHVz?= , Stefanie Gerdes Thread-Topic: [Ace] Solution direction Thread-Index: AQHRFTDg9A/8PVwLBkmphhXbn6Mnd56gBGOAgAGxGoCAAG/xoA== Date: Wed, 18 Nov 2015 17:39:23 +0000 Message-ID: References: <564AEE51.30407@tzi.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; x-originating-ip: [2001:4898:80e8:8::4f9] x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1233; 5:MN/mdoFIC9Ku8E55EqL17Vj5vNHAVeQ9H7pCd98lyRZ9MyFa/pWXGYAYJB29AaXKdf9K19kuzPOc09GwztWdqjNs6DzxLae38xAELM4PUb6JcdDz6QTqf9NN2aR0NM5xVcPjYG99i8l7tqjniHwF7g==; 24:25A9pfQKhQYl7Iwk6lGRVNRb91e353pF9wrVYr6u3Avym/MBhElHGzRFeGMkPNqQ7vy+v38hAMSqxUb0xc2VGaUr5bDSfyxpd6zD7vuqyfU= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1233; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715)(189930954265078)(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001)(61426024)(61427024); SRVR:BN3PR0301MB1233; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1233; x-forefront-prvs: 0764C4A8CD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(189002)(51444003)(199003)(53754006)(377454003)(40100003)(19625215002)(5002640100001)(5003600100002)(19580395003)(19300405004)(19580405001)(5007970100001)(87936001)(86362001)(76576001)(5004730100002)(50986999)(5001960100002)(33656002)(11100500001)(74316001)(76176999)(5008740100001)(54356999)(6116002)(102836003)(790700001)(99286002)(106116001)(189998001)(106356001)(97736004)(81156007)(101416001)(5001770100001)(10090500001)(105586002)(19617315012)(86612001)(15975445007)(77096005)(2950100001)(2900100001)(8990500004)(586003)(10400500002)(5005710100001)(10290500002)(16236675004)(19609705001)(122556002)(92566002)(3826002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1233; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB12343B3062F6973BA3B52449A61C0BN3PR0301MB1234_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2015 17:39:23.3977 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1233 Archived-At: Cc: Kathleen Moriarty , Hannes Tschofenig , Kepeng Li , "Ace@ietf.org" , Stephen Farrell Subject: Re: [Ace] Solution direction X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Nov 2015 17:39:31 -0000 --_000_BN3PR0301MB12343B3062F6973BA3B52449A61C0BN3PR0301MB1234_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RG9u4oCZdCBvciB3b27igJl0IHdlIGFscmVhZHkgaGF2ZSB0aGF0IGNvbmZ1c2lvbiB3aXRoIENP U0UgYW5kIEpPU0UgKG11Y2ggbGlrZSBjb25mdXNpb24gd2l0aCBEQ0FGIGFuZCBPQVVUSCkgPw0K DQpGcm9tOiBBY2UgW21haWx0bzphY2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVy aWsgV2FobHN0csO2bSBuZVh1cw0KU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAxOCwgMjAxNSAy OjU4IEFNDQpUbzogU3RlZmFuaWUgR2VyZGVzIDxnZXJkZXNAdHppLmRlPg0KQ2M6IEhhbm5lcyBU c2Nob2ZlbmlnIDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PjsgU3RlcGhlbiBGYXJyZWxsIDxz dGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPjsgS2F0aGxlZW4gTW9yaWFydHkgPGthdGhsZWVuLm1v cmlhcnR5LmlldGZAZ21haWwuY29tPjsgS2VwZW5nIExpIDxrZXBlbmcubGtwQGFsaWJhYmEtaW5j LmNvbT47IEFjZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtBY2VdIFNvbHV0aW9uIGRpcmVjdGlv bg0KDQpIaSwNCg0KRHluYW1pYyBjbGllbnQgcmVnaXN0cmF0aW9uIChSRkM3NTkxKSBhbmQgVXNl ci1NYW5hZ2VkIEFjY2VzcyAoVU1BKSBQcm9maWxlIG9mIE9BdXRoIDIuMCAoaHR0cHM6Ly9kb2Nz LmthbnRhcmFpbml0aWF0aXZlLm9yZy91bWEvcmVjLXVtYS1jb3JlLmh0bWw8aHR0cHM6Ly9uYTAx LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZkb2Nz LmthbnRhcmFpbml0aWF0aXZlLm9yZyUyZnVtYSUyZnJlYy11bWEtY29yZS5odG1sJmRhdGE9MDEl N2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjMmU0YTQyMzUyOGI4NDg2OTE3MWQwOGQy ZjAwNzE4OTYlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9QUxZ bk54NjVDMThzVVlRQjNMZ1hPYzVzNXRlT0hEWXYwTnpxbUNzdWJBSSUzZD4pIHNvbHZlcyB0aG9z ZSBzY2VuYXJpb3MuDQoNClRvIG1ha2UgdGhlbSB3b3JrIHdpdGggY29uc3RyYWluZWQgY2xpZW50 cyBhbmQgc2VydmVycywgYm90aCBSRkM3NTkxIGFuZCBVTUEgbXVzdCB0byBiZSBwcm9maWxlZCBp biB0aGUgc2FtZSB3YXkgYXMgdGhlIE9BdXRoIGZvciBJb1QgZHJhZnQgZGlkIGZvciBjb3JlIG9h dXRoLg0KDQpCb3RoIGR5bmFtaWMgY2xpZW50IHJlZ2lzdHJhdGlvbiBhbmQgVU1BIHdoZXJlIGFk ZGVkIGxhdGVyIG9uIGFmdGVyIE9hdXRoMiAoUkZDNjc0OSkgd2FzIGNvbXBsZXRlZC4gSSB0aGlu ayB0aGF04oCZcyBhIHNvdW5kIG1vZGVsIHRoYXQgd2Ugc2hvdWxkIGZvbGxvdy4gR2V0IHRoZSBj b3JlIGNvbmNlcHRzIGRvd24sIHRoZW4gZXh0ZW5kIHRoZW0gd2hlbiBuZWVkZWQgYW5kIHdoZW4g d2UgZG8gdGhhdCB3ZSBzaG91bGQgcmUtdXNlIHRoZSBjb25jZXB0cyBhbHJlYWR5IHRoZXJlLg0K DQpIYXZpbmcgdHdvIGRpZmZlcmVudCBwcm9wb3NhbHMsIGJvdGggRENBRiBhbmQgT0F1dGggZm9y IElvVCwgcnVubmluZyBhdCB0aGUgc2FtZSB0aW1lIGNvbmZ1c2VzIGltcGxlbWVudG9ycy4gSSBk b27igJl0IHRoaW5rIHdlIHdhbnQgdG8gZG8gdGhhdC4NCg0KLyBFcmlrDQoNCg0KDQpPbiAxNyBO b3YgMjAxNSwgYXQgMTA6MDcsIFN0ZWZhbmllIEdlcmRlcyA8Z2VyZGVzQHR6aS5kZTxtYWlsdG86 Z2VyZGVzQHR6aS5kZT4+IHdyb3RlOg0KDQpIaSBhbGwsDQoNCkkgdGhpbmsgd2Ugc2hvdWxkIGNv bnRpbnVlIHdvcmtpbmcgb24gRENBRiBpbiBBQ0UuIEl0IHByb3ZpZGVzIHZhbHVhYmxlDQpjb25j ZXB0cyBhbmQgbWVjaGFuaXNtcyB3aGljaCBpcyB3aHkgbWFueSBzb2x1dGlvbnMgaW4gQUNFIGRy YXcgaGVhdmlseQ0KZnJvbSBEQ0FGLg0KDQpJIHRoaW5rIG9uZSBhc3BlY3QgZGlkIG5vdCByZWFs bHkgYmVjb21lIGNsZWFyIGR1cmluZyB0aGUgQUNFIHNlc3Npb24gaW4NCllva29oYW1hOiBBIHNv bHV0aW9uIHdpdGggb25seSBvbmUgc3VwcG9ydGluZyBsZXNzIGNvbnN0cmFpbmVkIGRldmljZQ0K d2lsbCBub3QgYmUgYWJsZSB0byBmdWxseSBzdXBwb3J0IGNvbW11bmljYXRpb24gYmV0d2VlbiBj b25zdHJhaW5lZA0Kbm9kZXMgYXMgRENBRiBkb2VzLiBPbmUgbWFpbiBxdWVzdGlvbiB0aGF0IGlz IG9ubHkgcGFydGx5IHNvbHZlZCBieQ0Kb3RoZXIgc29sdXRpb25zIGlzOiBIb3cgY2FuIGEgY29u c3RyYWluZWQgY2xpZW50IGF1dGhlbnRpY2F0ZSB0aGUgb3RoZXINCnBhcnR5Pw0KDQpBIGNvbnN0 cmFpbmVkIGRldmljZSBpcyBub3QgYWJsZSB0byBlc3RhYmxpc2ggc2VjdXJpdHkgYXNzb2NpYXRp b25zIGFzDQplYXNpbHkgYXMgYSBsZXNzIGNvbnN0cmFpbmVkIGRldmljZS4gVGhlIGtleWluZyBt YXRlcmlhbCB0aGF0IGlzIHVzZWQNCmZvciBhdXRob3JpemF0aW9uIGFuZCBzZWN1cmUgY29tbXVu aWNhdGlvbiBtdXN0IHNlY3VyZWx5IGJlIG9idGFpbmVkLiBJdA0KY2FuIGVpdGhlciBiZSBwcm92 aXNpb25lZCBtYW51YWxseSB0byB0aGUgY29uc3RyYWluZWQgZGV2aWNlIG9yIGENCnNlY3VyaXR5 IGFzc29jaWF0aW9uIHdpdGggYSBsZXNzIGNvbnN0cmFpbmVkIGRldmljZSBpcyByZXF1aXJlZCB0 aGF0IGNhbg0KdGhlbiBwcm92aWRlIHRoZSBrZXlpbmcgbWF0ZXJpYWwuDQoNCkFuIEF1dGhvcml6 YXRpb24gU2VydmVyIGNhbiBwcm92aWRlIHNlc3Npb24ga2V5cyB0byB0aGUgY29uc3RyYWluZWQN CmRldmljZXMsIGJ1dCB0aGUgY29uc3RyYWluZWQgZGV2aWNlIG11c3QgaGF2ZSBhIHNlY3VyaXR5 IGFzc29jaWF0aW9uDQp3aXRoIHRoZSBBUyB0byBhdXRoZW50aWNhdGUgdGhlIG9yaWdpbiBvZiB0 aGUgc2Vzc2lvbiBrZXkuIEluIGEgc2NlbmFyaW8NCndoZXJlIHdlIGhhdmUgb25seSBhIHNpbmds ZSBBUyBhbmQgdHdvIGNvbnN0cmFpbmVkIG5vZGVzLCBib3RoIG5lZWQgYQ0Kc2VjdXJpdHkgYXNz b2NpYXRpb24gd2l0aCB0aGF0IEFTLiBGb3IgY3Jvc3MtZG9tYWluIHNjZW5hcmlvcyB0aGlzIG1p Z2h0DQpiZSBkaWZmaWN1bHQuIFdlIHdpbGwgbmVlZCB0byBtYW51YWxseSBwcm92aXNpb24gdGhl IGtleWluZyBtYXRlcmlhbCB0bw0Kb25lIG9mIHRoZSBkZXZpY2VzIHdoaWNoIG1ha2VzIHRoZSBk eW5hbWljIHNldHVwIG9mIHNlY3VyZSBjb21tdW5pY2F0aW9uDQppbXBvc3NpYmxlLiBUaGF0J3Mg d2h5IHdlIG5lZWQgdHdvIGxlc3MtY29uc3RyYWluZWQgZGV2aWNlcyBpbiB0aGlzDQpzY2VuYXJp by4NCg0KWW91IG1heSB0aGluayB0aGF0IHRoaXMgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCBhdXRo b3JpemF0aW9uIGFuZA0KdGhlcmVmb3JlIGlzIG5vdCBhIHRvcGljIGZvciBBQ0UuIFdlbGwsIGl0 IGhhcywgYnV0IGFub3RoZXINCnRlcm1pbm9sb2d5LWRpc2N1c3Npb24gbWlnaHQgbm90IGJlIHRo YXQgdXNlZnVsLiBIb3dldmVyLCB0aGUgaW1wb3J0YW50DQp0aGluZyBpcyB0aGF0IGRldmVsb3Bp bmcgYW4gYWRkaXRpb25hbCBzb2x1dGlvbiB0byBzb2x2ZSB0aGlzIHByb2JsZW0NCndpbGwgdmVy eSBsaWtlbHkgYWRkIG1vcmUgb3ZlcmhlYWQuIFRoZSByZXN1bHQgd2lsbCBiZSBtb3JlIGNvbXBs ZXggYW5kDQptb3JlIGRpZmZpY3VsdCB0byBpbXBsZW1lbnQuIFVudGlsIHN1Y2ggYSBzb2x1dGlv biBpcyBkZXZlbG9wZWQgd2Ugd2lsbA0KbmVlZCB0byB1c2UgY29tcGxleCB3b3JrYXJvdW5kcyAo ZS5nLiBtYW51YWwgcHJvdmlzaW9uaW5nKSwgbWF5IGhhdmUNCnNlY3VyaXR5IHByb2JsZW1zIG9y IGFyZSBub3QgYWJsZSB0byBhZGRyZXNzIGNlcnRhaW4gc2NlbmFyaW9zIGF0IGFsbC4NCg0KQnV0 IHdlIGhhdmUgbmV2ZXIgZG9uZSB0aGlzIGJlZm9yZSwgd2h5IG5vdz8gQmVjYXVzZSBvdGhlciB0 aGFuIHRoZQ0KZ2VuZXJhbCBwdXJwb3NlIGNvbXB1dGVycyB0aGF0IHdlIGFyZSB1c2luZyB0b2Rh eSwgY29uc3RyYWluZWQgZGV2aWNlcw0Kd2lsbCBjb21tdW5pY2F0ZSBhdXRvbm9tb3VzbHkgd2l0 aG91dCB0aGUgaGVscCBvZiB0aGVpciB1c2VyLiBUaGV5IG9mdGVuDQp3aWxsIG5vdCBldmVuIGhh dmUgdXNlciBpbnRlcmZhY2VzLiBVbnRpbCBub3cgdGhpcyB3YXMgdHJ1ZSBmb3Igc2VydmVycw0K d2hpY2ggaXMgd2h5IGV4aXN0aW5nIHByb3RvY29scyBwcm90ZWN0IHRoZW0uIEluIGEgdHJ1ZSBJ bnRlcm5ldCBvZg0KVGhpbmdzIHRoaXMgd2lsbCBhbHNvIGJlIHRydWUgZm9yIGNsaWVudHMuIFdl IHRoZXJlZm9yZSBuZWVkIHRvDQpyZWNvbnNpZGVyIGhvdyBjbGllbnRzIGNhbiBiZSBwcm90ZWN0 ZWQgYW5kIGhvdyB0aGVpciBhY3Rpb25zIGNhbiBiZQ0KY29udHJvbGxlZCBieSB0aGVpciBvd25l cnMuDQoNCkRDQUYgc3VwcG9ydHMgc2NlbmFyaW9zIHdpdGggYSBzaW5nbGUgbGVzcy1jb25zdHJh aW5lZCBkZXZpY2UgKEFTKSBhcw0Kd2VsbCBhcyBzY2VuYXJpb3Mgd2hlcmUgYm90aCB0aGUgQ2xp ZW50IGFuZCB0aGUgU2VydmVyIGhhdmUgdGhlaXIgb3duLg0KSXQgd29ya3Mgd2l0aCBPQXV0aCBh bmQgbWF5IGV2ZW4gdHJhbnNwb3J0IE9BdXRoIHRpY2tldHMgaWYgdGhhdCBpcw0KbmVjZXNzYXJ5 LiBJdCBoYXMgYSBidWlsdC1pbiBrZXkgZGlzdHJpYnV0aW9uIG1lY2hhbmlzbSBhbmQgdGhlcmVm b3JlIGlzDQp2ZXJ5IGVmZmljaWVudC4gVGhlIG1haW4gZmF1bHQgb2YgRENBRiBzZWVtcyB0byBi ZSB0aGF0IHdlIGRpZG4ndCBjYWxsDQppdCBPQXV0aC4NCg0KSSB0aGluayBEQ0FGIHNob3VsZCBi ZSBvbmUgb2YgdGhlIGJ1aWxkaW5nIGJsb2NrcyAob25lIG9mIHRoZSB0b29scyBpbg0Kb3VyIHRv b2xib3gpIHRoYXQgQUNFIGlzIHdvcmtpbmcgb24uDQoNCkJlc3QgcmVnYXJkcywNClN0ZWZmaQ0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQWNlIG1h aWxpbmcgbGlzdA0KQWNlQGlldGYub3JnPG1haWx0bzpBY2VAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZQ0KDQo= --_000_BN3PR0301MB12343B3062F6973BA3B52449A61C0BN3PR0301MB1234_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5Eb27igJl0IG9yIHdvbuKAmXQgd2UgYWxyZWFkeSBoYXZlIHRoYXQg Y29uZnVzaW9uIHdpdGggQ09TRSBhbmQgSk9TRSAobXVjaCBsaWtlIGNvbmZ1c2lvbiB3aXRoIERD QUYgYW5kIE9BVVRIKSA/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBBY2UgW21haWx0bzphY2UtYm91bmNlc0Bp ZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RXJpayBXYWhsc3Ryw7ZtIG5lWHVzPGJyPg0K PGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTm92ZW1iZXIgMTgsIDIwMTUgMjo1OCBBTTxicj4NCjxi PlRvOjwvYj4gU3RlZmFuaWUgR2VyZGVzICZsdDtnZXJkZXNAdHppLmRlJmd0Ozxicj4NCjxiPkNj OjwvYj4gSGFubmVzIFRzY2hvZmVuaWcgJmx0O2hhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQmZ3Q7 OyBTdGVwaGVuIEZhcnJlbGwgJmx0O3N0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWUmZ3Q7OyBLYXRo bGVlbiBNb3JpYXJ0eSAmbHQ7a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb20mZ3Q7OyBL ZXBlbmcgTGkgJmx0O2tlcGVuZy5sa3BAYWxpYmFiYS1pbmMuY29tJmd0OzsgQWNlQGlldGYub3Jn PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbQWNlXSBTb2x1dGlvbiBkaXJlY3Rpb248bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSwgPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EeW5hbWljIGNsaWVudCByZWdpc3Ry YXRpb24gKFJGQzc1OTEpIGFuZCBVc2VyLU1hbmFnZWQgQWNjZXNzIChVTUEpIFByb2ZpbGUgb2Yg T0F1dGggMi4wICg8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0 bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZmRvY3Mua2FudGFyYWluaXRpYXRpdmUub3JnJTJm dW1hJTJmcmVjLXVtYS1jb3JlLmh0bWwmYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNy b3NvZnQuY29tJTdjMmU0YTQyMzUyOGI4NDg2OTE3MWQwOGQyZjAwNzE4OTYlN2M3MmY5ODhiZjg2 ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPUFMWW5OeDY1QzE4c1VZUUIzTGdY T2M1czV0ZU9IRFl2ME56cW1Dc3ViQUklM2QiPmh0dHBzOi8vZG9jcy5rYW50YXJhaW5pdGlhdGl2 ZS5vcmcvdW1hL3JlYy11bWEtY29yZS5odG1sPC9hPikNCiBzb2x2ZXMgdGhvc2Ugc2NlbmFyaW9z LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U byBtYWtlIHRoZW0gd29yayB3aXRoIGNvbnN0cmFpbmVkIGNsaWVudHMgYW5kIHNlcnZlcnMsIGJv dGggUkZDNzU5MSBhbmQgVU1BIG11c3QgdG8gYmUgcHJvZmlsZWQgaW4gdGhlIHNhbWUgd2F5IGFz IHRoZSBPQXV0aCBmb3IgSW9UIGRyYWZ0IGRpZCBmb3IgY29yZSBvYXV0aC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Qm90aCBkeW5hbWljIGNs aWVudCByZWdpc3RyYXRpb24gYW5kIFVNQSB3aGVyZSBhZGRlZCBsYXRlciBvbiBhZnRlciBPYXV0 aDIgKFJGQzY3NDkpIHdhcyBjb21wbGV0ZWQuIEkgdGhpbmsgdGhhdOKAmXMgYSBzb3VuZCBtb2Rl bCB0aGF0IHdlIHNob3VsZCBmb2xsb3cuIEdldCB0aGUgY29yZSBjb25jZXB0cyBkb3duLCB0aGVu IGV4dGVuZCB0aGVtIHdoZW4gbmVlZGVkIGFuZCB3aGVuIHdlIGRvIHRoYXQgd2Ugc2hvdWxkDQog cmUtdXNlIHRoZSBjb25jZXB0cyBhbHJlYWR5IHRoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IYXZpbmcgdHdvIGRpZmZlcmVudCBwcm9w b3NhbHMsIGJvdGggRENBRiBhbmQgT0F1dGggZm9yIElvVCwgcnVubmluZyBhdCB0aGUgc2FtZSB0 aW1lIGNvbmZ1c2VzIGltcGxlbWVudG9ycy4gSSBkb27igJl0IHRoaW5rIHdlIHdhbnQgdG8gZG8g dGhhdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+LyBFcmlrPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gMTcgTm92IDIwMTUsIGF0IDEwOjA3LCBTdGVmYW5pZSBHZXJkZXMgJmx0 OzxhIGhyZWY9Im1haWx0bzpnZXJkZXNAdHppLmRlIj5nZXJkZXNAdHppLmRlPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIGFsbCw8YnI+DQo8 YnI+DQpJIHRoaW5rIHdlIHNob3VsZCBjb250aW51ZSB3b3JraW5nIG9uIERDQUYgaW4gQUNFLiBJ dCBwcm92aWRlcyB2YWx1YWJsZTxicj4NCmNvbmNlcHRzIGFuZCBtZWNoYW5pc21zIHdoaWNoIGlz IHdoeSBtYW55IHNvbHV0aW9ucyBpbiBBQ0UgZHJhdyBoZWF2aWx5PGJyPg0KZnJvbSBEQ0FGLjxi cj4NCjxicj4NCkkgdGhpbmsgb25lIGFzcGVjdCBkaWQgbm90IHJlYWxseSBiZWNvbWUgY2xlYXIg ZHVyaW5nIHRoZSBBQ0Ugc2Vzc2lvbiBpbjxicj4NCllva29oYW1hOiBBIHNvbHV0aW9uIHdpdGgg b25seSBvbmUgc3VwcG9ydGluZyBsZXNzIGNvbnN0cmFpbmVkIGRldmljZTxicj4NCndpbGwgbm90 IGJlIGFibGUgdG8gZnVsbHkgc3VwcG9ydCBjb21tdW5pY2F0aW9uIGJldHdlZW4gY29uc3RyYWlu ZWQ8YnI+DQpub2RlcyBhcyBEQ0FGIGRvZXMuIE9uZSBtYWluIHF1ZXN0aW9uIHRoYXQgaXMgb25s eSBwYXJ0bHkgc29sdmVkIGJ5PGJyPg0Kb3RoZXIgc29sdXRpb25zIGlzOiBIb3cgY2FuIGEgY29u c3RyYWluZWQgY2xpZW50IGF1dGhlbnRpY2F0ZSB0aGUgb3RoZXI8YnI+DQpwYXJ0eT88YnI+DQo8 YnI+DQpBIGNvbnN0cmFpbmVkIGRldmljZSBpcyBub3QgYWJsZSB0byBlc3RhYmxpc2ggc2VjdXJp dHkgYXNzb2NpYXRpb25zIGFzPGJyPg0KZWFzaWx5IGFzIGEgbGVzcyBjb25zdHJhaW5lZCBkZXZp Y2UuIFRoZSBrZXlpbmcgbWF0ZXJpYWwgdGhhdCBpcyB1c2VkPGJyPg0KZm9yIGF1dGhvcml6YXRp b24gYW5kIHNlY3VyZSBjb21tdW5pY2F0aW9uIG11c3Qgc2VjdXJlbHkgYmUgb2J0YWluZWQuIEl0 PGJyPg0KY2FuIGVpdGhlciBiZSBwcm92aXNpb25lZCBtYW51YWxseSB0byB0aGUgY29uc3RyYWlu ZWQgZGV2aWNlIG9yIGE8YnI+DQpzZWN1cml0eSBhc3NvY2lhdGlvbiB3aXRoIGEgbGVzcyBjb25z dHJhaW5lZCBkZXZpY2UgaXMgcmVxdWlyZWQgdGhhdCBjYW48YnI+DQp0aGVuIHByb3ZpZGUgdGhl IGtleWluZyBtYXRlcmlhbC48YnI+DQo8YnI+DQpBbiBBdXRob3JpemF0aW9uIFNlcnZlciBjYW4g cHJvdmlkZSBzZXNzaW9uIGtleXMgdG8gdGhlIGNvbnN0cmFpbmVkPGJyPg0KZGV2aWNlcywgYnV0 IHRoZSBjb25zdHJhaW5lZCBkZXZpY2UgbXVzdCBoYXZlIGEgc2VjdXJpdHkgYXNzb2NpYXRpb248 YnI+DQp3aXRoIHRoZSBBUyB0byBhdXRoZW50aWNhdGUgdGhlIG9yaWdpbiBvZiB0aGUgc2Vzc2lv biBrZXkuIEluIGEgc2NlbmFyaW88YnI+DQp3aGVyZSB3ZSBoYXZlIG9ubHkgYSBzaW5nbGUgQVMg YW5kIHR3byBjb25zdHJhaW5lZCBub2RlcywgYm90aCBuZWVkIGE8YnI+DQpzZWN1cml0eSBhc3Nv Y2lhdGlvbiB3aXRoIHRoYXQgQVMuIEZvciBjcm9zcy1kb21haW4gc2NlbmFyaW9zIHRoaXMgbWln aHQ8YnI+DQpiZSBkaWZmaWN1bHQuIFdlIHdpbGwgbmVlZCB0byBtYW51YWxseSBwcm92aXNpb24g dGhlIGtleWluZyBtYXRlcmlhbCB0bzxicj4NCm9uZSBvZiB0aGUgZGV2aWNlcyB3aGljaCBtYWtl cyB0aGUgZHluYW1pYyBzZXR1cCBvZiBzZWN1cmUgY29tbXVuaWNhdGlvbjxicj4NCmltcG9zc2li bGUuIFRoYXQncyB3aHkgd2UgbmVlZCB0d28gbGVzcy1jb25zdHJhaW5lZCBkZXZpY2VzIGluIHRo aXM8YnI+DQpzY2VuYXJpby48YnI+DQo8YnI+DQpZb3UgbWF5IHRoaW5rIHRoYXQgdGhpcyBoYXMg bm90aGluZyB0byBkbyB3aXRoIGF1dGhvcml6YXRpb24gYW5kPGJyPg0KdGhlcmVmb3JlIGlzIG5v dCBhIHRvcGljIGZvciBBQ0UuIFdlbGwsIGl0IGhhcywgYnV0IGFub3RoZXI8YnI+DQp0ZXJtaW5v bG9neS1kaXNjdXNzaW9uIG1pZ2h0IG5vdCBiZSB0aGF0IHVzZWZ1bC4gSG93ZXZlciwgdGhlIGlt cG9ydGFudDxicj4NCnRoaW5nIGlzIHRoYXQgZGV2ZWxvcGluZyBhbiBhZGRpdGlvbmFsIHNvbHV0 aW9uIHRvIHNvbHZlIHRoaXMgcHJvYmxlbTxicj4NCndpbGwgdmVyeSBsaWtlbHkgYWRkIG1vcmUg b3ZlcmhlYWQuIFRoZSByZXN1bHQgd2lsbCBiZSBtb3JlIGNvbXBsZXggYW5kPGJyPg0KbW9yZSBk aWZmaWN1bHQgdG8gaW1wbGVtZW50LiBVbnRpbCBzdWNoIGEgc29sdXRpb24gaXMgZGV2ZWxvcGVk IHdlIHdpbGw8YnI+DQpuZWVkIHRvIHVzZSBjb21wbGV4IHdvcmthcm91bmRzIChlLmcuIG1hbnVh bCBwcm92aXNpb25pbmcpLCBtYXkgaGF2ZTxicj4NCnNlY3VyaXR5IHByb2JsZW1zIG9yIGFyZSBu b3QgYWJsZSB0byBhZGRyZXNzIGNlcnRhaW4gc2NlbmFyaW9zIGF0IGFsbC48YnI+DQo8YnI+DQpC dXQgd2UgaGF2ZSBuZXZlciBkb25lIHRoaXMgYmVmb3JlLCB3aHkgbm93PyBCZWNhdXNlIG90aGVy IHRoYW4gdGhlPGJyPg0KZ2VuZXJhbCBwdXJwb3NlIGNvbXB1dGVycyB0aGF0IHdlIGFyZSB1c2lu ZyB0b2RheSwgY29uc3RyYWluZWQgZGV2aWNlczxicj4NCndpbGwgY29tbXVuaWNhdGUgYXV0b25v bW91c2x5IHdpdGhvdXQgdGhlIGhlbHAgb2YgdGhlaXIgdXNlci4gVGhleSBvZnRlbjxicj4NCndp bGwgbm90IGV2ZW4gaGF2ZSB1c2VyIGludGVyZmFjZXMuIFVudGlsIG5vdyB0aGlzIHdhcyB0cnVl IGZvciBzZXJ2ZXJzPGJyPg0Kd2hpY2ggaXMgd2h5IGV4aXN0aW5nIHByb3RvY29scyBwcm90ZWN0 IHRoZW0uIEluIGEgdHJ1ZSBJbnRlcm5ldCBvZjxicj4NClRoaW5ncyB0aGlzIHdpbGwgYWxzbyBi ZSB0cnVlIGZvciBjbGllbnRzLiBXZSB0aGVyZWZvcmUgbmVlZCB0bzxicj4NCnJlY29uc2lkZXIg aG93IGNsaWVudHMgY2FuIGJlIHByb3RlY3RlZCBhbmQgaG93IHRoZWlyIGFjdGlvbnMgY2FuIGJl PGJyPg0KY29udHJvbGxlZCBieSB0aGVpciBvd25lcnMuPGJyPg0KPGJyPg0KRENBRiBzdXBwb3J0 cyBzY2VuYXJpb3Mgd2l0aCBhIHNpbmdsZSBsZXNzLWNvbnN0cmFpbmVkIGRldmljZSAoQVMpIGFz PGJyPg0Kd2VsbCBhcyBzY2VuYXJpb3Mgd2hlcmUgYm90aCB0aGUgQ2xpZW50IGFuZCB0aGUgU2Vy dmVyIGhhdmUgdGhlaXIgb3duLjxicj4NCkl0IHdvcmtzIHdpdGggT0F1dGggYW5kIG1heSBldmVu IHRyYW5zcG9ydCBPQXV0aCB0aWNrZXRzIGlmIHRoYXQgaXM8YnI+DQpuZWNlc3NhcnkuIEl0IGhh cyBhIGJ1aWx0LWluIGtleSBkaXN0cmlidXRpb24gbWVjaGFuaXNtIGFuZCB0aGVyZWZvcmUgaXM8 YnI+DQp2ZXJ5IGVmZmljaWVudC4gVGhlIG1haW4gZmF1bHQgb2YgRENBRiBzZWVtcyB0byBiZSB0 aGF0IHdlIGRpZG4ndCBjYWxsPGJyPg0KaXQgT0F1dGguPGJyPg0KPGJyPg0KSSB0aGluayBEQ0FG IHNob3VsZCBiZSBvbmUgb2YgdGhlIGJ1aWxkaW5nIGJsb2NrcyAob25lIG9mIHRoZSB0b29scyBp bjxicj4NCm91ciB0b29sYm94KSB0aGF0IEFDRSBpcyB3b3JraW5nIG9uLjxicj4NCjxicj4NCkJl c3QgcmVnYXJkcyw8YnI+DQpTdGVmZmk8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkFjZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo cmVmPSJtYWlsdG86QWNlQGlldGYub3JnIj5BY2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN3PR0301MB12343B3062F6973BA3B52449A61C0BN3PR0301MB1234_-- From nobody Wed Nov 18 10:13: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 528BB1A1B2D for ; Wed, 18 Nov 2015 10:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.884 X-Spam-Level: X-Spam-Status: No, score=-2.884 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585] 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 FeyQ58S5-hWO for ; Wed, 18 Nov 2015 10:13:35 -0800 (PST) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C1F11A1B2A for ; Wed, 18 Nov 2015 10:13:35 -0800 (PST) Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX01.ad.nexusgroup.com (10.75.28.40) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 18 Nov 2015 19:13:32 +0100 Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0995.032; Wed, 18 Nov 2015 19:13:32 +0100 From: =?iso-8859-1?Q?Erik_Wahlstr=F6m_neXus?= To: Anthony Nadalin Thread-Topic: [Ace] Solution direction Thread-Index: AQHRFTDl5UZ0bor0rkKLapy4GQJkbZ6f85+AgAGxGQCAAHBCgIAAGk6s Date: Wed, 18 Nov 2015 18:13:32 +0000 Message-ID: <56666935-C2EE-495B-9D32-639D887870AD@nexusgroup.com> References: <564AEE51.30407@tzi.de> , In-Reply-To: Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_56666935C2EE495B9D32639D887870ADnexusgroupcom_" MIME-Version: 1.0 Archived-At: Cc: Kathleen Moriarty , Kepeng Li , "Ace@ietf.org" , Stefanie Gerdes , Hannes Tschofenig , Stephen Farrell Subject: Re: [Ace] Solution direction X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Nov 2015 18:13:41 -0000 --_000_56666935C2EE495B9D32639D887870ADnexusgroupcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Don't think so. If it's a JWT/JOSE or a CWT/COSE does not mean the world. I= t's just a token format (both will exist). A client don't really have to ca= re what type of token it is. It's just a access token. Then we have the framework on how access tokens are retrieved and sent to e= stablish a context. That's another thing. / Erik Sent from my iPhone On 18 Nov 2015, at 18:39, Anthony Nadalin > wrote: Don't or won't we already have that confusion with COSE and JOSE (much like= confusion with DCAF and OAUTH) ? From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Erik Wahlstr=F6m neXus Sent: Wednesday, November 18, 2015 2:58 AM To: Stefanie Gerdes > Cc: Hannes Tschofenig >; Stephen Farrell >; Kathleen Moriarty >; Kepeng Li >; Ace@ietf.org Subject: Re: [Ace] Solution direction Hi, Dynamic client registration (RFC7591) and User-Managed Access (UMA) Profile= of OAuth 2.0 (https://docs.kantarainitiative.org/uma/rec-uma-core.html) solves thos= e scenarios. To make them work with constrained clients and servers, both RFC7591 and UM= A must to be profiled in the same way as the OAuth for IoT draft did for co= re oauth. Both dynamic client registration and UMA where added later on after Oauth2 = (RFC6749) was completed. I think that's a sound model that we should follow= . Get the core concepts down, then extend them when needed and when we do t= hat we should re-use the concepts already there. Having two different proposals, both DCAF and OAuth for IoT, running at the= same time confuses implementors. I don't think we want to do that. / Erik On 17 Nov 2015, at 10:07, Stefanie Gerdes > wrote: Hi all, I think we should continue working on DCAF in ACE. It provides valuable concepts and mechanisms which is why many solutions in ACE draw heavily from DCAF. I think one aspect did not really become clear during the ACE session in Yokohama: A solution with only one supporting less constrained device will not be able to fully support communication between constrained nodes as DCAF does. One main question that is only partly solved by other solutions is: How can a constrained client authenticate the other party? A constrained device is not able to establish security associations as easily as a less constrained device. The keying material that is used for authorization and secure communication must securely be obtained. It can either be provisioned manually to the constrained device or a security association with a less constrained device is required that can then provide the keying material. An Authorization Server can provide session keys to the constrained devices, but the constrained device must have a security association with the AS to authenticate the origin of the session key. In a scenario where we have only a single AS and two constrained nodes, both need a security association with that AS. For cross-domain scenarios this might be difficult. We will need to manually provision the keying material to one of the devices which makes the dynamic setup of secure communication impossible. That's why we need two less-constrained devices in this scenario. You may think that this has nothing to do with authorization and therefore is not a topic for ACE. Well, it has, but another terminology-discussion might not be that useful. However, the important thing is that developing an additional solution to solve this problem will very likely add more overhead. The result will be more complex and more difficult to implement. Until such a solution is developed we will need to use complex workarounds (e.g. manual provisioning), may have security problems or are not able to address certain scenarios at all. But we have never done this before, why now? Because other than the general purpose computers that we are using today, constrained devices will communicate autonomously without the help of their user. They often will not even have user interfaces. Until now this was true for servers which is why existing protocols protect them. In a true Internet of Things this will also be true for clients. We therefore need to reconsider how clients can be protected and how their actions can be controlled by their owners. DCAF supports scenarios with a single less-constrained device (AS) as well as scenarios where both the Client and the Server have their own. It works with OAuth and may even transport OAuth tickets if that is necessary. It has a built-in key distribution mechanism and therefore is very efficient. The main fault of DCAF seems to be that we didn't call it OAuth. I think DCAF should be one of the building blocks (one of the tools in our toolbox) that ACE is working on. Best regards, Steffi _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace --_000_56666935C2EE495B9D32639D887870ADnexusgroupcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Don't think so. If it's a JWT/JOSE or a CWT/COSE does not mean the wor= ld. It's just a token format (both will exist). A client don't really have = to care what type of token it is. It's just a access token. 

Then we have the framework on how access tok= ens are retrieved and sent to establish a context. That's another thing.
/ Erik

Sent from my iPhone

On 18 Nov 2015, at 18:39, Anthony Nadalin <tonynad@microsoft.com> wrote:

Don’t or won’t we already= have that confusion with COSE and JOSE (much like confusion with DCAF and = OAUTH) ?

&nbs= p;

From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Erik Wahlstr=F6m neXus
Sent: Wednesday, November 18, 2015 2:58 AM
To: Stefanie Gerdes <gerdes@tzi.= de>
Cc: Hannes Tschofenig <hannes.tschofenig@gmx.net>; Stephen Farrell <stephen.farrell@cs.tcd.ie>; Kathleen Mor= iarty <kathleen.mori= arty.ietf@gmail.com>; Kepeng Li <kepeng.lkp@ali= baba-inc.com>; Ace@ietf.org
Subject: Re: [Ace] Solution direction

 

Hi,

 

Dynamic client registration (RFC7591) and User-Manag= ed Access (UMA) Profile of OAuth 2.0 (https://docs.kantarainitiat= ive.org/uma/rec-uma-core.html) solves those scenarios.

 

To make them work with constrained clients and serve= rs, both RFC7591 and UMA must to be profiled in the same way as the OAuth f= or IoT draft did for core oauth.

 

Both dynamic client registration and UMA where added= later on after Oauth2 (RFC6749) was completed. I think that’s a soun= d model that we should follow. Get the core concepts down, then extend them= when needed and when we do that we should re-use the concepts already there.

 

Having two different proposals, both DCAF and OAuth = for IoT, running at the same time confuses implementors. I don’t thin= k we want to do that.

 

/ Erik

 

 

 

On 17 Nov 2015, at 10:07, Stefanie Gerdes <gerdes@tzi.de> wrote:

 

Hi all,

I think we should continue working on DCAF in ACE. It provides valuable
concepts and mechanisms which is why many solutions in ACE draw heavily
from DCAF.

I think one aspect did not really become clear during the ACE session in Yokohama: A solution with only one supporting less constrained device
will not be able to fully support communication between constrained
nodes as DCAF does. One main question that is only partly solved by
other solutions is: How can a constrained client authenticate the other
party?

A constrained device is not able to establish security associations as
easily as a less constrained device. The keying material that is used
for authorization and secure communication must securely be obtained. It can either be provisioned manually to the constrained device or a
security association with a less constrained device is required that can then provide the keying material.

An Authorization Server can provide session keys to the constrained
devices, but the constrained device must have a security association
with the AS to authenticate the origin of the session key. In a scenario where we have only a single AS and two constrained nodes, both need a
security association with that AS. For cross-domain scenarios this might be difficult. We will need to manually provision the keying material to
one of the devices which makes the dynamic setup of secure communication impossible. That's why we need two less-constrained devices in this
scenario.

You may think that this has nothing to do with authorization and
therefore is not a topic for ACE. Well, it has, but another
terminology-discussion might not be that useful. However, the important
thing is that developing an additional solution to solve this problem
will very likely add more overhead. The result will be more complex and
more difficult to implement. Until such a solution is developed we will
need to use complex workarounds (e.g. manual provisioning), may have
security problems or are not able to address certain scenarios at all.

But we have never done this before, why now? Because other than the
general purpose computers that we are using today, constrained devices
will communicate autonomously without the help of their user. They often will not even have user interfaces. Until now this was true for servers
which is why existing protocols protect them. In a true Internet of
Things this will also be true for clients. We therefore need to
reconsider how clients can be protected and how their actions can be
controlled by their owners.

DCAF supports scenarios with a single less-constrained device (AS) as
well as scenarios where both the Client and the Server have their own.
It works with OAuth and may even transport OAuth tickets if that is
necessary. It has a built-in key distribution mechanism and therefore is very efficient. The main fault of DCAF seems to be that we didn't call
it OAuth.

I think DCAF should be one of the building blocks (one of the tools in
our toolbox) that ACE is working on.

Best regards,
Steffi

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

 

--_000_56666935C2EE495B9D32639D887870ADnexusgroupcom_-- From nobody Wed Nov 18 10: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 1A8691A1B89 for ; Wed, 18 Nov 2015 10:17:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.288 X-Spam-Level: X-Spam-Status: No, score=0.288 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, HTTPS_HTTP_MISMATCH=1.989, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 n2olkevsRoei for ; Wed, 18 Nov 2015 10:17:22 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0116.outbound.protection.outlook.com [65.55.169.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53E281A1B6F for ; Wed, 18 Nov 2015 10:17:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8SLNUeOMPK+uNH5TPTvYOPG+1hnEnsqOMdnJJWDnmvs=; b=n/WU2ab3bWvQMDppWbtoG9paVBC48Bz0rA2VvNj1qEKrPVIbt+2pbd3qSFjriAhD5S8Qd+2ezICn60XG9K+oNvbntayGpv+1jAdf9fljkQdunKuNMGTBY8o0XRKAmAAp55KrpZJSvAVz4Q811ZEvAMaRDCON7O5xER0dJTohH2k= Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BN3PR0301MB1235.namprd03.prod.outlook.com (10.161.207.23) with Microsoft SMTP Server (TLS) id 15.1.318.15; Wed, 18 Nov 2015 18:17:19 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0331.019; Wed, 18 Nov 2015 18:17:19 +0000 From: Anthony Nadalin To: =?iso-8859-1?Q?Erik_Wahlstr=F6m_neXus?= Thread-Topic: [Ace] Solution direction Thread-Index: AQHRFTDg9A/8PVwLBkmphhXbn6Mnd56gBGOAgAGxGoCAAG/xoIAACdoAgAAAreA= Date: Wed, 18 Nov 2015 18:17:18 +0000 Message-ID: References: <564AEE51.30407@tzi.de> , <56666935-C2EE-495B-9D32-639D887870AD@nexusgroup.com> In-Reply-To: <56666935-C2EE-495B-9D32-639D887870AD@nexusgroup.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; x-originating-ip: [2001:4898:80e8:1::5b1] x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1235; 5:Lu64QH1P5uXtAG31CZNmpwd+PCANjS3keIY9h+tn+d/9tRZHFMnfooOUSOUcduFImVdQkymHKoL6vJmEoHb8mLsI533EAFPK0zg1Y+mPZyZCF2NKrLP/lAzhkzqaS3vvQNwGF72h3hq9RmQTln3ksQ==; 24:I33TgAQjvahC1nt3aDXV7vXqrqSnkemz0eeTZHjeq1NGeZQnBewFdoMgzv2cM8jhhhzYJuqvcS1cFUGT2UaBzEl3rV1gvuIlWwjyIvk9JBo=; 20:BjA6walcnlSOlfBIeiNKYzLmeSPTJOek66xXsTuwY6NGAg3bcGitZaJEXJJKIc1Ue/n1IdAavmBKaecutwqJUw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1235; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715)(189930954265078)(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001)(61426024)(61427024); SRVR:BN3PR0301MB1235; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1235; x-forefront-prvs: 0764C4A8CD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(189002)(53754006)(377454003)(51444003)(199003)(5004730100002)(189998001)(19580395003)(5005710100001)(10400500002)(110136002)(122556002)(86612001)(5003630100001)(5002640100001)(8990500004)(19300405004)(15975445007)(87936001)(16236675004)(10290500002)(5001960100002)(77096005)(790700001)(6116002)(102836003)(33656002)(86362001)(19580405001)(19617315012)(105586002)(97736004)(92566002)(81156007)(106356001)(106116001)(5003600100002)(50986999)(101416001)(5008740100001)(11100500001)(2950100001)(2900100001)(40100003)(54356999)(10090500001)(76176999)(74316001)(19625215002)(5007970100001)(19609705001)(93886004)(76576001)(586003)(99286002)(3826002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1235; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB1234E86283CB6887B2E44ACBA61C0BN3PR0301MB1234_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2015 18:17:18.8441 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1235 Archived-At: Cc: Kathleen Moriarty , Kepeng Li , "Ace@ietf.org" , Stefanie Gerdes , Hannes Tschofenig , Stephen Farrell Subject: Re: [Ace] Solution direction X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Nov 2015 18:17:29 -0000 --_000_BN3PR0301MB1234E86283CB6887B2E44ACBA61C0BN3PR0301MB1234_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Its more than that as we have to deal with JSON and CBOR, so far OAUTH only= deals with JSON in the various profiles/extensions From: Erik Wahlstr=F6m neXus [mailto:erik.wahlstrom@nexusgroup.com] Sent: Wednesday, November 18, 2015 10:14 AM To: Anthony Nadalin Cc: Stefanie Gerdes ; Hannes Tschofenig ; Stephen Farrell ; Kathleen Moriarty ; Kepeng Li ; Ac= e@ietf.org Subject: Re: [Ace] Solution direction Don't think so. If it's a JWT/JOSE or a CWT/COSE does not mean the world. I= t's just a token format (both will exist). A client don't really have to ca= re what type of token it is. It's just a access token. Then we have the framework on how access tokens are retrieved and sent to e= stablish a context. That's another thing. / Erik Sent from my iPhone On 18 Nov 2015, at 18:39, Anthony Nadalin > wrote: Don't or won't we already have that confusion with COSE and JOSE (much like= confusion with DCAF and OAUTH) ? From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Erik Wahlstr=F6m neXus Sent: Wednesday, November 18, 2015 2:58 AM To: Stefanie Gerdes > Cc: Hannes Tschofenig >; Stephen Farrell >; Kathleen Moriarty >; Kepeng Li >; Ace@ietf.org Subject: Re: [Ace] Solution direction Hi, Dynamic client registration (RFC7591) and User-Managed Access (UMA) Profile= of OAuth 2.0 (https://docs.kantarainitiative.org/uma/rec-uma-core.html) solves thos= e scenarios. To make them work with constrained clients and servers, both RFC7591 and UM= A must to be profiled in the same way as the OAuth for IoT draft did for co= re oauth. Both dynamic client registration and UMA where added later on after Oauth2 = (RFC6749) was completed. I think that's a sound model that we should follow= . Get the core concepts down, then extend them when needed and when we do t= hat we should re-use the concepts already there. Having two different proposals, both DCAF and OAuth for IoT, running at the= same time confuses implementors. I don't think we want to do that. / Erik On 17 Nov 2015, at 10:07, Stefanie Gerdes > wrote: Hi all, I think we should continue working on DCAF in ACE. It provides valuable concepts and mechanisms which is why many solutions in ACE draw heavily from DCAF. I think one aspect did not really become clear during the ACE session in Yokohama: A solution with only one supporting less constrained device will not be able to fully support communication between constrained nodes as DCAF does. One main question that is only partly solved by other solutions is: How can a constrained client authenticate the other party? A constrained device is not able to establish security associations as easily as a less constrained device. The keying material that is used for authorization and secure communication must securely be obtained. It can either be provisioned manually to the constrained device or a security association with a less constrained device is required that can then provide the keying material. An Authorization Server can provide session keys to the constrained devices, but the constrained device must have a security association with the AS to authenticate the origin of the session key. In a scenario where we have only a single AS and two constrained nodes, both need a security association with that AS. For cross-domain scenarios this might be difficult. We will need to manually provision the keying material to one of the devices which makes the dynamic setup of secure communication impossible. That's why we need two less-constrained devices in this scenario. You may think that this has nothing to do with authorization and therefore is not a topic for ACE. Well, it has, but another terminology-discussion might not be that useful. However, the important thing is that developing an additional solution to solve this problem will very likely add more overhead. The result will be more complex and more difficult to implement. Until such a solution is developed we will need to use complex workarounds (e.g. manual provisioning), may have security problems or are not able to address certain scenarios at all. But we have never done this before, why now? Because other than the general purpose computers that we are using today, constrained devices will communicate autonomously without the help of their user. They often will not even have user interfaces. Until now this was true for servers which is why existing protocols protect them. In a true Internet of Things this will also be true for clients. We therefore need to reconsider how clients can be protected and how their actions can be controlled by their owners. DCAF supports scenarios with a single less-constrained device (AS) as well as scenarios where both the Client and the Server have their own. It works with OAuth and may even transport OAuth tickets if that is necessary. It has a built-in key distribution mechanism and therefore is very efficient. The main fault of DCAF seems to be that we didn't call it OAuth. I think DCAF should be one of the building blocks (one of the tools in our toolbox) that ACE is working on. Best regards, Steffi _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace --_000_BN3PR0301MB1234E86283CB6887B2E44ACBA61C0BN3PR0301MB1234_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Its more than that as we have to deal= with JSON and CBOR, so far OAUTH only deals with JSON in the various profi= les/extensions

&nbs= p;

From: Erik Wahlstr=F6m neXus [mailto= :erik.wahlstrom@nexusgroup.com]
Sent: Wednesday, November 18, 2015 10:14 AM
To: Anthony Nadalin <tonynad@microsoft.com>
Cc: Stefanie Gerdes <gerdes@tzi.de>; Hannes Tschofenig <han= nes.tschofenig@gmx.net>; Stephen Farrell <stephen.farrell@cs.tcd.ie&g= t;; Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>; Kepeng Li &= lt;kepeng.lkp@alibaba-inc.com>; Ace@ietf.org
Subject: Re: [Ace] Solution direction

 

Don't think so. If it's a JWT/JOSE or a CWT/COSE doe= s not mean the world. It's just a token format (both will exist). A client = don't really have to care what type of token it is. It's just a access toke= n. 

 

Then we have the framework on how access tokens are = retrieved and sent to establish a context. That's another thing.

/ Erik


Sent from my iPhone


On 18 Nov 2015, at 18:39, Anthony Nadalin <tonynad@microsoft.com> wrote:

Don’t or won’t we already= have that confusion with COSE and JOSE (much like confusion with DCAF and = OAUTH) ?

 

From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Erik Wahlstr=F6m neXus
Sent: Wednesday, November 18, 2015 2:58 AM
To: Stefanie Gerdes <gerdes@tzi.= de>
Cc: Hannes Tschofenig <hannes.tschofenig@gmx.net>; Stephen Farrell <stephen.farrell@cs.tcd.ie>; Kathleen Mor= iarty <kathleen.mori= arty.ietf@gmail.com>; Kepeng Li <kepeng.lkp@ali= baba-inc.com>; Ace@ietf.org
Subject: Re: [Ace] Solution direction

 

Hi,

 

Dynamic client registration (RFC7591) and User-Manag= ed Access (UMA) Profile of OAuth 2.0 (https://docs.kantarainitiat= ive.org/uma/rec-uma-core.html) solves those scenarios.

 

To make them work with constrained clients and serve= rs, both RFC7591 and UMA must to be profiled in the same way as the OAuth f= or IoT draft did for core oauth.

 

Both dynamic client registration and UMA where added= later on after Oauth2 (RFC6749) was completed. I think that’s a soun= d model that we should follow. Get the core concepts down, then extend them= when needed and when we do that we should re-use the concepts already there.

 

Having two different proposals, both DCAF and OAuth = for IoT, running at the same time confuses implementors. I don’t thin= k we want to do that.

 

/ Erik

 

 

 

On 17 Nov 2015, at 10:07, Stefanie Gerdes <gerdes@tzi.de> wrote:

 

Hi all,

I think we should continue working on DCAF in ACE. It provides valuable
concepts and mechanisms which is why many solutions in ACE draw heavily
from DCAF.

I think one aspect did not really become clear during the ACE session in Yokohama: A solution with only one supporting less constrained device
will not be able to fully support communication between constrained
nodes as DCAF does. One main question that is only partly solved by
other solutions is: How can a constrained client authenticate the other
party?

A constrained device is not able to establish security associations as
easily as a less constrained device. The keying material that is used
for authorization and secure communication must securely be obtained. It can either be provisioned manually to the constrained device or a
security association with a less constrained device is required that can then provide the keying material.

An Authorization Server can provide session keys to the constrained
devices, but the constrained device must have a security association
with the AS to authenticate the origin of the session key. In a scenario where we have only a single AS and two constrained nodes, both need a
security association with that AS. For cross-domain scenarios this might be difficult. We will need to manually provision the keying material to
one of the devices which makes the dynamic setup of secure communication impossible. That's why we need two less-constrained devices in this
scenario.

You may think that this has nothing to do with authorization and
therefore is not a topic for ACE. Well, it has, but another
terminology-discussion might not be that useful. However, the important
thing is that developing an additional solution to solve this problem
will very likely add more overhead. The result will be more complex and
more difficult to implement. Until such a solution is developed we will
need to use complex workarounds (e.g. manual provisioning), may have
security problems or are not able to address certain scenarios at all.

But we have never done this before, why now? Because other than the
general purpose computers that we are using today, constrained devices
will communicate autonomously without the help of their user. They often will not even have user interfaces. Until now this was true for servers
which is why existing protocols protect them. In a true Internet of
Things this will also be true for clients. We therefore need to
reconsider how clients can be protected and how their actions can be
controlled by their owners.

DCAF supports scenarios with a single less-constrained device (AS) as
well as scenarios where both the Client and the Server have their own.
It works with OAuth and may even transport OAuth tickets if that is
necessary. It has a built-in key distribution mechanism and therefore is very efficient. The main fault of DCAF seems to be that we didn't call
it OAuth.

I think DCAF should be one of the building blocks (one of the tools in
our toolbox) that ACE is working on.

Best regards,
Steffi

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

 

--_000_BN3PR0301MB1234E86283CB6887B2E44ACBA61C0BN3PR0301MB1234_-- From nobody Wed Nov 18 10:31: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 D08891A212D for ; Wed, 18 Nov 2015 10:31:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.895 X-Spam-Level: X-Spam-Status: No, score=-0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585] 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 CcRdluVjCkOi for ; Wed, 18 Nov 2015 10:31:30 -0800 (PST) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C71AC1A1EEC for ; Wed, 18 Nov 2015 10:31:29 -0800 (PST) Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX01.ad.nexusgroup.com (10.75.28.40) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 18 Nov 2015 19:31:27 +0100 Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0995.032; Wed, 18 Nov 2015 19:31:27 +0100 From: =?Windows-1252?Q?Erik_Wahlstr=F6m_neXus?= To: Anthony Nadalin Thread-Topic: [Ace] Solution direction Thread-Index: AQHRFTDl5UZ0bor0rkKLapy4GQJkbZ6f85+AgAGxGQCAAHBCgIAAGk6s///wSgCAABS4Lg== Date: Wed, 18 Nov 2015 18:31:27 +0000 Message-ID: <0F619216-DE67-4640-90AD-3D0CAC4F80B0@nexusgroup.com> References: <564AEE51.30407@tzi.de> , <56666935-C2EE-495B-9D32-639D887870AD@nexusgroup.com>, In-Reply-To: Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_0F619216DE67464090AD3D0CAC4F80B0nexusgroupcom_" MIME-Version: 1.0 Archived-At: Cc: Kathleen Moriarty , Kepeng Li , "Ace@ietf.org" , Stefanie Gerdes , Hannes Tschofenig , Stephen Farrell Subject: Re: [Ace] Solution direction X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Nov 2015 18:31:35 -0000 --_000_0F619216DE67464090AD3D0CAC4F80B0nexusgroupcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Yes. Json will still be a key format. And it will be heavenly used, especia= lly for class 2 devices. In our tests we did see that JWT got us a very lon= g way. Especially if we just have to send token once (according to the draf= t). Then we have the super constrained class 1 devices. They need something mor= e compact. Sent from my iPhone On 18 Nov 2015, at 19:17, Anthony Nadalin > wrote: Its more than that as we have to deal with JSON and CBOR, so far OAUTH only= deals with JSON in the various profiles/extensions From: Erik Wahlstr=F6m neXus [mailto:erik.wahlstrom@nexusgroup.com] Sent: Wednesday, November 18, 2015 10:14 AM To: Anthony Nadalin > Cc: Stefanie Gerdes >; Hannes Tschofeni= g >; Stephen Fa= rrell >; Kathle= en Moriarty >; Kepeng Li >; Ace@ietf.org Subject: Re: [Ace] Solution direction Don't think so. If it's a JWT/JOSE or a CWT/COSE does not mean the world. I= t's just a token format (both will exist). A client don't really have to ca= re what type of token it is. It's just a access token. Then we have the framework on how access tokens are retrieved and sent to e= stablish a context. That's another thing. / Erik Sent from my iPhone On 18 Nov 2015, at 18:39, Anthony Nadalin > wrote: Don=92t or won=92t we already have that confusion with COSE and JOSE (much = like confusion with DCAF and OAUTH) ? From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Erik Wahlstr=F6m neXus Sent: Wednesday, November 18, 2015 2:58 AM To: Stefanie Gerdes > Cc: Hannes Tschofenig >; Stephen Farrell >; Kathleen Moriarty >; Kepeng Li >; Ace@ietf.org Subject: Re: [Ace] Solution direction Hi, Dynamic client registration (RFC7591) and User-Managed Access (UMA) Profile= of OAuth 2.0 (https://docs.kantarainitiative.org/uma/rec-uma-core.html) solves thos= e scenarios. To make them work with constrained clients and servers, both RFC7591 and UM= A must to be profiled in the same way as the OAuth for IoT draft did for co= re oauth. Both dynamic client registration and UMA where added later on after Oauth2 = (RFC6749) was completed. I think that=92s a sound model that we should foll= ow. Get the core concepts down, then extend them when needed and when we do= that we should re-use the concepts already there. Having two different proposals, both DCAF and OAuth for IoT, running at the= same time confuses implementors. I don=92t think we want to do that. / Erik On 17 Nov 2015, at 10:07, Stefanie Gerdes > wrote: Hi all, I think we should continue working on DCAF in ACE. It provides valuable concepts and mechanisms which is why many solutions in ACE draw heavily from DCAF. I think one aspect did not really become clear during the ACE session in Yokohama: A solution with only one supporting less constrained device will not be able to fully support communication between constrained nodes as DCAF does. One main question that is only partly solved by other solutions is: How can a constrained client authenticate the other party? A constrained device is not able to establish security associations as easily as a less constrained device. The keying material that is used for authorization and secure communication must securely be obtained. It can either be provisioned manually to the constrained device or a security association with a less constrained device is required that can then provide the keying material. An Authorization Server can provide session keys to the constrained devices, but the constrained device must have a security association with the AS to authenticate the origin of the session key. In a scenario where we have only a single AS and two constrained nodes, both need a security association with that AS. For cross-domain scenarios this might be difficult. We will need to manually provision the keying material to one of the devices which makes the dynamic setup of secure communication impossible. That's why we need two less-constrained devices in this scenario. You may think that this has nothing to do with authorization and therefore is not a topic for ACE. Well, it has, but another terminology-discussion might not be that useful. However, the important thing is that developing an additional solution to solve this problem will very likely add more overhead. The result will be more complex and more difficult to implement. Until such a solution is developed we will need to use complex workarounds (e.g. manual provisioning), may have security problems or are not able to address certain scenarios at all. But we have never done this before, why now? Because other than the general purpose computers that we are using today, constrained devices will communicate autonomously without the help of their user. They often will not even have user interfaces. Until now this was true for servers which is why existing protocols protect them. In a true Internet of Things this will also be true for clients. We therefore need to reconsider how clients can be protected and how their actions can be controlled by their owners. DCAF supports scenarios with a single less-constrained device (AS) as well as scenarios where both the Client and the Server have their own. It works with OAuth and may even transport OAuth tickets if that is necessary. It has a built-in key distribution mechanism and therefore is very efficient. The main fault of DCAF seems to be that we didn't call it OAuth. I think DCAF should be one of the building blocks (one of the tools in our toolbox) that ACE is working on. Best regards, Steffi _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace --_000_0F619216DE67464090AD3D0CAC4F80B0nexusgroupcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Yes. Json will still be a key format. And it will be heavenly used, es= pecially for class 2 devices. In our tests we d= id see that JWT got us a very long way. Especially if we just have to send = token once (according to the draft). 

Then we have the super constrained class 1 d= evices. They need something more compact. 

Sent from my iPhone

On 18 Nov 2015, at 19:17, Anthony Nadalin <tonynad@microsoft.com> wrote:

Its more than that as we have to deal= with JSON and CBOR, so far OAUTH only deals with JSON in the various profi= les/extensions

&nbs= p;

From: Erik Wahlstr=F6m neXus [mailto:erik.wahlstrom@nexusgroup= .com]
Sent: Wednesday, November 18, 2015 10:14 AM
To: Anthony Nadalin <ton= ynad@microsoft.com>
Cc: Stefanie Gerdes <gerdes@tzi.= de>; Hannes Tschofenig <hannes.tschofenig@gmx.net>; Stephen Farrell <stephen.farrell@cs.tcd.ie>; Kathleen Moriarty <= kathleen.moriarty.ietf@gmail.com>; Kepeng Li <kepeng.lkp@alibaba-inc.com>; Ace@ietf.org
Subject: Re: [Ace] Solution direction

 

Don't think so. If it's a JWT/JOSE or a CWT/COSE doe= s not mean the world. It's just a token format (both will exist). A client = don't really have to care what type of token it is. It's just a access toke= n. 

 

Then we have the framework on how access tokens are = retrieved and sent to establish a context. That's another thing.

/ Erik


Sent from my iPhone


On 18 Nov 2015, at 18:39, Anthony Nadalin <tonynad@microsoft.com> wrote:

Don=92t or won=92t we already have th= at confusion with COSE and JOSE (much like confusion with DCAF and OAUTH) ?=

 

From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Erik Wahlstr=F6m neXus
Sent: Wednesday, November 18, 2015 2:58 AM
To: Stefanie Gerdes <gerdes@tzi.= de>
Cc: Hannes Tschofenig <hannes.tschofenig@gmx.net>; Stephen Farrell <stephen.farrell@cs.tcd.ie>; Kathleen Mor= iarty <kathleen.mori= arty.ietf@gmail.com>; Kepeng Li <kepeng.lkp@ali= baba-inc.com>; Ace@ietf.org
Subject: Re: [Ace] Solution direction

 

Hi,

 

Dynamic client registration (RFC7591) and User-Manag= ed Access (UMA) Profile of OAuth 2.0 (https://docs.kantarainitiat= ive.org/uma/rec-uma-core.html) solves those scenarios.

 

To make them work with constrained clients and serve= rs, both RFC7591 and UMA must to be profiled in the same way as the OAuth f= or IoT draft did for core oauth.

 

Both dynamic client registration and UMA where added= later on after Oauth2 (RFC6749) was completed. I think that=92s a sound mo= del that we should follow. Get the core concepts down, then extend them whe= n needed and when we do that we should re-use the concepts already there.

 

Having two different proposals, both DCAF and OAuth = for IoT, running at the same time confuses implementors. I don=92t think we= want to do that.

 

/ Erik

 

 

 

On 17 Nov 2015, at 10:07, Stefanie Gerdes <gerdes@tzi.de> wrote:

 

Hi all,

I think we should continue working on DCAF in ACE. It provides valuable
concepts and mechanisms which is why many solutions in ACE draw heavily
from DCAF.

I think one aspect did not really become clear during the ACE session in Yokohama: A solution with only one supporting less constrained device
will not be able to fully support communication between constrained
nodes as DCAF does. One main question that is only partly solved by
other solutions is: How can a constrained client authenticate the other
party?

A constrained device is not able to establish security associations as
easily as a less constrained device. The keying material that is used
for authorization and secure communication must securely be obtained. It can either be provisioned manually to the constrained device or a
security association with a less constrained device is required that can then provide the keying material.

An Authorization Server can provide session keys to the constrained
devices, but the constrained device must have a security association
with the AS to authenticate the origin of the session key. In a scenario where we have only a single AS and two constrained nodes, both need a
security association with that AS. For cross-domain scenarios this might be difficult. We will need to manually provision the keying material to
one of the devices which makes the dynamic setup of secure communication impossible. That's why we need two less-constrained devices in this
scenario.

You may think that this has nothing to do with authorization and
therefore is not a topic for ACE. Well, it has, but another
terminology-discussion might not be that useful. However, the important
thing is that developing an additional solution to solve this problem
will very likely add more overhead. The result will be more complex and
more difficult to implement. Until such a solution is developed we will
need to use complex workarounds (e.g. manual provisioning), may have
security problems or are not able to address certain scenarios at all.

But we have never done this before, why now? Because other than the
general purpose computers that we are using today, constrained devices
will communicate autonomously without the help of their user. They often will not even have user interfaces. Until now this was true for servers
which is why existing protocols protect them. In a true Internet of
Things this will also be true for clients. We therefore need to
reconsider how clients can be protected and how their actions can be
controlled by their owners.

DCAF supports scenarios with a single less-constrained device (AS) as
well as scenarios where both the Client and the Server have their own.
It works with OAuth and may even transport OAuth tickets if that is
necessary. It has a built-in key distribution mechanism and therefore is very efficient. The main fault of DCAF seems to be that we didn't call
it OAuth.

I think DCAF should be one of the building blocks (one of the tools in
our toolbox) that ACE is working on.

Best regards,
Steffi

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

 

--_000_0F619216DE67464090AD3D0CAC4F80B0nexusgroupcom_-- From nobody Wed Nov 18 10:58: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 5631F1A6F81 for ; Wed, 18 Nov 2015 10:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.288 X-Spam-Level: X-Spam-Status: No, score=0.288 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, HTTPS_HTTP_MISMATCH=1.989, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-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 0AVmQcB8cISc for ; Wed, 18 Nov 2015 10:58:04 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0730.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:730]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC7731A6F7F for ; Wed, 18 Nov 2015 10:58:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PadxGnBTAPzdRRCoHoRMp82/n/pJijIvHgeUwk3RtAI=; b=BmfP1m3hGzkQV4gv+D5eC0M+jbwJPwJRSD9n61tDIyMBbi/hh9iGPMZrc/kVsLpu5Z/AJGzhoATXvaRF5EYEKQJqXL18HvfnYAggRGf+7JjgsmHUhLpBszzwnmFJlI5g5epy+QGcChSQhazgRr8933coXIeflIgJD16h9G+OZp4= Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) with Microsoft SMTP Server (TLS) id 15.1.331.20; Wed, 18 Nov 2015 18:57:42 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0331.019; Wed, 18 Nov 2015 18:57:42 +0000 From: Anthony Nadalin To: =?iso-8859-1?Q?Erik_Wahlstr=F6m_neXus?= Thread-Topic: [Ace] Solution direction Thread-Index: AQHRFTDg9A/8PVwLBkmphhXbn6Mnd56gBGOAgAGxGoCAAG/xoIAACdoAgAAAreCAAARUgIAABrBQ Date: Wed, 18 Nov 2015 18:57:42 +0000 Message-ID: References: <564AEE51.30407@tzi.de> , <56666935-C2EE-495B-9D32-639D887870AD@nexusgroup.com>, <0F619216-DE67-4640-90AD-3D0CAC4F80B0@nexusgroup.com> In-Reply-To: <0F619216-DE67-4640-90AD-3D0CAC4F80B0@nexusgroup.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; x-originating-ip: [2001:4898:80e8:1::5b1] x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1234; 5:e9ZGbjmKFRNqWeI5wii5CAJuPIC6M8cfOGLiyuN8cnOWWIOaD2s8QxpsL75bSsy08EpyXZSRuFigD4bDtVcGyFJeo5ktij1zWSvaYq437VGUIm+Aifwl211/nTP8SJ8pCAr50zWDpuTS9TmdqhiNiw==; 24:CpAenOJ0afHUz8Yemcrj0zPYReiKG5A8VPuTrDsvK8mIDeF+dBl3UKPkhy5/oAfDC0x2tKnuhzTnBSvmfSR6NEwOxWIrEazTyUJ02IniR3w= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1234; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715)(189930954265078)(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001)(61426024)(61427024); SRVR:BN3PR0301MB1234; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1234; x-forefront-prvs: 0764C4A8CD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(53754006)(377454003)(24454002)(199003)(189002)(51444003)(586003)(77096005)(93886004)(50986999)(92566002)(86362001)(189998001)(97736004)(15975445007)(76176999)(54356999)(19580405001)(106116001)(19580395003)(99286002)(11100500001)(5008740100001)(81156007)(122556002)(106356001)(102836003)(790700001)(6116002)(19300405004)(5003600100002)(5003630100001)(2900100001)(87936001)(40100003)(105586002)(2950100001)(10090500001)(19617315012)(5007970100001)(16236675004)(5001920100001)(110136002)(74316001)(19625215002)(76576001)(5001960100002)(10290500002)(33656002)(5004730100002)(5002640100001)(10400500002)(8990500004)(86612001)(101416001)(5005710100001)(19609705001)(3826002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1234; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB12348C0A2787AB11B59D1C85A61C0BN3PR0301MB1234_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2015 18:57:42.2336 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1234 Archived-At: Cc: Kathleen Moriarty , Kepeng Li , "Ace@ietf.org" , Stefanie Gerdes , Hannes Tschofenig , Stephen Farrell Subject: Re: [Ace] Solution direction X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Nov 2015 18:58:12 -0000 --_000_BN3PR0301MB12348C0A2787AB11B59D1C85A61C0BN3PR0301MB1234_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Makes more sense to have a solution that uses Oauth and JSON/JOSE and a DCA= F solution that uses CBOR/COSE instead of mixing all the combinations as th= at will be a nightmare From: Erik Wahlstr=F6m neXus [mailto:erik.wahlstrom@nexusgroup.com] Sent: Wednesday, November 18, 2015 10:31 AM To: Anthony Nadalin Cc: Stefanie Gerdes ; Hannes Tschofenig ; Stephen Farrell ; Kathleen Moriarty ; Kepeng Li ; Ac= e@ietf.org Subject: Re: [Ace] Solution direction Yes. Json will still be a key format. And it will be heavenly used, especia= lly for class 2 devices. In our tests we did see that JWT got us a very lon= g way. Especially if we just have to send token once (according to the draf= t). Then we have the super constrained class 1 devices. They need something mor= e compact. Sent from my iPhone On 18 Nov 2015, at 19:17, Anthony Nadalin > wrote: Its more than that as we have to deal with JSON and CBOR, so far OAUTH only= deals with JSON in the various profiles/extensions From: Erik Wahlstr=F6m neXus [mailto:erik.wahlstrom@nexusgroup.com] Sent: Wednesday, November 18, 2015 10:14 AM To: Anthony Nadalin > Cc: Stefanie Gerdes >; Hannes Tschofeni= g >; Stephen Fa= rrell >; Kathle= en Moriarty >; Kepeng Li >; Ace@ietf.org Subject: Re: [Ace] Solution direction Don't think so. If it's a JWT/JOSE or a CWT/COSE does not mean the world. I= t's just a token format (both will exist). A client don't really have to ca= re what type of token it is. It's just a access token. Then we have the framework on how access tokens are retrieved and sent to e= stablish a context. That's another thing. / Erik Sent from my iPhone On 18 Nov 2015, at 18:39, Anthony Nadalin > wrote: Don't or won't we already have that confusion with COSE and JOSE (much like= confusion with DCAF and OAUTH) ? From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Erik Wahlstr=F6m neXus Sent: Wednesday, November 18, 2015 2:58 AM To: Stefanie Gerdes > Cc: Hannes Tschofenig >; Stephen Farrell >; Kathleen Moriarty >; Kepeng Li >; Ace@ietf.org Subject: Re: [Ace] Solution direction Hi, Dynamic client registration (RFC7591) and User-Managed Access (UMA) Profile= of OAuth 2.0 (https://docs.kantarainitiative.org/uma/rec-uma-core.html) solves thos= e scenarios. To make them work with constrained clients and servers, both RFC7591 and UM= A must to be profiled in the same way as the OAuth for IoT draft did for co= re oauth. Both dynamic client registration and UMA where added later on after Oauth2 = (RFC6749) was completed. I think that's a sound model that we should follow= . Get the core concepts down, then extend them when needed and when we do t= hat we should re-use the concepts already there. Having two different proposals, both DCAF and OAuth for IoT, running at the= same time confuses implementors. I don't think we want to do that. / Erik On 17 Nov 2015, at 10:07, Stefanie Gerdes > wrote: Hi all, I think we should continue working on DCAF in ACE. It provides valuable concepts and mechanisms which is why many solutions in ACE draw heavily from DCAF. I think one aspect did not really become clear during the ACE session in Yokohama: A solution with only one supporting less constrained device will not be able to fully support communication between constrained nodes as DCAF does. One main question that is only partly solved by other solutions is: How can a constrained client authenticate the other party? A constrained device is not able to establish security associations as easily as a less constrained device. The keying material that is used for authorization and secure communication must securely be obtained. It can either be provisioned manually to the constrained device or a security association with a less constrained device is required that can then provide the keying material. An Authorization Server can provide session keys to the constrained devices, but the constrained device must have a security association with the AS to authenticate the origin of the session key. In a scenario where we have only a single AS and two constrained nodes, both need a security association with that AS. For cross-domain scenarios this might be difficult. We will need to manually provision the keying material to one of the devices which makes the dynamic setup of secure communication impossible. That's why we need two less-constrained devices in this scenario. You may think that this has nothing to do with authorization and therefore is not a topic for ACE. Well, it has, but another terminology-discussion might not be that useful. However, the important thing is that developing an additional solution to solve this problem will very likely add more overhead. The result will be more complex and more difficult to implement. Until such a solution is developed we will need to use complex workarounds (e.g. manual provisioning), may have security problems or are not able to address certain scenarios at all. But we have never done this before, why now? Because other than the general purpose computers that we are using today, constrained devices will communicate autonomously without the help of their user. They often will not even have user interfaces. Until now this was true for servers which is why existing protocols protect them. In a true Internet of Things this will also be true for clients. We therefore need to reconsider how clients can be protected and how their actions can be controlled by their owners. DCAF supports scenarios with a single less-constrained device (AS) as well as scenarios where both the Client and the Server have their own. It works with OAuth and may even transport OAuth tickets if that is necessary. It has a built-in key distribution mechanism and therefore is very efficient. The main fault of DCAF seems to be that we didn't call it OAuth. I think DCAF should be one of the building blocks (one of the tools in our toolbox) that ACE is working on. Best regards, Steffi _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace --_000_BN3PR0301MB12348C0A2787AB11B59D1C85A61C0BN3PR0301MB1234_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Makes more sense to have a solution t= hat uses Oauth and JSON/JOSE and a DCAF solution that uses CBOR/COSE instea= d of mixing all the combinations as that will be a nightmare

&nbs= p;

From: Erik Wahlstr=F6m neXus [mailto= :erik.wahlstrom@nexusgroup.com]
Sent: Wednesday, November 18, 2015 10:31 AM
To: Anthony Nadalin <tonynad@microsoft.com>
Cc: Stefanie Gerdes <gerdes@tzi.de>; Hannes Tschofenig <han= nes.tschofenig@gmx.net>; Stephen Farrell <stephen.farrell@cs.tcd.ie&g= t;; Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>; Kepeng Li &= lt;kepeng.lkp@alibaba-inc.com>; Ace@ietf.org
Subject: Re: [Ace] Solution direction

 

Yes. Json will still be a key format. And it will be= heavenly used, especially for class 2 devices. In our tests we did see tha= t JWT got us a very long way. Especially if we just have to send token once= (according to the draft). 

 

Then we have the super constrained class 1 devices. = They need something more compact. 


Sent from my iPhone


On 18 Nov 2015, at 19:17, Anthony Nadalin <tonynad@microsoft.com> wrote:

Its more than that as we have to deal= with JSON and CBOR, so far OAUTH only deals with JSON in the various profi= les/extensions

 

From: Erik Wahlstr=F6m neXus [mailto:erik.wahlstrom@nexusgroup= .com]
Sent: Wednesday, November 18, 2015 10:14 AM
To: Anthony Nadalin <ton= ynad@microsoft.com>
Cc: Stefanie Gerdes <gerdes@tzi.= de>; Hannes Tschofenig <hannes.tschofenig@gmx.net>; Stephen Farrell <stephen.farrell@cs.tcd.ie>; Kathleen Moriarty <= kathleen.moriarty.ietf@gmail.com>; Kepeng Li <kepeng.lkp@alibaba-inc.com>; Ace@ietf.org
Subject: Re: [Ace] Solution direction

 

Don't think so. If it's a JWT/JOSE or a CWT/COSE doe= s not mean the world. It's just a token format (both will exist). A client = don't really have to care what type of token it is. It's just a access toke= n. 

 

Then we have the framework on how access tokens are = retrieved and sent to establish a context. That's another thing.

/ Erik


Sent from my iPhone


On 18 Nov 2015, at 18:39, Anthony Nadalin <tonynad@microsoft.com> wrote:

Don’t or won’t we already= have that confusion with COSE and JOSE (much like confusion with DCAF and = OAUTH) ?

 

From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Erik Wahlstr=F6m neXus
Sent: Wednesday, November 18, 2015 2:58 AM
To: Stefanie Gerdes <gerdes@tzi.= de>
Cc: Hannes Tschofenig <hannes.tschofenig@gmx.net>; Stephen Farrell <stephen.farrell@cs.tcd.ie>; Kathleen Mor= iarty <kathleen.mori= arty.ietf@gmail.com>; Kepeng Li <kepeng.lkp@ali= baba-inc.com>; Ace@ietf.org
Subject: Re: [Ace] Solution direction

 

Hi,

 

Dynamic client registration (RFC7591) and User-Manag= ed Access (UMA) Profile of OAuth 2.0 (https://docs.kantarainitiat= ive.org/uma/rec-uma-core.html) solves those scenarios.

 

To make them work with constrained clients and serve= rs, both RFC7591 and UMA must to be profiled in the same way as the OAuth f= or IoT draft did for core oauth.

 

Both dynamic client registration and UMA where added= later on after Oauth2 (RFC6749) was completed. I think that’s a soun= d model that we should follow. Get the core concepts down, then extend them= when needed and when we do that we should re-use the concepts already there.

 

Having two different proposals, both DCAF and OAuth = for IoT, running at the same time confuses implementors. I don’t thin= k we want to do that.

 

/ Erik

 

 

 

On 17 Nov 2015, at 10:07, Stefanie Gerdes <gerdes@tzi.de> wrote:

 

Hi all,

I think we should continue working on DCAF in ACE. It provides valuable
concepts and mechanisms which is why many solutions in ACE draw heavily
from DCAF.

I think one aspect did not really become clear during the ACE session in Yokohama: A solution with only one supporting less constrained device
will not be able to fully support communication between constrained
nodes as DCAF does. One main question that is only partly solved by
other solutions is: How can a constrained client authenticate the other
party?

A constrained device is not able to establish security associations as
easily as a less constrained device. The keying material that is used
for authorization and secure communication must securely be obtained. It can either be provisioned manually to the constrained device or a
security association with a less constrained device is required that can then provide the keying material.

An Authorization Server can provide session keys to the constrained
devices, but the constrained device must have a security association
with the AS to authenticate the origin of the session key. In a scenario where we have only a single AS and two constrained nodes, both need a
security association with that AS. For cross-domain scenarios this might be difficult. We will need to manually provision the keying material to
one of the devices which makes the dynamic setup of secure communication impossible. That's why we need two less-constrained devices in this
scenario.

You may think that this has nothing to do with authorization and
therefore is not a topic for ACE. Well, it has, but another
terminology-discussion might not be that useful. However, the important
thing is that developing an additional solution to solve this problem
will very likely add more overhead. The result will be more complex and
more difficult to implement. Until such a solution is developed we will
need to use complex workarounds (e.g. manual provisioning), may have
security problems or are not able to address certain scenarios at all.

But we have never done this before, why now? Because other than the
general purpose computers that we are using today, constrained devices
will communicate autonomously without the help of their user. They often will not even have user interfaces. Until now this was true for servers
which is why existing protocols protect them. In a true Internet of
Things this will also be true for clients. We therefore need to
reconsider how clients can be protected and how their actions can be
controlled by their owners.

DCAF supports scenarios with a single less-constrained device (AS) as
well as scenarios where both the Client and the Server have their own.
It works with OAuth and may even transport OAuth tickets if that is
necessary. It has a built-in key distribution mechanism and therefore is very efficient. The main fault of DCAF seems to be that we didn't call
it OAuth.

I think DCAF should be one of the building blocks (one of the tools in
our toolbox) that ACE is working on.

Best regards,
Steffi

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

 

--_000_BN3PR0301MB12348C0A2787AB11B59D1C85A61C0BN3PR0301MB1234_-- From nobody Wed Nov 18 11:08: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 D3D661A8B84 for ; Wed, 18 Nov 2015 11:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.895 X-Spam-Level: X-Spam-Status: No, score=-0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585] 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 yUwMZH_brRAu for ; Wed, 18 Nov 2015 11:08:19 -0800 (PST) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9E7B1A8AFB for ; Wed, 18 Nov 2015 11:08:18 -0800 (PST) Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX01.ad.nexusgroup.com (10.75.28.40) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 18 Nov 2015 20:08:16 +0100 Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0995.032; Wed, 18 Nov 2015 20:08:16 +0100 From: =?Windows-1252?Q?Erik_Wahlstr=F6m_neXus?= To: Anthony Nadalin Thread-Topic: [Ace] Solution direction Thread-Index: AQHRFTDl5UZ0bor0rkKLapy4GQJkbZ6f85+AgAGxGQCAAHBCgIAAGk6s///wSgCAABS4Lv//9pEAgAAC8gA= Date: Wed, 18 Nov 2015 19:08:15 +0000 Message-ID: References: <564AEE51.30407@tzi.de> <56666935-C2EE-495B-9D32-639D887870AD@nexusgroup.com> <0F619216-DE67-4640-90AD-3D0CAC4F80B0@nexusgroup.com> In-Reply-To: Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2104) x-originating-ip: [213.113.163.201] Content-Type: multipart/alternative; boundary="_000_B823665ECBF04247B9ED37FA124243C5nexusgroupcom_" MIME-Version: 1.0 Archived-At: Cc: Kathleen Moriarty , Kepeng Li , "Ace@ietf.org" , Stefanie Gerdes , Hannes Tschofenig , Stephen Farrell Subject: Re: [Ace] Solution direction X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Nov 2015 19:08:24 -0000 --_000_B823665ECBF04247B9ED37FA124243C5nexusgroupcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable If the constrained world and the non-constrained world would exists in two = different parallell worlds that would make sense. But it=92s not. It=92s a = continuum where both big and small devices will talk to each other. I will = have a phone that talks standard oauth2 flows to get a token from an author= ization server and it=92s later used against a constrained device using coa= p and vice versa. I would be fine if we only could get by with a JWT, but I don=92t think so.= Please prove me wrong :) / Erik On 18 Nov 2015, at 19:57, Anthony Nadalin > wrote: Makes more sense to have a solution that uses Oauth and JSON/JOSE and a DCA= F solution that uses CBOR/COSE instead of mixing all the combinations as th= at will be a nightmare From: Erik Wahlstr=F6m neXus [mailto:erik.wahlstrom@nexusgroup.com] Sent: Wednesday, November 18, 2015 10:31 AM To: Anthony Nadalin > Cc: Stefanie Gerdes >; Hannes Tschofeni= g >; Stephen Fa= rrell >; Kathle= en Moriarty >; Kepeng Li >; Ace@ietf.org Subject: Re: [Ace] Solution direction Yes. Json will still be a key format. And it will be heavenly used, especia= lly for class 2 devices. In our tests we did see that JWT got us a very lon= g way. Especially if we just have to send token once (according to the draf= t). Then we have the super constrained class 1 devices. They need something mor= e compact. Sent from my iPhone On 18 Nov 2015, at 19:17, Anthony Nadalin > wrote: Its more than that as we have to deal with JSON and CBOR, so far OAUTH only= deals with JSON in the various profiles/extensions From: Erik Wahlstr=F6m neXus [mailto:erik.wahlstrom@nexusgroup.com] Sent: Wednesday, November 18, 2015 10:14 AM To: Anthony Nadalin > Cc: Stefanie Gerdes >; Hannes Tschofeni= g >; Stephen Fa= rrell >; Kathle= en Moriarty >; Kepeng Li >;Ace@ietf.org Subject: Re: [Ace] Solution direction Don't think so. If it's a JWT/JOSE or a CWT/COSE does not mean the world. I= t's just a token format (both will exist). A client don't really have to ca= re what type of token it is. It's just a access token. Then we have the framework on how access tokens are retrieved and sent to e= stablish a context. That's another thing. / Erik Sent from my iPhone On 18 Nov 2015, at 18:39, Anthony Nadalin > wrote: Don=92t or won=92t we already have that confusion with COSE and JOSE (much = like confusion with DCAF and OAUTH) ? From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Erik Wahlstr=F6m neXus Sent: Wednesday, November 18, 2015 2:58 AM To: Stefanie Gerdes > Cc: Hannes Tschofenig >; Stephen Farrell >; Kathleen Moriarty >; Kepeng Li >; Ace@ietf.org Subject: Re: [Ace] Solution direction Hi, Dynamic client registration (RFC7591) and User-Managed Access (UMA) Profile= of OAuth 2.0 (https://docs.kantarainitiative.org/uma/rec-uma-core.html) solves thos= e scenarios. To make them work with constrained clients and servers, both RFC7591 and UM= A must to be profiled in the same way as the OAuth for IoT draft did for co= re oauth. Both dynamic client registration and UMA where added later on after Oauth2 = (RFC6749) was completed. I think that=92s a sound model that we should foll= ow. Get the core concepts down, then extend them when needed and when we do= that we should re-use the concepts already there. Having two different proposals, both DCAF and OAuth for IoT, running at the= same time confuses implementors. I don=92t think we want to do that. / Erik On 17 Nov 2015, at 10:07, Stefanie Gerdes > wrote: Hi all, I think we should continue working on DCAF in ACE. It provides valuable concepts and mechanisms which is why many solutions in ACE draw heavily from DCAF. I think one aspect did not really become clear during the ACE session in Yokohama: A solution with only one supporting less constrained device will not be able to fully support communication between constrained nodes as DCAF does. One main question that is only partly solved by other solutions is: How can a constrained client authenticate the other party? A constrained device is not able to establish security associations as easily as a less constrained device. The keying material that is used for authorization and secure communication must securely be obtained. It can either be provisioned manually to the constrained device or a security association with a less constrained device is required that can then provide the keying material. An Authorization Server can provide session keys to the constrained devices, but the constrained device must have a security association with the AS to authenticate the origin of the session key. In a scenario where we have only a single AS and two constrained nodes, both need a security association with that AS. For cross-domain scenarios this might be difficult. We will need to manually provision the keying material to one of the devices which makes the dynamic setup of secure communication impossible. That's why we need two less-constrained devices in this scenario. You may think that this has nothing to do with authorization and therefore is not a topic for ACE. Well, it has, but another terminology-discussion might not be that useful. However, the important thing is that developing an additional solution to solve this problem will very likely add more overhead. The result will be more complex and more difficult to implement. Until such a solution is developed we will need to use complex workarounds (e.g. manual provisioning), may have security problems or are not able to address certain scenarios at all. But we have never done this before, why now? Because other than the general purpose computers that we are using today, constrained devices will communicate autonomously without the help of their user. They often will not even have user interfaces. Until now this was true for servers which is why existing protocols protect them. In a true Internet of Things this will also be true for clients. We therefore need to reconsider how clients can be protected and how their actions can be controlled by their owners. DCAF supports scenarios with a single less-constrained device (AS) as well as scenarios where both the Client and the Server have their own. It works with OAuth and may even transport OAuth tickets if that is necessary. It has a built-in key distribution mechanism and therefore is very efficient. The main fault of DCAF seems to be that we didn't call it OAuth. I think DCAF should be one of the building blocks (one of the tools in our toolbox) that ACE is working on. Best regards, Steffi _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace --_000_B823665ECBF04247B9ED37FA124243C5nexusgroupcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5C080D7CC8B14E4FB3DDBE8748523C35@nexusgroup.com> Content-Transfer-Encoding: quoted-printable If the constrained world and the non-constrained world would exists in two = different parallell worlds that would make sense. But it=92s not. It=92s a = continuum where both big and small devices will talk to each other. I will = have a phone that talks standard oauth2 flows to get a token from an authorization server and it=92s later used ag= ainst a constrained device using coap and vice versa.

I would be fine if we only could get by with a JWT, but I d= on=92t think so. Please prove me wrong :)

/ Erik
 

On 18 Nov 2015, at 19:57, Anthony Nadalin <tonynad@microsoft.com> wrote:=

Makes more sense to have a solution that uses O= auth and JSON/JOSE and a DCAF solution that uses CBOR/COSE instead of mixin= g all the combinations as that will be a nightmare 
 
From:&= nbsp;Erik Wahlstr=F6m neXus [m= ailto:erik.wahlstrom@nexusgroup.com] 
Sent: W= ednesday, November 18, 2015 10:31 AM
To: Ant= hony Nadalin <tonynad@microsoft.com>= ;
Cc: Ste= fanie Gerdes <gerdes@tzi.de>; Hannes Tschof= enig <hannes.tschofenig@gmx.net>= ;; Stephen Farrell <stephen.farrell@cs.t= cd.ie>; Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>; Kepeng Li <kepeng.lkp@alibaba-inc.co= m>; Ace@ietf.org
Subject: Re: [Ace] Solution direction
 
Yes. Json will still be a key format. And it will be heavenly used, especia= lly for class 2 devices. In our tests we did see that JWT got us a very lon= g way. Especially if we just have to send token once (according to the draf= t). 
 
Then we have the super constrained class 1 devices. They need something mor= e compact. 

Sent from my iPhone


On 18 Nov 2015, at 19:17, Anthony Nadalin <tonynad@microsoft.com> wrote:

Its more than that as we have to deal with JSON= and CBOR, so far OAUTH only deals with JSON in the various profiles/extens= ions
 
From:&= nbsp;Erik Wahlstr=F6m neXus [m= ailto:erik.wahlstrom@nexusgroup.com] 
Sent: W= ednesday, November 18, 2015 10:14 AM
To: Ant= hony Nadalin <tonynad@microsoft.com>= ;
Cc: Ste= fanie Gerdes <gerdes@tzi.de>; Hannes Tschof= enig <hannes.tschofenig@gmx.net>= ;; Stephen Farrell <stephen.farrell@cs.t= cd.ie>; Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>; Kepeng Li <kepeng.lkp@alibaba-inc.co= m>;Ace@ietf.org
Subject: Re: [Ace] Solution direction
 
Don't think so. If it's a JWT/JOSE or a CWT/COSE does not mean the world. I= t's just a token format (both will exist). A client don't really have to ca= re what type of token it is. It's just a access token. 
 
Then we have the framework on how access tokens are retrieved and sent to e= stablish a context. That's another thing.

/ Erik

Sent from my iPhone


On 18 Nov 2015, at 18:39, Anthony Nadalin <tonynad@microsoft.com> wrote:

Don=92t or won=92t we already have that confusi= on with COSE and JOSE (much like confusion with DCAF and OAUTH) ?
 
From:&= nbsp;Ace [mailto:ace-bounces@ietf.org] On Behalf Of Erik Wahls= tr=F6m neXus
Sent: W= ednesday, November 18, 2015 2:58 AM
To: Ste= fanie Gerdes <gerdes@tzi.de>
Cc: Han= nes Tschofenig <hannes.tschofenig@gmx.= net>; Stephen Farrell <stephen.= farrell@cs.tcd.ie>; Kathleen Moriarty <kathleen.mo= riarty.ietf@gmail.com>; Kepeng Li <kepeng.lkp@alibaba-inc.com>; Ace@ietf.org
Subject: Re: [Ace] Solution direction
 
Hi, 
 
Dynamic client registration (RFC7591) and User-Managed Access (UMA) Profile= of OAuth 2.0 (https://docs.kantarainitiative.org/uma/rec-uma-core.html) solves those scenarios.
 
To make them work with constrained clients and servers, both RFC7591 and UM= A must to be profiled in the same way as the OAuth for IoT draft did for co= re oauth.
 
Both dynamic client registration and UMA where added later on after Oauth2 = (RFC6749) was completed. I think that=92s a sound model that we should foll= ow. Get the core concepts down, then extend them when needed and when we do= that we should re-use the concepts already there.
 
Having two different proposals, both DCAF and OAuth for IoT, running at the= same time confuses implementors. I don=92t think we want to do that.
 
/ Erik
 
 
 
On 17 Nov 2015, at 10:07, Stefanie Gerdes <gerdes@= tzi.de> wrote:
 
Hi all,

I think we should continue working on DCAF in ACE. It provides valuable
concepts and mechanisms which is why many solutions in ACE draw heavily
from DCAF.

I think one aspect did not really become clear during the ACE session in Yokohama: A solution with only one supporting less constrained device
will not be able to fully support communication between constrained
nodes as DCAF does. One main question that is only partly solved by
other solutions is: How can a constrained client authenticate the other
party?

A constrained device is not able to establish security associations as
easily as a less constrained device. The keying material that is used
for authorization and secure communication must securely be obtained. It can either be provisioned manually to the constrained device or a
security association with a less constrained device is required that can then provide the keying material.

An Authorization Server can provide session keys to the constrained
devices, but the constrained device must have a security association
with the AS to authenticate the origin of the session key. In a scenario where we have only a single AS and two constrained nodes, both need a
security association with that AS. For cross-domain scenarios this might be difficult. We will need to manually provision the keying material to
one of the devices which makes the dynamic setup of secure communication impossible. That's why we need two less-constrained devices in this
scenario.

You may think that this has nothing to do with authorization and
therefore is not a topic for ACE. Well, it has, but another
terminology-discussion might not be that useful. However, the important
thing is that developing an additional solution to solve this problem
will very likely add more overhead. The result will be more complex and
more difficult to implement. Until such a solution is developed we will
need to use complex workarounds (e.g. manual provisioning), may have
security problems or are not able to address certain scenarios at all.

But we have never done this before, why now? Because other than the
general purpose computers that we are using today, constrained devices
will communicate autonomously without the help of their user. They often will not even have user interfaces. Until now this was true for servers
which is why existing protocols protect them. In a true Internet of
Things this will also be true for clients. We therefore need to
reconsider how clients can be protected and how their actions can be
controlled by their owners.

DCAF supports scenarios with a single less-constrained device (AS) as
well as scenarios where both the Client and the Server have their own.
It works with OAuth and may even transport OAuth tickets if that is
necessary. It has a built-in key distribution mechanism and therefore is very efficient. The main fault of DCAF seems to be that we didn't call
it OAuth.

I think DCAF should be one of the building blocks (one of the tools in
our toolbox) that ACE is working on.

Best regards,
Steffi

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

--_000_B823665ECBF04247B9ED37FA124243C5nexusgroupcom_-- From nobody Thu Nov 19 00:09: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 1D9FF1A0390 for ; Thu, 19 Nov 2015 00:07:49 -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 3VcAPaxQNTwb for ; Thu, 19 Nov 2015 00:07:48 -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 883D91A00E1 for ; Thu, 19 Nov 2015 00:07:47 -0800 (PST) X-AuditID: c1b4fb3a-f79136d0000071e2-b2-564d8351fec3 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F8.9E.29154.1538D465; Thu, 19 Nov 2015 09:07:45 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.32]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0248.002; Thu, 19 Nov 2015 09:07:44 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Renzo Navas Thread-Topic: [Ace] Solution direction Thread-Index: AQHRFTDg07zJr+9pXE+873zmc1A4Kp6f85+AgAGhoe+AAAN6gIABf54A Date: Thu, 19 Nov 2015 08:07:45 +0000 Message-ID: References: <564AEE51.30407@tzi.de> <87d1v7r88r.fsf@aung.informatik.uni-bremen.de> 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: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNIsWRmVeSWpSXmKPExsUyM2K7vW5gs2+YQfNJQ4vv33qYLZ6+6WB0 YPLYOesuu8eSJT+ZApiiuGxSUnMyy1KL9O0SuDKOPn/IXLBCuOLE1PVsDYwvhLoYOTkkBEwk 3v5bwAJhi0lcuLeerYuRi0NI4DCjRE9HAzOEs5hR4uvL+2wgVWwCLhIPGh4xgdgiAqoSk369 BYszCyhK7J51lh3EFgaK713/lB2iRk2i5+B8KNtNYtvTNWD1LEA1rZvmgtm8AhYSc/a/g1p2 nFHi9pnVQCdxcHAKBEr0vLMHqWEEuu77qTVMELvEJW49mc8EcbWAxJI955khbFGJl4//sYLY ogJ6EiuvN7FBxJUkGpc8YQUZySygKbF+lz7EGGuJxt1f2GHOn9L9kB3iHEGJkzOfsExglJiF ZNsshO5ZSLpnIemehaR7ASPrKkbR4tTi4tx0IyO91KLM5OLi/Dy9vNSSTYzAKDy45bfVDsaD zx0PMQpwMCrx8H5g8g0TYk0sK67MPcQowcGsJML7oAwoxJuSWFmVWpQfX1Sak1p8iFGag0VJ nLeZ6UGokEB6YklqdmpqQWoRTJaJg1OqgTFknf6+B7WJz3atu/PrT2xu3s4HtSeu5pYdjNK8 tGgN34KZTHP7P3teO90YGjU9Z/cMw/4dn/79/7Hc7K9O1ocQ15Ye70RlU+Yc+68pZgt+eda4 RZpVLXc6wGRu2PRHfZeL4+yfq9bKOUvsjZ8v1J86z/CjHk/Y2Uf9J3c7xfEmBhlbiC95OU2J pTgj0VCLuag4EQBZPSM4vgIAAA== Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Solution direction X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Nov 2015 08:07:49 -0000 SGkgUmVuem8sIA0KDQpPbiAyMDE1LTExLTE4IDExOjE0LCAiUmVuem8gTmF2YXMiIDxyZW56b2Vm cmFAZ21haWwuY29tPiB3cm90ZToNCg0KPkdvb2QgTW9ybmluZyBldmVyeWJvZHksDQo+DQo+SSBk byBhZ3JlZSB0aGF0IHdlIGhhdmUgdG8gc3RhcnQgZm9jdXNpbmcgb25lIG9uZSBzb2x1dGlvbiBv bmx5LCBhbmQNCj5PQXV0aCBzZWVtcyB0byBoYXZlIG1vcmUgbW9tZW50dW0gdGhhbiBEQ0FGLCBJ IHJlYWQgYm90aCBkcmFmdHMgYW5kDQo+T0F1dGggaXMgY2xlYXIgYW5kIGVhc3kgdG8gdW5kZXJz dGFuZC4NCj5JIGRvIG5vdCBvcHBvc2UgdG8gaGF2ZSBPQXV0aC1wcm9maWxpbmcgYXMgYSBzdGFy dGluZyBwb2ludC4NCj4NCj5Ib3dldmVyIEkgZG8gYWdyZWUgd2l0aCBPbGFmLCB0aGF0IHRoZXJl IGFyZSBzdGlsbCBzb21lIGNvcmUgaXNzdWVzDQo+dGhhdCBhcmUgbm90IGFkZHJlc3NlZCB3aXRo IE9BdXRoLWJhc2VkIHNvbHV0aW9uIHlldCBidXQgeWVzIHdpdGgNCj5EQ0FGLA0KPk5vdGFibHkg dGhlIENBUyBjb25jZXB0IGlzIG5vdCBwcmVzZW50IG9uIHRoZSBPQXV0aCBzb2x1dGlvbiB5ZXQs IGFuZA0KPkNBUyBpcyBhbiBpbnRlZ3JhbCBwYXJ0IG9mIHRoZSBBY3RvcnMgQUNFIGRvY3VtZW50 LCBzbyB3ZSB3aWxsDQo+ZXZlbnR1YWxseSBhcnJpdmUgdG8gdGhlIHBvaW50IHRoYXQgd2UgaGF2 ZSB0byB0YWtlIENBUyBpbiBhY2NvdW50LA0KPmFuZCB0aGVuIHdlIHdpbGwgYmUgZG9pbmcgc29t ZSB3b3JrIERDQUYgaXMgYWxyZWFkeSBkb2luZy4NCj5TbyBhcyBPbGFmIHNheSBJIHZvdGUgYWxz byBmb3IgbWFpbnRhaW5pbmcgRENBRiBhdCBsZWFzdCBmb3IgdGhlDQo+Y3Jvc3MtZG9tYWluIENB Uy1uZWVkZWQgY2FzZSwNCg0KQW4gb3ZlcndoZWxtaW5nIG1ham9yaXR5IGF0IHRoZSBGMkYgbWVl dGluZyB3YW50ZWQgb25lIHNvbHV0aW9uIHdpdGggdGhlDQpPQXV0aCBwcm9maWxlIGRyYWZ0IGFz IGEgc3RhcnRpbmcgcG9pbnQuIEFzc3VtaW5nIHRoaXMgaXMgY29uZmlybWVkIGJ5IHRoZQ0KV0cg KHBlbmRpbmcgdGhlIHJ1bGluZyBieSB0aGUgQUNFIGNoYWlycykgbXkgaW50ZXJwcmV0YXRpb24g b2Yg4oCcc3RhcnRpbmcNCnBvaW50IiBpcyB0aGF0IHdlIHRyeSB0byBidWlsZCB3aGF0ZXZlciBj b21wb25lbnRzIG1pc3Npbmcgb250byB0aGUgT0F1dGgNCnByb2ZpbGUgZHJhZnQsIG5vdCBtYWlu dGFpbiB0d28gc29sdXRpb25zLiBBbmQgaW4gdGhhdCByZXNwZWN0IGFueQ0KcHJvcG9zZWQgc29s dXRpb24gY29tcG9uZW50IGlzIHdlbGNvbWUgYW5kIHNob3VsZCBiZSBqdWRnZWQgYnkgaXRzIG1l cml0cywNCmxpa2UgZm9yIGV4YW1wbGUgeW91ciBwcm9wb3NhbCBmb3Igbm9uY2UtYmFzZWQgYXV0 aGVudGljYXRlZCBrZXkNCmVzdGFibGlzaG1lbnQuDQoNCg0KPiBhbmQgd2h5IG5vdCBzdGFydCBt ZXJnaW5nIGl0IHdpdGggdGhlDQo+T0F1dGgtYmFzZWQgc29sdXRpb24gb24gdGhlIHBvaW50cyB0 aGF0IE9BdXRoIGlzIG1pc3NpbmcuDQoNCkkgZG9u4oCZdCB0aGluayBhIG1lcmdlIGlzIGEgZ29v ZCBpZGVhLCBhdCBsZWFzdCBub3QgaW4gdGhlIHNlbnNlIG9mIHRoZQ0KYWN0b3JzIGRyYWZ0IHdo aWNoIGlzIGEgcmVzdWx0IG9mIHRoZSBkaWZmZXJlbnQgdmlld3MgcmVwcmVzZW50ZWQgYnkgc29t ZQ0Kb2YgdGhlIGF1dGhvcnMgYmVoaW5kIHRoZSBPQXV0aCBwcm9maWxlIGRyYWZ0IGFuZCBzb21l IG9mIHRoZSBhdXRob3JzDQpiZWhpbmQgRENBRi4gVGhlIHR3byBsYXRlc3QgcmV2aWV3cyB3ZXJl IG5vdCB2ZXJ5IHBvc2l0aXZlLg0KDQpHw7ZyYW4NCg0KPg0KDQo= From nobody Thu Nov 19 01:22: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 25C5C1B304B for ; Thu, 19 Nov 2015 01:19:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.887 X-Spam-Level: X-Spam-Status: No, score=-2.887 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, 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 gscJVfZJoLfV for ; Thu, 19 Nov 2015 01:19:55 -0800 (PST) Received: from xenon22.um.es (xenon22.um.es [155.54.212.162]) by ietfa.amsl.com (Postfix) with ESMTP id BDF481B29D7 for ; Thu, 19 Nov 2015 01:19:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon22.um.es (Postfix) with ESMTP id 79D8371BB; Thu, 19 Nov 2015 10:19:53 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon22.um.es Received: from xenon22.um.es ([127.0.0.1]) by localhost (xenon22.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id s99f8eRoWGG0; Thu, 19 Nov 2015 10:19:53 +0100 (CET) Received: from eduroam_um-7-75.inf.um.es (eduroam_um-7-75.inf.um.es [155.54.7.75]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon22.um.es (Postfix) with ESMTPSA id 779E77176; Thu, 19 Nov 2015 10:19:52 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Rafa Marin Lopez In-Reply-To: Date: Thu, 19 Nov 2015 10:19:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <67780087-1D9F-4018-ADB8-724A2D0BEE81@um.es> References: To: Renzo Navas X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: Rafa Marin Lopez , ace Subject: Re: [Ace] Authenticated Key Establishment, OAut PoP Token and Time Requirements for Constrained Devices X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Nov 2015 09:19:58 -0000 Hi Renzo: I agree with you that if we consider the distribution of a symmetric key = between three parties the literature is full of very concise and = security proven protocols.=20 Please count on me if some help is required in this area. Best Regards.=20 > El 13 nov 2015, a las 17:30, Renzo Navas = escribi=C3=B3: >=20 > Good Evening ACE ML, >=20 > Reading draft-seitz-ace-oauth-authz-00 (thanks to the authors for easy > to read doc) I was very interested by the PoP token that offers an > authenticated fresh key to be used for further secure the comm., > but I saw a very strong requirement for the RS to have a Time Sync. = mechanism. > I preview the objective of my mail, is to raise the question: >=20 > * Do we want to have a strong requirement for the constrained device > (RS) on an AA Architecture to have a Time Synchronization mechanism? > * Are we interested on offering non-time -nonce- based solution for an > OAuth PoP Token approach (for example when the token does not expire)? >=20 >=20 > (those interested on those concerns can read the rest of the mail, > that is rather long) >=20 > Regards >=20 > ------------------------------------------------------- >=20 > (Long version) >=20 > I've been working lately on the Authenticated Key Establishment > problem (The are two very good reference books [1][2]), focusing on > solutions with a Trusted Third Party, Symmetric Crypto, and not using > Time-stamps but Nonces (To avoid having to deal with time > synchronization).I have no strong Crypto background. >=20 > First I want to thank the authors of draft-seitz-ace-oauth-authz-00 , > very enlightening for the oauth neophytes. > I'm mostly interested on the authentication problem (auth. key > establishment), so the Proof-of-Possesion Token is a great > tool/concept, I took the time to read > draft-ietf-oauth-pop-architecture-05 and > draft-ietf-oauth-pop-key-distribution-02 to try to have all the > background possible. >=20 > So from the Authenticated key establishment mechanism point of view a > new fresh key between C and RS obtained by means of a PoP Token > mechanism -I think- will be similar to a Denning-Sacco shared key > protocol ( = http://www.lsv.ens-cachan.fr/Software/spore/denningSacco.html > . Client is A, AS is S, and RS is B), with the difference that the PoP > Token Timestamp have a start and end value that will make the > "mutiplicity attack" of Denning-Sacco limited on time. >=20 > My concern is that we will always need Time sync on the RS, that some > (most) times will be the constrained node (I think that the Client > does not need to be Time-aware), is that a MUST requirement? So > no-time aware devices will not be able to use OAuth PoP Token (or will > have to use token introspection, a good fallback solution btw) >=20 > Will be of interest offering a PoP Token generation and transport > mechanisms that offers an authenticated fresh key without the need of > Time-awarenness at the RS? >=20 > Time awareness at the RS offers great advantages, and maybe also Time > is always needed in all authorization solutions (to make easy token > expiration and freshness claims). >=20 > But I'm thinking about nonce-based authenticated key establishment. Of > course without time information embedded on the token, token > expiration will be more difficult: > * we will need token introspection, or > * the AS will contact the RS to revoke tokens, or > * we will need on a non-time based solution for revocation that does > not involve the AS, for example: a pop token/key is valid for use only > for one (or N) Resource Requests (of course if the response message > get lost we are screwed...) >=20 >=20 > So maybe we cannot avoid to have Time-awareness at the RS, for > Authorization purposes.. > But for Authentication certainly we can avoid Time, the three most > recommended by [2] nonce-based protocols are: > * Bellare-Rogaway (3PKD) [a Choo modified version It has been proven > provably secure on the strongest model to test auth. key establishment > protocols ] [3] > * Yahalom [a modified version has been proven secure on a weaker model > -bellare rogway- than 3PKD] [4] > * Boyd [Key Agreement: RS, C and AS contribute inputs to generate the > key] [proof idem yahalom ][5] >=20 > The message flows on that three of protocols do not respect OAuth > flows (I attach an image with the high level message flows, A is the > initiator always), so that take us apart a bit from OAuth... >=20 > This mail is starting to get long so I will try to conclude it, but > hopefully raise the question: >=20 >=20 > ** Are we interested on offering non-time -nonce- based solution for > an OAuth PoP Token approach (for example when the token does not > expire)**? >=20 >=20 >=20 > If NO, I guess that will need token introspection for RS that cannot > support time (That mechanism will map to other authenticated key > establishment protocol and not Denning-Sacco-based ) >=20 > if YES, are we interested in adapting a nonce-based auth. key > establishment protocol to OAuth PoP Token? >=20 >=20 > I hope this questions are useful, >=20 > Best regards >=20 > Renzo >=20 >=20 >=20 > [1] Colin A. Boyd and Anish Mathuria. 2003. Protocols for Key > Establishment and Authentication. Springer-Verlag New York, Inc., > Secaucus, NJ, USA. > [2] Kim-Kwang Raymond Choo. 2008. Secure Key Establishment (1ed.). > Springer Publishing Company, Incorporated. >=20 > [3] 3PKD - = http://eprints.qut.edu.au/1230/1/ACISP_Full_Version_-_03_May_2005.pdf > [4] Yahalom - https://eprint.iacr.org/2007/188.pdf > [5] Boyd - http://eprints.qut.edu.au/4421/1/4421_1.pdf > = ______________________________________= _________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From nobody Thu Nov 19 01:59: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 407001B3117 for ; Thu, 19 Nov 2015 01:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.185 X-Spam-Level: X-Spam-Status: No, score=-3.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585, 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 UZm069px4zOG for ; Thu, 19 Nov 2015 01:57:46 -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 E53FF1B3124 for ; Thu, 19 Nov 2015 01:57:44 -0800 (PST) Received: from [192.168.10.143] ([80.92.121.34]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lv9lm-1aQGpD0QIU-010POq; Thu, 19 Nov 2015 10:57:41 +0100 To: Somaraju Abhinav , "ace@ietf.org" References: <0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC07D@ATBRAGMSX02.itiso.net> <564C335F.4050404@gmx.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <564D9D13.5080308@gmx.net> Date: Thu, 19 Nov 2015 10:57:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <564C335F.4050404@gmx.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="nhojB36e0muocPoWLaMWOnVU9IRUfeXOr" X-Provags-ID: V03:K0:BDq2gsTdRMpPdFgbd5P14kN2EZghynNlwB6lwJKoFOuI5/Vsdem mWoK4Z33PtRC9lSYYiF2nb4gnrSem3bQJzTYtCUTieG04LTMP0tiSPPjiMnPGg1bXTj/PIZ yUPIH9SMSXAvKH3I6usBlNWh1yHhoGxvqWpvQxDe8G5htJvClvmzqQO9nPqt9LfpT2WxEAp 5nqv3jIVcl02OrQBQEHRg== X-UI-Out-Filterresults: notjunk:1;V01:K0:ABO7PAnwmsQ=:OZy3E9Ki1I2vO2fUPBHo0Y TKOoaMih6+R7846q5ZhazebHGQFwSTTwUyC+zZ5zIBA6by23xngLrpSOVg/fpJau7o4iH/40b Drm/v/TAXBAa9HrurCR7rNYcU4oyjXIud7QHb8gc4dUVxujyuyc+pmjPKxWZIGQkAJnuBkpBh 7jA6KBRqbvHy8nxcFSUFAJm6WGPtHaTU/22T162KDZg2mjhXAopdiumbPQGq/i8HxdIlZUHsP 58S4uEyz0YdGUbCnvQGbPNuqEvHEOmsbf2GFDSXLW/jUkRuAeIXpS/PjQk+/op+UPLIbAnao7 aEUIGnZDvxSdCB8FvA2DEWvFvUurd5iLpoWM8LH0tHPjPqWRMFrTaY6L1ACZUaYLhv25KhR+N NXmB7pZ9bbHvu05lpRNMo5g4ke1sjs/kjXdWu/pIdjk0iNJlEDL9X467jtR9Vgk9u9izt5YRU jbFJSx/UFCLRlhvcHABUAIaMH+BEOOwvbscL+zzEXJsAbotnca33fsgf0zkRffpHOrrvU9JFh bYE+tLZwewYm5gnwcPw/XKcuXrEPJC6PbnCsKIU71AB7qezT1VgR2Yz1qSxoYSZxvGOTVT6kP bhwUqZ6qM6Tv77y1nrfs1FgRJodMjW+0IyGYmilGu7qDzyu1B2ybdVxripXHm4+Uqc/Fss5Y1 q58Sbf65uEfKKscfY5dD6zfJ51QyY0pzXlZ2taY60P0q/wEpWH5TmkeKcY1SYwRl9IEClu7i5 JzmTDGNLMFyPlDlt8zsKC15jJ4zALk3wKo30MEMRkOtarAee7qW4lUzhVMo= Archived-At: Subject: Re: [Ace] [ACE] Permanant client-server relations and draft-seitz-ace-oauth-authz-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 09:57:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nhojB36e0muocPoWLaMWOnVU9IRUfeXOr Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable As an add-on to my email from yesterday I thought it might be also useful to look at the LWM2M protocol and to see whether it helps in those scenarios. I was thinking about doing a tutorial about LWM2M to the group for a little while already and maybe I should give it a try in December. Ciao Hannes On 11/18/2015 09:14 AM, Hannes Tschofenig wrote: > Hi Abhinav, >=20 >> I have reviewed the draft and find that is very nicely written and eas= y >> to understand. It would be nice to see this document taken further and= >> made into an RFC. > Thanks. >=20 > ~snip~ >=20 >> I would like to focus on the constrained device<->constrained device t= o >> case. In this case, we typically have permanent authorization rules th= at >> connect e.g. sensors to actuators (pushbuttons connected to lights). F= or >> such permanent authorization rules that do not change, does it still >> make sense to use OAuth. I would have thought that an access control >> list type solution that is managed by a central server is more suitabl= e >> for this situation. I would like to understand from the authors exactl= y >> which type of communication is being targeted in this draft and if it = is >> also applicable to create =93permanent client-server authorization rul= es=94. >=20 > The constrained client to constrained server case is conceptually > simpler than the other cases since the authorization step, as you noted= , > already happened out-of-band (by someone). >=20 > This scenario motivated me to write this IoT credential grant, see > draft-tschofenig-oauth-iot. In response to the draft submission I got > comments that claimed I can get the same functionality already with bas= e > OAuth, which may need to be discussed. At that time it was, however, > premature to have these detailed discussions. >=20 > Another input to take into account is a document you might well be > familiar with, namely . There we also > had use cases where the authorization rules were pre-provisioned into > the devices and, in addition to what you mentioned, the device may need= > to operate without having an authorization server to consult in real ti= me. >=20 > Does this make sense to you? >=20 > Ciao > Hannes >=20 --nhojB36e0muocPoWLaMWOnVU9IRUfeXOr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWTZ0UAAoJEGhJURNOOiAt5nwH/RS0AtOqMtyxo9jNdJwY13X5 7mdONeGdMJ9i7rbvtjbC573KaNFbPEPfu/hBeGqLmzGI7pjGS1xD0/e1cVf+f9Hy 1uJC2cv4UUgHI0rvDIlBn+3hmY2NV3Pi7612RfO7dcGFjQp8ae6apN7P7qcMK6FO 3kiZjy1grEf7kJ/e9gXRqxnISYPEhLXvtAMyWgslmeep1Hvod6PdxhFMm5BEhLMv Sux2F0K1kemJdctkRcmvl6pu94CzuBKt/k2wtnhyBYI1o5mBqW59rkf/PjvbtXli QVw7yE+Pwn5jrBWeKKVPIRF48OAHfLTDbncyv+n3jyAKs6MWY4swZWOhzEnerWw= =2uYO -----END PGP SIGNATURE----- --nhojB36e0muocPoWLaMWOnVU9IRUfeXOr-- From nobody Thu Nov 19 02:06: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 B60131B312F for ; Thu, 19 Nov 2015 02:04:24 -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 XYVTdcqL9Qda for ; Thu, 19 Nov 2015 02:04:21 -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 83D4C1B3132 for ; Thu, 19 Nov 2015 02:04:21 -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 tAJA43EO026571; Thu, 19 Nov 2015 11:04:04 +0100 (CET) Received: from [IPv6:2001:638:708:30da:4498:9a37:725d:af60] (unknown [IPv6:2001:638:708:30da:4498:9a37:725d:af60]) (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 3p1c6W6wrRz2PJs; Thu, 19 Nov 2015 11:04:03 +0100 (CET) To: =?UTF-8?Q?Erik_Wahlstr=c3=b6m_neXus?= , Anthony Nadalin References: <564AEE51.30407@tzi.de> <56666935-C2EE-495B-9D32-639D887870AD@nexusgroup.com> <0F619216-DE67-4640-90AD-3D0CAC4F80B0@nexusgroup.com> From: Stefanie Gerdes Message-ID: <564D9E8F.805@tzi.de> Date: Thu, 19 Nov 2015 11:03:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: Hannes Tschofenig , Stephen Farrell , Kathleen Moriarty , Kepeng Li , "Ace@ietf.org" Subject: Re: [Ace] Solution direction X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Nov 2015 10:04:25 -0000 Hi Erik, Fortunately, DCAF works with constrained AND less-constrained devices, so we will not have "parallel worlds" if we use it. Steffi On 11/18/2015 08:08 PM, Erik Wahlström neXus wrote: > If the constrained world and the non-constrained world would exists in two different parallell worlds that would make sense. But it’s not. It’s a continuum where both big and small devices will talk to each other. I will have a phone that talks standard oauth2 flows to get a token from an authorization server and it’s later used against a constrained device using coap and vice versa. > > I would be fine if we only could get by with a JWT, but I don’t think so. Please prove me wrong :) > > / Erik > > > On 18 Nov 2015, at 19:57, Anthony Nadalin > wrote: > > Makes more sense to have a solution that uses Oauth and JSON/JOSE and a DCAF solution that uses CBOR/COSE instead of mixing all the combinations as that will be a nightmare > > From: Erik Wahlström neXus [mailto:erik.wahlstrom@nexusgroup.com] > Sent: Wednesday, November 18, 2015 10:31 AM > To: Anthony Nadalin > > Cc: Stefanie Gerdes >; Hannes Tschofenig >; Stephen Farrell >; Kathleen Moriarty >; Kepeng Li >; Ace@ietf.org > Subject: Re: [Ace] Solution direction > > Yes. Json will still be a key format. And it will be heavenly used, especially for class 2 devices. In our tests we did see that JWT got us a very long way. Especially if we just have to send token once (according to the draft). > > Then we have the super constrained class 1 devices. They need something more compact. > > Sent from my iPhone > > On 18 Nov 2015, at 19:17, Anthony Nadalin > wrote: > Its more than that as we have to deal with JSON and CBOR, so far OAUTH only deals with JSON in the various profiles/extensions > > From: Erik Wahlström neXus [mailto:erik.wahlstrom@nexusgroup.com] > Sent: Wednesday, November 18, 2015 10:14 AM > To: Anthony Nadalin > > Cc: Stefanie Gerdes >; Hannes Tschofenig >; Stephen Farrell >; Kathleen Moriarty >; Kepeng Li >;Ace@ietf.org > Subject: Re: [Ace] Solution direction > > Don't think so. If it's a JWT/JOSE or a CWT/COSE does not mean the world. It's just a token format (both will exist). A client don't really have to care what type of token it is. It's just a access token. > > Then we have the framework on how access tokens are retrieved and sent to establish a context. That's another thing. > > / Erik > > Sent from my iPhone > > On 18 Nov 2015, at 18:39, Anthony Nadalin > wrote: > Don’t or won’t we already have that confusion with COSE and JOSE (much like confusion with DCAF and OAUTH) ? > > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Erik Wahlström neXus > Sent: Wednesday, November 18, 2015 2:58 AM > To: Stefanie Gerdes > > Cc: Hannes Tschofenig >; Stephen Farrell >; Kathleen Moriarty >; Kepeng Li >; Ace@ietf.org > Subject: Re: [Ace] Solution direction > > Hi, > > Dynamic client registration (RFC7591) and User-Managed Access (UMA) Profile of OAuth 2.0 (https://docs.kantarainitiative.org/uma/rec-uma-core.html) solves those scenarios. > > To make them work with constrained clients and servers, both RFC7591 and UMA must to be profiled in the same way as the OAuth for IoT draft did for core oauth. > > Both dynamic client registration and UMA where added later on after Oauth2 (RFC6749) was completed. I think that’s a sound model that we should follow. Get the core concepts down, then extend them when needed and when we do that we should re-use the concepts already there. > > Having two different proposals, both DCAF and OAuth for IoT, running at the same time confuses implementors. I don’t think we want to do that. > > / Erik > > > > On 17 Nov 2015, at 10:07, Stefanie Gerdes > wrote: > > Hi all, > > I think we should continue working on DCAF in ACE. It provides valuable > concepts and mechanisms which is why many solutions in ACE draw heavily > from DCAF. > > I think one aspect did not really become clear during the ACE session in > Yokohama: A solution with only one supporting less constrained device > will not be able to fully support communication between constrained > nodes as DCAF does. One main question that is only partly solved by > other solutions is: How can a constrained client authenticate the other > party? > > A constrained device is not able to establish security associations as > easily as a less constrained device. The keying material that is used > for authorization and secure communication must securely be obtained. It > can either be provisioned manually to the constrained device or a > security association with a less constrained device is required that can > then provide the keying material. > > An Authorization Server can provide session keys to the constrained > devices, but the constrained device must have a security association > with the AS to authenticate the origin of the session key. In a scenario > where we have only a single AS and two constrained nodes, both need a > security association with that AS. For cross-domain scenarios this might > be difficult. We will need to manually provision the keying material to > one of the devices which makes the dynamic setup of secure communication > impossible. That's why we need two less-constrained devices in this > scenario. > > You may think that this has nothing to do with authorization and > therefore is not a topic for ACE. Well, it has, but another > terminology-discussion might not be that useful. However, the important > thing is that developing an additional solution to solve this problem > will very likely add more overhead. The result will be more complex and > more difficult to implement. Until such a solution is developed we will > need to use complex workarounds (e.g. manual provisioning), may have > security problems or are not able to address certain scenarios at all. > > But we have never done this before, why now? Because other than the > general purpose computers that we are using today, constrained devices > will communicate autonomously without the help of their user. They often > will not even have user interfaces. Until now this was true for servers > which is why existing protocols protect them. In a true Internet of > Things this will also be true for clients. We therefore need to > reconsider how clients can be protected and how their actions can be > controlled by their owners. > > DCAF supports scenarios with a single less-constrained device (AS) as > well as scenarios where both the Client and the Server have their own. > It works with OAuth and may even transport OAuth tickets if that is > necessary. It has a built-in key distribution mechanism and therefore is > very efficient. The main fault of DCAF seems to be that we didn't call > it OAuth. > > I think DCAF should be one of the building blocks (one of the tools in > our toolbox) that ACE is working on. > > Best regards, > Steffi > > _______________________________________________ > 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 Nov 19 02:22:07 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC3A1B315E for ; Thu, 19 Nov 2015 02:19:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.885 X-Spam-Level: X-Spam-Status: No, score=-2.885 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585] 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 cVggSHMW32SE for ; Thu, 19 Nov 2015 02:19:54 -0800 (PST) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD1FD1B317D for ; Thu, 19 Nov 2015 02:19:53 -0800 (PST) Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX02.ad.nexusgroup.com (10.75.28.43) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 19 Nov 2015 11:19:50 +0100 Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0995.032; Thu, 19 Nov 2015 11:19:51 +0100 From: =?Windows-1252?Q?Erik_Wahlstr=F6m_neXus?= To: Stefanie Gerdes Thread-Topic: [Ace] Solution direction Thread-Index: AQHRFTDl5UZ0bor0rkKLapy4GQJkbZ6f85+AgAGxGQCAAHBCgIAAGk6s///wSgCAABS4Lv//9pEAgAAC8gCAAPpFgIAABG4A Date: Thu, 19 Nov 2015 10:19:51 +0000 Message-ID: <291CFA30-065D-4334-90DE-671AC9AE8146@nexusgroup.com> References: <564AEE51.30407@tzi.de> <56666935-C2EE-495B-9D32-639D887870AD@nexusgroup.com> <0F619216-DE67-4640-90AD-3D0CAC4F80B0@nexusgroup.com> <564D9E8F.805@tzi.de> In-Reply-To: <564D9E8F.805@tzi.de> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2104) x-originating-ip: [213.113.163.201] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Anthony Nadalin , Kathleen Moriarty , Kepeng Li , "Ace@ietf.org" , Hannes Tschofenig , Stephen Farrell Subject: Re: [Ace] Solution direction X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Nov 2015 10:19:58 -0000 Hi Steffi, Yes, I realise that DCAF can be profiled and used to non-constrained device= s just as OAuth can be profiled for constrained devices. For me, it=92s mor= e of a question of where momentum is and taking that further to target the = continuum of both non-constrained and constrained devices (i.e. take OAuth = to constrained devices). / Erik > On 19 Nov 2015, at 11:03, Stefanie Gerdes wrote: >=20 > Hi Erik, >=20 > Fortunately, DCAF works with constrained AND less-constrained devices, > so we will not have "parallel worlds" if we use it. >=20 > Steffi >=20 > On 11/18/2015 08:08 PM, Erik Wahlstr=F6m neXus wrote: >> If the constrained world and the non-constrained world would exists in t= wo different parallell worlds that would make sense. But it=92s not. It=92s= a continuum where both big and small devices will talk to each other. I wi= ll have a phone that talks standard oauth2 flows to get a token from an aut= horization server and it=92s later used against a constrained device using = coap and vice versa. >>=20 >> I would be fine if we only could get by with a JWT, but I don=92t think = so. Please prove me wrong :) >>=20 >> / Erik >>=20 >>=20 >> On 18 Nov 2015, at 19:57, Anthony Nadalin > wrote: >>=20 >> Makes more sense to have a solution that uses Oauth and JSON/JOSE and a = DCAF solution that uses CBOR/COSE instead of mixing all the combinations as= that will be a nightmare >>=20 >> From: Erik Wahlstr=F6m neXus [mailto:erik.wahlstrom@nexusgroup.com] >> Sent: Wednesday, November 18, 2015 10:31 AM >> To: Anthony Nadalin = > >> Cc: Stefanie Gerdes >; Hannes Tschof= enig >; Stephen= Farrell >; Kat= hleen Moriarty >; Kepeng Li >; Ace@ietf.org >> Subject: Re: [Ace] Solution direction >>=20 >> Yes. Json will still be a key format. And it will be heavenly used, espe= cially for class 2 devices. In our tests we did see that JWT got us a very = long way. Especially if we just have to send token once (according to the d= raft). >>=20 >> Then we have the super constrained class 1 devices. They need something = more compact. >>=20 >> Sent from my iPhone >>=20 >> On 18 Nov 2015, at 19:17, Anthony Nadalin > wrote: >> Its more than that as we have to deal with JSON and CBOR, so far OAUTH o= nly deals with JSON in the various profiles/extensions >>=20 >> From: Erik Wahlstr=F6m neXus [mailto:erik.wahlstrom@nexusgroup.com] >> Sent: Wednesday, November 18, 2015 10:14 AM >> To: Anthony Nadalin = > >> Cc: Stefanie Gerdes >; Hannes Tschof= enig >; Stephen= Farrell >; Kat= hleen Moriarty >; Kepeng Li >;Ace@ietf.org >> Subject: Re: [Ace] Solution direction >>=20 >> Don't think so. If it's a JWT/JOSE or a CWT/COSE does not mean the world= . It's just a token format (both will exist). A client don't really have to= care what type of token it is. It's just a access token. >>=20 >> Then we have the framework on how access tokens are retrieved and sent t= o establish a context. That's another thing. >>=20 >> / Erik >>=20 >> Sent from my iPhone >>=20 >> On 18 Nov 2015, at 18:39, Anthony Nadalin > wrote: >> Don=92t or won=92t we already have that confusion with COSE and JOSE (mu= ch like confusion with DCAF and OAUTH) ? >>=20 >> From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Erik Wahlstr=F6m ne= Xus >> Sent: Wednesday, November 18, 2015 2:58 AM >> To: Stefanie Gerdes > >> Cc: Hannes Tschofenig >; Stephen Farrell >; Kathleen Moriarty >; Kepeng Li >; Ace@ietf.org >> Subject: Re: [Ace] Solution direction >>=20 >> Hi, >>=20 >> Dynamic client registration (RFC7591) and User-Managed Access (UMA) Prof= ile of OAuth 2.0 (https://docs.kantarainitiative.org/uma/rec-uma-core.html<= https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fdocs.kan= tarainitiative.org%2fuma%2frec-uma-core.html&data=3D01%7c01%7ctonynad%40mic= rosoft.com%7c2e4a423528b84869171d08d2f0071896%7c72f988bf86f141af91ab2d7cd01= 1db47%7c1&sdata=3DALYnNx65C18sUYQB3LgXOc5s5teOHDYv0NzqmCsubAI%3d>) solves t= hose scenarios. >>=20 >> To make them work with constrained clients and servers, both RFC7591 and= UMA must to be profiled in the same way as the OAuth for IoT draft did for= core oauth. >>=20 >> Both dynamic client registration and UMA where added later on after Oaut= h2 (RFC6749) was completed. I think that=92s a sound model that we should f= ollow. Get the core concepts down, then extend them when needed and when we= do that we should re-use the concepts already there. >>=20 >> Having two different proposals, both DCAF and OAuth for IoT, running at = the same time confuses implementors. I don=92t think we want to do that. >>=20 >> / Erik >>=20 >>=20 >>=20 >> On 17 Nov 2015, at 10:07, Stefanie Gerdes > wrote: >>=20 >> Hi all, >>=20 >> I think we should continue working on DCAF in ACE. It provides valuable >> concepts and mechanisms which is why many solutions in ACE draw heavily >> from DCAF. >>=20 >> I think one aspect did not really become clear during the ACE session in >> Yokohama: A solution with only one supporting less constrained device >> will not be able to fully support communication between constrained >> nodes as DCAF does. One main question that is only partly solved by >> other solutions is: How can a constrained client authenticate the other >> party? >>=20 >> A constrained device is not able to establish security associations as >> easily as a less constrained device. The keying material that is used >> for authorization and secure communication must securely be obtained. It >> can either be provisioned manually to the constrained device or a >> security association with a less constrained device is required that can >> then provide the keying material. >>=20 >> An Authorization Server can provide session keys to the constrained >> devices, but the constrained device must have a security association >> with the AS to authenticate the origin of the session key. In a scenario >> where we have only a single AS and two constrained nodes, both need a >> security association with that AS. For cross-domain scenarios this might >> be difficult. We will need to manually provision the keying material to >> one of the devices which makes the dynamic setup of secure communication >> impossible. That's why we need two less-constrained devices in this >> scenario. >>=20 >> You may think that this has nothing to do with authorization and >> therefore is not a topic for ACE. Well, it has, but another >> terminology-discussion might not be that useful. However, the important >> thing is that developing an additional solution to solve this problem >> will very likely add more overhead. The result will be more complex and >> more difficult to implement. Until such a solution is developed we will >> need to use complex workarounds (e.g. manual provisioning), may have >> security problems or are not able to address certain scenarios at all. >>=20 >> But we have never done this before, why now? Because other than the >> general purpose computers that we are using today, constrained devices >> will communicate autonomously without the help of their user. They often >> will not even have user interfaces. Until now this was true for servers >> which is why existing protocols protect them. In a true Internet of >> Things this will also be true for clients. We therefore need to >> reconsider how clients can be protected and how their actions can be >> controlled by their owners. >>=20 >> DCAF supports scenarios with a single less-constrained device (AS) as >> well as scenarios where both the Client and the Server have their own. >> It works with OAuth and may even transport OAuth tickets if that is >> necessary. It has a built-in key distribution mechanism and therefore is >> very efficient. The main fault of DCAF seems to be that we didn't call >> it OAuth. >>=20 >> I think DCAF should be one of the building blocks (one of the tools in >> our toolbox) that ACE is working on. >>=20 >> Best regards, >> Steffi >>=20 >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >>=20 >=20 > --=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 Thu Nov 19 02:33: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 0CC901B31A4 for ; Thu, 19 Nov 2015 02:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGnP9_mEC0Tc for ; Thu, 19 Nov 2015 02:32:10 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E23571B31A3 for ; Thu, 19 Nov 2015 02:32:09 -0800 (PST) Received: by lbbsy6 with SMTP id sy6so40732401lbb.2 for ; Thu, 19 Nov 2015 02:32:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=REpsn3U7RD3BwITcJyMZFajNkkIHYeMVr5QvVJQ2j9U=; b=jFl6nL6Tv8uptUn6XL1CVjQtZK2gDjTMKpYcbXYTFBFg9i69iptlIcrnlZ5Xl9oXV8 gEwNxv1nab1S1hAB/4SrfUegIZBgdtY1D1YsEVAvuLT1i02OshKX53eCn56Dzp3MH/Fl ioi8n+ORHqyy+bEaxwkeNwjgzTLiZqMOkFhhDD7rpru90QkoydjeR1a5eLmW/U71phcS j0eUF87RMyKjrNjsarBsRgilAbIyfOzFu0YD/wT0hqEMW8MKNQtE1s8t9AdZnyDHUGh6 VVwb867KB4ysQI1q38IGVTUF8GMpFZH9vEtKnT5F3RWMY6YGXEl83CiISAx2l8zTDpwZ K9SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=REpsn3U7RD3BwITcJyMZFajNkkIHYeMVr5QvVJQ2j9U=; b=mt0qsYtwFE/tvDw13FDlGKsexqLKfGT7CWQZG4MgtHY1RUGShWIbbMnEse1KOU2p3P dt/33HCvGCNEe9xmZ9t1mFBwH8lZgqXEmIVHzuzudFwGMj2gpeWiy+zrNsXJhz+GO+dh P3ICzfVt0mS9MsPUAa4ijKc5aFREyprO24/lCfr+70kF9b8289/6zsmwatQc5iOF89JV w4h9qZ3KfifMVgYlFJjPj9Gi21ddT1ALV0J/qeLRKxxLkmdRudRW6gf+C0QDjqe5xhlN R6ogPe48kX85re18OLVyoRVjhQUPYdbeIeqIbUdiJMat8FkKtlqTQ0oXNt9HCS7kFzRz +hmQ== X-Gm-Message-State: ALoCoQmuxxZnc5r2pLyjY//X9XSeLmW4eLSMmi+//faemwmGZRPIFTPTv9v0pi8PEviQExhro4Gx X-Received: by 10.112.157.166 with SMTP id wn6mr2903259lbb.30.1447929127843; Thu, 19 Nov 2015 02:32:07 -0800 (PST) Received: from [192.168.0.108] ([85.235.10.186]) by smtp.gmail.com with ESMTPSA id h196sm1103344lfb.48.2015.11.19.02.32.06 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Nov 2015 02:32:06 -0800 (PST) To: ace@ietf.org References: <0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC07D@ATBRAGMSX02.itiso.net> <564C335F.4050404@gmx.net> <564D9D13.5080308@gmx.net> From: Ludwig Seitz Message-ID: <564DA526.7010604@sics.se> Date: Thu, 19 Nov 2015 11:32:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <564D9D13.5080308@gmx.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070707060700010405090101" Archived-At: Subject: Re: [Ace] [ACE] Permanant client-server relations and draft-seitz-ace-oauth-authz-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 10:32:12 -0000 This is a cryptographically signed message in MIME format. --------------ms070707060700010405090101 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 2015-11-19 10:57, Hannes Tschofenig wrote: > As an add-on to my email from yesterday I thought it might be also > useful to look at the LWM2M protocol and to see whether it helps in > those scenarios. I was thinking about doing a tutorial about LWM2M to > the group for a little while already and maybe I should give it a try i= n > December. > > Ciao > Hannes > I think a LWM2M tutorial would be very helpful. Please do give it a try. /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 --------------ms070707060700010405090101 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DFQwggYYMIIFAKADAgECAgMMhpgwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTAxMDgwODM5MDZaFw0xNjAxMDkyMjQxMzBaMDgxFzAV BgNVBAMMDmx1ZHdpZ0BzaWNzLnNlMR0wGwYJKoZIhvcNAQkBFg5sdWR3aWdAc2ljcy5zZTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVB4rAuq4FxbARxwRqPLpc/3C194F+V H4XMKK6fu3Y8zDLijzNSjh6tG41oZhXvJcvAs1nZNjUutNLeyBAUFiYhy7HXNdlKpjbMEFKQ +6KpEdZ0Rk+pXgB2E1mqZEfp3M2djcQ/h+7uGVlSGYNAxYk6rWPIIWBx2GMvAQaHP4xxu/F+ PiSQILOVzmtIFZe1t/Lw71aaNeMYVhARo8z5PVsVoq6gBeujxfiRLtiQ/S8xW6RKvNvUkVyT BQfcKaEDZR9FENNf9rFgiAcT6R7hI8RBf1d2fxdlbDU8uM72K3fvzGDt8N9Bfm1kDWbDBxJE 1taRIYs+60D1kwV6DvBb9MECAwEAAaOCAtQwggLQMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6ryrKahJtBOEdbIL AAWCpOsQyagwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwGQYDVR0RBBIwEIEO bHVkd2lnQHNpY3Muc2UwggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYB BQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqBvlRo aXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDEgVmFs aWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUg cmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEF BQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEvY2xpZW50L2NhMEIG CCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNs aWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqG SIb3DQEBBQUAA4IBAQBl8BbG0n7+JjFqiJOuAqMbkeqM6Oyd+4oHGu3fbaSiM1SKesae2bfm vifV99a+M4DERZ2SVkOYcvNlv31Q3hvYtzRjDOqewzVKxo021R3ddQULW1DhvTEpclikG5rd 0NRJQn+EkSwEKLeUj68i0dhU8ULhZDDq3A81cTcZzIGrTjNnwDvCktB/sF/iO4At6RJ24P3j KjYFPirW3NsvZ2gzZizSzeubPE0/cWcqEBJ/UtaFPF54efejjLuPRHHMLPDcvrwBhEiBxuG6 oTEo465g4pS9Vo/Z0GoZgZyA+aGQ+YPbPSsqsYmSBjZ6MGGDqQq0niE2dW+8IOdHQvMkqI52 MIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcN MDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxwmDzM4t2BqxKaQu E6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESip7vMz39ScLpNLbL1QpOlPW/t FIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9ftTyhxvxWkf8KW37iKrueKsxw 2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsWoTb7q8hmgv6Nv3Hg9rmA1/VP BIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/43Yksq60jExipA4l5uv9/+Hm 33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IBrTCCAakwDwYDVR0TAQH/BAUw AwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8G A1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsGAQUFBwEBBFowWDAnBggrBgEF BQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0GCCsGAQUFBzAChiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQwUjAnoCWgI4YhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcBAgEwZjAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDov L3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjANBgkqhkiG9w0BAQUFAAOCAgEA CoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHbWNaPeQn3oBSU8KgQZn/Kck1J xbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4OxK9QPoSjCMxM3HbkZCDJgnl E8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0KAkXCzeQNLeA5LlYUzFyM7kP Ap8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL04qYK/zu+Qg1Bw0RwgigVZs/0 c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0IFiNu9IPuTGAPBn4CPxD0+Ru 8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6fDEPme+1Nbi+03pVjuZQKbGw KJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVtjYsv0L1TSm2+NwON58tO+pIV zu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm48ZCYfAWLb/Xj7F5JQMbZvCex glAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BIXRsF1du4qESm4/3CKuyUV7p9 DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJ bnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJYIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MTExOTEwMzIwNlowLwYJKoZI hvcNAQkEMSIEIGd1mseerHFB9a+VLnCYLIBdR+zk0STehIBN2wXl6RLqMGwGCSqGSIb3DQEJ DzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQB gjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwgacG CyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC AwyGmDANBgkqhkiG9w0BAQEFAASCAQB9pjLv8QCmq4rIT2iMCpgIl2Bc9sOiIaituls34J/G C5eTRn/iQnUmZ7Mp8Ieis4PtQml+ocWZM9m+wRCXWZz/7PXlvAsN815C/S+ngGQu/p6kg1HV tnCQ5ypcC/WasoVFtyeEpsl4jbaLJ/QeG8Fckv6TptvFy2OQ/LAVSkbzHn7/e26kg5j4vOWf A3Z9AzsoQDeT5W1hYYnRLzuzEK2T/8mQkbnAfmCCcGslWoPn8Qu3AN2kg7xg8LOH3PqQIlAt oYmhWvBZFmEVtJd4Hxe9+PaEkqyjpYSRBZc4F/DkVQn7yZZhAk2aopiB3sIbf7m0AW1VTCv/ J3I5Ki/1R5ARAAAAAAAA --------------ms070707060700010405090101-- From nobody Thu Nov 19 02:52: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 BF6611B31E6 for ; Thu, 19 Nov 2015 02:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, 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 KUYgGX_akaTQ for ; Thu, 19 Nov 2015 02:50:50 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC4A21B31E4 for ; Thu, 19 Nov 2015 02:50:49 -0800 (PST) Received: by wmvv187 with SMTP id v187so19021220wmv.1 for ; Thu, 19 Nov 2015 02:50:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=39GEUfWUe4CEwzOl+S7+9iaKP2/CiKoOjxdan7vcqr0=; b=TYNdPpHXwCCdcLf1tbgZrxCvYlmAQ1NaNODjt0HY/rGOHFyRBianJxFx3Eu0fTQW4u PvzuWrYPTp30GkinCa63cqsgT+EC5ZmfCCa4NOKlOnPo8Fb0oA0Ona9VVcXXqW1xd3ZH Zi1qu2JVv36g9tPHH93bUDjGamR79mbSkIgvZwgQl6pCNaNhTo/NPfUx/2MptRsm1orN ++49pHFIXous38RYamjNH8n6pc4uTdypUOQAD0nf6jgT+Kfl+ancgAS1cVBW1Qyrzt3S 6OcrRvU74VTmsk/Olbx8D6bH9uGRV/NUOBckqFHwSmjRnUMtKvhuWv944S1TiuPailEJ 7O4A== X-Received: by 10.194.222.137 with SMTP id qm9mr7522759wjc.30.1447930248105; Thu, 19 Nov 2015 02:50:48 -0800 (PST) Received: from [10.7.3.143] ([217.138.7.34]) by smtp.googlemail.com with ESMTPSA id 186sm7738421wmv.9.2015.11.19.02.50.46 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Nov 2015 02:50:46 -0800 (PST) To: =?UTF-8?Q?Erik_Wahlstr=c3=b6m_neXus?= , Stefanie Gerdes References: <564AEE51.30407@tzi.de> <56666935-C2EE-495B-9D32-639D887870AD@nexusgroup.com> <0F619216-DE67-4640-90AD-3D0CAC4F80B0@nexusgroup.com> <564D9E8F.805@tzi.de> <291CFA30-065D-4334-90DE-671AC9AE8146@nexusgroup.com> From: Paul Madsen Message-ID: <564DA984.8060205@gmail.com> Date: Thu, 19 Nov 2015 05:50:44 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <291CFA30-065D-4334-90DE-671AC9AE8146@nexusgroup.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Anthony Nadalin , Kathleen Moriarty , Kepeng Li , "Ace@ietf.org" , Hannes Tschofenig , Stephen Farrell Subject: Re: [Ace] Solution direction X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Nov 2015 10:50:52 -0000 Enterprises know & understand OAuth and many have already invested in it to protect their HTTP APIs A security model for constrained devices that builds on this established collective knowledge & experience with OAuth (and the other specs that have been defined on it like Connect & UMA) is a much easier proposition for these enterprises as they roll-out IoT paul On 11/19/15 5:19 AM, Erik Wahlström neXus wrote: > Hi Steffi, > > Yes, I realise that DCAF can be profiled and used to non-constrained devices just as OAuth can be profiled for constrained devices. For me, it’s more of a question of where momentum is and taking that further to target the continuum of both non-constrained and constrained devices (i.e. take OAuth to constrained devices). > > / Erik > > >> On 19 Nov 2015, at 11:03, Stefanie Gerdes wrote: >> >> Hi Erik, >> >> Fortunately, DCAF works with constrained AND less-constrained devices, >> so we will not have "parallel worlds" if we use it. >> >> Steffi >> >> On 11/18/2015 08:08 PM, Erik Wahlström neXus wrote: >>> If the constrained world and the non-constrained world would exists in two different parallell worlds that would make sense. But it’s not. It’s a continuum where both big and small devices will talk to each other. I will have a phone that talks standard oauth2 flows to get a token from an authorization server and it’s later used against a constrained device using coap and vice versa. >>> >>> I would be fine if we only could get by with a JWT, but I don’t think so. Please prove me wrong :) >>> >>> / Erik >>> >>> >>> On 18 Nov 2015, at 19:57, Anthony Nadalin > wrote: >>> >>> Makes more sense to have a solution that uses Oauth and JSON/JOSE and a DCAF solution that uses CBOR/COSE instead of mixing all the combinations as that will be a nightmare >>> >>> From: Erik Wahlström neXus [mailto:erik.wahlstrom@nexusgroup.com] >>> Sent: Wednesday, November 18, 2015 10:31 AM >>> To: Anthony Nadalin > >>> Cc: Stefanie Gerdes >; Hannes Tschofenig >; Stephen Farrell >; Kathleen Moriarty >; Kepeng Li >; Ace@ietf.org >>> Subject: Re: [Ace] Solution direction >>> >>> Yes. Json will still be a key format. And it will be heavenly used, especially for class 2 devices. In our tests we did see that JWT got us a very long way. Especially if we just have to send token once (according to the draft). >>> >>> Then we have the super constrained class 1 devices. They need something more compact. >>> >>> Sent from my iPhone >>> >>> On 18 Nov 2015, at 19:17, Anthony Nadalin > wrote: >>> Its more than that as we have to deal with JSON and CBOR, so far OAUTH only deals with JSON in the various profiles/extensions >>> >>> From: Erik Wahlström neXus [mailto:erik.wahlstrom@nexusgroup.com] >>> Sent: Wednesday, November 18, 2015 10:14 AM >>> To: Anthony Nadalin > >>> Cc: Stefanie Gerdes >; Hannes Tschofenig >; Stephen Farrell >; Kathleen Moriarty >; Kepeng Li >;Ace@ietf.org >>> Subject: Re: [Ace] Solution direction >>> >>> Don't think so. If it's a JWT/JOSE or a CWT/COSE does not mean the world. It's just a token format (both will exist). A client don't really have to care what type of token it is. It's just a access token. >>> >>> Then we have the framework on how access tokens are retrieved and sent to establish a context. That's another thing. >>> >>> / Erik >>> >>> Sent from my iPhone >>> >>> On 18 Nov 2015, at 18:39, Anthony Nadalin > wrote: >>> Don’t or won’t we already have that confusion with COSE and JOSE (much like confusion with DCAF and OAUTH) ? >>> >>> From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Erik Wahlström neXus >>> Sent: Wednesday, November 18, 2015 2:58 AM >>> To: Stefanie Gerdes > >>> Cc: Hannes Tschofenig >; Stephen Farrell >; Kathleen Moriarty >; Kepeng Li >; Ace@ietf.org >>> Subject: Re: [Ace] Solution direction >>> >>> Hi, >>> >>> Dynamic client registration (RFC7591) and User-Managed Access (UMA) Profile of OAuth 2.0 (https://docs.kantarainitiative.org/uma/rec-uma-core.html) solves those scenarios. >>> >>> To make them work with constrained clients and servers, both RFC7591 and UMA must to be profiled in the same way as the OAuth for IoT draft did for core oauth. >>> >>> Both dynamic client registration and UMA where added later on after Oauth2 (RFC6749) was completed. I think that’s a sound model that we should follow. Get the core concepts down, then extend them when needed and when we do that we should re-use the concepts already there. >>> >>> Having two different proposals, both DCAF and OAuth for IoT, running at the same time confuses implementors. I don’t think we want to do that. >>> >>> / Erik >>> >>> >>> >>> On 17 Nov 2015, at 10:07, Stefanie Gerdes > wrote: >>> >>> Hi all, >>> >>> I think we should continue working on DCAF in ACE. It provides valuable >>> concepts and mechanisms which is why many solutions in ACE draw heavily >>> from DCAF. >>> >>> I think one aspect did not really become clear during the ACE session in >>> Yokohama: A solution with only one supporting less constrained device >>> will not be able to fully support communication between constrained >>> nodes as DCAF does. One main question that is only partly solved by >>> other solutions is: How can a constrained client authenticate the other >>> party? >>> >>> A constrained device is not able to establish security associations as >>> easily as a less constrained device. The keying material that is used >>> for authorization and secure communication must securely be obtained. It >>> can either be provisioned manually to the constrained device or a >>> security association with a less constrained device is required that can >>> then provide the keying material. >>> >>> An Authorization Server can provide session keys to the constrained >>> devices, but the constrained device must have a security association >>> with the AS to authenticate the origin of the session key. In a scenario >>> where we have only a single AS and two constrained nodes, both need a >>> security association with that AS. For cross-domain scenarios this might >>> be difficult. We will need to manually provision the keying material to >>> one of the devices which makes the dynamic setup of secure communication >>> impossible. That's why we need two less-constrained devices in this >>> scenario. >>> >>> You may think that this has nothing to do with authorization and >>> therefore is not a topic for ACE. Well, it has, but another >>> terminology-discussion might not be that useful. However, the important >>> thing is that developing an additional solution to solve this problem >>> will very likely add more overhead. The result will be more complex and >>> more difficult to implement. Until such a solution is developed we will >>> need to use complex workarounds (e.g. manual provisioning), may have >>> security problems or are not able to address certain scenarios at all. >>> >>> But we have never done this before, why now? Because other than the >>> general purpose computers that we are using today, constrained devices >>> will communicate autonomously without the help of their user. They often >>> will not even have user interfaces. Until now this was true for servers >>> which is why existing protocols protect them. In a true Internet of >>> Things this will also be true for clients. We therefore need to >>> reconsider how clients can be protected and how their actions can be >>> controlled by their owners. >>> >>> DCAF supports scenarios with a single less-constrained device (AS) as >>> well as scenarios where both the Client and the Server have their own. >>> It works with OAuth and may even transport OAuth tickets if that is >>> necessary. It has a built-in key distribution mechanism and therefore is >>> very efficient. The main fault of DCAF seems to be that we didn't call >>> it OAuth. >>> >>> I think DCAF should be one of the building blocks (one of the tools in >>> our toolbox) that ACE is working on. >>> >>> Best regards, >>> Steffi >>> >>> _______________________________________________ >>> 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 From nobody Thu Nov 19 04:50:17 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C121ACED2 for ; Thu, 19 Nov 2015 04:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trYn1VF605dD for ; Thu, 19 Nov 2015 04:50:07 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0707.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::707]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C3A11ACED0 for ; Thu, 19 Nov 2015 04:50:06 -0800 (PST) Received: from DB4PR06CA0006.eurprd06.prod.outlook.com (10.162.49.16) by AMSPR06MB152.eurprd06.prod.outlook.com (10.242.91.27) with Microsoft SMTP Server (TLS) id 15.1.331.20; Thu, 19 Nov 2015 12:50:00 +0000 Received: from DB3FFO11FD022.protection.gbl (2a01:111:f400:7e04::134) by DB4PR06CA0006.outlook.office365.com (2a01:111:e400:9866::16) with Microsoft SMTP Server (TLS) id 15.1.331.20 via Frontend Transport; Thu, 19 Nov 2015 12:50:00 +0000 Authentication-Results: spf=pass (sender IP is 146.108.200.10) smtp.mailfrom=tridonic.com; sics.se; dkim=none (message not signed) header.d=none;sics.se; dmarc=bestguesspass action=none header.from=tridonic.com; Received-SPF: Pass (protection.outlook.com: domain of tridonic.com designates 146.108.200.10 as permitted sender) receiver=protection.outlook.com; client-ip=146.108.200.10; helo=ATDOAGMSX01.itiso.net; Received: from ATDOAGMSX01.itiso.net (146.108.200.10) by DB3FFO11FD022.mail.protection.outlook.com (10.47.217.53) with Microsoft SMTP Server (TLS) id 15.1.325.5 via Frontend Transport; Thu, 19 Nov 2015 12:49:59 +0000 Received: from ATBRAGMSX02.itiso.net ([169.254.2.220]) by ATDOAGMSX01.itiso.net ([146.108.41.67]) with mapi id 14.03.0248.002; Thu, 19 Nov 2015 13:49:58 +0100 From: Somaraju Abhinav To: Ludwig Seitz , "ace@ietf.org" Thread-Topic: [Ace] [ACE] Permanant client-server relations and draft-seitz-ace-oauth-authz-00 Thread-Index: AdEhN5xFUnXCzFUVReqBc2YQQmmyoAAmSPSAADXl4YAAATQBAAAGXD/B Date: Thu, 19 Nov 2015 12:49:58 +0000 Message-ID: <0E9A48AB39AF3547ACD28A6DE3E2906A0F1ACF8E@ATBRAGMSX02.itiso.net> References: <0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC07D@ATBRAGMSX02.itiso.net> <564C335F.4050404@gmx.net> <564D9D13.5080308@gmx.net>,<564DA526.7010604@sics.se> In-Reply-To: <564DA526.7010604@sics.se> Accept-Language: en-US, de-AT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.108.8.124] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD022; 1:WEDlboWpgZ85NQW7QGCMcYQBfFHrOFEWPrFQKHWmZnpjSkFCM7UP2xWeC7/1AJuyC2jO1EgmAEIdq3jUdpXhsoir4SJNiN55BXKa86khN2BWuWLoYaQNDUYOLTT0L+WmHPM8KPeyUsGvBvf76kAFz3dpjvUimXOvMo4POXsxdnBQWvMUKssP+3arljx4bPBb5yFunRqWhb+0FIiCwJDXNbmW3qEu+DdfPNpSnRW6ZPzrNmHSof1Lr4OcOknarAwA3F0taOqeaFyZxZYST9K7kFSNfdgc+OL4lqGn0hR8yuy/Ax/NaWkcJLEk0K/HjuFTOJq+cZsHkZshWmmhFtp2UQE7V+vs2R9wgdM0pRylyXBi9r+E094bZ1zMcp26lTXPo7CtT1CYNeOwKgDGGOGImA== X-Forefront-Antispam-Report: CIP:146.108.200.10; CTRY:AT; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(199003)(377454003)(377424004)(24454002)(189002)(50986999)(81156007)(66066001)(55846006)(4001150100001)(5001770100001)(2920100001)(5001960100002)(2950100001)(107886002)(53416004)(93886004)(11100500001)(2900100001)(561944003)(47776003)(230783001)(19580405001)(19580395003)(69596002)(3846002)(102836003)(189998001)(15975445007)(6116002)(54356999)(23746002)(5008740100001)(86362001)(5003600100002)(33656002)(92566002)(5004730100002)(26826002)(16601075003)(5890100001)(6806005)(76176999)(106466001)(5007970100001)(50466002)(87936001)(586003)(2501003)(104016004); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR06MB152; H:ATDOAGMSX01.itiso.net; FPR:; SPF:Pass; PTR:unknown.zgrp.net; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AMSPR06MB152; 2:4pQdrvdKBSRFrNyqnZgbd9edl4kaZIOEPIdvp482Pdi7/4j5hVqWX426cKoVlRx7gx8jfr+gI/JAP0tv2wXJ9xjo8QJ8QDg8z50R812w9/DSydK6W5r80qKUnLIVntp/02gOq+lFfwgsXQiWY+fIVw==; 3:DwDGi7sD/uG/AUxPwxiSuUd5UHJa6OIKWNbTqvGnwfanvDFpK0U5lyK5S4bfDgAcCx1hoAsFdvZtWWoAZFm60oSzIDmz0hJM+IZPT159uRC25G0gSTmOGvQRTs40YQ4ZihykMANa5HGQ8VkMyXNmrYlwkXqRmeqQXSXnHX0fhC41O2zHbxlJUI2kE0tCaUlOYlH2yMJ/Ls38pV8rRd9EZUuhxUqeUb+PFQDys/eG4Z2bNxqCLDSxveAwDEF17eE2JU6qr1CBJdqh23BBK2jaCg==; 25:N9GQO0P0fwf/8zaf7Tz18Ooz0TIUSG999kIN9E4TUv4RCd8wBazIeqH0yhgbDzaAOF4BI5eLGSZQZSsxCzxU8MsGdHe93ANHeaWZjfKfohYBqHK8DNDlH/LzEE9cSQjma4UocwaHX6dIK76GSyiPZ9g7B4N2IlJhOBoO9Mv6YFMhucl6KNWpMFhZis6a6ir+ZSE5CTu8lJeOGFnqBtBQ2brOyUw2sNISaTfGBl6+LHbY0/eC80PTN5zhvGqI5vOly2yEGMwMEcxADCt+Ob1ZEA== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501001); SRVR:AMSPR06MB152; X-Microsoft-Exchange-Diagnostics: 1; AMSPR06MB152; 20:/S0g7IURMEyr34nQ0u+EtgezYhwY5e6cqgHy5vfMQH7pz5g+LF/qbJR5W7zn7mkKcMTvB+NH0Gkxkb9F8ex+E+Y5+HQEeWfKGzqmPdBdLs9QnO2IUPU68lCgpgqBQShduYZ6/Tl8iyJog5unX43MrAxxJHocxKoP7zE6C3upGxTlc8oH5TacDiai7BN9JA85QdZkh5BOrTqqwyUsy7EO0vN5/D3Dzy8wfnYjhJsftDvwYCtYcfklbtvyWiSoYeAIVJ17u2nLLwqiy/67geeu4VvZSauvIrwk5/LyghjmM+ldQ59KhNiXV567+8O9lNSWmYHi/aKibvGA+bF8W+BABpwH1vR/IZyp+5zS9TvpdVqke48rDLJeB/Xu2ipKi41ah4OPRNW9qcrieKMLarWEndzuzSxuZ0dfrrTsP1gUs5lDxSvEG/0ururMHCE9d6KX3MEkLuhM0xXK6F81hLCT9FxWEMLVkiOBQAJSK8bnWWJYWjURXGjmicWYGMXqUAVx; 4:s4Sp9M63njuI+HgsowcY3v0GqaKsElZfXzpk6nG4ZqZNXuUr3ddyVV9Rd3CcEWuIFKq2ExtHY4mUAVMMUcIhtWFhNfGy0CLJ6itq4ewNGyj9v/rORKG3EQuAQ9zfd1JGeAmL+eQdZYCVKe7UbMb5+KZl+pX1U0rQlyMtHhN6fLCR/dwTI3KP2Hk5SQAS4/sTB+P1S9NC91lhqiR33B7G5wiTuFIdzMAvcvqt4A/X5wl15EFf906pcarjfwUOa3gkdzdnbuM7iqgioqdnNW/Oeg7xvEJTsDxnPjXDQcA1OKy3g/WvkNBBY5cK/HNxiZrXJmpnP0ERoEXeMzbyIJalHAHq1aTZoeoRK9JqlwoILN9nwIIfeKV6r5kp7/b+7tap X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:AMSPR06MB152; BCL:0; PCL:0; RULEID:; SRVR:AMSPR06MB152; X-Forefront-PRVS: 07658B8EA3 X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; AMSPR06MB152; 23:aWX+4fReDCPMAuLhb004A3+6pJlC78PJoZEcej?= =?Windows-1252?Q?b8WCjS52EXPqOrWmKSu4pEKYbthIONtJF/OVVjSvv2Q3NhdDx5Ln9Grd?= =?Windows-1252?Q?o6WLq6GEwBdvzZY45X/9Kyff0Z9sL5htuRJ/pZ5g4imqEoneK6/U1MQv?= =?Windows-1252?Q?GrkDNPLWxVGjG1pcqmP+ypcyzha6U5aBIcP+5BNRWm2ugl+Bi+X1Ci1z?= =?Windows-1252?Q?EE3n8bu5at2CSZYrmZdM5f8S2z7zQm5DLChWvLuzwoDh4laQlcvaYVEG?= =?Windows-1252?Q?4OSerBT0tBhz07oQaOoR2RUmq+c5SeV3HUX0HXigEmeTiM+BiiJ0H5IF?= =?Windows-1252?Q?iXhmBUXzmHhzvU45MlIcQdv43Cprqm08igmjeJIPX3ND/bt8FOblDdQD?= =?Windows-1252?Q?g/JkKhNvCTlcWowqOonizOYVQd8ebhvWrzRCWbfXHHNL3f4+Nxbf96dC?= =?Windows-1252?Q?3sw+45h9iDB0XiV/PcSWfyMiv+w1TrX4DXuTXnbTHTNYgDnK38cp6vpd?= =?Windows-1252?Q?GWP3N/ve5s8b3WHN4yQkAHQHBK0XJNpKqBBvgsboK//DYz0lh562SREB?= =?Windows-1252?Q?xLbbuJTzWmheziyMykzu9nt3xVcqhsZMP9j8arpHROUx9jvQwd5Ci9+b?= =?Windows-1252?Q?m5O0BIjZxqNgaMnXXi7VqpZ84RLKuWrsnH+fdSoTy+Fb253GJE2ptyoB?= =?Windows-1252?Q?FLhXiFe70rVjsfmmpmoGf8on1xKv/X3RutGuLmPP1Pf0nTsnsq3qwvGu?= =?Windows-1252?Q?S6yfXYXLSDR+q0JO4dIb1wCg0YwQUn9tz3Vu/fRyO93a5lsW6DufRdLP?= =?Windows-1252?Q?92TeateJZeXKcKlKsL+pU1Fwe8kFHvv9NHW5LShO7/vA/GSwP+vguK3U?= =?Windows-1252?Q?U7L3rPFqynkcQLmnj4l2Nl1dlEN1EzxdhiJlhQOz8SSbyMEUQFBlgR4Z?= =?Windows-1252?Q?Gvq9yNnsPX4579JMFMK6h1LK/8PJmWk6K/tMh+12DK1gAqEjNfEXVZkJ?= =?Windows-1252?Q?CrVGgRPiO8bQltoxJ03L86a12RUTzqVQHJTqUSc4IGiTuEmivTIgXyUV?= =?Windows-1252?Q?8/VjFrWXk3nAH1LD1nkxDZ8N3xt/s5lC5nEfM1CD02AvgQ35F7fUgP0g?= =?Windows-1252?Q?O9A/Lz54NbSHAduClpmDW40ntdwlx5KHqtkfx/AYOV94K0slO8gsGM5d?= =?Windows-1252?Q?VNBgvDNFea7lRvyJwFIeyHNYjfNCnS4TbNdYrvB5yTJPCuKS5YRTbfP4?= =?Windows-1252?Q?GY/29YyN3g5HQGR7kL/50ovfz5gkTCYHkDb36del12j0laoAL1qNLShO?= =?Windows-1252?Q?v6r4VziutWgu8lQ0WRua136NlLJtoUoZFTUyQi/I9yVRzNAkTN5YSZV5?= =?Windows-1252?Q?gw3H444fOwQU4cNjXWwHLGAgQiRCi714KHkdYQyh5fOQB3A6OLso489b?= =?Windows-1252?Q?HIxE/+xWMj9JSuw2tW76GVgTTIy44ZyCPJL5MQsaVXaGKIJ6HKkkNlHs?= =?Windows-1252?Q?pTwZBaVGBfAMZmZFWyojeFp2ap?= X-Microsoft-Exchange-Diagnostics: 1; AMSPR06MB152; 5:ifrlt5N6vyKl6Ybv3oEJ2teEP9NWs2bTEkzjyTAekcVIQj0zcRx5hdSVnMfCv+rK7bCTKWTe4ezipgLleReG6uFzzgqQEuvCae8jJ1eNci/bLcZlM4iT83r71L0KtgMvi34g3QLkmWXyStzwtwZU1Q==; 24:HIYDi1RuyoCiU/vACLMw8We6R7yN8mYpK6AXPUXCGYMdqZ61DUsvhdKkVyWIuIY1t40tQDbTZAD323IzyzC+zCcWbQBgOdsD0vDa52b0BAo= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: tridonic.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Nov 2015 12:49:59.7879 (UTC) X-MS-Exchange-CrossTenant-Id: 8b206608-a593-4ace-a4b6-ef1fc83c9169 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8b206608-a593-4ace-a4b6-ef1fc83c9169; Ip=[146.108.200.10]; Helo=[ATDOAGMSX01.itiso.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR06MB152 Archived-At: Subject: Re: [Ace] [ACE] Permanant client-server relations and draft-seitz-ace-oauth-authz-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 12:50:15 -0000 Hi Hannes, G=F6ran, I will try to summaries your replies and please correct me if I am wrong.: "The constrained client to constrained server case is conceptually simpler = than the other cases since the authorization step, as you noted, already ha= ppened out-of-band (by someone)" and =93permanent client-server relations = may be viewed as a special case of the dynamic access rights." I agree with this assessment. However, for a lot of constrained devices, th= e only use case that is important is permanent client-server relations. So,= considering the proposal to use OAuth draft as the starting point for the = ACE solutions, the questions for me are: 1) Can we judge how many use cases we have for permanent client-server rela= tions vs temporary (dynamic) client server relationships. From how I see it= , the permanent ones are a lot more used in practice for constrained device= s. 2) Do we want to mandate- Option1: the use of full OAuth (constrained profile) for every device or Option2: will we have a method to say that a constrained server or client i= s only going to support permanent links and not the full OAuth constrained = profile. 3) If we choose Option 1 in Step 2, can we get an estimate of how much over= head it is compared to Option 1. The LWM2M comparison is relevant here whic= h is more or less option 2 with Option 1 still possible but managed via a s= ingle central server. Abhinav ________________________________________ From: Ace [ace-bounces@ietf.org] on behalf of Ludwig Seitz [ludwig@sics.se] Sent: Thursday, November 19, 2015 11:32 AM To: ace@ietf.org Subject: Re: [Ace] [ACE] Permanant client-server relations and draft-seitz-= ace-oauth-authz-00 On 2015-11-19 10:57, Hannes Tschofenig wrote: > As an add-on to my email from yesterday I thought it might be also > useful to look at the LWM2M protocol and to see whether it helps in > those scenarios. I was thinking about doing a tutorial about LWM2M to > the group for a little while already and maybe I should give it a try in > December. > > Ciao > Hannes > I think a LWM2M tutorial would be very helpful. Please do give it a try. /Ludwig -- 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 ________________________________________________________ The contents of th= is e-mail and any attachments are confidential to the intended recipient. T= hey may not be disclosed to or used by or copied in any way by anyone other= than the intended recipient. If this e-mail is received in error, please i= mmediately notify the sender and delete the e-mail and attached documents. = Please note that neither the sender nor the sender's company accept any res= ponsibility for viruses and it is your responsibility to scan or otherwise = check this e-mail and any attachments. From nobody Thu Nov 19 04:55: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 F0A151ACEE0 for ; Thu, 19 Nov 2015 04:55:51 -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 6Lu1v8lpGvr0 for ; Thu, 19 Nov 2015 04:55:49 -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 840821ACEE3 for ; Thu, 19 Nov 2015 04:55:35 -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 tAJCtJv6019037; Thu, 19 Nov 2015 13:55:20 +0100 (CET) Received: from [IPv6:2001:638:708:30da:4498:9a37:725d:af60] (unknown [IPv6:2001:638:708:30da:4498:9a37:725d:af60]) (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 3p1gw76dphz2PZc; Thu, 19 Nov 2015 13:55:19 +0100 (CET) To: =?UTF-8?Q?Erik_Wahlstr=c3=b6m_neXus?= References: <564AEE51.30407@tzi.de> <56666935-C2EE-495B-9D32-639D887870AD@nexusgroup.com> <0F619216-DE67-4640-90AD-3D0CAC4F80B0@nexusgroup.com> <564D9E8F.805@tzi.de> <291CFA30-065D-4334-90DE-671AC9AE8146@nexusgroup.com> From: Stefanie Gerdes X-Enigmail-Draft-Status: N1110 Message-ID: <564DC6B7.4010408@tzi.de> Date: Thu, 19 Nov 2015 13:55:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <291CFA30-065D-4334-90DE-671AC9AE8146@nexusgroup.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: Anthony Nadalin , Kathleen Moriarty , Kepeng Li , "Ace@ietf.org" , Hannes Tschofenig , Stephen Farrell Subject: Re: [Ace] Solution direction X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Nov 2015 12:55:52 -0000 Hi Erik, DCAF as it is already supports less-constrained devices. It also works together with OAuth as we showed in an example in draft-gerdes-ace-dcaf-examples [1]. If we want to, we can also transport OAuth tickets in DCAF. We should find out which is more useful for which use case (we may find out that there is more than one answer to that). The discussion always seems to be whether we are doing something for the constrained devices or if we are supporting OAuth. I think we should do both. I don't think it is that important whether we name the result DCAF, OAuth or UMA in the end as long as it does the right thing. Best regards, Steffi [1] https://tools.ietf.org/html/draft-gerdes-ace-dcaf-examples-00 On 11/19/2015 11:19 AM, Erik Wahlström neXus wrote: > Hi Steffi, > > Yes, I realise that DCAF can be profiled and used to non-constrained devices just as OAuth can be profiled for constrained devices. For me, it’s more of a question of where momentum is and taking that further to target the continuum of both non-constrained and constrained devices (i.e. take OAuth to constrained devices). > > / Erik > > >> On 19 Nov 2015, at 11:03, Stefanie Gerdes wrote: >> >> Hi Erik, >> >> Fortunately, DCAF works with constrained AND less-constrained devices, >> so we will not have "parallel worlds" if we use it. >> >> Steffi >> >> On 11/18/2015 08:08 PM, Erik Wahlström neXus wrote: >>> If the constrained world and the non-constrained world would exists in two different parallell worlds that would make sense. But it’s not. It’s a continuum where both big and small devices will talk to each other. I will have a phone that talks standard oauth2 flows to get a token from an authorization server and it’s later used against a constrained device using coap and vice versa. >>> >>> I would be fine if we only could get by with a JWT, but I don’t think so. Please prove me wrong :) >>> >>> / Erik >>> >>> >>> On 18 Nov 2015, at 19:57, Anthony Nadalin > wrote: >>> >>> Makes more sense to have a solution that uses Oauth and JSON/JOSE and a DCAF solution that uses CBOR/COSE instead of mixing all the combinations as that will be a nightmare >>> >>> From: Erik Wahlström neXus [mailto:erik.wahlstrom@nexusgroup.com] >>> Sent: Wednesday, November 18, 2015 10:31 AM >>> To: Anthony Nadalin > >>> Cc: Stefanie Gerdes >; Hannes Tschofenig >; Stephen Farrell >; Kathleen Moriarty >; Kepeng Li >; Ace@ietf.org >>> Subject: Re: [Ace] Solution direction >>> >>> Yes. Json will still be a key format. And it will be heavenly used, especially for class 2 devices. In our tests we did see that JWT got us a very long way. Especially if we just have to send token once (according to the draft). >>> >>> Then we have the super constrained class 1 devices. They need something more compact. >>> >>> Sent from my iPhone >>> >>> On 18 Nov 2015, at 19:17, Anthony Nadalin > wrote: >>> Its more than that as we have to deal with JSON and CBOR, so far OAUTH only deals with JSON in the various profiles/extensions >>> >>> From: Erik Wahlström neXus [mailto:erik.wahlstrom@nexusgroup.com] >>> Sent: Wednesday, November 18, 2015 10:14 AM >>> To: Anthony Nadalin > >>> Cc: Stefanie Gerdes >; Hannes Tschofenig >; Stephen Farrell >; Kathleen Moriarty >; Kepeng Li >;Ace@ietf.org >>> Subject: Re: [Ace] Solution direction >>> >>> Don't think so. If it's a JWT/JOSE or a CWT/COSE does not mean the world. It's just a token format (both will exist). A client don't really have to care what type of token it is. It's just a access token. >>> >>> Then we have the framework on how access tokens are retrieved and sent to establish a context. That's another thing. >>> >>> / Erik >>> >>> Sent from my iPhone >>> >>> On 18 Nov 2015, at 18:39, Anthony Nadalin > wrote: >>> Don’t or won’t we already have that confusion with COSE and JOSE (much like confusion with DCAF and OAUTH) ? >>> >>> From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Erik Wahlström neXus >>> Sent: Wednesday, November 18, 2015 2:58 AM >>> To: Stefanie Gerdes > >>> Cc: Hannes Tschofenig >; Stephen Farrell >; Kathleen Moriarty >; Kepeng Li >; Ace@ietf.org >>> Subject: Re: [Ace] Solution direction >>> >>> Hi, >>> >>> Dynamic client registration (RFC7591) and User-Managed Access (UMA) Profile of OAuth 2.0 (https://docs.kantarainitiative.org/uma/rec-uma-core.html) solves those scenarios. >>> >>> To make them work with constrained clients and servers, both RFC7591 and UMA must to be profiled in the same way as the OAuth for IoT draft did for core oauth. >>> >>> Both dynamic client registration and UMA where added later on after Oauth2 (RFC6749) was completed. I think that’s a sound model that we should follow. Get the core concepts down, then extend them when needed and when we do that we should re-use the concepts already there. >>> >>> Having two different proposals, both DCAF and OAuth for IoT, running at the same time confuses implementors. I don’t think we want to do that. >>> >>> / Erik >>> >>> >>> >>> On 17 Nov 2015, at 10:07, Stefanie Gerdes > wrote: >>> >>> Hi all, >>> >>> I think we should continue working on DCAF in ACE. It provides valuable >>> concepts and mechanisms which is why many solutions in ACE draw heavily >>> from DCAF. >>> >>> I think one aspect did not really become clear during the ACE session in >>> Yokohama: A solution with only one supporting less constrained device >>> will not be able to fully support communication between constrained >>> nodes as DCAF does. One main question that is only partly solved by >>> other solutions is: How can a constrained client authenticate the other >>> party? >>> >>> A constrained device is not able to establish security associations as >>> easily as a less constrained device. The keying material that is used >>> for authorization and secure communication must securely be obtained. It >>> can either be provisioned manually to the constrained device or a >>> security association with a less constrained device is required that can >>> then provide the keying material. >>> >>> An Authorization Server can provide session keys to the constrained >>> devices, but the constrained device must have a security association >>> with the AS to authenticate the origin of the session key. In a scenario >>> where we have only a single AS and two constrained nodes, both need a >>> security association with that AS. For cross-domain scenarios this might >>> be difficult. We will need to manually provision the keying material to >>> one of the devices which makes the dynamic setup of secure communication >>> impossible. That's why we need two less-constrained devices in this >>> scenario. >>> >>> You may think that this has nothing to do with authorization and >>> therefore is not a topic for ACE. Well, it has, but another >>> terminology-discussion might not be that useful. However, the important >>> thing is that developing an additional solution to solve this problem >>> will very likely add more overhead. The result will be more complex and >>> more difficult to implement. Until such a solution is developed we will >>> need to use complex workarounds (e.g. manual provisioning), may have >>> security problems or are not able to address certain scenarios at all. >>> >>> But we have never done this before, why now? Because other than the >>> general purpose computers that we are using today, constrained devices >>> will communicate autonomously without the help of their user. They often >>> will not even have user interfaces. Until now this was true for servers >>> which is why existing protocols protect them. In a true Internet of >>> Things this will also be true for clients. We therefore need to >>> reconsider how clients can be protected and how their actions can be >>> controlled by their owners. >>> >>> DCAF supports scenarios with a single less-constrained device (AS) as >>> well as scenarios where both the Client and the Server have their own. >>> It works with OAuth and may even transport OAuth tickets if that is >>> necessary. It has a built-in key distribution mechanism and therefore is >>> very efficient. The main fault of DCAF seems to be that we didn't call >>> it OAuth. >>> >>> I think DCAF should be one of the building blocks (one of the tools in >>> our toolbox) that ACE is working on. >>> >>> Best regards, >>> Steffi >>> >>> _______________________________________________ >>> 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 > > > -- 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 Nov 19 05:03: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 DCAF41AD06D for ; Thu, 19 Nov 2015 05:03:47 -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 Q9CTdvW1xx1h for ; Thu, 19 Nov 2015 05:03: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 EB36F1AD070 for ; Thu, 19 Nov 2015 05:03: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 [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id tAJD3flG010352; Thu, 19 Nov 2015 14:03:41 +0100 (CET) Received: from [IPv6:2001:638:708:30da:4498:9a37:725d:af60] (unknown [IPv6:2001:638:708:30da:4498:9a37:725d:af60]) (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 3p1h5n43Rgz2QF3; Thu, 19 Nov 2015 14:03:41 +0100 (CET) To: =?UTF-8?Q?G=c3=b6ran_Selander?= , Renzo Navas References: <564AEE51.30407@tzi.de> <87d1v7r88r.fsf@aung.informatik.uni-bremen.de> From: Stefanie Gerdes Message-ID: <564DC8AD.3090804@tzi.de> Date: Thu, 19 Nov 2015 14:03:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Solution direction X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Nov 2015 13:03:48 -0000 Hi Göran, On 11/19/2015 09:07 AM, Göran Selander wrote: > Hi Renzo, > > On 2015-11-18 11:14, "Renzo Navas" wrote: > >> and why not start merging it with the >> OAuth-based solution on the points that OAuth is missing. > > I don’t think a merge is a good idea, at least not in the sense of the > actors draft which is a result of the different views represented by some > of the authors behind the OAuth profile draft and some of the authors > behind DCAF. The two latest reviews were not very positive. > I don't think we should be to pessimistic. The use cases document was hard work but turned out to be especially useful in the end. I think that is a remarkable success. Best regards Steffi From nobody Thu Nov 19 05:37: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 5B0791AD368 for ; Thu, 19 Nov 2015 05:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6HkBYWNaQbf for ; Thu, 19 Nov 2015 05:36:51 -0800 (PST) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD4FC1AD36A for ; Thu, 19 Nov 2015 05:36:48 -0800 (PST) Received: by vkgy188 with SMTP id y188so16471953vkg.3 for ; Thu, 19 Nov 2015 05:36:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EwKEn4oLb+ikJgDN+3Mivxvlj+6j2dV3J8P8AdEYlbY=; b=LxG2WYHc3l1eu8EoqCalkznsIKO5b2DyvmoFivBBtDItNn6ffiwniDtTHIgim9+7mr jXjvHe9lWrPIEwqSbN6jTXxIobWcIRlWdmJX6XmimJYL8K74/8E2Wy2yR4Xwp0dNIVoc 5fOWzQqQJO5+bB371oMMdiKV9BsXj4GHnYpy/hZezZ3mTohzs/dBcuWfNEgL3xQw1/6W spbFXJQH/drO6Bv2D5Xz3IkmNMr0juMxl3+kkZM8UGzr4tPaw9BQXjMPSaDT+jfHZtPH UV41DmixQG8I/b4ihH5f9GVgfjDKXBe+d3Q5BGBPoAAmmupnhKKo8G/NhvzYuGz4OLcR HCLA== X-Received: by 10.31.31.216 with SMTP id f207mr4674732vkf.109.1447940207831; Thu, 19 Nov 2015 05:36:47 -0800 (PST) Received: from [172.20.3.0] ([65.200.157.66]) by smtp.gmail.com with ESMTPSA id w130sm3810406vke.10.2015.11.19.05.36.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Nov 2015 05:36:46 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (12H143) In-Reply-To: <564D9E8F.805@tzi.de> Date: Thu, 19 Nov 2015 08:36:45 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <564AEE51.30407@tzi.de> <56666935-C2EE-495B-9D32-639D887870AD@nexusgroup.com> <0F619216-DE67-4640-90AD-3D0CAC4F80B0@nexusgroup.com> <564D9E8F.805@tzi.de> To: Stefanie Gerdes Archived-At: Cc: Anthony Nadalin , Kepeng Li , "Ace@ietf.org" , Hannes Tschofenig , =?utf-8?Q?Erik_Wahlstr=C3=B6m_neXus?= , Stephen Farrell Subject: Re: [Ace] Solution direction X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Nov 2015 13:37:00 -0000 Hi, Sent from my iPhone > On Nov 19, 2015, at 5:03 AM, Stefanie Gerdes wrote: >=20 > Hi Erik, >=20 > Fortunately, DCAF works with constrained AND less-constrained devices, > so we will not have "parallel worlds" if we use it. Is DCAF deployed? I believe UMA is, right? If DCAF were used, we would hav= e "parallel worlds". Thanks, Kathleen=20 >=20 > Steffi >=20 >> On 11/18/2015 08:08 PM, Erik Wahlstr=C3=B6m neXus wrote: >> If the constrained world and the non-constrained world would exists in tw= o different parallell worlds that would make sense. But it=E2=80=99s not. It= =E2=80=99s a continuum where both big and small devices will talk to each ot= her. I will have a phone that talks standard oauth2 flows to get a token fro= m an authorization server and it=E2=80=99s later used against a constrained d= evice using coap and vice versa. >>=20 >> I would be fine if we only could get by with a JWT, but I don=E2=80=99t t= hink so. Please prove me wrong :) >>=20 >> / Erik >>=20 >>=20 >> On 18 Nov 2015, at 19:57, Anthony Nadalin > wrote: >>=20 >> Makes more sense to have a solution that uses Oauth and JSON/JOSE and a D= CAF solution that uses CBOR/COSE instead of mixing all the combinations as t= hat will be a nightmare >>=20 >> From: Erik Wahlstr=C3=B6m neXus [mailto:erik.wahlstrom@nexusgroup.com] >> Sent: Wednesday, November 18, 2015 10:31 AM >> To: Anthony Nadalin >= >> Cc: Stefanie Gerdes >; Hannes Tschofe= nig >; Stephen Fa= rrell >; Kathlee= n Moriarty >; Kepeng Li >; Ace@ietf.org >> Subject: Re: [Ace] Solution direction >>=20 >> Yes. Json will still be a key format. And it will be heavenly used, espec= ially for class 2 devices. In our tests we did see that JWT got us a very lo= ng way. Especially if we just have to send token once (according to the draf= t). >>=20 >> Then we have the super constrained class 1 devices. They need something m= ore compact. >>=20 >> Sent from my iPhone >>=20 >> On 18 Nov 2015, at 19:17, Anthony Nadalin > wrote: >> Its more than that as we have to deal with JSON and CBOR, so far OAUTH on= ly deals with JSON in the various profiles/extensions >>=20 >> From: Erik Wahlstr=C3=B6m neXus [mailto:erik.wahlstrom@nexusgroup.com] >> Sent: Wednesday, November 18, 2015 10:14 AM >> To: Anthony Nadalin >= >> Cc: Stefanie Gerdes >; Hannes Tschofe= nig >; Stephen Fa= rrell >; Kathlee= n Moriarty >; Kepeng Li >;Ace@ietf.org >> Subject: Re: [Ace] Solution direction >>=20 >> Don't think so. If it's a JWT/JOSE or a CWT/COSE does not mean the world.= It's just a token format (both will exist). A client don't really have to c= are what type of token it is. It's just a access token. >>=20 >> Then we have the framework on how access tokens are retrieved and sent to= establish a context. That's another thing. >>=20 >> / Erik >>=20 >> Sent from my iPhone >>=20 >> On 18 Nov 2015, at 18:39, Anthony Nadalin > wrote: >> Don=E2=80=99t or won=E2=80=99t we already have that confusion with COSE a= nd JOSE (much like confusion with DCAF and OAUTH) ? >>=20 >> From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Erik Wahlstr=C3=B6m n= eXus >> Sent: Wednesday, November 18, 2015 2:58 AM >> To: Stefanie Gerdes > >> Cc: Hannes Tschofenig >; Stephen Farrell >; Kathleen Moriarty >; Kepeng Li >; Ace@ietf.org >> Subject: Re: [Ace] Solution direction >>=20 >> Hi, >>=20 >> Dynamic client registration (RFC7591) and User-Managed Access (UMA) Profi= le of OAuth 2.0 (https://docs.kantarainitiative.org/uma/rec-uma-core.html) solves those s= cenarios. >>=20 >> To make them work with constrained clients and servers, both RFC7591 and U= MA must to be profiled in the same way as the OAuth for IoT draft did for co= re oauth. >>=20 >> Both dynamic client registration and UMA where added later on after Oauth= 2 (RFC6749) was completed. I think that=E2=80=99s a sound model that we shou= ld follow. Get the core concepts down, then extend them when needed and when= we do that we should re-use the concepts already there. >>=20 >> Having two different proposals, both DCAF and OAuth for IoT, running at t= he same time confuses implementors. I don=E2=80=99t think we want to do that= . >>=20 >> / Erik >>=20 >>=20 >>=20 >> On 17 Nov 2015, at 10:07, Stefanie Gerdes > wrote: >>=20 >> Hi all, >>=20 >> I think we should continue working on DCAF in ACE. It provides valuable >> concepts and mechanisms which is why many solutions in ACE draw heavily >> from DCAF. >>=20 >> I think one aspect did not really become clear during the ACE session in >> Yokohama: A solution with only one supporting less constrained device >> will not be able to fully support communication between constrained >> nodes as DCAF does. One main question that is only partly solved by >> other solutions is: How can a constrained client authenticate the other >> party? >>=20 >> A constrained device is not able to establish security associations as >> easily as a less constrained device. The keying material that is used >> for authorization and secure communication must securely be obtained. It >> can either be provisioned manually to the constrained device or a >> security association with a less constrained device is required that can >> then provide the keying material. >>=20 >> An Authorization Server can provide session keys to the constrained >> devices, but the constrained device must have a security association >> with the AS to authenticate the origin of the session key. In a scenario >> where we have only a single AS and two constrained nodes, both need a >> security association with that AS. For cross-domain scenarios this might >> be difficult. We will need to manually provision the keying material to >> one of the devices which makes the dynamic setup of secure communication >> impossible. That's why we need two less-constrained devices in this >> scenario. >>=20 >> You may think that this has nothing to do with authorization and >> therefore is not a topic for ACE. Well, it has, but another >> terminology-discussion might not be that useful. However, the important >> thing is that developing an additional solution to solve this problem >> will very likely add more overhead. The result will be more complex and >> more difficult to implement. Until such a solution is developed we will >> need to use complex workarounds (e.g. manual provisioning), may have >> security problems or are not able to address certain scenarios at all. >>=20 >> But we have never done this before, why now? Because other than the >> general purpose computers that we are using today, constrained devices >> will communicate autonomously without the help of their user. They often >> will not even have user interfaces. Until now this was true for servers >> which is why existing protocols protect them. In a true Internet of >> Things this will also be true for clients. We therefore need to >> reconsider how clients can be protected and how their actions can be >> controlled by their owners. >>=20 >> DCAF supports scenarios with a single less-constrained device (AS) as >> well as scenarios where both the Client and the Server have their own. >> It works with OAuth and may even transport OAuth tickets if that is >> necessary. It has a built-in key distribution mechanism and therefore is >> very efficient. The main fault of DCAF seems to be that we didn't call >> it OAuth. >>=20 >> I think DCAF should be one of the building blocks (one of the tools in >> our toolbox) that ACE is working on. >>=20 >> Best regards, >> Steffi >>=20 >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >=20 > --=20 > Stefanie Gerdes Tel: +49 421 218 63906 > TZI Universit=C3=A4t Bremen E-Mail: gerdes@tzi.de > Bibliothekstr. 1, MZH 5150 > 28359 Bremen, Germany From nobody Thu Nov 19 05:43: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 3E4661ADEB6 for ; Thu, 19 Nov 2015 05:43:49 -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 vS2Uy6BzPLLp for ; Thu, 19 Nov 2015 05:43: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 CA9451B29B9 for ; Thu, 19 Nov 2015 05:43:43 -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 tAJDhXVY016354; Thu, 19 Nov 2015 14:43:33 +0100 (CET) Received: from [IPv6:2001:638:708:30da:4498:9a37:725d:af60] (unknown [IPv6:2001:638:708:30da:4498:9a37:725d:af60]) (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 3p1hzn1b3Xz2Y14; Thu, 19 Nov 2015 14:43:33 +0100 (CET) To: Kathleen Moriarty References: <564AEE51.30407@tzi.de> <56666935-C2EE-495B-9D32-639D887870AD@nexusgroup.com> <0F619216-DE67-4640-90AD-3D0CAC4F80B0@nexusgroup.com> <564D9E8F.805@tzi.de> From: Stefanie Gerdes Message-ID: <564DD205.3010200@tzi.de> Date: Thu, 19 Nov 2015 14:43:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anthony Nadalin , Kepeng Li , "Ace@ietf.org" , Hannes Tschofenig , =?UTF-8?Q?Erik_Wahlstr=c3=b6m_neXus?= , Stephen Farrell Subject: Re: [Ace] Solution direction X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Nov 2015 13:43:49 -0000 Hi Kathleen, On 11/19/2015 02:36 PM, Kathleen Moriarty wrote: > > Is DCAF deployed? I believe UMA is, right? If DCAF were used, we would have "parallel worlds". > Only if DCAF and UMA contradict each other which I believe is not true. Best regards, Steffi From nobody Thu Nov 19 07:50:28 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3411B2BE7 for ; Thu, 19 Nov 2015 07:50:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfls5CtVPdM4 for ; Thu, 19 Nov 2015 07:50:19 -0800 (PST) Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (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 149641B2BDA for ; Thu, 19 Nov 2015 07:50:18 -0800 (PST) Received: by qgea14 with SMTP id a14so53449408qge.0 for ; Thu, 19 Nov 2015 07:49:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nISMNm8zVJCCiOaP2SdO73NdQe1QoQpYn+JbFPRS8o8=; b=QlUoXxsEdMJbe+gHx8o+9lr4h5+RfQViz4HZiUEOcxdIDtVhR+xrBUAaQ2Iv6jINjZ 0XmuxgUjX3QVLV1aV2Kya689eDchkLS5x3ZMQ2RX9GiaHZT+dxo4NbMaK9S+edZoCL+D tY2pxHK3uN8/5+Wjubdy3XvC3Htpddx0T2VGYYbNvCBZFoaHjq7joN9AtjyGHykIOXW3 lKVPMe1NO2PshP7+mNwXmTqTtilFy1tW/sd/uDw2OOQNHfd1BocRcXx+NRol4hbZMpwn Db+boL6ZDaNEAMHcu1Jyl8jLB9IAcJF5WcqRMDF5RkwQToOWEtQKS10g+8nF0j7Bb/kG KyQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nISMNm8zVJCCiOaP2SdO73NdQe1QoQpYn+JbFPRS8o8=; b=WTi0hC1cbu22pbTcDuUamy0qI7Nh5OpIzpLIYL6FBRH+RzV20dBSmH5cW9osX8SmB4 ltZTvVh3tl31WhxcjnECnCCsma6U3pUXQ0RqaPOKqGHPDnEDTIBgB0DNhykFowTGTgPM il17alQyEcEyz6NjLV2KBOEnr2CJMtk5yBC+hE7b9RhpnS5SyS312+HCS7q1QajB87cu 3CjQIFkVRLuGhoq6A0Go0sJ1wr5g7s8YG6iTs4PS/dXMcAl8eQPELYhFj4fbmPVDbNXD DPGVfiEs8tS2TnMGb1gv/XMsYYpVTOfPt6/M0XItfEfcfNCnNbWavXeJ1agQfemIbAS8 3Fxw== X-Gm-Message-State: ALoCoQmY/h5Xt6oz3qtu495yQp3aCWa59ufe3N9y8U7ErJAtF9dRFyiealjUyq/Yeu5GvZ7HXBjA MIME-Version: 1.0 X-Received: by 10.140.88.212 with SMTP id t78mr7630301qgd.82.1447948172951; Thu, 19 Nov 2015 07:49:32 -0800 (PST) Received: by 10.55.145.130 with HTTP; Thu, 19 Nov 2015 07:49:32 -0800 (PST) In-Reply-To: <0E9A48AB39AF3547ACD28A6DE3E2906A0F1ACF8E@ATBRAGMSX02.itiso.net> References: <0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC07D@ATBRAGMSX02.itiso.net> <564C335F.4050404@gmx.net> <564D9D13.5080308@gmx.net> <564DA526.7010604@sics.se> <0E9A48AB39AF3547ACD28A6DE3E2906A0F1ACF8E@ATBRAGMSX02.itiso.net> Date: Thu, 19 Nov 2015 16:49:32 +0100 Message-ID: From: Samuel Erdtman To: Somaraju Abhinav Content-Type: multipart/alternative; boundary=001a11c136aa8096890524e6b451 Archived-At: Cc: Ludwig Seitz , "ace@ietf.org" Subject: Re: [Ace] [ACE] Permanant client-server relations and draft-seitz-ace-oauth-authz-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 15:50:24 -0000 --001a11c136aa8096890524e6b451 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Abhinav, I=C2=B4m glad to here that you liked the draft. 1. > you might be right, I would say that all answers to this would just be more or less qualified guesses. 2. It is slightly unclear to me what you mean but I=C2=B4ll try to explain my understanding * option one would be to use an optimised OAuth2 profile * option two would be pre-provisioned keys to establish secure links I prefer option one since it includes metadata around the keys, i.e. how and where to use the keys and the server can connect them to an authorised client. I think this is information that you must have in som way independent of the solution, i.e. when you have added this to option two you will have the same amount of metadata more or less (but also another specification). 3. I think that there will be no or very little overhead since from my interpretation you would need to have som metadata around keys in option Regarding LWM2M I think but I=C2=B4m not sure that Hannes sees that it coul= d be used for provisioning of the trust relationship with the AS to RS (i.e. pushing AS key), and possible also for the provisioning of OAuth2 token and connected key to the Client. Best Regards //Samuel On Thu, Nov 19, 2015 at 1:49 PM, Somaraju Abhinav < abhinav.somaraju@tridonic.com> wrote: > Hi Hannes, G=C3=B6ran, > > I will try to summaries your replies and please correct me if I am wrong.= : > "The constrained client to constrained server case is conceptually simple= r > than the other cases since the authorization step, as you noted, already > happened out-of-band (by someone)" and =E2=80=9Cpermanent client-server = relations > may be viewed as a special case of the dynamic access rights." > > I agree with this assessment. However, for a lot of constrained devices, > the only use case that is important is permanent client-server relations. > So, considering the proposal to use OAuth draft as the starting point for > the ACE solutions, the questions for me are: > > 1) Can we judge how many use cases we have for permanent client-server > relations vs temporary (dynamic) client server relationships. From how I > see it, the permanent ones are a lot more used in practice for constraine= d > devices. > > 2) Do we want to mandate- > Option1: the use of full OAuth (constrained profile) for every device or > Option2: will we have a method to say that a constrained server or client > is only going to support permanent links and not the full OAuth constrain= ed > profile. > > 3) If we choose Option 1 in Step 2, can we get an estimate of how much > overhead it is compared to Option 1. The LWM2M comparison is relevant her= e > which is more or less option 2 with Option 1 still possible but managed v= ia > a single central server. > > Abhinav > > > ________________________________________ > From: Ace [ace-bounces@ietf.org] on behalf of Ludwig Seitz [ludwig@sics.s= e > ] > Sent: Thursday, November 19, 2015 11:32 AM > To: ace@ietf.org > Subject: Re: [Ace] [ACE] Permanant client-server relations and > draft-seitz-ace-oauth-authz-00 > > On 2015-11-19 10:57, Hannes Tschofenig wrote: > > As an add-on to my email from yesterday I thought it might be also > > useful to look at the LWM2M protocol and to see whether it helps in > > those scenarios. I was thinking about doing a tutorial about LWM2M to > > the group for a little while already and maybe I should give it a try i= n > > December. > > > > Ciao > > Hannes > > > > I think a LWM2M tutorial would be very helpful. Please do give it a try. > > /Ludwig > > -- > 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 > > ________________________________________________________ The contents of > this e-mail and any attachments are confidential to the intended recipien= t. > They may not be disclosed to or used by or copied in any way by anyone > other than the intended recipient. If this e-mail is received in error, > please immediately notify the sender and delete the e-mail and attached > documents. Please note that neither the sender nor the sender's company > accept any responsibility for viruses and it is your responsibility to sc= an > or otherwise check this e-mail and any attachments. > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --001a11c136aa8096890524e6b451 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Abhinav,

I=C2=B4m glad to= here that you liked the draft.

1.
> = you might be right, I would say that all answers to this would just be more= or less qualified guesses.

2.
It is sli= ghtly unclear to me what you mean but I=C2=B4ll try to explain my understan= ding=C2=A0
* option one would be to use an optimised OAuth2 profi= le
* option two would be pre-provisioned keys to establish secure= links
I prefer option one since it includes metadata around the = keys, i.e. how and where to use the keys and the server can connect them to= an authorised client. I think this is information that you must have in so= m way independent of the solution, i.e. when you have added this to option = two you will have the same amount of metadata more or less (but also anothe= r specification).=C2=A0

3.
I think that = there will be no or very little overhead since from my interpretation you w= ould need to have som metadata around keys in option


Regarding LWM2M I think but I=C2=B4m not sure that Hannes= sees that it could be used for provisioning of the trust relationship with= the AS to RS (i.e. pushing AS key), and possible also for the provisioning= of OAuth2 token and connected key to the Client.

=
Best Regards
//Samuel


On Thu, Nov 19, 201= 5 at 1:49 PM, Somaraju Abhinav <abhinav.somaraju@tridonic.com<= /a>> wrote:
Hi Hannes, G=C3=B6r= an,

I will try to summaries your replies and please correct me if I am wrong.:<= br> "The constrained client to constrained server case is conceptually sim= pler than the other cases since the authorization step, as you noted, alrea= dy happened out-of-band (by someone)" and=C2=A0 =E2=80=9Cpermanent cli= ent-server relations may be viewed as a special case of the dynamic access = rights."

I agree with this assessment. However, for a lot of constrained devices, th= e only use case that is important is permanent client-server relations. So,= considering the proposal to use OAuth draft as the starting point for the = ACE solutions, the questions for me are:

1) Can we judge how many use cases we have for permanent client-server rela= tions vs temporary (dynamic) client server relationships. From how I see it= , the permanent ones are a lot more used in practice for constrained device= s.

2) Do we want to mandate-
Option1: the use of full OAuth (constrained profile) for every device or Option2: will we have a method to say that a constrained server or client i= s only going to support permanent links and not the full OAuth constrained = profile.

3) If we choose Option 1 in Step 2, can we get an estimate of how much over= head it is compared to Option 1. The LWM2M comparison is relevant here whic= h is more or less option 2 with Option 1 still possible but managed via a s= ingle central server.

Abhinav


________________________________________
From: Ace [ace-bounces@ietf.org= ] on behalf of Ludwig Seitz [ludwig@sics.= se]
Sent: Thursday, November 19, 2015 11:32 AM
To: ace@ietf.org
Subject: Re: [Ace] [ACE] Permanant client-server relations and draft-seitz-= ace-oauth-authz-00

On 2015-11-19 10:57, Hannes Tschofenig wrote:
> As an add-on to my email from yesterday I thought it might be also
> useful to look at the LWM2M protocol and to see whether it helps in > those scenarios. I was thinking about doing a tutorial about LWM2M to<= br> > the group for a little while already and maybe I should give it a try = in
> December.
>
> Ciao
> Hannes
>

I think a LWM2M tutorial would be very helpful. Please do give it a try.
/Ludwig

--
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

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

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

--001a11c136aa8096890524e6b451-- From nobody Sun Nov 22 03:33:07 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F26CE1A21BF for ; Sun, 22 Nov 2015 03:33:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.248 X-Spam-Level: X-Spam-Status: No, score=-0.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_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 z4h6H20NBldZ for ; Sun, 22 Nov 2015 03:33:02 -0800 (PST) Received: from out4133-114.mail.aliyun.com (out4133-114.mail.aliyun.com [42.120.133.114]) by ietfa.amsl.com (Postfix) with ESMTP id 08E791A3B9D for ; Sun, 22 Nov 2015 03:33:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1448191976; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=PhRr+NKMme+K8EMQ/N7zvj85bxwieA03l0SSgD1VMpU=; b=Kai+exM+2KAWKdxUra1Bt8JgwybHSQQbsLRvoas/dkuIbAaSGmN7l2PfyyhI9G9HcPH6oQpJWUT3doBLnW+Iv6ziY6OjOYK+p2LddMyK1sbngDp5KOZL81f1lWDPiVEr9+M8kAtTSQJ9kWGOviP3rrK8vNnfu0sqY1jIk//SSsY= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R181e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03311; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=5; SR=0; TI=SMTPD_----4F1u-ST; Received: from 10.22.45.236(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.207) by smtp.aliyun-inc.com(127.0.0.1); Sun, 22 Nov 2015 19:32:52 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Sun, 22 Nov 2015 19:32:45 +0800 From: "Kepeng Li" To: "Kepeng Li" , "Ace@ietf.org" Message-ID: Thread-Topic: [Ace] Solution direction Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3531065572_14824338" Archived-At: Cc: Kathleen Moriarty , Hannes Tschofenig , Stephen Farrell Subject: Re: [Ace] Solution direction X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 22 Nov 2015 11:33:06 -0000 > ´ËÓʼþʹÓà MIME ¸ñʽ¡£ÓÉÓÚÓʼþÔĶÁ³ÌÐò²»ÄÜʶ±ð ´Ë¸ñʽ£¬Òò´Ë£¬¿ÉÄÜÎÞ·¨Ê¶±ð¸ÃÓʼþµÄ·Ö²¿»ò²¿·ÖÄÚÈÝ¡£ --B_3531065572_14824338 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable I would like to conclude that the rough consensus is to use OAuth profile draft as a starting point. http://datatracker.ietf.org/doc/draft-seitz-ace-oauth-authz/ Currently there are already several reviews in the mailing list about this draft. I notice that there are some concerns that some pieces (e.g. cross-domain support) are missing in the current OAuth profile draft. We can continue this kind of discussion in the mailing list and improve the draft. My recommendation is to ask the authors to make updates for the draft according to the review comments, to have a more mature verion for the working group to work on. Thanks, Kind Regards Kepeng (as ACE co-chair) =B7=A2=BC=FE=C8=CB: Li Kepeng =C8=D5=C6=DA: Monday, 2 November, 2015 1:39 pm =D6=C1: "Ace@ietf.org" =B3=AD=CB=CD: Kathleen Moriarty , Hannes Tschofenig , Stephen Farrell =D6=F7=CC=E2: [Ace] Solution direction At the face-to-face meeting of the ACE working group in Yokohama, the participants in the room decided to accept the OAuth profiling draft as a starting point for future work of the solution charter item: http://datatracker.ietf.org/doc/draft-seitz-ace-oauth-authz/ For those who weren't present in the room, please let us know whether you accept or object to this decision, before 17th Nov, 2015. Thanks, Kind Regards Kepeng=20 --B_3531065572_14824338 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable
= I would like to conclude that the rough consensus is to use OAuth profile dr= aft as a starting point. 
http://datatracker.ietf.org/doc/draft-seitz-= ace-oauth-authz/ 

Currently there ar= e already several reviews in the mailing list about this draft.

I notice = that there are some concerns that some pieces (e.g. cross-domain support) ar= e missing in the current OAuth profile draft. 

We can continue this = kind of discussion in the mailing list and improve the draft.

My recommen= dation is to ask the authors to make updates for the draft according to the = review comments, to have a more mature verion for the working group to work = on.

Thanks,

Kind Regards
Kepeng (= as ACE co-chair)

=B7=A2=BC=FE=C8=CB: Li Kepeng <kepeng.lkp@al= ibaba-inc.com>
=C8=D5=C6=DA: Monday= , 2 November, 2015 1:39 pm
=D6=C1: "Ace@ietf.org" <Ace@ietf.org>
=B3=AD=CB=CD: Kat= hleen Moriarty <kathlee= n.moriarty.ietf@gmail.com>, Hannes Tschofenig <hannes.tschofenig@gmx.net>, Stephen Farrell &= lt;stephen.farrell@cs.tcd.ie&= gt;
=D6=F7=CC=E2: [Ace] Solution direction=

At the face-to-face mee= ting of the ACE working group in Yokohama, the participants in the room deci= ded to accept the OAuth profiling draft as a starting point for future work = of the solution charter item:

For those who weren't= present in the room, please let us know whether you accept or object to thi= s decision, before 17th Nov, 2015.

Thanks,

Kind Regards
Kepeng 

--B_3531065572_14824338-- From nobody Sun Nov 22 05:59: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 73C3D1AC3B3 for ; Sun, 22 Nov 2015 05:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 2IWJvYt6to86 for ; Sun, 22 Nov 2015 05:59:21 -0800 (PST) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CC901A896B for ; Sun, 22 Nov 2015 05:59:21 -0800 (PST) Received: by vkha189 with SMTP id a189so23116661vkh.2 for ; Sun, 22 Nov 2015 05:59:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kB9D9W8n2g6MU4sA9wzYxIJAzAfi1EuaksVYzorqdyw=; b=h6e5JB3Ck5ZKJ3okw2XkH8HX3ille7T4LfwDHNkLktQsD67AaOIERIlVR3tXkFiH1Z +ZFDBs1LLPjoEjJ9lw1zj6feQOfk/GvQT7uC6EatnO775TVn36ZdizaSwczuIzVwrz09 +Ly9OgrkS9E/o96Qdu8YF7QZ/eRM1ZjDppNi2JSaJIcepDmB89W+u+Qw2PHUqH1q7jTj RfURkST/U9V9P1pmxatnuoLMMx8oU3TiCT7eOe7F6NugqY3rsA9HMYlDoGN0aLnmHrV1 9FGU7IbWUxMZwS5peCdSwfcJnMw8WJmRhzKyDyXTJ/y5PEYsPyuSdB0qthPzEPo+wmBB tOTw== X-Received: by 10.31.148.72 with SMTP id w69mr11136069vkd.49.1448200760244; Sun, 22 Nov 2015 05:59:20 -0800 (PST) Received: from [172.20.3.0] ([65.200.157.66]) by smtp.gmail.com with ESMTPSA id h200sm6989034vka.5.2015.11.22.05.59.18 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 22 Nov 2015 05:59:18 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: multipart/alternative; boundary=Apple-Mail-A688DAB9-A1D7-4D76-8833-D61AA0891464 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (12H143) In-Reply-To: Date: Sun, 22 Nov 2015 08:59:17 -0500 Content-Transfer-Encoding: 7bit Message-Id: <2F7185A0-300F-4CB2-9794-B5037147043A@gmail.com> References: To: Kepeng Li Archived-At: Cc: Stephen Farrell , Hannes Tschofenig , "Ace@ietf.org" Subject: Re: [Ace] Solution direction X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 22 Nov 2015 13:59:23 -0000 --Apple-Mail-A688DAB9-A1D7-4D76-8833-D61AA0891464 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thank you, Kepeng. I agree with this go forward plan as consensus in the ro= om was very strong. While cross-domain support may not be out of the questi= on, let's keep this question and how to do it from preventing progress with O= Auth. Thank you, Kathleen=20 Sent from my iPhone > On Nov 22, 2015, at 6:32 AM, Kepeng Li wrote:= >=20 > I would like to conclude that the rough consensus is to use OAuth profile d= raft as a starting point.=20 > http://datatracker.ietf.org/doc/draft-seitz-ace-oauth-authz/=20 >=20 > Currently there are already several reviews in the mailing list about this= draft. >=20 > I notice that there are some concerns that some pieces (e.g. cross-domain s= upport) are missing in the current OAuth profile draft.=20 >=20 > We can continue this kind of discussion in the mailing list and improve th= e draft. >=20 > My recommendation is to ask the authors to make updates for the draft acco= rding to the review comments, to have a more mature verion for the working g= roup to work on. >=20 > Thanks, >=20 > Kind Regards > Kepeng (as ACE co-chair) >=20 > =E5=8F=91=E4=BB=B6=E4=BA=BA: Li Kepeng > =E6=97=A5=E6=9C=9F: Monday, 2 November, 2015 1:39 pm > =E8=87=B3: "Ace@ietf.org" > =E6=8A=84=E9=80=81: Kathleen Moriarty , H= annes Tschofenig , Stephen Farrell > =E4=B8=BB=E9=A2=98: [Ace] Solution direction >=20 > At the face-to-face meeting of the ACE working group in Yokohama, the part= icipants in the room decided to accept the OAuth profiling draft as a starti= ng point for future work of the solution charter item: > http://datatracker.ietf.org/doc/draft-seitz-ace-oauth-authz/=20 >=20 > For those who weren't present in the room, please let us know whether you a= ccept or object to this decision, before 17th Nov, 2015. >=20 > Thanks, >=20 > Kind Regards > Kepeng=20 >=20 --Apple-Mail-A688DAB9-A1D7-4D76-8833-D61AA0891464 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thank you, Kepeng.  I agree with t= his go forward plan as consensus in the room was very strong.  While cr= oss-domain support may not be out of the question, let's keep this question a= nd how to do it from preventing progress with OAuth.

Thank you,
Kathleen 

Sent from my iPhone
<= br>On Nov 22, 2015, at 6:32 AM, Kepeng Li <kepeng.lkp@alibaba-inc.com> wrote:

I would like to conclude that the rough consensus is to use OAuth profile= draft as a starting point. 

Currently there are already several reviews in the mailing list about thi= s draft.

I notice that there are some con= cerns that some pieces (e.g. cross-domain support) are missing in the curren= t OAuth profile draft. 

We can conti= nue this kind of discussion in the mailing list and improve the draft.
=

My recommendation is to ask the authors to mak= e updates for the draft according to the review comments, to have a more mat= ure verion for the working group to work on.

Thanks,

Kind Regards
Kepeng (as ACE co-chair)

=E5=8F=91=E4=BB=B6=E4=BA=BA: Li= Kepeng <kepeng.lkp@alibaba= -inc.com>
=E6=97=A5=E6=9C=9F: Monday, 2 November, 2015 1:39 pm
=E8= =87=B3: "Ace@ietf.org" <Ace@ietf.org>
=E6=8A=84=E9=80=81: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, H= annes Tschofenig <hannes.tsc= hofenig@gmx.net>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
=E4=B8=BB=E9=A2=98: [Ace] Solution direction
<= br>
At the face-to-face mee= ting of the ACE working group in Yokohama, the participants in the room deci= ded to accept the OAuth profiling draft as a starting point for future work o= f the solution charter item:

For those who weren'= t present in the room, please let us know whether you accept or object to th= is decision, before 17th Nov, 2015.

Thanks,

Kind Regards
Kepeng 

<= /span> = --Apple-Mail-A688DAB9-A1D7-4D76-8833-D61AA0891464-- From nobody Mon Nov 23 00:28: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 B9A861B37AC for ; Mon, 23 Nov 2015 00:28:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6l6JspaS5HU for ; Mon, 23 Nov 2015 00:28:30 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0761.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::761]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 811F31B37AE for ; Mon, 23 Nov 2015 00:28:28 -0800 (PST) Received: from AM3PR06MB148.eurprd06.prod.outlook.com (10.242.245.19) by AM3PR06MB1267.eurprd06.prod.outlook.com (10.163.9.25) with Microsoft SMTP Server (TLS) id 15.1.331.20; Mon, 23 Nov 2015 08:28:07 +0000 Received: from VI1PR06CA0062.eurprd06.prod.outlook.com (10.163.160.30) by AM3PR06MB148.eurprd06.prod.outlook.com (10.242.245.19) with Microsoft SMTP Server (TLS) id 15.1.325.17; Mon, 23 Nov 2015 08:28:05 +0000 Received: from AM1FFO11OLC005.protection.gbl (2a01:111:f400:7e00::180) by VI1PR06CA0062.outlook.office365.com (2a01:111:e400:533c::30) with Microsoft SMTP Server (TLS) id 15.1.331.20 via Frontend Transport; Mon, 23 Nov 2015 08:28:04 +0000 Authentication-Results: spf=pass (sender IP is 146.108.200.10) smtp.mailfrom=tridonic.com; erdtman.se; dkim=none (message not signed) header.d=none;erdtman.se; dmarc=bestguesspass action=none header.from=tridonic.com; Received-SPF: Pass (protection.outlook.com: domain of tridonic.com designates 146.108.200.10 as permitted sender) receiver=protection.outlook.com; client-ip=146.108.200.10; helo=ATBRAGMSX01.itiso.net; Received: from ATBRAGMSX01.itiso.net (146.108.200.10) by AM1FFO11OLC005.mail.protection.outlook.com (10.174.64.132) with Microsoft SMTP Server (TLS) id 15.1.331.11 via Frontend Transport; Mon, 23 Nov 2015 08:28:03 +0000 Received: from ATBRAGMSX02.itiso.net ([169.254.2.220]) by ATBRAGMSX01.itiso.net ([169.254.1.64]) with mapi id 14.03.0248.002; Mon, 23 Nov 2015 09:27:54 +0100 From: Somaraju Abhinav To: Samuel Erdtman Thread-Topic: [Ace] [ACE] Permanant client-server relations and draft-seitz-ace-oauth-authz-00 Thread-Index: AdEhN5xFUnXCzFUVReqBc2YQQmmyoAAmSPSAADXl4YAAATQBAAAGXD/BAAS51QAAu2sVQA== Date: Mon, 23 Nov 2015 08:27:53 +0000 Message-ID: <0E9A48AB39AF3547ACD28A6DE3E2906A0F1AE185@ATBRAGMSX02.itiso.net> References: <0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC07D@ATBRAGMSX02.itiso.net> <564C335F.4050404@gmx.net> <564D9D13.5080308@gmx.net> <564DA526.7010604@sics.se> <0E9A48AB39AF3547ACD28A6DE3E2906A0F1ACF8E@ATBRAGMSX02.itiso.net> In-Reply-To: Accept-Language: en-US, de-AT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.108.41.149] Content-Type: multipart/alternative; boundary="_000_0E9A48AB39AF3547ACD28A6DE3E2906A0F1AE185ATBRAGMSX02itis_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11OLC005; 1:Kz4xMx8xbsxooa1zlNnbHsQkk+sQ/atUy8PrHiWs6IgFvHWeWhjL1q+hu+6w7ayBFkAgtTAGo8U1YDfCJVAb4oRjWM5bzqbdBvbKHw1kyfs16SBbihtJkJCmtxhzW1+Ju1Vr8C5nOgYt/KkLWN9n05TT40mMG1GqHfUPLbt+vSPqt0RkPM9KrBNvE4pyNHDXcmnZ7CAyPOFeTdmfVgVoy0muHhVB+XVYmLq2WWOwJGqa9FwcrEy1G/s68IgnLYAHm2DjAU/v5utzkbvaeK7uwPz3KJ0zlhoeiK9BmXF1f2Ro/V1uFG8+o8VrPLopHuVEZbBiYikgvKpgnaYEsjHvpx8bdQdMQsIBU4BnLn7TObo= X-Forefront-Antispam-Report: CIP:146.108.200.10; CTRY:AT; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(2980300002)(438002)(377454003)(189002)(199003)(24454002)(51444003)(377424004)(26826002)(110136002)(76176999)(33656002)(561944003)(66066001)(230783001)(19580395003)(5890100001)(300700001)(189998001)(5001960100002)(86362001)(53416004)(84326002)(19300405004)(69596002)(85806002)(4001150100001)(81156007)(16601075003)(586003)(5003600100002)(87936001)(92566002)(19580405001)(6806005)(2920100001)(2900100001)(19617315012)(104016004)(55846006)(106466001)(512874002)(19625215002)(54356999)(16236675004)(790700001)(93886004)(102836003)(5008740100001)(5007970100001)(2950100001)(50986999)(3846002)(6116002)(5004730100002)(15975445007); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR06MB148; H:ATBRAGMSX01.itiso.net; FPR:; SPF:Pass; PTR:unknown.zgrp.net; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AM3PR06MB148; 2:OAtd572r3zeE7Fv0YfSLs9jJFKiKBfYs+5K1Xo/yxxCW4ZKagPEsqERIjwJs0VDGM21FCuU2Y2NJmA4qttNH9B7NbPY5tQZTRCsjhOfflC9pUom6Fqa//EjBpPhv0fdZ1Qno+iKe1O8vXRqZ59g925vxXWeK/Lga+IDXmioaEXQ=; 3:O0mTdPLxPUnRLXexIGnlPFLHBLK1+WAgyy7SbK27IuOPL5lNidvRl8ZQrEZSJknMtFyeB2P6GOYjZZoY/WWaYbirtSJN0fFkMLnU0taS8tC3dqF0lcddz4XK9gux/KGt9x0z97rY/8rf7MLas/zLXJ7s7h1LqhUQB6KDDORCA5kYsnfxgU2kf7ipzZbCFPcTm5ZxQrfaOmQGGDOLF7SgXy5TWOBA8Dmh8OX5XhaJX2kefdRC/5pcxDBazai3jsm+Aqu0B75Jw+n77ycH4duwDwloDaiir01AYXEvANUkrN8=; 25:A2tvsAlNjs38hbAnAdGEQKfnP4EH8FoYdxyDD9XY6Qdm9M/W6bNYATIatjv3Gk4WRwVFD0LmKxBQSK1bug6AatILihC6X2wGaMO5BsvoUYVt8vjSK13D+5b9x1QrSMcYKlLPY5P0SwV2Xx+Y98tjzy7trDh6v06fyDUKmQyFBLKlxQofLsKIGSMctFbSTKq1RgRdh42WnV9vV5+qBRUJXJBRvc3Bl2J/GWhYs8MgGtR/WTXKRwzzoG1IP1tUW7onxKLcR9NFRvYKMFcTRbbDkQ== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(42142001)(8251501001); SRVR:AM3PR06MB148; X-Microsoft-Exchange-Diagnostics: 1; AM3PR06MB148; 20:SRTyfWe+6hWAY2/Ii9HY9NpBFiRH26TSftaMLj9voY/J161BJuUSdJnQRzIjKD2PuKi+Dqmoccza3TnsIdCJJmwc7Pv7iSTi7m9arQ1gNjptExy/oPScecASmtq4VVKRcGDL7RDmCimvLm48e62sANjloLgq5GLY2MlAHlRX/aon1fJn7wfNt8+71lciIsEGkPcHfQg3f8gtexy1+V7u5AuEFAR3QyZv1optv0zELed4puEo8Psgs+YDpRDo5vL2CW9XXYuvZ9gBOSOs0vjoMGhwdJmHK4QCZoLROZYZk92xXkeVlAlkP2Z4EJ1Ik4TggH6p0JsUPYSQQulki/B9MA8r0pjDiYo0elGPkQynUV5Hyv+uZdUWJqi+1DHeCX2CZuyOP2psY6PPsRcUVbUAVs/r0FVE7eHAqoS0gCt1dcMyWgf/PntRNUVOUMO/lLaJnDIdW2AMmMNjCpHDPjdtUQKpHoMOvB1vUt7ogWpEQvo4PzTQMOz545Ggyy4VjIuE; 4:3yLPwK55MQjdHngLOPKFK5rVx0Fcjgp+NGUdmjZ4R2UIdCJDofrrop2NJtWsNeqGPMU3Ao6s7djo6teJ2V9NxDqnGHIIcGGA+xFU3esNfGqggndG9UgoEAfI4lxVa1GxsNRhGmuHkzgilXE1Mpa4UKueRt5GrH7OIKTyESMISO1SvpNgnI+2EvDHMXjboD62tXKvxUi7pc+kUoijdnwLswDlSWG9FMN+C8g+Exxf/ZoHFOg9bcnI7qApabWXzULJdH6FPmKEbxCVcVObw19B0lbtByIosZOsRNbsOb5GWkSSL/cW/5dYmdJMPEitdd8rVyNIlfqSCjJiCxlkf7zYNcIsGbkFDm3GDFGc64YlW6fjDPS0VO3SesJAXYd6vnur X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(108003899814671)(216554174695431); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(10201501046)(3002001); SRVR:AM3PR06MB148; BCL:0; PCL:0; RULEID:; SRVR:AM3PR06MB148; X-Forefront-PRVS: 07697999E6 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; AM3PR06MB148; 23:7TH1wq+R52eU4MUS8eS+dcDqewYRhqU3g68bf30XBM?= =?us-ascii?Q?pSj0jNS6VxNjc2jwgHuXKB+H/HcTdplHk9JedRhZjHnwZO+//wBWFHrzvrVF?= =?us-ascii?Q?vk++koaNb1mC7MIQWLCxjz0M+fVelh/3beTrcRU2VePRbtnGRrIx8RSnvu/u?= =?us-ascii?Q?v8APZqcaFsqcz6WI+U8sHxXUfdmYCMj3KDv874BV33cUlsndNM7n4gfNkFtE?= =?us-ascii?Q?e7bU8VHdnU8mid395m7CdDL21mbG68cy38atdhvGMJEIQ45auhmq3NYef3m0?= =?us-ascii?Q?OOSC8Knr8oJNp+Hnr8mM/EFG9dkqeF0+zQZLRHDa+ZSI0vgDW1bzSM8+7VKE?= =?us-ascii?Q?JPPqmYI0/27yVbW+YqTiJ7I7qix49vKhInPwAinpB2bkdXkNRk+ODlLFmalR?= =?us-ascii?Q?8IDHICurJNtP5meuFT2/zW5vIffltfOb+WJRmJko3FAStJYBwSWxTYKUG+bv?= =?us-ascii?Q?+YEX23vCVpmeMPeyyfcdD/SgxJIFLOlmXg25DzhIOeLja7VKJYDkmATyNBWe?= =?us-ascii?Q?j3igg8PW9G+k4o+YsuQlXHzdLV843+QspCBYbvTg7W704Xv8uEc4ZeiiztDW?= =?us-ascii?Q?CCO0/ENwI6YddAieejCZljAwPPpZIl/KE3VYHMISbIfk8XhE8w02CRxLpnqo?= =?us-ascii?Q?e7B/GLs8wKBLHhsXhw91M0uWHZT4oCT8kDEkUXwbo1nX7vRwWFbxoUFaU1vZ?= =?us-ascii?Q?+39/r5feWWdfKARD6lYH7hNvYNdmRNy5e0PZrtKfhJiWkiJLsc3QQMUIBomE?= =?us-ascii?Q?64cYJAWnGhDDezTdt4k86RO2RTahlypUBOIAfjONJ71dQLjTYf1+WU/WC1/M?= =?us-ascii?Q?bEkKRHZcei8+AD02kyZPkT9zva+O4knohEpgKnhXFDTDH5V7/0gn5VaM7yi3?= =?us-ascii?Q?GhGRZkir04DBtrDkBBGV7rG98K11ZnP1P721KlK7Crkp1qY4bukyUgcYfuBa?= =?us-ascii?Q?uwEiONIiLRsgsPomK6iDMI6xMTCyFkObg7ZClXSHX05Jsjy/KBk7AkQhK7pp?= =?us-ascii?Q?T3qn2Rn8ULFLnHpfK5ShffKICCf2yryv/bYBAV0N+bk6DfV4r7SwuqUO6BxF?= =?us-ascii?Q?aLyOyIxRsFeP1f7B9ndABfrpuf7gx19DWh00mawXMWenL7SZgF7F5LQLkksj?= =?us-ascii?Q?AAVQjkLbudpxUlBkXkwBUUVoD9Tzdpq9Pc3amJkEkwuVfKOUngj9jsvBfv0t?= =?us-ascii?Q?3jNtAl0T4ObA91Rzj0cyb4jwsm6gCHk7PKdvEk4oc+rvmjmqFT6MW4VmDk4b?= =?us-ascii?Q?5RLG41Au2bWFbDD1ROqf09lZUO6FwnV0JUCvgIxfDKHFHQaSiexgfgxQWtda?= =?us-ascii?Q?tlaiBw91vYOhyTW/x/upp5tC0MHss8Sgw0G1T9hEtLV1pqhhTSuwvubgBIP4?= =?us-ascii?Q?McyViqKYam3qMf/hQCZ/1sRnIfLcKcPCi3G5IN1eE5aYeuOeKdzSGk9n78Cl?= =?us-ascii?Q?ON0illxxln7X3fJle2P16Zg04xsl55HsCpnjNUSSpzAbVQNkb+5ekaYB+EXX?= =?us-ascii?Q?YETTORJWl8Dg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM3PR06MB148; 5:kdxJz5NE/df1slvrrgEi+1TvkeIqKbmKIGmoRPd9mKahHMXXBPL/QdG/27nGhpEyL8JdEoLx/wLSqg3OaoURe+MtakNsQxokeenzO5JWcnMC+H86Zj9050huwvYD43A7Dg17/VJPIX3Wx25xtRJFnw==; 24:VGk5R1FcO4/i8VfVlq36XCVWNlTj0DyF4HUc6nxnw25bLcUk1BA/MGTGJ4Sk/os6ND+8dTnr/YkuyCi1yUOT0h/17Qlpa0szaztTYTn5+D0=; 20:cydJ9V076qmLJDJJjJCrgYFRu4ntShn1plMg0yArkJZHEDroH8IdkvMZ5a2ymhM5sPoF5yZjfGfFEUwlDmlr9A== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Nov 2015 08:28:03.7271 (UTC) X-MS-Exchange-CrossTenant-Id: 8b206608-a593-4ace-a4b6-ef1fc83c9169 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8b206608-a593-4ace-a4b6-ef1fc83c9169; Ip=[146.108.200.10]; Helo=[ATBRAGMSX01.itiso.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR06MB148 X-Microsoft-Exchange-Diagnostics: 1; AM3PR06MB1267; 2:iNCIO9NspvITVPqnTpCP2dnyokZGJQW4PvgeAUiHpwgaF6h9B6hMN0sYq2KahopUZup508LhrS/rspNobcznuX03vnYf9zmpU95btg7uXZlcH91WuGxHcQeRV4FaBaztlHm5Gz3ZOaKOw5x96nsJ8w==; 23:8QZ5x/8QKoRWf/PGTxRXhS3EHrfBypkbNZ6Muk1KDaF+OdMeMgcZ5kngwTOSh/Vh50Iw2uAmO8thmo3oU1fWdGVTZ+KKl09Eq83O122/xI2I/4gFkupu9snObPL3fKbF7ZMLl0H7Rj0WuoucJhzno7WS8P/8E/eWceuaoH3t0hcasJ+TqLeNDvl2gFOZPSBW X-OriginatorOrg: tridonic.com Archived-At: Cc: Ludwig Seitz , "ace@ietf.org" Subject: Re: [Ace] [ACE] Permanant client-server relations and draft-seitz-ace-oauth-authz-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 08:28:34 -0000 --_000_0E9A48AB39AF3547ACD28A6DE3E2906A0F1AE185ATBRAGMSX02itis_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU2FtdWVsLA0KVGhhbmsgeW91IGZvciB5b3VyIGNvbW1lbnRzLiBQbGVhc2Ugc2VlIGlubGlu ZS4NCg0KMS4NCj4geW91IG1pZ2h0IGJlIHJpZ2h0LCBJIHdvdWxkIHNheSB0aGF0IGFsbCBhbnN3 ZXJzIHRvIHRoaXMgd291bGQganVzdCBiZSBtb3JlIG9yIGxlc3MgcXVhbGlmaWVkIGd1ZXNzZXMu DQpbQVNdIEFncmVlLg0KDQoyLg0KSXQgaXMgc2xpZ2h0bHkgdW5jbGVhciB0byBtZSB3aGF0IHlv dSBtZWFuIGJ1dCBJwrRsbCB0cnkgdG8gZXhwbGFpbiBteSB1bmRlcnN0YW5kaW5nDQoqIG9wdGlv biBvbmUgd291bGQgYmUgdG8gdXNlIGFuIG9wdGltaXNlZCBPQXV0aDIgcHJvZmlsZQ0KKiBvcHRp b24gdHdvIHdvdWxkIGJlIHByZS1wcm92aXNpb25lZCBrZXlzIHRvIGVzdGFibGlzaCBzZWN1cmUg bGlua3MNCkkgcHJlZmVyIG9wdGlvbiBvbmUgc2luY2UgaXQgaW5jbHVkZXMgbWV0YWRhdGEgYXJv dW5kIHRoZSBrZXlzLCBpLmUuIGhvdyBhbmQgd2hlcmUgdG8gdXNlIHRoZSBrZXlzIGFuZCB0aGUg c2VydmVyIGNhbiBjb25uZWN0IHRoZW0gdG8gYW4gYXV0aG9yaXNlZCBjbGllbnQuIEkgdGhpbmsg dGhpcyBpcyBpbmZvcm1hdGlvbiB0aGF0IHlvdSBtdXN0IGhhdmUgaW4gc29tIHdheSBpbmRlcGVu ZGVudCBvZiB0aGUgc29sdXRpb24sIGkuZS4gd2hlbiB5b3UgaGF2ZSBhZGRlZCB0aGlzIHRvIG9w dGlvbiB0d28geW91IHdpbGwgaGF2ZSB0aGUgc2FtZSBhbW91bnQgb2YgbWV0YWRhdGEgbW9yZSBv ciBsZXNzIChidXQgYWxzbyBhbm90aGVyIHNwZWNpZmljYXRpb24pLg0KW0FTXSBJZGVhbGx5IHNw ZWFraW5nLCB3ZSBkbyBub3Qgd2FudCBhbm90aGVyIHNwZWNpZmljYXRpb24gYnV0IGFuIGFkZGl0 aW9uIHRvIHRoZSBPQXV0aCBkb2N1bWVudC4gUmVmZXJyaW5nIHRvIEZpZ3VyZSAxIGluIHlvdXIg ZG9jdW1lbnQsIGNhbiB3ZSBub3QgdGhpbmsgb2Ygc2ltcGxlciBmbG93cyB3aGVyZSB0aGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgd3JpdGVzIGNsaWVudCBjcmVkZW50aWFscyBkaXJlY3RseSB0byB0 aGUgUmVzb3VyY2Ugc2VydmVyIGFuZCBwcm92aWRlcyBjbGllbnQgaW5mb3JtYXRpb24gdG8gdGhl IGNsaWVudC4gU28sIHRoZSBvbmx5IHN0ZXBzIHRoYXQgbmVlZCB0byBiZSBwZXJmb3JtZWQgYXJl IEUsIEIsIEMgYW5kIEY/IEkgZG8gbm90IHRoaW5rIHRoZSBwZXJtYW5lbnQgY2xpZW50IHNlcnZl ciByb2xlcyBhcmUgY29ybmVyIGNhc2VzIHRvIGNvbnNpZGVyIGFuZCBhdCBsZWFzdCBpbiBteSBh cHBsaWNhdGlvbnMgKGluZG9vciBwcm9mLiBsaWdodGluZyksIGl0IGlzIHRoZSBtYWluIHVzZSBj YXNlLiBNYXliZSBpdCB3b3VsZCBoZWxwIGlmIEkgY291bGQgZ2V0IGEgbW9yZSBkZXRhaWxlZCBk ZXNjcmlwdGlvbiBvZiBob3cgdGhpcyBjYXNlIHdpbGwgYmUgYWRkcmVzc2VkIGluIHRoZSBjdXJy ZW50IGRyYWZ0Lg0KDQozLg0KSSB0aGluayB0aGF0IHRoZXJlIHdpbGwgYmUgbm8gb3IgdmVyeSBs aXR0bGUgb3ZlcmhlYWQgc2luY2UgZnJvbSBteSBpbnRlcnByZXRhdGlvbiB5b3Ugd291bGQgbmVl ZCB0byBoYXZlIHNvbSBtZXRhZGF0YSBhcm91bmQga2V5cyBpbiBvcHRpb24NCg0KDQpSZWdhcmRp bmcgTFdNMk0gSSB0aGluayBidXQgScK0bSBub3Qgc3VyZSB0aGF0IEhhbm5lcyBzZWVzIHRoYXQg aXQgY291bGQgYmUgdXNlZCBmb3IgcHJvdmlzaW9uaW5nIG9mIHRoZSB0cnVzdCByZWxhdGlvbnNo aXAgd2l0aCB0aGUgQVMgdG8gUlMgKGkuZS4gcHVzaGluZyBBUyBrZXkpLCBhbmQgcG9zc2libGUg YWxzbyBmb3IgdGhlIHByb3Zpc2lvbmluZyBvZiBPQXV0aDIgdG9rZW4gYW5kIGNvbm5lY3RlZCBr ZXkgdG8gdGhlIENsaWVudC4NCg0KDQpCZXN0IFJlZ2FyZHMNCi8vU2FtdWVsDQoNCg0KT24gVGh1 LCBOb3YgMTksIDIwMTUgYXQgMTo0OSBQTSwgU29tYXJhanUgQWJoaW5hdiA8YWJoaW5hdi5zb21h cmFqdUB0cmlkb25pYy5jb208bWFpbHRvOmFiaGluYXYuc29tYXJhanVAdHJpZG9uaWMuY29tPj4g d3JvdGU6DQpIaSBIYW5uZXMsIEfDtnJhbiwNCg0KSSB3aWxsIHRyeSB0byBzdW1tYXJpZXMgeW91 ciByZXBsaWVzIGFuZCBwbGVhc2UgY29ycmVjdCBtZSBpZiBJIGFtIHdyb25nLjoNCiJUaGUgY29u c3RyYWluZWQgY2xpZW50IHRvIGNvbnN0cmFpbmVkIHNlcnZlciBjYXNlIGlzIGNvbmNlcHR1YWxs eSBzaW1wbGVyIHRoYW4gdGhlIG90aGVyIGNhc2VzIHNpbmNlIHRoZSBhdXRob3JpemF0aW9uIHN0 ZXAsIGFzIHlvdSBub3RlZCwgYWxyZWFkeSBoYXBwZW5lZCBvdXQtb2YtYmFuZCAoYnkgc29tZW9u ZSkiIGFuZCAg4oCccGVybWFuZW50IGNsaWVudC1zZXJ2ZXIgcmVsYXRpb25zIG1heSBiZSB2aWV3 ZWQgYXMgYSBzcGVjaWFsIGNhc2Ugb2YgdGhlIGR5bmFtaWMgYWNjZXNzIHJpZ2h0cy4iDQoNCkkg YWdyZWUgd2l0aCB0aGlzIGFzc2Vzc21lbnQuIEhvd2V2ZXIsIGZvciBhIGxvdCBvZiBjb25zdHJh aW5lZCBkZXZpY2VzLCB0aGUgb25seSB1c2UgY2FzZSB0aGF0IGlzIGltcG9ydGFudCBpcyBwZXJt YW5lbnQgY2xpZW50LXNlcnZlciByZWxhdGlvbnMuIFNvLCBjb25zaWRlcmluZyB0aGUgcHJvcG9z YWwgdG8gdXNlIE9BdXRoIGRyYWZ0IGFzIHRoZSBzdGFydGluZyBwb2ludCBmb3IgdGhlIEFDRSBz b2x1dGlvbnMsIHRoZSBxdWVzdGlvbnMgZm9yIG1lIGFyZToNCg0KMSkgQ2FuIHdlIGp1ZGdlIGhv dyBtYW55IHVzZSBjYXNlcyB3ZSBoYXZlIGZvciBwZXJtYW5lbnQgY2xpZW50LXNlcnZlciByZWxh dGlvbnMgdnMgdGVtcG9yYXJ5IChkeW5hbWljKSBjbGllbnQgc2VydmVyIHJlbGF0aW9uc2hpcHMu IEZyb20gaG93IEkgc2VlIGl0LCB0aGUgcGVybWFuZW50IG9uZXMgYXJlIGEgbG90IG1vcmUgdXNl ZCBpbiBwcmFjdGljZSBmb3IgY29uc3RyYWluZWQgZGV2aWNlcy4NCg0KMikgRG8gd2Ugd2FudCB0 byBtYW5kYXRlLQ0KT3B0aW9uMTogdGhlIHVzZSBvZiBmdWxsIE9BdXRoIChjb25zdHJhaW5lZCBw cm9maWxlKSBmb3IgZXZlcnkgZGV2aWNlIG9yDQpPcHRpb24yOiB3aWxsIHdlIGhhdmUgYSBtZXRo b2QgdG8gc2F5IHRoYXQgYSBjb25zdHJhaW5lZCBzZXJ2ZXIgb3IgY2xpZW50IGlzIG9ubHkgZ29p bmcgdG8gc3VwcG9ydCBwZXJtYW5lbnQgbGlua3MgYW5kIG5vdCB0aGUgZnVsbCBPQXV0aCBjb25z dHJhaW5lZCBwcm9maWxlLg0KDQozKSBJZiB3ZSBjaG9vc2UgT3B0aW9uIDEgaW4gU3RlcCAyLCBj YW4gd2UgZ2V0IGFuIGVzdGltYXRlIG9mIGhvdyBtdWNoIG92ZXJoZWFkIGl0IGlzIGNvbXBhcmVk IHRvIE9wdGlvbiAxLiBUaGUgTFdNMk0gY29tcGFyaXNvbiBpcyByZWxldmFudCBoZXJlIHdoaWNo IGlzIG1vcmUgb3IgbGVzcyBvcHRpb24gMiB3aXRoIE9wdGlvbiAxIHN0aWxsIHBvc3NpYmxlIGJ1 dCBtYW5hZ2VkIHZpYSBhIHNpbmdsZSBjZW50cmFsIHNlcnZlci4NCg0KQWJoaW5hdg0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IEFjZSBbYWNlLWJv dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmFjZS1ib3VuY2VzQGlldGYub3JnPl0gb24gYmVoYWxmIG9m IEx1ZHdpZyBTZWl0eiBbbHVkd2lnQHNpY3Muc2U8bWFpbHRvOmx1ZHdpZ0BzaWNzLnNlPl0NClNl bnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAxOSwgMjAxNSAxMTozMiBBTQ0KVG86IGFjZUBpZXRmLm9y ZzxtYWlsdG86YWNlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtBY2VdIFtBQ0VdIFBlcm1hbmFu dCBjbGllbnQtc2VydmVyIHJlbGF0aW9ucyBhbmQgZHJhZnQtc2VpdHotYWNlLW9hdXRoLWF1dGh6 LTAwDQoNCk9uIDIwMTUtMTEtMTkgMTA6NTcsIEhhbm5lcyBUc2Nob2ZlbmlnIHdyb3RlOg0KPiBB cyBhbiBhZGQtb24gdG8gbXkgZW1haWwgZnJvbSB5ZXN0ZXJkYXkgSSB0aG91Z2h0IGl0IG1pZ2h0 IGJlIGFsc28NCj4gdXNlZnVsIHRvIGxvb2sgYXQgdGhlIExXTTJNIHByb3RvY29sIGFuZCB0byBz ZWUgd2hldGhlciBpdCBoZWxwcyBpbg0KPiB0aG9zZSBzY2VuYXJpb3MuIEkgd2FzIHRoaW5raW5n IGFib3V0IGRvaW5nIGEgdHV0b3JpYWwgYWJvdXQgTFdNMk0gdG8NCj4gdGhlIGdyb3VwIGZvciBh IGxpdHRsZSB3aGlsZSBhbHJlYWR5IGFuZCBtYXliZSBJIHNob3VsZCBnaXZlIGl0IGEgdHJ5IGlu DQo+IERlY2VtYmVyLg0KPg0KPiBDaWFvDQo+IEhhbm5lcw0KPg0KDQpJIHRoaW5rIGEgTFdNMk0g dHV0b3JpYWwgd291bGQgYmUgdmVyeSBoZWxwZnVsLiBQbGVhc2UgZG8gZ2l2ZSBpdCBhIHRyeS4N Cg0KL0x1ZHdpZw0KDQotLQ0KTHVkd2lnIFNlaXR6LCBQaEQNClNJQ1MgU3dlZGlzaCBJQ1QgQUIN CklkZW9uIFNjaWVuY2UgUGFyaw0KQnVpbGRpbmcgQmV0YSAyDQpTY2hlZWxldsOkZ2VuIDE3DQpT RS0yMjMgNzAgTHVuZA0KDQpQaG9uZSArNDYoMCk3MC0zNDkgOTIgNTENCmh0dHA6Ly93d3cuc2lj cy5zZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18gVGhlIGNvbnRlbnRzIG9mIHRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJl IGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LiBUaGV5IG1heSBub3QgYmUg ZGlzY2xvc2VkIHRvIG9yIHVzZWQgYnkgb3IgY29waWVkIGluIGFueSB3YXkgYnkgYW55b25lIG90 aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVudC4gSWYgdGhpcyBlLW1haWwgaXMgcmVjZWl2 ZWQgaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVs ZXRlIHRoZSBlLW1haWwgYW5kIGF0dGFjaGVkIGRvY3VtZW50cy4gUGxlYXNlIG5vdGUgdGhhdCBu ZWl0aGVyIHRoZSBzZW5kZXIgbm9yIHRoZSBzZW5kZXIncyBjb21wYW55IGFjY2VwdCBhbnkgcmVz cG9uc2liaWxpdHkgZm9yIHZpcnVzZXMgYW5kIGl0IGlzIHlvdXIgcmVzcG9uc2liaWxpdHkgdG8g c2NhbiBvciBvdGhlcndpc2UgY2hlY2sgdGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cy4N Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkFjZSBt YWlsaW5nIGxpc3QNCkFjZUBpZXRmLm9yZzxtYWlsdG86QWNlQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gVGhlIGNvbnRlbnRzIG9mIHRoaXMg ZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50LiBUaGV5IG1heSBub3QgYmUgZGlzY2xvc2VkIHRvIG9yIHVzZWQgYnkgb3Ig Y29waWVkIGluIGFueSB3YXkgYnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lw aWVudC4gSWYgdGhpcyBlLW1haWwgaXMgcmVjZWl2ZWQgaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlh dGVseSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoZSBlLW1haWwgYW5kIGF0dGFjaGVk IGRvY3VtZW50cy4gUGxlYXNlIG5vdGUgdGhhdCBuZWl0aGVyIHRoZSBzZW5kZXIgbm9yIHRoZSBz ZW5kZXIncyBjb21wYW55IGFjY2VwdCBhbnkgcmVzcG9uc2liaWxpdHkgZm9yIHZpcnVzZXMgYW5k IGl0IGlzIHlvdXIgcmVzcG9uc2liaWxpdHkgdG8gc2NhbiBvciBvdGhlcndpc2UgY2hlY2sgdGhp cyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cy4NCg== --_000_0E9A48AB39AF3547ACD28A6DE3E2906A0F1AE185ATBRAGMSX02itis_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5 Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCAyLjBjbSA3MC44NXB0O30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5IaSBTYW11ZWwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRo YW5rIHlvdSBmb3IgeW91ciBjb21tZW50cy4gUGxlYXNlIHNlZSBpbmxpbmUuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IHlvdSBt aWdodCBiZSByaWdodCwgSSB3b3VsZCBzYXkgdGhhdCBhbGwgYW5zd2VycyB0byB0aGlzIHdvdWxk IGp1c3QgYmUgbW9yZSBvciBsZXNzIHF1YWxpZmllZCBndWVzc2VzLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPltBU10gQWdyZWUuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4yLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SXQgaXMgc2xpZ2h0bHkgdW5jbGVhciB0byBtZSB3aGF0IHlvdSBtZWFuIGJ1dCBJwrRsbCB0cnkg dG8gZXhwbGFpbiBteSB1bmRlcnN0YW5kaW5nJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qIG9wdGlvbiBvbmUgd291bGQgYmUgdG8gdXNl IGFuIG9wdGltaXNlZCBPQXV0aDIgcHJvZmlsZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KiBvcHRpb24gdHdvIHdvdWxkIGJlIHByZS1wcm92aXNp b25lZCBrZXlzIHRvIGVzdGFibGlzaCBzZWN1cmUgbGlua3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgcHJlZmVyIG9wdGlvbiBvbmUgc2luY2Ug aXQgaW5jbHVkZXMgbWV0YWRhdGEgYXJvdW5kIHRoZSBrZXlzLCBpLmUuIGhvdyBhbmQgd2hlcmUg dG8gdXNlIHRoZSBrZXlzIGFuZCB0aGUgc2VydmVyIGNhbiBjb25uZWN0IHRoZW0gdG8gYW4gYXV0 aG9yaXNlZCBjbGllbnQuIEkgdGhpbmsgdGhpcyBpcyBpbmZvcm1hdGlvbiB0aGF0IHlvdSBtdXN0 IGhhdmUgaW4gc29tIHdheSBpbmRlcGVuZGVudCBvZiB0aGUgc29sdXRpb24sDQogaS5lLiB3aGVu IHlvdSBoYXZlIGFkZGVkIHRoaXMgdG8gb3B0aW9uIHR3byB5b3Ugd2lsbCBoYXZlIHRoZSBzYW1l IGFtb3VudCBvZiBtZXRhZGF0YSBtb3JlIG9yIGxlc3MgKGJ1dCBhbHNvIGFub3RoZXIgc3BlY2lm aWNhdGlvbikuJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0FTXSBJZGVhbGx5IHNwZWFr aW5nLCB3ZSBkbyBub3Qgd2FudCBhbm90aGVyIHNwZWNpZmljYXRpb24gYnV0IGFuIGFkZGl0aW9u IHRvIHRoZSBPQXV0aCBkb2N1bWVudC4gUmVmZXJyaW5nIHRvIEZpZ3VyZSAxIGluIHlvdXIgZG9j dW1lbnQsIGNhbiB3ZSBub3QgdGhpbmsNCiBvZiBzaW1wbGVyIGZsb3dzIHdoZXJlIHRoZSBhdXRo b3JpemF0aW9uIHNlcnZlciB3cml0ZXMgY2xpZW50IGNyZWRlbnRpYWxzIGRpcmVjdGx5IHRvIHRo ZSBSZXNvdXJjZSBzZXJ2ZXIgYW5kIHByb3ZpZGVzIGNsaWVudCBpbmZvcm1hdGlvbiB0byB0aGUg Y2xpZW50LiBTbywgdGhlIG9ubHkgc3RlcHMgdGhhdCBuZWVkIHRvIGJlIHBlcmZvcm1lZCBhcmUg RSwgQiwgQyBhbmQgRj8gSSBkbyBub3QgdGhpbmsgdGhlIHBlcm1hbmVudCBjbGllbnQgc2VydmVy DQogcm9sZXMgYXJlIGNvcm5lciBjYXNlcyB0byBjb25zaWRlciBhbmQgYXQgbGVhc3QgaW4gbXkg YXBwbGljYXRpb25zIChpbmRvb3IgcHJvZi4gbGlnaHRpbmcpLCBpdCBpcyB0aGUgbWFpbiB1c2Ug Y2FzZS4gTWF5YmUgaXQgd291bGQgaGVscCBpZiBJIGNvdWxkIGdldCBhIG1vcmUgZGV0YWlsZWQg ZGVzY3JpcHRpb24gb2YgaG93IHRoaXMgY2FzZSB3aWxsIGJlIGFkZHJlc3NlZCBpbiB0aGUgY3Vy cmVudCBkcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRoYXQgdGhlcmUgd2lsbCBiZSBubyBvciB2ZXJ5IGxpdHRs ZSBvdmVyaGVhZCBzaW5jZSBmcm9tIG15IGludGVycHJldGF0aW9uIHlvdSB3b3VsZCBuZWVkIHRv IGhhdmUgc29tIG1ldGFkYXRhIGFyb3VuZCBrZXlzIGluIG9wdGlvbjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZGluZyBMV00yTSBJ IHRoaW5rIGJ1dCBJwrRtIG5vdCBzdXJlIHRoYXQgSGFubmVzIHNlZXMgdGhhdCBpdCBjb3VsZCBi ZSB1c2VkIGZvciBwcm92aXNpb25pbmcgb2YgdGhlIHRydXN0IHJlbGF0aW9uc2hpcCB3aXRoIHRo ZSBBUyB0byBSUyAoaS5lLiBwdXNoaW5nIEFTIGtleSksIGFuZCBwb3NzaWJsZSBhbHNvIGZvciB0 aGUgcHJvdmlzaW9uaW5nIG9mIE9BdXRoMiB0b2tlbiBhbmQgY29ubmVjdGVkIGtleQ0KIHRvIHRo ZSBDbGllbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+QmVzdCBSZWdhcmRzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4vL1NhbXVlbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgTm92IDE5LCAyMDE1IGF0IDE6NDkgUE0s IFNvbWFyYWp1IEFiaGluYXYgJmx0OzxhIGhyZWY9Im1haWx0bzphYmhpbmF2LnNvbWFyYWp1QHRy aWRvbmljLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFiaGluYXYuc29tYXJhanVAdHJpZG9uaWMuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBI YW5uZXMsIEfDtnJhbiw8YnI+DQo8YnI+DQpJIHdpbGwgdHJ5IHRvIHN1bW1hcmllcyB5b3VyIHJl cGxpZXMgYW5kIHBsZWFzZSBjb3JyZWN0IG1lIGlmIEkgYW0gd3JvbmcuOjxicj4NCiZxdW90O1Ro ZSBjb25zdHJhaW5lZCBjbGllbnQgdG8gY29uc3RyYWluZWQgc2VydmVyIGNhc2UgaXMgY29uY2Vw dHVhbGx5IHNpbXBsZXIgdGhhbiB0aGUgb3RoZXIgY2FzZXMgc2luY2UgdGhlIGF1dGhvcml6YXRp b24gc3RlcCwgYXMgeW91IG5vdGVkLCBhbHJlYWR5IGhhcHBlbmVkIG91dC1vZi1iYW5kIChieSBz b21lb25lKSZxdW90OyBhbmQmbmJzcDsg4oCccGVybWFuZW50IGNsaWVudC1zZXJ2ZXIgcmVsYXRp b25zIG1heSBiZSB2aWV3ZWQgYXMgYSBzcGVjaWFsIGNhc2Ugb2YNCiB0aGUgZHluYW1pYyBhY2Nl c3MgcmlnaHRzLiZxdW90Ozxicj4NCjxicj4NCkkgYWdyZWUgd2l0aCB0aGlzIGFzc2Vzc21lbnQu IEhvd2V2ZXIsIGZvciBhIGxvdCBvZiBjb25zdHJhaW5lZCBkZXZpY2VzLCB0aGUgb25seSB1c2Ug Y2FzZSB0aGF0IGlzIGltcG9ydGFudCBpcyBwZXJtYW5lbnQgY2xpZW50LXNlcnZlciByZWxhdGlv bnMuIFNvLCBjb25zaWRlcmluZyB0aGUgcHJvcG9zYWwgdG8gdXNlIE9BdXRoIGRyYWZ0IGFzIHRo ZSBzdGFydGluZyBwb2ludCBmb3IgdGhlIEFDRSBzb2x1dGlvbnMsIHRoZSBxdWVzdGlvbnMgZm9y DQogbWUgYXJlOjxicj4NCjxicj4NCjEpIENhbiB3ZSBqdWRnZSBob3cgbWFueSB1c2UgY2FzZXMg d2UgaGF2ZSBmb3IgcGVybWFuZW50IGNsaWVudC1zZXJ2ZXIgcmVsYXRpb25zIHZzIHRlbXBvcmFy eSAoZHluYW1pYykgY2xpZW50IHNlcnZlciByZWxhdGlvbnNoaXBzLiBGcm9tIGhvdyBJIHNlZSBp dCwgdGhlIHBlcm1hbmVudCBvbmVzIGFyZSBhIGxvdCBtb3JlIHVzZWQgaW4gcHJhY3RpY2UgZm9y IGNvbnN0cmFpbmVkIGRldmljZXMuPGJyPg0KPGJyPg0KMikgRG8gd2Ugd2FudCB0byBtYW5kYXRl LTxicj4NCk9wdGlvbjE6IHRoZSB1c2Ugb2YgZnVsbCBPQXV0aCAoY29uc3RyYWluZWQgcHJvZmls ZSkgZm9yIGV2ZXJ5IGRldmljZSBvcjxicj4NCk9wdGlvbjI6IHdpbGwgd2UgaGF2ZSBhIG1ldGhv ZCB0byBzYXkgdGhhdCBhIGNvbnN0cmFpbmVkIHNlcnZlciBvciBjbGllbnQgaXMgb25seSBnb2lu ZyB0byBzdXBwb3J0IHBlcm1hbmVudCBsaW5rcyBhbmQgbm90IHRoZSBmdWxsIE9BdXRoIGNvbnN0 cmFpbmVkIHByb2ZpbGUuPGJyPg0KPGJyPg0KMykgSWYgd2UgY2hvb3NlIE9wdGlvbiAxIGluIFN0 ZXAgMiwgY2FuIHdlIGdldCBhbiBlc3RpbWF0ZSBvZiBob3cgbXVjaCBvdmVyaGVhZCBpdCBpcyBj b21wYXJlZCB0byBPcHRpb24gMS4gVGhlIExXTTJNIGNvbXBhcmlzb24gaXMgcmVsZXZhbnQgaGVy ZSB3aGljaCBpcyBtb3JlIG9yIGxlc3Mgb3B0aW9uIDIgd2l0aCBPcHRpb24gMSBzdGlsbCBwb3Nz aWJsZSBidXQgbWFuYWdlZCB2aWEgYSBzaW5nbGUgY2VudHJhbCBzZXJ2ZXIuPGJyPg0KPGJyPg0K QWJoaW5hdjxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpGcm9tOiBBY2UgWzxhIGhyZWY9Im1haWx0bzphY2UtYm91bmNlc0BpZXRm Lm9yZyI+YWNlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBvbiBiZWhhbGYgb2YgTHVkd2lnIFNlaXR6 IFs8YSBocmVmPSJtYWlsdG86bHVkd2lnQHNpY3Muc2UiPmx1ZHdpZ0BzaWNzLnNlPC9hPl08YnI+ DQpTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMTksIDIwMTUgMTE6MzIgQU08YnI+DQpUbzogPGEg aHJlZj0ibWFpbHRvOmFjZUBpZXRmLm9yZyI+YWNlQGlldGYub3JnPC9hPjxicj4NClN1YmplY3Q6 IFJlOiBbQWNlXSBbQUNFXSBQZXJtYW5hbnQgY2xpZW50LXNlcnZlciByZWxhdGlvbnMgYW5kIGRy YWZ0LXNlaXR6LWFjZS1vYXV0aC1hdXRoei0wMDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4N Ck9uIDIwMTUtMTEtMTkgMTA6NTcsIEhhbm5lcyBUc2Nob2ZlbmlnIHdyb3RlOjxicj4NCiZndDsg QXMgYW4gYWRkLW9uIHRvIG15IGVtYWlsIGZyb20geWVzdGVyZGF5IEkgdGhvdWdodCBpdCBtaWdo dCBiZSBhbHNvPGJyPg0KJmd0OyB1c2VmdWwgdG8gbG9vayBhdCB0aGUgTFdNMk0gcHJvdG9jb2wg YW5kIHRvIHNlZSB3aGV0aGVyIGl0IGhlbHBzIGluPGJyPg0KJmd0OyB0aG9zZSBzY2VuYXJpb3Mu IEkgd2FzIHRoaW5raW5nIGFib3V0IGRvaW5nIGEgdHV0b3JpYWwgYWJvdXQgTFdNMk0gdG88YnI+ DQomZ3Q7IHRoZSBncm91cCBmb3IgYSBsaXR0bGUgd2hpbGUgYWxyZWFkeSBhbmQgbWF5YmUgSSBz aG91bGQgZ2l2ZSBpdCBhIHRyeSBpbjxicj4NCiZndDsgRGVjZW1iZXIuPGJyPg0KJmd0Ozxicj4N CiZndDsgQ2lhbzxicj4NCiZndDsgSGFubmVzPGJyPg0KJmd0Ozxicj4NCjxicj4NCkkgdGhpbmsg YSBMV00yTSB0dXRvcmlhbCB3b3VsZCBiZSB2ZXJ5IGhlbHBmdWwuIFBsZWFzZSBkbyBnaXZlIGl0 IGEgdHJ5Ljxicj4NCjxicj4NCi9MdWR3aWc8YnI+DQo8YnI+DQotLTxicj4NCkx1ZHdpZyBTZWl0 eiwgUGhEPGJyPg0KU0lDUyBTd2VkaXNoIElDVCBBQjxicj4NCklkZW9uIFNjaWVuY2UgUGFyazxi cj4NCkJ1aWxkaW5nIEJldGEgMjxicj4NClNjaGVlbGV2w6RnZW4gMTc8YnI+DQpTRS0yMjMgNzAg THVuZDxicj4NCjxicj4NClBob25lICYjNDM7NDYoMCk3MC0zNDkgOTIgNTE8YnI+DQo8YSBocmVm PSJodHRwOi8vd3d3LnNpY3Muc2UiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LnNpY3Muc2U8 L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18g VGhlIGNvbnRlbnRzIG9mIHRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZp ZGVudGlhbCB0byB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LiBUaGV5IG1heSBub3QgYmUgZGlzY2xv c2VkIHRvIG9yIHVzZWQgYnkgb3IgY29waWVkIGluIGFueSB3YXkgYnkgYW55b25lIG90aGVyIHRo YW4gdGhlIGludGVuZGVkDQogcmVjaXBpZW50LiBJZiB0aGlzIGUtbWFpbCBpcyByZWNlaXZlZCBp biBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUg dGhlIGUtbWFpbCBhbmQgYXR0YWNoZWQgZG9jdW1lbnRzLiBQbGVhc2Ugbm90ZSB0aGF0IG5laXRo ZXIgdGhlIHNlbmRlciBub3IgdGhlIHNlbmRlcidzIGNvbXBhbnkgYWNjZXB0IGFueSByZXNwb25z aWJpbGl0eSBmb3IgdmlydXNlcyBhbmQgaXQgaXMgeW91ciByZXNwb25zaWJpbGl0eQ0KIHRvIHNj YW4gb3Igb3RoZXJ3aXNlIGNoZWNrIHRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMuPGJy Pg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpBY2UgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkFjZUBpZXRmLm9yZyI+ QWNlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vYWNlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9hY2U8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIFRoZSBjb250 ZW50cyBvZiB0aGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwg dG8gdGhlIGludGVuZGVkIHJlY2lwaWVudC4gVGhleSBtYXkgbm90IGJlIGRpc2Nsb3NlZCB0byBv ciB1c2VkIGJ5IG9yIGNvcGllZCBpbiBhbnkgd2F5IGJ5IGFueW9uZSBvdGhlciB0aGFuIHRoZSBp bnRlbmRlZCByZWNpcGllbnQuIElmDQogdGhpcyBlLW1haWwgaXMgcmVjZWl2ZWQgaW4gZXJyb3Is IHBsZWFzZSBpbW1lZGlhdGVseSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoZSBlLW1h aWwgYW5kIGF0dGFjaGVkIGRvY3VtZW50cy4gUGxlYXNlIG5vdGUgdGhhdCBuZWl0aGVyIHRoZSBz ZW5kZXIgbm9yIHRoZSBzZW5kZXIncyBjb21wYW55IGFjY2VwdCBhbnkgcmVzcG9uc2liaWxpdHkg Zm9yIHZpcnVzZXMgYW5kIGl0IGlzIHlvdXIgcmVzcG9uc2liaWxpdHkgdG8gc2NhbiBvcg0KIG90 aGVyd2lzZSBjaGVjayB0aGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzLg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_0E9A48AB39AF3547ACD28A6DE3E2906A0F1AE185ATBRAGMSX02itis_-- From nobody Mon Nov 23 02:11: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 27D211A876C for ; Mon, 23 Nov 2015 02:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eT2BxBNKi8sf for ; Mon, 23 Nov 2015 02:11:17 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF1101A876B for ; Mon, 23 Nov 2015 02:11:16 -0800 (PST) Received: by lbblt2 with SMTP id lt2so93064692lbb.3 for ; Mon, 23 Nov 2015 02:11:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=SZ2JwdORKHAhF1x6G7JixMciABiIVUsBeJoqDrDFaDY=; b=yrbV8ZDUqcjr7OBNh3574Iko7CTnF/sVeMwFJVdAKG+ekSs3nOU9GgpKKHRNrfiEh9 J72hu14F8J/c7Mk/YsUP4nIERFs7n0In3Zunv/vbWJPC0S24r2S2eJAeBHa8PasR56P8 4urthoPTtOyi5tPCXp+aBtBohwrXo1aLjQuN1mSHSIReIp1lyPodg0lUUPd0vEXlD6Xz 3xfGArNYDboV8A/MluXkn1P1hqlt9L7UtLnC7AQb+WkN8CMsBuj8WjYmwpatOvH9qiFZ ePn9uK5g00nja4GQJjxmt2NiKYWt4cFiKv6rcp2sUN53YYlJVakKk0HTzHX6VlvdUQkP 5lkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=SZ2JwdORKHAhF1x6G7JixMciABiIVUsBeJoqDrDFaDY=; b=UtCWcXZwtbTM7TryPasOxb3CMlCOt/PnIpBpBN7OWi/8+PM1KFxpDZHvHSYfdMWfMs 6pMGFAnClBRBivQSI8zDNmZymfInQ853x8/7OCEAslSsQKXsuwOXA7GFFrRSJBpe0H9z dFdXos743vYPboGPpoosUpghk1G6nVdcXfP5nbG0Y6qB9zt2qObFlHse6r9j00DO7iaC ehhZ0ceOa8bTgyPtw0ZMII3GrR1O2w3OcYuh1xDO4khPcFNGBxznelcQcDwuvB0cnq3i lgQrq0xLLw+I31hLhgcd+WuJ/vObsNY5CQshqJNdPpTSrAoNDNHpA++qpkVMUrt4IgL9 /h7A== X-Gm-Message-State: ALoCoQkDIKQiArscALm6Qe+pd0voEKcIw7w03O9FxiS7Uwmbw7bUeVgYI7la+kleqesRrpeg+US1 X-Received: by 10.112.130.195 with SMTP id og3mr8781955lbb.69.1448273475003; Mon, 23 Nov 2015 02:11:15 -0800 (PST) Received: from [192.168.0.108] ([85.235.10.186]) by smtp.gmail.com with ESMTPSA id li2sm1681571lbc.37.2015.11.23.02.11.13 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Nov 2015 02:11:13 -0800 (PST) To: ace@ietf.org References: From: Ludwig Seitz Message-ID: <5652E641.5030708@sics.se> Date: Mon, 23 Nov 2015 11:11:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030809070205010606030006" Archived-At: Subject: Re: [Ace] Solution direction X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Nov 2015 10:11:19 -0000 This is a cryptographically signed message in MIME format. --------------ms030809070205010606030006 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 2015-11-22 12:32, Kepeng Li wrote: [...] > My recommendation is to ask the authors to make updates for the draft > according to the review comments, to have a more mature verion for the > working group to work on. > > Thanks, > > Kind Regards > Kepeng (as ACE co-chair) > We are currently working on the comments provided by Madjid, Rafa,=20 Thomas, Renzo and Abhinav. Any further comments are most welcome. /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 --------------ms030809070205010606030006 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DFQwggYYMIIFAKADAgECAgMMhpgwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTAxMDgwODM5MDZaFw0xNjAxMDkyMjQxMzBaMDgxFzAV BgNVBAMMDmx1ZHdpZ0BzaWNzLnNlMR0wGwYJKoZIhvcNAQkBFg5sdWR3aWdAc2ljcy5zZTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVB4rAuq4FxbARxwRqPLpc/3C194F+V H4XMKK6fu3Y8zDLijzNSjh6tG41oZhXvJcvAs1nZNjUutNLeyBAUFiYhy7HXNdlKpjbMEFKQ +6KpEdZ0Rk+pXgB2E1mqZEfp3M2djcQ/h+7uGVlSGYNAxYk6rWPIIWBx2GMvAQaHP4xxu/F+ PiSQILOVzmtIFZe1t/Lw71aaNeMYVhARo8z5PVsVoq6gBeujxfiRLtiQ/S8xW6RKvNvUkVyT BQfcKaEDZR9FENNf9rFgiAcT6R7hI8RBf1d2fxdlbDU8uM72K3fvzGDt8N9Bfm1kDWbDBxJE 1taRIYs+60D1kwV6DvBb9MECAwEAAaOCAtQwggLQMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6ryrKahJtBOEdbIL AAWCpOsQyagwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwGQYDVR0RBBIwEIEO bHVkd2lnQHNpY3Muc2UwggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYB BQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqBvlRo aXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDEgVmFs aWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUg cmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEF BQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEvY2xpZW50L2NhMEIG CCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNs aWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqG SIb3DQEBBQUAA4IBAQBl8BbG0n7+JjFqiJOuAqMbkeqM6Oyd+4oHGu3fbaSiM1SKesae2bfm vifV99a+M4DERZ2SVkOYcvNlv31Q3hvYtzRjDOqewzVKxo021R3ddQULW1DhvTEpclikG5rd 0NRJQn+EkSwEKLeUj68i0dhU8ULhZDDq3A81cTcZzIGrTjNnwDvCktB/sF/iO4At6RJ24P3j KjYFPirW3NsvZ2gzZizSzeubPE0/cWcqEBJ/UtaFPF54efejjLuPRHHMLPDcvrwBhEiBxuG6 oTEo465g4pS9Vo/Z0GoZgZyA+aGQ+YPbPSsqsYmSBjZ6MGGDqQq0niE2dW+8IOdHQvMkqI52 MIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcN MDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxwmDzM4t2BqxKaQu E6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESip7vMz39ScLpNLbL1QpOlPW/t FIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9ftTyhxvxWkf8KW37iKrueKsxw 2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsWoTb7q8hmgv6Nv3Hg9rmA1/VP BIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/43Yksq60jExipA4l5uv9/+Hm 33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IBrTCCAakwDwYDVR0TAQH/BAUw AwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8G A1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsGAQUFBwEBBFowWDAnBggrBgEF BQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0GCCsGAQUFBzAChiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQwUjAnoCWgI4YhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcBAgEwZjAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDov L3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjANBgkqhkiG9w0BAQUFAAOCAgEA CoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHbWNaPeQn3oBSU8KgQZn/Kck1J xbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4OxK9QPoSjCMxM3HbkZCDJgnl E8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0KAkXCzeQNLeA5LlYUzFyM7kP Ap8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL04qYK/zu+Qg1Bw0RwgigVZs/0 c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0IFiNu9IPuTGAPBn4CPxD0+Ru 8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6fDEPme+1Nbi+03pVjuZQKbGw KJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVtjYsv0L1TSm2+NwON58tO+pIV zu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm48ZCYfAWLb/Xj7F5JQMbZvCex glAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BIXRsF1du4qESm4/3CKuyUV7p9 DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJ bnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJYIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MTEyMzEwMTExM1owLwYJKoZI hvcNAQkEMSIEIBnkI8ghxZMyGErYGoYAOmTdxxV9DKv9zBt3mH0NrxjtMGwGCSqGSIb3DQEJ DzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQB gjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwgacG CyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC AwyGmDANBgkqhkiG9w0BAQEFAASCAQBMiDnMgazo5GN7W1Hw3GFXe5f6eX7NIWMFGPaH0g6p sQgLfY0gMTPGzaKCOGsIgkOf1Eu98PsBoZ/SBS/jd/ZGbRW3K3j1vMNs6CmTV+FbHrZghZkj J+JMvxyrKaQUbjuPZA8ZRIpEA1kogYNThwI7a/Dg6qmX28itQPnfZ34bNs0emhroWx+9E57k Lebz9l1TXe3CehipVIJvq/tHoFRgxI+q6wIo1zBPLrShsBNiC058DrBMJ8E5DOw7oQzkpp/h ixr3DV2vCssy5zVMzd2yO1eAIGtfNS8vsDUMsHFVXId1JZVyn9OkDTGIutsud1pViOw/Nchx /DuJ8/xnV5KAAAAAAAAA --------------ms030809070205010606030006-- From nobody Mon Nov 23 12:44:45 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F16B1B3A84 for ; Mon, 23 Nov 2015 12:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.185 X-Spam-Level: X-Spam-Status: No, score=-3.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585, 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 ejlUGBmjQfM1 for ; Mon, 23 Nov 2015 12:44:41 -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 624F81B3A85 for ; Mon, 23 Nov 2015 12:44:41 -0800 (PST) Received: from [192.168.10.143] ([80.92.121.34]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MN1j6-1Zyjz03DnU-006edJ; Mon, 23 Nov 2015 21:44:35 +0100 To: "Ace@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56537AAF.3010008@gmx.net> Date: Mon, 23 Nov 2015 21:44:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lwaSENNkoNO5vHoRWJtOkjsqqDN1AMKjx" X-Provags-ID: V03:K0:RbVCrK17DNgrbgcdd8u2FJAOK9s/GoXvQ44ou/AQ/I/LAMgO4lt Ms41QvnF4DpZ6U5FX1U8yi9QwHw31EtG0zD7gn64BDjn6SxXMRSs1MlnfMTKEuGgboVMGYo 79XMVyVG6g2HHAOcjpPcuNJYe+TPcsCxI8CNUM2YwK5SRoB9h9PfZq87X0JbHp10XWThpup vnfW4WbmGMyyF0wX3eQWA== X-UI-Out-Filterresults: notjunk:1;V01:K0:A/WkKCgt3Fc=:JtjvEtjnF8dK1/d/zXBWj5 4tYftCBHEgm+0tO+WqnCKw2r9qB0L52Hb0HU18eK8nzfmEp6eCxnn7K5RNzpm1xkgyvViuAtH oFIlm7UYawijfPaNZIO799b/aohVVuVDBNC9xInKTgIye1CbhVEImruzVdgvj+jgdd7qRUU0f wEVhH2boM49JWJC55c6iYHu2tq6WqI+7LzgktekC7xWc21vksQ4Y/XVyMGSwGIArBY+S3D4Lm Ejlz15RFM1FfEj9hNbcVhtBziuC3Dj8YFkfk0eu0ziW4pr6blp2UrIsTTuZks7uqAybGi31Ec DZ4yMAbCOh+23rGt5mAnCJJN0c3i2MQj478StWULXoNNxvyKYWnv0LDvKIZfaHydfZWnRCzBI fCEzm5ATC5nvwBdsirSWbiL3Llwbxud0uiJPvqixptTJvJtD/o/ibLj1f5FqHBSqugQOar2kJ QZBJu9JRqlPn/ziNSbqojk48N/rqpgfMSAbShUoqg/qW1VTaqqVIkTPs9AWf7+mR2YSsbarPL g7OjmnBxP6NgTAxAkeQblkdj4kidx2n6h81ZdddFXAln3lRj2j7l5RIDU3jeuTv7DQ+rI2U7g DYQIViaFCKKGTEcd7ThP+UXhtYx773h73f5XZBHk5DYfVJr5kHT/mNuuLqT39zIMGc1l7RbZN cdPEX9sBefVJH2uQ8QWqvb5/9R9cUlx+UL92bkJByFDi9aAqtwV5cseb9XX6zxN4NHS9qIpca G++NHicWtRVI441MVeaM2LywP4mHPO+UEojzOpyi5VPrQktHoEOdMDjUGuc= Archived-At: Cc: SLemay@zebra.com Subject: [Ace] LWM2M Tutorial -- Tuesday, 15 December 2015, 6am PST X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Nov 2015 20:44:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lwaSENNkoNO5vHoRWJtOkjsqqDN1AMKjx Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, the Lightweight Machine-to-Machine (LWM2M) specification developed by the Open Mobile Alliance (OMA) was mentioned several times already and so I thought it would be useful to have a short tutorial session. The LWM2M specification has been around for a little while already and is currently being updated to reflect community feedback and insight gained during the interoperability test events. The presentation will be given by Simon Lemay and myself. In a discussion with Kepeng we decided to pick the Tuesday, 15 December 2015, 6am PST http://www.timeanddate.com/worldclock/meetingdetails.html?year=3D2015&mon= th=3D12&day=3D15&hour=3D14&min=3D0&sec=3D0&p1=3D1889&p2=3D33&p3=3D137 In case you are unable to attend, we will enable recording so that you can watch the talk later. The length of the tutorial (+discussion) will be around 1 hour. Ciao Hannes & Kepeng --lwaSENNkoNO5vHoRWJtOkjsqqDN1AMKjx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWU3qwAAoJEGhJURNOOiAtkXYH/RX235oKu6gdUSeESsU0GDbu V/qawutB0nd8IczGas9/dIl9rQSUfge5rkvzQYWKD8tkGNrilqIW9Jb5uI6mr3KT zDkxKHi9Az1HGFDxc1YnXFRvSbAamR/8fYc5xMuIyuZ3IGk2Ddf/aBJBWXL7jwYg AEIWGpOo4BXLvVo09UagnQ7WlSJ6BejNiY2NWWlQnTOLv3jICsQwwp+eedpI38AX 85oBBFOVoZ4vSH93lIFnxhklFKEslFaFP9slaQ2iMkJBnR/46tXCtMmb5Hoip2xc GA9KHyqMt68h4vRyUrmD4rwiUu9zUpuJIBIQ7sGhtNw/OPvkF8qqBOOjYUgLe0o= =iPU9 -----END PGP SIGNATURE----- --lwaSENNkoNO5vHoRWJtOkjsqqDN1AMKjx--