From nobody Sun Feb 1 23:52:23 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6831A930A for ; Sun, 1 Feb 2015 23:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-WyI1yBjzaG for ; Sun, 1 Feb 2015 23:52:12 -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 8DFB51ABB19 for ; Sun, 1 Feb 2015 23:52:11 -0800 (PST) X-AuditID: c1b4fb30-f79106d000001184-d3-54cf2ca9b766 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 7C.56.04484.9AC2FC45; Mon, 2 Feb 2015 08:52:09 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.13]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0210.002; Mon, 2 Feb 2015 08:52:09 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Stefanie Gerdes , "gerdes@tzi.de" Thread-Topic: [Ace] Role terminology in use case draft (Was: Container Use Case) Thread-Index: AQHQNW8OY2BIXPo9OU6z1ZDeRGr/mZzLy0+AgAGzfACABJpLgIAAUqcAgATuewCAAYLXgIAEMlwA Date: Mon, 2 Feb 2015 07:52:09 +0000 Message-ID: References: <54BF9029.4060200@tzi.de> <54C22C2C.9050709@tzi.de> <54C64DEE.3040608@tzi.de> <54CBB57B.7050207@informatik.uni-bremen.de> In-Reply-To: <54CBB57B.7050207@informatik.uni-bremen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-ID: <7E763387D33D3C44A17EF34841EF5890@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUyM+Jvje5KnfMhBmvbzS2+f+thtti35CWb xcaLdxkdmD2WLPnJ5PH9eb7HtrdfmQOYo7hsUlJzMstSi/TtErgyZvccZypY9pixonXtL+YG xj13GbsYOTkkBEwkTj97zAxhi0lcuLeerYuRi0NI4AijxL93rxghnEWMEu2d38Gq2ARcJB40 PGICsUUEIiQOT33FBmIzCyhK7J51lh3EFhYIlGg69JgNoiZIYv6DbkYIO0ri/PsGoBoODhYB FYm5vSogYV4BC4mP/44yQ+w6yCTR1rAQbBcnUOLcljawmYxA130/tYYJYpe4xK0n85kgrhaQ WLLnPNQHohIvH/9jBbFFBfQkVl5vYoOIK0ksuv2ZCWQvs4CmxPpd+hBjrCWWTDrBCHP+lO6H 7BD3CEqcnPmEZQKjxCwk22YhdM9C0j0LSfcsJN0LGFlXMYoWpxYn5aYbGemlFmUmFxfn5+nl pZZsYgTG5sEtvw12ML587niIUYCDUYmHt0DhfIgQa2JZcWXuIUZpDhYlcV4740MhQgLpiSWp 2ampBalF8UWlOanFhxiZODilGhh5Su0smqacSOO55/TV7apD7dI54T9lvHfH/lwwgcNWcLlg vYhnrPEuH81Fi9I4aoJfrgzZveWwbN6eO9MnHWnv3HTrseaRnKSdsZ5OHrPsFaTmFb/96f01 S/9U6/vteX6zSt/O32okf+XV41trHvEXuLl3vRCYYvNz465OExvJJT86n7cXtnsqsRRnJBpq MRcVJwIADf2JqK4CAAA= Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Role terminology in use case draft (Was: Container Use Case) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Feb 2015 07:52:18 -0000 SGkgU3RlZmZpLA0KDQpPSywgSeKAmWxsIHdhaXQgd2l0aCBmdXJ0aGVyIGNvbW1lbnRzIHVudGls IHRoZSBuZXh0IHVwZGF0ZSB0aGVuLg0KDQpCZXN0IHJlZ2FyZHMNCkfDtnJhbg0KDQpPbiAyMDE1 LTAxLTMwIDE3OjQ2LCAiU3RlZmFuaWUgR2VyZGVzIiA8Z2VyZGVzQGluZm9ybWF0aWsudW5pLWJy ZW1lbi5kZT4NCndyb3RlOg0KDQo+SGkgR8O2cmFuLA0KPg0KPldlIGFyZSBjdXJyZW50bHkgcHJl cGFyaW5nIGFuIHVwZGF0ZSBvZiB0aGUgdXNlIGNhc2VzIGRyYWZ0IHRoYXQNCj5ob3BlZnVsbHkg d2lsbCBhZGRyZXNzIHNvbWUgb2YgdGhlIGlzc3VlcyB3ZSBkaXNjdXNzZWQgZWFybGllci4NCj4N Cj5PbiAwMS8yOS8yMDE1IDA1OjQyIFBNLCBHw7ZyYW4gU2VsYW5kZXIgd3JvdGU6DQo+PiBIaSBT dGVmZmkNCj4+DQo+PiBJbiBzdW1tYXJ5LCBJIHRoaW5rIGl0IGlzIGFuIGlzc3VlIHRoYXQgdGhl IGF1dGhvcml6YXRpb24gcHJvYmxlbQ0KPj4gZm9ybXVsYXRpb25zIGluIHRoZSB1c2UgY2FzZSBk b2N1bWVudCBkb2VzIG5vdCB0YWtlIGludG8gYWNjb3VudCB0aGUgYQ0KPj4gcHJpb3JpIGRpZmZl cmVuY2UgYmV0d2VlbiBwcm92aWRpbmcgYWNjZXNzIHRvIHNlbnNvciBtZWFzdXJlbWVudHMgdnMN Cj4+IGFjY2Vzc2luZyBhIHNlbnNvciBtZWFzdXJlbWVudC4gT3IgcHJvdmlkaW5nIGFjY2VzcyB0 byBhbiBhY3R1YXRvcg0KPj5zZXJ2aWNlDQo+PiB2cyBhY2Nlc3NpbmcgYW4gYWN0dWF0b3Igc2Vy dmljZS4gRm9yIGV4YW1wbGUsIHRoZSBhdXRob3JpemF0aW9uIHByb2JsZW0NCj4+IG9mIG9wZW5p bmcgYSBsb2NrIG9uIGEgc3BlY2lmaWMgcmVxdWVzdCBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgcHJv YmxlbSBvZg0KPj4gbWFraW5nIHN1cmUgdGhhdCBpdCBpcyB0aGUgcmlnaHQgbG9jayB0byBvcGVu LiBPciByZXZlYWxpbmcgdG8gdGhlIGxvY2sNCj4+IHRoYXQgeW91IGludGVuZCB0byBvcGVuIGl0 LiBPciB3aGF0IGV4YWN0bHkgaXMgdGhlIHJlbGV2YW50IHByb2JsZW0gb24NCj4+dGhlDQo+PiBh Y2Nlc3Npbmcgc2lkZT8gVGhpcyB3b3VsZCBiZSBnb29kIHRvIGNsYXJpZnkgaW4gdGhlIHVzZSBj YXNlIGRvY3VtZW50Lg0KPg0KPklmIHRoZXJlIGlzIGEgcHJvYmxlbSBtaXNzaW5nIGZyb20gdGhl IHVzZSBjYXNlcywgcGxlYXNlIHByb3ZpZGUgZGV0YWlscw0KPmFib3V0IHRoaXMgcHJvYmxlbSBz byB0aGF0IHdlIGNhbiBhZGQgaXQuIEZvciB5b3VyIGxvY2sgZXhhbXBsZSwgd2UNCj5taWdodCBh ZGQgdG8gdGhlIGhvbWUgYXV0b21hdGlvbiB1c2UgY2FzZSB0aGF0IHRoZSBzbWFydHBob25lIG9m IEFsaWNlJ3MNCj5wYXJlbnRzIG5lZWRzIHRvIG1ha2Ugc3VyZSB0aGF0IGl0IGlzIGNvbW11bmlj YXRpbmcgd2l0aCB0aGUgcmlnaHQgbG9jay4NCj5JcyB0aGF0IHdoYXQgeW91IGFyZSBhaW1pbmcg YXQ/DQo+DQo+PiBUaGVyZSBtYXkgYmUgZGlmZmVyZW50IHNvbHV0aW9ucyB0byB0aGUgcHJvYmxl bSBvZiB0aGUgcHJvdmlkaW5nIHNpZGUNCj4+YW5kDQo+PiB0aGUgcHJvYmxlbSBvbiB0aGUgYWNj ZXNzaW5nIHNpZGUuIE9yIG1heWJlIHRoZSBzYW1lIHN0YW5kYXJkaXplZA0KPj5zb2x1dGlvbg0K Pj4gY2FuIGJlIGFwcGxpZWQgaW4gdHdvIGluc3RhbmNlcz8gVG8gdW5kZXJzdGFuZCB0aGF0IHdl IGFsc28gbmVlZCB0bw0KPj4gZm9ybXVsYXRlIHRoZSBwcm9ibGVtcy4NCj4+DQo+PiBGdXJ0aGVy bW9yZSwgSSB0aGluayBpdCBpcyBhbiBpc3N1ZSB3aXRoIGEgdGVybWlub2xvZ3kgd2hpY2ggZG9l cyBub3QNCj4+IGFsbG93IHRoZXNlIGRpc3RpbmN0aW9ucyB0byBiZSBtYWRlIHNvIHRoYXQgdGhl IGRpZmZlcmVudCBwcm9ibGVtcyBjYW4NCj4+YmUNCj4+IGZvcm11bGF0ZWQuIEkgdGhpbmsgb25l IHBhcnQgb2YgdGhlIHRlcm1pbm9sb2d5IHByb2JsZW0gaXMgdGhhdCB0aGUgdGVybQ0KPj4g4oCc cmVzb3VyY2XigJ0gaXMgb3ZlcmxvYWRlZC4gRm9yIGV4YW1wbGUsIHJlc291cmNlIGlzIHVzZWQg KGEpIGluIHRoZQ0KPj4gUkVTVC9Db0FQIG1lYW5pbmcgd2hhdCBpcyByZXF1ZXN0ZWQgb24gdGhl IHNlcnZlciBzaWRlIGFuZCAoYikgIGFzIOKAnGl0ZW0NCj4+IG9mIGludGVyZXN04oCdLCB3aGlj aCBjb3VsZCBiZSBhbnl0aGluZyBvbiBib3RoIHJlcXVlc3RpbmcgYW5kIHJlc3BvbmRpbmcNCj4+ IHNpZGUuIFNpbmNlIHRoZSBleGlzdGluZyBhdXRob3JpemF0aW9uIGZyYW1ld29ya3Mgc3VjaCBh cyBPQXV0aCBhbmQgVU1BDQo+PiBoYXMgYSBidWlsdCBpbiBhc3ltbWV0cnkgYmV0d2VlbiBhdXRo b3JpemluZyBwYXJ0eSBhbmQgcmVxdWVzdGluZyBwYXJ0eSwNCj4+IHRoZSBidXJkZW4gb2YgcHJv b2YgZGV2aWF0aW5nIGZyb20gdGhhdCByZXN0cyB3aXRoIHRoZSBhdXRob3JzIG9mIHRoaXMNCj4+ IGRyYWZ0LiBJdCBjb3VsZCBiZSBhIGNvbmNsdXNpb24gb2YgdGhlIHVzZSBjYXNlIGRyYWZ0IHRo YXQgdGhpcyBpcyBhDQo+PiBzeW1tZXRyaWMgcHJvYmxlbSwgYW5kIHRoYXQgdGhlIHByb2JsZW1z IG9uIGVhY2ggc2lkZSBpcyBvZiBlcXVhbA0KPj4gaW1wb3J0YW5jZS4gSXQgc2hvdWxkIG5vdCBi ZSBhbiBhc3N1bXB0aW9uLg0KPg0KPkFzIGZhciBhcyBJJ20gYXdhcmUgb2YsIHRoZSB1c2UgY2Fz ZXMgZHJhZnQgdXNlcyB0aGUgUkVTVCBkZWZpbml0aW9uIG9mDQo+dGhlIHRlcm0gInJlc291cmNl Ii4gSSBkaWRuJ3Qgc2VlIGV2aWRlbmNlIHRoYXQgaXQgaXMgdXNlZCBpbmNvcnJlY3RseS4NCj5C dXQgaWYgSSBtaXNzZWQgc29tZXRoaW5nLCBwbGVhc2UgcG9pbnQgbWUgdG8gdGhlIHJlc3BlY3Rp dmUgc2VjdGlvbi4NCj4NCj5JIHRoaW5rIFJGQzcyNTIgdXNlcyB0aGUgdGVybSAicmVzb3VyY2Ug cmVwcmVzZW50YXRpb24iIHRvIHJlZmVyIHRvIGENCj5jb3B5IG9mIHRoZSBkYXRhIG9mIGEgcmVz b3VyY2UuIE1heWJlIHlvdSBjYW4gdXNlIHRoaXMgdG8gZGVzY3JpYmUgeW91cg0KPnByb2JsZW0/ DQo+DQo+SSdtIG5vdCBzdXJlIGlmIEkgdW5kZXJzdGFuZCB3aGF0IHlvdSBtZWFuIHdpdGggInN5 bW1ldHJpYyBwcm9ibGVtIi4gSQ0KPnRoaW5rIHdlIGFncmVlIHRoYXQgdGhlIHR3byBwYXJ0aWVz IHRoYXQgcGFydGljaXBhdGUgaW4gYSBjb21tdW5pY2F0aW9uDQo+bWF5IGhhdmUgZGlmZmVyZW50 IGF1dGhvcml6YXRpb24gcHJvYmxlbXMuIEUuZy4sIHBhdGllbnRzIG1heSB3YW50IHRvDQo+cmVz dHJpY3Qgd2hvIGlzIGFibGUgdG8gYWNjZXNzIHRoZWlyIG1lZGljYWwgZGF0YSB3aGlsZSBwcmFj dGl0aW9uZXJzDQo+bWF5IHdhbnQgdG8gbWFrZSBzdXJlIHRoYXQgdGhlaXIgZGV2aWNlcyBvbmx5 IGFjY2VwdCBhdXRob3JpemVkIG1lZGljYWwNCj5kYXRhLiBJbiB0aGlzIGNhc2Ugd2UgaGF2ZSB0 d28gZW5kcG9pbnRzIHdob3NlIHByaW5jaXBhbHMgbmVlZCBkaWZmZXJlbnQNCj5wcm9ibGVtcyB0 byBiZSBzb2x2ZWQuDQo+DQo+RWFjaCBwYXJ0aWNpcGF0aW5nIHBhcnR5IG1heSBuZWVkIHRvIGF1 dGhvcml6ZSB0aGUgb3RoZXIgcGFydHkuIElzIHRoYXQNCj53aGF0IHlvdSBtZWFuIHdpdGggInN5 bW1ldHJpYyI/DQo+DQo+PiBJIHByb3Bvc2VkIHRvIHN3aXRjaCB0ZW1wb3JhcmlseSB0byBhIGRp ZmZlcmVudCB0ZXJtaW5vbG9neSBiYXNlZCBvbg0KPj4g4oCccHJvdmlkZXLigJ0gYW5kIOKAnHVz ZXLigJ0gKGEgdmFyaWFudCBvZiB0aGF0IHVzZWQgaW4gdGhlIFNFTlNFSSBwcm9qZWN0KQ0KPj5q dXN0DQo+PiB0byBhdm9pZCB0aGUgcG90ZW50aWFsIHByb2JsZW0gd2l0aCBvdmVybG9hZGluZyB0 aGUgdGVybSAicmVzb3VyY2XigJ0uDQo+Pk1vcmUNCj4+IGNvbW1lbnRzIGlubGluZS4NCj4+DQo+ Pg0KPj4NCj4+IE9uIDIwMTUtMDEtMjYgMTU6MjMsICJTdGVmYW5pZSBHZXJkZXMiIDxnZXJkZXNA dHppLmRlPiB3cm90ZToNCj4+DQo+Pj4gSGkgR8O2cmFuLA0KPj4+DQo+Pj4NCj4+PiBPbiAwMS8y Ni8yMDE1IDA5OjI3IEFNLCBHw7ZyYW4gU2VsYW5kZXIgd3JvdGU6DQo+Pj4+IEhpIFN0ZWZmaSwN Cj4+Pj4NCj4+Pj4gVGhhbmsgeW91IGZvciB5b3VyIHBhdGllbnQgZXhwbGFuYXRpb25zLiBJIGFt IGhhcHB5IHRoYXQgd2UgYWdyZWUgdG8NCj4+Pj4gbGVhdmUNCj4+Pj4gb3V0IGRldmljZSBvd25l cnNoaXAuDQo+Pj4+DQo+Pj4+IFJlZ2FyZGluZyB0aGUgcmVtYWluaW5nIGFyZ3VtZW50YXRpb24g SeKAmW0gc2FkIHRvIHNheSB0aGF0IEnigJltIHN0aWxsDQo+Pj4+bm90DQo+Pj4+IGNvbnZpbmNl ZC4gSW4gc2hvcnQ6IEkgdGhpbmsgd2Ugc2hvdWxkIGhhdmUgYSB0ZXJtaW5vbG9neSBpbiB0aGUg dXNlDQo+Pj4+IGNhc2UNCj4+Pj4gZG9jdW1lbnQgd2hpY2ggYWxsb3cgdXMgdG8gZXhwcmVzcyB0 aGUgY29uY3JldGUgYXV0aG9yaXphdGlvbiBwcm9ibGVtcw0KPj4+PiBvZg0KPj4+PiB0aGUgdXNl IGNhc2VzIGluIHRlcm1zIG9mIHRoaXMgdGVybWlub2xvZ3kuIElmIEkgdW5kZXJzdGFuZCB5b3Ug cmlnaHQsDQo+Pj4+IHlvdQ0KPj4+PiBzYXkgdGhhdCB3ZSBjYW7igJl0IGV4cHJlc3MgdGhlIGF1 dGhvcml6YXRpb24gcHJvYmxlbXMgaW4gdGVybXMgb2YNCj4+Pj4gUmVzb3VyY2UsDQo+Pj4+IFJl c291cmNlIE93bmVyICg9IFJlc291cmNlIFByaW5jaXBhbCksIGV0Yy4gYmVjYXVzZSB3aG8gaXMg UmVzb3VyY2UNCj4+Pj4gT3duZXINCj4+Pj4gbWF5IGRlcGVuZCBvbiBzb2x1dGlvbi4gSWYgdGhh dCBpcyB0aGUgY2FzZSwgdGhlbiBJIHRoaW5rIHdlIGhhdmUgYQ0KPj4+PiBwcm9ibGVtLiBJbiBt eSBvcGluaW9uLCBlaXRoZXIgdGhlIHRlcm1pbm9sb2d5IGlzIG5vdCBhcHByb3ByaWF0ZSwgb3IN Cj4+Pj4gdGhlcmUgaXMgc29tZSBwcm9ibGVtIHdpdGggdGhlIGFwcGxpY2F0aW9uIG9mIHRoZSB0 ZXJtaW5vbG9neSB0byB0aGUNCj4+Pj51c2UNCj4+Pj4gY2FzZXMuDQo+Pj4+DQo+Pj4+IFRvIGVs aW1pbmF0ZSB0aGUgZm9ybWVyLCBhbGxvdyBtZSB0byB0YWtlIGEgc3RlcCBiYWNrIGFuZCBhdHRl bXB0IGENCj4+Pj4gcHJlbGltaW5hcnkgdGVybWlub2xvZ3kgdG8gcmVhY2ggYSBjb21tb24gZ3Jv dW5kIG9mIHVuZGVyc3RhbmRpbmcuIExldA0KPj4+PiBtZQ0KPj4+PiBrbm93IHRvIHdoYXQgZXh0 ZW50IHdlIGNhbiBhZ3JlZSBvbiB0aGlzOg0KPj4+Pg0KPj4+PiBJbiB0aGUgdXNlIGNhc2VzIHdl IGZvY3VzIG9uIOKAnHRoaW5ncyIgbGlrZSBzZW5zb3JzICh0ZW1wZXJhdHVyZQ0KPj4+PnNlbnNv cnMsDQo+Pj4+IGhlYXJ0IHJhdGUgc2Vuc29ycyBldGMuKSBhbmQgYWN0dWF0b3JzIChmYW4gYWN0 dWF0b3JzLCBsb2NrIGFjdHVhdG9ycw0KPj4+PiBldGMuKTsgYW5kIHJlbGF0ZWQgZGF0YSBsaWtl IHNlbnNvciBtZWFzdXJlbWVudHMgKHRlbXBlcmF0dXJlcywgaGVhcnQNCj4+Pj4gcmF0ZXMsIGV0 Yy4pIGFuZCBhY3R1YXRvciBzZXR0aW5ncyAoZmFuIGNvbmZpZ3VyYXRpb24gc2V0dGluZ3MsIGxv Y2sNCj4+Pj4gb3Blbi9jbG9zZWQsIGV0Yy4gKS4gQWxsIHRoZXNlIGFyZSAiaXRlbXMgb2YgaW50 ZXJlc3QiLCBvciAiYXNzZXRzIg0KPj4+PnRoYXQNCj4+Pj4gbmVlZHMgdG8gYmUgcHJvdGVjdGVk LCBzb21lIG9mIHdoaWNoIGlzIGluIHNjb3BlIG9mIHRoaXMgd29ya2luZw0KPj4+Pmdyb3VwLg0K Pj4+Pg0KPj4+PiBJbiBvcmRlciB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIHRoZSBwYXJ0eSBwcm92 aWRpbmcgYSBzZW5zb3IvYWN0dWF0b3INCj4+Pj4gc2VydmljZSBhbmQgdGhlIHBhcnR5IHVzaW5n IHRoZSBzZXJ2aWNlIHdlIGNhbiB1c2UgdGhlIHRlcm1pbm9sb2d5DQo+Pj4+IOKAnHByb3ZpZGVy 4oCdIChvZiBzZW5zb3IvYWN0dWF0b3Igc2VydmljZXMpIGFuZCDigJx1c2Vy4oCdIChvZg0KPj4+ PnNlbnNvci9hY3R1YXRvcg0KPj4+PiBzZXJ2aWNlcykuIE9uZSBpbXBvcnRhbnQgc2VjdXJpdHkg cHJvYmxlbSBpbiBzY29wZSBvZiB0aGlzIHdvcmtpbmcNCj4+Pj5ncm91cA0KPj4+PiBkZWFscyB3 aGljaCBkZXZpY2VzIGFyZSBhbGxvd2VkIHRvIHJlYWQgZnJvbSBhIHNlbnNvciBvciB3cml0ZSB0 byBhbg0KPj4+PiBhY3R1YXRvci4gSW4gZGV0YWlsIHRoaXMgbWVhbnMgZm9yIGV4YW1wbGUgdGhh dCBhIGRldmljZSBhc3NvY2lhdGVkDQo+Pj4+dG8gYQ0KPj4+PiB1c2VyIG1heSBvciBtYXkgbm90 IOKAnHJlYWQiIG1lYXN1cmVtZW50cyBmcm9tIGEgZGV2aWNlIGFzc29jaWF0ZWQgdG8gYQ0KPj4+ PiBwcm92aWRlciBvZiBzZW5zb3Igc2VydmljZXMuIEFuYWxvZ291c2x5IGEgZGV2aWNlIGFzc29j aWF0ZWQgdG8gYSB1c2VyDQo+Pj4+IG1heQ0KPj4+PiBvciBtYXkgbm90IOKAnHdyaXRlIiBhY3R1 YXRvciBzZXR0aW5ncyB0byBhIGRldmljZSBhc3NvY2lhdGVkIHdpdGggYQ0KPj4+PiBwcm92aWRl ciBvZiBhY3R1YXRvciBzZXJ2aWNlcy4gIFRoZXJlIG1heSBiZSBvdGhlciBzZWN1cml0eSBwcm9i bGVtcw0KPj4+PmFzDQo+Pj4+IHdlbGwgYW5kIHdlIHNob3VsZCBsaXN0IHRoZW0gYW5kIGRlY2lk ZSBpZiB0aGV5IGFyZSBpbiBzY29wZS4NCj4+Pj4NCj4+Pj4gQXJlIHdlIE9LIG9uIHRoaXMgbGV2 ZWw/DQo+Pj4gSSBkb24ndCBzZWUgaG93IHRoaXMgdGVybWlub2xvZ3kgd2lsbCBoZWxwIHVzIHdp dGggdGhlIGF1dGhvcml6YXRpb24NCj4+PiBzb2x1dGlvbi4gSW4gQ29BUCwgdGhlIHNlcnZlciBp cyBub3QgbmVjZXNzYXJpbHkgdGhlIHNlbnNvci9hY3R1YXRvci4NCj4+PiBUaGUgcHJvdGVjdGlv biBvZiBzZW5zb3Igb3IgYWN0dWF0b3IgdmFsdWVzIGRvZXMgbm90IHJlYWxseSBmaXQgdG8gdGhl DQo+Pj4gcHJvdGVjdGlvbiBvZiBDb0FQIHJlc291cmNlcyAodGhhdCBhcmUgaWRlbnRpZmllZCBi eSBhIFVSSSkuDQo+Pj4NCj4+PiBNb3Jlb3Zlciwgb25lIG9mIHRoZSBlbmRwb2ludHMgbWF5IGJl IGEgc2Vuc29yIHdoaWxlIHRoZSBvdGhlciBtYXkgYmUNCj4+PmFuDQo+Pj4gYWN0dWF0b3IgYW5k IHdlIHRodXMgd291bGQgaGF2ZSB0d28gcHJvdmlkZXJzLg0KPj4gWWVzLCB0aGF0IGlzIGZpbmUu IFRoZXkgcHJvdmlkZSBkaWZmZXJlbnQgc2VydmljZXMuIElmIHdlIGhhdmUgYQ0KPj5zb2x1dGlv bg0KPj4gdG8gdGhlICJwcm92aWRlciBhdXRob3JpemVzIHVzZXIgcHJvYmxlbSIgd2UgY2FuIGFw cGx5IGl0IHR3aWNlLg0KPg0KPkkgY2FuJ3QgcmVhbGx5IGltYWdpbmUgaG93IHRoaXMgd291bGQg d29yayBpbiBwcmF4aXMuIEJ1dCB0aGlzIHdvdWxkIGJlDQo+b25lIHBvc3NpYmxlIHNvbHV0aW9u IHRvIGFkZHJlc3MgdGhpcyBwcm9ibGVtLCBJIGd1ZXNzLiBBcyBmYXIgYXMgSSdtDQo+YXdhcmUg b2YsIHRoZSB1c2UgY2FzZXMgZHJhZnQgZG9lc24ndCBwcmV2ZW50IHRoaXMga2luZCBvZiBzb2x1 dGlvbi4NCj4NCj4+PiBJIGFncmVlIHRoYXQgd2Ugd2FudCB0byBwcm90ZWN0IGl0ZW1zIG9mIGlu dGVyZXN0LiBJZiB5b3Ugd2FudCB0byBjdXQNCj4+PiBkb3duIHRoZSBwcm9ibGVtIHRvICJ3ZSBw cm90ZWN0IHRoZSBpdGVtIG9mIGludGVyZXN0IGJ5IGRlZmluaW5nIHdobyBpcw0KPj4+IGFsbG93 ZWQgdG8gcmVhZC93cml0ZSB0aGUgaXRlbSBvbiBvbmUgc2lkZSIgeW91IGFyZSBvbmx5IGFkZHJl c3NpbmcNCj4+PmhhbGYNCj4+PiBvZiB0aGUgcHJvYmxlbS4gV2UgZG9uJ3QgZ2V0IGFyb3VuZCB0 aGUgcHJvYmxlbSB0aGF0IHRoZXJlIG1heSBiZSB0d28NCj4+PiBwYXJ0aWVzIHdpdGggZGlmZmVy ZW50IGludGVyZXN0cyBpbnZvbHZlZCBieSByZW5hbWluZyB0aGVtIG9yIGJ5IHRyeWluZw0KPj4+ IHRvIGZpdCB0aGUgdXNlIGNhc2VzIHRvIGEgbW9kZWwsIHdoZXJlIGl0IGlzIGNsZWFyIHdoaWNo IHBhcnR5IHJlcXVlc3RzDQo+Pj4gYW5kIHdoaWNoIHBhcnR5IHByb3ZpZGVzIGFuIGl0ZW0gb2Yg aW50ZXJlc3QuIFdlIHdpbGwgb25seSBnYWluIGFuDQo+Pj4gYXV0aG9yaXphdGlvbiBzb2x1dGlv biB0aGF0IHJlc3RyaWN0cyB0aGUgcG9zc2liaWxpdGllcyBvZiBDb0FQLg0KPj4+DQo+Pj4gSSBk b24ndCBsaWtlIHRoZSB0ZXJtICJ1c2VyIiBzaW5jZSBpdCBpbXBsaWVzIHRoZSBwcmVzZW5jZSBv ZiBhIGh1bWFuDQo+Pj4gYmVpbmcuIEkgZG9uJ3Qga25vdyBpZiB0aGF0J3Mgd2hhdCB5b3UgaGF2 ZSBpbiBtaW5kPw0KPj4gVGhlIHByZWxpbWluYXJ5IHRlcm1pbm9sb2d5IEkgcHJvcG9zZWQgd2Fz IGEgdmFyaWFudCBvZiB0aGF0IHVzZWQgaW4gdGhlDQo+PiBTRU5TRUkgcHJvamVjdC4gSW4gdGhh dCBwcm9qZWN0IHdlIHVzZWQgdGhlIHRlcm1zIOKAnFJlc291cmNlIFByb3ZpZGVy4oCdDQo+PmFu ZA0KPj4g4oCcUmVzb3VyY2UgVXNlcuKAnSwgYnV0IEkgd2FudGVkIHRvIGF2b2lkIHRoZSBub3Rp b24gb2YgUmVzb3VyY2UgYXMNCj4+ZXhwbGFpbmVkDQo+PiBhYm92ZS4gSSBhZ3JlZSB0aGUgbm90 aW9uIOKAnFVzZXLigJ0gaXMgbm90IHBlcmZlY3QuIEkgY2FsbGVkIHRoZQ0KPj50ZXJtaW5vbG9n eQ0KPj4g4oCccHJlbGltaW5hcnnigJ0gYmVjYXVzZSBpdCB3YXMgaW50ZW5kZWQgYXMgYSBtZWFu cyB0byBnZXQgYXJvdW5kIHdoYXQNCj4+dGhpbmsNCj4+IGlzIGFuIG92ZXJsb2FkIG9mIHRlcm1z IGluIHlvdXIgY3VycmVudCBwcm9wb3NhbC4gV2UgY291bGQgb2YgY291cnNlDQo+PiByZW5hbWUg dGVybXMsIGJ1dCBmb3Igbm93IGl0IGlzIGp1c3QgYSBtYXR0ZXIgb2YgaGF2aW5nIHRlcm1zIHRo YXQNCj4+Y2xlYXJseQ0KPj4gZGlzdGluZ3Vpc2ggYmV0d2VlbiB0aGUgZGlmZmVyZW50IGZ1bmN0 aW9ucy4NCj4+DQo+PiA8c25pcD4NCj4+DQo+Pj4+PiBNb3Jlb3ZlciwgaW4gYQ0KPj4+Pj4gc2Nl bmFyaW8gd2hlcmUgdHdvIGRpZmZlcmVudCBwYXJ0aWVzIG1heSBiZSBpbnZvbHZlZCwgb25lIHRo YXQNCj4+Pj4+cmVxdWVzdHMNCj4+Pj4+IGEgcmVwcmVzZW50YXRpb24gb2YgdGhlIHJlc291cmNl IGFuZCBvbmUgdGhhdCBwcm92aWRlcyB0aGUgcmVzb3VyY2UNCj4+Pj4+IHJlcHJlc2VudGF0aW9u LCB0aGVzZSB0d28gcGFydGllcyBtYXkgaGF2ZSBkaWZmZXJlbnQgaW50ZXJlc3RzIGFuZA0KPj4+ Pj50aHVzDQo+Pj4+PiBoYXZlIGRpZmZlcmVudCBwcm9ibGVtcyB0aGF0IG5lZWQgdG8gYmUgc29s dmVkIGJ5IGFuIGF1dGhvcml6YXRpb24NCj4+Pj4+IHNvbHV0aW9uLiBUaHVzLCB0aGUgcmVzb3Vy Y2Ugb3duZXIncyBwcm9ibGVtcyBhcmUgbm90IHRoZSBvbmx5DQo+Pj4+PnByb2JsZW1zDQo+Pj4+ PiB3ZSBuZWVkIHRvIGNvbnNpZGVyLg0KPj4+PiBXaGF0IHlvdSBqdXN0IHN0YXRlZCBpcyB2ZXJ5 IGNsb3NlIHRvIHRoZSBwb2ludCBJIHdhbnQgdG8gbWFrZS4gSXQNCj4+Pj5zZWVtcw0KPj4+PiB3 ZSBhZ3JlZSB0aGF0IHRoZXJlIGlzIGEgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSBwYXJ0eSBwcm92 aWRpbmcgYW5kDQo+Pj4+dGhlDQo+Pj4+IHBhcnR5IHJlcXVlc3RpbmcuIFRoZXJlZm9yZSB3ZSBu ZWVkIGEgdGVybWlub2xvZ3kgdG8gZGVzY3JpYmUgaG93IHRoaXMNCj4+Pj4gZGlmZmVyZW5jZSBh cHBsaWVzIHRvIHRoZSBhdXRob3JpemF0aW9uIHByb2JsZW1zICAoaW4gdGhlIHNlY3Rpb25zDQo+ Pj4+IGVudGl0bGVkIOKAnEF1dGhvcml6YXRpb24gUHJvYmxlbSBTdW1tYXJ54oCdIGluIHRoZSB1 c2UgY2FzZSBkb2N1bWVudCkuDQo+Pj4gSSBkb24ndCB0aGluayB0aGF0IHRoZXNlIGRpZmZlcmVu Y2VzIGFwcGx5IHRvIHRoZSBzZWN1cml0eSBvYmplY3RpdmVzDQo+Pj4gdGhhdCB0aGUgaW52b2x2 ZWQgcGFydGllcyBtYXkgd2FudCB0byBhY2hpZXZlLiBBcyBhIHByaW5jaXBhbCwgSSBkb24ndA0K Pj4+IGNhcmUgd2hldGhlciBJIHJlcXVlc3QgYW4gaXRlbSBvciBwcm92aWRlIGFuIGl0ZW0uIFJl Z2FyZGxlc3Mgb2YgdGhlDQo+Pj4gc2V0dGluZyBJIHdhbnQgdG8gbWFrZSBzdXJlIHRoYXQgbXkg c2VjdXJpdHkgb2JqZWN0aXZlcyBhcmUgYWNoaWV2ZWQuDQo+PiBJIHNlZSB0d28gcXVpdGUgZGlm ZmVyZW50IHByb2JsZW1zOiBJ4oCZbSBmaW5lIHdpdGgg4oCcYXV0aG9yaXphdGlvbiB0bw0KPj4g cHJvdmlkZSBhbiBpdGVt4oCdLCBpLmUuIHRoZSBwcm92aWRlciBhdXRob3JpemVzIGEgdXNlciB3 aXRoIGFuIGl0ZW0uIFRoaXMNCj4+IGlzIGFuIGludGVyIGRvbWFpbiBwcm9ibGVtIHdoaWNoIGlz IG5hdHVyYWxseSBtYXBwZWQgdG8gYSBSRVNUZnVsDQo+PiByZXF1ZXN0L3Jlc3BvbnNlIHByb3Rv Y29sLiBJIGhhdmUgYSBwcm9ibGVtIHdpdGgg4oCcYXV0aG9yaXphdGlvbiB0bw0KPj5yZXF1ZXN0 DQo+PiBhbiBpdGVt4oCdIGkuZS4gdGhhdCB0aGUgdXNlciBhdXRob3JpemVzIGl0c2VsZiB0byBz ZW5kIGEgcmVxdWVzdCBmb3IgYW4NCj4+IGl0ZW0uIEkgc2VlIHRoYXQgYXMgYSB1c2VyIGRvbWFp biBpbnRlcm5hbCBwcm9ibGVtIHdoaWNoIGlzIG5vdA0KPj4gbmVjZXNzYXJpbHkgY2FzdCBpbiBh IFJFU1RmdWwgcmVxdWVzdC9yZXNwb25zZSBtZXNzYWdlIGV4Y2hhbmdlLiBBbmQgaWYNCj4+aXQN Cj4+IGlzLCB0aGVuIHdlIGNhbiBzb2x2ZSBhdXRob3JpemF0aW9uIG9mIFJFU1RmdWwgcmVxdWVz dCBhbmQgYXBwbHkgaXQNCj4+dHdpY2U6DQo+PiBPbmNlIG9uIHRoZSBpbnRlci1kb21haW4gcHJv YmxlbSBhbmQgb25jZSBvbiB0aGUgdXNlciBpbnRlcm5hbCB1c2VyDQo+PmRvbWFpbg0KPj4gcHJv YmxlbS4NCj4NCj5JIGRvbid0IHF1aXRlIHVuZGVyc3RhbmQgd2hhdCB0aGUgZGVmaW5pdGlvbiBv ZiAidXNlciIgaXMgaW4geW91cg0KPnByb3Bvc2VkIHRlcm1pbm9sb2d5LiBJcyAidXNlciIgYSBw cmluY2lwYWwsIGkuZS4gYSBodW1hbiBiZWluZyBpbiB5b3VyDQo+c2NlbmFyaW8gb3IgaXMgaXQg YSBkZXZpY2UvZW5kcG9pbnQ/IElmIHRoZSB1c2VyIGlzIGEgcHJpbmNpcGFsLCBpdCB3aWxsDQo+ aGF2ZSBzb21lIGtpbmQgb2YgZW5kcG9pbnQgdGhhdCBjb21tdW5pY2F0ZXMgd2l0aCBhbm90aGVy IGVuZHBvaW50LiBJZg0KPnRoZSB1c2VyIGlzIGFuIGVuZHBvaW50LCBpdCB3aWxsIGhhdmUgYSBw cmluY2lwYWwuIEluIGJvdGggY2FzZXMgdGhlDQo+cHJpbmNpcGFsIG1heSB3YW50IHRvIG1ha2Ug c3VyZSB0aGF0IGhlciBlbmRwb2ludCBpcyBvbmx5IGNvbW11bmljYXRpbmcNCj53aXRoIGF1dGhv cml6ZWQgZW5kcG9pbnRzLg0KPg0KPkkgZG9uJ3Qga25vdyB3aGF0ICJ1c2VyIGRvbWFpbiBpbnRl cm5hbCBwcm9ibGVtIiByZWZlcnMgdG8gaW4gdGhpcw0KPnNjZW5hcmlvLiBSZWdhcmRsZXNzIG9m IGhvdyB5b3UgbmFtZSB0aGlzIHByb2JsZW0sIGl0IGlzIGFuDQo+YXV0aG9yaXphdGlvbiBwcm9i bGVtIGFuZCB0aHVzIGlzIGxpc3RlZCBpbiB0aGUgdXNlIGNhc2VzIGRyYWZ0LiBJdCBpcw0KPnRo ZSBwdXJwb3NlIG9mIHRoZSBkcmFmdCB0byBsaXN0IGF1dGhvcml6YXRpb24gcHJvYmxlbXMuIEEg c29sdXRpb24NCj5taWdodCBub3QgYWRkcmVzcyBhbGwgb2YgdGhlIGxpc3RlZCBwcm9ibGVtcyBi dXQgSSBkb24ndCB0aGluayBpdCBpcyBhDQo+Z29vZCBpZGVhIHRvIGxlYXZlIG91dCBwcm9ibGVt cyBiZWNhdXNlIGEgY2VydGFpbiBzb2x1dGlvbiBtaWdodCBub3QNCj5hZGRyZXNzIHRoZW0uDQo+ DQo+Pj4+PiBGb3IgQ29BUCwgdGhlIGVudGl0eSB0aGF0IGNvbnRyb2xzIHRoZSBhY2Nlc3MgcGVy bWlzc2lvbnMgdG8gYSBDb0FQDQo+Pj4+PiByZXNvdXJjZSB3aWxsIGxpa2VseSBiZSB0aGUgcmVz b3VyY2Ugb3duZXIsIGFuZCB0aHVzIHRoZSBvd25lciBvZiB0aGUNCj4+Pj4+IGRhdGEgdGhhdCBp cyBzdG9yZWQgdGhlcmUuIElmIHlvdSBhcmUgdHJhbnNtaXR0aW5nIGRhdGEgdG8gdGhhdA0KPj4+ Pj4gcmVzb3VyY2UsIHlvdSBhcmUgdGhlIHJlc291cmNlIG93bmVyIGFzIGxvbmcgYXMgeW91IGNv bnRyb2wgdGhlDQo+Pj4+PmFjY2Vzcw0KPj4+Pj4gcGVybWlzc2lvbnMgZm9yIHRoaXMgcmVzb3Vy Y2UuIElmIHlvdSBhcmUgdHJhbnNtaXR0aW5nIGRhdGEgdG8NCj4+Pj4+c29tZW9uZQ0KPj4+Pj4g ZWxzZSdzIENvQVAgcmVzb3VyY2UgeW91IGFyZSBnaXZpbmcgdXAgb3duZXJzaGlwIGZvciB0aGlz IGNvcHkgb2YgdGhlDQo+Pj4+PiBkYXRhLg0KPj4+PiBJIGFncmVlIHRoYXQgc2Vuc29yIGFuZCBh Y3R1YXRvciByZWxhdGVkIGRhdGEgbmVlZHMgdG8gYmUgc2VjdXJlZA0KPj4+PiBlbmQtdG8tZW5k IGJldHdlZW4gdXNlciBkZXZpY2UgYW5kIHByb3ZpZGVyIGRldmljZSwgYW5kIHRoYXQgdGhpcyBp cw0KPj4+PiBwYXJ0DQo+Pj4+IG9mIHRoZSBhdXRob3JpemF0aW9uIHByb2JsZW06IGFjY2VzcyBj b250cm9sIHRvIHNlbnNvciBkYXRhIG1heSBiZSBvZg0KPj4+PiBsaW1pdGVkIHZhbHVlIGlmIHNl bnQgaW4gcGxhaW4gdGV4dDsgYWNjZXNzIGNvbnRyb2wgdG8gYWN0dWF0aW9uIGRhdGENCj4+Pj4g bmVlZHMgdG8gYmUgaW50ZWdyaXR5IHByb3RlY3RlZCwgZXRjLiBCdXQgSeKAmW0gbm90IHN1cmUg SSB1bmRlcnN0YW5kDQo+Pj4+d2hhdA0KPj4+PiB5b3UgbWVhbiB3aXRoICJkYXRhIG93bmVyc2hp cOKAnS4gU2Vuc29yIGRhdGEgaXMgcHJvdmlkZWQgaW4gcHJvdGVjdGVkDQo+Pj4+IGZvcm0NCj4+ Pj4gdG8gYW4gYXV0aG9yaXplZCB1c2VyLCB3aGF0IHRoZSB1c2VyIGRvZXMgd2l0aCB0aGlzIGRh dGEgaXMgYmV5b25kIHRoZQ0KPj4+PiBzY29wZSBvZiB0aGlzIHdvcmtpbmcgZ3JvdXAsIGlzbuKA mXQgaXQ/IElzbuKAmXQgdGhhdCBtb3JlIGxpa2UgYW4NCj4+Pj5hZ3JlZW1lbnQNCj4+Pj4gYmV0 d2VlbiB0aGUgcGFydGllcz8gSSBhc3N1bWUgeW91IGFyZSBub3QgdGhpbmtpbmcgb2YgZGlnaXRh bCByaWdodHMNCj4+Pj4gbWFuYWdlbWVudC4NCj4+PiBJIGRvbid0IHRoaW5rIHRoZSB0ZXJtICJ1 c2VyIiBpcyBoZWxwZnVsIGhlcmUuIFRoZXJlIG1heSBiZSB0d28gZGV2aWNlcw0KPj4+IGNvbW11 bmljYXRpbmcgd2l0aG91dCBhbnkgdXNlciBpbnRlcmFjdGlvbi4NCj4+Pg0KPj4+IEkgYW0ganVz dCB0cnlpbmcgdG8gZXhwbGFpbiB0aGF0IHRoZXJlIGFyZSB0d28gcGFydGllcyBpbnZvbHZlZCBp bg0KPj4+IGV4Y2hhbmdpbmcgYW4gaXRlbSBvZiBpbnRlcmVzdC4gRWFjaCBvbmUgb2YgdGhlc2Ug cGFydGllcyBtYXkgaGF2ZQ0KPj4+dGhlaXINCj4+PiBvd24gc2VjdXJpdHkgb2JqZWN0aXZlcy4g VGhlIHNlbmRlciB3aWxsIHdhbnQgdG8gbWFrZSBzdXJlIHRoYXQgdGhlDQo+Pj4gcmVjZWl2ZXIg aXMgYXV0aG9yaXplZCB0byBnZXQgdGhlIGRhdGEsIHRoZSByZWNlaXZlciB3aWxsIHdhbnQgdG8g bWFrZQ0KPj4+IHN1cmUgdGhhdCB0aGUgc2VuZGVyIGlzIGF1dGhvcml6ZWQgdG8gc2VuZCB0aGUg ZGF0YS4NCj4+Pg0KPj4+IEluIGEgY29uY3JldGUgdXNlIGNhc2UsIEkgc2VlIG5vIGV2aWRlbmNl IHdobyB0aGUgc2VuZGVyIGFuZCB3aG8gdGhlDQo+Pj4gcmVjZWl2ZXIgd2lsbCBiZS4NCj4+IE1h eWJlIHRoaXMgaXMgYSByZWFzb24gd2h5IHRoZSB0ZXJtaW5vbG9neSBpcyBub3Qgc3VpdGFibGU/ IFRoZXJlIGlzIGENCj4+IGRpZmZlcmVuY2UgYmV0d2VlbiB3aG8gaXMgcHJvdmlkaW5nIGEgc2Vu c29yL2FjdHVhdG9yIHNlcnZpY2UgYW5kIHdobyBpcw0KPj4gdXNpbmcgaXQuIEFuZCBleHByZXNz aW5nIHRoYXQgZGlmZmVyZW5jZSBhbGxvd3MgdXMgdG8gZWxhYm9yYXRlIG9uIHRoZQ0KPj4gcm9s ZXMgaW4gdGhlIHVzZSBjYXNlcy4NCj4NCj5JdCBzZWVtcyB0byBtZSB0aGF0IHlvdSBhcmUgdHJ5 aW5nIHRvIGZpbmQgYSB0ZXJtaW5vbG9neSB3aGVyZSB3ZSBvbmx5DQo+aGF2ZSBvbmUgcGFydHkg d2l0aCBhbiBhdXRob3JpemF0aW9uIHByb2JsZW0uDQo+DQo+Pg0KPj4+Pj4gSWYgeW91IHdhbnQg dG8gbWFrZSBzdXJlIHRoYXQgdGhlIG93bmVyIG9mIHRoZSBkYXRhIG5ldmVyIGNoYW5nZXMgeW91 DQo+Pj4+PiB3aWxsIGhhdmUgdG8gbWFrZSBzdXJlIHRoYXQgdGhlIHJlc291cmNlIG93bmVyIGNh biBjb250cm9sIHRoZSBhY2Nlc3MNCj4+Pj4+IHBlcm1pc3Npb25zIGZvciB0aGlzIGRhdGEgb24g YWxsIGRldmljZXMgd2hlcmUgdGhlIGRhdGEgaXMNCj4+Pj4+dHJhbnNtaXR0ZWQNCj4+Pj4+IHRv LiBFdmVuIGlmIGRhdGEgaXMgdHJhbnNtaXR0ZWQgdG8gYSByZXF1ZXN0aW5nIGNsaWVudCB5b3Ug YXJlIGdpdmluZw0KPj4+Pj4gdXANCj4+Pj4+IG93bmVyc2hpcCBmb3IgdGhlIGNvcHkgb2YgdGhl IGRhdGEgdGhhdCB5b3UgYXJlIHRyYW5zbWl0dGluZywgdW5sZXNzDQo+Pj4+PiB5b3UNCj4+Pj4+ IGNhbiBjb250cm9sIGFjY2VzcyBwb2xpY2llcyBmb3IgdGhlIGRhdGEgb24gdGhlIGNsaWVudC4g WW91IG1heQ0KPj4+Pj5jb250cm9sDQo+Pj4+PiB5b3VyIG93biBjb3B5IG9mIHRoZSBkYXRhLCBi dXQgbm90IHRoZSBjbGllbnQncyBjb3B5Lg0KPj4+Pj4NCj4+Pj4+IEkgZG9uJ3QgdGhpbmsgaXQn cyBzbyBjbGVhciB0aGF0IHRoZSBwYXRpZW50IGlzIGFsd2F5cyB0aGUgcmVzb3VyY2UNCj4+Pj4+ IG93bmVyIGluIGEgaGVhbHRoY2FyZSBzY2VuYXJpby4NCj4+Pj4gWWVzLCBhcyBJIG1lbnRpb25l ZCBpbiBteSBwcmV2aW91cyBtYWlsIOKAnEluIFN3ZWRlbiwgdGhlIGNhcmVnaXZlciB3aWxsDQo+ Pj4+IHNldA0KPj4+PiBhY2Nlc3MgcG9saWNpZXMg4oCcLiBJcyB0aGVyZSBzb21lIGNvbmZ1c2lv biBhYm91dCB0aGUgdGVybQ0KPj4+PuKAnGNhcmVnaXZlcuKAnT8gSQ0KPj4+PiBtZWFudCB0aGUg YWRtaW5pc3RyYXRpdmUgcmVwcmVzZW50YXRpdmUgb2YgdGhlIGRvY3RvciBldGMuIC0gcm91Z2hs eQ0KPj4+PnRoZQ0KPj4+PiBzYW1lIGFzIHlvdXIgdGVybSDigJxwcmFjdGl0aW9uZXLigJ0uDQo+ Pj4gSXQgc2VlbWVkIHRvIG1lIHRoYXQgeW91IHdhbnRlZCB0byBzdWdnZXN0IHRoYXQgd2UgdXNl IHRoZSB0ZXJtaW5vbG9neQ0KPj4gPmZyb20gVU1BIHdoZXJlIGluIG9uZSB1c2UgY2FzZSB0aGUg cGF0aWVudCBpcyB0aGUgcmVzb3VyY2Ugb3duZXIuIEluDQo+Pj4gdGhpcyBjYXNlIHRoZSBwYXRp ZW50IHdvdWxkIGJlIHRoZSBvbmUgdGhhdCBpcyBpbiBjb250cm9sIG9mIHRoZSBhY2Nlc3MNCj4+ PiBwb2xpY2llcy4NCj4+Pg0KPj4+IFNvIHdlIGFncmVlIHRoYXQgaXQncyBub3QgY2xlYXIgd2hl dGhlciB0aGUgcGF0aWVudCBvciB0aGUNCj4+PiBjYXJlZ2l2ZXIvcHJhY3RpdGlvbmVyIGlzIHRo ZSByZXNvdXJjZSBvd25lcj8NCj4+IFRoZXJlIGFyZSBkaWZmZXJlbmNlcyBpbiBsZWdpc2xhdGlv biBpbiBkaWZmZXJlbnQgY291bnRyaWVzIGFuZCB5b3UgbWF5DQo+PiBoYXZlIGRpZmZlcmVudCBh Z3JlZW1lbnRzIGJldHdlZW4gcGF0aWVudCBhbmQgY2FyZWdpdmVyIGV0Yy4gSG93ZXZlciwNCj4+ d2l0aA0KPj4gYSBnaXZlbiBsZWdpc2xhdGlvbiBhbmQgYWdyZWVtZW50LCBpdCBpcyBjbGVhciB3 aG8gaXMgcHJvdmlkZXIuDQo+Pg0KPj4+Pj4gTGV0J3MgYXNzdW1lIHRoYXQgaW4gdGhlIHBlcnNv bmFsIGhlYWx0aA0KPj4+Pj4gbW9uaXRvcmluZyBjYXNlLCBhIHByYWN0aXRpb25lciByZWNlaXZl cyBkYXRhIGZyb20gSm9obidzIGhlYXJ0IHJhdGUNCj4+Pj4+IG1vbml0b3Igd2l0aCBoZXIgc21h cnRwaG9uZS4gSm9obiBpcyB0aGUgb3duZXIgb2YgdGhlIGhlYXJ0IHJhdGUNCj4+Pj4+IGluZm9y bWF0aW9uIHdoaWxlIGl0IGlzIG9uIHRoZSBoZWFydCByYXRlIG1vbml0b3IuIEhlIHdhbnRzIHRv DQo+Pj4+PmNvbnRyb2wNCj4+Pj4+IHdobyBpcyBhYmxlIHRvIGFjY2VzcyB0aGlzIGRhdGEuIEJ1 dCBJIHRoaW5rIGl0IGlzIHVubGlrZWx5IHRoYXQgdGhlDQo+Pj4+PiBwcmFjdGl0aW9uZXIgd2ls bCBsZXQgSm9obiBjb25maWd1cmUgYWNjZXNzIHBvbGljaWVzIGZvciBkYXRhIG9uIGhlcg0KPj4+ Pj4gZGV2aWNlLiBTaGUgZ2FpbnMgb3duZXJzaGlwIGZvciBoZXIgY29weSBvZiBKb2huJ3MgZGF0 YSBzaW5jZSBzaGUgaXMNCj4+Pj4+IHRoZQ0KPj4+Pj4gb25lIHRoYXQgY29udHJvbHMgdGhlIGFj Y2VzcyBwb2xpY2llcy4NCj4+Pj4gSSBzZWUgdHdvIChvciBvbmUtYW5kLWEtaGFsZikgYXV0aG9y aXphdGlvbiBwcm9ibGVtcyBoZXJlLiBUaGUgZmlyc3QNCj4+Pj4gYXV0aG9yaXphdGlvbiBwcm9i bGVtIGlzIHdpdGggSm9obiBhcyDigJxwcm92aWRlcuKAnSBvZiBzZW5zb3IgbWVhc3VybWVudHMN Cj4+Pj4gYW5kDQo+Pj4+IHRoZSBwcmFjdGl0aW9uZXIgYXMg4oCcdXNlcuKAnS4gIFRoZSBzZWNv bmQgcHJvYmxlbSBpcyB3aXRoIHRoZQ0KPj4+PnByYWN0aXRpb25lcg0KPj4+PiBhcyBwcm92aWRl ciAodHJ1c3RlZCBwcm94eSksIGJ1dCBob3cgdGhhdCBkYXRhIGlzIHVzZWQgaXMgbm90DQo+Pj4+ ZGVzY3JpYmVkDQo+Pj4+ICh0aGlzIGlzIHdoYXQgSSBtZWFudCBieSDigJxhbmQtYS1oYWxm4oCd KS4NCj4+Pj4NCj4+Pj4gSWYgd2UgY2FuIGhhdmUgYSBzb2x1dGlvbiB0byBob3cgYSBwcm92aWRl ciBjYW4gc2V0IHBvbGljaWVzIGZvcg0KPj4+PmFjY2Vzcw0KPj4+PiB0bw0KPj4+PiBkYXRhIGFu ZCBvbmx5IGdyYW50IGFjY2VzcyB0byBhdXRob3JpemVkIHVzZXJzLCB0aGVuIHdlIGNvdWxkIGFw cGx5DQo+Pj4+dGhpcw0KPj4+PiBzb2x1dGlvbiB0d2ljZTogZmlyc3Qgd2l0aCBKb2huIGFzIHBy b3ZpZGVyLCB0aGVuIHdpdGggdGhlDQo+Pj4+cHJhY3RpdGlvbmVyDQo+Pj4+IGFzDQo+Pj4+IHBy b3ZpZGVyLiBPZiBjb3Vyc2UsIHRoZXJlIG11c3QgYmUgYW4gYWdyZWVtZW50IGJldHdlZW4gSm9o biBhbmQgdGhlDQo+Pj4+IHByYWN0aXRpb25lciBhYm91dCB0aGUgcHJhY3RpdGlvbmVyIGFjdGlu ZyBwcm92aWRlciBmb3IgdGhpcyBkYXRhLA0KPj4+PmJ1dCBJDQo+Pj4+IGRvbuKAmXQgdGhpbmsg dGhhdCBpcyBpbiBzY29wZSBvZiB0aGlzIHdvcmtpbmcgZ3JvdXAuDQo+Pj4gT2theSwgc28gd2Ug YWdyZWUgdGhhdCB3ZSBuZWVkIGEgc29sdXRpb24gdGhhdCBhZGRyZXNzZXMgdGhlDQo+Pj4gYXV0 aG9yaXphdGlvbiBwcm9ibGVtcyBvZiBib3RoIGVuZHBvaW50cyBpbiBhIGNvbnZlcnNhdGlvbj8N Cj4+IEFzIG1lbnRpb25lZCwgSSBzZWUgaW4geW91ciBleGFtcGxlIGEgc2VxdWVuY2Ugb2YgdHdv IGF1dGhvcml6YXRpb24NCj4+IHByb2JsZW1zLg0KPj4NCj4+IExldCBtZSBhZGQgdGhhdCBJIGZp bmQgdGhlIGV4YW1wbGUgYSBiaXQgIm1hZGUgdXAiLiBXaGF0IEnigJltIGZhbWlsaWFyDQo+Pndp dGgNCj4+IGZyb20gRXJpY3Nzb24gTW9iaWxlIEhlYWx0aCBpcyB0aGUgY2FzZSB3aGVuIHRoZSBj YXJlZ2l2ZXIgcHJvdmlkZXMgdGhlDQo+PiBoZWFsdGggbW9uaXRvciBzZW5zb3IgdG8gdGhlIHBh dGllbnQgKGluIHByYWN0aWNlIHRoZSBwYXRpZW50IGdldHMgYQ0KPj4gYnJpZWZjYXNlIHdpdGgg b25lIG9yIG1vcmUgc2Vuc29ycyBhbmQgYSBjZWxsdWxhciBjb21tdW5pY2F0aW9uIG1vZHVsZSku DQo+PiBUaGlzIGlzIGEgbW9yZSBuYXR1cmFsIHNpdHVhdGlvbiwgYmVjYXVzZSB0aGVuIHRoZSBj YXJlZ2l2ZXIgY2FuIGFzc3VtZQ0KPj5hDQo+PiBsYXJnZSByZXNwb25zaWJpbGl0eSBmb3IgdGhl IG1lYXN1cmVtZW50IGluY2x1ZGluZyBlcXVpcG1lbnQgbWFpbnRlbmFuY2UNCj4+IGFuZCBpbnN0 cnVjdGluZyB0aGUgcGF0aWVudCBob3cgdG8gbWFrZSB0aGUgbWVhc3VyZW1lbnQgaW4gYSBjb3Jy ZWN0IHdheQ0KPj4gZ2l2ZW4gdGhlIGVxdWlwbWVudCB1c2VkIGV0Yy4gVGhpcyBzaXR1YXRpb24g aGFzIG1vcmUgaW4gY29tbW9uIHdpdGggdGhlDQo+PiB0cmFkaXRpb25hbCBzZXR1cCBiZXR3ZWVu IHBhdGllbnQgYW5kIGNhcmVnaXZlciwgYWx0aG91Z2ggdGhlIHBhdGllbnQgaXMNCj4+IHJlcXVl c3RlZCB0byBwZXJmb3JtIHNpbXBsZSB0YXNrcyByZXBsYWNpbmcgYSBudXJzZS4gSGVuY2UgYSBz aW1pbGFyDQo+PiBhZ3JlZW1lbnQgYmV0d2VlbiBwYXRpZW50IGFuZCBjYXJlZ2l2ZXIgaW4gdGhl IGNvdW50cnkgaW4gcXVlc3Rpb24gY2FuDQo+PmJlDQo+PiBhcHBsaWVkLCBpbmNsdWRpbmcgd2hv IGhhcyB0aGUgcmlnaHRzIHRvIHNldCBhY2Nlc3MgY29udHJvbCBwb2xpY2llcy4NCj4+VGhlDQo+ PiBleGFtcGxlIHlvdSBwcm92aWRlIHdoZXJlIHRoZSBwYXRpZW50IG93bnMgdGhlIGhlYXJ0IHJh dGUgbW9uaXRvciBhbmQNCj4+IHRyYW5zZmVycyByaWdodHMgdG8gdGhlIHNldCBhY2Nlc3MgcG9s aWNpZXMgdG8gdGhlIGNhcmVnaXZlciB3b3VsZCBiZSBhDQo+PiBxdWl0ZSBkaWZmZXJlbnQgYWdy ZWVtZW50Lg0KPg0KPkkgZG9uJ3Qgc2VlIGhvdyB0aGlzIGNvbnRyYWRpY3RzIHRoZSBhdXRob3Jp emF0aW9uIHByb2JsZW1zIGxpc3RlZCBpbg0KPnRoZSBhdXRob3JpemF0aW9uIHByb2JsZW1zIHN1 bW1hcnkgc2VjdGlvbiBvZiB0aGUgcGVyc29uYWwgaGVhbHRoDQo+bW9uaXRvcmluZyB1c2UgY2Fz ZS4gSXQgdXNlcyB0aGUgdGVybSAicHJpbmNpcGFsIiB0byByZWZlciB0byB0aGUgcGVyc29uDQo+ dGhhdCB3YW50cyB0byBwcm90ZWN0IHRoZSBtZWRpY2FsIGRhdGEuDQo+DQo+RG8geW91IHN1Z2dl c3QgdG8gYWRkIHRoZSBzY2VuYXJpbyB5b3UgYXJlIGRlc2NyaWJpbmcgdG8gdGhlIHBlcnNvbmFs DQo+aGVhbHRoIG1vbml0b3JpbmcgdXNlIGNhc2U/DQo+DQo+RG8geW91IHRoaW5rIHRoYXQgYSBw cm9ibGVtIGlzIG1pc3NpbmcgZnJvbSB0aGUgcGVyc29uYWwgaGVhbHRoDQo+bW9uaXRvcmluZyB1 c2UgY2FzZSBhbmQgaWYgc28sIGNvdWxkIHlvdSBkZXNjcmliZSB0aGUgcHJvYmxlbSB0aGF0IGlz DQo+bWlzc2luZz8NCj4NCj4+Pj4+IFlvdSBtYXkgc2F5IHRoYXQgeW91IG9ubHkgd2FudCB0byBz b2x2ZSBKb2huJ3MgcHJvYmxlbSwgaS5lLg0KPj4+Pj5wcm90ZWN0aW5nDQo+Pj4+PiBoaXMgbWVk aWNhbCBkYXRhLiBCdXQgdGhlbiB5b3UgYXJlIG5vdCBjb25zaWRlcmluZyB0aGUgcHJhY3RpdGlv bmVyJ3MNCj4+Pj4+IGludGVyZXN0LiBTaGUgd2lsbCB3YW50IHRvIGJlIHN1cmUgdGhhdCBvbmx5 IGF1dGhvcml6ZWQgZGF0YSBpcw0KPj4+Pj4gdHJhbnNtaXR0ZWQgdG8gaGVyIHNtYXJ0cGhvbmUu DQo+Pj4+IFdoYXQgZG9lcyAiYXV0aG9yaXplZCBkYXRh4oCdIG1lYW4/IFdpdGggdGhlIGFwcHJv cHJpYXRlIHNlY3VyaXR5IHNldHVwLA0KPj4+PiB0aGUNCj4+Pj4gc21hcnRwaG9uZSAodXNlciBk ZXZpY2UpIGNvdWxkIGF1dGhlbnRpY2F0ZSB0aGUgaGVhcnQgcmF0ZSBtb25pdG9yDQo+Pj4+IChw cm92aWRlciBkZXZpY2UpLCB2ZXJpZnkgdGhlIGludGVncml0eSBvZiB0aGUgZGF0YSwgdmVyaWZ5 IHRoYXQgaXQgaXMNCj4+Pj4gbm90DQo+Pj4+IGEgcmVwbGF5IG9mIGFuIG9sZCBjb21tdW5pY2F0 aW9uLCB2ZXJpZnkg4oCcZnJlc2huZXNzIiBvZiB0aGUNCj4+Pj4gY29tbXVuaWNhdGlvbg0KPj4+ PiBldGMuIEJ1dCBJIGd1ZXNzIHlvdSBtZWFuIHNvbWV0aGluZyBlbHNlPw0KPj4+IEkgbWVhbnQg dGhhdCBwcmFjdGl0aW9uZXIgd2lsbCB3YW50IHRvIGJlIHN1cmUgdGhhdCB0aGUgZGF0YQ0KPj4+ dHJhbnNtaXR0ZWQNCj4+PiB0byB0aGUgcHJhY3RpdGlvbmVyJ3Mgc21hcnRwaG9uZSBzdGVtcyBm cm9tIGFuIGF1dGhvcml6ZWQgc291cmNlLg0KPj4gSXQgaXMgc3RpbGwgbm90IGNsZWFyIHRvIG1l IHdoYXQgaXMgYW4g4oCcYXV0aG9yaXplZCBzb3VyY2XigJ0gbWVhbnMuIEkNCj4+IGltYWdpbmUg dGhlIHByb2Nlc3Mgb2YgZGV0ZXJtaW5pbmcgd2hhdCBpcyBhbiAiYXV0aG9yaXplZCBzb3VyY2Xi gJ0gY291bGQNCj4+YmUNCj4+IHF1aXRlIGRpZmZlcmVudCBmcm9tIGF1dGhvcml6aW5nIHRoZSBw cmFjdGl0aW9uZXIgdG8gYWNjZXNzIHBhdGllbnQNCj4+ZGF0YToNCj4+IFRoZSBwcmFjdGl0aW9u ZXIgZGVjaWRlcyB3aGVuIHRvIHJlcXVlc3QgZGF0YSBmcm9tIHRoZSBwYXRpZW50cyBkZXZpY2Us DQo+Pml0DQo+PiBjb3VsZCBiZSBwYXJ0IG9mIHRoYXQgcHJvY2VzcyB0byBzZWxlY3Qgd2hpY2gg ZGV2aWNlIHRvIGFjY2VzcywgdGh1cw0KPj4g4oCcYXV0aG9yaXppbmcgdGhlIHNvdXJjZeKAnT8N Cj4NCj5Vc2VyIChodW1hbiBiZWluZykgaW50ZXJhY3Rpb24gaXMgb25lIHBvc3NpYmxlIHNvbHV0 aW9uIGZvcg0KPmF1dGhvcml6YXRpb24gZm9yIGNhc2VzIHdoZXJlIHdlIGhhdmUgYW4gYWN0aXZl IHVzZXIuIEluIE0yTSBzY2VuYXJpb3MsDQo+dGhpcyBtaWdodCBub3QgYWx3YXlzIGJlIGFwcGxp Y2FibGUuDQo+DQo+Pj4+PiBJZiB5b3Ugd2FudCB0byB1c2UgQ29BUCBmb3IgdGhlIHRyYW5zbWlz c2lvbiBvZiB0aGUgZGF0YSwgaXQgaXMgbm90DQo+Pj4+PiBldmVuDQo+Pj4+PiBjbGVhciB3aGlj aCBkZXZpY2Ugd2lsbCBiZSB0aGUgY2xpZW50IGFuZCB3aGljaCB3aWxsIGJlIHRoZSBzZXJ2ZXIu DQo+Pj4+Pkl0DQo+Pj4+PiBtaWdodCBiZSB1c2VmdWwgaWYgdGhlIGhlYXJ0IHJhdGUgbW9uaXRv ciBpcyB0aGUgc2VydmVyIGFuZCB0aGUNCj4+Pj4+IHNtYXJ0cGhvbmUgaXMgdGhlIGNsaWVudCB0 aGF0IHJlcXVlc3RzIGRhdGEuIEJ1dCBpdCBtaWdodCBhbHNvIGJlDQo+Pj4+PiB1c2VmdWwNCj4+ Pj4+IGlmIHRoZSBoZWFydCByYXRlIG1vbml0b3IgaXMgdGhlIGNsaWVudC4gSSBkb24ndCBzZWUg YSBnb29kIHJlYXNvbiB0bw0KPj4+Pj4gcnVsZSBvdXQgb25lIG9mIHRoZXNlIHNldHRpbmdzLg0K Pj4+PiBMZXTigJlzIHRyeSB0aGUgdGVybWlub2xvZ3kgYWJvdmU6IHRoZSBoZWFydCByYXRlIHNl bnNvciBpcyBhICJwcm92aWRlcg0KPj4+Pm9mDQo+Pj4+IHNlbnNvciBkYXRhIiBhbmQgdGhlIHNt YXJ0cGhvbmUgaXMgYSAidXNlciBvZiBzZW5zb3IgZGF0YSIuIERvZXMgdGhhdA0KPj4+PiBtYWtl DQo+Pj4+IG1vcmUgc2Vuc2U/DQo+Pj4gSG0sIEkgZG9uJ3Qgc2VlIGhvdyB0aGlzIGhlbHBzIHVz LiBJZiB5b3Ugd2FudCB0byBiZSBhYmxlIHRvDQo+Pj5kaXN0aW5ndWlzaA0KPj4+IHRoZSBwcmFj dGl0aW9uZXIncyBzZWN1cml0eSBvYmplY3RpdmVzIGZyb20gSm9obidzIHNlY3VyaXR5IG9iamVj dGl2ZXMsDQo+Pj4gd2UgY291bGQgc3RhdGUgdGhhdCBleHBsaWNpdGVseSBpbiB0aGUgcHJvYmxl bSBzdW1tYXJ5Lg0KPj4gSSB0aGluayB0aGF0IHdvdWxkIGJlIGhlbHBmdWwuDQo+DQo+SSB0aGlu ayB0aGUgdXNlIGNhc2VzIGRvY3VtZW50IGFscmVhZHkgc3RhdGVzIHRoZSBwcm9ibGVtcyBvZiB0 aGUNCj5kaWZmZXJlbnQgaW52b2x2ZWQgcHJpbmNpcGFscyB3aGVyZSB0aGlzIGlzIHBvc3NpYmxl LiBFLmcuLCB0aGUgaG9tZQ0KPmF1dG9tYXRpb24gdXNlIGNhc2Ugc3RhdGVzIHByb2JsZW1zIHRo YXQgaG9tZSBvd25lcnMgaGF2ZS4gSWYgeW91IHRoaW5rDQo+dGhhdCB3ZSBtaXNzZWQgdG8gc3Rh dGUgYSBwcm9ibGVtIG9mIGEgcGFydGljdWxhciBzdGFrZWhvbGRlciwgcGxlYXNlDQo+cHJvdmlk ZSBkZXRhaWxzIG9uIHRoaXMgcHJvYmxlbSBzbyB0aGF0IHdlIGNhbiBhZGQgaXQgb3IgZXhwbGFp biBpdCBtb3JlDQo+Y2xlYXJseS4NCj4NCj4NCj5CZXN0IHJlZ2FyZHMsDQo+U3RlZmZpDQoNCg== From nobody Mon Feb 2 01:14: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 6EB771A007C for ; Mon, 2 Feb 2015 01:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.44 X-Spam-Level: X-Spam-Status: No, score=0.44 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvkEqf8JD0zW for ; Mon, 2 Feb 2015 01:14:05 -0800 (PST) Received: from outbox.sics.se (outbox.sics.se [193.10.64.137]) by ietfa.amsl.com (Postfix) with ESMTP id F23E31A0076 for ; Mon, 2 Feb 2015 01:14:04 -0800 (PST) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [192.36.171.201]) by outbox.sics.se (Postfix) with ESMTPS id 55272271 for ; Mon, 2 Feb 2015 10:14:03 +0100 (CET) Received: from norm.sics.se (norm.sics.se [193.10.64.192]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id t129E3wU007063 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 2 Feb 2015 10:14:03 +0100 Received: from [192.168.0.108] (unknown [85.235.11.178]) by norm.sics.se (Postfix) with ESMTPSA id EC930144 for ; Mon, 2 Feb 2015 10:14:02 +0100 (CET) Message-ID: <54CF3FDA.5060006@sics.se> Date: Mon, 02 Feb 2015 10:14:02 +0100 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: ace@ietf.org References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010405050007000807060500" X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sics-se:default, sics-se:default, base:default, @@RPTN) X-p0f-Info: os=Linux 2.2.x-3.x, link=Ethernet or modem X-CanIt-Geo: =?UTF-8?Q?ip=3D85.235.11.178; _country=3DSE; _region=3DSk=C3=A5ne; _city=3DLund; _latitude=3D55.7028; _longitude=3D13.1927; _http://maps.google.com/maps=3Fq=3D55.7028,13.1927&z=3D6?= X-CanItPRO-Stream: outbound-sics-se:outbound (inherits from outbound-sics-se:default, sics-se:default, base:default) X-Canit-Stats-ID: 09NLle3ta - e60538030966 - 20150202 X-Antispam-Training-Forget: https://canit.sunet.se/canit/b.php?i=09NLle3ta&m=e60538030966&t=20150202&c=f X-Antispam-Training-Nonspam: https://canit.sunet.se/canit/b.php?i=09NLle3ta&m=e60538030966&t=20150202&c=n X-Antispam-Training-Spam: https://canit.sunet.se/canit/b.php?i=09NLle3ta&m=e60538030966&t=20150202&c=s X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 85.235.11.178 is neither permitted nor denied by domain ludwig@sics.se) receiver=e-mailfilter01.sunet.se; client-ip=85.235.11.178; envelope-from=; helo=norm.sics.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: Subject: Re: [Ace] Role terminology in use case draft (Was: Container Use Case) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Feb 2015 09:14:08 -0000 This is a cryptographically signed message in MIME format. --------------ms010405050007000807060500 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable If the terminology threatens to become an advanced persistent threat to=20 consensus, we could perhaps reach a compromise by doing the following: Instead of trying to agree on specific terminology in the use case=20 draft, we use the names of the specific actors in each use case to=20 describe the authentication and authorization problems (like e.g. "the=20 fruit vendor", "the shipping company" etc). Do you think that would work as a compromise? My guess is that the=20 specific terminology is not that important for the use cases, it will=20 get important when we talk solutions. Regards, Ludwig Seitz --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=E4gen 17 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se --------------ms010405050007000807060500 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVDCC BhgwggUAoAMCAQICAwyGmDANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTE1MDEwODA4MzkwNloXDTE2MDEwOTIyNDEzMFowODEXMBUGA1UE AwwObHVkd2lnQHNpY3Muc2UxHTAbBgkqhkiG9w0BCQEWDmx1ZHdpZ0BzaWNzLnNlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxUHisC6rgXFsBHHBGo8ulz/cLX3gX5Ufhcwo rp+7djzMMuKPM1KOHq0bjWhmFe8ly8CzWdk2NS600t7IEBQWJiHLsdc12UqmNswQUpD7oqkR 1nRGT6leAHYTWapkR+nczZ2NxD+H7u4ZWVIZg0DFiTqtY8ghYHHYYy8BBoc/jHG78X4+JJAg s5XOa0gVl7W38vDvVpo14xhWEBGjzPk9WxWirqAF66PF+JEu2JD9LzFbpEq829SRXJMFB9wp oQNlH0UQ01/2sWCIBxPpHuEjxEF/V3Z/F2VsNTy4zvYrd+/MYO3w30F+bWQNZsMHEkTW1pEh iz7rQPWTBXoO8Fv0wQIDAQABo4IC1DCCAtAwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTqvKspqEm0E4R1sgsABYKk 6xDJqDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZBgNVHREEEjAQgQ5sdWR3 aWdAc2ljcy5zZTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcC AjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0 aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5 aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQEFBQADggEBAGXwFsbSfv4mMWqIk64CoxuR6ozo7J37igca7d9tpKIzVIp6xp7Zt+a+J9X3 1r4zgMRFnZJWQ5hy82W/fVDeG9i3NGMM6p7DNUrGjTbVHd11BQtbUOG9MSlyWKQbmt3Q1ElC f4SRLAQot5SPryLR2FTxQuFkMOrcDzVxNxnMgatOM2fAO8KS0H+wX+I7gC3pEnbg/eMqNgU+ Ktbc2y9naDNmLNLN65s8TT9xZyoQEn9S1oU8Xnh596OMu49Eccws8Ny+vAGESIHG4bqhMSjj rmDilL1Wj9nQahmBnID5oZD5g9s9KyqxiZIGNnowYYOpCrSeITZ1b7wg50dC8ySojnYwggY0 MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEw MjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0d Lep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiU fsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5Dp IpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuC YKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/ MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0j BBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzAB hhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nm c2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9 eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukD FUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyi kfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8Cnykh ExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b 970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCD z+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqA SfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNb BIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBth HSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+ UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAwyGmDAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTAyMDIwOTE0MDJaMCMGCSqGSIb3DQEJBDEW BBTx8RKt84g4epbwhzf2STstGSj8RDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDDIaYMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJKoZIhvcNAQEBBQAE ggEAOqhLyBXKyhnU4jIqirPtH9dRxcbFAwGM3STARo9g8mBOABnq7tyO4XDxlD2ubZt6Mt+X JHoKlJ1x9DvVmsaHTO6jtw5zAPZ8Jh9+uDp1rPCjBsmRxkoHH/7lIGhBMIx3wNySz2GLBiHL wCzWqpmPOJk3QBmDjGAt7Vj/nSL8yidDgQqEdpi/BJLjTyrZzn3+BzP7BWz014+fRUnkl1bY hUDObIm27k0MWz1HOZLKg7x2AC556dHKaj3IizmS00oRMml6iFT2IuJ0FJHBc2H37k9Bsnl3 S6xrvn88bbGbyiO/Qb/e6hoy8fgdaWMjI6efHrzDaSkYkCkLQoXKo9GjewAAAAAAAA== --------------ms010405050007000807060500-- From nobody Mon Feb 2 04:51: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 81D1A1A037F for ; Mon, 2 Feb 2015 04:51:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.529 X-Spam-Level: X-Spam-Status: No, score=-0.529 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MISSING_HEADERS=1.021] 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 AYYPToksZhY9 for ; Mon, 2 Feb 2015 04:51:43 -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 206461A037E for ; Mon, 2 Feb 2015 04:51:42 -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 t12CpcTV005219 for ; Mon, 2 Feb 2015 13:51:38 +0100 (CET) Received: from [192.168.1.125] (pD9F61029.dip0.t-ipconnect.de [217.246.16.41]) (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 3kbTYk35cvz2P2X for ; Mon, 2 Feb 2015 13:51:38 +0100 (CET) Message-ID: <54CF72DA.6060401@tzi.de> Date: Mon, 02 Feb 2015 13:51:38 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 CC: "Ace@ietf.org" References: <54BF9029.4060200@tzi.de> <54C22C2C.9050709@tzi.de> <54C64DEE.3040608@tzi.de> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] Role terminology in use case draft (Was: Container Use Case) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Feb 2015 12:51:46 -0000 Hi Göran, We are currently preparing an update of the use cases draft that hopefully will address some of the issues we discussed earlier. On 01/29/2015 05:42 PM, Göran Selander wrote: > Hi Steffi > > In summary, I think it is an issue that the authorization problem > formulations in the use case document does not take into account the a > priori difference between providing access to sensor measurements vs > accessing a sensor measurement. Or providing access to an actuator service > vs accessing an actuator service. For example, the authorization problem > of opening a lock on a specific request is different from the problem of > making sure that it is the right lock to open. Or revealing to the lock > that you intend to open it. Or what exactly is the relevant problem on the > accessing side? This would be good to clarify in the use case document. If there is a problem missing from the use cases, please provide details about this problem so that we can add it. For your lock example, we might add to the home automation use case that the smartphone of Alice's parents needs to make sure that it is communicating with the right lock. Is that what you are aiming at? > There may be different solutions to the problem of the providing side and > the problem on the accessing side. Or maybe the same standardized solution > can be applied in two instances? To understand that we also need to > formulate the problems. > > Furthermore, I think it is an issue with a terminology which does not > allow these distinctions to be made so that the different problems can be > formulated. I think one part of the terminology problem is that the term > “resource” is overloaded. For example, resource is used (a) in the > REST/CoAP meaning what is requested on the server side and (b) as “item > of interest”, which could be anything on both requesting and responding > side. Since the existing authorization frameworks such as OAuth and UMA > has a built in asymmetry between authorizing party and requesting party, > the burden of proof deviating from that rests with the authors of this > draft. It could be a conclusion of the use case draft that this is a > symmetric problem, and that the problems on each side is of equal > importance. It should not be an assumption. As far as I'm aware of, the use cases draft uses the REST definition of the term "resource". I didn't see evidence that it is used incorrectly. But if I missed something, please point me to the respective section. I think RFC7252 uses the term "resource representation" to refer to a copy of the data of a resource. Maybe you can use this to describe your problem? I'm not sure if I understand what you mean with "symmetric problem". I think we agree that the two parties that participate in a communication may have different authorization problems. E.g., patients may want to restrict who is able to access their medical data while practitioners may want to make sure that their devices only accept authorized medical data. In this case we have two endpoints whose principals need different problems to be solved. Each participating party may need to authorize the other party. Is that what you mean with "symmetric"? > I proposed to switch temporarily to a different terminology based on > “provider” and “user” (a variant of that used in the SENSEI project) just > to avoid the potential problem with overloading the term "resource”. More > comments inline. > > > > On 2015-01-26 15:23, "Stefanie Gerdes" wrote: > >> Hi Göran, >> >> >> On 01/26/2015 09:27 AM, Göran Selander wrote: >>> Hi Steffi, >>> >>> Thank you for your patient explanations. I am happy that we agree to >>> leave >>> out device ownership. >>> >>> Regarding the remaining argumentation I’m sad to say that I’m still not >>> convinced. In short: I think we should have a terminology in the use >>> case >>> document which allow us to express the concrete authorization problems >>> of >>> the use cases in terms of this terminology. If I understand you right, >>> you >>> say that we can’t express the authorization problems in terms of >>> Resource, >>> Resource Owner (= Resource Principal), etc. because who is Resource >>> Owner >>> may depend on solution. If that is the case, then I think we have a >>> problem. In my opinion, either the terminology is not appropriate, or >>> there is some problem with the application of the terminology to the use >>> cases. >>> >>> To eliminate the former, allow me to take a step back and attempt a >>> preliminary terminology to reach a common ground of understanding. Let >>> me >>> know to what extent we can agree on this: >>> >>> In the use cases we focus on “things" like sensors (temperature sensors, >>> heart rate sensors etc.) and actuators (fan actuators, lock actuators >>> etc.); and related data like sensor measurements (temperatures, heart >>> rates, etc.) and actuator settings (fan configuration settings, lock >>> open/closed, etc. ). All these are "items of interest", or "assets" that >>> needs to be protected, some of which is in scope of this working group. >>> >>> In order to distinguish between the party providing a sensor/actuator >>> service and the party using the service we can use the terminology >>> “provider” (of sensor/actuator services) and “user” (of sensor/actuator >>> services). One important security problem in scope of this working group >>> deals which devices are allowed to read from a sensor or write to an >>> actuator. In detail this means for example that a device associated to a >>> user may or may not “read" measurements from a device associated to a >>> provider of sensor services. Analogously a device associated to a user >>> may >>> or may not “write" actuator settings to a device associated with a >>> provider of actuator services. There may be other security problems as >>> well and we should list them and decide if they are in scope. >>> >>> Are we OK on this level? >> I don't see how this terminology will help us with the authorization >> solution. In CoAP, the server is not necessarily the sensor/actuator. >> The protection of sensor or actuator values does not really fit to the >> protection of CoAP resources (that are identified by a URI). >> >> Moreover, one of the endpoints may be a sensor while the other may be an >> actuator and we thus would have two providers. > Yes, that is fine. They provide different services. If we have a solution > to the "provider authorizes user problem" we can apply it twice. I can't really imagine how this would work in praxis. But this would be one possible solution to address this problem, I guess. As far as I'm aware of, the use cases draft doesn't prevent this kind of solution. >> I agree that we want to protect items of interest. If you want to cut >> down the problem to "we protect the item of interest by defining who is >> allowed to read/write the item on one side" you are only addressing half >> of the problem. We don't get around the problem that there may be two >> parties with different interests involved by renaming them or by trying >> to fit the use cases to a model, where it is clear which party requests >> and which party provides an item of interest. We will only gain an >> authorization solution that restricts the possibilities of CoAP. >> >> I don't like the term "user" since it implies the presence of a human >> being. I don't know if that's what you have in mind? > The preliminary terminology I proposed was a variant of that used in the > SENSEI project. In that project we used the terms “Resource Provider” and > “Resource User”, but I wanted to avoid the notion of Resource as explained > above. I agree the notion “User” is not perfect. I called the terminology > “preliminary” because it was intended as a means to get around what think > is an overload of terms in your current proposal. We could of course > rename terms, but for now it is just a matter of having terms that clearly > distinguish between the different functions. > > > >>>> Moreover, in a >>>> scenario where two different parties may be involved, one that requests >>>> a representation of the resource and one that provides the resource >>>> representation, these two parties may have different interests and thus >>>> have different problems that need to be solved by an authorization >>>> solution. Thus, the resource owner's problems are not the only problems >>>> we need to consider. >>> What you just stated is very close to the point I want to make. It seems >>> we agree that there is a difference between the party providing and the >>> party requesting. Therefore we need a terminology to describe how this >>> difference applies to the authorization problems (in the sections >>> entitled “Authorization Problem Summary” in the use case document). >> I don't think that these differences apply to the security objectives >> that the involved parties may want to achieve. As a principal, I don't >> care whether I request an item or provide an item. Regardless of the >> setting I want to make sure that my security objectives are achieved. > I see two quite different problems: I’m fine with “authorization to > provide an item”, i.e. the provider authorizes a user with an item. This > is an inter domain problem which is naturally mapped to a RESTful > request/response protocol. I have a problem with “authorization to request > an item” i.e. that the user authorizes itself to send a request for an > item. I see that as a user domain internal problem which is not > necessarily cast in a RESTful request/response message exchange. And if it > is, then we can solve authorization of RESTful request and apply it twice: > Once on the inter-domain problem and once on the user internal user domain > problem. I don't quite understand what the definition of "user" is in your proposed terminology. Is "user" a principal, i.e. a human being in your scenario or is it a device/endpoint? If the user is a principal, it will have some kind of endpoint that communicates with another endpoint. If the user is an endpoint, it will have a principal. In both cases the principal may want to make sure that her endpoint is only communicating with authorized endpoints. I don't know what "user domain internal problem" refers to in this scenario. Regardless of how you name this problem, it is an authorization problem and thus is listed in the use cases draft. It is the purpose of the draft to list authorization problems. A solution might not address all of the listed problems but I don't think it is a good idea to leave out problems because a certain solution might not address them. >>>> For CoAP, the entity that controls the access permissions to a CoAP >>>> resource will likely be the resource owner, and thus the owner of the >>>> data that is stored there. If you are transmitting data to that >>>> resource, you are the resource owner as long as you control the access >>>> permissions for this resource. If you are transmitting data to someone >>>> else's CoAP resource you are giving up ownership for this copy of the >>>> data. >>> I agree that sensor and actuator related data needs to be secured >>> end-to-end between user device and provider device, and that this is >>> part >>> of the authorization problem: access control to sensor data may be of >>> limited value if sent in plain text; access control to actuation data >>> needs to be integrity protected, etc. But I’m not sure I understand what >>> you mean with "data ownership”. Sensor data is provided in protected >>> form >>> to an authorized user, what the user does with this data is beyond the >>> scope of this working group, isn’t it? Isn’t that more like an agreement >>> between the parties? I assume you are not thinking of digital rights >>> management. >> I don't think the term "user" is helpful here. There may be two devices >> communicating without any user interaction. >> >> I am just trying to explain that there are two parties involved in >> exchanging an item of interest. Each one of these parties may have their >> own security objectives. The sender will want to make sure that the >> receiver is authorized to get the data, the receiver will want to make >> sure that the sender is authorized to send the data. >> >> In a concrete use case, I see no evidence who the sender and who the >> receiver will be. > Maybe this is a reason why the terminology is not suitable? There is a > difference between who is providing a sensor/actuator service and who is > using it. And expressing that difference allows us to elaborate on the > roles in the use cases. It seems to me that you are trying to find a terminology where we only have one party with an authorization problem. > >>>> If you want to make sure that the owner of the data never changes you >>>> will have to make sure that the resource owner can control the access >>>> permissions for this data on all devices where the data is transmitted >>>> to. Even if data is transmitted to a requesting client you are giving >>>> up >>>> ownership for the copy of the data that you are transmitting, unless >>>> you >>>> can control access policies for the data on the client. You may control >>>> your own copy of the data, but not the client's copy. >>>> >>>> I don't think it's so clear that the patient is always the resource >>>> owner in a healthcare scenario. >>> Yes, as I mentioned in my previous mail “In Sweden, the caregiver will >>> set >>> access policies “. Is there some confusion about the term “caregiver”? I >>> meant the administrative representative of the doctor etc. - roughly the >>> same as your term “practitioner”. >> It seemed to me that you wanted to suggest that we use the terminology > >from UMA where in one use case the patient is the resource owner. In >> this case the patient would be the one that is in control of the access >> policies. >> >> So we agree that it's not clear whether the patient or the >> caregiver/practitioner is the resource owner? > There are differences in legislation in different countries and you may > have different agreements between patient and caregiver etc. However, with > a given legislation and agreement, it is clear who is provider. > >>>> Let's assume that in the personal health >>>> monitoring case, a practitioner receives data from John's heart rate >>>> monitor with her smartphone. John is the owner of the heart rate >>>> information while it is on the heart rate monitor. He wants to control >>>> who is able to access this data. But I think it is unlikely that the >>>> practitioner will let John configure access policies for data on her >>>> device. She gains ownership for her copy of John's data since she is >>>> the >>>> one that controls the access policies. >>> I see two (or one-and-a-half) authorization problems here. The first >>> authorization problem is with John as “provider” of sensor measurments >>> and >>> the practitioner as “user”. The second problem is with the practitioner >>> as provider (trusted proxy), but how that data is used is not described >>> (this is what I meant by “and-a-half”). >>> >>> If we can have a solution to how a provider can set policies for access >>> to >>> data and only grant access to authorized users, then we could apply this >>> solution twice: first with John as provider, then with the practitioner >>> as >>> provider. Of course, there must be an agreement between John and the >>> practitioner about the practitioner acting provider for this data, but I >>> don’t think that is in scope of this working group. >> Okay, so we agree that we need a solution that addresses the >> authorization problems of both endpoints in a conversation? > As mentioned, I see in your example a sequence of two authorization > problems. > > Let me add that I find the example a bit "made up". What I’m familiar with > from Ericsson Mobile Health is the case when the caregiver provides the > health monitor sensor to the patient (in practice the patient gets a > briefcase with one or more sensors and a cellular communication module). > This is a more natural situation, because then the caregiver can assume a > large responsibility for the measurement including equipment maintenance > and instructing the patient how to make the measurement in a correct way > given the equipment used etc. This situation has more in common with the > traditional setup between patient and caregiver, although the patient is > requested to perform simple tasks replacing a nurse. Hence a similar > agreement between patient and caregiver in the country in question can be > applied, including who has the rights to set access control policies. The > example you provide where the patient owns the heart rate monitor and > transfers rights to the set access policies to the caregiver would be a > quite different agreement. I don't see how this contradicts the authorization problems listed in the authorization problems summary section of the personal health monitoring use case. It uses the term "principal" to refer to the person that wants to protect the medical data. Do you suggest to add the scenario you are describing to the personal health monitoring use case? Do you think that a problem is missing from the personal health monitoring use case and if so, could you describe the problem that is missing? >>>> You may say that you only want to solve John's problem, i.e. protecting >>>> his medical data. But then you are not considering the practitioner's >>>> interest. She will want to be sure that only authorized data is >>>> transmitted to her smartphone. >>> What does "authorized data” mean? With the appropriate security setup, >>> the >>> smartphone (user device) could authenticate the heart rate monitor >>> (provider device), verify the integrity of the data, verify that it is >>> not >>> a replay of an old communication, verify “freshness" of the >>> communication >>> etc. But I guess you mean something else? >> I meant that practitioner will want to be sure that the data transmitted >> to the practitioner's smartphone stems from an authorized source. > It is still not clear to me what is an “authorized source” means. I > imagine the process of determining what is an "authorized source” could be > quite different from authorizing the practitioner to access patient data: > The practitioner decides when to request data from the patients device, it > could be part of that process to select which device to access, thus > “authorizing the source”? User (human being) interaction is one possible solution for authorization for cases where we have an active user. In M2M scenarios, this might not always be applicable. >>>> If you want to use CoAP for the transmission of the data, it is not >>>> even >>>> clear which device will be the client and which will be the server. It >>>> might be useful if the heart rate monitor is the server and the >>>> smartphone is the client that requests data. But it might also be >>>> useful >>>> if the heart rate monitor is the client. I don't see a good reason to >>>> rule out one of these settings. >>> Let’s try the terminology above: the heart rate sensor is a "provider of >>> sensor data" and the smartphone is a "user of sensor data". Does that >>> make >>> more sense? >> Hm, I don't see how this helps us. If you want to be able to distinguish >> the practitioner's security objectives from John's security objectives, >> we could state that explicitely in the problem summary. > I think that would be helpful. I think the use cases document already states the problems of the different involved principals where this is possible. E.g., the home automation use case states problems that home owners have. If you think that we missed to state a problem of a particular stakeholder, please provide details on this problem so that we can add it or explain it more clearly. Best regards, Steffi From nobody Mon Feb 2 06:53: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 A389B1A1AF9 for ; Mon, 2 Feb 2015 06:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.15 X-Spam-Level: X-Spam-Status: No, score=-0.15 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N15I49iLQPtJ for ; Mon, 2 Feb 2015 06:53:16 -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 AA5C51A1AFB for ; Mon, 2 Feb 2015 06:53:15 -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 t12ErC8p011727; Mon, 2 Feb 2015 15:53:12 +0100 (CET) Received: from [192.168.1.125] (pD9F61029.dip0.t-ipconnect.de [217.246.16.41]) (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 3kbXG05cqjz2PBN; Mon, 2 Feb 2015 15:53:12 +0100 (CET) Message-ID: <54CF8F58.9060803@tzi.de> Date: Mon, 02 Feb 2015 15:53:12 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ludwig Seitz , ace@ietf.org References: <54CF3FDA.5060006@sics.se> In-Reply-To: <54CF3FDA.5060006@sics.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ace] Role terminology in use case draft (Was: Container Use Case) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Feb 2015 14:53:16 -0000 Hi Ludwig, On 02/02/2015 10:14 AM, Ludwig Seitz wrote: > If the terminology threatens to become an advanced persistent threat > to consensus, we could perhaps reach a compromise by doing the following: > > Instead of trying to agree on specific terminology in the use case > draft, we use the names of the specific actors in each use case to > describe the authentication and authorization problems (like e.g. "the > fruit vendor", "the shipping company" etc). > > Do you think that would work as a compromise? My guess is that the > specific terminology is not that important for the use cases, it will > get important when we talk solutions. For the principals this might work in the problem summary sections. It might even make it easier to understand them. We would need to make sure that we don't lose important information. For some use cases we need client and server (or resource server) to express the problem that needs to be solved, e.g. U5.7. I am not sure about 2.7. We would also need a term for resources and resource representations (or items of interest), since this is necessary to describe the problems. In the security considerations section we try to derive facts from the use cases and would therefore need to use a more general terminology for principals (e.g. the term principal). Best regards, Steffi From nobody Wed Feb 4 00:05: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 9EBFB1A6FEA for ; Wed, 4 Feb 2015 00:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.15 X-Spam-Level: * X-Spam-Status: No, score=1.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dO5-UE-opa2S for ; Wed, 4 Feb 2015 00:05:52 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 672551A6FE9 for ; Wed, 4 Feb 2015 00:05:52 -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 t1485mBW001646 for ; Wed, 4 Feb 2015 09:05:48 +0100 (CET) Received: from alma.local (p5DCCC7CE.dip0.t-ipconnect.de [93.204.199.206]) (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 3kcb700yZ2z2Nyv; Wed, 4 Feb 2015 09:05:48 +0100 (CET) Message-ID: <54D1D2DB.4050901@tzi.org> Date: Wed, 04 Feb 2015 09:05:47 +0100 From: Carsten Bormann User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Ace@ietf.org" References: <37F0744B-E6B9-4BEC-935F-091BBA0940CE@ieca.com> In-Reply-To: <37F0744B-E6B9-4BEC-935F-091BBA0940CE@ieca.com> Content-Type: text/plain; charset=gbk Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] Arguments to publish use case document as RFC X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 08:05:55 -0000 On 2015-01-29 19:13, Sean Turner wrote: [a number of good thoughts.] > Put me in the camp that thinks this uc/req draft should be published > now. +1. Main reasons: We still have the energy*), and we want to get this off the table so we can use it (as intended) as input for the specification-level discussion of the WG. On a more meta level, I'm hearing a number of good arguments for not wanting to use up WG time upfront on something like a use case document. Now in this case, that doesn't apply: We already did use up that time. More generally speaking, getting a good view of the use cases is a good use of WG time *if* the "requirements engineering" (bickering around the requirements until your solution looks best) phase can be avoided. Should this be published as an RFC? Yes, some of our views might change over time, and yes, that publication process does consume some valuable IESG time, but there are a lot of good arguments for publication. -- First of all, the document simply is good. Real RFC material. -- Getting it published can help it guide the discussions (including making it so much easier to introduce new people to what the work is about). -- The process of getting it published usually supplies a final jolt of energy that can make the document even better (and increase the focus of the WG in the process). It is hard to overestimate this effect. -- Diversity.**) Indeed, this is a "start-of-WG" style use cases document, and it doesn't hurt to label it as such -- this is not trying to cover the surface of the earth. Gruesse, Carsten *) As a WG chair of the former 6LoWPAN WG, I can tell you it is not a good experience to have informational input documents drag on in parallel with the main specification work. Please let's avoid a repeat of that experience. **) OK, that was a rather opaque comment at the microphone in Honolulu. Let me expand: If we want to have inclusion of academics, we need to consider what makes them tick. The coin in which academics are paid is publication. Not giving them the opportunity of publication means they can't reasonably invest their time. We don't want to limit ourselves to the help of unreasonable academics. From nobody Wed Feb 4 05:14: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 79B1F1A87F0 for ; Wed, 4 Feb 2015 05:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 lVa_mLP5oZzj for ; Wed, 4 Feb 2015 05:14:15 -0800 (PST) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6D411A00E4 for ; Wed, 4 Feb 2015 05:14:14 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id f12so973534qad.10 for ; Wed, 04 Feb 2015 05:14:14 -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=3mDIwvKEeKxob/cIpxLWdDvrnr3Xv3WVX635PxjpRzE=; b=JznUPUPIQrMTCc2L3ttVGmLBFWipHf6lHTA+fQ7Bl0eiEB586U8Y6zfW+lLIcrRc64 /yRJXjp+owMIX++F3V1dkKfzGjbyRKe/TC13vxcqqqa3zJGvxWNLLgfajNyWdwUSa8b1 1AR10N2JHgQd8Afj2je6S7G4uRY4DjCl88LLd8W4g101ZSdYxFFQb9k4AkyexfMctj6o eoOLXqmFTxxhP0I7D+XtMqHkfKi8yeiwaSeHwcvex5u7WFHSaRYIebbRyMFgaj4PvdfP kz/4/iFJWMCSvtyZbVVHJ1kL/vO7+qrC5TVC5m3zHjdoqhjbXQx0h1O641duaKdXfn6z F3tA== X-Received: by 10.140.41.113 with SMTP id y104mr60337506qgy.51.1423055654066; Wed, 04 Feb 2015 05:14:14 -0800 (PST) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id y5sm1654695qah.38.2015.02.04.05.14.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Feb 2015 05:14:13 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <54D1D2DB.4050901@tzi.org> Date: Wed, 4 Feb 2015 08:14:12 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <37F0744B-E6B9-4BEC-935F-091BBA0940CE@ieca.com> <54D1D2DB.4050901@tzi.org> To: Carsten Bormann Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Arguments to publish use case document as RFC X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 13:14:19 -0000 Thanks for your input, Carsten. Inline. Sent from my iPhone > On Feb 4, 2015, at 3:05 AM, Carsten Bormann wrote: >=20 > On 2015-01-29 19:13, Sean Turner wrote: >=20 > [a number of good thoughts.] >=20 >> Put me in the camp that thinks this uc/req draft should be published >> now. >=20 > +1. Main reasons: We still have the energy*), and we want to get this > off the table so we can use it (as intended) as input for the > specification-level discussion of the WG. >=20 > On a more meta level, I'm hearing a number of good arguments for not > wanting to use up WG time upfront on something like a use case document. > Now in this case, that doesn't apply: We already did use up that time. > More generally speaking, getting a good view of the use cases is a good > use of WG time *if* the "requirements engineering" (bickering around the > requirements until your solution looks best) phase can be avoided. >=20 > Should this be published as an RFC? Yes, some of our views might change > over time, and yes, that publication process does consume some valuable > IESG time, but there are a lot of good arguments for publication. > -- First of all, the document simply is good. Real RFC material. > -- Getting it published can help it guide the discussions (including > making it so much easier to introduce new people to what the work is > about). > -- The process of getting it published usually supplies a final jolt of > energy that can make the document even better (and increase the focus > of the WG in the process). It is hard to overestimate this effect. > -- Diversity.**) >=20 > Indeed, this is a "start-of-WG" style use cases document, and it doesn't > hurt to label it as such -- this is not trying to cover the surface of > the earth. >=20 > Gruesse, Carsten >=20 > *) As a WG chair of the former 6LoWPAN WG, I can tell you it is not a > good experience to have informational input documents drag on in > parallel with the main specification work. Please let's avoid a repeat > of that experience. >=20 > **) OK, that was a rather opaque comment at the microphone in Honolulu. > Let me expand: If we want to have inclusion of academics, we need to > consider what makes them tick. The coin in which academics are paid is > publication. Not giving them the opportunity of publication means they > can't reasonably invest their time. We don't want to limit ourselves > to the help of unreasonable academics. I think this might apply more to engaging real customers as opposed to resea= rchers. We are interested to develop real solutions that will get used. Re= searchers might best help us with awareness on new techniques (their researc= h or research they are aware of). If researchers are guided by real world p= roblems working with customers, then perhaps they might be he authors of use= case drafts. In any case, these are 2 groups we don't have enough of and n= eed to encourage their participation. Thanks for the helpful input! Kathleen=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Thu Feb 5 02:12: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 D64F31A01F0 for ; Thu, 5 Feb 2015 02:12:13 -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 v0-S1YDqD9lU for ; Thu, 5 Feb 2015 02:12: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 371241A0211 for ; Thu, 5 Feb 2015 02:12: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 [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t15AC6ce008525 for ; Thu, 5 Feb 2015 11:12:06 +0100 (CET) Received: from [192.168.1.109] (p57A63C97.dip0.t-ipconnect.de [87.166.60.151]) (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 3kdFtG4tH3z2NvC for ; Thu, 5 Feb 2015 11:12:06 +0100 (CET) Message-ID: <54D341F6.9040109@tzi.de> Date: Thu, 05 Feb 2015 11:12:06 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Ace@ietf.org" References: <20150205095841.19111.5154.idtracker@ietfa.amsl.com> In-Reply-To: <20150205095841.19111.5154.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150205095841.19111.5154.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Ace] Fwd: I-D Action: draft-ietf-ace-usecases-02.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 10:12:14 -0000 Hi all, We submitted a new version of the use cases draft. Most changes are terminology changes: Instead of "Device Owner", the document now uses "Client Owner" or "Principal". Where applicable, "device" was replaced by "endpoint" accordingly. In 3.2 the phrasing of first item was changed according to the discussion on the list. Best regards, Steffi -------- Forwarded Message -------- Subject: I-D Action: draft-ietf-ace-usecases-02.txt Date: Thu, 05 Feb 2015 01:58:41 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: ace@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments Working Group of the IETF. Title : ACE use cases Authors : Ludwig Seitz Stefanie Gerdes Goeran Selander Mehdi Mani Sandeep S. Kumar Filename : draft-ietf-ace-usecases-02.txt Pages : 24 Date : 2015-02-05 Abstract: Constrained devices are nodes with limited processing power, storage space and transmission capacities. These devices in many cases do not provide user interfaces and are often intended to interact without human intervention. This document comprises a collection of representative use cases for the application of authentication and authorization in constrained environments. These use cases aim at identifying authorization problems that arise during the lifecylce of a constrained device and are intended to provide a guideline for developing a comprehensive authentication and access control solution for this class of scenarios. Where specific details are relevant, it is assumed that the devices use the Constrained Application Protocol (CoAP) as communication protocol, however most conclusions apply generally. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ace-usecases-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ace-usecases-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Thu Feb 5 07:05: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 E14BC1A0267; Thu, 5 Feb 2015 01:58:42 -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] 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 AnbXCziKTe6d; Thu, 5 Feb 2015 01:58:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 993A51A0222; Thu, 5 Feb 2015 01:58:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150205095841.19111.5154.idtracker@ietfa.amsl.com> Date: Thu, 05 Feb 2015 01:58:41 -0800 Archived-At: X-Mailman-Approved-At: Thu, 05 Feb 2015 07:05:14 -0800 Cc: ace@ietf.org Subject: [Ace] I-D Action: draft-ietf-ace-usecases-02.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 09:58:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments Working Group of the IETF. Title : ACE use cases Authors : Ludwig Seitz Stefanie Gerdes Goeran Selander Mehdi Mani Sandeep S. Kumar Filename : draft-ietf-ace-usecases-02.txt Pages : 24 Date : 2015-02-05 Abstract: Constrained devices are nodes with limited processing power, storage space and transmission capacities. These devices in many cases do not provide user interfaces and are often intended to interact without human intervention. This document comprises a collection of representative use cases for the application of authentication and authorization in constrained environments. These use cases aim at identifying authorization problems that arise during the lifecylce of a constrained device and are intended to provide a guideline for developing a comprehensive authentication and access control solution for this class of scenarios. Where specific details are relevant, it is assumed that the devices use the Constrained Application Protocol (CoAP) as communication protocol, however most conclusions apply generally. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ace-usecases-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ace-usecases-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 5 15:27:00 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0611A0BE8; Thu, 5 Feb 2015 15:26:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 slnKCIf5mQgx; Thu, 5 Feb 2015 15:26:43 -0800 (PST) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::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 C41661A0016; Thu, 5 Feb 2015 15:26:42 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id l4so12821552lbv.13; Thu, 05 Feb 2015 15:26:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=kPg3WXcOqhy6w9vxqceCZEXE/E+i2/wslEFOgaLNbv8=; b=r9QmVriD5uoftSahxLHb8qf+HwObqnJi+zoD8yevPqpDCTcIqGfAerdByS6EJbe746 xCY6VU9FZgHFmUKGndLeb3LwLLS7w6BGqjjishBFpZRk5CfVej3FXZWoSDkI3bz6jLUG QB3ltDu2xHXfbwrxV5gl4BMhUuesgVLDoGQViqDFK0DE4neT8L/+8pXMjy2J9G+qHrZq 0NkEIjN73ivXIHdUgaSvK9P4LmvhWMSj2AIhVNOUsKXMnpoYzig0zJLIYi6Jy56HxM5u Q8yyvaclrhAWSOy67q9Higucg4kz6H8XxJU4+pm0ig5gzSByOMeZFfJmLwERQ4/vewxo Nufg== MIME-Version: 1.0 X-Received: by 10.152.7.38 with SMTP id g6mr428710laa.65.1423178801288; Thu, 05 Feb 2015 15:26:41 -0800 (PST) Received: by 10.112.167.134 with HTTP; Thu, 5 Feb 2015 15:26:41 -0800 (PST) Date: Thu, 5 Feb 2015 18:26:41 -0500 Message-ID: From: Kathleen Moriarty To: "ace@ietf.org" , "sacm@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2906ce71a98050e5fa2db Archived-At: Subject: [Ace] Use Case drafts - should they be published summary X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 23:26:49 -0000 --001a11c2906ce71a98050e5fa2db Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, Sorry for the cross post, both WGs helped develop a list of arguments on why their use case draft should be published. I didn't get many messages (and the chairs didn't either in private), so it seems most are in favor of publishing use cases drafts. I'll plan to chat about this with the IESG next week and wanted to share my summary of reasons. I ordered them, but didn't spend too much time editing, as this won't be a living document (at least in this state). Thanks again for your assistance! ---- *Use Case Drafts: Should they be published?* *Reasons in favor:* 1. If this is part of the WGs charter and a milestone, the work has already been agreed to be done and there is an expectation from those working on it that it will be published. The WG has probably already sucked up this time if it's on the charter. It would be unfair to pull = it now. 2. The IESG is here to serve the IETF. If there is consensus to publish a use case draft, it should go forward. 3. If the WG wants it published, it ought to be darn well be published. There=E2=80=99s no prohibition against uc/req drafts that I=E2=80=99m aw= are of *AND* it=E2=80=99s an Informational RFC after all it=E2=80=99s *NOT* a standards track RFC.= There ought to be a lower bar for informational vs standards track and if ther= e isn=E2=80=99t one then that=E2=80=99s really the IESG=E2=80=99s fault. 4. The use cases draft helps to frame the problem(s) being addressed by the WG proposals and is important for guiding future development as well= as recording the history of consensus about the scope of work. 5. Allows WGs to get cross-area review and IESG input earlier in the process on the whole WG concept. That might be possible with just an IE= TF LC, but that seems like a bit of a waste of time and probably wouldn=E2= =80=99t be taken seriously by the reviewers without a =E2=80=9Cthreat=E2=80=9D of p= ublication. 6. They are usually informational with no RFC2119 language and should be easier to process. 7. It is desirable to have a published document that can be found later to better understand the scope of work produced by a WG or can be used t= o get a newcomer up-to-speed. While an expired draft can technically be found, it's existence may not be known by those interested to read the draft. Dave Crocker's dependency graph off the WG page in the data track= er include expires drafts. Some expired drafts should go away, how would o= ne distinguish in a traceable and helpful way? You can't rely on wiki's to= be maintained after WGs disappear. 8. A wiki to maintain this type of data is too dynamic and can't be trusted. How do you distinguish versions and changes over time even if = it isn't published as an RFC until the solutions are closer to final? 9. In most scientific publications, referencing a weblink (like e.g. a wiki) is strongly discouraged due to their ephemeral nature. Having an R= FC number is not only nice to have, it is quite essential if one is to refe= r to this document in any serious article. 10. The process of getting it published usually supplies a final jolt of energy that can make the document even better (and increase the focus of the WG in the process). It is hard to overestimate this effect. 11. From the ACE WG: One obvious reason for having this as a WG draft (published or not) is that some felt their input wasn't considered when = it was an individual draft. 12. People might be more motivated to contribute to a WG draft than to an individual draft. People will also be more motivated to contribute i= f the final result is a published document that they can point to when someone (employer, sponsor) asks them what the result of their work was. 13. Publishing the draft as (informational) RFC also helps to valorize the work that the authors put into this document. If the draft is just published as a wiki, this sends the message to many readers that IETF didn't consider this a worthy enough contribution for a real publication= . This would also discourage future contributions to such documents (especially by scientists). 14. WGs still have the energy*, and want to get this off the table so they can use it (as intended) as input for the specification-level discussion of the WG. Note: this may be especially true for newcomers to the IETF, it will help for them to see a progression of drafts and that work can move along. 15. Diversity: If we want to encourage customer participation, this is one of the key areas in which they can contribute and have a positive impact on the work. This may also help researchers who may be involved = in use cases or subsequent phases where they raise awareness of existing wo= rk to solve the problems discussed in the scope of work. *Opposition:* 1. It's time consuming for the IETF and ideally would have been completed prior to WG formation. By the time use cases are complete, fo= lks interested in solutions may have walked away already to go do something real, develop code. 2. This process doesn't keep pace with the open source community and should be a pre-cursor to WG formation. We need to figure out how to sp= eed up. 3. Use cases may be a moving target and may evolve over the course of the WG life. ---- Best regards, Kathleen --001a11c2906ce71a98050e5fa2db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

Sorry for the cross post, both WGs helped de= velop a list of arguments on why their use case draft should be published.= =C2=A0 I didn't get many messages (and the chairs didn't either in = private), so it seems most are in favor of publishing use cases drafts.
=
I'll plan to chat about this with the IESG next week and wanted to = share my summary of reasons.=C2=A0 I ordered them, but didn't spend too= much time editing, as this won't be a living document (at least in thi= s state).

Thanks again for your assistance!

----

Us= e Case Drafts: Should they be published?

Reasons in favor:

  1. If this is part of the WGs charter and a milestone, the wo= rk has already been agreed to be done and there is an expectation from thos= e working on it that it will be published.=C2=A0 The WG has probably alread= y sucked up this time if it's on the charter.=C2=A0 It would be unfair = to pull it now.
  2. The IESG is here to serve the IETF.=C2=A0 If th= ere is consensus to publish a use case draft, it should go forward.
  3. If the WG wants it published, it ought to be darn well be published. T= here=E2=80=99s no prohibition against uc/req drafts that I=E2=80=99m aware = of *AND* it=E2=80=99s an Informational RFC after all it=E2=80=99s *NOT* a s= tandards track RFC.=C2=A0 There ought to be a lower bar for informational v= s standards track and if there isn=E2=80=99t one then that=E2=80=99s really= the IESG=E2=80=99s fault.
  4. The use cases draft helps to frame t= he problem(s) being addressed by the WG proposals and is important for guid= ing future development as well as recording the history of consensus about = the scope of work.
  5. Allows WGs to get cross-area review and IESG= input earlier in the process on the whole WG concept.=C2=A0 That might be = possible with just an IETF LC, but that seems like a bit of a waste of time= and probably wouldn=E2=80=99t be taken seriously by the reviewers without = a =E2=80=9Cthreat=E2=80=9D of publication.
  6. They are usually inf= ormational with no RFC2119 language and should be easier to process.
  7. It is desirable to have a published document that can be found later = to better understand the scope of work produced by a WG or can be used to g= et a newcomer up-to-speed.=C2=A0 While an expired draft can technically be = found, it's existence may not be known by those interested to read the = draft. Dave Crocker's dependency graph off the WG page in the data trac= ker include expires drafts.=C2=A0 Some expired drafts should go away, how w= ould one distinguish in a traceable and helpful way?=C2=A0 You can't re= ly on wiki's to be maintained after WGs disappear.
  8. A wiki t= o maintain this type of data is too dynamic and can't be trusted.=C2=A0= How do you distinguish versions and changes over time even if it isn't= published as an RFC until the solutions are closer to final?
  9. I= n most scientific publications, referencing a weblink (like e.g. a wiki) is= strongly discouraged due to their ephemeral nature. Having an RFC number i= s not only nice to have, it is quite essential if one is to refer to this d= ocument in any serious article.
  10. The process of getting it publi= shed usually supplies a final jolt of energy that can make the document eve= n better (and increase the focus of the WG in the process).=C2=A0 It is har= d to overestimate this effect.
  11. From the ACE WG: One obvious rea= son for having this as a WG draft (published or not) is that some felt thei= r input wasn't considered when it was an individual draft.
  12. = People might be more motivated to contribute to a WG draft than to an indiv= idual draft.=C2=A0 People will also be more motivated to contribute if the = final result is a published document that they can point to when someone (e= mployer, sponsor) asks them what the result of their work was.
  13. = Publishing the draft as (informational) RFC also helps to valorize the work= that the authors put into this document.=C2=A0 If the draft is just publis= hed as a wiki, this sends the message to many readers that IETF didn't = consider this a worthy enough contribution for a real publication. This wou= ld also discourage future contributions to such documents (especially by sc= ientists).
  14. WGs still have the energy*, and want to get this off= the table so they can use it (as intended) as input for the specification-= level discussion of the WG. Note: this may be especially true for newcomers= to the IETF, it will help for them to see a progression of drafts and that= work can move along.
  15. Diversity: If we want to encourage custom= er participation, this is one of the key areas in which they can contribute= and have a positive impact on the work.=C2=A0 This may also help researche= rs who may be involved in use cases or subsequent phases where they raise a= wareness of existing work to solve the problems discussed in the scope of w= ork.

Opposition:

  1. It's time = consuming for the IETF and ideally would have been completed prior to WG fo= rmation.=C2=A0 By the time use cases are complete, folks interested in solu= tions may have walked away already to go do something real, develop code.
  2. This process doesn't keep pace with the open source community an= d should be a pre-cursor to WG formation.=C2=A0 We need to figure out how t= o speed up.
  3. Use cases may be a moving target and may evolve over th= e course of the WG life.

----

Best regards,
Kat= hleen
--001a11c2906ce71a98050e5fa2db-- From nobody Thu Feb 5 16:11:14 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B1C1A0011; Thu, 5 Feb 2015 16:11:09 -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 y5P5gn6e3KKc; Thu, 5 Feb 2015 16:11:04 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA1081A0029; Thu, 5 Feb 2015 16:10:50 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id w7so13184656lbi.1; Thu, 05 Feb 2015 16:10:49 -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=XMb3q3ErYIsAVOW9W7kJk1N2W3d3LJwp6s9duEBaEU4=; b=Ku7ASdDvy73q2l1i0BZ4pFtwJ66WtyL4+RkRA07ctFeGgnZvg7HPOFd7K1EA2zWK95 JHm2jcRK1g1krUlsKSIec7yXI0m3LHiDQ4W7+CY5U0Fdiwmeg+2yHly1sZcQTOBe1U4b 6J0lv6Giqs0pcdBC64n1tW+eJbr/GrNEplsfYpsxtHeiiYPbwP8ovUCPm0v17kiXYXeY rFPcaJex8vnnf1svhsVkzsVdpcHGgUNUMbTON3IvNNHgcadTiYpkQkXewWaj1ozC5iZV ZEAI0JoMINxuaaoTj7OiSSSXiGzmzUSAobQwKMW9zDoTEekgpAKCNErdO5B3pd7PHW+Q JrAQ== MIME-Version: 1.0 X-Received: by 10.112.118.144 with SMTP id km16mr506204lbb.75.1423181449242; Thu, 05 Feb 2015 16:10:49 -0800 (PST) Received: by 10.112.167.134 with HTTP; Thu, 5 Feb 2015 16:10:49 -0800 (PST) In-Reply-To: References: Date: Thu, 5 Feb 2015 19:10:49 -0500 Message-ID: From: Kathleen Moriarty To: "ace@ietf.org" , "sacm@ietf.org" Content-Type: multipart/alternative; boundary=047d7bfd07e6bbadce050e604082 Archived-At: Subject: Re: [Ace] Use Case drafts - should they be published summary X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 00:11:09 -0000 --047d7bfd07e6bbadce050e604082 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I;m just going to amend #2 so it's not misunderstood, this is specific to use case drafts. If a draft is harmful to the Internet and it gets to the IESG, it probably won't get published even if there is consensus. On Thu, Feb 5, 2015 at 6:26 PM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Hello, > > Sorry for the cross post, both WGs helped develop a list of arguments on > why their use case draft should be published. I didn't get many messages > (and the chairs didn't either in private), so it seems most are in favor = of > publishing use cases drafts. > > I'll plan to chat about this with the IESG next week and wanted to share > my summary of reasons. I ordered them, but didn't spend too much time > editing, as this won't be a living document (at least in this state). > > Thanks again for your assistance! > > ---- > > *Use Case Drafts: Should they be published?* > > *Reasons in favor:* > > > 1. If this is part of the WGs charter and a milestone, the work has > already been agreed to be done and there is an expectation from those > working on it that it will be published. The WG has probably already > sucked up this time if it's on the charter. It would be unfair to pul= l it > now. > 2. The IESG is here to serve the IETF. If there is consensus to > publish a use case draft, it should go forward. Cross area review may= help > identify early problems with the work or things that could be harmful = to > the Internet. > 3. If the WG wants it published, it ought to be darn well be > published. There=E2=80=99s no prohibition against uc/req drafts that I= =E2=80=99m aware of > *AND* it=E2=80=99s an Informational RFC after all it=E2=80=99s *NOT* a= standards track > RFC. There ought to be a lower bar for informational vs standards tra= ck > and if there isn=E2=80=99t one then that=E2=80=99s really the IESG=E2= =80=99s fault. > 4. The use cases draft helps to frame the problem(s) being addressed > by the WG proposals and is important for guiding future development as= well > as recording the history of consensus about the scope of work. > 5. Allows WGs to get cross-area review and IESG input earlier in the > process on the whole WG concept. That might be possible with just an = IETF > LC, but that seems like a bit of a waste of time and probably wouldn= =E2=80=99t be > taken seriously by the reviewers without a =E2=80=9Cthreat=E2=80=9D of= publication. > 6. They are usually informational with no RFC2119 language and should > be easier to process. > 7. It is desirable to have a published document that can be found > later to better understand the scope of work produced by a WG or can b= e > used to get a newcomer up-to-speed. While an expired draft can techni= cally > be found, it's existence may not be known by those interested to read = the > draft. Dave Crocker's dependency graph off the WG page in the data tra= cker > include expires drafts. Some expired drafts should go away, how would= one > distinguish in a traceable and helpful way? You can't rely on wiki's = to be > maintained after WGs disappear. > 8. A wiki to maintain this type of data is too dynamic and can't be > trusted. How do you distinguish versions and changes over time even i= f it > isn't published as an RFC until the solutions are closer to final? > 9. In most scientific publications, referencing a weblink (like e.g. a > wiki) is strongly discouraged due to their ephemeral nature. Having an= RFC > number is not only nice to have, it is quite essential if one is to re= fer > to this document in any serious article. > 10. The process of getting it published usually supplies a final jolt > of energy that can make the document even better (and increase the foc= us of > the WG in the process). It is hard to overestimate this effect. > 11. From the ACE WG: One obvious reason for having this as a WG draft > (published or not) is that some felt their input wasn't considered whe= n it > was an individual draft. > 12. People might be more motivated to contribute to a WG draft than to > an individual draft. People will also be more motivated to contribute= if > the final result is a published document that they can point to when > someone (employer, sponsor) asks them what the result of their work wa= s. > 13. Publishing the draft as (informational) RFC also helps to valorize > the work that the authors put into this document. If the draft is jus= t > published as a wiki, this sends the message to many readers that IETF > didn't consider this a worthy enough contribution for a real publicati= on. > This would also discourage future contributions to such documents > (especially by scientists). > 14. WGs still have the energy*, and want to get this off the table so > they can use it (as intended) as input for the specification-level > discussion of the WG. Note: this may be especially true for newcomers = to > the IETF, it will help for them to see a progression of drafts and tha= t > work can move along. > 15. Diversity: If we want to encourage customer participation, this is > one of the key areas in which they can contribute and have a positive > impact on the work. This may also help researchers who may be involve= d in > use cases or subsequent phases where they raise awareness of existing = work > to solve the problems discussed in the scope of work. > > > *Opposition:* > > > 1. It's time consuming for the IETF and ideally would have been > completed prior to WG formation. By the time use cases are complete, = folks > interested in solutions may have walked away already to go do somethin= g > real, develop code. > 2. This process doesn't keep pace with the open source community and > should be a pre-cursor to WG formation. We need to figure out how to = speed > up. > 3. Use cases may be a moving target and may evolve over the course of > the WG life. > > > ---- > > Best regards, > Kathleen > --=20 Best regards, Kathleen --047d7bfd07e6bbadce050e604082 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I;m just going to amend #2 so it's not misunderstood, = this is specific to use case drafts.=C2=A0 If a draft is harmful to the Int= ernet and it gets to the IESG, it probably won't get published even if = there is consensus.

On Thu, Feb 5, 2015 at 6:26 PM, Kathleen Moriarty <<= a href=3D"mailto:kathleen.moriarty.ietf@gmail.com" target=3D"_blank">kathle= en.moriarty.ietf@gmail.com> wrote:
Hello,

Sorry for the cross post, both WGs h= elped develop a list of arguments on why their use case draft should be pub= lished.=C2=A0 I didn't get many messages (and the chairs didn't eit= her in private), so it seems most are in favor of publishing use cases draf= ts.

I'll plan to chat about this with the IESG next week and wan= ted to share my summary of reasons.=C2=A0 I ordered them, but didn't sp= end too much time editing, as this won't be a living document (at least= in this state).

Thanks again for your assistance!

----
Use Case Drafts: Should they be published?

Reasons in fa= vor:

  1. If this is part of the WGs charter and a milestone,= the work has already been agreed to be done and there is an expectation fr= om those working on it that it will be published.=C2=A0 The WG has probably= already sucked up this time if it's on the charter.=C2=A0 It would be = unfair to pull it now.
  2. The IESG is here to serve the IETF.=C2= =A0 If there is consensus to publish a use case draft, it should go forward= .=C2=A0 Cross area review may help identify early problems with the work or= things that could be harmful to the Internet.
  3. If the WG wants = it published, it ought to be darn well be published. There=E2=80=99s no pro= hibition against uc/req drafts that I=E2=80=99m aware of *AND* it=E2=80=99s= an Informational RFC after all it=E2=80=99s *NOT* a standards track RFC.= =C2=A0 There ought to be a lower bar for informational vs standards track a= nd if there isn=E2=80=99t one then that=E2=80=99s really the IESG=E2=80=99s= fault.
  4. The use cases draft helps to frame the problem(s) being= addressed by the WG proposals and is important for guiding future developm= ent as well as recording the history of consensus about the scope of work.<= br>
  5. Allows WGs to get cross-area review and IESG input earlier in t= he process on the whole WG concept.=C2=A0 That might be possible with just = an IETF LC, but that seems like a bit of a waste of time and probably would= n=E2=80=99t be taken seriously by the reviewers without a =E2=80=9Cthreat= =E2=80=9D of publication.
  6. They are usually informational with n= o RFC2119 language and should be easier to process.
  7. It is desir= able to have a published document that can be found later to better underst= and the scope of work produced by a WG or can be used to get a newcomer up-= to-speed.=C2=A0 While an expired draft can technically be found, it's e= xistence may not be known by those interested to read the draft. Dave Crock= er's dependency graph off the WG page in the data tracker include expir= es drafts.=C2=A0 Some expired drafts should go away, how would one distingu= ish in a traceable and helpful way?=C2=A0 You can't rely on wiki's = to be maintained after WGs disappear.
  8. A wiki to maintain this t= ype of data is too dynamic and can't be trusted.=C2=A0 How do you disti= nguish versions and changes over time even if it isn't published as an = RFC until the solutions are closer to final?
  9. In most scientific= publications, referencing a weblink (like e.g. a wiki) is strongly discour= aged due to their ephemeral nature. Having an RFC number is not only nice t= o have, it is quite essential if one is to refer to this document in any se= rious article.
  10. The process of getting it published usually supp= lies a final jolt of energy that can make the document even better (and inc= rease the focus of the WG in the process).=C2=A0 It is hard to overestimate= this effect.
  11. From the ACE WG: One obvious reason for having th= is as a WG draft (published or not) is that some felt their input wasn'= t considered when it was an individual draft.
  12. People might be m= ore motivated to contribute to a WG draft than to an individual draft.=C2= =A0 People will also be more motivated to contribute if the final result is= a published document that they can point to when someone (employer, sponso= r) asks them what the result of their work was.
  13. Publishing the = draft as (informational) RFC also helps to valorize the work that the autho= rs put into this document.=C2=A0 If the draft is just published as a wiki, = this sends the message to many readers that IETF didn't consider this a= worthy enough contribution for a real publication. This would also discour= age future contributions to such documents (especially by scientists).
    <= /li>
  14. WGs still have the energy*, and want to get this off the table so t= hey can use it (as intended) as input for the specification-level discussio= n of the WG. Note: this may be especially true for newcomers to the IETF, i= t will help for them to see a progression of drafts and that work can move = along.
  15. Diversity: If we want to encourage customer participatio= n, this is one of the key areas in which they can contribute and have a pos= itive impact on the work.=C2=A0 This may also help researchers who may be i= nvolved in use cases or subsequent phases where they raise awareness of exi= sting work to solve the problems discussed in the scope of work.

    16. Opposition:

    1. It's time consuming for t= he IETF and ideally would have been completed prior to WG formation.=C2=A0 = By the time use cases are complete, folks interested in solutions may have = walked away already to go do something real, develop code.
    2. This pro= cess doesn't keep pace with the open source community and should be a p= re-cursor to WG formation.=C2=A0 We need to figure out how to speed up.
    3. Use cases may be a moving target and may evolve over the course of the= WG life.

    ----

    Best regards,
    Kathleen



--

Best regards,
Kath= leen
--047d7bfd07e6bbadce050e604082-- From nobody Fri Feb 6 02:45: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 583BF1A01EC for ; Fri, 6 Feb 2015 02:45:05 -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 BwH4zffGBIaO for ; Fri, 6 Feb 2015 02:45:02 -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 5E0CE1A014E for ; Fri, 6 Feb 2015 02:45:01 -0800 (PST) X-AuditID: c1b4fb30-f79106d000001184-a7-54d49b2b4532 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id AF.61.04484.B2B94D45; Fri, 6 Feb 2015 11:44:59 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.13]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0210.002; Fri, 6 Feb 2015 11:44:59 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Stefanie Gerdes , "Ace@ietf.org" Thread-Topic: [Ace] Fwd: I-D Action: draft-ietf-ace-usecases-02.txt Thread-Index: AQHQQSw5Sfw0ELIkVUS6mg1j4TnWLZzjcYsA Date: Fri, 6 Feb 2015 10:44:57 +0000 Message-ID: References: <20150205095841.19111.5154.idtracker@ietfa.amsl.com> <54D341F6.9040109@tzi.de> In-Reply-To: <54D341F6.9040109@tzi.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-ID: <44CA2986DB8FAA4598C2F9FA5EA85D35@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGfG3Rld79pUQg3OL1C2+f+thtth48S6j A5PHkiU/mTy2vf3KHMAUxWWTkpqTWZZapG+XwJVxs3sSY8Ent4qXkzewNTB2uHYxcnJICJhI PN79hw3CFpO4cG89kM3FISRwhFHi04/jrBDOIkaJqf0rGEGq2ARcJB40PGICsUUEnCSWbvvL AmILg9ivHrNCxJ0ljn/fzQhhG0ncab7PDmKzCKhI3Dq+D6iXg4NXwEJi7WpLkLCQQIzE9j+/ wMZwCqhJ7JixGGwMI9BB30+tAVvFLCAucevJfCaIQwUkluw5zwxhi0q8fPwPrF5UQE9i5fUm qGeUJNYe3s4CsopZQFNi/S59iDHWErPuLGaDsBUlpnQ/BLuMV0BQ4uTMJywTGMVnIdk2C6F7 FpLuWUi6ZyHpXsDIuopRtDi1OCk33chIL7UoM7m4OD9PLy+1ZBMjMNYObvltsIPx5XPHQ4wC HIxKPLwGeldChFgTy4orcw8xSnOwKInz2hkfChESSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXA WHhglnzhtNrrs3yd530uPrtoWtl/hQr3tqi1Af5yJhMWfuO5LlK596DiBr9v8zYcyVP/K5iz Wq/mcHp9VYbz+qazaeXWzdufpDYK1W2QnHDtdonXyVNs+R8TpQPsYmIDDho438vVVd0uuyP/ 4G7eg8opSV9O+ItOLim8pMuasf2F6r7e08/PKLEUZyQaajEXFScCAP8Se8eWAgAA Archived-At: Subject: Re: [Ace] Fwd: I-D Action: draft-ietf-ace-usecases-02.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 10:45:05 -0000 SGkgU3RlZmZpLA0KDQpTb21lIGNvbW1lbnRzIG9uIHRoZSBuZXcgcHJvcG9zZWQgdGVybWlub2xv Z3kuIEZpcnN0IG9mIGFsbCwgcmVtb3ZpbmcNCm93bmVyc2hpcCBmcm9tIHRoZSBkZXNjcmlwdGlv biBvZiB0aGUgdGVybWlub2xvZ3kgaXMgYSBkZWZpbml0ZQ0KaW1wcm92ZW1lbnQhIEJ1dCBJIHN0 aWxsIGhhdmUgYSBwcm9ibGVtIHdpdGggdGhpcyB2ZXJzaW9uLCBsZXQgbWUgaW5jbHVkZQ0KeW91 ciB0ZXJtaW5vbG9neSAoU2VjdGlvbiAxLjEuKSBmb3IgdGhlIGNvbnZlbmllbmNlIG9mIHRoZSBy ZWFkZXJzOg0KDQoiUmVzb3VyY2U6ICBBbiBpdGVtIG9mIGludGVyZXN0Lg0KDQpSZXNvdXJjZSBT ZXJ2ZXI6ICBUaGUgZW5kcG9pbnQgd2hpY2ggaG9zdHMgcmVzb3VyY2VzIHRoZSBDbGllbnQgd2Fu dHMgdG8NCmFjY2Vzcy4gIFJlc291cmNlIFNlcnZlcnMgbWlnaHQgYmUgbG9jYXRlZCBvbiBjb25z dHJhaW5lZCBkZXZpY2VzLg0KDQpDbGllbnQ6ICBBbiBlbmRwb2ludCB3aGljaCB3YW50cyB0byBh Y2Nlc3MgYSByZXNvdXJjZSBvbiB0aGUgUmVzb3VyY2UNClNlcnZlci4gIFRoaXMgY291bGQgYWxz byBiZSBsb2NhdGVkIG9uIGEgY29uc3RyYWluZWQgZGV2aWNlLg0KDQpSZXNvdXJjZSBPd25lcjog IFRoZSBzdWJqZWN0IHdobyBjb250cm9scyB0aGUgYWNjZXNzIHBlcm1pc3Npb25zIG9mIGENCnJl c291cmNlLg0KDQpDbGllbnQgT3duZXI6ICAgVGhlIHN1YmplY3Qgd2hvIGNvbnRyb2xzIHRoZSBh Y2Nlc3MgcGVybWlzc2lvbnMgb2YgYQ0KY2xpZW50Lg0KDQpQcmluY2lwYWw6ICBBIHN1YmplY3Qg d2hvIGlzIGVpdGhlciBhIHJlc291cmNlIG93bmVyIG9yIGEgY2xpZW50IG93bmVyIG9yDQpib3Ro LiINCg0KDQpPbiB0aGUgUmVzb3VyY2UgT3duZXIgc2lkZSBpdCBpcyB2ZXJ5IGNsZWFyIHdoYXQg aXMgdGhlIGl0ZW0gb2YgaW50ZXJlc3QsDQp3aGVyZSBpdCBpcyBob3N0ZWQsIHdobyB3YW50cyB0 byBhY2Nlc3MgaXQgYW5kIHdobyBkZWNpZGVzIGFib3V0IHRoZQ0KcGVybWlzc2lvbnMgdG8gYWNj ZXNzIGl0Og0KDQotIFdoYXQ6IFRoZSBSZXNvdXJjZQ0KLSBXaGVyZTogQXQgdGhlIFJlc291cmNl IFNlcnZlcg0KLSBXaG8gd2FudHMgdG8gYWNjZXNzOiBUaGUgQ2xpZW50DQotIFdobyBkZWNpZGVz IGFib3V0IHdobyBoYXMgdGhlIHJpZ2h0IHRvIGFjY2VzczogVGhlIFJlc291cmNlIE93bmVyDQoN CldpdGggcmVnYXJkcyB0byB0aGUgQ2xpZW50IE93bmVyIGNvbnRyb2xsaW5nIHRoZSDigJxhY2Nl c3MgcGVybWlzc2lvbnMgb2YgYQ0KY2xpZW50IiwgdGhhdCBpcyBub3QgYXQgYWxsIGNsZWFyIHRv IG1lLiBXaGF0IGlzIGJlaW5nIGFjY2Vzc2VkIGF0IHRoZQ0KY2xpZW50PyBXaG8gd2FudHMgdG8g YWNjZXNzPw0KDQoNClJlZ2FyZGluZyBTZWN0aW9uIDIuMToNCg0KIlRoZXJlIGFyZSB2YXJpb3Vz IHJlYXNvbnMgZm9yIGFzc2lnbmluZyBhIGZ1bmN0aW9uIChjbGllbnQgb3Igc2VydmVyKSB0bw0K YSBkZXZpY2UsIGUuZy4gd2hpY2ggZGV2aWNlIGluaXRpYXRlcyB0aGUgY29udmVyc2F0aW9uLCBo b3cgZG8gZGV2aWNlcw0KZmluZCBlYWNoIG90aGVyLCBldGMuICBUaGUgZGVmaW5pdGlvbiBvZiB0 aGUgZnVuY3Rpb24gb2YgYSBkZXZpY2UgaW4gYQ0KY2VydGFpbiB1c2UgY2FzZSBpcyBub3QgaW4g c2NvcGUgb2YgdGhpcyBkb2N1bWVudC4gUmVhZGVycyBzaG91bGQgYmUgYXdhcmUNCnRoYXQgdGhl cmUgbWlnaHQgYmUgcmVhc29ucyBmb3IgZWFjaCBzZXR0aW5nIGFuZCB0aGF0IGVuZHBvaW50cyBt aWdodCBldmVuDQpoYXZlIGRpZmZlcmVudCBmdW5jdGlvbnMgYXQgZGlmZmVyZW50IHRpbWVzLiIN Cg0KSSByZW1lbWJlciB5b3UgaGF2ZSB1c2VkIHRoaXMgcmVhc29uaW5nIHRvIGFyZ3VlIHRoYXQg aXQgaXMgbm90IHBvc3NpYmxlDQp0byBleHByZXNzIHdoYXQgaXMgdGhlIFJlc291cmNlIGluIGEg Z2l2ZW4gdXNlIGNhc2UuIElmIHRoaXMgaXMgdGhlIGNhc2UsDQp0aGF0IHdpdGggdGhpcyB0ZXJt aW5vbG9neSBpdCBpcyBub3QgcG9zc2libGUgdG8gc3BlY2lmeSB3aGF0IGFyZSB0aGUNCiJpdGVt cyBvZiBpbnRlcmVzdCIgaW4gYSBnaXZlbiB1c2UgY2FzZSwgdGhlbiBJIHRoaW5rIHRoZSB0ZXJt aW5vbG9neSBpcw0Kbm90IHNhdGlzZmFjdG9yeS4gVGhlIHB1cnBvc2Ugb2YgdGhlIHVzZSBjYXNl IGRvY3VtZW50IGlzIHRvIGhpZ2hsaWdodA0Kd2hhdCBpcyB0aGUgcHJvYmxlbSB3ZSBzaG91bGQg c29sdmUuIElmIHdlIGNhbuKAmXQgdXNlIHRoZSB0ZXJtIOKAnFJlc291cmNl4oCdLA0KdGhlbiB3 aGF0IG5lZWQgZG8gd2UgaGF2ZSBmb3Ig4oCcUmVzb3VyY2UgU2VydmVy4oCdIGFuZCDigJxSZXNv dXJjZSBPd25lcuKAnT8NCkZ1cnRoZXJtb3JlIOKAnENsaWVudOKAnSBpcyBkZWZpbmVkIGFzIHRo ZSBSZXNvdXJjZSBhY2Nlc3NpbmcgZW5kcG9pbnQsIHNvDQp0aGVuIG5laXRoZXIgdGhhdCBub3Ig IkNsaWVudCBPd25lcuKAnSBpcyB3ZWxsIGRlZmluZWQuDQoNClRoZSBvbmx5IHJlbWFpbmluZyB0 ZXJtIGlzIOKAnFByaW5jaXBhbOKAnSwgd2hpY2ggdGhlbiBiZWNvbWVzIGEgc3lub255bSB0bw0K 4oCcc29tZW9uZSBzZXR0aW5nIGFjY2VzcyBjb250cm9sIHBvbGljaWVz4oCdLiBJZiB0aGlzIGlz IHRoZSBvbmx5IHRoaW5nIHlvdQ0Kd2FudCB0byBleHByZXNzLCB0aGVuIEkgdGhpbmsgeW91IHNo b3VsZCByZW1vdmUgdGhlIHJlc3Qgb2YgdGhlIHRlcm1zLCBhcw0KdGhleSBhcmUgbm90IHVzZWQu IChSZXNvdXJjZSBTZXJ2ZXIgb3IgQ2xpZW50IGNhbiBiZSByZXBsYWNlZCBieSDigJxzb21lDQpw b3RlbnRpYWxseSBjb25zdHJhaW5lZCBkZXZpY2XigJ0gZXRjLikgQnV0IEkgdGhpbmsgdGhpcyBp cyBub3QgYXQgYWxsDQpjbGFyaWZ5aW5nIHdoYXQgYXJlIHRoZSBhdXRob3JpemF0aW9uIHByb2Js ZW1zLiBJbiBwYXJ0aWN1bGFyIHNpbmNlIEkgaGF2ZQ0KaGFyZCB0aW1lIHVuZGVyc3RhbmRpbmcg d2hhdCBleGFjdGx5IGFyZSB0aGUgYWNjZXNzIGNvbnRyb2wgcHJvYmxlbXMgb24NCnRoZSBjbGll bnQgc2lkZSwgSSB0aGluayBpdCB3b3VsZCBiZSBtb3JlIGhlbHBmdWwgdG8gZXhwbGFpbiB0aGF0 IGluIGENCmdpdmVuIHVzZSBjYXNlLiBXaGF0IGFyZSB0aGUgYWNjZXNzIGNvbnRyb2wgcG9saWN5 IGNvbnNpZGVyYXRpb25zIG9mIHRoZQ0KZnJ1aXQgdmVuZG9yLCB0aGUgdHJhbnNsb2FkaW5nIHBl cnNvbm5lbCBhbmQgdGhlIGNvbnRhaW5lciBvd25lcnM/DQoNCkFuZCB0aGVuIG1heWJlIHdlIGNh biBhdm9pZCB0aGUgZXhlcmNpc2Ugb2YgZmlyc3QgZGVmaW5pbmcgdGVybXMgaW4NCnNlY3Rpb24g MS4xIGFuZCB0aGVuIGRpc3F1YWxpZnlpbmcgdGhlIHVzZSBvZiBhbGwgdGVybXMgZXhjZXB0IG9u ZSBpbg0Kc2VjdGlvbiAyLjE/DQoNCkJlc3QgUmVnYXJkcw0KR8O2cmFuDQoNCg0KDQpPbiAyMDE1 LTAyLTA1IDExOjEyLCAiU3RlZmFuaWUgR2VyZGVzIiA8Z2VyZGVzQHR6aS5kZT4gd3JvdGU6DQoN Cj5IaSBhbGwsDQo+DQo+V2Ugc3VibWl0dGVkIGEgbmV3IHZlcnNpb24gb2YgdGhlIHVzZSBjYXNl cyBkcmFmdC4gTW9zdCBjaGFuZ2VzIGFyZQ0KPnRlcm1pbm9sb2d5IGNoYW5nZXM6IEluc3RlYWQg b2YgIkRldmljZSBPd25lciIsIHRoZSBkb2N1bWVudCBub3cgdXNlcw0KPiJDbGllbnQgT3duZXIi IG9yICJQcmluY2lwYWwiLiBXaGVyZSBhcHBsaWNhYmxlLCAiZGV2aWNlIiB3YXMgcmVwbGFjZWQN Cj5ieSAiZW5kcG9pbnQiIGFjY29yZGluZ2x5LiBJbiAzLjIgdGhlIHBocmFzaW5nIG9mIGZpcnN0 IGl0ZW0gd2FzIGNoYW5nZWQNCj5hY2NvcmRpbmcgdG8gdGhlIGRpc2N1c3Npb24gb24gdGhlIGxp c3QuDQo+DQo+QmVzdCByZWdhcmRzLA0KPlN0ZWZmaQ0KPg0KPg0KPi0tLS0tLS0tIEZvcndhcmRl ZCBNZXNzYWdlIC0tLS0tLS0tDQo+U3ViamVjdDogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1hY2Ut dXNlY2FzZXMtMDIudHh0DQo+RGF0ZTogVGh1LCAwNSBGZWIgMjAxNSAwMTo1ODo0MSAtMDgwMA0K PkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KPlJlcGx5LVRvOiBpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmcNCj5UbzogaS1kLWFubm91bmNlQGlldGYub3JnDQo+Q0M6IGFjZUBpZXRmLm9y Zw0KPg0KPg0KPkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1s aW5lIEludGVybmV0LURyYWZ0cw0KPmRpcmVjdG9yaWVzLg0KPiAgVGhpcyBkcmFmdCBpcyBhIHdv cmsgaXRlbSBvZiB0aGUgQXV0aGVudGljYXRpb24gYW5kIEF1dGhvcml6YXRpb24gZm9yDQo+Q29u c3RyYWluZWQgRW52aXJvbm1lbnRzIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQo+DQo+ICAg ICAgICAgVGl0bGUgICAgICAgICAgIDogQUNFIHVzZSBjYXNlcw0KPiAgICAgICAgIEF1dGhvcnMg ICAgICAgICA6IEx1ZHdpZyBTZWl0eg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIFN0ZWZh bmllIEdlcmRlcw0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIEdvZXJhbiBTZWxhbmRlcg0K PiAgICAgICAgICAgICAgICAgICAgICAgICAgIE1laGRpIE1hbmkNCj4gICAgICAgICAgICAgICAg ICAgICAgICAgICBTYW5kZWVwIFMuIEt1bWFyDQo+CUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWll dGYtYWNlLXVzZWNhc2VzLTAyLnR4dA0KPglQYWdlcyAgICAgICAgICAgOiAyNA0KPglEYXRlICAg ICAgICAgICAgOiAyMDE1LTAyLTA1DQo+DQo+QWJzdHJhY3Q6DQo+ICAgIENvbnN0cmFpbmVkIGRl dmljZXMgYXJlIG5vZGVzIHdpdGggbGltaXRlZCBwcm9jZXNzaW5nIHBvd2VyLCBzdG9yYWdlDQo+ ICAgIHNwYWNlIGFuZCB0cmFuc21pc3Npb24gY2FwYWNpdGllcy4gIFRoZXNlIGRldmljZXMgaW4g bWFueSBjYXNlcyBkbw0KPiAgICBub3QgcHJvdmlkZSB1c2VyIGludGVyZmFjZXMgYW5kIGFyZSBv ZnRlbiBpbnRlbmRlZCB0byBpbnRlcmFjdA0KPiAgICB3aXRob3V0IGh1bWFuIGludGVydmVudGlv bi4NCj4NCj4gICAgVGhpcyBkb2N1bWVudCBjb21wcmlzZXMgYSBjb2xsZWN0aW9uIG9mIHJlcHJl c2VudGF0aXZlIHVzZSBjYXNlcyBmb3INCj4gICAgdGhlIGFwcGxpY2F0aW9uIG9mIGF1dGhlbnRp Y2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIGluIGNvbnN0cmFpbmVkDQo+ICAgIGVudmlyb25tZW50 cy4gIFRoZXNlIHVzZSBjYXNlcyBhaW0gYXQgaWRlbnRpZnlpbmcgYXV0aG9yaXphdGlvbg0KPiAg ICBwcm9ibGVtcyB0aGF0IGFyaXNlIGR1cmluZyB0aGUgbGlmZWN5bGNlIG9mIGEgY29uc3RyYWlu ZWQgZGV2aWNlIGFuZA0KPiAgICBhcmUgaW50ZW5kZWQgdG8gcHJvdmlkZSBhIGd1aWRlbGluZSBm b3IgZGV2ZWxvcGluZyBhIGNvbXByZWhlbnNpdmUNCj4gICAgYXV0aGVudGljYXRpb24gYW5kIGFj Y2VzcyBjb250cm9sIHNvbHV0aW9uIGZvciB0aGlzIGNsYXNzIG9mDQo+ICAgIHNjZW5hcmlvcy4N Cj4NCj4gICAgV2hlcmUgc3BlY2lmaWMgZGV0YWlscyBhcmUgcmVsZXZhbnQsIGl0IGlzIGFzc3Vt ZWQgdGhhdCB0aGUgZGV2aWNlcw0KPiAgICB1c2UgdGhlIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9u IFByb3RvY29sIChDb0FQKSBhcyBjb21tdW5pY2F0aW9uDQo+ICAgIHByb3RvY29sLCBob3dldmVy IG1vc3QgY29uY2x1c2lvbnMgYXBwbHkgZ2VuZXJhbGx5Lg0KPg0KPg0KPlRoZSBJRVRGIGRhdGF0 cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtYWNlLXVzZWNhc2VzLw0KPg0KPlRoZXJlJ3MgYWxz byBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPmh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtYWNlLXVzZWNhc2VzLTAyDQo+DQo+QSBkaWZmIGZyb20gdGhlIHBy ZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LWlldGYtYWNlLXVzZWNhc2VzLTAyDQo+DQo+DQo+UGxlYXNlIG5vdGUg dGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj5z dWJtaXNzaW9uDQo+dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4NCj5JbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZh aWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy8NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPkktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCj5JLUQtQW5ub3VuY2VAaWV0Zi5vcmcN Cj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZQ0KPklu dGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1s DQo+b3IgZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQNCj4NCj4NCj4N Cj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPkFjZSBt YWlsaW5nIGxpc3QNCj5BY2VAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2FjZQ0KDQo= From nobody Mon Feb 9 05:19:43 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 066F01A0398 for ; Mon, 9 Feb 2015 05:15:27 -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 FlH1JX8gL8mu for ; Mon, 9 Feb 2015 05:15:24 -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 53BAE1A0318 for ; Mon, 9 Feb 2015 05:15:24 -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 t19DFKSO010667 for ; Mon, 9 Feb 2015 14:15:20 +0100 (CET) Received: from [192.168.1.109] (p57A63A20.dip0.t-ipconnect.de [87.166.58.32]) (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 3kgnlr63gxz2PZf for ; Mon, 9 Feb 2015 14:15:20 +0100 (CET) Message-ID: <54D8B2E8.9060100@tzi.de> Date: Mon, 09 Feb 2015 14:15:20 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Ace@ietf.org" References: <20150209130025.4048.40749.idtracker@ietfa.amsl.com> In-Reply-To: <20150209130025.4048.40749.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150209130025.4048.40749.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Ace] Fwd: I-D Action: draft-gerdes-ace-dcaf-authorize-01.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 13:15:27 -0000 Hi all, We submitted a new version of the DCAF draft. The main changes are the following: * Adopt the terminology of the actors draft [1]. * Specify details for authorization on the client's side. Comments are very welcome. Best regards, Steffi [1] http://tools.ietf.org/pdf/draft-gerdes-ace-actors.pdf -------- Forwarded Message -------- Subject: I-D Action: draft-gerdes-ace-dcaf-authorize-01.txt Date: Mon, 09 Feb 2015 05:00:25 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Delegated CoAP Authentication and Authorization Framework (DCAF) Authors : Stefanie Gerdes Olaf Bergmann Carsten Bormann Filename : draft-gerdes-ace-dcaf-authorize-01.txt Pages : 42 Date : 2015-02-09 Abstract: This specification defines a protocol for delegating client authentication and authorization in a constrained environment for establishing a Datagram Transport Layer Security (DTLS) channel between resource-constrained nodes. The protocol relies on DTLS to transfer authorization information and shared secrets for symmetric cryptography between entities in a constrained network. A resource- constrained node can use this protocol to delegate authentication of communication peers and management of authorization information to a trusted host with less severe limitations regarding processing power and memory. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-gerdes-ace-dcaf-authorize/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-gerdes-ace-dcaf-authorize-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-gerdes-ace-dcaf-authorize-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Feb 9 15:36: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 06EF61A1AB2 for ; Mon, 9 Feb 2015 07:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.45 X-Spam-Level: * X-Spam-Status: No, score=1.45 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yw8polp4KrWJ for ; Mon, 9 Feb 2015 07:25:23 -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 584791A1B07 for ; Mon, 9 Feb 2015 07:22: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 [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t19FMj8h007568; Mon, 9 Feb 2015 16:22:45 +0100 (CET) Received: from [192.168.1.109] (p57A63A20.dip0.t-ipconnect.de [87.166.58.32]) (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 3kgrZs2Pg2z2Pyh; Mon, 9 Feb 2015 16:22:45 +0100 (CET) Message-ID: <54D8D0C5.6030101@tzi.de> Date: Mon, 09 Feb 2015 16:22:45 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= , "Ace@ietf.org" References: <20150205095841.19111.5154.idtracker@ietfa.amsl.com> <54D341F6.9040109@tzi.de> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] Fwd: I-D Action: draft-ietf-ace-usecases-02.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 15:25:25 -0000 Hi Göran, On 02/06/2015 11:44 AM, Göran Selander wrote: > Hi Steffi, > > Some comments on the new proposed terminology. First of all, removing > ownership from the description of the terminology is a definite > improvement! But I still have a problem with this version, let me include > your terminology (Section 1.1.) for the convenience of the readers: > > "Resource: An item of interest. > > Resource Server: The endpoint which hosts resources the Client wants to > access. Resource Servers might be located on constrained devices. > > Client: An endpoint which wants to access a resource on the Resource > Server. This could also be located on a constrained device. > > Resource Owner: The subject who controls the access permissions of a > resource. > > Client Owner: The subject who controls the access permissions of a > client. > > Principal: A subject who is either a resource owner or a client owner or > both." > > > On the Resource Owner side it is very clear what is the item of interest, > where it is hosted, who wants to access it and who decides about the > permissions to access it: > > - What: The Resource > - Where: At the Resource Server > - Who wants to access: The Client > - Who decides about who has the right to access: The Resource Owner > > With regards to the Client Owner controlling the “access permissions of a > client", that is not at all clear to me. What is being accessed at the > client? Who wants to access? In the scenario we are analysing, there is the client on one end of the conversation and the Resource Server on the other side. The client may have a different owner that the Resource Server. On the Resource Server side, Resource Owners may want to control which data is entering and leaving their resources. On the client side, Client Owners may want to control which data is entering and leaving their endpoints. To put it another way: The Client Owner may want to make sure that only authorized endpoints can send data to the client and that the client sends data only to authorized resource servers. Just as on the Resource Server side, the Resource Owner may want to make sure that only authorized endpoints can send data to the Resource Server and the Resource Server sends data only to authorized clients. We could change the definition of Client Owner from "The subject who controls the access permissions of a client." to "The subject who defines authorization policies for a client". Does that solve your problem? > > > Regarding Section 2.1: > > "There are various reasons for assigning a function (client or server) to > a device, e.g. which device initiates the conversation, how do devices > find each other, etc. The definition of the function of a device in a > certain use case is not in scope of this document. Readers should be aware > that there might be reasons for each setting and that endpoints might even > have different functions at different times." > > I remember you have used this reasoning to argue that it is not possible > to express what is the Resource in a given use case. If this is the case, > that with this terminology it is not possible to specify what are the > "items of interest" in a given use case, then I think the terminology is > not satisfactory. The purpose of the use case document is to highlight > what is the problem we should solve. If we can’t use the term “Resource”, > then what need do we have for “Resource Server” and “Resource Owner”? > Furthermore “Client” is defined as the Resource accessing endpoint, so > then neither that nor "Client Owner” is well defined. I don't think I understand your reasoning. I can't remember saying that we don't know what the resource is in a given use case. The paragraph from section 2.1 just states that it is not clear whether an endpoint in a use case is a CoAP client or a server. I don't think that it is even necessary to be able to assign a function since I didn't see any evidence yet that this would be useful. As I mentioned in my last e-mail to Ludwig, we need the terms "client and server (or resource server) to express the problem that needs to be solved, e.g. U5.7" (cf http://www.ietf.org/mail-archive/web/ace/current/msg00973.html). We can change "Resource Server" to "server" to fit it to the CoAP terminology. If we don't need the terms Client Owner and Resource Owner, we can remove these terms from the terminology section. Is that what you are proposing? > > The only remaining term is “Principal”, which then becomes a synonym to > “someone setting access control policies”. If this is the only thing you > want to express, then I think you should remove the rest of the terms, as > they are not used. (Resource Server or Client can be replaced by “some > potentially constrained device” etc.) But I think this is not at all > clarifying what are the authorization problems. In particular since I have > hard time understanding what exactly are the access control problems on > the client side, I think it would be more helpful to explain that in a > given use case. What are the access control policy considerations of the > fruit vendor, the transloading personnel and the container owners? We can play out Ludwig's proposal and use the names of the specific actors in the problem summary section. Ist that what you are proposing? For the container monitoring use case, the section would look like this: U1.1 Principals such as the fruit vendor, the transloading personnel or the container owners want to define authorizations for their resources and endpoints. U1.2 The fruit vendor requires the integrity of the sensor data that pertains the state of the goods for climate control and to ensure the quality of the monitored recordings. U1.3 The container owner requires the integrity of the sensor data that is used for climate control. U1.4 The fruit vendor requires the confidentiality of the sensor data that pertains the state of the goods. U1.5 The fruit vendor may have several types of data that may be controlled by the same endpoint, e.g., sensor data and the data used for logistics. U1.6 The fruit vendor requires the confidentiality of the data that is used to locate the goods. U1.7 The fruit vendor requires the integrity of the data that is used to locate the goods. U1.8 The transloading personnel requires the integrity of the data that is used to locate the goods. U1.9 The container owner and the fruit vendor may not be present at the time of access and cannot manually intervene in the authorization process. U1.10 The principals want to grant temporary access permissions to a party. U1.11 Messages between client and resource server might need to be forwarded over multiple hops. U1.12 The constrained devices might not always be able to reach the Internet. Best regards, Steffi From nobody Tue Feb 10 00:20:21 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA7B91A000F for ; Tue, 10 Feb 2015 00:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXs5aTyRnO2f for ; Tue, 10 Feb 2015 00:19:56 -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 CE2F21A1A7C for ; Tue, 10 Feb 2015 00:19:45 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-8f-54d9bf1f28ee Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id BE.3C.24955.F1FB9D45; Tue, 10 Feb 2015 09:19:43 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.180]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0210.002; Tue, 10 Feb 2015 09:19:43 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Stefanie Gerdes Thread-Topic: [Ace] Fwd: I-D Action: draft-ietf-ace-usecases-02.txt Thread-Index: AQHQQSw5Sfw0ELIkVUS6mg1j4TnWLZzjcYsAgATz2oCAASzlgA== Date: Tue, 10 Feb 2015 08:19:42 +0000 Message-ID: References: <20150205095841.19111.5154.idtracker@ietfa.amsl.com> <54D341F6.9040109@tzi.de> <54D8D0C5.6030101@tzi.de> In-Reply-To: <54D8D0C5.6030101@tzi.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-ID: <3A8E58B3FD72884880EA5C5423E97703@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM+Jvja78/pshBmvaDSy+f+thtth48S6j A5PHkiU/mTy2vf3KHMAUxWWTkpqTWZZapG+XwJUxfccqtoKGsIpX67YzNzA+Ce5i5OSQEDCR WLzvAjOELSZx4d56NhBbSOAIo8SiJ3FdjFxA9hJGifl3bjGCJNgEXCQeNDxiArFFBJQlfi/+ BGYzCyhK7J51lh3EFhZwklj66jErRI2zxPHvuxkhbCeJN80rwJaxCKhK3Px5EGwZr4CFxKL5 jewQy5YySjS1XAYbxCmgJtHzfyPYIEag676fWgO1TFzi1pP5TBBXC0gs2XMe6gNRiZeP/4HV iwroSay83sQGEVeSWHt4O0sXIwdQr6bE+l36EGOsJdqOP2GBuX9K90N2iHsEJU7OfMIygVFi FpJtsxC6ZyHpnoWkexaS7gWMrKsYRYtTi5Ny042M9VKLMpOLi/Pz9PJSSzYxAqPw4JbfqjsY L79xPMQowMGoxMNrUHIzRIg1say4MvcQozQHi5I4r53xoRAhgfTEktTs1NSC1KL4otKc1OJD jEwcnFINjC2FB5ZXNZxUFQrtTPCce+xmcMDq5LXafKGSed98fLaWPW3QPuhY2pm9KmTR7uMf GLaLuDT+Df4rufz78YW9V9N2OCrapFt/qMx4viL+vI9y6eSnYQLcm1X/LbJ5XrvFbpue8LYD yjplDZuvhOz3vN9R+vTLu+aFv05y2pjck92wsLbc6tAWBiWW4oxEQy3mouJEAG40fb6jAgAA Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Fwd: I-D Action: draft-ietf-ace-usecases-02.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 08:20:12 -0000 DQpIaSBTdGVmZmksDQoNClRoYW5rcyBmb3IgeW91ciBjb25zdHJ1Y3RpdmUgYW5zd2VyLiBBIGNv bmNyZXRlIHJlcXVlc3QgYmVsb3cuDQoNCk9uIDIwMTUtMDItMDkgMTY6MjIsICJTdGVmYW5pZSBH ZXJkZXMiIDxnZXJkZXNAdHppLmRlPiB3cm90ZToNCg0KPkhpIEfDtnJhbiwNCj4NCj5PbiAwMi8w Ni8yMDE1IDExOjQ0IEFNLCBHw7ZyYW4gU2VsYW5kZXIgd3JvdGU6DQo+PiBIaSBTdGVmZmksDQo+ Pg0KPj4gU29tZSBjb21tZW50cyBvbiB0aGUgbmV3IHByb3Bvc2VkIHRlcm1pbm9sb2d5LiBGaXJz dCBvZiBhbGwsIHJlbW92aW5nDQo+PiBvd25lcnNoaXAgZnJvbSB0aGUgZGVzY3JpcHRpb24gb2Yg dGhlIHRlcm1pbm9sb2d5IGlzIGEgZGVmaW5pdGUNCj4+IGltcHJvdmVtZW50ISBCdXQgSSBzdGls bCBoYXZlIGEgcHJvYmxlbSB3aXRoIHRoaXMgdmVyc2lvbiwgbGV0IG1lDQo+PmluY2x1ZGUNCj4+ IHlvdXIgdGVybWlub2xvZ3kgKFNlY3Rpb24gMS4xLikgZm9yIHRoZSBjb252ZW5pZW5jZSBvZiB0 aGUgcmVhZGVyczoNCj4+DQo+PiAiUmVzb3VyY2U6ICBBbiBpdGVtIG9mIGludGVyZXN0Lg0KPj4N Cj4+IFJlc291cmNlIFNlcnZlcjogIFRoZSBlbmRwb2ludCB3aGljaCBob3N0cyByZXNvdXJjZXMg dGhlIENsaWVudCB3YW50cyB0bw0KPj4gYWNjZXNzLiAgUmVzb3VyY2UgU2VydmVycyBtaWdodCBi ZSBsb2NhdGVkIG9uIGNvbnN0cmFpbmVkIGRldmljZXMuDQo+Pg0KPj4gQ2xpZW50OiAgQW4gZW5k cG9pbnQgd2hpY2ggd2FudHMgdG8gYWNjZXNzIGEgcmVzb3VyY2Ugb24gdGhlIFJlc291cmNlDQo+ PiBTZXJ2ZXIuICBUaGlzIGNvdWxkIGFsc28gYmUgbG9jYXRlZCBvbiBhIGNvbnN0cmFpbmVkIGRl dmljZS4NCj4+DQo+PiBSZXNvdXJjZSBPd25lcjogIFRoZSBzdWJqZWN0IHdobyBjb250cm9scyB0 aGUgYWNjZXNzIHBlcm1pc3Npb25zIG9mIGENCj4+IHJlc291cmNlLg0KPj4NCj4+IENsaWVudCBP d25lcjogICBUaGUgc3ViamVjdCB3aG8gY29udHJvbHMgdGhlIGFjY2VzcyBwZXJtaXNzaW9ucyBv ZiBhDQo+PiBjbGllbnQuDQo+Pg0KPj4gUHJpbmNpcGFsOiAgQSBzdWJqZWN0IHdobyBpcyBlaXRo ZXIgYSByZXNvdXJjZSBvd25lciBvciBhIGNsaWVudCBvd25lcg0KPj5vcg0KPj4gYm90aC4iDQo+ Pg0KPj4NCj4+IE9uIHRoZSBSZXNvdXJjZSBPd25lciBzaWRlIGl0IGlzIHZlcnkgY2xlYXIgd2hh dCBpcyB0aGUgaXRlbSBvZg0KPj5pbnRlcmVzdCwNCj4+IHdoZXJlIGl0IGlzIGhvc3RlZCwgd2hv IHdhbnRzIHRvIGFjY2VzcyBpdCBhbmQgd2hvIGRlY2lkZXMgYWJvdXQgdGhlDQo+PiBwZXJtaXNz aW9ucyB0byBhY2Nlc3MgaXQ6DQo+Pg0KPj4gLSBXaGF0OiBUaGUgUmVzb3VyY2UNCj4+IC0gV2hl cmU6IEF0IHRoZSBSZXNvdXJjZSBTZXJ2ZXINCj4+IC0gV2hvIHdhbnRzIHRvIGFjY2VzczogVGhl IENsaWVudA0KPj4gLSBXaG8gZGVjaWRlcyBhYm91dCB3aG8gaGFzIHRoZSByaWdodCB0byBhY2Nl c3M6IFRoZSBSZXNvdXJjZSBPd25lcg0KPj4NCj4+IFdpdGggcmVnYXJkcyB0byB0aGUgQ2xpZW50 IE93bmVyIGNvbnRyb2xsaW5nIHRoZSDigJxhY2Nlc3MgcGVybWlzc2lvbnMgb2YNCj4+YQ0KPj4g Y2xpZW50IiwgdGhhdCBpcyBub3QgYXQgYWxsIGNsZWFyIHRvIG1lLiBXaGF0IGlzIGJlaW5nIGFj Y2Vzc2VkIGF0IHRoZQ0KPj4gY2xpZW50PyBXaG8gd2FudHMgdG8gYWNjZXNzPw0KPg0KPkluIHRo ZSBzY2VuYXJpbyB3ZSBhcmUgYW5hbHlzaW5nLCB0aGVyZSBpcyB0aGUgY2xpZW50IG9uIG9uZSBl bmQgb2YgdGhlDQo+Y29udmVyc2F0aW9uIGFuZCB0aGUgUmVzb3VyY2UgU2VydmVyIG9uIHRoZSBv dGhlciBzaWRlLiBUaGUgY2xpZW50IG1heQ0KPmhhdmUgYSBkaWZmZXJlbnQgb3duZXIgdGhhdCB0 aGUgUmVzb3VyY2UgU2VydmVyLiBPbiB0aGUgUmVzb3VyY2UgU2VydmVyDQo+c2lkZSwgUmVzb3Vy Y2UgT3duZXJzIG1heSB3YW50IHRvIGNvbnRyb2wgd2hpY2ggZGF0YSBpcyBlbnRlcmluZyBhbmQN Cj5sZWF2aW5nIHRoZWlyIHJlc291cmNlcy4gT24gdGhlIGNsaWVudCBzaWRlLCBDbGllbnQgT3du ZXJzIG1heSB3YW50IHRvDQo+Y29udHJvbCB3aGljaCBkYXRhIGlzIGVudGVyaW5nIGFuZCBsZWF2 aW5nIHRoZWlyIGVuZHBvaW50cy4NCg0KSSB0aGluayBpdCB3b3VsZCBiZSB2ZXJ5IGhlbHBmdWwg aWYgeW91IGV4cGxhaW4gd2hhdCB0aGlzIG1lYW5zIGluIHRlcm1zDQpvZiB0aGUgdXNlIGNhc2Vz LCBzZWUgYmVsb3cuDQoNCg0KPg0KPlRvIHB1dCBpdCBhbm90aGVyIHdheTogVGhlIENsaWVudCBP d25lciBtYXkgd2FudCB0byBtYWtlIHN1cmUgdGhhdCBvbmx5DQo+YXV0aG9yaXplZCBlbmRwb2lu dHMgY2FuIHNlbmQgZGF0YSB0byB0aGUgY2xpZW50IGFuZCB0aGF0IHRoZSBjbGllbnQNCj5zZW5k cyBkYXRhIG9ubHkgdG8gYXV0aG9yaXplZCByZXNvdXJjZSBzZXJ2ZXJzLiBKdXN0IGFzIG9uIHRo ZSBSZXNvdXJjZQ0KPlNlcnZlciBzaWRlLCB0aGUgUmVzb3VyY2UgT3duZXIgbWF5IHdhbnQgdG8g bWFrZSBzdXJlIHRoYXQgb25seQ0KPmF1dGhvcml6ZWQgZW5kcG9pbnRzIGNhbiBzZW5kIGRhdGEg dG8gdGhlIFJlc291cmNlIFNlcnZlciBhbmQgdGhlDQo+UmVzb3VyY2UgU2VydmVyIHNlbmRzIGRh dGEgb25seSB0byBhdXRob3JpemVkIGNsaWVudHMuDQo+DQo+V2UgY291bGQgY2hhbmdlIHRoZSBk ZWZpbml0aW9uIG9mIENsaWVudCBPd25lciBmcm9tICJUaGUgc3ViamVjdCB3aG8NCj5jb250cm9s cyB0aGUgYWNjZXNzIHBlcm1pc3Npb25zIG9mIGEgY2xpZW50LiIgdG8gIlRoZSBzdWJqZWN0IHdo bw0KPmRlZmluZXMgYXV0aG9yaXphdGlvbiBwb2xpY2llcyBmb3IgYSBjbGllbnQiLiBEb2VzIHRo YXQgc29sdmUgeW91cg0KPnByb2JsZW0/DQo+DQo+Pg0KPj4NCj4+IFJlZ2FyZGluZyBTZWN0aW9u IDIuMToNCj4+DQo+PiAiVGhlcmUgYXJlIHZhcmlvdXMgcmVhc29ucyBmb3IgYXNzaWduaW5nIGEg ZnVuY3Rpb24gKGNsaWVudCBvciBzZXJ2ZXIpDQo+PnRvDQo+PiBhIGRldmljZSwgZS5nLiB3aGlj aCBkZXZpY2UgaW5pdGlhdGVzIHRoZSBjb252ZXJzYXRpb24sIGhvdyBkbyBkZXZpY2VzDQo+PiBm aW5kIGVhY2ggb3RoZXIsIGV0Yy4gIFRoZSBkZWZpbml0aW9uIG9mIHRoZSBmdW5jdGlvbiBvZiBh IGRldmljZSBpbiBhDQo+PiBjZXJ0YWluIHVzZSBjYXNlIGlzIG5vdCBpbiBzY29wZSBvZiB0aGlz IGRvY3VtZW50LiBSZWFkZXJzIHNob3VsZCBiZQ0KPj5hd2FyZQ0KPj4gdGhhdCB0aGVyZSBtaWdo dCBiZSByZWFzb25zIGZvciBlYWNoIHNldHRpbmcgYW5kIHRoYXQgZW5kcG9pbnRzIG1pZ2h0DQo+ PmV2ZW4NCj4+IGhhdmUgZGlmZmVyZW50IGZ1bmN0aW9ucyBhdCBkaWZmZXJlbnQgdGltZXMuIg0K Pj4NCj4+IEkgcmVtZW1iZXIgeW91IGhhdmUgdXNlZCB0aGlzIHJlYXNvbmluZyB0byBhcmd1ZSB0 aGF0IGl0IGlzIG5vdCBwb3NzaWJsZQ0KPj4gdG8gZXhwcmVzcyB3aGF0IGlzIHRoZSBSZXNvdXJj ZSBpbiBhIGdpdmVuIHVzZSBjYXNlLiBJZiB0aGlzIGlzIHRoZQ0KPj5jYXNlLA0KPj4gdGhhdCB3 aXRoIHRoaXMgdGVybWlub2xvZ3kgaXQgaXMgbm90IHBvc3NpYmxlIHRvIHNwZWNpZnkgd2hhdCBh cmUgdGhlDQo+PiAiaXRlbXMgb2YgaW50ZXJlc3QiIGluIGEgZ2l2ZW4gdXNlIGNhc2UsIHRoZW4g SSB0aGluayB0aGUgdGVybWlub2xvZ3kgaXMNCj4+IG5vdCBzYXRpc2ZhY3RvcnkuIFRoZSBwdXJw b3NlIG9mIHRoZSB1c2UgY2FzZSBkb2N1bWVudCBpcyB0byBoaWdobGlnaHQNCj4+IHdoYXQgaXMg dGhlIHByb2JsZW0gd2Ugc2hvdWxkIHNvbHZlLiBJZiB3ZSBjYW7igJl0IHVzZSB0aGUgdGVybQ0K Pj7igJxSZXNvdXJjZeKAnSwNCj4+IHRoZW4gd2hhdCBuZWVkIGRvIHdlIGhhdmUgZm9yIOKAnFJl c291cmNlIFNlcnZlcuKAnSBhbmQg4oCcUmVzb3VyY2UgT3duZXLigJ0/DQo+PiBGdXJ0aGVybW9y ZSDigJxDbGllbnTigJ0gaXMgZGVmaW5lZCBhcyB0aGUgUmVzb3VyY2UgYWNjZXNzaW5nIGVuZHBv aW50LCBzbw0KPj4gdGhlbiBuZWl0aGVyIHRoYXQgbm9yICJDbGllbnQgT3duZXLigJ0gaXMgd2Vs bCBkZWZpbmVkLg0KPg0KPkkgZG9uJ3QgdGhpbmsgSSB1bmRlcnN0YW5kIHlvdXIgcmVhc29uaW5n LiBJIGNhbid0IHJlbWVtYmVyIHNheWluZyB0aGF0DQo+d2UgZG9uJ3Qga25vdyB3aGF0IHRoZSBy ZXNvdXJjZSBpcyBpbiBhIGdpdmVuIHVzZSBjYXNlLg0KDQpNYXliZSBJIG1pc3VuZGVyc3Rvb2Qu IFdlbGwgdGhlbiwgbGV04oCZcyB1c2UgaXQuIFNlZSBiZWxvdy4NCg0KPg0KPlRoZSBwYXJhZ3Jh cGggZnJvbSBzZWN0aW9uIDIuMSBqdXN0IHN0YXRlcyB0aGF0IGl0IGlzIG5vdCBjbGVhciB3aGV0 aGVyDQo+YW4gZW5kcG9pbnQgaW4gYSB1c2UgY2FzZSBpcyBhIENvQVAgY2xpZW50IG9yIGEgc2Vy dmVyLiBJIGRvbid0IHRoaW5rDQo+dGhhdCBpdCBpcyBldmVuIG5lY2Vzc2FyeSB0byBiZSBhYmxl IHRvIGFzc2lnbiBhIGZ1bmN0aW9uIHNpbmNlIEkgZGlkbid0DQo+c2VlIGFueSBldmlkZW5jZSB5 ZXQgdGhhdCB0aGlzIHdvdWxkIGJlIHVzZWZ1bC4NCj4NCj5BcyBJIG1lbnRpb25lZCBpbiBteSBs YXN0IGUtbWFpbCB0byBMdWR3aWcsIHdlIG5lZWQgdGhlIHRlcm1zICJjbGllbnQNCj5hbmQgc2Vy dmVyIChvciByZXNvdXJjZSBzZXJ2ZXIpIHRvIGV4cHJlc3MgdGhlIHByb2JsZW0gdGhhdCBuZWVk cyB0byBiZQ0KPnNvbHZlZCwgZS5nLiBVNS43IiAoY2YNCj5odHRwOi8vd3d3LmlldGYub3JnL21h aWwtYXJjaGl2ZS93ZWIvYWNlL2N1cnJlbnQvbXNnMDA5NzMuaHRtbCkuDQo+DQo+V2UgY2FuIGNo YW5nZSAiUmVzb3VyY2UgU2VydmVyIiB0byAic2VydmVyIiB0byBmaXQgaXQgdG8gdGhlIENvQVAN Cj50ZXJtaW5vbG9neS4gSWYgd2UgZG9uJ3QgbmVlZCB0aGUgdGVybXMgQ2xpZW50IE93bmVyIGFu ZCBSZXNvdXJjZSBPd25lciwNCj53ZSBjYW4gcmVtb3ZlIHRoZXNlIHRlcm1zIGZyb20gdGhlIHRl cm1pbm9sb2d5IHNlY3Rpb24uIElzIHRoYXQgd2hhdCB5b3UNCj5hcmUgcHJvcG9zaW5nPw0KPg0K Pj4NCj4+IFRoZSBvbmx5IHJlbWFpbmluZyB0ZXJtIGlzIOKAnFByaW5jaXBhbOKAnSwgd2hpY2gg dGhlbiBiZWNvbWVzIGEgc3lub255bSB0bw0KPj4g4oCcc29tZW9uZSBzZXR0aW5nIGFjY2VzcyBj b250cm9sIHBvbGljaWVz4oCdLiBJZiB0aGlzIGlzIHRoZSBvbmx5IHRoaW5nIHlvdQ0KPj4gd2Fu dCB0byBleHByZXNzLCB0aGVuIEkgdGhpbmsgeW91IHNob3VsZCByZW1vdmUgdGhlIHJlc3Qgb2Yg dGhlIHRlcm1zLA0KPj5hcw0KPj4gdGhleSBhcmUgbm90IHVzZWQuIChSZXNvdXJjZSBTZXJ2ZXIg b3IgQ2xpZW50IGNhbiBiZSByZXBsYWNlZCBieSDigJxzb21lDQo+PiBwb3RlbnRpYWxseSBjb25z dHJhaW5lZCBkZXZpY2XigJ0gZXRjLikgQnV0IEkgdGhpbmsgdGhpcyBpcyBub3QgYXQgYWxsDQo+ PiBjbGFyaWZ5aW5nIHdoYXQgYXJlIHRoZSBhdXRob3JpemF0aW9uIHByb2JsZW1zLiBJbiBwYXJ0 aWN1bGFyIHNpbmNlIEkNCj4+aGF2ZQ0KPj4gaGFyZCB0aW1lIHVuZGVyc3RhbmRpbmcgd2hhdCBl eGFjdGx5IGFyZSB0aGUgYWNjZXNzIGNvbnRyb2wgcHJvYmxlbXMgb24NCj4+IHRoZSBjbGllbnQg c2lkZSwgSSB0aGluayBpdCB3b3VsZCBiZSBtb3JlIGhlbHBmdWwgdG8gZXhwbGFpbiB0aGF0IGlu IGENCj4+IGdpdmVuIHVzZSBjYXNlLiBXaGF0IGFyZSB0aGUgYWNjZXNzIGNvbnRyb2wgcG9saWN5 IGNvbnNpZGVyYXRpb25zIG9mIHRoZQ0KPj4gZnJ1aXQgdmVuZG9yLCB0aGUgdHJhbnNsb2FkaW5n IHBlcnNvbm5lbCBhbmQgdGhlIGNvbnRhaW5lciBvd25lcnM/DQo+DQo+V2UgY2FuIHBsYXkgb3V0 IEx1ZHdpZydzIHByb3Bvc2FsIGFuZCB1c2UgdGhlIG5hbWVzIG9mIHRoZSBzcGVjaWZpYw0KPmFj dG9ycyBpbiB0aGUgcHJvYmxlbSBzdW1tYXJ5IHNlY3Rpb24uIElzdCB0aGF0IHdoYXQgeW91IGFy ZSBwcm9wb3Npbmc/DQo+DQo+Rm9yIHRoZSBjb250YWluZXIgbW9uaXRvcmluZyB1c2UgY2FzZSwg dGhlIHNlY3Rpb24gd291bGQgbG9vayBsaWtlIHRoaXM6DQo+DQo+VTEuMSBQcmluY2lwYWxzIHN1 Y2ggYXMgdGhlIGZydWl0IHZlbmRvciwgdGhlIHRyYW5zbG9hZGluZyBwZXJzb25uZWwgb3INCj50 aGUgY29udGFpbmVyIG93bmVycyB3YW50IHRvIGRlZmluZSBhdXRob3JpemF0aW9ucyBmb3IgdGhl aXIgcmVzb3VyY2VzDQo+YW5kIGVuZHBvaW50cy4NCg0KQ291bGQgd2UgcmVwbGFjZSB0aGlzIHJl cXVpcmVtZW50IHdpdGggc29tZXRoaW5nIGNvbmNyZXRlPyBBcyBpdCBpcyBzdGF0ZWQNCm5vdyBJ IGludGVycHJldCBpdCByb3VnaGx5IGFzIOKAnGV2ZXJ5Ym9keSB3YW50cyB0byBzZXQgYWNjZXNz IHBvbGljaWVzIGZvcg0KdGhlaXIgdGhpbmdz4oCdLg0KDQpDb3VsZCB3ZSB0aGVuIHVzZSB0aGUg cHJvcG9zZWQgdGVybWlub2xvZ3kgdG8gZXhwcmVzczoNCi0gV2hhdCBhcmUgdGhlIFJlc291cmNl cy4NCi0gV2hpY2ggYXJlIHRoZSBDbGllbnRzIGFjY2Vzc2luZyB0aGUgUmVzb3VyY2VzLg0KLSBX aGF0IGFyZSB0aGUgYWNjZXNzIHBvbGljeSBjb25zaWRlcmF0aW9ucyBvZiB0aGUgUmVzb3VyY2Ug T3duZXJzLiBJLmUuOg0KV2hhdCBDbGllbnRzIHNob3VsZCBoYXZlIGFjY2VzcyB0byB3aGF0IFJl c291cmNlcy4NCi0gV2hhdCBhcmUgdGhlIGFjY2VzcyBwb2xpY3kgY29uc2lkZXJhdGlvbnMgb2Yg dGhlIENsaWVudCBPd25lcnMuDQoNCg0KVGhhbmtzDQpHw7ZyYW4NCg0KPg0KPlUxLjIgVGhlIGZy dWl0IHZlbmRvciByZXF1aXJlcyB0aGUgaW50ZWdyaXR5IG9mIHRoZSBzZW5zb3IgZGF0YSB0aGF0 DQo+cGVydGFpbnMgdGhlIHN0YXRlIG9mIHRoZSBnb29kcyBmb3IgY2xpbWF0ZSBjb250cm9sIGFu ZCB0byBlbnN1cmUgdGhlDQo+cXVhbGl0eSBvZiB0aGUgbW9uaXRvcmVkIHJlY29yZGluZ3MuDQo+ DQo+VTEuMyBUaGUgY29udGFpbmVyIG93bmVyIHJlcXVpcmVzIHRoZSBpbnRlZ3JpdHkgb2YgdGhl IHNlbnNvciBkYXRhIHRoYXQNCj5pcyB1c2VkIGZvciBjbGltYXRlIGNvbnRyb2wuDQo+DQo+VTEu NCBUaGUgZnJ1aXQgdmVuZG9yIHJlcXVpcmVzIHRoZSBjb25maWRlbnRpYWxpdHkgb2YgdGhlIHNl bnNvciBkYXRhDQo+dGhhdCBwZXJ0YWlucyB0aGUgc3RhdGUgb2YgdGhlIGdvb2RzLg0KPg0KPlUx LjUgVGhlIGZydWl0IHZlbmRvciBtYXkgaGF2ZSBzZXZlcmFsIHR5cGVzIG9mIGRhdGEgdGhhdCBt YXkgYmUNCj5jb250cm9sbGVkIGJ5IHRoZSBzYW1lIGVuZHBvaW50LCBlLmcuLCBzZW5zb3IgZGF0 YSBhbmQgdGhlIGRhdGEgdXNlZCBmb3INCj5sb2dpc3RpY3MuDQo+DQo+VTEuNiBUaGUgZnJ1aXQg dmVuZG9yIHJlcXVpcmVzIHRoZSBjb25maWRlbnRpYWxpdHkgb2YgdGhlIGRhdGEgdGhhdCBpcw0K PnVzZWQgdG8gbG9jYXRlIHRoZSBnb29kcy4NCj4NCj5VMS43IFRoZSBmcnVpdCB2ZW5kb3IgcmVx dWlyZXMgdGhlIGludGVncml0eSBvZiB0aGUgZGF0YSB0aGF0IGlzIHVzZWQgdG8NCj5sb2NhdGUg dGhlIGdvb2RzLg0KPg0KPlUxLjggVGhlIHRyYW5zbG9hZGluZyBwZXJzb25uZWwgcmVxdWlyZXMg dGhlIGludGVncml0eSBvZiB0aGUgZGF0YSB0aGF0DQo+aXMgdXNlZCB0byBsb2NhdGUgdGhlIGdv b2RzLg0KPg0KPlUxLjkgVGhlIGNvbnRhaW5lciBvd25lciBhbmQgdGhlIGZydWl0IHZlbmRvciBt YXkgbm90IGJlIHByZXNlbnQgYXQgdGhlDQo+dGltZSBvZiBhY2Nlc3MgYW5kIGNhbm5vdCBtYW51 YWxseSBpbnRlcnZlbmUgaW4gdGhlIGF1dGhvcml6YXRpb24gcHJvY2Vzcy4NCj4NCj5VMS4xMCBU aGUgcHJpbmNpcGFscyB3YW50IHRvIGdyYW50IHRlbXBvcmFyeSBhY2Nlc3MgcGVybWlzc2lvbnMg dG8gYQ0KPnBhcnR5Lg0KPg0KPlUxLjExIE1lc3NhZ2VzIGJldHdlZW4gY2xpZW50IGFuZCByZXNv dXJjZSBzZXJ2ZXIgbWlnaHQgbmVlZCB0byBiZQ0KPmZvcndhcmRlZCBvdmVyIG11bHRpcGxlIGhv cHMuDQo+DQo+VTEuMTIgVGhlIGNvbnN0cmFpbmVkIGRldmljZXMgbWlnaHQgbm90IGFsd2F5cyBi ZSBhYmxlIHRvIHJlYWNoIHRoZQ0KPkludGVybmV0Lg0KPg0KPkJlc3QgcmVnYXJkcywNCj5TdGVm ZmkNCg0K From nobody Wed Feb 11 08:17: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 424791A1A1E for ; Wed, 11 Feb 2015 08:17:37 -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 86bl2WxaFWG8 for ; Wed, 11 Feb 2015 08:17:34 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C73581A0393 for ; Wed, 11 Feb 2015 08:17:33 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t1BGHR3V006319; Wed, 11 Feb 2015 17:17:27 +0100 (CET) Received: from [IPv6:2001:638:708:30da:65e4:2319:2d9e:8bd] (unknown [IPv6:2001:638:708:30da:65e4:2319:2d9e:8bd]) (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 3kj5j34Hmrz2Nqn; Wed, 11 Feb 2015 17:17:27 +0100 (CET) Message-ID: <54DB8097.4030206@tzi.de> Date: Wed, 11 Feb 2015 17:17:27 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= References: <20150205095841.19111.5154.idtracker@ietfa.amsl.com> <54D341F6.9040109@tzi.de> <54D8D0C5.6030101@tzi.de> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Fwd: I-D Action: draft-ietf-ace-usecases-02.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 16:17:39 -0000 Hi Göran, I don't see how your questions provide anything useful to the use cases. The use cases document is about the problems that need to be solved. So the question is if there are relevant problems missing from the use cases or if there is something wrong with the described problems. You seem to believe that we failed to list authorization problems because the terminology is not suitable to describe them. Please provide text that describes these problems. If you think that the description of a problem is wrong, please provide details why they are wrong and provide text which you think will help to describe the problem correctly. Currently, it sounds like you don't like the terminology in the use cases draft because certain solutions use a different terminology. It is not the purpose of the use cases draft to define terminology for the authorization solution ACE will choose. If there is nothing wrong with the problems described in the use cases and no relevant problems are missing from the descriptions, I see no need to change the terminology. Best regards, Steffi On 02/10/2015 09:19 AM, Göran Selander wrote: > > Hi Steffi, > > Thanks for your constructive answer. A concrete request below. > > On 2015-02-09 16:22, "Stefanie Gerdes" wrote: > >> Hi Göran, >> >> On 02/06/2015 11:44 AM, Göran Selander wrote: >>> Hi Steffi, >>> >>> Some comments on the new proposed terminology. First of all, removing >>> ownership from the description of the terminology is a definite >>> improvement! But I still have a problem with this version, let me >>> include >>> your terminology (Section 1.1.) for the convenience of the readers: >>> >>> "Resource: An item of interest. >>> >>> Resource Server: The endpoint which hosts resources the Client wants to >>> access. Resource Servers might be located on constrained devices. >>> >>> Client: An endpoint which wants to access a resource on the Resource >>> Server. This could also be located on a constrained device. >>> >>> Resource Owner: The subject who controls the access permissions of a >>> resource. >>> >>> Client Owner: The subject who controls the access permissions of a >>> client. >>> >>> Principal: A subject who is either a resource owner or a client owner >>> or >>> both." >>> >>> >>> On the Resource Owner side it is very clear what is the item of >>> interest, >>> where it is hosted, who wants to access it and who decides about the >>> permissions to access it: >>> >>> - What: The Resource >>> - Where: At the Resource Server >>> - Who wants to access: The Client >>> - Who decides about who has the right to access: The Resource Owner >>> >>> With regards to the Client Owner controlling the “access permissions of >>> a >>> client", that is not at all clear to me. What is being accessed at the >>> client? Who wants to access? >> >> In the scenario we are analysing, there is the client on one end of the >> conversation and the Resource Server on the other side. The client may >> have a different owner that the Resource Server. On the Resource Server >> side, Resource Owners may want to control which data is entering and >> leaving their resources. On the client side, Client Owners may want to >> control which data is entering and leaving their endpoints. > > I think it would be very helpful if you explain what this means in terms > of the use cases, see below. > > >> >> To put it another way: The Client Owner may want to make sure that only >> authorized endpoints can send data to the client and that the client >> sends data only to authorized resource servers. Just as on the Resource >> Server side, the Resource Owner may want to make sure that only >> authorized endpoints can send data to the Resource Server and the >> Resource Server sends data only to authorized clients. >> >> We could change the definition of Client Owner from "The subject who >> controls the access permissions of a client." to "The subject who >> defines authorization policies for a client". Does that solve your >> problem? >> >>> >>> >>> Regarding Section 2.1: >>> >>> "There are various reasons for assigning a function (client or server) >>> to >>> a device, e.g. which device initiates the conversation, how do devices >>> find each other, etc. The definition of the function of a device in a >>> certain use case is not in scope of this document. Readers should be >>> aware >>> that there might be reasons for each setting and that endpoints might >>> even >>> have different functions at different times." >>> >>> I remember you have used this reasoning to argue that it is not possible >>> to express what is the Resource in a given use case. If this is the >>> case, >>> that with this terminology it is not possible to specify what are the >>> "items of interest" in a given use case, then I think the terminology is >>> not satisfactory. The purpose of the use case document is to highlight >>> what is the problem we should solve. If we can’t use the term >>> “Resource”, >>> then what need do we have for “Resource Server” and “Resource Owner”? >>> Furthermore “Client” is defined as the Resource accessing endpoint, so >>> then neither that nor "Client Owner” is well defined. >> >> I don't think I understand your reasoning. I can't remember saying that >> we don't know what the resource is in a given use case. > > Maybe I misunderstood. Well then, let’s use it. See below. > >> >> The paragraph from section 2.1 just states that it is not clear whether >> an endpoint in a use case is a CoAP client or a server. I don't think >> that it is even necessary to be able to assign a function since I didn't >> see any evidence yet that this would be useful. >> >> As I mentioned in my last e-mail to Ludwig, we need the terms "client >> and server (or resource server) to express the problem that needs to be >> solved, e.g. U5.7" (cf >> http://www.ietf.org/mail-archive/web/ace/current/msg00973.html). >> >> We can change "Resource Server" to "server" to fit it to the CoAP >> terminology. If we don't need the terms Client Owner and Resource Owner, >> we can remove these terms from the terminology section. Is that what you >> are proposing? >> >>> >>> The only remaining term is “Principal”, which then becomes a synonym to >>> “someone setting access control policies”. If this is the only thing you >>> want to express, then I think you should remove the rest of the terms, >>> as >>> they are not used. (Resource Server or Client can be replaced by “some >>> potentially constrained device” etc.) But I think this is not at all >>> clarifying what are the authorization problems. In particular since I >>> have >>> hard time understanding what exactly are the access control problems on >>> the client side, I think it would be more helpful to explain that in a >>> given use case. What are the access control policy considerations of the >>> fruit vendor, the transloading personnel and the container owners? >> >> We can play out Ludwig's proposal and use the names of the specific >> actors in the problem summary section. Ist that what you are proposing? >> >> For the container monitoring use case, the section would look like this: >> >> U1.1 Principals such as the fruit vendor, the transloading personnel or >> the container owners want to define authorizations for their resources >> and endpoints. > > Could we replace this requirement with something concrete? As it is stated > now I interpret it roughly as “everybody wants to set access policies for > their things”. > > Could we then use the proposed terminology to express: > - What are the Resources. > - Which are the Clients accessing the Resources. > - What are the access policy considerations of the Resource Owners. I.e.: > What Clients should have access to what Resources. > - What are the access policy considerations of the Client Owners. > > > Thanks > Göran > >> >> U1.2 The fruit vendor requires the integrity of the sensor data that >> pertains the state of the goods for climate control and to ensure the >> quality of the monitored recordings. >> >> U1.3 The container owner requires the integrity of the sensor data that >> is used for climate control. >> >> U1.4 The fruit vendor requires the confidentiality of the sensor data >> that pertains the state of the goods. >> >> U1.5 The fruit vendor may have several types of data that may be >> controlled by the same endpoint, e.g., sensor data and the data used for >> logistics. >> >> U1.6 The fruit vendor requires the confidentiality of the data that is >> used to locate the goods. >> >> U1.7 The fruit vendor requires the integrity of the data that is used to >> locate the goods. >> >> U1.8 The transloading personnel requires the integrity of the data that >> is used to locate the goods. >> >> U1.9 The container owner and the fruit vendor may not be present at the >> time of access and cannot manually intervene in the authorization process. >> >> U1.10 The principals want to grant temporary access permissions to a >> party. >> >> U1.11 Messages between client and resource server might need to be >> forwarded over multiple hops. >> >> U1.12 The constrained devices might not always be able to reach the >> Internet. >> >> Best regards, >> Steffi > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > -- Stefanie Gerdes Tel: +49 421 218 63906 TZI Universität Bremen E-Mail: gerdes@tzi.de Bibliothekstr. 1, MZH 5150 28359 Bremen, Germany From nobody Wed Feb 11 09:46: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 72E0A1A007D for ; Wed, 11 Feb 2015 09:46:01 -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 ilmZ01EuTfO4 for ; Wed, 11 Feb 2015 09:45:55 -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 526B01A1A27 for ; Wed, 11 Feb 2015 09:45:54 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-1d-54db954f53f7 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 08.34.24955.F459BD45; Wed, 11 Feb 2015 18:45:51 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.180]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0210.002; Wed, 11 Feb 2015 18:45:51 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Stefanie Gerdes Thread-Topic: [Ace] Fwd: I-D Action: draft-ietf-ace-usecases-02.txt Thread-Index: AQHQQSw5Sfw0ELIkVUS6mg1j4TnWLZzjcYsAgATz2oCAASzlgIACBw6AgAApeIA= Date: Wed, 11 Feb 2015 17:45:51 +0000 Message-ID: References: <20150205095841.19111.5154.idtracker@ietfa.amsl.com> <54D341F6.9040109@tzi.de> <54D8D0C5.6030101@tzi.de> <54DB8097.4030206@tzi.de> In-Reply-To: <54DB8097.4030206@tzi.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGfG3Rtd/6u0Qg9vLbCy+f+thtth48S6j A5PHkiU/mTy2vf3KHMAUxWWTkpqTWZZapG+XwJVxd3d1QU9FxZvF/cwNjA2lXYycHBICJhJ3 1y9ihbDFJC7cW8/WxcjFISRwhFHiXcchRghnCaNE0+dp7CBVbAIuEg8aHjGB2CICyhK/F38C s5kFFCV2zzoLViMs4CSx9NVjVogaZ4nj33czQth+En82NYLFWQRUJaYcvs8GYvMKWEgcunkN avM7RoknD64ydzFycHAKqEm8aXUGqWEEuu77qTVQu8Qlbj2ZzwRxtYDEkj3nmSFsUYmXj/+B zRcV0JNYeb2JDSKuJPFjwyUWkJHMApoS63fpQ4yxlui7dwbu/CndD9khzhGUODnzCcsERolZ SLbNQuiehaR7FpLuWUi6FzCyrmIULU4tTspNNzLWSy3KTC4uzs/Ty0st2cQIjMGDW36r7mC8 /MbxEKMAB6MSD++Go7dChFgTy4orcw8xSnOwKInz2hkfChESSE8sSc1OTS1ILYovKs1JLT7E yMTBKdXAWDLlwGJRJpfpO2dWxV4pOLNAMpl/UZXsuqx/Ls9/stdekJD2m1uvK8fxMWxm/tdn U7fd+6BckfC65+oD01etDhvyDygEhDMYaEeqtVy5fu3uCcXbjt/KXR+caI4XfPBwzumtOx4e LLp45LnJH/9KQZ6lva9E3H/4ZJ+SK5LNzk7Wlfm37eMJAyWW4oxEQy3mouJEAPK3LUaiAgAA Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Fwd: I-D Action: draft-ietf-ace-usecases-02.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 17:46:01 -0000 SGkgU3RlZmZpLA0KDQpJIGFza2VkIHlvdSB0byBkZXNjcmliZSwgdXNpbmcgeW91ciBwcm9wb3Nl ZCB0ZXJtaW5vbG9neSwgd2hhdCBhcmUgdGhlDQphdXRob3JpemF0aW9uIHByb2JsZW1zIG9uIHRo ZSBDbGllbnQgc2lkZSBpbiB0aGlzIGNvbmNyZXRlIHVzZSBjYXNlLA0KYmVjYXVzZSBJIGRvbuKA mXQgdW5kZXJzdGFuZCBleGFjdGx5IHdoYXQgdGhlc2UgcHJvYmxlbXMgYXJlLiAgSSBtYXkgYmUN Cndyb25nLCBidXQgb25lIGludGVycHJldGF0aW9uIG9mIHlvdXIgYW5zd2VyIGlzIHRoYXQgaXQg aXMgbm90IHBvc3NpYmxlIHRvDQpleHByZXNzIHRoZSBhdXRob3JpemF0aW9uIHByb2JsZW1zIG9u IHRoZSBDbGllbnQgc2lkZSB3aXRoIHRoaXMNCnRlcm1pbm9sb2d5LiAgT3IgYWx0ZXJuYXRpdmVs eSB0aGF0IHRoZXJlIGFyZSBubyByZWxldmFudCBhdXRob3JpemF0aW9uDQpwcm9ibGVtcyBvbiB0 aGUgQ2xpZW50IHNpZGUuICBPciBtYXliZSB5b3UganVzdCBkaWRu4oCZdCBzZWUgdGhlIHBvaW50 IG9mDQp0aGUgZXhlcmNpc2U/IA0KDQpJZiB3ZSBkb24ndCBleHBsYWluIHdoYXQgYXJlIHRoZSBy ZWxldmFudCBhdXRob3JpemF0aW9uIHByb2JsZW1zIG9uIHRoZQ0KQ2xpZW50IHNpZGUgaW4gdGhp cyB1c2UgY2FzZSwgdGhlbiBJIGRpc2FncmVlIHdpdGggdGhlIHRlcm0g4oCcUHJpbmNpcGFs4oCd IGluDQpVMS4xLiANCg0KUHJvcG9zYWw6DQoNCjEuIHJlcGxhY2UgdGhlIHRlcm0g4oCcUHJpbmNp cGFsIiBieSDigJxSZXNvdXJjZSBPd25lcuKAnSwgYW5kIGNoYW5nZSB0aGUgbGlzdA0Kb2YgYWN0 b3JzIGFjY29yZGluZ2x5LA0KDQpvciBhbHRlcm5hdGl2ZWx5Og0KDQoyLiByZXBsYWNlIFUxLjEg d2l0aCBtb3JlIGNvbmNyZXRlIHN0YXRlbWVudHMgc3VjaCBhcyAiVGhlIGZydWl0IHZlbmRvcg0K ZGVmaW5lcyB0aGUgYWNjZXNzIGNvbnRyb2wgcG9saWNpZXMgZm9yIHRoZSBzZW5zb3IgZGF0YSB0 aGF0IHBlcnRhaW5zIHRoZQ0Kc3RhdGUgb2YgdGhlIGdvb2Rz4oCdLCBldGMuDQoNCg0KDQpCZXN0 IHJlZ2FyZHMsDQpHw7ZyYW4NCg0KDQoNCk9uIDIwMTUtMDItMTEgMTc6MTcsICJTdGVmYW5pZSBH ZXJkZXMiIDxnZXJkZXNAdHppLmRlPiB3cm90ZToNCg0KPkhpIEfDtnJhbiwNCj4NCj5JIGRvbid0 IHNlZSBob3cgeW91ciBxdWVzdGlvbnMgcHJvdmlkZSBhbnl0aGluZyB1c2VmdWwgdG8gdGhlIHVz ZSBjYXNlcy4NCj4NCj5UaGUgdXNlIGNhc2VzIGRvY3VtZW50IGlzIGFib3V0IHRoZSBwcm9ibGVt cyB0aGF0IG5lZWQgdG8gYmUgc29sdmVkLiBTbw0KPnRoZSBxdWVzdGlvbiBpcyBpZiB0aGVyZSBh cmUgcmVsZXZhbnQgcHJvYmxlbXMgbWlzc2luZyBmcm9tIHRoZSB1c2UNCj5jYXNlcyBvciBpZiB0 aGVyZSBpcyBzb21ldGhpbmcgd3Jvbmcgd2l0aCB0aGUgZGVzY3JpYmVkIHByb2JsZW1zLg0KPg0K PllvdSBzZWVtIHRvIGJlbGlldmUgdGhhdCB3ZSBmYWlsZWQgdG8gbGlzdCBhdXRob3JpemF0aW9u IHByb2JsZW1zDQo+YmVjYXVzZSB0aGUgdGVybWlub2xvZ3kgaXMgbm90IHN1aXRhYmxlIHRvIGRl c2NyaWJlIHRoZW0uIFBsZWFzZSBwcm92aWRlDQo+dGV4dCB0aGF0IGRlc2NyaWJlcyB0aGVzZSBw cm9ibGVtcy4NCj4NCj5JZiB5b3UgdGhpbmsgdGhhdCB0aGUgZGVzY3JpcHRpb24gb2YgYSBwcm9i bGVtIGlzIHdyb25nLCBwbGVhc2UgcHJvdmlkZQ0KPmRldGFpbHMgd2h5IHRoZXkgYXJlIHdyb25n IGFuZCBwcm92aWRlIHRleHQgd2hpY2ggeW91IHRoaW5rIHdpbGwgaGVscCB0bw0KPmRlc2NyaWJl IHRoZSBwcm9ibGVtIGNvcnJlY3RseS4NCj4NCj5DdXJyZW50bHksIGl0IHNvdW5kcyBsaWtlIHlv dSBkb24ndCBsaWtlIHRoZSB0ZXJtaW5vbG9neSBpbiB0aGUgdXNlDQo+Y2FzZXMgZHJhZnQgYmVj YXVzZSBjZXJ0YWluIHNvbHV0aW9ucyB1c2UgYSBkaWZmZXJlbnQgdGVybWlub2xvZ3kuIEl0IGlz DQo+bm90IHRoZSBwdXJwb3NlIG9mIHRoZSB1c2UgY2FzZXMgZHJhZnQgdG8gZGVmaW5lIHRlcm1p bm9sb2d5IGZvciB0aGUNCj5hdXRob3JpemF0aW9uIHNvbHV0aW9uIEFDRSB3aWxsIGNob29zZS4N Cj4NCj5JZiB0aGVyZSBpcyBub3RoaW5nIHdyb25nIHdpdGggdGhlIHByb2JsZW1zIGRlc2NyaWJl ZCBpbiB0aGUgdXNlIGNhc2VzDQo+YW5kIG5vIHJlbGV2YW50IHByb2JsZW1zIGFyZSBtaXNzaW5n IGZyb20gdGhlIGRlc2NyaXB0aW9ucywgSSBzZWUgbm8NCj5uZWVkIHRvIGNoYW5nZSB0aGUgdGVy bWlub2xvZ3kuDQo+DQo+QmVzdCByZWdhcmRzLA0KPlN0ZWZmaQ0KPg0KPg0KPg0KPk9uIDAyLzEw LzIwMTUgMDk6MTkgQU0sIEfDtnJhbiBTZWxhbmRlciB3cm90ZToNCj4+DQo+PiBIaSBTdGVmZmks DQo+Pg0KPj4gVGhhbmtzIGZvciB5b3VyIGNvbnN0cnVjdGl2ZSBhbnN3ZXIuIEEgY29uY3JldGUg cmVxdWVzdCBiZWxvdy4NCj4+DQo+PiBPbiAyMDE1LTAyLTA5IDE2OjIyLCAiU3RlZmFuaWUgR2Vy ZGVzIiA8Z2VyZGVzQHR6aS5kZT4gd3JvdGU6DQo+Pg0KPj4+IEhpIEfDtnJhbiwNCj4+Pg0KPj4+ IE9uIDAyLzA2LzIwMTUgMTE6NDQgQU0sIEfDtnJhbiBTZWxhbmRlciB3cm90ZToNCj4+Pj4gSGkg U3RlZmZpLA0KPj4+Pg0KPj4+PiBTb21lIGNvbW1lbnRzIG9uIHRoZSBuZXcgcHJvcG9zZWQgdGVy bWlub2xvZ3kuIEZpcnN0IG9mIGFsbCwgcmVtb3ZpbmcNCj4+Pj4gb3duZXJzaGlwIGZyb20gdGhl IGRlc2NyaXB0aW9uIG9mIHRoZSB0ZXJtaW5vbG9neSBpcyBhIGRlZmluaXRlDQo+Pj4+IGltcHJv dmVtZW50ISBCdXQgSSBzdGlsbCBoYXZlIGEgcHJvYmxlbSB3aXRoIHRoaXMgdmVyc2lvbiwgbGV0 IG1lDQo+Pj4+IGluY2x1ZGUNCj4+Pj4geW91ciB0ZXJtaW5vbG9neSAoU2VjdGlvbiAxLjEuKSBm b3IgdGhlIGNvbnZlbmllbmNlIG9mIHRoZSByZWFkZXJzOg0KPj4+Pg0KPj4+PiAiUmVzb3VyY2U6 ICBBbiBpdGVtIG9mIGludGVyZXN0Lg0KPj4+Pg0KPj4+PiBSZXNvdXJjZSBTZXJ2ZXI6ICBUaGUg ZW5kcG9pbnQgd2hpY2ggaG9zdHMgcmVzb3VyY2VzIHRoZSBDbGllbnQgd2FudHMNCj4+Pj50bw0K Pj4+PiBhY2Nlc3MuICBSZXNvdXJjZSBTZXJ2ZXJzIG1pZ2h0IGJlIGxvY2F0ZWQgb24gY29uc3Ry YWluZWQgZGV2aWNlcy4NCj4+Pj4NCj4+Pj4gQ2xpZW50OiAgQW4gZW5kcG9pbnQgd2hpY2ggd2Fu dHMgdG8gYWNjZXNzIGEgcmVzb3VyY2Ugb24gdGhlIFJlc291cmNlDQo+Pj4+IFNlcnZlci4gIFRo aXMgY291bGQgYWxzbyBiZSBsb2NhdGVkIG9uIGEgY29uc3RyYWluZWQgZGV2aWNlLg0KPj4+Pg0K Pj4+PiBSZXNvdXJjZSBPd25lcjogIFRoZSBzdWJqZWN0IHdobyBjb250cm9scyB0aGUgYWNjZXNz IHBlcm1pc3Npb25zIG9mIGENCj4+Pj4gcmVzb3VyY2UuDQo+Pj4+DQo+Pj4+IENsaWVudCBPd25l cjogICBUaGUgc3ViamVjdCB3aG8gY29udHJvbHMgdGhlIGFjY2VzcyBwZXJtaXNzaW9ucyBvZiBh DQo+Pj4+IGNsaWVudC4NCj4+Pj4NCj4+Pj4gUHJpbmNpcGFsOiAgQSBzdWJqZWN0IHdobyBpcyBl aXRoZXIgYSByZXNvdXJjZSBvd25lciBvciBhIGNsaWVudCBvd25lcg0KPj4+PiBvcg0KPj4+PiBi b3RoLiINCj4+Pj4NCj4+Pj4NCj4+Pj4gT24gdGhlIFJlc291cmNlIE93bmVyIHNpZGUgaXQgaXMg dmVyeSBjbGVhciB3aGF0IGlzIHRoZSBpdGVtIG9mDQo+Pj4+IGludGVyZXN0LA0KPj4+PiB3aGVy ZSBpdCBpcyBob3N0ZWQsIHdobyB3YW50cyB0byBhY2Nlc3MgaXQgYW5kIHdobyBkZWNpZGVzIGFi b3V0IHRoZQ0KPj4+PiBwZXJtaXNzaW9ucyB0byBhY2Nlc3MgaXQ6DQo+Pj4+DQo+Pj4+IC0gV2hh dDogVGhlIFJlc291cmNlDQo+Pj4+IC0gV2hlcmU6IEF0IHRoZSBSZXNvdXJjZSBTZXJ2ZXINCj4+ Pj4gLSBXaG8gd2FudHMgdG8gYWNjZXNzOiBUaGUgQ2xpZW50DQo+Pj4+IC0gV2hvIGRlY2lkZXMg YWJvdXQgd2hvIGhhcyB0aGUgcmlnaHQgdG8gYWNjZXNzOiBUaGUgUmVzb3VyY2UgT3duZXINCj4+ Pj4NCj4+Pj4gV2l0aCByZWdhcmRzIHRvIHRoZSBDbGllbnQgT3duZXIgY29udHJvbGxpbmcgdGhl IOKAnGFjY2VzcyBwZXJtaXNzaW9ucw0KPj4+Pm9mDQo+Pj4+IGENCj4+Pj4gY2xpZW50IiwgdGhh dCBpcyBub3QgYXQgYWxsIGNsZWFyIHRvIG1lLiBXaGF0IGlzIGJlaW5nIGFjY2Vzc2VkIGF0IHRo ZQ0KPj4+PiBjbGllbnQ/IFdobyB3YW50cyB0byBhY2Nlc3M/DQo+Pj4NCj4+PiBJbiB0aGUgc2Nl bmFyaW8gd2UgYXJlIGFuYWx5c2luZywgdGhlcmUgaXMgdGhlIGNsaWVudCBvbiBvbmUgZW5kIG9m IHRoZQ0KPj4+IGNvbnZlcnNhdGlvbiBhbmQgdGhlIFJlc291cmNlIFNlcnZlciBvbiB0aGUgb3Ro ZXIgc2lkZS4gVGhlIGNsaWVudCBtYXkNCj4+PiBoYXZlIGEgZGlmZmVyZW50IG93bmVyIHRoYXQg dGhlIFJlc291cmNlIFNlcnZlci4gT24gdGhlIFJlc291cmNlIFNlcnZlcg0KPj4+IHNpZGUsIFJl c291cmNlIE93bmVycyBtYXkgd2FudCB0byBjb250cm9sIHdoaWNoIGRhdGEgaXMgZW50ZXJpbmcg YW5kDQo+Pj4gbGVhdmluZyB0aGVpciByZXNvdXJjZXMuIE9uIHRoZSBjbGllbnQgc2lkZSwgQ2xp ZW50IE93bmVycyBtYXkgd2FudCB0bw0KPj4+IGNvbnRyb2wgd2hpY2ggZGF0YSBpcyBlbnRlcmlu ZyBhbmQgbGVhdmluZyB0aGVpciBlbmRwb2ludHMuDQo+Pg0KPj4gSSB0aGluayBpdCB3b3VsZCBi ZSB2ZXJ5IGhlbHBmdWwgaWYgeW91IGV4cGxhaW4gd2hhdCB0aGlzIG1lYW5zIGluIHRlcm1zDQo+ PiBvZiB0aGUgdXNlIGNhc2VzLCBzZWUgYmVsb3cuDQo+Pg0KPj4NCj4+Pg0KPj4+IFRvIHB1dCBp dCBhbm90aGVyIHdheTogVGhlIENsaWVudCBPd25lciBtYXkgd2FudCB0byBtYWtlIHN1cmUgdGhh dCBvbmx5DQo+Pj4gYXV0aG9yaXplZCBlbmRwb2ludHMgY2FuIHNlbmQgZGF0YSB0byB0aGUgY2xp ZW50IGFuZCB0aGF0IHRoZSBjbGllbnQNCj4+PiBzZW5kcyBkYXRhIG9ubHkgdG8gYXV0aG9yaXpl ZCByZXNvdXJjZSBzZXJ2ZXJzLiBKdXN0IGFzIG9uIHRoZSBSZXNvdXJjZQ0KPj4+IFNlcnZlciBz aWRlLCB0aGUgUmVzb3VyY2UgT3duZXIgbWF5IHdhbnQgdG8gbWFrZSBzdXJlIHRoYXQgb25seQ0K Pj4+IGF1dGhvcml6ZWQgZW5kcG9pbnRzIGNhbiBzZW5kIGRhdGEgdG8gdGhlIFJlc291cmNlIFNl cnZlciBhbmQgdGhlDQo+Pj4gUmVzb3VyY2UgU2VydmVyIHNlbmRzIGRhdGEgb25seSB0byBhdXRo b3JpemVkIGNsaWVudHMuDQo+Pj4NCj4+PiBXZSBjb3VsZCBjaGFuZ2UgdGhlIGRlZmluaXRpb24g b2YgQ2xpZW50IE93bmVyIGZyb20gIlRoZSBzdWJqZWN0IHdobw0KPj4+IGNvbnRyb2xzIHRoZSBh Y2Nlc3MgcGVybWlzc2lvbnMgb2YgYSBjbGllbnQuIiB0byAiVGhlIHN1YmplY3Qgd2hvDQo+Pj4g ZGVmaW5lcyBhdXRob3JpemF0aW9uIHBvbGljaWVzIGZvciBhIGNsaWVudCIuIERvZXMgdGhhdCBz b2x2ZSB5b3VyDQo+Pj4gcHJvYmxlbT8NCj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBSZWdhcmRpbmcg U2VjdGlvbiAyLjE6DQo+Pj4+DQo+Pj4+ICJUaGVyZSBhcmUgdmFyaW91cyByZWFzb25zIGZvciBh c3NpZ25pbmcgYSBmdW5jdGlvbiAoY2xpZW50IG9yIHNlcnZlcikNCj4+Pj4gdG8NCj4+Pj4gYSBk ZXZpY2UsIGUuZy4gd2hpY2ggZGV2aWNlIGluaXRpYXRlcyB0aGUgY29udmVyc2F0aW9uLCBob3cg ZG8gZGV2aWNlcw0KPj4+PiBmaW5kIGVhY2ggb3RoZXIsIGV0Yy4gIFRoZSBkZWZpbml0aW9uIG9m IHRoZSBmdW5jdGlvbiBvZiBhIGRldmljZSBpbiBhDQo+Pj4+IGNlcnRhaW4gdXNlIGNhc2UgaXMg bm90IGluIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuIFJlYWRlcnMgc2hvdWxkIGJlDQo+Pj4+IGF3 YXJlDQo+Pj4+IHRoYXQgdGhlcmUgbWlnaHQgYmUgcmVhc29ucyBmb3IgZWFjaCBzZXR0aW5nIGFu ZCB0aGF0IGVuZHBvaW50cyBtaWdodA0KPj4+PiBldmVuDQo+Pj4+IGhhdmUgZGlmZmVyZW50IGZ1 bmN0aW9ucyBhdCBkaWZmZXJlbnQgdGltZXMuIg0KPj4+Pg0KPj4+PiBJIHJlbWVtYmVyIHlvdSBo YXZlIHVzZWQgdGhpcyByZWFzb25pbmcgdG8gYXJndWUgdGhhdCBpdCBpcyBub3QNCj4+Pj5wb3Nz aWJsZQ0KPj4+PiB0byBleHByZXNzIHdoYXQgaXMgdGhlIFJlc291cmNlIGluIGEgZ2l2ZW4gdXNl IGNhc2UuIElmIHRoaXMgaXMgdGhlDQo+Pj4+IGNhc2UsDQo+Pj4+IHRoYXQgd2l0aCB0aGlzIHRl cm1pbm9sb2d5IGl0IGlzIG5vdCBwb3NzaWJsZSB0byBzcGVjaWZ5IHdoYXQgYXJlIHRoZQ0KPj4+ PiAiaXRlbXMgb2YgaW50ZXJlc3QiIGluIGEgZ2l2ZW4gdXNlIGNhc2UsIHRoZW4gSSB0aGluayB0 aGUgdGVybWlub2xvZ3kNCj4+Pj5pcw0KPj4+PiBub3Qgc2F0aXNmYWN0b3J5LiBUaGUgcHVycG9z ZSBvZiB0aGUgdXNlIGNhc2UgZG9jdW1lbnQgaXMgdG8gaGlnaGxpZ2h0DQo+Pj4+IHdoYXQgaXMg dGhlIHByb2JsZW0gd2Ugc2hvdWxkIHNvbHZlLiBJZiB3ZSBjYW7igJl0IHVzZSB0aGUgdGVybQ0K Pj4+PiDigJxSZXNvdXJjZeKAnSwNCj4+Pj4gdGhlbiB3aGF0IG5lZWQgZG8gd2UgaGF2ZSBmb3Ig 4oCcUmVzb3VyY2UgU2VydmVy4oCdIGFuZCDigJxSZXNvdXJjZSBPd25lcuKAnT8NCj4+Pj4gRnVy dGhlcm1vcmUg4oCcQ2xpZW504oCdIGlzIGRlZmluZWQgYXMgdGhlIFJlc291cmNlIGFjY2Vzc2lu ZyBlbmRwb2ludCwgc28NCj4+Pj4gdGhlbiBuZWl0aGVyIHRoYXQgbm9yICJDbGllbnQgT3duZXLi gJ0gaXMgd2VsbCBkZWZpbmVkLg0KPj4+DQo+Pj4gSSBkb24ndCB0aGluayBJIHVuZGVyc3RhbmQg eW91ciByZWFzb25pbmcuIEkgY2FuJ3QgcmVtZW1iZXIgc2F5aW5nIHRoYXQNCj4+PiB3ZSBkb24n dCBrbm93IHdoYXQgdGhlIHJlc291cmNlIGlzIGluIGEgZ2l2ZW4gdXNlIGNhc2UuDQo+Pg0KPj4g TWF5YmUgSSBtaXN1bmRlcnN0b29kLiBXZWxsIHRoZW4sIGxldOKAmXMgdXNlIGl0LiBTZWUgYmVs b3cuDQo+Pg0KPj4+DQo+Pj4gVGhlIHBhcmFncmFwaCBmcm9tIHNlY3Rpb24gMi4xIGp1c3Qgc3Rh dGVzIHRoYXQgaXQgaXMgbm90IGNsZWFyIHdoZXRoZXINCj4+PiBhbiBlbmRwb2ludCBpbiBhIHVz ZSBjYXNlIGlzIGEgQ29BUCBjbGllbnQgb3IgYSBzZXJ2ZXIuIEkgZG9uJ3QgdGhpbmsNCj4+PiB0 aGF0IGl0IGlzIGV2ZW4gbmVjZXNzYXJ5IHRvIGJlIGFibGUgdG8gYXNzaWduIGEgZnVuY3Rpb24g c2luY2UgSQ0KPj4+ZGlkbid0DQo+Pj4gc2VlIGFueSBldmlkZW5jZSB5ZXQgdGhhdCB0aGlzIHdv dWxkIGJlIHVzZWZ1bC4NCj4+Pg0KPj4+IEFzIEkgbWVudGlvbmVkIGluIG15IGxhc3QgZS1tYWls IHRvIEx1ZHdpZywgd2UgbmVlZCB0aGUgdGVybXMgImNsaWVudA0KPj4+IGFuZCBzZXJ2ZXIgKG9y IHJlc291cmNlIHNlcnZlcikgdG8gZXhwcmVzcyB0aGUgcHJvYmxlbSB0aGF0IG5lZWRzIHRvIGJl DQo+Pj4gc29sdmVkLCBlLmcuIFU1LjciIChjZg0KPj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi9hY2UvY3VycmVudC9tc2cwMDk3My5odG1sKS4NCj4+Pg0KPj4+IFdlIGNh biBjaGFuZ2UgIlJlc291cmNlIFNlcnZlciIgdG8gInNlcnZlciIgdG8gZml0IGl0IHRvIHRoZSBD b0FQDQo+Pj4gdGVybWlub2xvZ3kuIElmIHdlIGRvbid0IG5lZWQgdGhlIHRlcm1zIENsaWVudCBP d25lciBhbmQgUmVzb3VyY2UNCj4+Pk93bmVyLA0KPj4+IHdlIGNhbiByZW1vdmUgdGhlc2UgdGVy bXMgZnJvbSB0aGUgdGVybWlub2xvZ3kgc2VjdGlvbi4gSXMgdGhhdCB3aGF0DQo+Pj55b3UNCj4+ PiBhcmUgcHJvcG9zaW5nPw0KPj4+DQo+Pj4+DQo+Pj4+IFRoZSBvbmx5IHJlbWFpbmluZyB0ZXJt IGlzIOKAnFByaW5jaXBhbOKAnSwgd2hpY2ggdGhlbiBiZWNvbWVzIGEgc3lub255bQ0KPj4+PnRv DQo+Pj4+IOKAnHNvbWVvbmUgc2V0dGluZyBhY2Nlc3MgY29udHJvbCBwb2xpY2llc+KAnS4gSWYg dGhpcyBpcyB0aGUgb25seSB0aGluZw0KPj4+PnlvdQ0KPj4+PiB3YW50IHRvIGV4cHJlc3MsIHRo ZW4gSSB0aGluayB5b3Ugc2hvdWxkIHJlbW92ZSB0aGUgcmVzdCBvZiB0aGUgdGVybXMsDQo+Pj4+ IGFzDQo+Pj4+IHRoZXkgYXJlIG5vdCB1c2VkLiAoUmVzb3VyY2UgU2VydmVyIG9yIENsaWVudCBj YW4gYmUgcmVwbGFjZWQgYnkg4oCcc29tZQ0KPj4+PiBwb3RlbnRpYWxseSBjb25zdHJhaW5lZCBk ZXZpY2XigJ0gZXRjLikgQnV0IEkgdGhpbmsgdGhpcyBpcyBub3QgYXQgYWxsDQo+Pj4+IGNsYXJp Znlpbmcgd2hhdCBhcmUgdGhlIGF1dGhvcml6YXRpb24gcHJvYmxlbXMuIEluIHBhcnRpY3VsYXIg c2luY2UgSQ0KPj4+PiBoYXZlDQo+Pj4+IGhhcmQgdGltZSB1bmRlcnN0YW5kaW5nIHdoYXQgZXhh Y3RseSBhcmUgdGhlIGFjY2VzcyBjb250cm9sIHByb2JsZW1zDQo+Pj4+b24NCj4+Pj4gdGhlIGNs aWVudCBzaWRlLCBJIHRoaW5rIGl0IHdvdWxkIGJlIG1vcmUgaGVscGZ1bCB0byBleHBsYWluIHRo YXQgaW4gYQ0KPj4+PiBnaXZlbiB1c2UgY2FzZS4gV2hhdCBhcmUgdGhlIGFjY2VzcyBjb250cm9s IHBvbGljeSBjb25zaWRlcmF0aW9ucyBvZg0KPj4+PnRoZQ0KPj4+PiBmcnVpdCB2ZW5kb3IsIHRo ZSB0cmFuc2xvYWRpbmcgcGVyc29ubmVsIGFuZCB0aGUgY29udGFpbmVyIG93bmVycz8NCj4+Pg0K Pj4+IFdlIGNhbiBwbGF5IG91dCBMdWR3aWcncyBwcm9wb3NhbCBhbmQgdXNlIHRoZSBuYW1lcyBv ZiB0aGUgc3BlY2lmaWMNCj4+PiBhY3RvcnMgaW4gdGhlIHByb2JsZW0gc3VtbWFyeSBzZWN0aW9u LiBJc3QgdGhhdCB3aGF0IHlvdSBhcmUgcHJvcG9zaW5nPw0KPj4+DQo+Pj4gRm9yIHRoZSBjb250 YWluZXIgbW9uaXRvcmluZyB1c2UgY2FzZSwgdGhlIHNlY3Rpb24gd291bGQgbG9vayBsaWtlDQo+ Pj50aGlzOg0KPj4+DQo+Pj4gVTEuMSBQcmluY2lwYWxzIHN1Y2ggYXMgdGhlIGZydWl0IHZlbmRv ciwgdGhlIHRyYW5zbG9hZGluZyBwZXJzb25uZWwgb3INCj4+PiB0aGUgY29udGFpbmVyIG93bmVy cyB3YW50IHRvIGRlZmluZSBhdXRob3JpemF0aW9ucyBmb3IgdGhlaXIgcmVzb3VyY2VzDQo+Pj4g YW5kIGVuZHBvaW50cy4NCj4+DQo+PiBDb3VsZCB3ZSByZXBsYWNlIHRoaXMgcmVxdWlyZW1lbnQg d2l0aCBzb21ldGhpbmcgY29uY3JldGU/IEFzIGl0IGlzDQo+PnN0YXRlZA0KPj4gbm93IEkgaW50 ZXJwcmV0IGl0IHJvdWdobHkgYXMg4oCcZXZlcnlib2R5IHdhbnRzIHRvIHNldCBhY2Nlc3MgcG9s aWNpZXMNCj4+Zm9yDQo+PiB0aGVpciB0aGluZ3PigJ0uDQo+Pg0KPj4gQ291bGQgd2UgdGhlbiB1 c2UgdGhlIHByb3Bvc2VkIHRlcm1pbm9sb2d5IHRvIGV4cHJlc3M6DQo+PiAtIFdoYXQgYXJlIHRo ZSBSZXNvdXJjZXMuDQo+PiAtIFdoaWNoIGFyZSB0aGUgQ2xpZW50cyBhY2Nlc3NpbmcgdGhlIFJl c291cmNlcy4NCj4+IC0gV2hhdCBhcmUgdGhlIGFjY2VzcyBwb2xpY3kgY29uc2lkZXJhdGlvbnMg b2YgdGhlIFJlc291cmNlIE93bmVycy4NCj4+SS5lLjoNCj4+IFdoYXQgQ2xpZW50cyBzaG91bGQg aGF2ZSBhY2Nlc3MgdG8gd2hhdCBSZXNvdXJjZXMuDQo+PiAtIFdoYXQgYXJlIHRoZSBhY2Nlc3Mg cG9saWN5IGNvbnNpZGVyYXRpb25zIG9mIHRoZSBDbGllbnQgT3duZXJzLg0KPj4NCj4+DQo+PiBU aGFua3MNCj4+IEfDtnJhbg0KPj4NCj4+Pg0KPj4+IFUxLjIgVGhlIGZydWl0IHZlbmRvciByZXF1 aXJlcyB0aGUgaW50ZWdyaXR5IG9mIHRoZSBzZW5zb3IgZGF0YSB0aGF0DQo+Pj4gcGVydGFpbnMg dGhlIHN0YXRlIG9mIHRoZSBnb29kcyBmb3IgY2xpbWF0ZSBjb250cm9sIGFuZCB0byBlbnN1cmUg dGhlDQo+Pj4gcXVhbGl0eSBvZiB0aGUgbW9uaXRvcmVkIHJlY29yZGluZ3MuDQo+Pj4NCj4+PiBV MS4zIFRoZSBjb250YWluZXIgb3duZXIgcmVxdWlyZXMgdGhlIGludGVncml0eSBvZiB0aGUgc2Vu c29yIGRhdGEgdGhhdA0KPj4+IGlzIHVzZWQgZm9yIGNsaW1hdGUgY29udHJvbC4NCj4+Pg0KPj4+ IFUxLjQgVGhlIGZydWl0IHZlbmRvciByZXF1aXJlcyB0aGUgY29uZmlkZW50aWFsaXR5IG9mIHRo ZSBzZW5zb3IgZGF0YQ0KPj4+IHRoYXQgcGVydGFpbnMgdGhlIHN0YXRlIG9mIHRoZSBnb29kcy4N Cj4+Pg0KPj4+IFUxLjUgVGhlIGZydWl0IHZlbmRvciBtYXkgaGF2ZSBzZXZlcmFsIHR5cGVzIG9m IGRhdGEgdGhhdCBtYXkgYmUNCj4+PiBjb250cm9sbGVkIGJ5IHRoZSBzYW1lIGVuZHBvaW50LCBl LmcuLCBzZW5zb3IgZGF0YSBhbmQgdGhlIGRhdGEgdXNlZA0KPj4+Zm9yDQo+Pj4gbG9naXN0aWNz Lg0KPj4+DQo+Pj4gVTEuNiBUaGUgZnJ1aXQgdmVuZG9yIHJlcXVpcmVzIHRoZSBjb25maWRlbnRp YWxpdHkgb2YgdGhlIGRhdGEgdGhhdCBpcw0KPj4+IHVzZWQgdG8gbG9jYXRlIHRoZSBnb29kcy4N Cj4+Pg0KPj4+IFUxLjcgVGhlIGZydWl0IHZlbmRvciByZXF1aXJlcyB0aGUgaW50ZWdyaXR5IG9m IHRoZSBkYXRhIHRoYXQgaXMgdXNlZA0KPj4+dG8NCj4+PiBsb2NhdGUgdGhlIGdvb2RzLg0KPj4+ DQo+Pj4gVTEuOCBUaGUgdHJhbnNsb2FkaW5nIHBlcnNvbm5lbCByZXF1aXJlcyB0aGUgaW50ZWdy aXR5IG9mIHRoZSBkYXRhIHRoYXQNCj4+PiBpcyB1c2VkIHRvIGxvY2F0ZSB0aGUgZ29vZHMuDQo+ Pj4NCj4+PiBVMS45IFRoZSBjb250YWluZXIgb3duZXIgYW5kIHRoZSBmcnVpdCB2ZW5kb3IgbWF5 IG5vdCBiZSBwcmVzZW50IGF0IHRoZQ0KPj4+IHRpbWUgb2YgYWNjZXNzIGFuZCBjYW5ub3QgbWFu dWFsbHkgaW50ZXJ2ZW5lIGluIHRoZSBhdXRob3JpemF0aW9uDQo+Pj5wcm9jZXNzLg0KPj4+DQo+ Pj4gVTEuMTAgVGhlIHByaW5jaXBhbHMgd2FudCB0byBncmFudCB0ZW1wb3JhcnkgYWNjZXNzIHBl cm1pc3Npb25zIHRvIGENCj4+PiBwYXJ0eS4NCj4+Pg0KPj4+IFUxLjExIE1lc3NhZ2VzIGJldHdl ZW4gY2xpZW50IGFuZCByZXNvdXJjZSBzZXJ2ZXIgbWlnaHQgbmVlZCB0byBiZQ0KPj4+IGZvcndh cmRlZCBvdmVyIG11bHRpcGxlIGhvcHMuDQo+Pj4NCj4+PiBVMS4xMiBUaGUgY29uc3RyYWluZWQg ZGV2aWNlcyBtaWdodCBub3QgYWx3YXlzIGJlIGFibGUgdG8gcmVhY2ggdGhlDQo+Pj4gSW50ZXJu ZXQuDQo+Pj4NCj4+PiBCZXN0IHJlZ2FyZHMsDQo+Pj4gU3RlZmZpDQo+Pg0KPj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IEFjZSBtYWlsaW5nIGxp c3QNCj4+IEFjZUBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9hY2UNCj4+DQo+Pg0KPg0KPi0tIA0KPlN0ZWZhbmllIEdlcmRlcwkJCVRlbDogKzQ5IDQy MSAyMTggNjM5MDYNCj5UWkkgVW5pdmVyc2l0w6R0IEJyZW1lbgkJRS1NYWlsOiBnZXJkZXNAdHpp LmRlDQo+QmlibGlvdGhla3N0ci4gMSwgTVpIIDUxNTANCj4yODM1OSBCcmVtZW4sIEdlcm1hbnkN Cg0K From nobody Thu Feb 12 06:17:50 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 898341A8872 for ; Thu, 12 Feb 2015 06:17:48 -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 2fluJTXyKZAs for ; Thu, 12 Feb 2015 06:17:45 -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 35B351A88E2 for ; Thu, 12 Feb 2015 06:17:45 -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 t1CEHcWf004426; Thu, 12 Feb 2015 15:17:38 +0100 (CET) Received: from [192.168.1.109] (p57A63D7F.dip0.t-ipconnect.de [87.166.61.127]) (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 3kjg0L2dmnz2PQY; Thu, 12 Feb 2015 15:17:38 +0100 (CET) Message-ID: <54DCB601.3070307@tzi.de> Date: Thu, 12 Feb 2015 15:17:37 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= References: <20150205095841.19111.5154.idtracker@ietfa.amsl.com> <54D341F6.9040109@tzi.de> <54D8D0C5.6030101@tzi.de> <54DB8097.4030206@tzi.de> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Fwd: I-D Action: draft-ietf-ace-usecases-02.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 14:17:48 -0000 Hi Göran, I don't see the point of this exercise. I explained the authorization problems several times already, e.g., two times in my last E-Mail. You even admitted that there are problems on both sides. I think your solution is to apply the same solution twice (see http://www.ietf.org/mail-archive/web/ace/current/msg00967.html). Therefore, I don't understand why you insist that we should not describe these problems in the use cases draft. Protecting resources on the on the resource server side is only one possibility for authorization and may not solve every problem. It is not a good idea to design the problem descriptions in the use cases draft to fit to a specific solution because that blindfolds us for other solutions that might be more suitable. To describe the authorization problem yet again: In the container monitoring case, the fruit vendor wants to define authorization policies for the temperatur sensors and the container owner wants to define authorization policies for the ventilation system. One of their devices may be a client, one of them may be a resource server. If the ventilation system is the client, the container owner will only want to allow data from authorized sources. If the temperature sensor is the client, the fruit vendor will only want to send sensor data to authorized resources. Principals can also be Resource Owners so I don't see the point in discussing this over and over. We could change: "Principals such as the fruit vendor, the transloading personnel or the container owners want to define authorizations for their resources and endpoints." to "Principals such as the fruit vendor, the transloading personnel or the container owners want to define authorizations for their resources and/or endpoints." if that helps things. Best regards, Steffi On 02/11/2015 06:45 PM, Göran Selander wrote: > Hi Steffi, > > I asked you to describe, using your proposed terminology, what are the > authorization problems on the Client side in this concrete use case, > because I don’t understand exactly what these problems are. I may be > wrong, but one interpretation of your answer is that it is not possible to > express the authorization problems on the Client side with this > terminology. Or alternatively that there are no relevant authorization > problems on the Client side. Or maybe you just didn’t see the point of > the exercise? > > If we don't explain what are the relevant authorization problems on the > Client side in this use case, then I disagree with the term “Principal” in > U1.1. > > Proposal: > > 1. replace the term “Principal" by “Resource Owner”, and change the list > of actors accordingly, > > or alternatively: > > 2. replace U1.1 with more concrete statements such as "The fruit vendor > defines the access control policies for the sensor data that pertains the > state of the goods”, etc. > > > > Best regards, > Göran > > > > On 2015-02-11 17:17, "Stefanie Gerdes" wrote: > >> Hi Göran, >> >> I don't see how your questions provide anything useful to the use cases. >> >> The use cases document is about the problems that need to be solved. So >> the question is if there are relevant problems missing from the use >> cases or if there is something wrong with the described problems. >> >> You seem to believe that we failed to list authorization problems >> because the terminology is not suitable to describe them. Please provide >> text that describes these problems. >> >> If you think that the description of a problem is wrong, please provide >> details why they are wrong and provide text which you think will help to >> describe the problem correctly. >> >> Currently, it sounds like you don't like the terminology in the use >> cases draft because certain solutions use a different terminology. It is >> not the purpose of the use cases draft to define terminology for the >> authorization solution ACE will choose. >> >> If there is nothing wrong with the problems described in the use cases >> and no relevant problems are missing from the descriptions, I see no >> need to change the terminology. >> >> Best regards, >> Steffi >> >> >> >> On 02/10/2015 09:19 AM, Göran Selander wrote: >>> >>> Hi Steffi, >>> >>> Thanks for your constructive answer. A concrete request below. >>> >>> On 2015-02-09 16:22, "Stefanie Gerdes" wrote: >>> >>>> Hi Göran, >>>> >>>> On 02/06/2015 11:44 AM, Göran Selander wrote: >>>>> Hi Steffi, >>>>> >>>>> Some comments on the new proposed terminology. First of all, removing >>>>> ownership from the description of the terminology is a definite >>>>> improvement! But I still have a problem with this version, let me >>>>> include >>>>> your terminology (Section 1.1.) for the convenience of the readers: >>>>> >>>>> "Resource: An item of interest. >>>>> >>>>> Resource Server: The endpoint which hosts resources the Client wants >>>>> to >>>>> access. Resource Servers might be located on constrained devices. >>>>> >>>>> Client: An endpoint which wants to access a resource on the Resource >>>>> Server. This could also be located on a constrained device. >>>>> >>>>> Resource Owner: The subject who controls the access permissions of a >>>>> resource. >>>>> >>>>> Client Owner: The subject who controls the access permissions of a >>>>> client. >>>>> >>>>> Principal: A subject who is either a resource owner or a client owner >>>>> or >>>>> both." >>>>> >>>>> >>>>> On the Resource Owner side it is very clear what is the item of >>>>> interest, >>>>> where it is hosted, who wants to access it and who decides about the >>>>> permissions to access it: >>>>> >>>>> - What: The Resource >>>>> - Where: At the Resource Server >>>>> - Who wants to access: The Client >>>>> - Who decides about who has the right to access: The Resource Owner >>>>> >>>>> With regards to the Client Owner controlling the “access permissions >>>>> of >>>>> a >>>>> client", that is not at all clear to me. What is being accessed at the >>>>> client? Who wants to access? >>>> >>>> In the scenario we are analysing, there is the client on one end of the >>>> conversation and the Resource Server on the other side. The client may >>>> have a different owner that the Resource Server. On the Resource Server >>>> side, Resource Owners may want to control which data is entering and >>>> leaving their resources. On the client side, Client Owners may want to >>>> control which data is entering and leaving their endpoints. >>> >>> I think it would be very helpful if you explain what this means in terms >>> of the use cases, see below. >>> >>> >>>> >>>> To put it another way: The Client Owner may want to make sure that only >>>> authorized endpoints can send data to the client and that the client >>>> sends data only to authorized resource servers. Just as on the Resource >>>> Server side, the Resource Owner may want to make sure that only >>>> authorized endpoints can send data to the Resource Server and the >>>> Resource Server sends data only to authorized clients. >>>> >>>> We could change the definition of Client Owner from "The subject who >>>> controls the access permissions of a client." to "The subject who >>>> defines authorization policies for a client". Does that solve your >>>> problem? >>>> >>>>> >>>>> >>>>> Regarding Section 2.1: >>>>> >>>>> "There are various reasons for assigning a function (client or server) >>>>> to >>>>> a device, e.g. which device initiates the conversation, how do devices >>>>> find each other, etc. The definition of the function of a device in a >>>>> certain use case is not in scope of this document. Readers should be >>>>> aware >>>>> that there might be reasons for each setting and that endpoints might >>>>> even >>>>> have different functions at different times." >>>>> >>>>> I remember you have used this reasoning to argue that it is not >>>>> possible >>>>> to express what is the Resource in a given use case. If this is the >>>>> case, >>>>> that with this terminology it is not possible to specify what are the >>>>> "items of interest" in a given use case, then I think the terminology >>>>> is >>>>> not satisfactory. The purpose of the use case document is to highlight >>>>> what is the problem we should solve. If we can’t use the term >>>>> “Resource”, >>>>> then what need do we have for “Resource Server” and “Resource Owner”? >>>>> Furthermore “Client” is defined as the Resource accessing endpoint, so >>>>> then neither that nor "Client Owner” is well defined. >>>> >>>> I don't think I understand your reasoning. I can't remember saying that >>>> we don't know what the resource is in a given use case. >>> >>> Maybe I misunderstood. Well then, let’s use it. See below. >>> >>>> >>>> The paragraph from section 2.1 just states that it is not clear whether >>>> an endpoint in a use case is a CoAP client or a server. I don't think >>>> that it is even necessary to be able to assign a function since I >>>> didn't >>>> see any evidence yet that this would be useful. >>>> >>>> As I mentioned in my last e-mail to Ludwig, we need the terms "client >>>> and server (or resource server) to express the problem that needs to be >>>> solved, e.g. U5.7" (cf >>>> http://www.ietf.org/mail-archive/web/ace/current/msg00973.html). >>>> >>>> We can change "Resource Server" to "server" to fit it to the CoAP >>>> terminology. If we don't need the terms Client Owner and Resource >>>> Owner, >>>> we can remove these terms from the terminology section. Is that what >>>> you >>>> are proposing? >>>> >>>>> >>>>> The only remaining term is “Principal”, which then becomes a synonym >>>>> to >>>>> “someone setting access control policies”. If this is the only thing >>>>> you >>>>> want to express, then I think you should remove the rest of the terms, >>>>> as >>>>> they are not used. (Resource Server or Client can be replaced by “some >>>>> potentially constrained device” etc.) But I think this is not at all >>>>> clarifying what are the authorization problems. In particular since I >>>>> have >>>>> hard time understanding what exactly are the access control problems >>>>> on >>>>> the client side, I think it would be more helpful to explain that in a >>>>> given use case. What are the access control policy considerations of >>>>> the >>>>> fruit vendor, the transloading personnel and the container owners? >>>> >>>> We can play out Ludwig's proposal and use the names of the specific >>>> actors in the problem summary section. Ist that what you are proposing? >>>> >>>> For the container monitoring use case, the section would look like >>>> this: >>>> >>>> U1.1 Principals such as the fruit vendor, the transloading personnel or >>>> the container owners want to define authorizations for their resources >>>> and endpoints. >>> >>> Could we replace this requirement with something concrete? As it is >>> stated >>> now I interpret it roughly as “everybody wants to set access policies >>> for >>> their things”. >>> >>> Could we then use the proposed terminology to express: >>> - What are the Resources. >>> - Which are the Clients accessing the Resources. >>> - What are the access policy considerations of the Resource Owners. >>> I.e.: >>> What Clients should have access to what Resources. >>> - What are the access policy considerations of the Client Owners. >>> >>> >>> Thanks >>> Göran >>> >>>> >>>> U1.2 The fruit vendor requires the integrity of the sensor data that >>>> pertains the state of the goods for climate control and to ensure the >>>> quality of the monitored recordings. >>>> >>>> U1.3 The container owner requires the integrity of the sensor data that >>>> is used for climate control. >>>> >>>> U1.4 The fruit vendor requires the confidentiality of the sensor data >>>> that pertains the state of the goods. >>>> >>>> U1.5 The fruit vendor may have several types of data that may be >>>> controlled by the same endpoint, e.g., sensor data and the data used >>>> for >>>> logistics. >>>> >>>> U1.6 The fruit vendor requires the confidentiality of the data that is >>>> used to locate the goods. >>>> >>>> U1.7 The fruit vendor requires the integrity of the data that is used >>>> to >>>> locate the goods. >>>> >>>> U1.8 The transloading personnel requires the integrity of the data that >>>> is used to locate the goods. >>>> >>>> U1.9 The container owner and the fruit vendor may not be present at the >>>> time of access and cannot manually intervene in the authorization >>>> process. >>>> >>>> U1.10 The principals want to grant temporary access permissions to a >>>> party. >>>> >>>> U1.11 Messages between client and resource server might need to be >>>> forwarded over multiple hops. >>>> >>>> U1.12 The constrained devices might not always be able to reach the >>>> Internet. >>>> >>>> Best regards, >>>> Steffi >>> >>> _______________________________________________ >>> Ace mailing list >>> Ace@ietf.org >>> https://www.ietf.org/mailman/listinfo/ace >>> >>> >> >> -- >> Stefanie Gerdes Tel: +49 421 218 63906 >> TZI Universität Bremen E-Mail: gerdes@tzi.de >> Bibliothekstr. 1, MZH 5150 >> 28359 Bremen, Germany > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > -- Stefanie Gerdes Tel: +49 421 218 63906 TZI Universität Bremen E-Mail: gerdes@tzi.de Bibliothekstr. 1, MZH 5150 28359 Bremen, Germany From nobody Thu Feb 12 06:51:54 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCBD31A8A9E for ; Thu, 12 Feb 2015 06:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.86 X-Spam-Level: X-Spam-Status: No, score=-0.86 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyYW5ENXGsl0 for ; Thu, 12 Feb 2015 06:51:45 -0800 (PST) Received: from outbox.sics.se (outbox.sics.se [193.10.64.137]) by ietfa.amsl.com (Postfix) with ESMTP id 8915A1A8BBE for ; Thu, 12 Feb 2015 06:51:09 -0800 (PST) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [192.36.171.201]) by outbox.sics.se (Postfix) with ESMTPS id 29047866 for ; Thu, 12 Feb 2015 15:51:05 +0100 (CET) Received: from norm.sics.se (norm.sics.se [193.10.64.192]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id t1CEp48Y022425 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 12 Feb 2015 15:51:04 +0100 Received: from [192.168.0.108] (unknown [85.235.11.178]) by norm.sics.se (Postfix) with ESMTPSA id 8A6C741E for ; Thu, 12 Feb 2015 15:51:04 +0100 (CET) Message-ID: <54DCBDD7.2060300@sics.se> Date: Thu, 12 Feb 2015 15:51:03 +0100 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: ace@ietf.org References: <20150205095841.19111.5154.idtracker@ietfa.amsl.com> <54D341F6.9040109@tzi.de> <54D8D0C5.6030101@tzi.de> <54DB8097.4030206@tzi.de> <54DCB601.3070307@tzi.de> In-Reply-To: <54DCB601.3070307@tzi.de> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030808040609020000080105" X-Bayes-Prob: 0.5 (Score 0, tokens from: outbound, outbound-sics-se:default, sics-se:default, base:default, @@RPTN) X-p0f-Info: os=Linux 2.2.x-3.x, link=Ethernet or modem X-CanIt-Geo: =?UTF-8?Q?ip=3D85.235.11.178; _country=3DSE; _region=3DSk=C3=A5ne; _city=3DLund; _latitude=3D55.7028; _longitude=3D13.1927; _http://maps.google.com/maps=3Fq=3D55.7028,13.1927&z=3D6?= X-CanItPRO-Stream: outbound-sics-se:outbound (inherits from outbound-sics-se:default, sics-se:default, base:default) X-Canit-Stats-ID: 09NPqP4UQ - 2001e631236d - 20150212 X-Antispam-Training-Forget: https://canit.sunet.se/canit/b.php?i=09NPqP4UQ&m=2001e631236d&t=20150212&c=f X-Antispam-Training-Nonspam: https://canit.sunet.se/canit/b.php?i=09NPqP4UQ&m=2001e631236d&t=20150212&c=n X-Antispam-Training-Spam: https://canit.sunet.se/canit/b.php?i=09NPqP4UQ&m=2001e631236d&t=20150212&c=s X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 85.235.11.178 is neither permitted nor denied by domain ludwig@sics.se) receiver=e-mailfilter01.sunet.se; client-ip=85.235.11.178; envelope-from=; helo=norm.sics.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: Subject: Re: [Ace] Fwd: I-D Action: draft-ietf-ace-usecases-02.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 14:51:51 -0000 This is a cryptographically signed message in MIME format. --------------ms030808040609020000080105 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 02/12/2015 03:17 PM, Stefanie Gerdes wrote: > Hi G=C3=B6ran, > > I don't see the point of this exercise. I explained the authorization > problems several times already, e.g., two times in my last E-Mail. You > even admitted that there are problems on both sides. I think your > solution is to apply the same solution twice (see > http://www.ietf.org/mail-archive/web/ace/current/msg00967.html). > Therefore, I don't understand why you insist that we should not describ= e > these problems in the use cases draft. Perhaps the reason is that your explanation was not quite convincing. As far as I see it there are indeed _security_ problems both on the=20 client and the server side. But you have failed to convince me that=20 there is an _authorization_ problem on the client side. > > Protecting resources on the on the resource server side is only one > possibility for authorization and may not solve every problem. It is no= t > a good idea to design the problem descriptions in the use cases draft t= o > fit to a specific solution because that blindfolds us for other > solutions that might be more suitable. > > To describe the authorization problem yet again: > In the container monitoring case, the fruit vendor wants to define > authorization policies for the temperature sensors and the container > owner wants to define authorization policies for the ventilation system= =2E > One of their devices may be a client, one of them may be a resource > server. If the ventilation system is the client, the container owner > will only want to allow data from authorized sources. I see this as "the container owner will only want to receive or send=20 data from/to authenticated sources". It is after all the client which=20 took the initiative to request or send data (otherwise it would be a=20 server in that specific message exchange). Perhaps you mean that there should be policies that determine which=20 (authenticated) servers a device can contact when acting in a client=20 role? I think that calling these authorization policies would be a=20 misnomer, since there is no enforcement. Either the code on the device=20 takes these policies into consideration before sending a request or not. I would call this type of policies 'security policies'. > If the temperature > sensor is the client, the fruit vendor will only want to send sensor > data to authorized resources. > In my mind that would be "send sensor data to authenticated servers". > Principals can also be Resource Owners so I don't see the point in > discussing this over and over. > The point is that the term "Principal" makes the problem description=20 vague and unclear, at least to me. I still don't see why we cannot reuse = the terminology of OAuth or UMA. /Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=C3=A4gen 17 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se --------------ms030808040609020000080105 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVDCC BhgwggUAoAMCAQICAwyGmDANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTE1MDEwODA4MzkwNloXDTE2MDEwOTIyNDEzMFowODEXMBUGA1UE AwwObHVkd2lnQHNpY3Muc2UxHTAbBgkqhkiG9w0BCQEWDmx1ZHdpZ0BzaWNzLnNlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxUHisC6rgXFsBHHBGo8ulz/cLX3gX5Ufhcwo rp+7djzMMuKPM1KOHq0bjWhmFe8ly8CzWdk2NS600t7IEBQWJiHLsdc12UqmNswQUpD7oqkR 1nRGT6leAHYTWapkR+nczZ2NxD+H7u4ZWVIZg0DFiTqtY8ghYHHYYy8BBoc/jHG78X4+JJAg s5XOa0gVl7W38vDvVpo14xhWEBGjzPk9WxWirqAF66PF+JEu2JD9LzFbpEq829SRXJMFB9wp oQNlH0UQ01/2sWCIBxPpHuEjxEF/V3Z/F2VsNTy4zvYrd+/MYO3w30F+bWQNZsMHEkTW1pEh iz7rQPWTBXoO8Fv0wQIDAQABo4IC1DCCAtAwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTqvKspqEm0E4R1sgsABYKk 6xDJqDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZBgNVHREEEjAQgQ5sdWR3 aWdAc2ljcy5zZTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcC AjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0 aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5 aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQEFBQADggEBAGXwFsbSfv4mMWqIk64CoxuR6ozo7J37igca7d9tpKIzVIp6xp7Zt+a+J9X3 1r4zgMRFnZJWQ5hy82W/fVDeG9i3NGMM6p7DNUrGjTbVHd11BQtbUOG9MSlyWKQbmt3Q1ElC f4SRLAQot5SPryLR2FTxQuFkMOrcDzVxNxnMgatOM2fAO8KS0H+wX+I7gC3pEnbg/eMqNgU+ Ktbc2y9naDNmLNLN65s8TT9xZyoQEn9S1oU8Xnh596OMu49Eccws8Ny+vAGESIHG4bqhMSjj rmDilL1Wj9nQahmBnID5oZD5g9s9KyqxiZIGNnowYYOpCrSeITZ1b7wg50dC8ySojnYwggY0 MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEw MjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0d Lep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiU fsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5Dp IpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuC YKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/ MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0j BBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzAB hhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nm c2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9 eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukD FUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyi kfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8Cnykh ExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b 970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCD z+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqA SfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNb BIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBth HSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+ UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAwyGmDAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTAyMTIxNDUxMDNaMCMGCSqGSIb3DQEJBDEW BBTLsBI42AIVe84gkngKTYOUkywNwDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDDIaYMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJKoZIhvcNAQEBBQAE ggEAY0zmf9U8BNmrjHA8BymrbvzqBktIhjAwjLRmxU8q4A3c1LXgiZBqTs13/nRHvIlozAd8 mWPySmAhjSgDpVBgACF3OTKAB4datM8d5OzIZaRmvS6R6Vr1XhqMAYeIxMKmxxz/ntwC32Rd gkC+VjcEJRQN1lbHugqbx3D3gDVMRo4zq10+el2J/9SAeFzDAiuYdAHRV8egtw6SRbUwQF91 Wr4eLy42uCZQ/YoTh7xl8QI+8GAeezo6x/nwBy7qU7zagMizdjDlPabC1dykQKkQsHBoFd/0 siqe35G5u9XGgB6Wa6LjeSfC48nx7xgQVbUX5f4InUG+5clG08ZN474ONAAAAAAAAA== --------------ms030808040609020000080105-- From nobody Thu Feb 12 07:19: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 69FD21A88B2 for ; Thu, 12 Feb 2015 07:19:17 -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 J3zfZUjQFSTx for ; Thu, 12 Feb 2015 07:19:16 -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 1B8A61A8857 for ; Thu, 12 Feb 2015 07:19:15 -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 t1CFJB9f024288; Thu, 12 Feb 2015 16:19:12 +0100 (CET) Received: from aung.tzi.org (eduroam-pool3-223.wlan.uni-bremen.de [134.102.232.223]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3kjhMM22f4z2Pfx; Thu, 12 Feb 2015 16:19:11 +0100 (CET) From: Olaf Bergmann To: Ludwig Seitz References: <20150205095841.19111.5154.idtracker@ietfa.amsl.com> <54D341F6.9040109@tzi.de> <54D8D0C5.6030101@tzi.de> <54DB8097.4030206@tzi.de> <54DCB601.3070307@tzi.de> <54DCBDD7.2060300@sics.se> Date: Thu, 12 Feb 2015 16:19:10 +0100 In-Reply-To: <54DCBDD7.2060300@sics.se> (Ludwig Seitz's message of "Thu, 12 Feb 2015 15:51:03 +0100") Message-ID: <87lhk317kh.fsf@tzi.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: ace@ietf.org Subject: Re: [Ace] Fwd: I-D Action: draft-ietf-ace-usecases-02.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 15:19:17 -0000 Hi Ludwig, Ludwig Seitz writes: > Perhaps you mean that there should be policies that determine which > (authenticated) servers a device can contact when acting in a client > role? I think that calling these authorization policies would be a > misnomer, since there is no enforcement. Either the code on the device > takes these policies into consideration before sending a request or > not. This is already (implicit) authorization. But sometimes you might want to differentiate the actions that a client does on authenticated endpoints. For example, it might be allowed report certain sensitive data it has collected to resource server A whereas it must not disclose this data to other resource servers it also has communication relationships to. This decision is very common in desktop systems where a dialog box opens saying "allow application x to send data to service y?". The issue with M2M is that you do not have modal dialog boxes popping up and therefore need to find other ways of performing this explicit authorization. Gr=C3=BC=C3=9Fe Olaf From nobody Fri Feb 13 00:23: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 980281A1B88 for ; Fri, 13 Feb 2015 00:23:28 -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 2SQSb0z8ZQSF for ; Fri, 13 Feb 2015 00:23: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 9E8A11A1B70 for ; Fri, 13 Feb 2015 00:23:22 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-95-54ddb4782796 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 3D.AE.24955.874BDD45; Fri, 13 Feb 2015 09:23:20 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.180]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0210.002; Fri, 13 Feb 2015 09:23:19 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Stefanie Gerdes Thread-Topic: [Ace] Fwd: I-D Action: draft-ietf-ace-usecases-02.txt Thread-Index: AQHQQSw5Sfw0ELIkVUS6mg1j4TnWLZzjcYsAgATz2oCAASzlgIACBw6AgAApeICAAUdhgIABQBmA Date: Fri, 13 Feb 2015 08:23:19 +0000 Message-ID: References: <20150205095841.19111.5154.idtracker@ietfa.amsl.com> <54D341F6.9040109@tzi.de> <54D8D0C5.6030101@tzi.de> <54DB8097.4030206@tzi.de> <54DCB601.3070307@tzi.de> In-Reply-To: <54DCB601.3070307@tzi.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-ID: <27B1FF72C30FA14EB8B405AFBE1520CE@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM+JvjW7FlrshBj9mqFp8/9bDbLHx4l1G ByaPJUt+Mnlse/uVOYApissmJTUnsyy1SN8ugStj8Yo1rAXHjjBWbHm6h7GB8cB+xi5GTg4J AROJA9+7oGwxiQv31rN1MXJxCAkcYZT4sfUXM4SzhFHi9NnrLCBVbAIuEg8aHjGB2CICyhK/ F38Cs5kFFCV2zzrLDmILCzhJLH31mBWixlni+PfdjBB2lMSHeUvB4iwCqhLPDswHinNw8ApY SEz74wSxazuTxJoZC8DmcAqoSdydeR+snhHouu+n1kDtEpe49WQ+E8TVAhJL9pxnhrBFJV4+ /gdWLyqgJ7HyehMbRFxJonHJE1aQXcwCmhLrd+lDjLGWmLNjIQvM+VO6H4Kt5RUQlDg58wnL BEaJWUi2zULonoWkexaS7llIuhcwsq5iFC1OLU7KTTcy1kstykwuLs7P08tLLdnECIzEg1t+ q+5gvPzG8RCjAAejEg/vhoy7IUKsiWXFlbmHGKU5WJTEee2MD4UICaQnlqRmp6YWpBbFF5Xm pBYfYmTi4JRqYExWPrma73P2kmcRGslHSpwCz1+/vUomc9PZadFmKVGWDo7XH655fOLXF2Nr GT/dfTKuRkuqpv3ROMDTl6tx0GJhVkmmhrPQLetb2h/P3Y8uu5conzd78fvu3iebWKunK1ts 2fLn8tKX01LY1zRWrn199f78Wfv+mP6IP8j0Nd56SmqohXzODE0lluKMREMt5qLiRAC5WOO9 pQIAAA== Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Fwd: I-D Action: draft-ietf-ace-usecases-02.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 08:23:28 -0000 SGkgU3RlZmZpLA0KDQpUaGFua3MgZm9yIHN0YXJ0aW5nIHRoZSBleGVyY2lzZS4gIEnigJlsbCBy ZWZyYWluIGZyb20gY29tbWVudGluZw0K4oCcYmxpbmRmb2xkc+KAnSAodGhvdWdoIGl0IGlzIHRl bXB0aW5nKSBhbmQgc3RpY2sgdG8gdGhlIHVzZSBjYXNlLCBpbmxpbmUuDQoNCk9uIDIwMTUtMDIt MTIgMTU6MTcsICJTdGVmYW5pZSBHZXJkZXMiIDxnZXJkZXNAdHppLmRlPiB3cm90ZToNCg0KPkhp IEfDtnJhbiwNCj4NCj5JIGRvbid0IHNlZSB0aGUgcG9pbnQgb2YgdGhpcyBleGVyY2lzZS4gSSBl eHBsYWluZWQgdGhlIGF1dGhvcml6YXRpb24NCj5wcm9ibGVtcyBzZXZlcmFsIHRpbWVzIGFscmVh ZHksIGUuZy4sIHR3byB0aW1lcyBpbiBteSBsYXN0IEUtTWFpbC4gWW91DQo+ZXZlbiBhZG1pdHRl ZCB0aGF0IHRoZXJlIGFyZSBwcm9ibGVtcyBvbiBib3RoIHNpZGVzLiBJIHRoaW5rIHlvdXINCj5z b2x1dGlvbiBpcyB0byBhcHBseSB0aGUgc2FtZSBzb2x1dGlvbiB0d2ljZSAoc2VlDQo+aHR0cDov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2FjZS9jdXJyZW50L21zZzAwOTY3Lmh0bWwp Lg0KPlRoZXJlZm9yZSwgSSBkb24ndCB1bmRlcnN0YW5kIHdoeSB5b3UgaW5zaXN0IHRoYXQgd2Ug c2hvdWxkIG5vdCBkZXNjcmliZQ0KPnRoZXNlIHByb2JsZW1zIGluIHRoZSB1c2UgY2FzZXMgZHJh ZnQuDQo+DQo+UHJvdGVjdGluZyByZXNvdXJjZXMgb24gdGhlIG9uIHRoZSByZXNvdXJjZSBzZXJ2 ZXIgc2lkZSBpcyBvbmx5IG9uZQ0KPnBvc3NpYmlsaXR5IGZvciBhdXRob3JpemF0aW9uIGFuZCBt YXkgbm90IHNvbHZlIGV2ZXJ5IHByb2JsZW0uIEl0IGlzIG5vdA0KPmEgZ29vZCBpZGVhIHRvIGRl c2lnbiB0aGUgcHJvYmxlbSBkZXNjcmlwdGlvbnMgaW4gdGhlIHVzZSBjYXNlcyBkcmFmdCB0bw0K PmZpdCB0byBhIHNwZWNpZmljIHNvbHV0aW9uIGJlY2F1c2UgdGhhdCBibGluZGZvbGRzIHVzIGZv ciBvdGhlcg0KPnNvbHV0aW9ucyB0aGF0IG1pZ2h0IGJlIG1vcmUgc3VpdGFibGUuDQo+DQo+VG8g ZGVzY3JpYmUgdGhlIGF1dGhvcml6YXRpb24gcHJvYmxlbSB5ZXQgYWdhaW46DQo+SW4gdGhlIGNv bnRhaW5lciBtb25pdG9yaW5nIGNhc2UsIHRoZSBmcnVpdCB2ZW5kb3Igd2FudHMgdG8gZGVmaW5l DQo+YXV0aG9yaXphdGlvbiBwb2xpY2llcyBmb3IgdGhlIHRlbXBlcmF0dXIgc2Vuc29ycyBhbmQg dGhlIGNvbnRhaW5lcg0KPm93bmVyIHdhbnRzIHRvIGRlZmluZSBhdXRob3JpemF0aW9uIHBvbGlj aWVzIGZvciB0aGUgdmVudGlsYXRpb24gc3lzdGVtLg0KDQpXZWxsIHN1bW1hcml6ZWQsIHRoZXNl IGFyZSB0aGUgcmVsZXZhbnQgYXV0aG9yaXphdGlvbiBwcm9ibGVtcy4gUmVwbGFjZQ0KVTEuMSB3 aXRoIHNvbWV0aGluZyBsaWtlIHRoaXMgYW5kIHdlIGFyZSBkb25lIHdpdGggdXNlIGNhc2UgMS4N Cg0KDQo+IA0KPk9uZSBvZiB0aGVpciBkZXZpY2VzIG1heSBiZSBhIGNsaWVudCwgb25lIG9mIHRo ZW0gbWF5IGJlIGEgcmVzb3VyY2UNCj5zZXJ2ZXIuIA0KDQpBbGxvdyBtZSB0byBjb21wbGV0ZSB0 aGUgZXhlcmNpc2UsIHVzaW5nIHlvdXIgcHJvcG9zZWQgdGVybWlub2xvZ3kuIFdlDQphZ3JlZWQg YSBmZXcgbWFpbHMgYWdvIHRoYXQgdGhlIHJlc291cmNlcyBhcmUgd2VsbCBkZWZpbmVkDQpodHRw Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvYWNlL2N1cnJlbnQvbXNnMDA5ODIuaHRt bA0KDQooT3IgeW91IGZvcm11bGF0ZWQgaXQgIkkgY2FuJ3QgcmVtZW1iZXIgc2F5aW5nIHRoYXQg d2UgZG9uJ3Qga25vdyB3aGF0IHRoZQ0KcmVzb3VyY2UgaXMgaW4gYSBnaXZlbiB1c2UgY2FzZS7i gJ0sIHdoaWNoIEkgaG9wZSBtZWFucyB0aGF0IHlvdSBhZ3JlZSB0aGF0DQp0aGUgcmVzb3VyY2Vz IGFyZSB3ZWxsIGRlZmluZWQuKQ0KDQoNCkFjY2VzcyBjb250cm9sIHByb2JsZW0gMTogRW50aXR5 IDEgd2FudHMgdG8gYWNjZXNzIGEgdGVtcGVyYXR1cmUuDQoNCkNsZWFybHksIHRoZSDigJxpdGVt IG9mIGludGVyZXN04oCdLCB3aGljaCBzb21lb25lIHdhbnRzIHRvIGFjY2VzcywgaXM6IHRoZQ0K dGVtcGVyYXR1cmUuDQoNCi0gUmVzb3VyY2U6IFRlbXBlcmF0dXJlDQotIFJlc291cmNlIFNlcnZl cjogVGVtcGVyYXR1cmUgc2Vuc29yIGhvc3RpbmcgZGV2aWNlDQotIFJlc291cmNlIE93bmVyOiBG cnVpdCB2ZW5kb3INCi0gQ2xpZW50OiBEZXZpY2UgaG9zdGluZyBFbnRpdHkgMQ0KDQpBY2Nlc3Mg Y29udHJvbCBwcm9ibGVtIDI6IEVudGl0eSAyIHdhbnRzIHRvIGFjY2VzcyBhIHZlbnRpbGF0aW9u IGFjdHVhdGlvbg0KcmVzb3VyY2UgKHNheSBhIGZhbiBzZXR0aW5nKQ0KDQpDbGVhcmx5LCB0aGUg 4oCcaXRlbSBvZiBpbnRlcmVzdOKAnSwgIHdoaWNoIHNvbWVvbmUgd2FudHMgdG8gYWNjZXNzLCBp czogdGhlDQpmYW4gc2V0dGluZy4gDQoNCg0KLSBSZXNvdXJjZTogRmFuIHNldHRpbmcNCi0gUmVz b3VyY2UgU2VydmVyOiBWZW50aWxhdGlvbiBhY3R1YXRvciBob3N0aW5nIGRldmljZQ0KLSBSZXNv dXJjZSBPd25lcjogQ29udGFpbmVyIE93bmVyDQotIENsaWVudDogRW50aXR5IDINCg0KDQpPZiBj b3Vyc2UgYW4gYWNjZXNzaW5nIGVudGl0eSAo4oCcY2xpZW504oCdKSBvZiBvbmUgcmVzb3VyY2Ug Y2FuIGJlIGhvc3RlZCBpbg0KdGhlIHNhbWUgZGV2aWNlIGFzIHNvbWUgb3RoZXIgcmVzb3VyY2Uu IFRoaXMgZG9lc27igJl0IG1ha2Ugb25lIHJlc291cmNlIGENCmNsaWVudCBvZiBhbm90aGVyIHJl c291cmNlLiBJbiBzdW1tYXJ5LCB0aGVyZSBhcmUgdHdvIGRpc3RpbmN0IGFjY2Vzcw0KY29udHJv bCBwcm9ibGVtcywgYW5kIHRoZXJlIG1heSBiZSBjb250cm9sIGxvZ2ljIHdoZXJlaW4gb25lIHJl c291cmNlDQpyZXByZXNlbnRhdGlvbiB0cmlnZ2VycyBhbiBhY2Nlc3MgcmVxdWVzdCB0byBhbm90 aGVyIHJlc291cmNlLg0KDQoNCg0KPklmIHRoZSB2ZW50aWxhdGlvbiBzeXN0ZW0gaXMgdGhlIGNs aWVudCwgdGhlIGNvbnRhaW5lciBvd25lcg0KPndpbGwgb25seSB3YW50IHRvIGFsbG93IGRhdGEg ZnJvbSBhdXRob3Jpc2VkIHNvdXJjZXMuDQo+SWYgdGhlIHRlbXBlcmF0dXJlIHNlbnNvciBpcyB0 aGUgY2xpZW50LCB0aGUgZnJ1aXQgdmVuZG9yIHdpbGwgb25seSB3YW50DQo+dG8gc2VuZCBzZW5z b3INCj5kYXRhIHRvIGF1dGhvcml6ZWQgcmVzb3VyY2VzLg0KPg0KPg0KDQpJIHRha2UgaXQgeW91 IG1lYW4gdGhhdCB0aGUgdmVudGlsYXRpb24gc3lzdGVtIGhvc3RzIGEgY2xpZW50IG9mIHRoZQ0K dGVtcGVyYXR1cmUgcmVzb3VyY2UuDQoNCk5vdywgd2hhdCBraW5kIG9mIGFjY2VzcyBjb250cm9s IHByb2JsZW0gaXMg4oCcb25seSBhbGxvdyBkYXRhIGZyb20NCmF1dGhvcml6ZWQgc291cmNlc+KA nT8gKEFuYWxvZ291cyBjb21tZW50cyBmb3Igc2VuZGluZyB0byBhdXRob3JpemVkDQpyZXNvdXJj ZXMuKQ0KDQotIFRoZSBjbGllbnQgc2hvdWxkIGFsc28gIm9ubHkgYWxsb3cgYWNjZXNzIHRva2Vu cyBmcm9tIGF1dGhvcml6ZWQNCnNvdXJjZXPigJ0gKGF1dGhvcml6YXRpb24gc2VydmVycykuDQoN Ci0gSXQgc2hvdWxkICJvbmx5IGFsbG93IGRhdGEgZnJvbSBhdXRob3JpemVkIGNsb3VkIHNlcnZp Y2VzIiBvZiB0aGUNCmNvbnRhaW5lciBvd25lciAobm90IHBhcnRpY3VsYXIgZm9yIHRoaXMgZXhh bXBsZSwgYnV0IGp1c3QgYXMgYW4gZXhhbXBsZQ0Kb2YgYW5vdGhlciBzb3VyY2Ugb2YgZGF0YSB0 aGF0IG5lZWRzIHRvIGJlICJhdXRob3JpemVk4oCdKS4NCg0KLSBBIGRldmljZSBzaG91bGQgIm9u bHkgYWxsb3cgZGF0YSBmcm9tIGF1dGhvcml6ZWQgZHJpdmVycyIgaW4NCmNvbW11bmljYXRpbmcg d2l0aCBpdHMgcmVzb3VyY2VzLg0KDQotIEl0IHNob3VsZCAib25seSBhbGxvdyBkYXRhIGZyb20g YXV0aG9yaXplZCBjaXBoZXJzdWl0ZXMiIGluDQpjb21tdW5pY2F0aW9uIHdpdGggdGhlIHJlc291 cmNlIChpZiB5b3UgdmlldyBkZWNyeXB0aW9uIGFzIGEgc291cmNlIG9mDQpwb3RlbnRpYWxseSB1 bmF1dGhvcml6ZWQgZGF0YSkuDQoNCklmIHlvdSB0aGluayBhYm91dCBpdCwgdGhlcmUgaXMgYSBs b3Qgb2YgdGhpbmdzIHRoYXQgbmVlZHMgdG8gYmUNCuKAnGF1dGhvcml6ZWTigJ0uICBBbGwgdGhl c2UgImF1dGhvcml6YXRpb24gcHJvYmxlbXPigJ0gY2FuIHBvdGVudGlhbGx5IGJlIGhhcmQNCmNv ZGVkLiBBbGwgY2FuIHBvdGVudGlhbGx5IGJlIGFkZHJlc3NlZCB3aXRoIGFjY2VzcyBjb250cm9s IHBvbGljaWVzLA0KZGVjaXNpb24sIGVuZm9yY2VtZW50IGV0Yy4uIE15IG9iamVjdGlvbnMgdG8g aW5jbHVkZSB0aGlzIGNhdGVnb3J5IG9mDQpwcm9ibGVtcyBpbiBBQ0UgaXM6DQoNCi0gVGhlIHBy b2JsZW0gaXMgbm90IHdlbGwgc2NvcGVkIChhcyB0aGlzIGxpc3Qgb2YgZXhhbXBsZXMgdHJpZXMg dG8NCmlsbHVzdHJhdGUpIGNvbXBhcmVkIHRvIHRoZSBhY2Nlc3MgY29udHJvbCBwcm9ibGVtcyBh Ym92ZQ0KLSBJIHNlZSBubyBldmlkZW5jZSBpbiB0aGUgdXNlIGNhc2VzIHRoYXQgdGhpcyBpcyBh biBpbXBvcnRhbnQgcHJvYmxlbQ0KdGhhdCBuZWVkcyB0byBiZSBhZGRyZXNzZWQgd2l0aCBhY2Nl c3MgcG9saWNpZXMgZXRjLi4NCi0gVGhpcyBhcyBhbiBpbmRlcGVuZGVudCBwcm9ibGVtIHdoaWNo IG1ha2VzIHRoZSB0b3RhbCBwcm9ibGVtIHN0YXRlbWVudA0KbW9yZSBjb21wbGV4LiANCg0KSGVu Y2UgaXQgc2hvdWxkIGJlIGxlZnQgb3V0IG9mIHNjb3BlLg0KDQpUaGUgY2FzdWFsIOKAnFByaW5j aXBhbHMgd2FudCAuLuKAnSBmb3JtdWxhdGlvbiBpbiB0aGUgcmVxdWlyZW1lbnRzIGlzIGhpZGlu Zw0KdGhlIGZhY3QgdGhhdCBpdCBpcyBhIHByaW9yaSBkaWZmZXJlbnQgcHJvYmxlbXMgb24gdGhl IGNsaWVudCBzaWRlIGFuZCB0aGUNCnJlc291cmNlIHNpZGUuIFRoZXJlZm9yZSB5b3VyIHByb3Bv c2VkIGZvcm11bGF0aW9uIHByZXZlbnRzIGEgZGlzY3Vzc2lvbg0Kb2YgdGhlIHNjb3BlIG9mIEFD RSwgYW5kIGluIGVzc2VuY2UgcHJlc2VudHMgYSBjb25jbHVzaW9uIHRoYXQgdGhlIGNsaWVudA0K YW5kIHJlc291cmNlIHByb2JsZW1zIGFyZSBvYnZpb3VzbHkgc2ltaWxhciBhbmQgZXF1YWxseSBy ZWxldmFudCwgd2hpY2ggSQ0KZG9u4oCZdCBzZWUgYW55IHByb29mIG9mLg0KDQoNCj4NCj5Qcmlu Y2lwYWxzIGNhbiBhbHNvIGJlIFJlc291cmNlIE93bmVycyBzbyBJIGRvbid0IHNlZSB0aGUgcG9p bnQgaW4NCj5kaXNjdXNzaW5nIHRoaXMgb3ZlciBhbmQgb3Zlci4NCg0KDQoiTWFtbWFscyBjYW4g YWxzbyBiZSBFbGVwaGFudHPigJ0uIChZb3UgbWVhbiBvZiBjb3Vyc2UgIkVsZXBoYW50cyBhcmUN Ck1hbW1hbHPigJ0uKSBEb24ndCB5b3Ugc2VlIHRoZSBwb2ludCBpbiBkaXNjdXNzaW5nIHRoZSBz dGF0ZW1lbnQg4oCcTWFtbWFscw0Kd2FsayBvbiBmb3VyIGxlZ3PigJ0/DQoNCkJvdHRvbSBsaW5l OiBNeSBwcm9wb3NhbCBpbiB0aGUgcHJldmlvdXMgbWFpbC4NCg0KQmVzdCBSZWdhcmRzLA0KR8O2 cmFuDQoNCg0KPg0KPldlIGNvdWxkIGNoYW5nZTogIlByaW5jaXBhbHMgc3VjaCBhcyB0aGUgZnJ1 aXQgdmVuZG9yLCB0aGUgdHJhbnNsb2FkaW5nDQo+cGVyc29ubmVsIG9yIHRoZSBjb250YWluZXIg b3duZXJzIHdhbnQgdG8gZGVmaW5lIGF1dGhvcml6YXRpb25zIGZvcg0KPnRoZWlyIHJlc291cmNl cyBhbmQgZW5kcG9pbnRzLiINCj50bw0KPiJQcmluY2lwYWxzIHN1Y2ggYXMgdGhlIGZydWl0IHZl bmRvciwgdGhlIHRyYW5zbG9hZGluZyBwZXJzb25uZWwgb3IgdGhlDQo+Y29udGFpbmVyIG93bmVy cyB3YW50IHRvIGRlZmluZSBhdXRob3JpemF0aW9ucyBmb3IgdGhlaXIgcmVzb3VyY2VzDQo+YW5k L29yIGVuZHBvaW50cy4iIGlmIHRoYXQgaGVscHMgdGhpbmdzLg0KPg0KPkJlc3QgcmVnYXJkcywN Cj5TdGVmZmkNCj4NCj4NCj5PbiAwMi8xMS8yMDE1IDA2OjQ1IFBNLCBHw7ZyYW4gU2VsYW5kZXIg d3JvdGU6DQo+PiBIaSBTdGVmZmksDQo+Pg0KPj4gSSBhc2tlZCB5b3UgdG8gZGVzY3JpYmUsIHVz aW5nIHlvdXIgcHJvcG9zZWQgdGVybWlub2xvZ3ksIHdoYXQgYXJlIHRoZQ0KPj4gYXV0aG9yaXph dGlvbiBwcm9ibGVtcyBvbiB0aGUgQ2xpZW50IHNpZGUgaW4gdGhpcyBjb25jcmV0ZSB1c2UgY2Fz ZSwNCj4+IGJlY2F1c2UgSSBkb27igJl0IHVuZGVyc3RhbmQgZXhhY3RseSB3aGF0IHRoZXNlIHBy b2JsZW1zIGFyZS4gIEkgbWF5IGJlDQo+PiB3cm9uZywgYnV0IG9uZSBpbnRlcnByZXRhdGlvbiBv ZiB5b3VyIGFuc3dlciBpcyB0aGF0IGl0IGlzIG5vdCBwb3NzaWJsZQ0KPj50bw0KPj4gZXhwcmVz cyB0aGUgYXV0aG9yaXphdGlvbiBwcm9ibGVtcyBvbiB0aGUgQ2xpZW50IHNpZGUgd2l0aCB0aGlz DQo+PiB0ZXJtaW5vbG9neS4gIE9yIGFsdGVybmF0aXZlbHkgdGhhdCB0aGVyZSBhcmUgbm8gcmVs ZXZhbnQgYXV0aG9yaXphdGlvbg0KPj4gcHJvYmxlbXMgb24gdGhlIENsaWVudCBzaWRlLiAgT3Ig bWF5YmUgeW91IGp1c3QgZGlkbuKAmXQgc2VlIHRoZSBwb2ludCBvZg0KPj4gdGhlIGV4ZXJjaXNl Pw0KPj4NCj4+IElmIHdlIGRvbid0IGV4cGxhaW4gd2hhdCBhcmUgdGhlIHJlbGV2YW50IGF1dGhv cml6YXRpb24gcHJvYmxlbXMgb24gdGhlDQo+PiBDbGllbnQgc2lkZSBpbiB0aGlzIHVzZSBjYXNl LCB0aGVuIEkgZGlzYWdyZWUgd2l0aCB0aGUgdGVybSDigJxQcmluY2lwYWzigJ0NCj4+aW4NCj4+ IFUxLjEuDQo+Pg0KPj4gUHJvcG9zYWw6DQo+Pg0KPj4gMS4gcmVwbGFjZSB0aGUgdGVybSDigJxQ cmluY2lwYWwiIGJ5IOKAnFJlc291cmNlIE93bmVy4oCdLCBhbmQgY2hhbmdlIHRoZSBsaXN0DQo+ PiBvZiBhY3RvcnMgYWNjb3JkaW5nbHksDQo+Pg0KPj4gb3IgYWx0ZXJuYXRpdmVseToNCj4+DQo+ PiAyLiByZXBsYWNlIFUxLjEgd2l0aCBtb3JlIGNvbmNyZXRlIHN0YXRlbWVudHMgc3VjaCBhcyAi VGhlIGZydWl0IHZlbmRvcg0KPj4gZGVmaW5lcyB0aGUgYWNjZXNzIGNvbnRyb2wgcG9saWNpZXMg Zm9yIHRoZSBzZW5zb3IgZGF0YSB0aGF0IHBlcnRhaW5zDQo+PnRoZQ0KPj4gc3RhdGUgb2YgdGhl IGdvb2Rz4oCdLCBldGMuDQo+Pg0KPj4NCj4+DQo+PiBCZXN0IHJlZ2FyZHMsDQo+PiBHw7ZyYW4N Cj4+DQo+Pg0KPj4NCj4+IE9uIDIwMTUtMDItMTEgMTc6MTcsICJTdGVmYW5pZSBHZXJkZXMiIDxn ZXJkZXNAdHppLmRlPiB3cm90ZToNCj4+DQo+Pj4gSGkgR8O2cmFuLA0KPj4+DQo+Pj4gSSBkb24n dCBzZWUgaG93IHlvdXIgcXVlc3Rpb25zIHByb3ZpZGUgYW55dGhpbmcgdXNlZnVsIHRvIHRoZSB1 c2UNCj4+PmNhc2VzLg0KPj4+DQo+Pj4gVGhlIHVzZSBjYXNlcyBkb2N1bWVudCBpcyBhYm91dCB0 aGUgcHJvYmxlbXMgdGhhdCBuZWVkIHRvIGJlIHNvbHZlZC4gU28NCj4+PiB0aGUgcXVlc3Rpb24g aXMgaWYgdGhlcmUgYXJlIHJlbGV2YW50IHByb2JsZW1zIG1pc3NpbmcgZnJvbSB0aGUgdXNlDQo+ Pj4gY2FzZXMgb3IgaWYgdGhlcmUgaXMgc29tZXRoaW5nIHdyb25nIHdpdGggdGhlIGRlc2NyaWJl ZCBwcm9ibGVtcy4NCj4+Pg0KPj4+IFlvdSBzZWVtIHRvIGJlbGlldmUgdGhhdCB3ZSBmYWlsZWQg dG8gbGlzdCBhdXRob3JpemF0aW9uIHByb2JsZW1zDQo+Pj4gYmVjYXVzZSB0aGUgdGVybWlub2xv Z3kgaXMgbm90IHN1aXRhYmxlIHRvIGRlc2NyaWJlIHRoZW0uIFBsZWFzZQ0KPj4+cHJvdmlkZQ0K Pj4+IHRleHQgdGhhdCBkZXNjcmliZXMgdGhlc2UgcHJvYmxlbXMuDQo+Pj4NCj4+PiBJZiB5b3Ug dGhpbmsgdGhhdCB0aGUgZGVzY3JpcHRpb24gb2YgYSBwcm9ibGVtIGlzIHdyb25nLCBwbGVhc2Ug cHJvdmlkZQ0KPj4+IGRldGFpbHMgd2h5IHRoZXkgYXJlIHdyb25nIGFuZCBwcm92aWRlIHRleHQg d2hpY2ggeW91IHRoaW5rIHdpbGwgaGVscA0KPj4+dG8NCj4+PiBkZXNjcmliZSB0aGUgcHJvYmxl bSBjb3JyZWN0bHkuDQo+Pj4NCj4+PiBDdXJyZW50bHksIGl0IHNvdW5kcyBsaWtlIHlvdSBkb24n dCBsaWtlIHRoZSB0ZXJtaW5vbG9neSBpbiB0aGUgdXNlDQo+Pj4gY2FzZXMgZHJhZnQgYmVjYXVz ZSBjZXJ0YWluIHNvbHV0aW9ucyB1c2UgYSBkaWZmZXJlbnQgdGVybWlub2xvZ3kuIEl0DQo+Pj5p cw0KPj4+IG5vdCB0aGUgcHVycG9zZSBvZiB0aGUgdXNlIGNhc2VzIGRyYWZ0IHRvIGRlZmluZSB0 ZXJtaW5vbG9neSBmb3IgdGhlDQo+Pj4gYXV0aG9yaXphdGlvbiBzb2x1dGlvbiBBQ0Ugd2lsbCBj aG9vc2UuDQo+Pj4NCj4+PiBJZiB0aGVyZSBpcyBub3RoaW5nIHdyb25nIHdpdGggdGhlIHByb2Js ZW1zIGRlc2NyaWJlZCBpbiB0aGUgdXNlIGNhc2VzDQo+Pj4gYW5kIG5vIHJlbGV2YW50IHByb2Js ZW1zIGFyZSBtaXNzaW5nIGZyb20gdGhlIGRlc2NyaXB0aW9ucywgSSBzZWUgbm8NCj4+PiBuZWVk IHRvIGNoYW5nZSB0aGUgdGVybWlub2xvZ3kuDQo+Pj4NCj4+PiBCZXN0IHJlZ2FyZHMsDQo+Pj4g U3RlZmZpDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gT24gMDIvMTAvMjAxNSAwOToxOSBBTSwgR8O2cmFu IFNlbGFuZGVyIHdyb3RlOg0KPj4+Pg0KPj4+PiBIaSBTdGVmZmksDQo+Pj4+DQo+Pj4+IFRoYW5r cyBmb3IgeW91ciBjb25zdHJ1Y3RpdmUgYW5zd2VyLiBBIGNvbmNyZXRlIHJlcXVlc3QgYmVsb3cu DQo+Pj4+DQo+Pj4+IE9uIDIwMTUtMDItMDkgMTY6MjIsICJTdGVmYW5pZSBHZXJkZXMiIDxnZXJk ZXNAdHppLmRlPiB3cm90ZToNCj4+Pj4NCj4+Pj4+IEhpIEfDtnJhbiwNCj4+Pj4+DQo+Pj4+PiBP biAwMi8wNi8yMDE1IDExOjQ0IEFNLCBHw7ZyYW4gU2VsYW5kZXIgd3JvdGU6DQo+Pj4+Pj4gSGkg U3RlZmZpLA0KPj4+Pj4+DQo+Pj4+Pj4gU29tZSBjb21tZW50cyBvbiB0aGUgbmV3IHByb3Bvc2Vk IHRlcm1pbm9sb2d5LiBGaXJzdCBvZiBhbGwsDQo+Pj4+Pj5yZW1vdmluZw0KPj4+Pj4+IG93bmVy c2hpcCBmcm9tIHRoZSBkZXNjcmlwdGlvbiBvZiB0aGUgdGVybWlub2xvZ3kgaXMgYSBkZWZpbml0 ZQ0KPj4+Pj4+IGltcHJvdmVtZW50ISBCdXQgSSBzdGlsbCBoYXZlIGEgcHJvYmxlbSB3aXRoIHRo aXMgdmVyc2lvbiwgbGV0IG1lDQo+Pj4+Pj4gaW5jbHVkZQ0KPj4+Pj4+IHlvdXIgdGVybWlub2xv Z3kgKFNlY3Rpb24gMS4xLikgZm9yIHRoZSBjb252ZW5pZW5jZSBvZiB0aGUgcmVhZGVyczoNCj4+ Pj4+Pg0KPj4+Pj4+ICJSZXNvdXJjZTogIEFuIGl0ZW0gb2YgaW50ZXJlc3QuDQo+Pj4+Pj4NCj4+ Pj4+PiBSZXNvdXJjZSBTZXJ2ZXI6ICBUaGUgZW5kcG9pbnQgd2hpY2ggaG9zdHMgcmVzb3VyY2Vz IHRoZSBDbGllbnQNCj4+Pj4+PndhbnRzDQo+Pj4+Pj4gdG8NCj4+Pj4+PiBhY2Nlc3MuICBSZXNv dXJjZSBTZXJ2ZXJzIG1pZ2h0IGJlIGxvY2F0ZWQgb24gY29uc3RyYWluZWQgZGV2aWNlcy4NCj4+ Pj4+Pg0KPj4+Pj4+IENsaWVudDogIEFuIGVuZHBvaW50IHdoaWNoIHdhbnRzIHRvIGFjY2VzcyBh IHJlc291cmNlIG9uIHRoZQ0KPj4+Pj4+UmVzb3VyY2UNCj4+Pj4+PiBTZXJ2ZXIuICBUaGlzIGNv dWxkIGFsc28gYmUgbG9jYXRlZCBvbiBhIGNvbnN0cmFpbmVkIGRldmljZS4NCj4+Pj4+Pg0KPj4+ Pj4+IFJlc291cmNlIE93bmVyOiAgVGhlIHN1YmplY3Qgd2hvIGNvbnRyb2xzIHRoZSBhY2Nlc3Mg cGVybWlzc2lvbnMgb2YNCj4+Pj4+PmENCj4+Pj4+PiByZXNvdXJjZS4NCj4+Pj4+Pg0KPj4+Pj4+ IENsaWVudCBPd25lcjogICBUaGUgc3ViamVjdCB3aG8gY29udHJvbHMgdGhlIGFjY2VzcyBwZXJt aXNzaW9ucyBvZiBhDQo+Pj4+Pj4gY2xpZW50Lg0KPj4+Pj4+DQo+Pj4+Pj4gUHJpbmNpcGFsOiAg QSBzdWJqZWN0IHdobyBpcyBlaXRoZXIgYSByZXNvdXJjZSBvd25lciBvciBhIGNsaWVudA0KPj4+ Pj4+b3duZXINCj4+Pj4+PiBvcg0KPj4+Pj4+IGJvdGguIg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+ PiBPbiB0aGUgUmVzb3VyY2UgT3duZXIgc2lkZSBpdCBpcyB2ZXJ5IGNsZWFyIHdoYXQgaXMgdGhl IGl0ZW0gb2YNCj4+Pj4+PiBpbnRlcmVzdCwNCj4+Pj4+PiB3aGVyZSBpdCBpcyBob3N0ZWQsIHdo byB3YW50cyB0byBhY2Nlc3MgaXQgYW5kIHdobyBkZWNpZGVzIGFib3V0IHRoZQ0KPj4+Pj4+IHBl cm1pc3Npb25zIHRvIGFjY2VzcyBpdDoNCj4+Pj4+Pg0KPj4+Pj4+IC0gV2hhdDogVGhlIFJlc291 cmNlDQo+Pj4+Pj4gLSBXaGVyZTogQXQgdGhlIFJlc291cmNlIFNlcnZlcg0KPj4+Pj4+IC0gV2hv IHdhbnRzIHRvIGFjY2VzczogVGhlIENsaWVudA0KPj4+Pj4+IC0gV2hvIGRlY2lkZXMgYWJvdXQg d2hvIGhhcyB0aGUgcmlnaHQgdG8gYWNjZXNzOiBUaGUgUmVzb3VyY2UgT3duZXINCj4+Pj4+Pg0K Pj4+Pj4+IFdpdGggcmVnYXJkcyB0byB0aGUgQ2xpZW50IE93bmVyIGNvbnRyb2xsaW5nIHRoZSDi gJxhY2Nlc3MgcGVybWlzc2lvbnMNCj4+Pj4+PiBvZg0KPj4+Pj4+IGENCj4+Pj4+PiBjbGllbnQi LCB0aGF0IGlzIG5vdCBhdCBhbGwgY2xlYXIgdG8gbWUuIFdoYXQgaXMgYmVpbmcgYWNjZXNzZWQg YXQNCj4+Pj4+PnRoZQ0KPj4+Pj4+IGNsaWVudD8gV2hvIHdhbnRzIHRvIGFjY2Vzcz8NCj4+Pj4+ DQo+Pj4+PiBJbiB0aGUgc2NlbmFyaW8gd2UgYXJlIGFuYWx5c2luZywgdGhlcmUgaXMgdGhlIGNs aWVudCBvbiBvbmUgZW5kIG9mDQo+Pj4+PnRoZQ0KPj4+Pj4gY29udmVyc2F0aW9uIGFuZCB0aGUg UmVzb3VyY2UgU2VydmVyIG9uIHRoZSBvdGhlciBzaWRlLiBUaGUgY2xpZW50DQo+Pj4+Pm1heQ0K Pj4+Pj4gaGF2ZSBhIGRpZmZlcmVudCBvd25lciB0aGF0IHRoZSBSZXNvdXJjZSBTZXJ2ZXIuIE9u IHRoZSBSZXNvdXJjZQ0KPj4+Pj5TZXJ2ZXINCj4+Pj4+IHNpZGUsIFJlc291cmNlIE93bmVycyBt YXkgd2FudCB0byBjb250cm9sIHdoaWNoIGRhdGEgaXMgZW50ZXJpbmcgYW5kDQo+Pj4+PiBsZWF2 aW5nIHRoZWlyIHJlc291cmNlcy4gT24gdGhlIGNsaWVudCBzaWRlLCBDbGllbnQgT3duZXJzIG1h eSB3YW50DQo+Pj4+PnRvDQo+Pj4+PiBjb250cm9sIHdoaWNoIGRhdGEgaXMgZW50ZXJpbmcgYW5k IGxlYXZpbmcgdGhlaXIgZW5kcG9pbnRzLg0KPj4+Pg0KPj4+PiBJIHRoaW5rIGl0IHdvdWxkIGJl IHZlcnkgaGVscGZ1bCBpZiB5b3UgZXhwbGFpbiB3aGF0IHRoaXMgbWVhbnMgaW4NCj4+Pj50ZXJt cw0KPj4+PiBvZiB0aGUgdXNlIGNhc2VzLCBzZWUgYmVsb3cuDQo+Pj4+DQo+Pj4+DQo+Pj4+Pg0K Pj4+Pj4gVG8gcHV0IGl0IGFub3RoZXIgd2F5OiBUaGUgQ2xpZW50IE93bmVyIG1heSB3YW50IHRv IG1ha2Ugc3VyZSB0aGF0DQo+Pj4+Pm9ubHkNCj4+Pj4+IGF1dGhvcml6ZWQgZW5kcG9pbnRzIGNh biBzZW5kIGRhdGEgdG8gdGhlIGNsaWVudCBhbmQgdGhhdCB0aGUgY2xpZW50DQo+Pj4+PiBzZW5k cyBkYXRhIG9ubHkgdG8gYXV0aG9yaXplZCByZXNvdXJjZSBzZXJ2ZXJzLiBKdXN0IGFzIG9uIHRo ZQ0KPj4+Pj5SZXNvdXJjZQ0KPj4+Pj4gU2VydmVyIHNpZGUsIHRoZSBSZXNvdXJjZSBPd25lciBt YXkgd2FudCB0byBtYWtlIHN1cmUgdGhhdCBvbmx5DQo+Pj4+PiBhdXRob3JpemVkIGVuZHBvaW50 cyBjYW4gc2VuZCBkYXRhIHRvIHRoZSBSZXNvdXJjZSBTZXJ2ZXIgYW5kIHRoZQ0KPj4+Pj4gUmVz b3VyY2UgU2VydmVyIHNlbmRzIGRhdGEgb25seSB0byBhdXRob3JpemVkIGNsaWVudHMuDQo+Pj4+ Pg0KPj4+Pj4gV2UgY291bGQgY2hhbmdlIHRoZSBkZWZpbml0aW9uIG9mIENsaWVudCBPd25lciBm cm9tICJUaGUgc3ViamVjdCB3aG8NCj4+Pj4+IGNvbnRyb2xzIHRoZSBhY2Nlc3MgcGVybWlzc2lv bnMgb2YgYSBjbGllbnQuIiB0byAiVGhlIHN1YmplY3Qgd2hvDQo+Pj4+PiBkZWZpbmVzIGF1dGhv cml6YXRpb24gcG9saWNpZXMgZm9yIGEgY2xpZW50Ii4gRG9lcyB0aGF0IHNvbHZlIHlvdXINCj4+ Pj4+IHByb2JsZW0/DQo+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiBSZWdhcmRpbmcgU2Vj dGlvbiAyLjE6DQo+Pj4+Pj4NCj4+Pj4+PiAiVGhlcmUgYXJlIHZhcmlvdXMgcmVhc29ucyBmb3Ig YXNzaWduaW5nIGEgZnVuY3Rpb24gKGNsaWVudCBvcg0KPj4+Pj4+c2VydmVyKQ0KPj4+Pj4+IHRv DQo+Pj4+Pj4gYSBkZXZpY2UsIGUuZy4gd2hpY2ggZGV2aWNlIGluaXRpYXRlcyB0aGUgY29udmVy c2F0aW9uLCBob3cgZG8NCj4+Pj4+PmRldmljZXMNCj4+Pj4+PiBmaW5kIGVhY2ggb3RoZXIsIGV0 Yy4gIFRoZSBkZWZpbml0aW9uIG9mIHRoZSBmdW5jdGlvbiBvZiBhIGRldmljZQ0KPj4+Pj4+aW4g YQ0KPj4+Pj4+IGNlcnRhaW4gdXNlIGNhc2UgaXMgbm90IGluIHNjb3BlIG9mIHRoaXMgZG9jdW1l bnQuIFJlYWRlcnMgc2hvdWxkIGJlDQo+Pj4+Pj4gYXdhcmUNCj4+Pj4+PiB0aGF0IHRoZXJlIG1p Z2h0IGJlIHJlYXNvbnMgZm9yIGVhY2ggc2V0dGluZyBhbmQgdGhhdCBlbmRwb2ludHMNCj4+Pj4+ Pm1pZ2h0DQo+Pj4+Pj4gZXZlbg0KPj4+Pj4+IGhhdmUgZGlmZmVyZW50IGZ1bmN0aW9ucyBhdCBk aWZmZXJlbnQgdGltZXMuIg0KPj4+Pj4+DQo+Pj4+Pj4gSSByZW1lbWJlciB5b3UgaGF2ZSB1c2Vk IHRoaXMgcmVhc29uaW5nIHRvIGFyZ3VlIHRoYXQgaXQgaXMgbm90DQo+Pj4+Pj4gcG9zc2libGUN Cj4+Pj4+PiB0byBleHByZXNzIHdoYXQgaXMgdGhlIFJlc291cmNlIGluIGEgZ2l2ZW4gdXNlIGNh c2UuIElmIHRoaXMgaXMgdGhlDQo+Pj4+Pj4gY2FzZSwNCj4+Pj4+PiB0aGF0IHdpdGggdGhpcyB0 ZXJtaW5vbG9neSBpdCBpcyBub3QgcG9zc2libGUgdG8gc3BlY2lmeSB3aGF0IGFyZQ0KPj4+Pj4+ dGhlDQo+Pj4+Pj4gIml0ZW1zIG9mIGludGVyZXN0IiBpbiBhIGdpdmVuIHVzZSBjYXNlLCB0aGVu IEkgdGhpbmsgdGhlDQo+Pj4+Pj50ZXJtaW5vbG9neQ0KPj4+Pj4+IGlzDQo+Pj4+Pj4gbm90IHNh dGlzZmFjdG9yeS4gVGhlIHB1cnBvc2Ugb2YgdGhlIHVzZSBjYXNlIGRvY3VtZW50IGlzIHRvDQo+ Pj4+Pj5oaWdobGlnaHQNCj4+Pj4+PiB3aGF0IGlzIHRoZSBwcm9ibGVtIHdlIHNob3VsZCBzb2x2 ZS4gSWYgd2UgY2Fu4oCZdCB1c2UgdGhlIHRlcm0NCj4+Pj4+PiDigJxSZXNvdXJjZeKAnSwNCj4+ Pj4+PiB0aGVuIHdoYXQgbmVlZCBkbyB3ZSBoYXZlIGZvciDigJxSZXNvdXJjZSBTZXJ2ZXLigJ0g YW5kIOKAnFJlc291cmNlDQo+Pj4+Pj5Pd25lcuKAnT8NCj4+Pj4+PiBGdXJ0aGVybW9yZSDigJxD bGllbnTigJ0gaXMgZGVmaW5lZCBhcyB0aGUgUmVzb3VyY2UgYWNjZXNzaW5nIGVuZHBvaW50LA0K Pj4+Pj4+c28NCj4+Pj4+PiB0aGVuIG5laXRoZXIgdGhhdCBub3IgIkNsaWVudCBPd25lcuKAnSBp cyB3ZWxsIGRlZmluZWQuDQo+Pj4+Pg0KPj4+Pj4gSSBkb24ndCB0aGluayBJIHVuZGVyc3RhbmQg eW91ciByZWFzb25pbmcuIEkgY2FuJ3QgcmVtZW1iZXIgc2F5aW5nDQo+Pj4+PnRoYXQNCj4+Pj4+ IHdlIGRvbid0IGtub3cgd2hhdCB0aGUgcmVzb3VyY2UgaXMgaW4gYSBnaXZlbiB1c2UgY2FzZS4N Cj4+Pj4NCj4+Pj4gTWF5YmUgSSBtaXN1bmRlcnN0b29kLiBXZWxsIHRoZW4sIGxldOKAmXMgdXNl IGl0LiBTZWUgYmVsb3cuDQo+Pj4+DQo+Pj4+Pg0KPj4+Pj4gVGhlIHBhcmFncmFwaCBmcm9tIHNl Y3Rpb24gMi4xIGp1c3Qgc3RhdGVzIHRoYXQgaXQgaXMgbm90IGNsZWFyDQo+Pj4+PndoZXRoZXIN Cj4+Pj4+IGFuIGVuZHBvaW50IGluIGEgdXNlIGNhc2UgaXMgYSBDb0FQIGNsaWVudCBvciBhIHNl cnZlci4gSSBkb24ndCB0aGluaw0KPj4+Pj4gdGhhdCBpdCBpcyBldmVuIG5lY2Vzc2FyeSB0byBi ZSBhYmxlIHRvIGFzc2lnbiBhIGZ1bmN0aW9uIHNpbmNlIEkNCj4+Pj4+IGRpZG4ndA0KPj4+Pj4g c2VlIGFueSBldmlkZW5jZSB5ZXQgdGhhdCB0aGlzIHdvdWxkIGJlIHVzZWZ1bC4NCj4+Pj4+DQo+ Pj4+PiBBcyBJIG1lbnRpb25lZCBpbiBteSBsYXN0IGUtbWFpbCB0byBMdWR3aWcsIHdlIG5lZWQg dGhlIHRlcm1zICJjbGllbnQNCj4+Pj4+IGFuZCBzZXJ2ZXIgKG9yIHJlc291cmNlIHNlcnZlcikg dG8gZXhwcmVzcyB0aGUgcHJvYmxlbSB0aGF0IG5lZWRzIHRvDQo+Pj4+PmJlDQo+Pj4+PiBzb2x2 ZWQsIGUuZy4gVTUuNyIgKGNmDQo+Pj4+PiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvYWNlL2N1cnJlbnQvbXNnMDA5NzMuaHRtbCkuDQo+Pj4+Pg0KPj4+Pj4gV2UgY2FuIGNo YW5nZSAiUmVzb3VyY2UgU2VydmVyIiB0byAic2VydmVyIiB0byBmaXQgaXQgdG8gdGhlIENvQVAN Cj4+Pj4+IHRlcm1pbm9sb2d5LiBJZiB3ZSBkb24ndCBuZWVkIHRoZSB0ZXJtcyBDbGllbnQgT3du ZXIgYW5kIFJlc291cmNlDQo+Pj4+PiBPd25lciwNCj4+Pj4+IHdlIGNhbiByZW1vdmUgdGhlc2Ug dGVybXMgZnJvbSB0aGUgdGVybWlub2xvZ3kgc2VjdGlvbi4gSXMgdGhhdCB3aGF0DQo+Pj4+PiB5 b3UNCj4+Pj4+IGFyZSBwcm9wb3Npbmc/DQo+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gVGhlIG9ubHkg cmVtYWluaW5nIHRlcm0gaXMg4oCcUHJpbmNpcGFs4oCdLCB3aGljaCB0aGVuIGJlY29tZXMgYSBz eW5vbnltDQo+Pj4+Pj4gdG8NCj4+Pj4+PiDigJxzb21lb25lIHNldHRpbmcgYWNjZXNzIGNvbnRy b2wgcG9saWNpZXPigJ0uIElmIHRoaXMgaXMgdGhlIG9ubHkgdGhpbmcNCj4+Pj4+PiB5b3UNCj4+ Pj4+PiB3YW50IHRvIGV4cHJlc3MsIHRoZW4gSSB0aGluayB5b3Ugc2hvdWxkIHJlbW92ZSB0aGUg cmVzdCBvZiB0aGUNCj4+Pj4+PnRlcm1zLA0KPj4+Pj4+IGFzDQo+Pj4+Pj4gdGhleSBhcmUgbm90 IHVzZWQuIChSZXNvdXJjZSBTZXJ2ZXIgb3IgQ2xpZW50IGNhbiBiZSByZXBsYWNlZCBieQ0KPj4+ Pj4+4oCcc29tZQ0KPj4+Pj4+IHBvdGVudGlhbGx5IGNvbnN0cmFpbmVkIGRldmljZeKAnSBldGMu KSBCdXQgSSB0aGluayB0aGlzIGlzIG5vdCBhdCBhbGwNCj4+Pj4+PiBjbGFyaWZ5aW5nIHdoYXQg YXJlIHRoZSBhdXRob3JpemF0aW9uIHByb2JsZW1zLiBJbiBwYXJ0aWN1bGFyIHNpbmNlDQo+Pj4+ Pj5JDQo+Pj4+Pj4gaGF2ZQ0KPj4+Pj4+IGhhcmQgdGltZSB1bmRlcnN0YW5kaW5nIHdoYXQgZXhh Y3RseSBhcmUgdGhlIGFjY2VzcyBjb250cm9sIHByb2JsZW1zDQo+Pj4+Pj4gb24NCj4+Pj4+PiB0 aGUgY2xpZW50IHNpZGUsIEkgdGhpbmsgaXQgd291bGQgYmUgbW9yZSBoZWxwZnVsIHRvIGV4cGxh aW4gdGhhdA0KPj4+Pj4+aW4gYQ0KPj4+Pj4+IGdpdmVuIHVzZSBjYXNlLiBXaGF0IGFyZSB0aGUg YWNjZXNzIGNvbnRyb2wgcG9saWN5IGNvbnNpZGVyYXRpb25zIG9mDQo+Pj4+Pj4gdGhlDQo+Pj4+ Pj4gZnJ1aXQgdmVuZG9yLCB0aGUgdHJhbnNsb2FkaW5nIHBlcnNvbm5lbCBhbmQgdGhlIGNvbnRh aW5lciBvd25lcnM/DQo+Pj4+Pg0KPj4+Pj4gV2UgY2FuIHBsYXkgb3V0IEx1ZHdpZydzIHByb3Bv c2FsIGFuZCB1c2UgdGhlIG5hbWVzIG9mIHRoZSBzcGVjaWZpYw0KPj4+Pj4gYWN0b3JzIGluIHRo ZSBwcm9ibGVtIHN1bW1hcnkgc2VjdGlvbi4gSXN0IHRoYXQgd2hhdCB5b3UgYXJlDQo+Pj4+PnBy b3Bvc2luZz8NCj4+Pj4+DQo+Pj4+PiBGb3IgdGhlIGNvbnRhaW5lciBtb25pdG9yaW5nIHVzZSBj YXNlLCB0aGUgc2VjdGlvbiB3b3VsZCBsb29rIGxpa2UNCj4+Pj4+IHRoaXM6DQo+Pj4+Pg0KPj4+ Pj4gVTEuMSBQcmluY2lwYWxzIHN1Y2ggYXMgdGhlIGZydWl0IHZlbmRvciwgdGhlIHRyYW5zbG9h ZGluZyBwZXJzb25uZWwNCj4+Pj4+b3INCj4+Pj4+IHRoZSBjb250YWluZXIgb3duZXJzIHdhbnQg dG8gZGVmaW5lIGF1dGhvcml6YXRpb25zIGZvciB0aGVpcg0KPj4+Pj5yZXNvdXJjZXMNCj4+Pj4+ IGFuZCBlbmRwb2ludHMuDQo+Pj4+DQo+Pj4+IENvdWxkIHdlIHJlcGxhY2UgdGhpcyByZXF1aXJl bWVudCB3aXRoIHNvbWV0aGluZyBjb25jcmV0ZT8gQXMgaXQgaXMNCj4+Pj4gc3RhdGVkDQo+Pj4+ IG5vdyBJIGludGVycHJldCBpdCByb3VnaGx5IGFzIOKAnGV2ZXJ5Ym9keSB3YW50cyB0byBzZXQg YWNjZXNzIHBvbGljaWVzDQo+Pj4+IGZvcg0KPj4+PiB0aGVpciB0aGluZ3PigJ0uDQo+Pj4+DQo+ Pj4+IENvdWxkIHdlIHRoZW4gdXNlIHRoZSBwcm9wb3NlZCB0ZXJtaW5vbG9neSB0byBleHByZXNz Og0KPj4+PiAtIFdoYXQgYXJlIHRoZSBSZXNvdXJjZXMuDQo+Pj4+IC0gV2hpY2ggYXJlIHRoZSBD bGllbnRzIGFjY2Vzc2luZyB0aGUgUmVzb3VyY2VzLg0KPj4+PiAtIFdoYXQgYXJlIHRoZSBhY2Nl c3MgcG9saWN5IGNvbnNpZGVyYXRpb25zIG9mIHRoZSBSZXNvdXJjZSBPd25lcnMuDQo+Pj4+IEku ZS46DQo+Pj4+IFdoYXQgQ2xpZW50cyBzaG91bGQgaGF2ZSBhY2Nlc3MgdG8gd2hhdCBSZXNvdXJj ZXMuDQo+Pj4+IC0gV2hhdCBhcmUgdGhlIGFjY2VzcyBwb2xpY3kgY29uc2lkZXJhdGlvbnMgb2Yg dGhlIENsaWVudCBPd25lcnMuDQo+Pj4+DQo+Pj4+DQo+Pj4+IFRoYW5rcw0KPj4+PiBHw7ZyYW4N Cj4+Pj4NCj4+Pj4+DQo+Pj4+PiBVMS4yIFRoZSBmcnVpdCB2ZW5kb3IgcmVxdWlyZXMgdGhlIGlu dGVncml0eSBvZiB0aGUgc2Vuc29yIGRhdGEgdGhhdA0KPj4+Pj4gcGVydGFpbnMgdGhlIHN0YXRl IG9mIHRoZSBnb29kcyBmb3IgY2xpbWF0ZSBjb250cm9sIGFuZCB0byBlbnN1cmUgdGhlDQo+Pj4+ PiBxdWFsaXR5IG9mIHRoZSBtb25pdG9yZWQgcmVjb3JkaW5ncy4NCj4+Pj4+DQo+Pj4+PiBVMS4z IFRoZSBjb250YWluZXIgb3duZXIgcmVxdWlyZXMgdGhlIGludGVncml0eSBvZiB0aGUgc2Vuc29y IGRhdGENCj4+Pj4+dGhhdA0KPj4+Pj4gaXMgdXNlZCBmb3IgY2xpbWF0ZSBjb250cm9sLg0KPj4+ Pj4NCj4+Pj4+IFUxLjQgVGhlIGZydWl0IHZlbmRvciByZXF1aXJlcyB0aGUgY29uZmlkZW50aWFs aXR5IG9mIHRoZSBzZW5zb3IgZGF0YQ0KPj4+Pj4gdGhhdCBwZXJ0YWlucyB0aGUgc3RhdGUgb2Yg dGhlIGdvb2RzLg0KPj4+Pj4NCj4+Pj4+IFUxLjUgVGhlIGZydWl0IHZlbmRvciBtYXkgaGF2ZSBz ZXZlcmFsIHR5cGVzIG9mIGRhdGEgdGhhdCBtYXkgYmUNCj4+Pj4+IGNvbnRyb2xsZWQgYnkgdGhl IHNhbWUgZW5kcG9pbnQsIGUuZy4sIHNlbnNvciBkYXRhIGFuZCB0aGUgZGF0YSB1c2VkDQo+Pj4+ PiBmb3INCj4+Pj4+IGxvZ2lzdGljcy4NCj4+Pj4+DQo+Pj4+PiBVMS42IFRoZSBmcnVpdCB2ZW5k b3IgcmVxdWlyZXMgdGhlIGNvbmZpZGVudGlhbGl0eSBvZiB0aGUgZGF0YSB0aGF0DQo+Pj4+Pmlz DQo+Pj4+PiB1c2VkIHRvIGxvY2F0ZSB0aGUgZ29vZHMuDQo+Pj4+Pg0KPj4+Pj4gVTEuNyBUaGUg ZnJ1aXQgdmVuZG9yIHJlcXVpcmVzIHRoZSBpbnRlZ3JpdHkgb2YgdGhlIGRhdGEgdGhhdCBpcyB1 c2VkDQo+Pj4+PiB0bw0KPj4+Pj4gbG9jYXRlIHRoZSBnb29kcy4NCj4+Pj4+DQo+Pj4+PiBVMS44 IFRoZSB0cmFuc2xvYWRpbmcgcGVyc29ubmVsIHJlcXVpcmVzIHRoZSBpbnRlZ3JpdHkgb2YgdGhl IGRhdGENCj4+Pj4+dGhhdA0KPj4+Pj4gaXMgdXNlZCB0byBsb2NhdGUgdGhlIGdvb2RzLg0KPj4+ Pj4NCj4+Pj4+IFUxLjkgVGhlIGNvbnRhaW5lciBvd25lciBhbmQgdGhlIGZydWl0IHZlbmRvciBt YXkgbm90IGJlIHByZXNlbnQgYXQNCj4+Pj4+dGhlDQo+Pj4+PiB0aW1lIG9mIGFjY2VzcyBhbmQg Y2Fubm90IG1hbnVhbGx5IGludGVydmVuZSBpbiB0aGUgYXV0aG9yaXphdGlvbg0KPj4+Pj4gcHJv Y2Vzcy4NCj4+Pj4+DQo+Pj4+PiBVMS4xMCBUaGUgcHJpbmNpcGFscyB3YW50IHRvIGdyYW50IHRl bXBvcmFyeSBhY2Nlc3MgcGVybWlzc2lvbnMgdG8gYQ0KPj4+Pj4gcGFydHkuDQo+Pj4+Pg0KPj4+ Pj4gVTEuMTEgTWVzc2FnZXMgYmV0d2VlbiBjbGllbnQgYW5kIHJlc291cmNlIHNlcnZlciBtaWdo dCBuZWVkIHRvIGJlDQo+Pj4+PiBmb3J3YXJkZWQgb3ZlciBtdWx0aXBsZSBob3BzLg0KPj4+Pj4N Cj4+Pj4+IFUxLjEyIFRoZSBjb25zdHJhaW5lZCBkZXZpY2VzIG1pZ2h0IG5vdCBhbHdheXMgYmUg YWJsZSB0byByZWFjaCB0aGUNCj4+Pj4+IEludGVybmV0Lg0KPj4+Pj4NCj4+Pj4+IEJlc3QgcmVn YXJkcywNCj4+Pj4+IFN0ZWZmaQ0KPj4+Pg0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBBY2UgbWFpbGluZyBsaXN0DQo+Pj4+IEFjZUBp ZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZQ0K Pj4+Pg0KPj4+Pg0KPj4+DQo+Pj4gLS0NCj4+PiBTdGVmYW5pZSBHZXJkZXMJCQlUZWw6ICs0OSA0 MjEgMjE4IDYzOTA2DQo+Pj4gVFpJIFVuaXZlcnNpdMOkdCBCcmVtZW4JCUUtTWFpbDogZ2VyZGVz QHR6aS5kZQ0KPj4+IEJpYmxpb3RoZWtzdHIuIDEsIE1aSCA1MTUwDQo+Pj4gMjgzNTkgQnJlbWVu LCBHZXJtYW55DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+IEFjZSBtYWlsaW5nIGxpc3QNCj4+IEFjZUBpZXRmLm9yZw0KPj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UNCj4+DQo+Pg0KPg0KPi0tIA0KPlN0 ZWZhbmllIEdlcmRlcwkJCVRlbDogKzQ5IDQyMSAyMTggNjM5MDYNCj5UWkkgVW5pdmVyc2l0w6R0 IEJyZW1lbgkJRS1NYWlsOiBnZXJkZXNAdHppLmRlDQo+QmlibGlvdGhla3N0ci4gMSwgTVpIIDUx NTANCj4yODM1OSBCcmVtZW4sIEdlcm1hbnkNCg0K From nobody Fri Feb 13 08:33: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 716631A8777 for ; Fri, 13 Feb 2015 08:33:04 -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 9Bb0FQEwWsgZ for ; Fri, 13 Feb 2015 08:33:01 -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 67AC61A87B0 for ; Fri, 13 Feb 2015 08:32:39 -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 t1DGWXcX014372; Fri, 13 Feb 2015 17:32:33 +0100 (CET) Received: from [134.102.233.146] (eduroam-pool3-402.wlan.uni-bremen.de [134.102.233.146]) (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 3kkKxY291Dz2P72; Fri, 13 Feb 2015 17:32:33 +0100 (CET) Message-ID: <54DE2721.40304@tzi.de> Date: Fri, 13 Feb 2015 17:32:33 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= References: <20150205095841.19111.5154.idtracker@ietfa.amsl.com> <54D341F6.9040109@tzi.de> <54D8D0C5.6030101@tzi.de> <54DB8097.4030206@tzi.de> <54DCB601.3070307@tzi.de> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Fwd: I-D Action: draft-ietf-ace-usecases-02.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 16:33:04 -0000 Hi Göran, On 02/13/2015 09:23 AM, Göran Selander wrote: > Hi Steffi, > > Thanks for starting the exercise. I’ll refrain from commenting > “blindfolds” (though it is tempting) and stick to the use case, inline. > > On 2015-02-12 15:17, "Stefanie Gerdes" wrote: > >> Hi Göran, >> >> I don't see the point of this exercise. I explained the authorization >> problems several times already, e.g., two times in my last E-Mail. You >> even admitted that there are problems on both sides. I think your >> solution is to apply the same solution twice (see >> http://www.ietf.org/mail-archive/web/ace/current/msg00967.html). >> Therefore, I don't understand why you insist that we should not describe >> these problems in the use cases draft. >> >> Protecting resources on the on the resource server side is only one >> possibility for authorization and may not solve every problem. It is not >> a good idea to design the problem descriptions in the use cases draft to >> fit to a specific solution because that blindfolds us for other >> solutions that might be more suitable. >> >> To describe the authorization problem yet again: >> In the container monitoring case, the fruit vendor wants to define >> authorization policies for the temperatur sensors and the container >> owner wants to define authorization policies for the ventilation system. > > Well summarized, these are the relevant authorization problems. Replace > U1.1 with something like this and we are done with use case 1. > > >> >> One of their devices may be a client, one of them may be a resource >> server. > > Allow me to complete the exercise, using your proposed terminology. We > agreed a few mails ago that the resources are well defined > http://www.ietf.org/mail-archive/web/ace/current/msg00982.html > > (Or you formulated it "I can't remember saying that we don't know what the > resource is in a given use case.”, which I hope means that you agree that > the resources are well defined.) > > > Access control problem 1: Entity 1 wants to access a temperature. > > Clearly, the “item of interest”, which someone wants to access, is: the > temperature. > > - Resource: Temperature > - Resource Server: Temperature sensor hosting device > - Resource Owner: Fruit vendor > - Client: Device hosting Entity 1 We have two authorization problems here. The owner of the Resource Server that hosts the temperature may want to control the access to the temperature resource. The owner of the client may want to control which resources of which resource server a client is authorized and therefore safe to access (BTW, I don't know if it is important here, but in CoAP the client is an endpoint, not a device. I would expect the Resource Server to be an endpoint, too). The client must be able to answer the following question: Is it in the interest of my owner if I send a request to this resource (e.g. a get request) and receive data from this resource (the response to a get request that contains the temperature values for which the container owner needs integrity protection). The client owner may solve the authorization problem by using implicit authorization: If the Resource Server can be authenticated, it is authorized. Client Owners may also decide that they want more fine-grained authorization. For less-constrained devices that have a display and allow for user interaction, authorization can be achieved by user interaction at the time of access. In scenarios where devices communicate autonomously, the devices must be able to enforce the authorization policies of their owners themselves. > > Access control problem 2: Entity 2 wants to access a ventilation actuation > resource (say a fan setting) > > Clearly, the “item of interest”, which someone wants to access, is: the > fan setting. > > > - Resource: Fan setting > - Resource Server: Ventilation actuator hosting device > - Resource Owner: Container Owner > - Client: Entity 2 The client owner may want to decide which resource server is an authorized source for the fan setting. The client must be able to answer the following question: Is it in the interest of my owner if I send a request to this resource (e.g. a put request with a confidential sensor value) and receive data from this resource (the response to this get request). You missed to mention two other settings: 1. The temperature values are hosted by the Resource Server. The client is the fan. The client communicates directly with the Resource Server to obtain the temperature values that is than used to control the hardware of the fan. The Resource Owner, i.e., the fruit vendor, wants to make sure that sensor values are only accessed by authorized clients. The Client Owner, i.e., the container owner, wants to make sure that temperature values stem from authorized Resource Servers. 2. The fan settings are hosted by the Resource Server. The client is the temperature sensor. The client sends the temperature values directly to the Resource Server. The Resource Owner, i.e., the container owner, wants to make sure that the fan settings are only accessed by authorized clients. The Client Owner, i.e., the fruit vendor, wants to make sure that temperature values are only sent to authorized Resource Servers. > Of course an accessing entity (“client”) of one resource can be hosted in > the same device as some other resource. This doesn’t make one resource a > client of another resource. In summary, there are two distinct access > control problems, and there may be control logic wherein one resource > representation triggers an access request to another resource. I don't really understand what you are trying to express here. Do you want to state that a client can be located on the same device as a resource server? Do you want to state that one client can access several different resources? I am glad that we agree that there are at least two authorization problems here. The disagreement thus seems to be about how these problems can be solved. You seem to be determined to solve this exclusively on the Resource Server side. I don't think that the use cases document is the right place to discuss solutions. Your proposal to replace the more neutral term "Principal" by "Resource Owner" artifically restricts the solution space to the protection of resources which only considers the interests of one side of the conversation. I don't see a reason to restrict the solution space like this. If there is a way to solve the authorization problems on both sides of the conversation we should do so. The use cases should reflect the main authorization problems in constrained environments. One characteristic of these environments is that devices often communicate autonomously. This is different from the typical web scenario where authorization can be achieved by user interaction. If we fail to address the main differences between web scenarios and constrained scenarios the use cases document would not be very useful. Best regards, Steffi From nobody Mon Feb 16 00:27: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 5FEE81A875A for ; Mon, 16 Feb 2015 00:27:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPAy6gqt6ifO for ; Mon, 16 Feb 2015 00:27:07 -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 750EA1A1A67 for ; Mon, 16 Feb 2015 00:27:06 -0800 (PST) X-AuditID: c1b4fb30-f79106d000001184-e6-54e1a9d8041b Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 2E.C1.04484.8D9A1E45; Mon, 16 Feb 2015 09:27:04 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.27]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0210.002; Mon, 16 Feb 2015 09:27:04 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Stefanie Gerdes Thread-Topic: [Ace] Fwd: I-D Action: draft-ietf-ace-usecases-02.txt Thread-Index: AQHQQSw5Sfw0ELIkVUS6mg1j4TnWLZzjcYsAgATz2oCAASzlgIACBw6AgAApeICAAUdhgIABQBmAgAB374CABEAdgA== Date: Mon, 16 Feb 2015 08:27:03 +0000 Message-ID: References: <20150205095841.19111.5154.idtracker@ietfa.amsl.com> <54D341F6.9040109@tzi.de> <54D8D0C5.6030101@tzi.de> <54DB8097.4030206@tzi.de> <54DCB601.3070307@tzi.de> <54DE2721.40304@tzi.de> In-Reply-To: <54DE2721.40304@tzi.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM+Jvje6NlQ9DDJra9Sy+f+thtth48S6j A5PHkiU/mTy2vf3KHMAUxWWTkpqTWZZapG+XwJVx78dW5oJPSRVrT9Q1MK5J6GLk5JAQMJGY uPY/O4QtJnHh3nq2LkYuDiGBI4wSp3fdZ4VwFjNKXGh6xQJSxSbgIvGg4RETiC0ioCzxe/En MJtZQFFi96yzYJOEBZwklr56zApR4yxx/PtuRgg7S+LnjO9gNouAqsSW7g6wXl4BC4kdG7ex QCz7xySxYclhsCJOARWJv5PmgBUxAp33/dQaqGXiEreezGeCOFtAYsme88wQtqjEy8f/wBaL CuhJrLzexAYRV5L4seES0AIOoF5NifW79CHGWEt07lvEAnP/lO6H7BD3CEqcnPmEZQKjxCwk 22YhdM9C0j0LSfcsJN0LGFlXMYoWpxYn5aYbGemlFmUmFxfn5+nlpZZsYgRG4cEtvw12ML58 7niIUYCDUYmH94PKwxAh1sSy4srcQ4zSHCxK4rx2xodChATSE0tSs1NTC1KL4otKc1KLDzEy cXBKNTA6qa54mH/gadTSvZu+H+p+68TXvu3V4u0vjrcU1N5qV3psqvJ0/1EmiSqd2pSF/k/+ xen5dOk8u3uwdOqZ+82zg/WmNUhHvZLQt+a8lrpqRv38+J3JzitqXvyq1rk591Df7jlCWoyf CosTPNm4JjHm+x8XaXvP/uj11dzfJ2ujQ0yaNr7zeCKixFKckWioxVxUnAgAM88rjaMCAAA= Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Fwd: I-D Action: draft-ietf-ace-usecases-02.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 08:27:10 -0000 SGkgU3RlZmZpLA0KDQpUaGFua3MgZm9yIGNvbnRpbnVpbmcgdGhlIGV4ZXJjaXNlLiBXZSBkaXNh Z3JlZSBvbiBzbWFsbCB0aGluZ3MgYW5kIGJpZw0KdGhpbmdzLiBUaGUgc21hbGwgdGhpbmdzIHdl IGNvdWxkIHByb2JhYmx5IHNvcnQgb3V0LCBidXQgdGhhdCB3b24ndCBhbnl3YXkNCmhhdmUgYW4g aW1wYWN0IG9uIHRoZSB1c2UgY2FzZSBkcmFmdC4gVGhlIGJpZyB0aGluZ3Mgd2UgZGlzYWdyZWUg YWJvdXQNCndpbGwgbWF5YmUgbm90IGJlIHJlc29sdmVkIGluIHRoaXMgbWFpbCB0aHJlYWQuIExp a2UsIGZvciBleGFtcGxlLCB0aGUNCmFyZ3VtZW50cyBJIGdhdmUgaW4gbXkgcHJldmlvdXMgbWFp bCAod2hpY2ggeW91IGRpZG7igJl0IGNvbW1lbnQgb24pIHdoeSB0aGUNCmNsaWVudCAiYXV0aG9y aXphdGlvbiBwcm9ibGVtIiBhcyB5b3UgaGF2ZSBkZWZpbmVkIGlzIGFuIGFyYml0cmFyeSBjaG9p Y2UNCm91dCBvZiBhIHNldCBvZiBjbGllbnQgb3duZXIgcHJvYmxlbXMsIHdoaWNoIElNSE8gc2hv dWxkIGJlIHNlcGFyYXRlZCBvdXQNCmZyb20gdGhpcyBwcm9ibGVtIHN0YXRlbWVudC4NCg0KQnV0 LCBhcyB0aGlzIGV4ZXJjaXNlIHNob3dzLCB3ZSBhbHNvIGFncmVlIG9uIGJpZyB0aGluZ3MsIGxp a2UgYWNjZXNzDQpjb250cm9sIHRvIHJlc291cmNlcy4gSWYgSSB3ZXJlIGVkaXRvciBvZiB0aGlz IGRvY3VtZW50IGFuZCBsaXN0ZW5lZCB0bw0KdGhpcyBkaXNjdXNzaW9uLCBJIHdvdWxkIHRyeSB0 byByZXBsYWNlIHRoZSBvbmx5IHJlcXVpcmVtZW50IGZvcm11bGF0aW9uDQp3ZSBkaXNhZ3JlZSBh Ym91dCBpbiB0aGUgbW9kaWZpZWQgc2V0Og0KDQoiVTEuMSBQcmluY2lwYWxzIHN1Y2ggYXMgdGhl IGZydWl0IHZlbmRvciwgdGhlIHRyYW5zbG9hZGluZyBwZXJzb25uZWwgb3INCnRoZSBjb250YWlu ZXIgb3duZXJzIHdhbnQgdG8gZGVmaW5lIGF1dGhvcml6YXRpb25zIGZvciB0aGVpciByZXNvdXJj ZXMgYW5kDQplbmRwb2ludHMuIg0KDQp3aXRoIHR3byBuZXcgcmVxdWlyZW1lbnRzOiBvbmUgcmVx dWlyZW1lbnQgYWJvdXQgYWNjZXNzIGNvbnRyb2wgdG8NCnJlc291cmNlcyB3aGljaCB3ZSBjb3Vs ZCBhZ3JlZSBhYm91dCwgYW5kIGFub3RoZXIgcmVxdWlyZW1lbnQgYWJvdXQgY2xpZW50DQpvd25l ciBjb25jZXJucyB3aGljaCB3ZSB3aWxsIG1heWJlIG5vdCBhZ3JlZSBhYm91dCwgYW5kIHRodXMg bWFrZSBhbg0K4oCcRWRpdG9ycyBub3RlIiB0aGF0IHRoaXMgcmVxdWlyZW1lbnQgaXMgbm90IGFn cmVlZCB0byBiZSBpbiBzY29wZS4gRm9yDQpleGFtcGxlOg0KDQoiVTEuMWEgUmVzb3VyY2UgT3du ZXJzLCBzdWNoIGFzIHRoZSBmcnVpdCB2ZW5kb3IgYW5kIGNvbnRhaW5lciBvd25lcg0KcmVxdWly ZXMgdG8gZGVmaW5lIGFjY2VzcyBjb250cm9sIHBvbGljaWVzIGZvciB0aGVpciByZXNvdXJjZXMg c3VjaCBhcw0KZ29vZHMgc2Vuc29ycyBhbmQgdmVudGlsYXRpb24gYWN0dWF0b3JzLCByZXNwZWN0 aXZlbHkuDQoNClUxLjFiIENsaWVudCBPd25lcnMsIHN1Y2ggYXMgdHJhbnNsb2FkaW5nIHBlcnNv bm5lbCAuIC4gLg0KRWQuIE5vdGU6IC4gLiAuICINCg0KQW5kIHRoZW4gYW5hbG9nb3VzbHkgZm9y IHRoZSByZXF1aXJlbWVudHMgaW4gb3RoZXIgdXNlIGNhc2VzLg0KDQpJIHRoaW5rIHRoaXMgd291 bGQgYmUgbW9zdCBob25lc3QgdG8gdGhlIHJldmlld2VycyBvZiB0aGlzIGRyYWZ0LCB3aG8NCm1p Z2h0IG90aGVyd2lzZSBiZWxpZXZlIHRoYXQgdGhlIGN1cnJlbnQgc3RhdGUgb2YgdGhlIGRyYWZ0 IGlzIHRoZSBhZ3JlZWQNCnBvc2l0aW9uLg0KDQpCZXN0IFJlZ2FyZHMsDQpHw7ZyYW4NCg0KDQoN Cg0KT24gMjAxNS0wMi0xMyAxNzozMiwgIlN0ZWZhbmllIEdlcmRlcyIgPGdlcmRlc0B0emkuZGU+ IHdyb3RlOg0KDQo+SGkgR8O2cmFuLA0KPg0KPk9uIDAyLzEzLzIwMTUgMDk6MjMgQU0sIEfDtnJh biBTZWxhbmRlciB3cm90ZToNCj4+IEhpIFN0ZWZmaSwNCj4+DQo+PiBUaGFua3MgZm9yIHN0YXJ0 aW5nIHRoZSBleGVyY2lzZS4gIEnigJlsbCByZWZyYWluIGZyb20gY29tbWVudGluZw0KPj4g4oCc YmxpbmRmb2xkc+KAnSAodGhvdWdoIGl0IGlzIHRlbXB0aW5nKSBhbmQgc3RpY2sgdG8gdGhlIHVz ZSBjYXNlLCBpbmxpbmUuDQo+Pg0KPj4gT24gMjAxNS0wMi0xMiAxNToxNywgIlN0ZWZhbmllIEdl cmRlcyIgPGdlcmRlc0B0emkuZGU+IHdyb3RlOg0KPj4NCj4+PiBIaSBHw7ZyYW4sDQo+Pj4NCj4+ PiBJIGRvbid0IHNlZSB0aGUgcG9pbnQgb2YgdGhpcyBleGVyY2lzZS4gSSBleHBsYWluZWQgdGhl IGF1dGhvcml6YXRpb24NCj4+PiBwcm9ibGVtcyBzZXZlcmFsIHRpbWVzIGFscmVhZHksIGUuZy4s IHR3byB0aW1lcyBpbiBteSBsYXN0IEUtTWFpbC4gWW91DQo+Pj4gZXZlbiBhZG1pdHRlZCB0aGF0 IHRoZXJlIGFyZSBwcm9ibGVtcyBvbiBib3RoIHNpZGVzLiBJIHRoaW5rIHlvdXINCj4+PiBzb2x1 dGlvbiBpcyB0byBhcHBseSB0aGUgc2FtZSBzb2x1dGlvbiB0d2ljZSAoc2VlDQo+Pj4gaHR0cDov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2FjZS9jdXJyZW50L21zZzAwOTY3Lmh0bWwp Lg0KPj4+IFRoZXJlZm9yZSwgSSBkb24ndCB1bmRlcnN0YW5kIHdoeSB5b3UgaW5zaXN0IHRoYXQg d2Ugc2hvdWxkIG5vdA0KPj4+ZGVzY3JpYmUNCj4+PiB0aGVzZSBwcm9ibGVtcyBpbiB0aGUgdXNl IGNhc2VzIGRyYWZ0Lg0KPj4+DQo+Pj4gUHJvdGVjdGluZyByZXNvdXJjZXMgb24gdGhlIG9uIHRo ZSByZXNvdXJjZSBzZXJ2ZXIgc2lkZSBpcyBvbmx5IG9uZQ0KPj4+IHBvc3NpYmlsaXR5IGZvciBh dXRob3JpemF0aW9uIGFuZCBtYXkgbm90IHNvbHZlIGV2ZXJ5IHByb2JsZW0uIEl0IGlzDQo+Pj5u b3QNCj4+PiBhIGdvb2QgaWRlYSB0byBkZXNpZ24gdGhlIHByb2JsZW0gZGVzY3JpcHRpb25zIGlu IHRoZSB1c2UgY2FzZXMgZHJhZnQNCj4+PnRvDQo+Pj4gZml0IHRvIGEgc3BlY2lmaWMgc29sdXRp b24gYmVjYXVzZSB0aGF0IGJsaW5kZm9sZHMgdXMgZm9yIG90aGVyDQo+Pj4gc29sdXRpb25zIHRo YXQgbWlnaHQgYmUgbW9yZSBzdWl0YWJsZS4NCj4+Pg0KPj4+IFRvIGRlc2NyaWJlIHRoZSBhdXRo b3JpemF0aW9uIHByb2JsZW0geWV0IGFnYWluOg0KPj4+IEluIHRoZSBjb250YWluZXIgbW9uaXRv cmluZyBjYXNlLCB0aGUgZnJ1aXQgdmVuZG9yIHdhbnRzIHRvIGRlZmluZQ0KPj4+IGF1dGhvcml6 YXRpb24gcG9saWNpZXMgZm9yIHRoZSB0ZW1wZXJhdHVyIHNlbnNvcnMgYW5kIHRoZSBjb250YWlu ZXINCj4+PiBvd25lciB3YW50cyB0byBkZWZpbmUgYXV0aG9yaXphdGlvbiBwb2xpY2llcyBmb3Ig dGhlIHZlbnRpbGF0aW9uDQo+Pj5zeXN0ZW0uDQo+Pg0KPj4gV2VsbCBzdW1tYXJpemVkLCB0aGVz ZSBhcmUgdGhlIHJlbGV2YW50IGF1dGhvcml6YXRpb24gcHJvYmxlbXMuIFJlcGxhY2UNCj4+IFUx LjEgd2l0aCBzb21ldGhpbmcgbGlrZSB0aGlzIGFuZCB3ZSBhcmUgZG9uZSB3aXRoIHVzZSBjYXNl IDEuDQo+Pg0KPj4NCj4+Pg0KPj4+IE9uZSBvZiB0aGVpciBkZXZpY2VzIG1heSBiZSBhIGNsaWVu dCwgb25lIG9mIHRoZW0gbWF5IGJlIGEgcmVzb3VyY2UNCj4+PiBzZXJ2ZXIuDQo+Pg0KPj4gQWxs b3cgbWUgdG8gY29tcGxldGUgdGhlIGV4ZXJjaXNlLCB1c2luZyB5b3VyIHByb3Bvc2VkIHRlcm1p bm9sb2d5LiBXZQ0KPj4gYWdyZWVkIGEgZmV3IG1haWxzIGFnbyB0aGF0IHRoZSByZXNvdXJjZXMg YXJlIHdlbGwgZGVmaW5lZA0KPj4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L2FjZS9jdXJyZW50L21zZzAwOTgyLmh0bWwNCj4+DQo+PiAoT3IgeW91IGZvcm11bGF0ZWQgaXQg IkkgY2FuJ3QgcmVtZW1iZXIgc2F5aW5nIHRoYXQgd2UgZG9uJ3Qga25vdyB3aGF0DQo+PnRoZQ0K Pj4gcmVzb3VyY2UgaXMgaW4gYSBnaXZlbiB1c2UgY2FzZS7igJ0sIHdoaWNoIEkgaG9wZSBtZWFu cyB0aGF0IHlvdSBhZ3JlZQ0KPj50aGF0DQo+PiB0aGUgcmVzb3VyY2VzIGFyZSB3ZWxsIGRlZmlu ZWQuKQ0KPj4NCj4+DQo+PiBBY2Nlc3MgY29udHJvbCBwcm9ibGVtIDE6IEVudGl0eSAxIHdhbnRz IHRvIGFjY2VzcyBhIHRlbXBlcmF0dXJlLg0KPj4NCj4+IENsZWFybHksIHRoZSDigJxpdGVtIG9m IGludGVyZXN04oCdLCB3aGljaCBzb21lb25lIHdhbnRzIHRvIGFjY2VzcywgaXM6IHRoZQ0KPj4g dGVtcGVyYXR1cmUuDQo+Pg0KPj4gLSBSZXNvdXJjZTogVGVtcGVyYXR1cmUNCj4+IC0gUmVzb3Vy Y2UgU2VydmVyOiBUZW1wZXJhdHVyZSBzZW5zb3IgaG9zdGluZyBkZXZpY2UNCj4+IC0gUmVzb3Vy Y2UgT3duZXI6IEZydWl0IHZlbmRvcg0KPj4gLSBDbGllbnQ6IERldmljZSBob3N0aW5nIEVudGl0 eSAxDQo+DQo+V2UgaGF2ZSB0d28gYXV0aG9yaXphdGlvbiBwcm9ibGVtcyBoZXJlLiBUaGUgb3du ZXIgb2YgdGhlIFJlc291cmNlDQo+U2VydmVyIHRoYXQgaG9zdHMgdGhlIHRlbXBlcmF0dXJlIG1h eSB3YW50IHRvIGNvbnRyb2wgdGhlIGFjY2VzcyB0byB0aGUNCj50ZW1wZXJhdHVyZSByZXNvdXJj ZS4gVGhlIG93bmVyIG9mIHRoZSBjbGllbnQgbWF5IHdhbnQgdG8gY29udHJvbCB3aGljaA0KPnJl c291cmNlcyBvZiB3aGljaCByZXNvdXJjZSBzZXJ2ZXIgYSBjbGllbnQgaXMgYXV0aG9yaXplZCBh bmQgdGhlcmVmb3JlDQo+c2FmZSB0byBhY2Nlc3MgKEJUVywgSSBkb24ndCBrbm93IGlmIGl0IGlz IGltcG9ydGFudCBoZXJlLCBidXQgaW4gQ29BUA0KPnRoZSBjbGllbnQgaXMgYW4gZW5kcG9pbnQs IG5vdCBhIGRldmljZS4gSSB3b3VsZCBleHBlY3QgdGhlIFJlc291cmNlDQo+U2VydmVyIHRvIGJl IGFuIGVuZHBvaW50LCB0b28pLiBUaGUgY2xpZW50IG11c3QgYmUgYWJsZSB0byBhbnN3ZXIgdGhl DQo+Zm9sbG93aW5nIHF1ZXN0aW9uOiBJcyBpdCBpbiB0aGUgaW50ZXJlc3Qgb2YgbXkgb3duZXIg aWYgSSBzZW5kIGENCj5yZXF1ZXN0IHRvIHRoaXMgcmVzb3VyY2UgKGUuZy4gYSBnZXQgcmVxdWVz dCkgYW5kIHJlY2VpdmUgZGF0YSBmcm9tIHRoaXMNCj5yZXNvdXJjZSAodGhlIHJlc3BvbnNlIHRv IGEgZ2V0IHJlcXVlc3QgdGhhdCBjb250YWlucyB0aGUgdGVtcGVyYXR1cmUNCj52YWx1ZXMgZm9y IHdoaWNoIHRoZSBjb250YWluZXIgb3duZXIgbmVlZHMgaW50ZWdyaXR5IHByb3RlY3Rpb24pLg0K Pg0KPlRoZSBjbGllbnQgb3duZXIgbWF5IHNvbHZlIHRoZSBhdXRob3JpemF0aW9uIHByb2JsZW0g YnkgdXNpbmcgaW1wbGljaXQNCj5hdXRob3JpemF0aW9uOiBJZiB0aGUgUmVzb3VyY2UgU2VydmVy IGNhbiBiZSBhdXRoZW50aWNhdGVkLCBpdCBpcw0KPmF1dGhvcml6ZWQuIENsaWVudCBPd25lcnMg bWF5IGFsc28gZGVjaWRlIHRoYXQgdGhleSB3YW50IG1vcmUNCj5maW5lLWdyYWluZWQgYXV0aG9y aXphdGlvbi4NCj4NCj5Gb3IgbGVzcy1jb25zdHJhaW5lZCBkZXZpY2VzIHRoYXQgaGF2ZSBhIGRp c3BsYXkgYW5kIGFsbG93IGZvciB1c2VyDQo+aW50ZXJhY3Rpb24sIGF1dGhvcml6YXRpb24gY2Fu IGJlIGFjaGlldmVkIGJ5IHVzZXIgaW50ZXJhY3Rpb24gYXQgdGhlDQo+dGltZSBvZiBhY2Nlc3Mu IEluIHNjZW5hcmlvcyB3aGVyZSBkZXZpY2VzIGNvbW11bmljYXRlIGF1dG9ub21vdXNseSwgdGhl DQo+ZGV2aWNlcyBtdXN0IGJlIGFibGUgdG8gZW5mb3JjZSB0aGUgYXV0aG9yaXphdGlvbiBwb2xp Y2llcyBvZiB0aGVpcg0KPm93bmVycyB0aGVtc2VsdmVzLg0KPg0KPj4NCj4+IEFjY2VzcyBjb250 cm9sIHByb2JsZW0gMjogRW50aXR5IDIgd2FudHMgdG8gYWNjZXNzIGEgdmVudGlsYXRpb24NCj4+ YWN0dWF0aW9uDQo+PiByZXNvdXJjZSAoc2F5IGEgZmFuIHNldHRpbmcpDQo+Pg0KPj4gQ2xlYXJs eSwgdGhlIOKAnGl0ZW0gb2YgaW50ZXJlc3TigJ0sICB3aGljaCBzb21lb25lIHdhbnRzIHRvIGFj Y2VzcywgaXM6IHRoZQ0KPj4gZmFuIHNldHRpbmcuDQo+Pg0KPj4NCj4+IC0gUmVzb3VyY2U6IEZh biBzZXR0aW5nDQo+PiAtIFJlc291cmNlIFNlcnZlcjogVmVudGlsYXRpb24gYWN0dWF0b3IgaG9z dGluZyBkZXZpY2UNCj4+IC0gUmVzb3VyY2UgT3duZXI6IENvbnRhaW5lciBPd25lcg0KPj4gLSBD bGllbnQ6IEVudGl0eSAyDQo+DQo+VGhlIGNsaWVudCBvd25lciBtYXkgd2FudCB0byBkZWNpZGUg d2hpY2ggcmVzb3VyY2Ugc2VydmVyIGlzIGFuDQo+YXV0aG9yaXplZCBzb3VyY2UgZm9yIHRoZSBm YW4gc2V0dGluZy4gVGhlIGNsaWVudCBtdXN0IGJlIGFibGUgdG8gYW5zd2VyDQo+dGhlIGZvbGxv d2luZyBxdWVzdGlvbjogSXMgaXQgaW4gdGhlIGludGVyZXN0IG9mIG15IG93bmVyIGlmIEkgc2Vu ZCBhDQo+cmVxdWVzdCB0byB0aGlzIHJlc291cmNlIChlLmcuIGEgcHV0IHJlcXVlc3Qgd2l0aCBh IGNvbmZpZGVudGlhbCBzZW5zb3INCj52YWx1ZSkgYW5kIHJlY2VpdmUgZGF0YSBmcm9tIHRoaXMg cmVzb3VyY2UgKHRoZSByZXNwb25zZSB0byB0aGlzIGdldA0KPnJlcXVlc3QpLg0KPg0KPllvdSBt aXNzZWQgdG8gbWVudGlvbiB0d28gb3RoZXIgc2V0dGluZ3M6DQo+DQo+MS4gVGhlIHRlbXBlcmF0 dXJlIHZhbHVlcyBhcmUgaG9zdGVkIGJ5IHRoZSBSZXNvdXJjZSBTZXJ2ZXIuIFRoZSBjbGllbnQN Cj5pcyB0aGUgZmFuLiBUaGUgY2xpZW50IGNvbW11bmljYXRlcyBkaXJlY3RseSB3aXRoIHRoZSBS ZXNvdXJjZSBTZXJ2ZXIgdG8NCj5vYnRhaW4gdGhlIHRlbXBlcmF0dXJlIHZhbHVlcyB0aGF0IGlz IHRoYW4gdXNlZCB0byBjb250cm9sIHRoZSBoYXJkd2FyZQ0KPm9mIHRoZSBmYW4uIFRoZSBSZXNv dXJjZSBPd25lciwgaS5lLiwgdGhlIGZydWl0IHZlbmRvciwgd2FudHMgdG8gbWFrZQ0KPnN1cmUg dGhhdCBzZW5zb3IgdmFsdWVzIGFyZSBvbmx5IGFjY2Vzc2VkIGJ5IGF1dGhvcml6ZWQgY2xpZW50 cy4gVGhlDQo+Q2xpZW50IE93bmVyLCBpLmUuLCB0aGUgY29udGFpbmVyIG93bmVyLCB3YW50cyB0 byBtYWtlIHN1cmUgdGhhdA0KPnRlbXBlcmF0dXJlIHZhbHVlcyBzdGVtIGZyb20gYXV0aG9yaXpl ZCBSZXNvdXJjZSBTZXJ2ZXJzLg0KPg0KPjIuIFRoZSBmYW4gc2V0dGluZ3MgYXJlIGhvc3RlZCBi eSB0aGUgUmVzb3VyY2UgU2VydmVyLiBUaGUgY2xpZW50IGlzIHRoZQ0KPnRlbXBlcmF0dXJlIHNl bnNvci4gVGhlIGNsaWVudCBzZW5kcyB0aGUgdGVtcGVyYXR1cmUgdmFsdWVzIGRpcmVjdGx5IHRv DQo+dGhlIFJlc291cmNlIFNlcnZlci4gVGhlIFJlc291cmNlIE93bmVyLCBpLmUuLCB0aGUgY29u dGFpbmVyIG93bmVyLA0KPndhbnRzIHRvIG1ha2Ugc3VyZSB0aGF0IHRoZSBmYW4gc2V0dGluZ3Mg YXJlIG9ubHkgYWNjZXNzZWQgYnkgYXV0aG9yaXplZA0KPmNsaWVudHMuIFRoZSBDbGllbnQgT3du ZXIsIGkuZS4sIHRoZSBmcnVpdCB2ZW5kb3IsIHdhbnRzIHRvIG1ha2Ugc3VyZQ0KPnRoYXQgdGVt cGVyYXR1cmUgdmFsdWVzIGFyZSBvbmx5IHNlbnQgdG8gYXV0aG9yaXplZCBSZXNvdXJjZSBTZXJ2 ZXJzLg0KPg0KPg0KPj4gT2YgY291cnNlIGFuIGFjY2Vzc2luZyBlbnRpdHkgKOKAnGNsaWVudOKA nSkgb2Ygb25lIHJlc291cmNlIGNhbiBiZSBob3N0ZWQNCj4+aW4NCj4+IHRoZSBzYW1lIGRldmlj ZSBhcyBzb21lIG90aGVyIHJlc291cmNlLiBUaGlzIGRvZXNu4oCZdCBtYWtlIG9uZSByZXNvdXJj ZSBhDQo+PiBjbGllbnQgb2YgYW5vdGhlciByZXNvdXJjZS4gSW4gc3VtbWFyeSwgdGhlcmUgYXJl IHR3byBkaXN0aW5jdCBhY2Nlc3MNCj4+IGNvbnRyb2wgcHJvYmxlbXMsIGFuZCB0aGVyZSBtYXkg YmUgY29udHJvbCBsb2dpYyB3aGVyZWluIG9uZSByZXNvdXJjZQ0KPj4gcmVwcmVzZW50YXRpb24g dHJpZ2dlcnMgYW4gYWNjZXNzIHJlcXVlc3QgdG8gYW5vdGhlciByZXNvdXJjZS4NCj4NCj5JIGRv bid0IHJlYWxseSB1bmRlcnN0YW5kIHdoYXQgeW91IGFyZSB0cnlpbmcgdG8gZXhwcmVzcyBoZXJl LiBEbyB5b3UNCj53YW50IHRvIHN0YXRlIHRoYXQgYSBjbGllbnQgY2FuIGJlIGxvY2F0ZWQgb24g dGhlIHNhbWUgZGV2aWNlIGFzIGENCj5yZXNvdXJjZSBzZXJ2ZXI/IERvIHlvdSB3YW50IHRvIHN0 YXRlIHRoYXQgb25lIGNsaWVudCBjYW4gYWNjZXNzIHNldmVyYWwNCj5kaWZmZXJlbnQgcmVzb3Vy Y2VzPw0KPg0KPkkgYW0gZ2xhZCB0aGF0IHdlIGFncmVlIHRoYXQgdGhlcmUgYXJlIGF0IGxlYXN0 IHR3byBhdXRob3JpemF0aW9uDQo+cHJvYmxlbXMgaGVyZS4gVGhlIGRpc2FncmVlbWVudCB0aHVz IHNlZW1zIHRvIGJlIGFib3V0IGhvdyB0aGVzZQ0KPnByb2JsZW1zIGNhbiBiZSBzb2x2ZWQuIFlv dSBzZWVtIHRvIGJlIGRldGVybWluZWQgdG8gc29sdmUgdGhpcw0KPmV4Y2x1c2l2ZWx5IG9uIHRo ZSBSZXNvdXJjZSBTZXJ2ZXIgc2lkZS4NCj4NCj5JIGRvbid0IHRoaW5rIHRoYXQgdGhlIHVzZSBj YXNlcyBkb2N1bWVudCBpcyB0aGUgcmlnaHQgcGxhY2UgdG8gZGlzY3Vzcw0KPnNvbHV0aW9ucy4g WW91ciBwcm9wb3NhbCB0byByZXBsYWNlIHRoZSBtb3JlIG5ldXRyYWwgdGVybSAiUHJpbmNpcGFs IiBieQ0KPiJSZXNvdXJjZSBPd25lciIgYXJ0aWZpY2FsbHkgcmVzdHJpY3RzIHRoZSBzb2x1dGlv biBzcGFjZSB0byB0aGUNCj5wcm90ZWN0aW9uIG9mIHJlc291cmNlcyB3aGljaCBvbmx5IGNvbnNp ZGVycyB0aGUgaW50ZXJlc3RzIG9mIG9uZSBzaWRlDQo+b2YgdGhlIGNvbnZlcnNhdGlvbi4gSSBk b24ndCBzZWUgYSByZWFzb24gdG8gcmVzdHJpY3QgdGhlIHNvbHV0aW9uIHNwYWNlDQo+bGlrZSB0 aGlzLiBJZiB0aGVyZSBpcyBhIHdheSB0byBzb2x2ZSB0aGUgYXV0aG9yaXphdGlvbiBwcm9ibGVt cyBvbiBib3RoDQo+c2lkZXMgb2YgdGhlIGNvbnZlcnNhdGlvbiB3ZSBzaG91bGQgZG8gc28uDQo+ DQo+VGhlIHVzZSBjYXNlcyBzaG91bGQgcmVmbGVjdCB0aGUgbWFpbiBhdXRob3JpemF0aW9uIHBy b2JsZW1zIGluDQo+Y29uc3RyYWluZWQgZW52aXJvbm1lbnRzLiBPbmUgY2hhcmFjdGVyaXN0aWMg b2YgdGhlc2UgZW52aXJvbm1lbnRzIGlzDQo+dGhhdCBkZXZpY2VzIG9mdGVuIGNvbW11bmljYXRl IGF1dG9ub21vdXNseS4gVGhpcyBpcyBkaWZmZXJlbnQgZnJvbSB0aGUNCj50eXBpY2FsIHdlYiBz Y2VuYXJpbyB3aGVyZSBhdXRob3JpemF0aW9uIGNhbiBiZSBhY2hpZXZlZCBieSB1c2VyDQo+aW50 ZXJhY3Rpb24uIElmIHdlIGZhaWwgdG8gYWRkcmVzcyB0aGUgbWFpbiBkaWZmZXJlbmNlcyBiZXR3 ZWVuIHdlYg0KPnNjZW5hcmlvcyBhbmQgY29uc3RyYWluZWQgc2NlbmFyaW9zIHRoZSB1c2UgY2Fz ZXMgZG9jdW1lbnQgd291bGQgbm90IGJlDQo+dmVyeSB1c2VmdWwuDQo+DQo+QmVzdCByZWdhcmRz LA0KPlN0ZWZmaQ0KDQo= From nobody Mon Feb 16 10:03: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 1CAE31A1DBC for ; Mon, 16 Feb 2015 10:03:14 -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 thxTeC-gCdXD for ; Mon, 16 Feb 2015 10:03:10 -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 9BB7A1A1F16 for ; Mon, 16 Feb 2015 10:03:09 -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 t1GI32Wo002000; Mon, 16 Feb 2015 19:03:02 +0100 (CET) Received: from [IPv6:2001:638:708:30da:bcfa:31e2:bb65:2357] (unknown [IPv6:2001:638:708:30da:bcfa:31e2:bb65:2357]) (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 3kmCpZ1TRdz2PVX; Mon, 16 Feb 2015 19:03:02 +0100 (CET) Message-ID: <54E230D5.8090104@tzi.de> Date: Mon, 16 Feb 2015 19:03:01 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= References: <20150205095841.19111.5154.idtracker@ietfa.amsl.com> <54D341F6.9040109@tzi.de> <54D8D0C5.6030101@tzi.de> <54DB8097.4030206@tzi.de> <54DCB601.3070307@tzi.de> <54DE2721.40304@tzi.de> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Fwd: I-D Action: draft-ietf-ace-usecases-02.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 18:03:14 -0000 Hi Göran, On 02/16/2015 09:27 AM, Göran Selander wrote: > Hi Steffi, > > Thanks for continuing the exercise. We disagree on small things and big > things. The small things we could probably sort out, but that won't anyway > have an impact on the use case draft. The big things we disagree about > will maybe not be resolved in this mail thread. Like, for example, the > arguments I gave in my previous mail (which you didn’t comment on) why the > client "authorization problem" as you have defined is an arbitrary choice > out of a set of client owner problems, which IMHO should be separated out > from this problem statement. I thought that my explanation made pretty clear why this is not an arbitrary authorization problem. But I can try to make this even clearer. The charter says: "This working group therefore aims to produce a standardized solution for authentication and authorization to enable authorized access (Get, Put, Post, Delete) to resources identified by a URI and hosted on a resource server in constrained environments. As a starting point, the working group will assume that access to resources at a resource server by a client device takes place using CoAP and is protected by DTLS. Both resource server and client may be constrained." Authorized access to a resource is not only a Resource Owner problem, but also a Client Owner problem. Since both the Client Owner and the Resource Owner may want to control access to resources (see also my last e-mail: http://www.ietf.org/mail-archive/web/ace/current/msg00990.html), the charter fits to the problems of both parties. A solution might decide to address these problems or not. But we cannot reasonably say that they are not there or that they are not in scope. In M2M scenarios it will be a security problem if a client is not able to decide if accessing a resource on a resource server is authorized by its owner. Therefore, we cannot omit this problem in the use cases document. If you still think that the Client Owner problem is not in scope please explain to me why you think that it is not covered by the charter. > > But, as this exercise shows, we also agree on big things, like access > control to resources. If I were editor of this document and listened to > this discussion, I would try to replace the only requirement formulation > we disagree about in the modified set: Maybe this is part of the problem. The problems summary sections do not list requirements. They list problems. We can split up the first problem into two problems: U1.1: Resource Owners want to grant different access rights for their resources to different parties. U1.2: Client Owners want to define for their clients if and how they are allowed to access resources hosted on a Resource Server. Best regards, Steffi > > "U1.1 Principals such as the fruit vendor, the transloading personnel or > the container owners want to define authorizations for their resources and > endpoints." > > with two new requirements: one requirement about access control to > resources which we could agree about, and another requirement about client > owner concerns which we will maybe not agree about, and thus make an > “Editors note" that this requirement is not agreed to be in scope. For > example: > > "U1.1a Resource Owners, such as the fruit vendor and container owner > requires to define access control policies for their resources such as > goods sensors and ventilation actuators, respectively. > > U1.1b Client Owners, such as transloading personnel . . . > Ed. Note: . . . " > > And then analogously for the requirements in other use cases. > > I think this would be most honest to the reviewers of this draft, who > might otherwise believe that the current state of the draft is the agreed > position. > > Best Regards, > Göran > > > > > On 2015-02-13 17:32, "Stefanie Gerdes" wrote: > >> Hi Göran, >> >> On 02/13/2015 09:23 AM, Göran Selander wrote: >>> Hi Steffi, >>> >>> Thanks for starting the exercise. I’ll refrain from commenting >>> “blindfolds” (though it is tempting) and stick to the use case, inline. >>> >>> On 2015-02-12 15:17, "Stefanie Gerdes" wrote: >>> >>>> Hi Göran, >>>> >>>> I don't see the point of this exercise. I explained the authorization >>>> problems several times already, e.g., two times in my last E-Mail. You >>>> even admitted that there are problems on both sides. I think your >>>> solution is to apply the same solution twice (see >>>> http://www.ietf.org/mail-archive/web/ace/current/msg00967.html). >>>> Therefore, I don't understand why you insist that we should not >>>> describe >>>> these problems in the use cases draft. >>>> >>>> Protecting resources on the on the resource server side is only one >>>> possibility for authorization and may not solve every problem. It is >>>> not >>>> a good idea to design the problem descriptions in the use cases draft >>>> to >>>> fit to a specific solution because that blindfolds us for other >>>> solutions that might be more suitable. >>>> >>>> To describe the authorization problem yet again: >>>> In the container monitoring case, the fruit vendor wants to define >>>> authorization policies for the temperatur sensors and the container >>>> owner wants to define authorization policies for the ventilation >>>> system. >>> >>> Well summarized, these are the relevant authorization problems. Replace >>> U1.1 with something like this and we are done with use case 1. >>> >>> >>>> >>>> One of their devices may be a client, one of them may be a resource >>>> server. >>> >>> Allow me to complete the exercise, using your proposed terminology. We >>> agreed a few mails ago that the resources are well defined >>> http://www.ietf.org/mail-archive/web/ace/current/msg00982.html >>> >>> (Or you formulated it "I can't remember saying that we don't know what >>> the >>> resource is in a given use case.”, which I hope means that you agree >>> that >>> the resources are well defined.) >>> >>> >>> Access control problem 1: Entity 1 wants to access a temperature. >>> >>> Clearly, the “item of interest”, which someone wants to access, is: the >>> temperature. >>> >>> - Resource: Temperature >>> - Resource Server: Temperature sensor hosting device >>> - Resource Owner: Fruit vendor >>> - Client: Device hosting Entity 1 >> >> We have two authorization problems here. The owner of the Resource >> Server that hosts the temperature may want to control the access to the >> temperature resource. The owner of the client may want to control which >> resources of which resource server a client is authorized and therefore >> safe to access (BTW, I don't know if it is important here, but in CoAP >> the client is an endpoint, not a device. I would expect the Resource >> Server to be an endpoint, too). The client must be able to answer the >> following question: Is it in the interest of my owner if I send a >> request to this resource (e.g. a get request) and receive data from this >> resource (the response to a get request that contains the temperature >> values for which the container owner needs integrity protection). >> >> The client owner may solve the authorization problem by using implicit >> authorization: If the Resource Server can be authenticated, it is >> authorized. Client Owners may also decide that they want more >> fine-grained authorization. >> >> For less-constrained devices that have a display and allow for user >> interaction, authorization can be achieved by user interaction at the >> time of access. In scenarios where devices communicate autonomously, the >> devices must be able to enforce the authorization policies of their >> owners themselves. >> >>> >>> Access control problem 2: Entity 2 wants to access a ventilation >>> actuation >>> resource (say a fan setting) >>> >>> Clearly, the “item of interest”, which someone wants to access, is: the >>> fan setting. >>> >>> >>> - Resource: Fan setting >>> - Resource Server: Ventilation actuator hosting device >>> - Resource Owner: Container Owner >>> - Client: Entity 2 >> >> The client owner may want to decide which resource server is an >> authorized source for the fan setting. The client must be able to answer >> the following question: Is it in the interest of my owner if I send a >> request to this resource (e.g. a put request with a confidential sensor >> value) and receive data from this resource (the response to this get >> request). >> >> You missed to mention two other settings: >> >> 1. The temperature values are hosted by the Resource Server. The client >> is the fan. The client communicates directly with the Resource Server to >> obtain the temperature values that is than used to control the hardware >> of the fan. The Resource Owner, i.e., the fruit vendor, wants to make >> sure that sensor values are only accessed by authorized clients. The >> Client Owner, i.e., the container owner, wants to make sure that >> temperature values stem from authorized Resource Servers. >> >> 2. The fan settings are hosted by the Resource Server. The client is the >> temperature sensor. The client sends the temperature values directly to >> the Resource Server. The Resource Owner, i.e., the container owner, >> wants to make sure that the fan settings are only accessed by authorized >> clients. The Client Owner, i.e., the fruit vendor, wants to make sure >> that temperature values are only sent to authorized Resource Servers. >> >> >>> Of course an accessing entity (“client”) of one resource can be hosted >>> in >>> the same device as some other resource. This doesn’t make one resource a >>> client of another resource. In summary, there are two distinct access >>> control problems, and there may be control logic wherein one resource >>> representation triggers an access request to another resource. >> >> I don't really understand what you are trying to express here. Do you >> want to state that a client can be located on the same device as a >> resource server? Do you want to state that one client can access several >> different resources? >> >> I am glad that we agree that there are at least two authorization >> problems here. The disagreement thus seems to be about how these >> problems can be solved. You seem to be determined to solve this >> exclusively on the Resource Server side. >> >> I don't think that the use cases document is the right place to discuss >> solutions. Your proposal to replace the more neutral term "Principal" by >> "Resource Owner" artifically restricts the solution space to the >> protection of resources which only considers the interests of one side >> of the conversation. I don't see a reason to restrict the solution space >> like this. If there is a way to solve the authorization problems on both >> sides of the conversation we should do so. >> >> The use cases should reflect the main authorization problems in >> constrained environments. One characteristic of these environments is >> that devices often communicate autonomously. This is different from the >> typical web scenario where authorization can be achieved by user >> interaction. If we fail to address the main differences between web >> scenarios and constrained scenarios the use cases document would not be >> very useful. >> >> Best regards, >> Steffi > > > -- Stefanie Gerdes Tel: +49 421 218 63906 TZI Universität Bremen E-Mail: gerdes@tzi.de Bibliothekstr. 1, MZH 5150 28359 Bremen, Germany From nobody Mon Feb 16 11: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 05B041A1A81 for ; Mon, 16 Feb 2015 11:22:09 -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 RttBBSHF_xop for ; Mon, 16 Feb 2015 11:22:03 -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 953781A0470 for ; Mon, 16 Feb 2015 11:22:02 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-0e-54e24357836b Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 55.35.04076.75342E45; Mon, 16 Feb 2015 20:22:00 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.27]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0210.002; Mon, 16 Feb 2015 20:21:59 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Stefanie Gerdes Thread-Topic: [Ace] Fwd: I-D Action: draft-ietf-ace-usecases-02.txt Thread-Index: AQHQQSw5Sfw0ELIkVUS6mg1j4TnWLZzjcYsAgATz2oCAASzlgIACBw6AgAApeICAAUdhgIABQBmAgAB374CABEAdgIAAkCiAgAAm0wA= Date: Mon, 16 Feb 2015 19:21:59 +0000 Message-ID: References: <20150205095841.19111.5154.idtracker@ietfa.amsl.com> <54D341F6.9040109@tzi.de> <54D8D0C5.6030101@tzi.de> <54DB8097.4030206@tzi.de> <54DCB601.3070307@tzi.de> <54DE2721.40304@tzi.de> <54E230D5.8090104@tzi.de> In-Reply-To: <54E230D5.8090104@tzi.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-ID: <46B3CA9F596DA2478B05DA9D2147233C@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM+JvjW6E86MQg2s3OCy+f+thtth48S6j A5PHkiU/mTy2vf3KHMAUxWWTkpqTWZZapG+XwJXxaOlXpoIjfYwVZ2b2MTUwfuhi7GLk5JAQ MJH4eqiNFcIWk7hwbz1bFyMXh5DAEUaJqWdOs4AkhAQWM0pMeqgMYrMJuEg8aHjEBGKLCChL /F78CcxmFlCU2D3rLDuILSzgJLH01WNWiBpniePfdzNC2GUSV5dsAathEVCVONN4Amw+r4CF xOoXe5ggFh9nlvj2dgZYA6eAmkT3zxfMIDYj0HXfT62BWiYucevJfCaIqwUkluw5zwxhi0q8 fPwPbLGogJ7EyutNbBBxJYnGJU+A4hxAvZoS63fpQ4yxlph1/BkzzP1Tuh+yQ9wjKHFy5hOW CYwSs5Bsm4XQPQtJ9ywk3bOQdC9gZF3FKFqcWlycm25kpJdalJlcXJyfp5eXWrKJERiJB7f8 ttrBePC54yFGAQ5GJR7eDyoPQ4RYE8uKK3MPMUpzsCiJ89oZHwoREkhPLEnNTk0tSC2KLyrN SS0+xMjEwSnVwNgVvPDCt/ArfSpJv1zrSt5YxL9P+r9s0zbuT1t2/K4rqH9qLd1y7BTT6TAJ mQkX9ef8VIxR/PBqycQLqzIUWMMkorl6VnrzLvx1dfLGvNCn7++piR+R0VGUqLRLN2Jpl70c dpt/RsqmWbe/cl269Cc1cWuaUD7r2vS+pTYOhRveFOXt2ejr8VKJpTgj0VCLuag4EQAodOl3 pQIAAA== Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Fwd: I-D Action: draft-ietf-ace-usecases-02.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 19:22:09 -0000 SGkgU3RlZmZpLA0KDQpBYm91dCB0aGUgQ2hhcnRlcjogSWYgeW91IGFzayBhYm91dCBwZW9wbGUg d2hhdCAiYXV0aG9yaXplZCBhY2Nlc3MgdG8NCnJlc291cmNlcyBpZGVudGlmaWVkIGJ5IGEgVVJJ IGFuZCBob3N0ZWQgb24gYQ0KcmVzb3VyY2Ugc2VydmVy4oCdIG1lYW5zLCBJIHRoaW5rIG1hbnkg d291bGQgbWFrZSB0aGUgaW50ZXJwcmV0YXRpb24gaW4gVTEuMQ0KYW5kIHZlcnkgZmV3LCBpZiBh bnksIHdvdWxkIG1ha2UgdGhlIGludGVycHJldGF0aW9uIG9mIFUxLjIuIFN0YXRpbmcgdGhhdA0K dGhlIGNoYXJ0ZXIgc3VwcG9ydHMgeW91ciBjbGFpbSBpcyBJTUhPIGFuIG92ZXItaW50ZXJwcmV0 YXRpb24uDQoNClRoZXJlIGFyZSBhbHNvIG90aGVyICJwcm9ibGVtc+KAnSBvZiB0aGUgQ2xpZW50 IE93bmVycywgbGlrZSB0aGUgZXhhbXBsZXMgSQ0KbWVudGlvbmVkIGluIA0KaHR0cDovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2FjZS9jdXJyZW50L21zZzAwOTg5Lmh0bWwuIFRoZQ0K YXNzdW1wdGlvbiB0aGF0IFUxLjIgc2hvdWxkIGJlIHNvbHZlZCB3aXRoIGFjY2VzcyBjb250cm9s IHBvbGljaWVzIChpZg0KdGhhdCBpcyBpbXBsaWVkKSBpcyBhcmJpdHJhcnkuDQoNCkFib3V0IHJl cXVpcmVtZW50IHZzIHByb2JsZW06IElmIGEgY2FuZGlkYXRlIHNvbHV0aW9uIGRvZXMgbm90IHNv bHZlDQpwcm9ibGVtIFUxLjEgdGhhdCBpcyBub3QgYWNjZXB0YWJsZS4gSG93ZXZlciwgd2Ugc2hv dWxkIG5vdCBkaXNjcmltaW5hdGUNCnNvbHV0aW9ucyB3aGljaCBkb2VzIG5vdCBzb2x2ZSBVMS4y IHdpdGggYWNjZXNzIGNvbnRyb2wgcG9saWNpZXMuIElmIHdlDQpoYXZlIHRoaXMgZm9ybXVsYXRp b24sIGl0IHNob3VsZCBiZSBtYWRlIGNsZWFyIHRoYXQgVTEuMiBpcyBvcHRpb25hbC4NCg0KWW91 IHNob3VsZCBrZWVwICJzdWNoIGFzIHRoZSBmcnVpdCB2ZW5kb3IgYW5kIGNvbnRhaW5lciBvd25l cuKAnSBldGMuIGluIHRoZQ0KZm9ybXVsYXRpb24sIGp1c3QgYXMgeW91IGhhZCBpbiB5b3VyIHBy ZXZpb3VzIHZlcnNpb24uIE9uZSBtYWpvciBwb2ludA0Kd2l0aCB0aGUgcHJvYmxlbSBmb3JtdWxh dGlvbiBpcyB0byBleHBsYWluIHRoZSB0ZXJtaW5vbG9neSBpbiB0ZXJtcyBvZiB0aGUNCmFjdG9y cyBvZiB0aGUgdXNlIGNhc2UuDQoNCg0KQmVzdCBSZWdhcmRzLA0KR8O2cmFuDQoNCg0KDQpPbiAy MDE1LTAyLTE2IDE5OjAzLCAiU3RlZmFuaWUgR2VyZGVzIiA8Z2VyZGVzQHR6aS5kZT4gd3JvdGU6 DQoNCj5IaSBHw7ZyYW4sDQo+DQo+DQo+T24gMDIvMTYvMjAxNSAwOToyNyBBTSwgR8O2cmFuIFNl bGFuZGVyIHdyb3RlOg0KPj4gSGkgU3RlZmZpLA0KPj4NCj4+IFRoYW5rcyBmb3IgY29udGludWlu ZyB0aGUgZXhlcmNpc2UuIFdlIGRpc2FncmVlIG9uIHNtYWxsIHRoaW5ncyBhbmQgYmlnDQo+PiB0 aGluZ3MuIFRoZSBzbWFsbCB0aGluZ3Mgd2UgY291bGQgcHJvYmFibHkgc29ydCBvdXQsIGJ1dCB0 aGF0IHdvbid0DQo+PmFueXdheQ0KPj4gaGF2ZSBhbiBpbXBhY3Qgb24gdGhlIHVzZSBjYXNlIGRy YWZ0LiBUaGUgYmlnIHRoaW5ncyB3ZSBkaXNhZ3JlZSBhYm91dA0KPj4gd2lsbCBtYXliZSBub3Qg YmUgcmVzb2x2ZWQgaW4gdGhpcyBtYWlsIHRocmVhZC4gTGlrZSwgZm9yIGV4YW1wbGUsIHRoZQ0K Pj4gYXJndW1lbnRzIEkgZ2F2ZSBpbiBteSBwcmV2aW91cyBtYWlsICh3aGljaCB5b3UgZGlkbuKA mXQgY29tbWVudCBvbikgd2h5DQo+PnRoZQ0KPj4gY2xpZW50ICJhdXRob3JpemF0aW9uIHByb2Js ZW0iIGFzIHlvdSBoYXZlIGRlZmluZWQgaXMgYW4gYXJiaXRyYXJ5DQo+PmNob2ljZQ0KPj4gb3V0 IG9mIGEgc2V0IG9mIGNsaWVudCBvd25lciBwcm9ibGVtcywgd2hpY2ggSU1ITyBzaG91bGQgYmUg c2VwYXJhdGVkDQo+Pm91dA0KPj4gZnJvbSB0aGlzIHByb2JsZW0gc3RhdGVtZW50Lg0KPg0KPkkg dGhvdWdodCB0aGF0IG15IGV4cGxhbmF0aW9uIG1hZGUgcHJldHR5IGNsZWFyIHdoeSB0aGlzIGlz IG5vdCBhbg0KPmFyYml0cmFyeSBhdXRob3JpemF0aW9uIHByb2JsZW0uIEJ1dCBJIGNhbiB0cnkg dG8gbWFrZSB0aGlzIGV2ZW4NCj5jbGVhcmVyLiBUaGUgY2hhcnRlciBzYXlzOg0KPg0KPiJUaGlz IHdvcmtpbmcgZ3JvdXAgdGhlcmVmb3JlIGFpbXMgdG8gcHJvZHVjZSBhIHN0YW5kYXJkaXplZCBz b2x1dGlvbg0KPmZvciBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiB0byBlbmFibGUg YXV0aG9yaXplZCBhY2Nlc3MgKEdldCwNCj5QdXQsIFBvc3QsIERlbGV0ZSkgdG8gcmVzb3VyY2Vz IGlkZW50aWZpZWQgYnkgYSBVUkkgYW5kIGhvc3RlZCBvbiBhDQo+cmVzb3VyY2Ugc2VydmVyIGlu IGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy4gQXMgYSBzdGFydGluZyBwb2ludCwgdGhlDQo+d29y a2luZyBncm91cCB3aWxsIGFzc3VtZSB0aGF0IGFjY2VzcyB0byByZXNvdXJjZXMgYXQgYSByZXNv dXJjZSBzZXJ2ZXINCj5ieSBhIGNsaWVudCBkZXZpY2UgdGFrZXMgcGxhY2UgdXNpbmcgQ29BUCBh bmQgaXMgcHJvdGVjdGVkIGJ5IERUTFMuIEJvdGgNCj5yZXNvdXJjZSBzZXJ2ZXIgYW5kIGNsaWVu dCBtYXkgYmUgY29uc3RyYWluZWQuIg0KPg0KPkF1dGhvcml6ZWQgYWNjZXNzIHRvIGEgcmVzb3Vy Y2UgaXMgbm90IG9ubHkgYSBSZXNvdXJjZSBPd25lciBwcm9ibGVtLA0KPmJ1dCBhbHNvIGEgQ2xp ZW50IE93bmVyIHByb2JsZW0uIFNpbmNlIGJvdGggdGhlIENsaWVudCBPd25lciBhbmQgdGhlDQo+ UmVzb3VyY2UgT3duZXIgbWF5IHdhbnQgdG8gY29udHJvbCBhY2Nlc3MgdG8gcmVzb3VyY2VzIChz ZWUgYWxzbyBteSBsYXN0DQo+ZS1tYWlsOiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvYWNlL2N1cnJlbnQvbXNnMDA5OTAuaHRtbCksDQo+dGhlIGNoYXJ0ZXIgZml0cyB0byB0 aGUgcHJvYmxlbXMgb2YgYm90aCBwYXJ0aWVzLiBBIHNvbHV0aW9uIG1pZ2h0DQo+ZGVjaWRlIHRv IGFkZHJlc3MgdGhlc2UgcHJvYmxlbXMgb3Igbm90LiBCdXQgd2UgY2Fubm90IHJlYXNvbmFibHkg c2F5DQo+dGhhdCB0aGV5IGFyZSBub3QgdGhlcmUgb3IgdGhhdCB0aGV5IGFyZSBub3QgaW4gc2Nv cGUuIEluIE0yTSBzY2VuYXJpb3MNCj5pdCB3aWxsIGJlIGEgc2VjdXJpdHkgcHJvYmxlbSBpZiBh IGNsaWVudCBpcyBub3QgYWJsZSB0byBkZWNpZGUgaWYNCj5hY2Nlc3NpbmcgYSByZXNvdXJjZSBv biBhIHJlc291cmNlIHNlcnZlciBpcyBhdXRob3JpemVkIGJ5IGl0cyBvd25lci4NCj5UaGVyZWZv cmUsIHdlIGNhbm5vdCBvbWl0IHRoaXMgcHJvYmxlbSBpbiB0aGUgdXNlIGNhc2VzIGRvY3VtZW50 Lg0KPg0KPklmIHlvdSBzdGlsbCB0aGluayB0aGF0IHRoZSBDbGllbnQgT3duZXIgcHJvYmxlbSBp cyBub3QgaW4gc2NvcGUgcGxlYXNlDQo+ZXhwbGFpbiB0byBtZSB3aHkgeW91IHRoaW5rIHRoYXQg aXQgaXMgbm90IGNvdmVyZWQgYnkgdGhlIGNoYXJ0ZXIuDQo+DQo+Pg0KPj4gQnV0LCBhcyB0aGlz IGV4ZXJjaXNlIHNob3dzLCB3ZSBhbHNvIGFncmVlIG9uIGJpZyB0aGluZ3MsIGxpa2UgYWNjZXNz DQo+PiBjb250cm9sIHRvIHJlc291cmNlcy4gSWYgSSB3ZXJlIGVkaXRvciBvZiB0aGlzIGRvY3Vt ZW50IGFuZCBsaXN0ZW5lZCB0bw0KPj4gdGhpcyBkaXNjdXNzaW9uLCBJIHdvdWxkIHRyeSB0byBy ZXBsYWNlIHRoZSBvbmx5IHJlcXVpcmVtZW50IGZvcm11bGF0aW9uDQo+PiB3ZSBkaXNhZ3JlZSBh Ym91dCBpbiB0aGUgbW9kaWZpZWQgc2V0Og0KPg0KPk1heWJlIHRoaXMgaXMgcGFydCBvZiB0aGUg cHJvYmxlbS4gVGhlIHByb2JsZW1zIHN1bW1hcnkgc2VjdGlvbnMgZG8gbm90DQo+bGlzdCByZXF1 aXJlbWVudHMuIFRoZXkgbGlzdCBwcm9ibGVtcy4NCj4NCj5XZSBjYW4gc3BsaXQgdXAgdGhlIGZp cnN0IHByb2JsZW0gaW50byB0d28gcHJvYmxlbXM6DQo+DQo+VTEuMTogUmVzb3VyY2UgT3duZXJz IHdhbnQgdG8gZ3JhbnQgZGlmZmVyZW50IGFjY2VzcyByaWdodHMgZm9yIHRoZWlyDQo+cmVzb3Vy Y2VzIHRvIGRpZmZlcmVudCBwYXJ0aWVzLg0KPlUxLjI6IENsaWVudCBPd25lcnMgd2FudCB0byBk ZWZpbmUgZm9yIHRoZWlyIGNsaWVudHMgaWYgYW5kIGhvdyB0aGV5IGFyZQ0KPmFsbG93ZWQgdG8g YWNjZXNzIHJlc291cmNlcyBob3N0ZWQgb24gYSBSZXNvdXJjZSBTZXJ2ZXIuDQo+DQo+QmVzdCBy ZWdhcmRzLA0KPlN0ZWZmaQ0KPg0KPj4NCj4+ICJVMS4xIFByaW5jaXBhbHMgc3VjaCBhcyB0aGUg ZnJ1aXQgdmVuZG9yLCB0aGUgdHJhbnNsb2FkaW5nIHBlcnNvbm5lbCBvcg0KPj4gdGhlIGNvbnRh aW5lciBvd25lcnMgd2FudCB0byBkZWZpbmUgYXV0aG9yaXphdGlvbnMgZm9yIHRoZWlyIHJlc291 cmNlcw0KPj5hbmQNCj4+IGVuZHBvaW50cy4iDQo+Pg0KPj4gd2l0aCB0d28gbmV3IHJlcXVpcmVt ZW50czogb25lIHJlcXVpcmVtZW50IGFib3V0IGFjY2VzcyBjb250cm9sIHRvDQo+PiByZXNvdXJj ZXMgd2hpY2ggd2UgY291bGQgYWdyZWUgYWJvdXQsIGFuZCBhbm90aGVyIHJlcXVpcmVtZW50IGFi b3V0DQo+PmNsaWVudA0KPj4gb3duZXIgY29uY2VybnMgd2hpY2ggd2Ugd2lsbCBtYXliZSBub3Qg YWdyZWUgYWJvdXQsIGFuZCB0aHVzIG1ha2UgYW4NCj4+IOKAnEVkaXRvcnMgbm90ZSIgdGhhdCB0 aGlzIHJlcXVpcmVtZW50IGlzIG5vdCBhZ3JlZWQgdG8gYmUgaW4gc2NvcGUuIEZvcg0KPj4gZXhh bXBsZToNCj4+DQo+PiAiVTEuMWEgUmVzb3VyY2UgT3duZXJzLCBzdWNoIGFzIHRoZSBmcnVpdCB2 ZW5kb3IgYW5kIGNvbnRhaW5lciBvd25lcg0KPj4gcmVxdWlyZXMgdG8gZGVmaW5lIGFjY2VzcyBj b250cm9sIHBvbGljaWVzIGZvciB0aGVpciByZXNvdXJjZXMgc3VjaCBhcw0KPj4gZ29vZHMgc2Vu c29ycyBhbmQgdmVudGlsYXRpb24gYWN0dWF0b3JzLCByZXNwZWN0aXZlbHkuDQo+Pg0KPj4gVTEu MWIgQ2xpZW50IE93bmVycywgc3VjaCBhcyB0cmFuc2xvYWRpbmcgcGVyc29ubmVsIC4gLiAuDQo+ PiBFZC4gTm90ZTogLiAuIC4gIg0KPj4NCj4+IEFuZCB0aGVuIGFuYWxvZ291c2x5IGZvciB0aGUg cmVxdWlyZW1lbnRzIGluIG90aGVyIHVzZSBjYXNlcy4NCj4+DQo+PiBJIHRoaW5rIHRoaXMgd291 bGQgYmUgbW9zdCBob25lc3QgdG8gdGhlIHJldmlld2VycyBvZiB0aGlzIGRyYWZ0LCB3aG8NCj4+ IG1pZ2h0IG90aGVyd2lzZSBiZWxpZXZlIHRoYXQgdGhlIGN1cnJlbnQgc3RhdGUgb2YgdGhlIGRy YWZ0IGlzIHRoZQ0KPj5hZ3JlZWQNCj4+IHBvc2l0aW9uLg0KPj4NCj4+IEJlc3QgUmVnYXJkcywN Cj4+IEfDtnJhbg0KPj4NCj4+DQo+Pg0KPj4NCj4+IE9uIDIwMTUtMDItMTMgMTc6MzIsICJTdGVm YW5pZSBHZXJkZXMiIDxnZXJkZXNAdHppLmRlPiB3cm90ZToNCj4+DQo+Pj4gSGkgR8O2cmFuLA0K Pj4+DQo+Pj4gT24gMDIvMTMvMjAxNSAwOToyMyBBTSwgR8O2cmFuIFNlbGFuZGVyIHdyb3RlOg0K Pj4+PiBIaSBTdGVmZmksDQo+Pj4+DQo+Pj4+IFRoYW5rcyBmb3Igc3RhcnRpbmcgdGhlIGV4ZXJj aXNlLiAgSeKAmWxsIHJlZnJhaW4gZnJvbSBjb21tZW50aW5nDQo+Pj4+IOKAnGJsaW5kZm9sZHPi gJ0gKHRob3VnaCBpdCBpcyB0ZW1wdGluZykgYW5kIHN0aWNrIHRvIHRoZSB1c2UgY2FzZSwNCj4+ Pj5pbmxpbmUuDQo+Pj4+DQo+Pj4+IE9uIDIwMTUtMDItMTIgMTU6MTcsICJTdGVmYW5pZSBHZXJk ZXMiIDxnZXJkZXNAdHppLmRlPiB3cm90ZToNCj4+Pj4NCj4+Pj4+IEhpIEfDtnJhbiwNCj4+Pj4+ DQo+Pj4+PiBJIGRvbid0IHNlZSB0aGUgcG9pbnQgb2YgdGhpcyBleGVyY2lzZS4gSSBleHBsYWlu ZWQgdGhlIGF1dGhvcml6YXRpb24NCj4+Pj4+IHByb2JsZW1zIHNldmVyYWwgdGltZXMgYWxyZWFk eSwgZS5nLiwgdHdvIHRpbWVzIGluIG15IGxhc3QgRS1NYWlsLg0KPj4+Pj5Zb3UNCj4+Pj4+IGV2 ZW4gYWRtaXR0ZWQgdGhhdCB0aGVyZSBhcmUgcHJvYmxlbXMgb24gYm90aCBzaWRlcy4gSSB0aGlu ayB5b3VyDQo+Pj4+PiBzb2x1dGlvbiBpcyB0byBhcHBseSB0aGUgc2FtZSBzb2x1dGlvbiB0d2lj ZSAoc2VlDQo+Pj4+PiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvYWNlL2N1 cnJlbnQvbXNnMDA5NjcuaHRtbCkuDQo+Pj4+PiBUaGVyZWZvcmUsIEkgZG9uJ3QgdW5kZXJzdGFu ZCB3aHkgeW91IGluc2lzdCB0aGF0IHdlIHNob3VsZCBub3QNCj4+Pj4+IGRlc2NyaWJlDQo+Pj4+ PiB0aGVzZSBwcm9ibGVtcyBpbiB0aGUgdXNlIGNhc2VzIGRyYWZ0Lg0KPj4+Pj4NCj4+Pj4+IFBy b3RlY3RpbmcgcmVzb3VyY2VzIG9uIHRoZSBvbiB0aGUgcmVzb3VyY2Ugc2VydmVyIHNpZGUgaXMg b25seSBvbmUNCj4+Pj4+IHBvc3NpYmlsaXR5IGZvciBhdXRob3JpemF0aW9uIGFuZCBtYXkgbm90 IHNvbHZlIGV2ZXJ5IHByb2JsZW0uIEl0IGlzDQo+Pj4+PiBub3QNCj4+Pj4+IGEgZ29vZCBpZGVh IHRvIGRlc2lnbiB0aGUgcHJvYmxlbSBkZXNjcmlwdGlvbnMgaW4gdGhlIHVzZSBjYXNlcyBkcmFm dA0KPj4+Pj4gdG8NCj4+Pj4+IGZpdCB0byBhIHNwZWNpZmljIHNvbHV0aW9uIGJlY2F1c2UgdGhh dCBibGluZGZvbGRzIHVzIGZvciBvdGhlcg0KPj4+Pj4gc29sdXRpb25zIHRoYXQgbWlnaHQgYmUg bW9yZSBzdWl0YWJsZS4NCj4+Pj4+DQo+Pj4+PiBUbyBkZXNjcmliZSB0aGUgYXV0aG9yaXphdGlv biBwcm9ibGVtIHlldCBhZ2FpbjoNCj4+Pj4+IEluIHRoZSBjb250YWluZXIgbW9uaXRvcmluZyBj YXNlLCB0aGUgZnJ1aXQgdmVuZG9yIHdhbnRzIHRvIGRlZmluZQ0KPj4+Pj4gYXV0aG9yaXphdGlv biBwb2xpY2llcyBmb3IgdGhlIHRlbXBlcmF0dXIgc2Vuc29ycyBhbmQgdGhlIGNvbnRhaW5lcg0K Pj4+Pj4gb3duZXIgd2FudHMgdG8gZGVmaW5lIGF1dGhvcml6YXRpb24gcG9saWNpZXMgZm9yIHRo ZSB2ZW50aWxhdGlvbg0KPj4+Pj4gc3lzdGVtLg0KPj4+Pg0KPj4+PiBXZWxsIHN1bW1hcml6ZWQs IHRoZXNlIGFyZSB0aGUgcmVsZXZhbnQgYXV0aG9yaXphdGlvbiBwcm9ibGVtcy4NCj4+Pj5SZXBs YWNlDQo+Pj4+IFUxLjEgd2l0aCBzb21ldGhpbmcgbGlrZSB0aGlzIGFuZCB3ZSBhcmUgZG9uZSB3 aXRoIHVzZSBjYXNlIDEuDQo+Pj4+DQo+Pj4+DQo+Pj4+Pg0KPj4+Pj4gT25lIG9mIHRoZWlyIGRl dmljZXMgbWF5IGJlIGEgY2xpZW50LCBvbmUgb2YgdGhlbSBtYXkgYmUgYSByZXNvdXJjZQ0KPj4+ Pj4gc2VydmVyLg0KPj4+Pg0KPj4+PiBBbGxvdyBtZSB0byBjb21wbGV0ZSB0aGUgZXhlcmNpc2Us IHVzaW5nIHlvdXIgcHJvcG9zZWQgdGVybWlub2xvZ3kuIFdlDQo+Pj4+IGFncmVlZCBhIGZldyBt YWlscyBhZ28gdGhhdCB0aGUgcmVzb3VyY2VzIGFyZSB3ZWxsIGRlZmluZWQNCj4+Pj4gaHR0cDov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2FjZS9jdXJyZW50L21zZzAwOTgyLmh0bWwN Cj4+Pj4NCj4+Pj4gKE9yIHlvdSBmb3JtdWxhdGVkIGl0ICJJIGNhbid0IHJlbWVtYmVyIHNheWlu ZyB0aGF0IHdlIGRvbid0IGtub3cgd2hhdA0KPj4+PiB0aGUNCj4+Pj4gcmVzb3VyY2UgaXMgaW4g YSBnaXZlbiB1c2UgY2FzZS7igJ0sIHdoaWNoIEkgaG9wZSBtZWFucyB0aGF0IHlvdSBhZ3JlZQ0K Pj4+PiB0aGF0DQo+Pj4+IHRoZSByZXNvdXJjZXMgYXJlIHdlbGwgZGVmaW5lZC4pDQo+Pj4+DQo+ Pj4+DQo+Pj4+IEFjY2VzcyBjb250cm9sIHByb2JsZW0gMTogRW50aXR5IDEgd2FudHMgdG8gYWNj ZXNzIGEgdGVtcGVyYXR1cmUuDQo+Pj4+DQo+Pj4+IENsZWFybHksIHRoZSDigJxpdGVtIG9mIGlu dGVyZXN04oCdLCB3aGljaCBzb21lb25lIHdhbnRzIHRvIGFjY2VzcywgaXM6DQo+Pj4+dGhlDQo+ Pj4+IHRlbXBlcmF0dXJlLg0KPj4+Pg0KPj4+PiAtIFJlc291cmNlOiBUZW1wZXJhdHVyZQ0KPj4+ PiAtIFJlc291cmNlIFNlcnZlcjogVGVtcGVyYXR1cmUgc2Vuc29yIGhvc3RpbmcgZGV2aWNlDQo+ Pj4+IC0gUmVzb3VyY2UgT3duZXI6IEZydWl0IHZlbmRvcg0KPj4+PiAtIENsaWVudDogRGV2aWNl IGhvc3RpbmcgRW50aXR5IDENCj4+Pg0KPj4+IFdlIGhhdmUgdHdvIGF1dGhvcml6YXRpb24gcHJv YmxlbXMgaGVyZS4gVGhlIG93bmVyIG9mIHRoZSBSZXNvdXJjZQ0KPj4+IFNlcnZlciB0aGF0IGhv c3RzIHRoZSB0ZW1wZXJhdHVyZSBtYXkgd2FudCB0byBjb250cm9sIHRoZSBhY2Nlc3MgdG8gdGhl DQo+Pj4gdGVtcGVyYXR1cmUgcmVzb3VyY2UuIFRoZSBvd25lciBvZiB0aGUgY2xpZW50IG1heSB3 YW50IHRvIGNvbnRyb2wgd2hpY2gNCj4+PiByZXNvdXJjZXMgb2Ygd2hpY2ggcmVzb3VyY2Ugc2Vy dmVyIGEgY2xpZW50IGlzIGF1dGhvcml6ZWQgYW5kIHRoZXJlZm9yZQ0KPj4+IHNhZmUgdG8gYWNj ZXNzIChCVFcsIEkgZG9uJ3Qga25vdyBpZiBpdCBpcyBpbXBvcnRhbnQgaGVyZSwgYnV0IGluIENv QVANCj4+PiB0aGUgY2xpZW50IGlzIGFuIGVuZHBvaW50LCBub3QgYSBkZXZpY2UuIEkgd291bGQg ZXhwZWN0IHRoZSBSZXNvdXJjZQ0KPj4+IFNlcnZlciB0byBiZSBhbiBlbmRwb2ludCwgdG9vKS4g VGhlIGNsaWVudCBtdXN0IGJlIGFibGUgdG8gYW5zd2VyIHRoZQ0KPj4+IGZvbGxvd2luZyBxdWVz dGlvbjogSXMgaXQgaW4gdGhlIGludGVyZXN0IG9mIG15IG93bmVyIGlmIEkgc2VuZCBhDQo+Pj4g cmVxdWVzdCB0byB0aGlzIHJlc291cmNlIChlLmcuIGEgZ2V0IHJlcXVlc3QpIGFuZCByZWNlaXZl IGRhdGEgZnJvbQ0KPj4+dGhpcw0KPj4+IHJlc291cmNlICh0aGUgcmVzcG9uc2UgdG8gYSBnZXQg cmVxdWVzdCB0aGF0IGNvbnRhaW5zIHRoZSB0ZW1wZXJhdHVyZQ0KPj4+IHZhbHVlcyBmb3Igd2hp Y2ggdGhlIGNvbnRhaW5lciBvd25lciBuZWVkcyBpbnRlZ3JpdHkgcHJvdGVjdGlvbikuDQo+Pj4N Cj4+PiBUaGUgY2xpZW50IG93bmVyIG1heSBzb2x2ZSB0aGUgYXV0aG9yaXphdGlvbiBwcm9ibGVt IGJ5IHVzaW5nIGltcGxpY2l0DQo+Pj4gYXV0aG9yaXphdGlvbjogSWYgdGhlIFJlc291cmNlIFNl cnZlciBjYW4gYmUgYXV0aGVudGljYXRlZCwgaXQgaXMNCj4+PiBhdXRob3JpemVkLiBDbGllbnQg T3duZXJzIG1heSBhbHNvIGRlY2lkZSB0aGF0IHRoZXkgd2FudCBtb3JlDQo+Pj4gZmluZS1ncmFp bmVkIGF1dGhvcml6YXRpb24uDQo+Pj4NCj4+PiBGb3IgbGVzcy1jb25zdHJhaW5lZCBkZXZpY2Vz IHRoYXQgaGF2ZSBhIGRpc3BsYXkgYW5kIGFsbG93IGZvciB1c2VyDQo+Pj4gaW50ZXJhY3Rpb24s IGF1dGhvcml6YXRpb24gY2FuIGJlIGFjaGlldmVkIGJ5IHVzZXIgaW50ZXJhY3Rpb24gYXQgdGhl DQo+Pj4gdGltZSBvZiBhY2Nlc3MuIEluIHNjZW5hcmlvcyB3aGVyZSBkZXZpY2VzIGNvbW11bmlj YXRlIGF1dG9ub21vdXNseSwNCj4+PnRoZQ0KPj4+IGRldmljZXMgbXVzdCBiZSBhYmxlIHRvIGVu Zm9yY2UgdGhlIGF1dGhvcml6YXRpb24gcG9saWNpZXMgb2YgdGhlaXINCj4+PiBvd25lcnMgdGhl bXNlbHZlcy4NCj4+Pg0KPj4+Pg0KPj4+PiBBY2Nlc3MgY29udHJvbCBwcm9ibGVtIDI6IEVudGl0 eSAyIHdhbnRzIHRvIGFjY2VzcyBhIHZlbnRpbGF0aW9uDQo+Pj4+IGFjdHVhdGlvbg0KPj4+PiBy ZXNvdXJjZSAoc2F5IGEgZmFuIHNldHRpbmcpDQo+Pj4+DQo+Pj4+IENsZWFybHksIHRoZSDigJxp dGVtIG9mIGludGVyZXN04oCdLCAgd2hpY2ggc29tZW9uZSB3YW50cyB0byBhY2Nlc3MsIGlzOg0K Pj4+PnRoZQ0KPj4+PiBmYW4gc2V0dGluZy4NCj4+Pj4NCj4+Pj4NCj4+Pj4gLSBSZXNvdXJjZTog RmFuIHNldHRpbmcNCj4+Pj4gLSBSZXNvdXJjZSBTZXJ2ZXI6IFZlbnRpbGF0aW9uIGFjdHVhdG9y IGhvc3RpbmcgZGV2aWNlDQo+Pj4+IC0gUmVzb3VyY2UgT3duZXI6IENvbnRhaW5lciBPd25lcg0K Pj4+PiAtIENsaWVudDogRW50aXR5IDINCj4+Pg0KPj4+IFRoZSBjbGllbnQgb3duZXIgbWF5IHdh bnQgdG8gZGVjaWRlIHdoaWNoIHJlc291cmNlIHNlcnZlciBpcyBhbg0KPj4+IGF1dGhvcml6ZWQg c291cmNlIGZvciB0aGUgZmFuIHNldHRpbmcuIFRoZSBjbGllbnQgbXVzdCBiZSBhYmxlIHRvDQo+ Pj5hbnN3ZXINCj4+PiB0aGUgZm9sbG93aW5nIHF1ZXN0aW9uOiBJcyBpdCBpbiB0aGUgaW50ZXJl c3Qgb2YgbXkgb3duZXIgaWYgSSBzZW5kIGENCj4+PiByZXF1ZXN0IHRvIHRoaXMgcmVzb3VyY2Ug KGUuZy4gYSBwdXQgcmVxdWVzdCB3aXRoIGEgY29uZmlkZW50aWFsIHNlbnNvcg0KPj4+IHZhbHVl KSBhbmQgcmVjZWl2ZSBkYXRhIGZyb20gdGhpcyByZXNvdXJjZSAodGhlIHJlc3BvbnNlIHRvIHRo aXMgZ2V0DQo+Pj4gcmVxdWVzdCkuDQo+Pj4NCj4+PiBZb3UgbWlzc2VkIHRvIG1lbnRpb24gdHdv IG90aGVyIHNldHRpbmdzOg0KPj4+DQo+Pj4gMS4gVGhlIHRlbXBlcmF0dXJlIHZhbHVlcyBhcmUg aG9zdGVkIGJ5IHRoZSBSZXNvdXJjZSBTZXJ2ZXIuIFRoZSBjbGllbnQNCj4+PiBpcyB0aGUgZmFu LiBUaGUgY2xpZW50IGNvbW11bmljYXRlcyBkaXJlY3RseSB3aXRoIHRoZSBSZXNvdXJjZSBTZXJ2 ZXINCj4+PnRvDQo+Pj4gb2J0YWluIHRoZSB0ZW1wZXJhdHVyZSB2YWx1ZXMgdGhhdCBpcyB0aGFu IHVzZWQgdG8gY29udHJvbCB0aGUgaGFyZHdhcmUNCj4+PiBvZiB0aGUgZmFuLiBUaGUgUmVzb3Vy Y2UgT3duZXIsIGkuZS4sIHRoZSBmcnVpdCB2ZW5kb3IsIHdhbnRzIHRvIG1ha2UNCj4+PiBzdXJl IHRoYXQgc2Vuc29yIHZhbHVlcyBhcmUgb25seSBhY2Nlc3NlZCBieSBhdXRob3JpemVkIGNsaWVu dHMuIFRoZQ0KPj4+IENsaWVudCBPd25lciwgaS5lLiwgdGhlIGNvbnRhaW5lciBvd25lciwgd2Fu dHMgdG8gbWFrZSBzdXJlIHRoYXQNCj4+PiB0ZW1wZXJhdHVyZSB2YWx1ZXMgc3RlbSBmcm9tIGF1 dGhvcml6ZWQgUmVzb3VyY2UgU2VydmVycy4NCj4+Pg0KPj4+IDIuIFRoZSBmYW4gc2V0dGluZ3Mg YXJlIGhvc3RlZCBieSB0aGUgUmVzb3VyY2UgU2VydmVyLiBUaGUgY2xpZW50IGlzDQo+Pj50aGUN Cj4+PiB0ZW1wZXJhdHVyZSBzZW5zb3IuIFRoZSBjbGllbnQgc2VuZHMgdGhlIHRlbXBlcmF0dXJl IHZhbHVlcyBkaXJlY3RseSB0bw0KPj4+IHRoZSBSZXNvdXJjZSBTZXJ2ZXIuIFRoZSBSZXNvdXJj ZSBPd25lciwgaS5lLiwgdGhlIGNvbnRhaW5lciBvd25lciwNCj4+PiB3YW50cyB0byBtYWtlIHN1 cmUgdGhhdCB0aGUgZmFuIHNldHRpbmdzIGFyZSBvbmx5IGFjY2Vzc2VkIGJ5DQo+Pj5hdXRob3Jp emVkDQo+Pj4gY2xpZW50cy4gVGhlIENsaWVudCBPd25lciwgaS5lLiwgdGhlIGZydWl0IHZlbmRv ciwgd2FudHMgdG8gbWFrZSBzdXJlDQo+Pj4gdGhhdCB0ZW1wZXJhdHVyZSB2YWx1ZXMgYXJlIG9u bHkgc2VudCB0byBhdXRob3JpemVkIFJlc291cmNlIFNlcnZlcnMuDQo+Pj4NCj4+Pg0KPj4+PiBP ZiBjb3Vyc2UgYW4gYWNjZXNzaW5nIGVudGl0eSAo4oCcY2xpZW504oCdKSBvZiBvbmUgcmVzb3Vy Y2UgY2FuIGJlIGhvc3RlZA0KPj4+PiBpbg0KPj4+PiB0aGUgc2FtZSBkZXZpY2UgYXMgc29tZSBv dGhlciByZXNvdXJjZS4gVGhpcyBkb2VzbuKAmXQgbWFrZSBvbmUNCj4+Pj5yZXNvdXJjZSBhDQo+ Pj4+IGNsaWVudCBvZiBhbm90aGVyIHJlc291cmNlLiBJbiBzdW1tYXJ5LCB0aGVyZSBhcmUgdHdv IGRpc3RpbmN0IGFjY2Vzcw0KPj4+PiBjb250cm9sIHByb2JsZW1zLCBhbmQgdGhlcmUgbWF5IGJl IGNvbnRyb2wgbG9naWMgd2hlcmVpbiBvbmUgcmVzb3VyY2UNCj4+Pj4gcmVwcmVzZW50YXRpb24g dHJpZ2dlcnMgYW4gYWNjZXNzIHJlcXVlc3QgdG8gYW5vdGhlciByZXNvdXJjZS4NCj4+Pg0KPj4+ IEkgZG9uJ3QgcmVhbGx5IHVuZGVyc3RhbmQgd2hhdCB5b3UgYXJlIHRyeWluZyB0byBleHByZXNz IGhlcmUuIERvIHlvdQ0KPj4+IHdhbnQgdG8gc3RhdGUgdGhhdCBhIGNsaWVudCBjYW4gYmUgbG9j YXRlZCBvbiB0aGUgc2FtZSBkZXZpY2UgYXMgYQ0KPj4+IHJlc291cmNlIHNlcnZlcj8gRG8geW91 IHdhbnQgdG8gc3RhdGUgdGhhdCBvbmUgY2xpZW50IGNhbiBhY2Nlc3MNCj4+PnNldmVyYWwNCj4+ PiBkaWZmZXJlbnQgcmVzb3VyY2VzPw0KPj4+DQo+Pj4gSSBhbSBnbGFkIHRoYXQgd2UgYWdyZWUg dGhhdCB0aGVyZSBhcmUgYXQgbGVhc3QgdHdvIGF1dGhvcml6YXRpb24NCj4+PiBwcm9ibGVtcyBo ZXJlLiBUaGUgZGlzYWdyZWVtZW50IHRodXMgc2VlbXMgdG8gYmUgYWJvdXQgaG93IHRoZXNlDQo+ Pj4gcHJvYmxlbXMgY2FuIGJlIHNvbHZlZC4gWW91IHNlZW0gdG8gYmUgZGV0ZXJtaW5lZCB0byBz b2x2ZSB0aGlzDQo+Pj4gZXhjbHVzaXZlbHkgb24gdGhlIFJlc291cmNlIFNlcnZlciBzaWRlLg0K Pj4+DQo+Pj4gSSBkb24ndCB0aGluayB0aGF0IHRoZSB1c2UgY2FzZXMgZG9jdW1lbnQgaXMgdGhl IHJpZ2h0IHBsYWNlIHRvIGRpc2N1c3MNCj4+PiBzb2x1dGlvbnMuIFlvdXIgcHJvcG9zYWwgdG8g cmVwbGFjZSB0aGUgbW9yZSBuZXV0cmFsIHRlcm0gIlByaW5jaXBhbCINCj4+PmJ5DQo+Pj4gIlJl c291cmNlIE93bmVyIiBhcnRpZmljYWxseSByZXN0cmljdHMgdGhlIHNvbHV0aW9uIHNwYWNlIHRv IHRoZQ0KPj4+IHByb3RlY3Rpb24gb2YgcmVzb3VyY2VzIHdoaWNoIG9ubHkgY29uc2lkZXJzIHRo ZSBpbnRlcmVzdHMgb2Ygb25lIHNpZGUNCj4+PiBvZiB0aGUgY29udmVyc2F0aW9uLiBJIGRvbid0 IHNlZSBhIHJlYXNvbiB0byByZXN0cmljdCB0aGUgc29sdXRpb24NCj4+PnNwYWNlDQo+Pj4gbGlr ZSB0aGlzLiBJZiB0aGVyZSBpcyBhIHdheSB0byBzb2x2ZSB0aGUgYXV0aG9yaXphdGlvbiBwcm9i bGVtcyBvbg0KPj4+Ym90aA0KPj4+IHNpZGVzIG9mIHRoZSBjb252ZXJzYXRpb24gd2Ugc2hvdWxk IGRvIHNvLg0KPj4+DQo+Pj4gVGhlIHVzZSBjYXNlcyBzaG91bGQgcmVmbGVjdCB0aGUgbWFpbiBh dXRob3JpemF0aW9uIHByb2JsZW1zIGluDQo+Pj4gY29uc3RyYWluZWQgZW52aXJvbm1lbnRzLiBP bmUgY2hhcmFjdGVyaXN0aWMgb2YgdGhlc2UgZW52aXJvbm1lbnRzIGlzDQo+Pj4gdGhhdCBkZXZp Y2VzIG9mdGVuIGNvbW11bmljYXRlIGF1dG9ub21vdXNseS4gVGhpcyBpcyBkaWZmZXJlbnQgZnJv bSB0aGUNCj4+PiB0eXBpY2FsIHdlYiBzY2VuYXJpbyB3aGVyZSBhdXRob3JpemF0aW9uIGNhbiBi ZSBhY2hpZXZlZCBieSB1c2VyDQo+Pj4gaW50ZXJhY3Rpb24uIElmIHdlIGZhaWwgdG8gYWRkcmVz cyB0aGUgbWFpbiBkaWZmZXJlbmNlcyBiZXR3ZWVuIHdlYg0KPj4+IHNjZW5hcmlvcyBhbmQgY29u c3RyYWluZWQgc2NlbmFyaW9zIHRoZSB1c2UgY2FzZXMgZG9jdW1lbnQgd291bGQgbm90IGJlDQo+ Pj4gdmVyeSB1c2VmdWwuDQo+Pj4NCj4+PiBCZXN0IHJlZ2FyZHMsDQo+Pj4gU3RlZmZpDQo+Pg0K Pj4NCj4+DQo+DQo+LS0gDQo+U3RlZmFuaWUgR2VyZGVzCQkJVGVsOiArNDkgNDIxIDIxOCA2Mzkw Ng0KPlRaSSBVbml2ZXJzaXTDpHQgQnJlbWVuCQlFLU1haWw6IGdlcmRlc0B0emkuZGUNCj5CaWJs aW90aGVrc3RyLiAxLCBNWkggNTE1MA0KPjI4MzU5IEJyZW1lbiwgR2VybWFueQ0KDQo= From nobody Mon Feb 16 12:29: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 B49AA1A8892 for ; Mon, 16 Feb 2015 12:29:23 -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 XLYsrVYqZcQO for ; Mon, 16 Feb 2015 12:29:22 -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 C1A4E1A8776 for ; Mon, 16 Feb 2015 12:29: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 t1GKTGKK001513; Mon, 16 Feb 2015 21:29:16 +0100 (CET) Received: from aung.tzi.org (p57A63EC9.dip0.t-ipconnect.de [87.166.62.201]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3kmH3J0SrRz2PtC; Mon, 16 Feb 2015 21:29:16 +0100 (CET) From: Olaf Bergmann To: =?utf-8?Q?G=C3=B6ran?= Selander References: <20150205095841.19111.5154.idtracker@ietfa.amsl.com> <54D341F6.9040109@tzi.de> <54D8D0C5.6030101@tzi.de> <54DB8097.4030206@tzi.de> <54DCB601.3070307@tzi.de> Date: Mon, 16 Feb 2015 21:29:15 +0100 In-Reply-To: (=?utf-8?Q?=22G?= =?utf-8?Q?=C3=B6ran?= Selander"'s message of "Fri, 13 Feb 2015 08:23:19 +0000") Message-ID: <87iof1txb8.fsf@tzi.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Stefanie Gerdes , "Ace@ietf.org" Subject: Re: [Ace] Fwd: I-D Action: draft-ietf-ace-usecases-02.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 20:29:23 -0000 Hi G=C3=B6ran, please let me comment on your previous message as you keep referencing this as a proof that client actions need not be authorized and hence should be out of scope in your opinion. G=C3=B6ran Selander writes: > Now, what kind of access control problem is =E2=80=9Conly allow data from > authorized sources=E2=80=9D? (Analogous comments for sending to authorized > resources.) > > - The client should also "only allow access tokens from authorized > sources=E2=80=9D (authorization servers). Yes, that is very important once you try to define authorization transfer to entirely cover a device's lifecycle. Meanwhile, many solutions just use implicit authorization by accepting "access tokens" only from authenticated authorization servers. > - It should "only allow data from authorized cloud services" of the > container owner (not particular for this example, but just as an example > of another source of data that needs to be "authorized=E2=80=9D). Sure, but this "cloud service" is just another resource server. Nothing new here. > - A device should "only allow data from authorized drivers" in > communicating with its resources. If "driver" here means "device driver" as in operating systems, then this is clearly out of IETF scope. > - It should "only allow data from authorized ciphersuites" in > communication with the resource (if you view decryption as a source of > potentially unauthorized data). Not sure what you mean here, but yes: You could distinguish your crypto parameters according to the security objectives for a particular action.=20 Given that this WG addresses the layer above DTLS, I do not think that this is in scope of the ACE WG (while the CoAP interaction is). > If you think about it, there is a lot of things that needs to be > =E2=80=9Cauthorized=E2=80=9D. All these "authorization problems=E2=80=9D= can potentially be hard > coded. All can potentially be addressed with access control policies, > decision, enforcement etc.. My objections to include this category of > problems in ACE is: Sure, you can do without explicit authorization. Or with just addressing half of the problem. > - The problem is not well scoped (as this list of examples tries to > illustrate) compared to the access control problems above As you can see above, there is a very clear boundary of what falls in scope and what does not. > - I see no evidence in the use cases that this is an important problem > that needs to be addressed with access policies etc.. How about: "Transfer my credit card details only to resource x on device y"? I really love today's web browsers that let me as a user take control over which data is sent where. And I really want to be able to control my M2M devices (sometimes called "smart objects") to also be that smart. > - This as an independent problem which makes the total problem statement > more complex.=20 As you can see, it does not make anything complex. It is just: The resource owner wants to protect its resources, the client owner wants to protect its client. No more, no less. Gr=C3=BC=C3=9Fe Olaf From nobody Tue Feb 17 01:05:54 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651E61A0545 for ; Tue, 17 Feb 2015 01:05:53 -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 34dP72_iebwx for ; Tue, 17 Feb 2015 01:05:51 -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 7296C1A037C for ; Tue, 17 Feb 2015 01:05:50 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-b7-54e3046c45b8 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 89.8E.24955.C6403E45; Tue, 17 Feb 2015 10:05:48 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.27]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0210.002; Tue, 17 Feb 2015 10:05:47 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Olaf Bergmann Thread-Topic: [Ace] Fwd: I-D Action: draft-ietf-ace-usecases-02.txt Thread-Index: AQHQQSw5Sfw0ELIkVUS6mg1j4TnWLZzjcYsAgATz2oCAASzlgIACBw6AgAApeICAAUdhgIABQBmAgAWB2c2AANNZAA== Date: Tue, 17 Feb 2015 09:05:47 +0000 Message-ID: References: <20150205095841.19111.5154.idtracker@ietfa.amsl.com> <54D341F6.9040109@tzi.de> <54D8D0C5.6030101@tzi.de> <54DB8097.4030206@tzi.de> <54DCB601.3070307@tzi.de> <87iof1txb8.fsf@tzi.org> In-Reply-To: <87iof1txb8.fsf@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyM+JvjW4Oy+MQgx3PJS2+f+thtmha3Mhk sfHiXUYHZo8lS34yeWx7+5XZY9qizADmKC6blNSczLLUIn27BK6M91t3MBccM67o/rOBvYFx jlEXIyeHhICJxKK/P5ghbDGJC/fWs3UxcnEICRxhlLjb3wflLGaUaPs0EayKTcBF4kHDIyYQ W0RARWJD9zMwm1nASeL/zFNsILYwkL301WNWiBpniePfdzNC2FkSXzesBathEVCVWLvzN1ic V8BCYv/kVewQy/4zSZw7cYcdJMEJVDR36yGwBYxA530/tQZqmbjErSfzmSDOFpBYsuc81Aui Ei8f/wNbLCqgJ7HyehMbRFxJonHJE6A4B1CvpsT6XfoQY6wlXh25zgxhK0pM6X7IDnGPoMTJ mU9YJjBKzEKybRZC9ywk3bOQdM9C0r2AkXUVo2hxanFSbrqRsV5qUWZycXF+nl5easkmRmBk HtzyW3UH4+U3jocYBTgYlXh4N6x7FCLEmlhWXJl7iFGag0VJnNfO+FCIkEB6YklqdmpqQWpR fFFpTmrxIUYmDk6pBsbyqWk8QS90Y+b3PJm1d0L9ia+Jxydtvbz5qbP9vcKnjySddU77Fq5q uvZESlV27+NtbPMV5yWxClS90lL7vGa9jY3rnhMzlArn1O41S97lbHixZn2A20xtPwljnrWV r5deUMr6qXhiF48Lsxrz0yS7w5yLd7KU19w3mnla78AP69NWTzLs1Q2UWIozEg21mIuKEwFp sUw2rQIAAA== Archived-At: Cc: Stefanie Gerdes , "Ace@ietf.org" Subject: Re: [Ace] Fwd: I-D Action: draft-ietf-ace-usecases-02.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 09:05:53 -0000 SGkgT2xhZiwNCg0KT24gMjAxNS0wMi0xNiAyMToyOSwgIk9sYWYgQmVyZ21hbm4iIDxiZXJnbWFu bkB0emkub3JnPiB3cm90ZToNCg0KPkhpIEfDtnJhbiwNCj4NCj5wbGVhc2UgbGV0IG1lIGNvbW1l bnQgb24geW91ciBwcmV2aW91cyBtZXNzYWdlIGFzIHlvdSBrZWVwIHJlZmVyZW5jaW5nDQo+dGhp cyBhcyBhIHByb29mIHRoYXQgY2xpZW50IGFjdGlvbnMgbmVlZCBub3QgYmUgYXV0aG9yaXplZCBh bmQgaGVuY2UNCj5zaG91bGQgYmUgb3V0IG9mIHNjb3BlIGluIHlvdXIgb3Bpbmlvbi4NCg0KUGxl YXNlIG5vdGUgdGhhdCBJ4oCZbSBub3QgcXVlc3Rpb25pbmcgdGhhdCBhbGwgdGhlc2UgYWN0aW9u cywgdGhlIG9uZXMgeW91DQpsaXN0IGFuZCB0aGUgb25lcyBJIGxpc3QgbmVlZCB0byBiZSBjYXJy aWVkIG91dC4gSeKAmW0gcXVlc3Rpb25pbmcgdGhhdCB0aGV5DQpNVVNUIGJlIHNvbHZlZCB3aXRo IGFjY2VzcyBjb250cm9sIHBvbGljaWVzLiBSZWNhbGwgdGhlIGN1cnJlbnQNCmRlZmluaXRpb246 ICJDbGllbnQgT3duZXI6ICAgVGhlIHN1YmplY3Qgd2hvIGNvbnRyb2xzIHRoZSBhY2Nlc3MNCnBl cm1pc3Npb25zIG9mIGEgY2xpZW50LuKAnQ0KDQpJIHdhbnRlZCB0byBpbGx1c3RyYXRlIHRoZSBp c3N1ZSBieSBsaXN0aW5nIGEgbnVtYmVyIG9mIG90aGVyIGNsaWVudA0KYWN0aW9ucyB0aGF0IHlv dSB3b3VsZCB0eXBpY2FsbHkgbm90IHVzZSBhY2Nlc3MgY29udHJvbCBwb2xpY2llcyBmb3IuDQoN Cj4NCj5Hw7ZyYW4gU2VsYW5kZXIgPGdvcmFuLnNlbGFuZGVyQGVyaWNzc29uLmNvbT4gd3JpdGVz Og0KPg0KPj4gTm93LCB3aGF0IGtpbmQgb2YgYWNjZXNzIGNvbnRyb2wgcHJvYmxlbSBpcyDigJxv bmx5IGFsbG93IGRhdGEgZnJvbQ0KPj4gYXV0aG9yaXplZCBzb3VyY2Vz4oCdPyAoQW5hbG9nb3Vz IGNvbW1lbnRzIGZvciBzZW5kaW5nIHRvIGF1dGhvcml6ZWQNCj4+IHJlc291cmNlcy4pDQo+Pg0K Pj4gLSBUaGUgY2xpZW50IHNob3VsZCBhbHNvICJvbmx5IGFsbG93IGFjY2VzcyB0b2tlbnMgZnJv bSBhdXRob3JpemVkDQo+PiBzb3VyY2Vz4oCdIChhdXRob3JpemF0aW9uIHNlcnZlcnMpLg0KPg0K PlllcywgdGhhdCBpcyB2ZXJ5IGltcG9ydGFudCBvbmNlIHlvdSB0cnkgdG8gZGVmaW5lIGF1dGhv cml6YXRpb24NCj50cmFuc2ZlciB0byBlbnRpcmVseSBjb3ZlciBhIGRldmljZSdzIGxpZmVjeWNs ZS4gTWVhbndoaWxlLCBtYW55DQo+c29sdXRpb25zIGp1c3QgdXNlIGltcGxpY2l0IGF1dGhvcml6 YXRpb24gYnkgYWNjZXB0aW5nICJhY2Nlc3MgdG9rZW5zIg0KPm9ubHkgZnJvbSBhdXRoZW50aWNh dGVkIGF1dGhvcml6YXRpb24gc2VydmVycy4NCg0KRXhhY3RseSwgYW5kIOKAnGltcGxpY2l0IGF1 dGhvcml6YXRpb27igJ0gaXMgYSB2YWxpZCBzb2x1dGlvbiBhbHNvIHRvIHRoZQ0KcHJvYmxlbSB5 b3UgbGlzdC4NCg0KPg0KPj4gLSBJdCBzaG91bGQgIm9ubHkgYWxsb3cgZGF0YSBmcm9tIGF1dGhv cml6ZWQgY2xvdWQgc2VydmljZXMiIG9mIHRoZQ0KPj4gY29udGFpbmVyIG93bmVyIChub3QgcGFy dGljdWxhciBmb3IgdGhpcyBleGFtcGxlLCBidXQganVzdCBhcyBhbiBleGFtcGxlDQo+PiBvZiBh bm90aGVyIHNvdXJjZSBvZiBkYXRhIHRoYXQgbmVlZHMgdG8gYmUgImF1dGhvcml6ZWTigJ0pLg0K Pg0KPlN1cmUsIGJ1dCB0aGlzICJjbG91ZCBzZXJ2aWNlIiBpcyBqdXN0IGFub3RoZXIgcmVzb3Vy Y2Ugc2VydmVyLiBOb3RoaW5nDQo+bmV3IGhlcmUuDQoNClRoaXMgZXZlbiBmdXJ0aGVyIGhpZ2hs aWdodHMgdGhlIHByb2JsZW06IHRoZSBjbGllbnQgYWNjZXNzaW5nIGEgY2xvdWQNCnNlcnZpY2Ug b2YgdGhlIGNsaWVudCBvd25lciBpcyBhIGNvbXBsZXRlbHkgY2xpZW50IGludGVybmFsIHByb2Js ZW0uIFdoeQ0KbXVzdCBhbGwgQUNFIHNvbHV0aW9ucyB1c2UgYWNjZXNzIGNvbnRyb2wgcG9saWNp ZXMgZm9yIHRoaXM/DQoNCj4NCj4+IC0gQSBkZXZpY2Ugc2hvdWxkICJvbmx5IGFsbG93IGRhdGEg ZnJvbSBhdXRob3JpemVkIGRyaXZlcnMiIGluDQo+PiBjb21tdW5pY2F0aW5nIHdpdGggaXRzIHJl c291cmNlcy4NCj4NCj5JZiAiZHJpdmVyIiBoZXJlIG1lYW5zICJkZXZpY2UgZHJpdmVyIiBhcyBp biBvcGVyYXRpbmcgc3lzdGVtcywgdGhlbg0KPnRoaXMgaXMgY2xlYXJseSBvdXQgb2YgSUVURiBz Y29wZS4NCg0KQWdyZWUsIHRoaXMgd2FzIGEgYml0IG9mIGEgc3RyZXRjaC4NCg0KPg0KPj4gLSBJ dCBzaG91bGQgIm9ubHkgYWxsb3cgZGF0YSBmcm9tIGF1dGhvcml6ZWQgY2lwaGVyc3VpdGVzIiBp bg0KPj4gY29tbXVuaWNhdGlvbiB3aXRoIHRoZSByZXNvdXJjZSAoaWYgeW91IHZpZXcgZGVjcnlw dGlvbiBhcyBhIHNvdXJjZSBvZg0KPj4gcG90ZW50aWFsbHkgdW5hdXRob3JpemVkIGRhdGEpLg0K Pg0KPk5vdCBzdXJlIHdoYXQgeW91IG1lYW4gaGVyZSwgYnV0IHllczogWW91IGNvdWxkIGRpc3Rp bmd1aXNoIHlvdXIgY3J5cHRvDQo+cGFyYW1ldGVycyBhY2NvcmRpbmcgdG8gdGhlIHNlY3VyaXR5 IG9iamVjdGl2ZXMgZm9yIGEgcGFydGljdWxhciBhY3Rpb24uDQo+R2l2ZW4gdGhhdCB0aGlzIFdH IGFkZHJlc3NlcyB0aGUgbGF5ZXIgYWJvdmUgRFRMUywgSSBkbyBub3QgdGhpbmsgdGhhdA0KPnRo aXMgaXMgaW4gc2NvcGUgb2YgdGhlIEFDRSBXRyAod2hpbGUgdGhlIENvQVAgaW50ZXJhY3Rpb24g aXMpLg0KDQpBbiBpbGx1c3RyYXRpb24gb2YgYSBjbGllbnQgY29uY2VybiB3aGljaCBhbHNvIGNv dWxkIGJ1dCBwcm9iYWJseSBzaG91bGQNCm5vdCBiZSBoYW5kbGVkIHdpdGggYWNjZXNzIGNvbnRy b2wgcG9saWNpZXMuDQoNCj4NCj4+IElmIHlvdSB0aGluayBhYm91dCBpdCwgdGhlcmUgaXMgYSBs b3Qgb2YgdGhpbmdzIHRoYXQgbmVlZHMgdG8gYmUNCj4+IOKAnGF1dGhvcml6ZWTigJ0uICBBbGwg dGhlc2UgImF1dGhvcml6YXRpb24gcHJvYmxlbXPigJ0gY2FuIHBvdGVudGlhbGx5IGJlDQo+Pmhh cmQNCj4+IGNvZGVkLiBBbGwgY2FuIHBvdGVudGlhbGx5IGJlIGFkZHJlc3NlZCB3aXRoIGFjY2Vz cyBjb250cm9sIHBvbGljaWVzLA0KPj4gZGVjaXNpb24sIGVuZm9yY2VtZW50IGV0Yy4uIE15IG9i amVjdGlvbnMgdG8gaW5jbHVkZSB0aGlzIGNhdGVnb3J5IG9mDQo+PiBwcm9ibGVtcyBpbiBBQ0Ug aXM6DQo+DQo+U3VyZSwgeW91IGNhbiBkbyB3aXRob3V0IGV4cGxpY2l0IGF1dGhvcml6YXRpb24u IE9yIHdpdGgganVzdCBhZGRyZXNzaW5nDQo+aGFsZiBvZiB0aGUgcHJvYmxlbS4NCg0KU2VlIGJl bG93Lg0KDQo+DQo+PiAtIFRoZSBwcm9ibGVtIGlzIG5vdCB3ZWxsIHNjb3BlZCAoYXMgdGhpcyBs aXN0IG9mIGV4YW1wbGVzIHRyaWVzIHRvDQo+PiBpbGx1c3RyYXRlKSBjb21wYXJlZCB0byB0aGUg YWNjZXNzIGNvbnRyb2wgcHJvYmxlbXMgYWJvdmUNCj4NCj5BcyB5b3UgY2FuIHNlZSBhYm92ZSwg dGhlcmUgaXMgYSB2ZXJ5IGNsZWFyIGJvdW5kYXJ5IG9mIHdoYXQgZmFsbHMgaW4NCj5zY29wZSBh bmQgd2hhdCBkb2VzIG5vdC4NCj4NCj4+IC0gSSBzZWUgbm8gZXZpZGVuY2UgaW4gdGhlIHVzZSBj YXNlcyB0aGF0IHRoaXMgaXMgYW4gaW1wb3J0YW50IHByb2JsZW0NCj4+IHRoYXQgbmVlZHMgdG8g YmUgYWRkcmVzc2VkIHdpdGggYWNjZXNzIHBvbGljaWVzIGV0Yy4uDQo+DQo+SG93IGFib3V0OiAi VHJhbnNmZXIgbXkgY3JlZGl0IGNhcmQgZGV0YWlscyBvbmx5IHRvIHJlc291cmNlIHggb24gZGV2 aWNlDQo+eSI/DQo+SSByZWFsbHkgbG92ZSB0b2RheSdzIHdlYiBicm93c2VycyB0aGF0IGxldCBt ZSBhcyBhIHVzZXIgdGFrZSBjb250cm9sDQo+b3ZlciB3aGljaCBkYXRhIGlzIHNlbnQgd2hlcmUu IEFuZCBJIHJlYWxseSB3YW50IHRvIGJlIGFibGUgdG8gY29udHJvbA0KPm15IE0yTSBkZXZpY2Vz IChzb21ldGltZXMgY2FsbGVkICJzbWFydCBvYmplY3RzIikgdG8gYWxzbyBiZSB0aGF0IHNtYXJ0 Lg0KDQpJIGRvbuKAmXQgcmVhbGx5IHVuZGVyc3RhbmQgdGhlIHVzZSBjYXNlIHdoZXJlIHlvdSBu ZWVkIHRvIHRyYW5zZmVyIGNyZWRpdA0KY2FyZCBkZXRhaWxzIHRvIHZhcmlvdXMgZGV2aWNlcy4g QnV0IGlmIEkgd291bGQgbW9kZWwgdGhhdCB3aXRoIGFjY2Vzcw0KY29udHJvbCBwb2xpY2llcywg SSB3b3VsZCBjb25zaWRlciB0aGUgY3JlZGl0IGNhcmQgZGV0YWlscyB0byBiZSB0aGUNCnJlc291 cmNlLCBhbmQgdGhlIGRldmljZSBob3N0aW5nIGEgY29weSB0byBiZSB0aGUgY2xpZW50Lg0KDQo+ DQo+PiAtIFRoaXMgYXMgYW4gaW5kZXBlbmRlbnQgcHJvYmxlbSB3aGljaCBtYWtlcyB0aGUgdG90 YWwgcHJvYmxlbSBzdGF0ZW1lbnQNCj4+IG1vcmUgY29tcGxleC4gDQo+DQo+QXMgeW91IGNhbiBz ZWUsIGl0IGRvZXMgbm90IG1ha2UgYW55dGhpbmcgY29tcGxleC4gSXQgaXMganVzdDogVGhlDQo+ cmVzb3VyY2Ugb3duZXIgd2FudHMgdG8gcHJvdGVjdCBpdHMgcmVzb3VyY2VzLCB0aGUgY2xpZW50 IG93bmVyIHdhbnRzIHRvDQo+cHJvdGVjdCBpdHMgY2xpZW50LiBObyBtb3JlLCBubyBsZXNzLg0K DQpUaGUgY2xpZW50IGNvbmNlcm4gaXMgYW4gaW5kZXBlbmRlbnQgcHJvYmxlbSwgd2hpY2ggd2Ug Y291bGQgbGVhdmUgdG8gdGhlDQphcHBsaWNhdGlvbiBkZXZlbG9wZXIgdG8gZGVjaWRlIGFib3V0 LiBZb3Ugc3RhdGUgYWJvdmUgdGhhdCBpdCBpcyBoYWxmIG9mDQp0aGUgcHJvYmxlbS4gV291bGRu 4oCZdCB0aGVuIHRoZSB0b3RhbCBwcm9ibGVtIHN0YXRlbWVudCBiZSBhYm91dCB0d2ljZSBhcw0K ZWFzeSBpZiB3ZSByZW1vdmUgdGhlIGNsaWVudCBjb25jZXJucz8NCg0KQmVzdCByZWdhcmRzDQpH w7ZyYW4NCg0KDQo+DQo+R3LDvMOfZQ0KPk9sYWYNCg0K From nobody Tue Feb 17 01:52: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 80F5C1A6F38 for ; Tue, 17 Feb 2015 01:52:18 -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 wwA4l9HONBcy for ; Tue, 17 Feb 2015 01:52:16 -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 65A1A1A1A98 for ; Tue, 17 Feb 2015 01:52:16 -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 t1H9qBLw015076; Tue, 17 Feb 2015 10:52:11 +0100 (CET) Received: from aung.tzi.org (eduroam-pool3-015.wlan.uni-bremen.de [134.102.232.15]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3kmcsl3VwTz2Npm; Tue, 17 Feb 2015 10:52:11 +0100 (CET) From: Olaf Bergmann To: =?utf-8?Q?G=C3=B6ran?= Selander References: <20150205095841.19111.5154.idtracker@ietfa.amsl.com> <54D341F6.9040109@tzi.de> <54D8D0C5.6030101@tzi.de> <54DB8097.4030206@tzi.de> <54DCB601.3070307@tzi.de> <87iof1txb8.fsf@tzi.org> Date: Tue, 17 Feb 2015 10:52:11 +0100 In-Reply-To: (=?utf-8?Q?=22G?= =?utf-8?Q?=C3=B6ran?= Selander"'s message of "Tue, 17 Feb 2015 09:05:47 +0000") Message-ID: <87egpouapg.fsf@tzi.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Stefanie Gerdes , "Ace@ietf.org" Subject: Re: [Ace] Fwd: I-D Action: draft-ietf-ace-usecases-02.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 09:52:18 -0000 Hi G=C3=B6ran, G=C3=B6ran Selander writes: > Please note that I=E2=80=99m not questioning that all these actions, the = ones you > list and the ones I list need to be carried out. I=E2=80=99m questioning = that they > MUST be solved with access control policies. Recall the current > definition: "Client Owner: The subject who controls the access > permissions of a client.=E2=80=9D > > I wanted to illustrate the issue by listing a number of other client > actions that you would typically not use access control policies for. Your point taken. But you are going into the solution space again (and I agree that many of your proposed solutions are good practice and will most likely do in many cases). But the goal of the use cases document is to list authorization problems and their solutions. In my opinion it is good to know the problem space and then design a solution for this. At that step (and not before), it can be reasonable to decide that some of the problems are addressed later or are addressed not at all by the actual solution while some are a must. But to be able to deliberately decide this, one must be aware of those problems. This, and not more, is the intention of the use cases as I read it. Gr=C3=BC=C3=9Fe Olaf From nobody Tue Feb 17 02:08: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 7442E1A8547 for ; Tue, 17 Feb 2015 02:08:38 -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 Ogg9c82aG-rP for ; Tue, 17 Feb 2015 02:08:36 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 575761A00D4 for ; Tue, 17 Feb 2015 02:08:36 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-a7-54e313211be3 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 60.6C.04231.12313E45; Tue, 17 Feb 2015 11:08:34 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.27]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0210.002; Tue, 17 Feb 2015 11:08:33 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Olaf Bergmann Thread-Topic: [Ace] Fwd: I-D Action: draft-ietf-ace-usecases-02.txt Thread-Index: AQHQQSw5Sfw0ELIkVUS6mg1j4TnWLZzjcYsAgATz2oCAASzlgIACBw6AgAApeICAAUdhgIABQBmAgAWB2c2AANNZAIAADPzbgAAEjQA= Date: Tue, 17 Feb 2015 10:08:33 +0000 Message-ID: References: <20150205095841.19111.5154.idtracker@ietfa.amsl.com> <54D341F6.9040109@tzi.de> <54D8D0C5.6030101@tzi.de> <54DB8097.4030206@tzi.de> <54DCB601.3070307@tzi.de> <87iof1txb8.fsf@tzi.org> <87egpouapg.fsf@tzi.org> In-Reply-To: <87egpouapg.fsf@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-ID: <5628C76391AEE143A1A2494ED73CFA58@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyM+Jvja6S8OMQg7/fOCy+f+thtmha3Mhk sfHiXUYHZo8lS34yeWx7+5XZY9qizADmKC6blNSczLLUIn27BK6MZ19/shbsEKn4ef0+YwPj F+EuRk4OCQETif4/l9ggbDGJC/fWA9lcHEICRxgl/j6/ygjhLGaUeL5tKzNIFZuAi8SDhkdM ILaIgIrEhu5nYDazgJPE/5mnwCYJA9lLXz1mhahxljj+fTcjhF0m8XLXC6A4BweLgKrEhx4B kDCvgIXE3asLwUqEBI4zS5y+nAFicwKVnG1tYgexGYGO+35qDdQqcYlbT+YzQRwtILFkz3lm CFtU4uXjf2BrRQX0JFZeb4J6TEmicckTsLXMApoS63fpQ4yxllh87TTUSEWJKd0P2SHOEZQ4 OfMJywRGiVlIts1C6J6FpHsWku5ZSLoXMLKuYhQtTi0uzk03MtZLLcpMLi7Oz9PLSy3ZxAiM yoNbfuvuYFz92vEQowAHoxIP74Z1j0KEWBPLiitzDzFKc7AoifPaGR8KERJITyxJzU5NLUgt ii8qzUktPsTIxMEp1cDYZPWnXff3Xatkp7WBnrdnGX5/uYgjO8tdb0vN02uPlY7vN1g00ZH5 qdRKzquHtY+u4ZHf5bmyI9c/V4H1kvWBiJ6ADSufqmVsmS077SjH7Ilqc5fWun28af1CV/mc smtuK1NCvL4At6Cd7pr8WWdjaooXW+typS/ND53PH8pn83jlvqQFswSUWIozEg21mIuKEwEF hQhdqwIAAA== Archived-At: Cc: Stefanie Gerdes , "Ace@ietf.org" Subject: Re: [Ace] Fwd: I-D Action: draft-ietf-ace-usecases-02.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 10:08:38 -0000 SGkgT2xhZg0KDQpPbiAyMDE1LTAyLTE3IDEwOjUyLCAiT2xhZiBCZXJnbWFubiIgPGJlcmdtYW5u QHR6aS5vcmc+IHdyb3RlOg0KDQo+SGkgR8O2cmFuLA0KPg0KPkfDtnJhbiBTZWxhbmRlciA8Z29y YW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tPiB3cml0ZXM6DQo+DQo+PiBQbGVhc2Ugbm90ZSB0aGF0 IEnigJltIG5vdCBxdWVzdGlvbmluZyB0aGF0IGFsbCB0aGVzZSBhY3Rpb25zLCB0aGUgb25lcw0K Pj55b3UNCj4+IGxpc3QgYW5kIHRoZSBvbmVzIEkgbGlzdCBuZWVkIHRvIGJlIGNhcnJpZWQgb3V0 LiBJ4oCZbSBxdWVzdGlvbmluZyB0aGF0DQo+PnRoZXkNCj4+IE1VU1QgYmUgc29sdmVkIHdpdGgg YWNjZXNzIGNvbnRyb2wgcG9saWNpZXMuIFJlY2FsbCB0aGUgY3VycmVudA0KPj4gZGVmaW5pdGlv bjogIkNsaWVudCBPd25lcjogICBUaGUgc3ViamVjdCB3aG8gY29udHJvbHMgdGhlIGFjY2Vzcw0K Pj4gcGVybWlzc2lvbnMgb2YgYSBjbGllbnQu4oCdDQo+Pg0KPj4gSSB3YW50ZWQgdG8gaWxsdXN0 cmF0ZSB0aGUgaXNzdWUgYnkgbGlzdGluZyBhIG51bWJlciBvZiBvdGhlciBjbGllbnQNCj4+IGFj dGlvbnMgdGhhdCB5b3Ugd291bGQgdHlwaWNhbGx5IG5vdCB1c2UgYWNjZXNzIGNvbnRyb2wgcG9s aWNpZXMgZm9yLg0KPg0KPllvdXIgcG9pbnQgdGFrZW4uIEJ1dCB5b3UgYXJlIGdvaW5nIGludG8g dGhlIHNvbHV0aW9uIHNwYWNlIGFnYWluIChhbmQgSQ0KPmFncmVlIHRoYXQgbWFueSBvZiB5b3Vy IHByb3Bvc2VkIHNvbHV0aW9ucyBhcmUgZ29vZCBwcmFjdGljZSBhbmQgd2lsbA0KPm1vc3QgbGlr ZWx5IGRvIGluIG1hbnkgY2FzZXMpLiBCdXQgdGhlIGdvYWwgb2YgdGhlIHVzZSBjYXNlcyBkb2N1 bWVudCBpcw0KPnRvIGxpc3QgYXV0aG9yaXphdGlvbiBwcm9ibGVtcyBhbmQgdGhlaXIgc29sdXRp b25zLiBJbiBteSBvcGluaW9uIGl0IGlzDQo+Z29vZCB0byBrbm93IHRoZSBwcm9ibGVtIHNwYWNl IGFuZCB0aGVuIGRlc2lnbiBhIHNvbHV0aW9uIGZvciB0aGlzLiBBdA0KPnRoYXQgc3RlcCAoYW5k IG5vdCBiZWZvcmUpLCBpdCBjYW4gYmUgcmVhc29uYWJsZSB0byBkZWNpZGUgdGhhdCBzb21lIG9m DQo+dGhlIHByb2JsZW1zIGFyZSBhZGRyZXNzZWQgbGF0ZXIgb3IgYXJlIGFkZHJlc3NlZCBub3Qg YXQgYWxsIGJ5IHRoZQ0KPmFjdHVhbCBzb2x1dGlvbiB3aGlsZSBzb21lIGFyZSBhIG11c3QuIEJ1 dCB0byBiZSBhYmxlIHRvIGRlbGliZXJhdGVseQ0KPmRlY2lkZSB0aGlzLCBvbmUgbXVzdCBiZSBh d2FyZSBvZiB0aG9zZSBwcm9ibGVtcy4gVGhpcywgYW5kIG5vdCBtb3JlLCBpcw0KPnRoZSBpbnRl bnRpb24gb2YgdGhlIHVzZSBjYXNlcyBhcyBJIHJlYWQgaXQuDQoNCldlIGJvdGggc2VlbSB0byBo YXZlIGlzc3VlcyB3aXRoIGdvaW5nIGludG8gc29sdXRpb24gc3BhY2UuIEkgdGhpbmsNCmV2ZXJ5 b25lIGFncmVlcyB0aGF0IHdlIGludGVuZCB0byBkZWZpbmUgYW4gIHNvbHV0aW9uIHRvIHRoZSBh Y2Nlc3MNCmNvbnRyb2wgdG8gcmVzb3VyY2UgcHJvYmxlbSB3aGljaCBpcyBiYXNlZCBvbiBhY2Nl c3MgY29udHJvbCBwb2xpY2llcyBzZXQNCmJ5IHRoZSBSZXNvdXJjZSBPd25lci4gSeKAmW0gaGFw cHkgd2l0aCBsaXN0aW5nIFUxLjIgYXMgYSBjbGllbnQgcHJvYmxlbSwNCnVubGVzcyB5b3UgaW5z aXN0IHRoYXQgaXQgbXVzdCBiZSBzb2x2ZWQgYnkgbWVhbnMgb2YgdGhpcyBtYWNoaW5lcnkgd2l0 aA0KYWNjZXNzIGNvbnRyb2wgcG9saWNpZXMsIGRlY2lzaW9uLCBlbmZvcmNlbWVudCwgZXRjLi4g TWF5YmUgd2UgY291bGQganVzdA0KcmVwbGFjZSB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgQ2xpZW50 IE93bmVyIHdpdGggIlRoZSBzdWJqZWN0IHdobyBkZWNpZGVzDQphYm91dCBhIGNsaWVudC7igJ0/ DQoNCg0KPg0KPkdyw7zDn2UNCj5PbGFmDQoNCg== From nobody Tue Feb 17 09:40:22 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E86C1A1AF8 for ; Tue, 17 Feb 2015 09:40:21 -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 wGDTQzLr054b for ; Tue, 17 Feb 2015 09:40:18 -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 6D4111A1B5C for ; Tue, 17 Feb 2015 09:40:18 -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 t1HHeD5G025198; Tue, 17 Feb 2015 18:40:13 +0100 (CET) Received: from [IPv6:2001:638:708:30da:917f:c7ca:5213:e1c] (unknown [IPv6:2001:638:708:30da:917f:c7ca:5213:e1c]) (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 3kmqFn60YLz2Ns2; Tue, 17 Feb 2015 18:40:13 +0100 (CET) Message-ID: <54E37CFD.9010208@tzi.de> Date: Tue, 17 Feb 2015 18:40:13 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= References: <20150205095841.19111.5154.idtracker@ietfa.amsl.com> <54D341F6.9040109@tzi.de> <54D8D0C5.6030101@tzi.de> <54DB8097.4030206@tzi.de> <54DCB601.3070307@tzi.de> <54DE2721.40304@tzi.de> <54E230D5.8090104@tzi.de> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "Ace@ietf.org" Subject: [Ace] Variants (was: Re: Fwd: I-D Action: draft-ietf-ace-usecases-02.txt) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 17:40:21 -0000 Hi Göran, On 02/16/2015 08:21 PM, Göran Selander wrote: > Hi Steffi, > > About the Charter: If you ask about people what "authorized access to > resources identified by a URI and hosted on a > resource server” means, I think many would make the interpretation in U1.1 > and very few, if any, would make the interpretation of U1.2. Stating that > the charter supports your claim is IMHO an over-interpretation. > > There are also other "problems” of the Client Owners, like the examples I > mentioned in > http://www.ietf.org/mail-archive/web/ace/current/msg00989.html. The > assumption that U1.2 should be solved with access control policies (if > that is implied) is arbitrary. > > About requirement vs problem: If a candidate solution does not solve > problem U1.1 that is not acceptable. However, we should not discriminate > solutions which does not solve U1.2 with access control policies. If we > have this formulation, it should be made clear that U1.2 is optional. It is not optional to solve the U1.2 problem. In some cases authorization problems might be solved by implicit authorization. We can point this out in the security considerations. We can add the following to 3.2: Endpoints need to be enabled to enforce the authorization policies of their principals. In some cases, authorization problems might bei solved by implicit authorization (all authenticated entities are authorized). > > You should keep "such as the fruit vendor and container owner” etc. in the > formulation, just as you had in your previous version. One major point > with the problem formulation is to explain the terminology in terms of the > actors of the use case. We will not be able to decide whether a fruit vendor will in every case be a client owner or a resource owner. To make this more clear, we can add the following section to the container use case (I think this is a useful exercise since it shows the various possible settings): # Variants As mentioned in section 2, there are various reasons for assigning a function (CoAP client or server) to a device. This section lists possible settings for the communication between a temperature sensor and a fan actuator. ## Temperature Sensor and Fan Actuator Servers Temperature sensors and fan actuators are servers, an aggregation server that belongs to the container owner is the client. Therefore, the fruit vendor is a Resource Owner. The container owner is a Resource Owner and a Client Owner. Temperature sensors are resources on individual CoAP servers that belong to the fruit vendor. The CoAP client is an aggregation server that requests the temperature values from the servers and computes a temperature setting from these results. The result is then transmitted to the ventilation system of the container owner. ## Temperature Sensor and Fan Actuator Clients Temperature sensors and fan actuators are located on clients. An aggregation server that belongs to the container owner is a server. The fruit vendor is a Client Owner. The container owner is a Client Owner and a Resource Owner. The clients with the temperature sensors send a representation of the current temperature values to a resource on the aggregation server whenever the temperature changes. The client that controls the fan actuator requests the aggregated temperature values from the aggregation server. It uses observe to receive resource representations periodically. ## Temperature Sensor Client and Fan Actuator Server Temperature sensors are located on a client. The fan actuator is located on a server. An aggregation server that belongs to the container owner acts as a resource server for the temperature sensor and as a client for the fan actuator server. The client with the temperature sensor sends a representation of the current temperature values to a resource on the aggregation server whenever the temperature changes. The aggregation server then acts as a client to send the aggregated temperature values to a resource on the fan actuator server. ## Temperature Sensor Server and Fan Actuator Client Communicating directly Temperature sensors are located on a server. The fan actuator is located on a client. The fruit vendor is a resource owner, the container owner is a client owner. The client with the fan actuator requests the current sensor values directly from the nearest temperature sensor. It uses observe to get regular updates of the resource representation. The fan can react directly to local temperature changes and thus allows for an optimal temperature at different places within a container. ## Temperature Sensor Client and Fan Actuator Server Communicating directly Temperature sensors are located on a client. The fan actuator is located on a server. The fruit vendor is a Client Owner, the container owner is a Resource Owner. The client with the temperature sensor sends a representation of the current temperature values directly to a resource on the fan actuator server. The fan can react directly to local temperature changes as described above. Best regards, Steffi From nobody Tue Feb 17 23:16:47 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481131A033B for ; Tue, 17 Feb 2015 23:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aALu_mJ_7xqf for ; Tue, 17 Feb 2015 23:16:43 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B94E1A005D for ; Tue, 17 Feb 2015 23:16:43 -0800 (PST) Received: from [192.168.131.129] ([80.92.119.127]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MRo6b-1Y05Gz3w6b-00SzKK for ; Wed, 18 Feb 2015 08:16:41 +0100 Message-ID: <54E43C50.3040503@gmx.net> Date: Wed, 18 Feb 2015 08:16:32 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Ace@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IX5IKOmtU4FKnXesBdrejfIUWB6aEeQmK" X-Provags-ID: V03:K0:j6CLZkApr6VN3kbGB5qQjcNjU9eRJyR0PBM2Sxi/Um9kuQeiqPR k5j6ggPGTHpVwm5uEPbpo1LWNwHspavxkWUjGukOY3w/18lWvb44YZjXnbdzaCczLdX+mYm Rc88ZctaQppJ9cZ8TRpoa2jOi6f9DotV3qvKVtipMTOnv+tT2cduBS9QBY5c+E8BK9rYMjO 1RRsGG7pMSOynAvizlQDQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [Ace] Feedback on DTLS Documents X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Feb 2015 07:16:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IX5IKOmtU4FKnXesBdrejfIUWB6aEeQmK Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, I thought I should drop a mail to this group since DTLS is an important building block for an overall security solution in ACE. Although there is a lot of talk about optimization I am having a hard time getting feedback on the DICE mailing list for the 'Cached Info' document. Here is my mail to the DICE List: http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00550.html Ciao Hannes PS: Btw, the profile draft has also just gone through a working group last call in DICE and I was hoping to see more review comments: http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00551.html --IX5IKOmtU4FKnXesBdrejfIUWB6aEeQmK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU5DxQAAoJEGhJURNOOiAtASsH/AqC6d4zYMOuDGfNIv1tXYLn XMJz7ORpdf85mMMWIODDG3k5vRr+ANmeJWB0tYsd8/MKlCKNpJsH5jIGYy2a3Q/d vpJfFkDwbAZH6ht/HwZFdktkv27IoQgzDN2FiY5QbZdWn5ND2J/JjqmafS5+En8k NC5wIobx4puFo73u/TeUtXT3trZUzFu2MZ5c8MK8GcV6dY83PjmA7WF7tT7/UsnG rXQkKVObYW5VgxIj7dAzw+sS/BzHVWqH1XXzCL1s7O7MPH2AgfM2Y1x8sK8tQXFZ YAUXs+Ons+sEYv5W7Y8KOMOX7RdAvhNcOCjvKIXHliTFx7+PlvFk430FWmS737U= =SOlV -----END PGP SIGNATURE----- --IX5IKOmtU4FKnXesBdrejfIUWB6aEeQmK-- From nobody Wed Feb 18 00:17:50 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A8C1A911D for ; Wed, 18 Feb 2015 00:17: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 1zvm2ihS2CNs for ; Wed, 18 Feb 2015 00:17:46 -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 E2CC91A911A for ; Wed, 18 Feb 2015 00:17:45 -0800 (PST) X-AuditID: c1b4fb30-f79106d000001184-77-54e44aa73f4c Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 47.60.04484.7AA44E45; Wed, 18 Feb 2015 09:17:43 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.27]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0210.002; Wed, 18 Feb 2015 09:17:43 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Stefanie Gerdes Thread-Topic: Variants (was: Re: [Ace] Fwd: I-D Action: draft-ietf-ace-usecases-02.txt) Thread-Index: AQHQStjKNxpobLI34UujK0EjCjWiRZz2EQkA Date: Wed, 18 Feb 2015 08:17:43 +0000 Message-ID: References: <20150205095841.19111.5154.idtracker@ietfa.amsl.com> <54D341F6.9040109@tzi.de> <54D8D0C5.6030101@tzi.de> <54DB8097.4030206@tzi.de> <54DCB601.3070307@tzi.de> <54DE2721.40304@tzi.de> <54E230D5.8090104@tzi.de> <54E37CFD.9010208@tzi.de> In-Reply-To: <54E37CFD.9010208@tzi.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="utf-8" Content-ID: <186F7D48B0329040AF3DDE134AEAD3C0@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM+Jvje5yrychBj3dBhbfv/UwW2y8eJfR gcljyZKfTB7b3n5lDmCK4rJJSc3JLEst0rdL4MqY++UDY8EH/4plr14yNzC+8O1i5OSQEDCR mLRmMSuELSZx4d56ti5GLg4hgSOMEt8nn2KBcBYzSjx4/ZUFpIpNwEXiQcMjJhBbREBZ4vfi T2A2s4CixO5ZZ9lBbGGBCIklb7sZIWoiJZafmgA0lQPINpLoWCYPEmYRUJVoOTIVrJVXwELi 0vxHzBC7JrBI/H3aCtbLKaAmsXvpfWYQmxHouu+n1kDtEpe49WQ+E8TVAhJL9pxnhrBFJV4+ /gf2jaiAnsTK601sEHFFiY+v9jGC3MAsoCmxfpc+xBhriQ//djLDnD+l+yE7xD2CEidnPmGZ wCgxC8m2WQjds5B0z0LSPQtJ9wJG1lWMosWpxUm56UZGeqlFmcnFxfl5enmpJZsYgVF4cMtv gx2ML587HmIU4GBU4uEtsHgSIsSaWFZcmXuIUZqDRUmc1874UIiQQHpiSWp2ampBalF8UWlO avEhRiYOTqkGxoWlj0tlJ/IZf0q2K0/Svivo/l+9qHtSvpLoFY3D0+8qrJysu8ClvDbCs5d5 kkVM87efh/ND5ITu7PxqensOl4HlRQ4B8R0FF8o4OjZePTyxN2jKqR6/G/UGtxt5srXuuJRd F2Vl9eJVyo9YYS0SeUy6fp2P54RH4rHVziFOSvtML03OupChxFKckWioxVxUnAgAsXEHjKMC AAA= Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Variants (was: Re: Fwd: I-D Action: draft-ietf-ace-usecases-02.txt) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 08:17:49 -0000 SGkgU3RlZmZpLA0KDQpZb3VyIGxhc3QgbWFpbCBtYWtlIG1lIGhlc2l0YXRlIHdoZXRoZXIgd2Ug d2lsbCBwcm9ncmVzcyBiZXlvbmQgdGhlIGZpcnN0DQp1c2UgY2FzZSBiZWZvcmUgRGFsbGFzLg0K DQpXZeKAmXZlIHNwZW50IGEgZ29vZCBtb250aCBkaXNjdXNzaW5nIHRlcm1pbm9sb2d5IGFuZCBh cHBseWluZyBpdCB0byB0aGUNCmZpcnN0IHVzZSBjYXNlLiBJIGluaXRpYWxseSBjaGFsbGVuZ2Vk IHRoZSB0ZXJtaW5vbG9neSBhbmQgd2hldGhlciB0aGUNCnRlcm0g4oCcUmVzb3VyY2XigJ0gKGFu ZCB0aGVyZWJ5IHRoZSBvdGhlciB0ZXJtcykgaXMgd2VsbCBkZWZpbmVkLiBXZSBhZ3JlZWQNCnRo YXQgaXQgaXMgd2VsbCBkZWZpbmVkIGFuZCB3ZSBtYWRlIHRoZSBleGVyY2lzZSB0b2dldGhlciBv biB0aGUgZmlyc3QgdXNlDQpjYXNlLiBXZSBkaXNhZ3JlZSBvbiBVMS4xIGFuZCByZXBsYWNlZCBp dCB3aXRoIHR3byBwcm9ibGVtIHN0YXRlbWVudHMsDQpoZXJlIGlzIHlvdXIgbGF0ZXN0IHByb3Bv c2FsDQoNCiJXZSBjYW4gc3BsaXQgdXAgdGhlIGZpcnN0IHByb2JsZW0gaW50byB0d28gcHJvYmxl bXM6DQoNClUxLjE6IFJlc291cmNlIE93bmVycyB3YW50IHRvIGdyYW50IGRpZmZlcmVudCBhY2Nl c3MgcmlnaHRzIGZvciB0aGVpcg0KcmVzb3VyY2VzIHRvIGRpZmZlcmVudCBwYXJ0aWVzLg0KVTEu MjogQ2xpZW50IE93bmVycyB3YW50IHRvIGRlZmluZSBmb3IgdGhlaXIgY2xpZW50cyBpZiBhbmQg aG93IHRoZXkgYXJlDQphbGxvd2VkIHRvIGFjY2VzcyByZXNvdXJjZXMgaG9zdGVkIG9uIGEgUmVz b3VyY2UgU2VydmVyLiINCg0KTm93IHlvdSBwcmVzZW50IGEgbmV3IHNlY3Rpb24gd2l0aCBpbXBs ZW1lbnRhdGlvbiBzcGVjaWZpYyB2YXJpYW50cw0KaW5jbHVkaW5nICJhZ2dyZWdhdGlvbiBzZXJ2 ZXJz4oCdIGV0Yy4gd2hpY2ggZG9lcyBub3Qgc3RhdGUgd2hhdCB0aGUNCnJlc291cmNlcyBhcmUu IE9idmlvdXNseSwgb25lIGFjdG9yIGNhbiBiZSByZXNvdXJjZSBvd25lciBpbiBvbmUgY2FzZSBh bmQNCmNsaWVudCBvd25lciBpbiBhbm90aGVyLCBidXQgdGhpcyBkb2VzbuKAmXQgaW52YWxpZGF0 ZSB0aGF0IHRoZSByZXNvdXJjZXMNCmFyZSB0aGUgdGVtcGVyYXR1cmUgYW5kIHRoZSBmYW4gc2V0 dGluZ3MuIENvdWxkIHdlIHBsZWFzZSBub3RlIHRoYXQsIGFuZA0KdGhhdCBhbmQgdGhlIHJlc291 cmNlIG93bmVycyBhcmUgZnJ1aXQgdmVuZG9yIGFuZCBjb250YWluZXIgb3duZXIsDQpyZXNwZWN0 aXZlbHk/IEZvciBleGFtcGxlDQoNClUxLjE6IFJlc291cmNlIE93bmVycywgc3VjaCBhcyBmcnVp dCB2ZW5kb3JzIGFuZCBjb250YWluZXIgb3duZXJzLCB3YW50IHRvDQpncmFudCBkaWZmZXJlbnQg YWNjZXNzIHJpZ2h0cyB0byBkaWZmZXJlbnQgcGFydGllcyBmb3IgdGhlaXIgcmVzcGVjdGl2ZQ0K cmVzb3VyY2VzLCBzdWNoIGFzIHRlbXBlcmF0dXJlcyBhbmQgZmFuIHNldHRpbmdzLg0KDQpBcyBh IHNpZGUgbm90ZSwgSSB3aWxsIGJlIHRyYXZlbGxpbmcgbmV4dCB3ZWVrIHdpdGggbGltaXRlZCBl bWFpbCBhY2Nlc3MuDQpJIHdvdWxkIGxpa2UgdG8gaGF2ZSBhIHZlcnNpb24gb2YgdGhpcyBkcmFm dCB0aGF0IGlzIHJlcHJlc2VudGluZyB0aGUNCnZpZXdzIG9mIHRoZSBhdXRob3JzLCBvciBleHBy ZXNzZXMgdGhlIGRpc2FncmVlbWVudHMgaW4gdGhlIGRyYWZ0LCBiZWZvcmUNCnRoZSBjdXRvZmYu DQoNCk9uZSBjb21tZW50IGlubGluZS4NCg0KQmVzdCBSZWdhcmRzLA0KR8O2cmFuDQoNCk9uIDIw MTUtMDItMTcgMTg6NDAsICJTdGVmYW5pZSBHZXJkZXMiIDxnZXJkZXNAdHppLmRlPiB3cm90ZToN Cg0KPkhpIEfDtnJhbiwNCj4NCj5PbiAwMi8xNi8yMDE1IDA4OjIxIFBNLCBHw7ZyYW4gU2VsYW5k ZXIgd3JvdGU6DQo+PiBIaSBTdGVmZmksDQo+Pg0KPj4gQWJvdXQgdGhlIENoYXJ0ZXI6IElmIHlv dSBhc2sgYWJvdXQgcGVvcGxlIHdoYXQgImF1dGhvcml6ZWQgYWNjZXNzIHRvDQo+PiByZXNvdXJj ZXMgaWRlbnRpZmllZCBieSBhIFVSSSBhbmQgaG9zdGVkIG9uIGENCj4+IHJlc291cmNlIHNlcnZl cuKAnSBtZWFucywgSSB0aGluayBtYW55IHdvdWxkIG1ha2UgdGhlIGludGVycHJldGF0aW9uIGlu DQo+PlUxLjENCj4+IGFuZCB2ZXJ5IGZldywgaWYgYW55LCB3b3VsZCBtYWtlIHRoZSBpbnRlcnBy ZXRhdGlvbiBvZiBVMS4yLiBTdGF0aW5nDQo+PnRoYXQNCj4+IHRoZSBjaGFydGVyIHN1cHBvcnRz IHlvdXIgY2xhaW0gaXMgSU1ITyBhbiBvdmVyLWludGVycHJldGF0aW9uLg0KPj4NCj4+IFRoZXJl IGFyZSBhbHNvIG90aGVyICJwcm9ibGVtc+KAnSBvZiB0aGUgQ2xpZW50IE93bmVycywgbGlrZSB0 aGUgZXhhbXBsZXMNCj4+SQ0KPj4gbWVudGlvbmVkIGluDQo+PiBodHRwOi8vd3d3LmlldGYub3Jn L21haWwtYXJjaGl2ZS93ZWIvYWNlL2N1cnJlbnQvbXNnMDA5ODkuaHRtbC4gVGhlDQo+PiBhc3N1 bXB0aW9uIHRoYXQgVTEuMiBzaG91bGQgYmUgc29sdmVkIHdpdGggYWNjZXNzIGNvbnRyb2wgcG9s aWNpZXMgKGlmDQo+PiB0aGF0IGlzIGltcGxpZWQpIGlzIGFyYml0cmFyeS4NCj4+DQo+PiBBYm91 dCByZXF1aXJlbWVudCB2cyBwcm9ibGVtOiBJZiBhIGNhbmRpZGF0ZSBzb2x1dGlvbiBkb2VzIG5v dCBzb2x2ZQ0KPj4gcHJvYmxlbSBVMS4xIHRoYXQgaXMgbm90IGFjY2VwdGFibGUuIEhvd2V2ZXIs IHdlIHNob3VsZCBub3QgZGlzY3JpbWluYXRlDQo+PiBzb2x1dGlvbnMgd2hpY2ggZG9lcyBub3Qg c29sdmUgVTEuMiB3aXRoIGFjY2VzcyBjb250cm9sIHBvbGljaWVzLiBJZiB3ZQ0KPj4gaGF2ZSB0 aGlzIGZvcm11bGF0aW9uLCBpdCBzaG91bGQgYmUgbWFkZSBjbGVhciB0aGF0IFUxLjIgaXMgb3B0 aW9uYWwuDQo+DQo+SXQgaXMgbm90IG9wdGlvbmFsIHRvIHNvbHZlIHRoZSBVMS4yIHByb2JsZW0u DQoNCg0KWWVzLCB3ZSBkaXNhZ3JlZSBhYm91dCB0aGlzLiBNeSB2aWV3IGlzIHRoYXQgaXQgbXVz dCBiZSBvcHRpb25hbCB0byBzb2x2ZQ0KdGhlIHByb2JsZW0gb24gdGhlIGNsaWVudCBzaWRlIHdp dGggYWNjZXNzIGNvbnRyb2wgcG9saWNpZXMuIFNlZSByZWNlbnQNCmRpc2N1c3Npb24gd2l0aCBP bGFmLiBBcyBsb25nIGFzIHRoZSDigJxDbGllbnQgT3duZXLigJ0gaXMgZGVmaW5lZCBpbiB0ZXJt cyBvZg0Kc2V0dGluZyBhY2Nlc3MgcmlnaHRzLCBVMS4yIGlzIG9wdGlvbmFsLg0KDQpQbGVhc2Ug bm90ZSB0aGUgZGlzYWdyZWVtZW50IGluIHRoZSBkcmFmdC4NCg0KPkluIHNvbWUgY2FzZXMgDQo+ YXV0aG9yaXphdGlvbiBwcm9ibGVtcyBtaWdodCBiZSBzb2x2ZWQgYnkgaW1wbGljaXQgYXV0aG9y aXphdGlvbi4gV2UgY2FuDQo+cG9pbnQgdGhpcyBvdXQgaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVy YXRpb25zLiBXZSBjYW4gYWRkIHRoZSBmb2xsb3dpbmcNCj50byAzLjI6IEVuZHBvaW50cyBuZWVk IHRvIGJlIGVuYWJsZWQgdG8gZW5mb3JjZSB0aGUgYXV0aG9yaXphdGlvbg0KPnBvbGljaWVzIG9m IHRoZWlyIHByaW5jaXBhbHMuIEluIHNvbWUgY2FzZXMsIGF1dGhvcml6YXRpb24gcHJvYmxlbXMN Cj5taWdodCBiZWkgc29sdmVkIGJ5IGltcGxpY2l0IGF1dGhvcml6YXRpb24gKGFsbCBhdXRoZW50 aWNhdGVkIGVudGl0aWVzDQo+YXJlIGF1dGhvcml6ZWQpLg0KPg0KPg0KPj4NCj4+IFlvdSBzaG91 bGQga2VlcCAic3VjaCBhcyB0aGUgZnJ1aXQgdmVuZG9yIGFuZCBjb250YWluZXIgb3duZXLigJ0g ZXRjLiBpbg0KPj50aGUNCj4+IGZvcm11bGF0aW9uLCBqdXN0IGFzIHlvdSBoYWQgaW4geW91ciBw cmV2aW91cyB2ZXJzaW9uLiBPbmUgbWFqb3IgcG9pbnQNCj4+IHdpdGggdGhlIHByb2JsZW0gZm9y bXVsYXRpb24gaXMgdG8gZXhwbGFpbiB0aGUgdGVybWlub2xvZ3kgaW4gdGVybXMgb2YNCj4+dGhl DQo+PiBhY3RvcnMgb2YgdGhlIHVzZSBjYXNlLg0KPg0KPldlIHdpbGwgbm90IGJlIGFibGUgdG8g ZGVjaWRlIHdoZXRoZXIgYSBmcnVpdCB2ZW5kb3Igd2lsbCBpbiBldmVyeSBjYXNlDQo+YmUgYSBj bGllbnQgb3duZXIgb3IgYSByZXNvdXJjZSBvd25lci4gVG8gbWFrZSB0aGlzIG1vcmUgY2xlYXIs IHdlIGNhbg0KPmFkZCB0aGUgZm9sbG93aW5nIHNlY3Rpb24gdG8gdGhlIGNvbnRhaW5lciB1c2Ug Y2FzZSAoSSB0aGluayB0aGlzIGlzIGENCj51c2VmdWwgZXhlcmNpc2Ugc2luY2UgaXQgc2hvd3Mg dGhlIHZhcmlvdXMgcG9zc2libGUgc2V0dGluZ3MpOg0KPg0KPiMgVmFyaWFudHMNCj4NCj5BcyBt ZW50aW9uZWQgaW4gc2VjdGlvbiAyLCB0aGVyZSBhcmUgdmFyaW91cyByZWFzb25zIGZvciBhc3Np Z25pbmcgYQ0KPmZ1bmN0aW9uIChDb0FQIGNsaWVudCBvciBzZXJ2ZXIpIHRvIGEgZGV2aWNlLiBU aGlzIHNlY3Rpb24gbGlzdHMNCj5wb3NzaWJsZSBzZXR0aW5ncyBmb3IgdGhlIGNvbW11bmljYXRp b24gYmV0d2VlbiBhIHRlbXBlcmF0dXJlIHNlbnNvciBhbmQNCj5hIGZhbiBhY3R1YXRvci4NCj4N Cj4jIyBUZW1wZXJhdHVyZSBTZW5zb3IgYW5kIEZhbiBBY3R1YW9yIFNlcnZlcnMNCj4NCj5UZW1w ZXJhdHVyZSBzZW5zb3JzIGFuZCBmYW4gYWN0dWF0b3JzIGFyZSBzZXJ2ZXJzLCBhbiBhZ2dyZWdh dGlvbiBzZXJ2ZXINCj50aGF0IGJlbG9uZ3MgdG8gdGhlIGNvbnRhaW5lciBvd25lciBpcyB0aGUg Y2xpZW50LiBUaGVyZWZvcmUsIHRoZSBmcnVpdA0KPnZlbmRvciBpcyBhIFJlc291cmNlIE93bmVy LiBUaGUgY29udGFpbmVyIG93bmVyIGlzIGEgUmVzb3VyY2UgT3duZXIgYW5kDQo+YSBDbGllbnQg T3duZXIuDQo+DQo+VGVtcGVyYXR1cmUgc2Vuc29ycyBhcmUgcmVzb3VyY2VzIG9uIGluZGl2aWR1 YWwgQ29BUCBzZXJ2ZXJzIHRoYXQgYmVsb25nDQo+dG8gdGhlIGZydWl0IHZlbmRvci4gVGhlIENv QVAgY2xpZW50IGlzIGFuIGFnZ3JlZ2F0aW9uIHNlcnZlciB0aGF0DQo+cmVxdWVzdHMgdGhlIHRl bXBlcmF0dXJlIHZhbHVlcyBmcm9tIHRoZSBzZXJ2ZXJzIGFuZCBjb21wdXRlcyBhDQo+dGVtcGVy YXR1cmUgc2V0dGluZyBmcm9tIHRoZXNlIHJlc3VsdHMuIFRoZSByZXN1bHQgaXMgdGhlbiB0cmFu c21pdHRlZA0KPnRvIHRoZSB2ZW50aWxhdGlvbiBzeXN0ZW0gb2YgdGhlIGNvbnRhaW5lciBvd25l ci4NCj4NCj4jIyBUZW1wZXJhdHVyZSBTZW5zb3IgYW5kIEZhbiBBY3R1YXRvciBDbGllbnRzDQo+ DQo+VGVtcGVyYXR1cmUgc2Vuc29ycyBhbmQgZmFuIGFjdHVhdG9ycyBhcmUgbG9jYXRlZCBvbiBj bGllbnRzLiBBbg0KPmFnZ3JlZ2F0aW9uIHNlcnZlciB0aGF0IGJlbG9uZ3MgdG8gdGhlIGNvbnRh aW5lciBvd25lciBpcyBhIHNlcnZlci4gVGhlDQo+ZnJ1aXQgdmVuZG9yIGlzIGEgQ2xpZW50IE93 bmVyLiBUaGUgY29udGFpbmVyIG93bmVyIGlzIGEgQ2xpZW50IE93bmVyDQo+YW5kIGEgUmVzb3Vy Y2UgT3duZXIuDQo+DQo+VGhlIGNsaWVudHMgd2l0aCB0aGUgdGVtcGVyYXR1cmUgc2Vuc29ycyBz ZW5kIGEgcmVwcmVzZW50YXRpb24gb2YgdGhlDQo+Y3VycmVudCB0ZW1wZXJhdHVyZSB2YWx1ZXMg dG8gYSByZXNvdXJjZSBvbiB0aGUgYWdncmVnYXRpb24gc2VydmVyDQo+d2hlbmV2ZXIgdGhlIHRl bXBlcmF0dXJlIGNoYW5nZXMuIFRoZSBjbGllbnQgdGhhdCBjb250cm9scyB0aGUgZmFuDQo+YWN0 dWF0b3IgcmVxdWVzdHMgdGhlIGFnZ3JlZ2F0ZWQgdGVtcGVyYXR1cmUgdmFsdWVzIGZyb20gdGhl IGFnZ3JlZ2F0aW9uDQo+c2VydmVyLiBJdCB1c2VzIG9ic2VydmUgdG8gcmVjZWl2ZSByZXNvdXJj ZSByZXByZXNlbnRhdGlvbnMgcGVyaW9kaWNhbGx5Lg0KPg0KPiMjIFRlbXBlcmF0dXJlIFNlbnNv ciBDbGllbnQgYW5kIEZhbiBBY3R1YXRvciBTZXJ2ZXINCj4NCj5UZW1wZXJhdHVyZSBzZW5zb3Jz IGFyZSBsb2NhdGVkIG9uIGEgY2xpZW50LiBUaGUgZmFuIGFjdHVhdG9yIGlzIGxvY2F0ZWQNCj5v biBhIHNlcnZlci4gQW4gYWdncmVnYXRpb24gc2VydmVyIHRoYXQgYmVsb25ncyB0byB0aGUgY29u dGFpbmVyIG93bmVyDQo+YWN0cyBhcyBhIHJlc291cmNlIHNlcnZlciBmb3IgdGhlIHRlbXBlcmF0 dXJlIHNlbnNvciBhbmQgYXMgYSBjbGllbnQgZm9yDQo+dGhlIGZhbiBhY3R1YXRvciBzZXJ2ZXIu DQo+DQo+VGhlIGNsaWVudCB3aXRoIHRoZSB0ZW1wZXJhdHVyZSBzZW5zb3Igc2VuZHMgYSByZXBy ZXNlbnRhdGlvbiBvZiB0aGUNCj5jdXJyZW50IHRlbXBlcmF0dXJlIHZhbHVlcyB0byBhIHJlc291 cmNlIG9uIHRoZSBhZ2dyZWdhdGlvbiBzZXJ2ZXINCj53aGVuZXZlciB0aGUgdGVtcGVyYXR1cmUg Y2hhbmdlcy4gVGhlIGFnZ3JlZ2F0aW9uIHNlcnZlciB0aGVuIGFjdHMgYXMgYQ0KPmNsaWVudCB0 byBzZW5kIHRoZSBhZ2dyZWdhdGVkIHRlbXBlcmF0dXJlIHZhbHVlcyB0byBhIHJlc291cmNlIG9u IHRoZQ0KPmZhbiBhY3R1YXRvciBzZXJ2ZXIuDQo+DQo+IyMgVGVtcGVyYXR1cmUgU2Vuc29yIFNl cnZlciBhbmQgRmFuIEFjdHVhdG9yIENsaWVudCBDb21tdW5pY2F0aW5nDQo+ZGlyZWN0bHkNCj4N Cj5UZW1wZXJhdHVyZSBzZW5zb3JzIGFyZSBsb2NhdGVkIG9uIGEgc2VydmVyLiBUaGUgZmFuIGFj dHVhdG9yIGlzIGxvY2F0ZWQNCj5vbiBhIGNsaWVudC4gVGhlIGZydWl0IHZlbmRvciBpcyBhIHJl c291cmNlIG93bmVyLCB0aGUgY29udGFpbmVyIG93bmVyDQo+aXMgYSBjbGllbnQgb3duZXIuDQo+ DQo+VGhlIGNsaWVudCB3aXRoIHRoZSBmYW4gYWN0dWF0b3IgcmVxdWVzdHMgdGhlIGN1cnJlbnQg c2Vuc29yIHZhbHVlcw0KPmRpcmVjdGx5IGZyb20gdGhlIG5lYXJlc3QgdGVtcGVyYXR1cmUgc2Vu c29yLiBJdCB1c2VzIG9ic2VydmUgdG8gZ2V0DQo+cmVndWxhciB1cGRhdGVzIG9mIHRoZSByZXNv dXJjZSByZXByZXNlbnRhdGlvbi4gVGhlIGZhbiBjYW4gcmVhY3QNCj5kaXJlY3RseSB0byBsb2Nh bCB0ZW1wZXJhdHVyZSBjaGFuZ2VzIGFuZCB0aHVzIGFsbG93cyBmb3IgYW4gb3B0aW1hbA0KPnRl bXBlcmF0dXJlIGF0IGRpZmZlcmVudCBwbGFjZXMgd2l0aGluIGEgY29udGFpbmVyLg0KPg0KPiMj IFRlbXBlcmF0dXJlIFNlbnNvciBDbGllbnQgYW5kIEZhbiBBY3R1YXRvciBTZXJ2ZXIgQ29tbXVu aWNhdGluZw0KPmRpcmVjdGx5DQo+DQo+VGVtcGVyYXR1cmUgc2Vuc29ycyBhcmUgbG9jYXRlZCBv biBhIGNsaWVudC4gVGhlIGZhbiBhY3R1YXRvciBpcyBsb2NhdGVkDQo+b24gYSBzZXJ2ZXIuIFRo ZSBmcnVpdCB2ZW5kb3IgaXMgYSBDbGllbnQgT3duZXIsIHRoZSBjb250YWluZXIgb3duZXIgaXMN Cj5hIFJlc291cmNlIE93bmVyLg0KPg0KPlRoZSBjbGllbnQgd2l0aCB0aGUgdGVtcGVyYXR1cmUg c2Vuc29yIHNlbmRzIGEgcmVwcmVzZW50YXRpb24gb2YgdGhlDQo+Y3VycmVudCB0ZW1wZXJhdHVy ZSB2YWx1ZXMgZGlyZWN0bHkgdG8gYSByZXNvdXJjZSBvbiB0aGUgZmFuIGFjdHVhdG9yDQo+c2Vy dmVyLiBUaGUgZmFuIGNhbiByZWFjdCBkaXJlY3RseSB0byBsb2NhbCB0ZW1wZXJhdHVyZSBjaGFu Z2VzIGFzDQo+ZGVzY3JpYmVkIGFib3ZlLg0KPg0KPg0KPkJlc3QgcmVnYXJkcywNCj5TdGVmZmkN Cg0K From nobody Wed Feb 18 00:26: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 C05721A9105 for ; Wed, 18 Feb 2015 00:26:21 -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 nYChFsfX4tYl for ; Wed, 18 Feb 2015 00:26:20 -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 DE1D61A9115 for ; Wed, 18 Feb 2015 00:26:19 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t1I8QFbQ022824; Wed, 18 Feb 2015 09:26:15 +0100 (CET) Received: from alma.local (eduroam-pool7-0618.wlan.uni-bremen.de [134.102.114.106]) (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 3knBw7532yz2PsY; Wed, 18 Feb 2015 09:26:15 +0100 (CET) Message-ID: <54E44CA6.40000@tzi.org> Date: Wed, 18 Feb 2015 09:26:14 +0100 From: Carsten Bormann User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= , Stefanie Gerdes References: <20150205095841.19111.5154.idtracker@ietfa.amsl.com> <54D341F6.9040109@tzi.de> <54D8D0C5.6030101@tzi.de> <54DB8097.4030206@tzi.de> <54DCB601.3070307@tzi.de> <54DE2721.40304@tzi.de> <54E230D5.8090104@tzi.de> <54E37CFD.9010208@tzi.de> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Variants X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Feb 2015 08:26:21 -0000 On 2015-02-18 09:17, Göran Selander wrote: > Hi Steffi, > > Your last mail make me hesitate whether we will progress beyond the first > use case before Dallas. Indeed, we are wasting a lot of time here. I have only skimmed this discussion, but much of it seems to be "requirements engineering" of the form that we need to avoid: Each participant trying to change the requirements to suit their favorite solution. This is not only wrong, but also misguided: a use case document is not a requirements document. Can we now please finish the use cases? Grüße, Carsten From nobody Wed Feb 18 01:13: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 DBEA91A7023 for ; Wed, 18 Feb 2015 01:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mnxvjt2hqvJ0 for ; Wed, 18 Feb 2015 01:13:50 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ABB11A0397 for ; Wed, 18 Feb 2015 01:13:50 -0800 (PST) Received: from [192.168.131.129] ([80.92.119.127]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lkwc9-1Xo7SA1Al3-00alZW; Wed, 18 Feb 2015 10:13:47 +0100 Message-ID: <54E45744.3050106@gmx.net> Date: Wed, 18 Feb 2015 10:11:32 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Carsten Bormann , =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= , Stefanie Gerdes References: <20150205095841.19111.5154.idtracker@ietfa.amsl.com> <54D341F6.9040109@tzi.de> <54D8D0C5.6030101@tzi.de> <54DB8097.4030206@tzi.de> <54DCB601.3070307@tzi.de> <54DE2721.40304@tzi.de> <54E230D5.8090104@tzi.de> <54E37CFD.9010208@tzi.de> <54E44CA6.40000@tzi.org> In-Reply-To: <54E44CA6.40000@tzi.org> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="F7N7HmwoaLuaftPH7QqEBfmbOT8lIAlfi" X-Provags-ID: V03:K0:eQPZ4rLEjaNaqRmos1tTAt2ZICXWeohCt43Q9P8oQh4hefKVwZZ dC1EY1o1DX1B0btsuvI0aSX+a9RvH9Z3lvStCgkoqZiaYY7SicB5noV5kAzn4cfaMG1Wj6k BRGw5XDMIhoouH7dTz8heNFACTjuhVdLVfKK6AZGmqTdStrPYKx9UhfOsjQlA4OikajXaMO 0uQlJrXDz30SGH40yiKLQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Variants X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Feb 2015 09:13:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --F7N7HmwoaLuaftPH7QqEBfmbOT8lIAlfi Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Carsten, Hi Steffi, G=C3=B6ran, Olaf, I fear it is very difficult to describe scenarios in such a way that they have nothing to-do with the solutions. As such, it is quite natural that the different solution preferences surface as one tries to provide more details and include requirements (*)= =2E I would suggest to acknowledge the limitations of the use case approach and let this issue rest for a little. During this time I hope we can recruit a few other working group participants to review the use case document and to share their views with us on the list. Maybe we get a few additional perspectives on the topic. Ciao Hannes (*): This use case document actually contains requirements. They are labled as 'UX.X' and are contained in the 'Authorization Problems Summary' sections. On 02/18/2015 09:26 AM, Carsten Bormann wrote: > Each participant trying to change the requirements to suit their > favorite solution. >=20 > This is not only wrong, but also misguided: a use case document is not = a > requirements document. >=20 > Can we now please finish the use cases? --F7N7HmwoaLuaftPH7QqEBfmbOT8lIAlfi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU5FdEAAoJEGhJURNOOiAt170H/iy5Zdgvhs1OqIMhMQJ4kzii s3lB84k1TtpkXaI0Cea2VogIHrkDOznzGWNnkHpPEe81c+bBKlbFTHA4qRtULhNb szqPbMZ8LhBUCpkT/jb+PIb7GN+Cgt2Q1Z9rB+GqF+nEhaFdY+NqPHk6YQoCz6Ly fjF36Zr/4Ty/DdgR9Aulf/dzNzONhvmMHbwF7DmEEnHHzRSQt6N6GfIumqSqvplf hW+Jd1pWW3AQ6MAq+gmtUqz6QMp+Oq4MW5CNqEDDsB+1/cPFbnLtqLbxKYIGbMXF G3JG/lLONxKDVElHBW2U1hGgO1IzHlnwet1TjOgifBfkDAak5OmyI/UJJKCkwoI= =joYp -----END PGP SIGNATURE----- --F7N7HmwoaLuaftPH7QqEBfmbOT8lIAlfi-- From nobody Wed Feb 18 01:39:26 2015 Return-Path: <1095318589@qq.com> X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A851A7029 for ; Wed, 18 Feb 2015 01:39:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.78 X-Spam-Level: X-Spam-Status: No, score=-0.78 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJKVEvzy4AoJ for ; Wed, 18 Feb 2015 01:39:18 -0800 (PST) Received: from smtpbgbr1.qq.com (smtpbgbr1.qq.com [54.207.19.206]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35BE81A86F1 for ; Wed, 18 Feb 2015 01:39:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s201307; t=1424252350; bh=TWCG4C/eYdgRiiLrJsOa6Uvp8LZ0LTG18AT5QOp9HTg=; h=X-QQ-mid:X-QQ-mid:X-QQ-SSF:From:To:Cc:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:Date: X-Priority:Message-ID:X-QQ-MIME:X-Mailer:X-QQ-Mailer: X-QQ-SENDSIZE; b=j1fPp0uCw8Pxu+/JVOoFRDDpGhQ2mG/YBnWdw5YpWGjVSSya72vHfpo06lS83hnMF 8Q6d7rDUFCotOUsypvQ1L3OBjrE4zzCLP3guaqNzOrg8TiNPa3FLxeegO3OHKUYepU BGe4ADAMS1w0L+g6KlGWpNtJzWOYI57Rnzq7xZ3E= X-QQ-mid: mb25t1424252348t488531 X-QQ-mid: mb25t1424252348t488531 X-QQ-SSF: 00000000000000F0F8100F00000000M From: "=?utf-8?B?S2VwZW5nIExp?=" <1095318589@qq.com> To: "=?utf-8?B?Z2VyZGVz?=" , "=?utf-8?B?Z29yYW4uc2VsYW5kZXI=?=" Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_54E45DBC_0C34AA90_72E91761" Content-Transfer-Encoding: 8Bit Date: Wed, 18 Feb 2015 17:39:08 +0800 X-Priority: 3 Message-ID: X-QQ-MIME: TCMime 1.0 by Tencent X-Mailer: QQMail 2.x X-QQ-Mailer: QQMail 2.x X-QQ-SENDSIZE: 520 X-QQ-Bgrelay: 1 Archived-At: Cc: =?utf-8?B?QWNl?= Subject: Re: [Ace] Variants (was: Re: Fwd: I-D Action:draft-ietf-ace-usecase X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Feb 2015 09:39:24 -0000 This is a multi-part message in MIME format. ------=_NextPart_54E45DBC_0C34AA90_72E91761 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PsKgSXTCoGlzwqBub3TCoG9wdGlvbmFswqB0b8Kgc29sdmXCoHRoZcKgVTEuMsKgcHJvYmxl bS4NCg0KSXQgc2VlbXMgdGhhdCB0aGlzIGlzIHRoZSBtYWluIGRpc2FncmVlbWVudCBiZXRl d2VlbiBlYWNoIG90aGVyLg0KDQpBcyBIYW5uZXMgbWVudGlvbmVkLCB0aGlzIGlzIGFjdHVh bGx5IGFib3V0IHJlcXVpcmVtZW50cy4NCg0KSW4gbGFzdCBGMkYgbWVldGluZywgdGhlcmUg d2VyZSBzb21lIGNvbW1lbnRzIHRvIHJlbW92ZSByZXF1aXJlbWVudHMgaW4gdGhlIHVzZSBj YXNlIGRvY3VtZW50Lg0KDQpJIHN1Z2dlc3QgdGhhdCB3ZSBkb24ndCB0YWxrIHRvbyBtdWNo IGFib3V0IHJlcXVpcmVtZW50IGF0IHRoaXMgc3RhZ2UuDQoNCktlcGVuZw0KDQoNCi0tLS0t LS0tLS0tLS0tLS0tLSDljp/lp4vpgq7ku7YgLS0tLS0tLS0tLS0tLS0tLS0tDQrlj5Hku7bk uro6ICJTdGVmYW5pZSBHZXJkZXMiIDxnZXJkZXNAdHppLmRlPjsNCuWPkemAgeaXtumXtDog MjAxNeW5tDLmnIgxOOaXpSjmmJ/mnJ/kuIkpIDE6NDANCuaUtuS7tuS6ujogIkfvv73vv71y YW4gU2VsYW5kZXIiIDxnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20+Ow0K5oqE6YCBOiAi QWNlQGlldGYub3JnIiA8QWNlQGlldGYub3JnPjsNCuS4u+mimDogW0FjZV0gVmFyaWFudHMg KHdhczogUmU6IEZ3ZDogSS1EIEFjdGlvbjpkcmFmdC1pZXRmLWFjZS11c2VjYXNlcy0wMi50 eHQpDQoNCg0KDQpIaSBH77+977+9cmFuLA0KDQpPbiAwMi8xNi8yMDE1IDA4OjIxIFBNLCBH 77+977+9cmFuIFNlbGFuZGVyIHdyb3RlOg0KPiBIaSBTdGVmZmksDQo+DQo+IEFib3V0IHRo ZSBDaGFydGVyOiBJZiB5b3UgYXNrIGFib3V0IHBlb3BsZSB3aGF0ICJhdXRob3JpemVkIGFj Y2VzcyB0bw0KPiByZXNvdXJjZXMgaWRlbnRpZmllZCBieSBhIFVSSSBhbmQgaG9zdGVkIG9u IGENCj4gcmVzb3VyY2Ugc2VydmVy4oCdIG1lYW5zLCBJIHRoaW5rIG1hbnkgd291bGQgbWFr ZSB0aGUgaW50ZXJwcmV0YXRpb24gaW4gVTEuMQ0KPiBhbmQgdmVyeSBmZXcsIGlmIGFueSwg d291bGQgbWFrZSB0aGUgaW50ZXJwcmV0YXRpb24gb2YgVTEuMi4gU3RhdGluZyB0aGF0DQo+ IHRoZSBjaGFydGVyIHN1cHBvcnRzIHlvdXIgY2xhaW0gaXMgSU1ITyBhbiBvdmVyLWludGVy cHJldGF0aW9uLg0KPg0KPiBUaGVyZSBhcmUgYWxzbyBvdGhlciAicHJvYmxlbXPigJ0gb2Yg dGhlIENsaWVudCBPd25lcnMsIGxpa2UgdGhlIGV4YW1wbGVzIEkNCj4gbWVudGlvbmVkIGlu DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9hY2UvY3VycmVudC9t c2cwMDk4OS5odG1sLiBUaGUNCj4gYXNzdW1wdGlvbiB0aGF0IFUxLjIgc2hvdWxkIGJlIHNv bHZlZCB3aXRoIGFjY2VzcyBjb250cm9sIHBvbGljaWVzIChpZg0KPiB0aGF0IGlzIGltcGxp ZWQpIGlzIGFyYml0cmFyeS4NCj4NCj4gQWJvdXQgcmVxdWlyZW1lbnQgdnMgcHJvYmxlbTog SWYgYSBjYW5kaWRhdGUgc29sdXRpb24gZG9lcyBub3Qgc29sdmUNCj4gcHJvYmxlbSBVMS4x IHRoYXQgaXMgbm90IGFjY2VwdGFibGUuIEhvd2V2ZXIsIHdlIHNob3VsZCBub3QgZGlzY3Jp bWluYXRlDQo+IHNvbHV0aW9ucyB3aGljaCBkb2VzIG5vdCBzb2x2ZSBVMS4yIHdpdGggYWNj ZXNzIGNvbnRyb2wgcG9saWNpZXMuIElmIHdlDQo+IGhhdmUgdGhpcyBmb3JtdWxhdGlvbiwg aXQgc2hvdWxkIGJlIG1hZGUgY2xlYXIgdGhhdCBVMS4yIGlzIG9wdGlvbmFsLg0KDQpJdCBp cyBub3Qgb3B0aW9uYWwgdG8gc29sdmUgdGhlIFUxLjIgcHJvYmxlbS4gSW4gc29tZSBjYXNl cyANCmF1dGhvcml6YXRpb24gcHJvYmxlbXMgbWlnaHQgYmUgc29sdmVkIGJ5IGltcGxpY2l0 IGF1dGhvcml6YXRpb24uIFdlIGNhbiANCnBvaW50IHRoaXMgb3V0IGluIHRoZSBzZWN1cml0 eSBjb25zaWRlcmF0aW9ucy4gV2UgY2FuIGFkZCB0aGUgZm9sbG93aW5nIA0KdG8gMy4yOiBF bmRwb2ludHMgbmVlZCB0byBiZSBlbmFibGVkIHRvIGVuZm9yY2UgdGhlIGF1dGhvcml6YXRp b24gDQpwb2xpY2llcyBvZiB0aGVpciBwcmluY2lwYWxzLiBJbiBzb21lIGNhc2VzLCBhdXRo b3JpemF0aW9uIHByb2JsZW1zIA0KbWlnaHQgYmVpIHNvbHZlZCBieSBpbXBsaWNpdCBhdXRo b3JpemF0aW9uIChhbGwgYXV0aGVudGljYXRlZCBlbnRpdGllcyANCmFyZSBhdXRob3JpemVk KS4NCg0KDQo+DQo+IFlvdSBzaG91bGQga2VlcCAic3VjaCBhcyB0aGUgZnJ1aXQgdmVuZG9y IGFuZCBjb250YWluZXIgb3duZXLigJ0gZXRjLiBpbiB0aGUNCj4gZm9ybXVsYXRpb24sIGp1 c3QgYXMgeW91IGhhZCBpbiB5b3VyIHByZXZpb3VzIHZlcnNpb24uIE9uZSBtYWpvciBwb2lu dA0KPiB3aXRoIHRoZSBwcm9ibGVtIGZvcm11bGF0aW9uIGlzIHRvIGV4cGxhaW4gdGhlIHRl cm1pbm9sb2d5IGluIHRlcm1zIG9mIHRoZQ0KPiBhY3RvcnMgb2YgdGhlIHVzZSBjYXNlLg0K DQpXZSB3aWxsIG5vdCBiZSBhYmxlIHRvIGRlY2lkZSB3aGV0aGVyIGEgZnJ1aXQgdmVuZG9y IHdpbGwgaW4gZXZlcnkgY2FzZSANCmJlIGEgY2xpZW50IG93bmVyIG9yIGEgcmVzb3VyY2Ug b3duZXIuIFRvIG1ha2UgdGhpcyBtb3JlIGNsZWFyLCB3ZSBjYW4gDQphZGQgdGhlIGZvbGxv d2luZyBzZWN0aW9uIHRvIHRoZSBjb250YWluZXIgdXNlIGNhc2UgKEkgdGhpbmsgdGhpcyBp cyBhIA0KdXNlZnVsIGV4ZXJjaXNlIHNpbmNlIGl0IHNob3dzIHRoZSB2YXJpb3VzIHBvc3Np YmxlIHNldHRpbmdzKToNCg0KIyBWYXJpYW50cw0KDQpBcyBtZW50aW9uZWQgaW4gc2VjdGlv biAyLCB0aGVyZSBhcmUgdmFyaW91cyByZWFzb25zIGZvciBhc3NpZ25pbmcgYSANCmZ1bmN0 aW9uIChDb0FQIGNsaWVudCBvciBzZXJ2ZXIpIHRvIGEgZGV2aWNlLiBUaGlzIHNlY3Rpb24g bGlzdHMgDQpwb3NzaWJsZSBzZXR0aW5ncyBmb3IgdGhlIGNvbW11bmljYXRpb24gYmV0d2Vl biBhIHRlbXBlcmF0dXJlIHNlbnNvciBhbmQgDQphIGZhbiBhY3R1YXRvci4NCg0KIyMgVGVt cGVyYXR1cmUgU2Vuc29yIGFuZCBGYW4gQWN0dWF0b3IgU2VydmVycw0KDQpUZW1wZXJhdHVy ZSBzZW5zb3JzIGFuZCBmYW4gYWN0dWF0b3JzIGFyZSBzZXJ2ZXJzLCBhbiBhZ2dyZWdhdGlv biBzZXJ2ZXIgDQp0aGF0IGJlbG9uZ3MgdG8gdGhlIGNvbnRhaW5lciBvd25lciBpcyB0aGUg Y2xpZW50LiBUaGVyZWZvcmUsIHRoZSBmcnVpdCANCnZlbmRvciBpcyBhIFJlc291cmNlIE93 bmVyLiBUaGUgY29udGFpbmVyIG93bmVyIGlzIGEgUmVzb3VyY2UgT3duZXIgYW5kIA0KYSBD bGllbnQgT3duZXIuDQoNClRlbXBlcmF0dXJlIHNlbnNvcnMgYXJlIHJlc291cmNlcyBvbiBp bmRpdmlkdWFsIENvQVAgc2VydmVycyB0aGF0IGJlbG9uZyANCnRvIHRoZSBmcnVpdCB2ZW5k b3IuIFRoZSBDb0FQIGNsaWVudCBpcyBhbiBhZ2dyZWdhdGlvbiBzZXJ2ZXIgdGhhdCANCnJl cXVlc3RzIHRoZSB0ZW1wZXJhdHVyZSB2YWx1ZXMgZnJvbSB0aGUgc2VydmVycyBhbmQgY29t cHV0ZXMgYSANCnRlbXBlcmF0dXJlIHNldHRpbmcgZnJvbSB0aGVzZSByZXN1bHRzLiBUaGUg cmVzdWx0IGlzIHRoZW4gdHJhbnNtaXR0ZWQgDQp0byB0aGUgdmVudGlsYXRpb24gc3lzdGVt IG9mIHRoZSBjb250YWluZXIgb3duZXIuDQoNCiMjIFRlbXBlcmF0dXJlIFNlbnNvciBhbmQg RmFuIEFjdHVhdG9yIENsaWVudHMNCg0KVGVtcGVyYXR1cmUgc2Vuc29ycyBhbmQgZmFuIGFj dHVhdG9ycyBhcmUgbG9jYXRlZCBvbiBjbGllbnRzLiBBbiANCmFnZ3JlZ2F0aW9uIHNlcnZl ciB0aGF0IGJlbG9uZ3MgdG8gdGhlIGNvbnRhaW5lciBvd25lciBpcyBhIHNlcnZlci4gVGhl IA0KZnJ1aXQgdmVuZG9yIGlzIGEgQ2xpZW50IE93bmVyLiBUaGUgY29udGFpbmVyIG93bmVy IGlzIGEgQ2xpZW50IE93bmVyIA0KYW5kIGEgUmVzb3VyY2UgT3duZXIuDQoNClRoZSBjbGll bnRzIHdpdGggdGhlIHRlbXBlcmF0dXJlIHNlbnNvcnMgc2VuZCBhIHJlcHJlc2VudGF0aW9u IG9mIHRoZSANCmN1cnJlbnQgdGVtcGVyYXR1cmUgdmFsdWVzIHRvIGEgcmVzb3VyY2Ugb24g dGhlIGFnZ3JlZ2F0aW9uIHNlcnZlciANCndoZW5ldmVyIHRoZSB0ZW1wZXJhdHVyZSBjaGFu Z2VzLiBUaGUgY2xpZW50IHRoYXQgY29udHJvbHMgdGhlIGZhbiANCmFjdHVhdG9yIHJlcXVl c3RzIHRoZSBhZ2dyZWdhdGVkIHRlbXBlcmF0dXJlIHZhbHVlcyBmcm9tIHRoZSBhZ2dyZWdh dGlvbiANCnNlcnZlci4gSXQgdXNlcyBvYnNlcnZlIHRvIHJlY2VpdmUgcmVzb3VyY2UgcmVw cmVzZW50YXRpb25zIHBlcmlvZGljYWxseS4NCg0KIyMgVGVtcGVyYXR1cmUgU2Vuc29yIENs aWVudCBhbmQgRmFuIEFjdHVhdG9yIFNlcnZlcg0KDQpUZW1wZXJhdHVyZSBzZW5zb3JzIGFy ZSBsb2NhdGVkIG9uIGEgY2xpZW50LiBUaGUgZmFuIGFjdHVhdG9yIGlzIGxvY2F0ZWQgDQpv biBhIHNlcnZlci4gQW4gYWdncmVnYXRpb24gc2VydmVyIHRoYXQgYmVsb25ncyB0byB0aGUg Y29udGFpbmVyIG93bmVyIA0KYWN0cyBhcyBhIHJlc291cmNlIHNlcnZlciBmb3IgdGhlIHRl bXBlcmF0dXJlIHNlbnNvciBhbmQgYXMgYSBjbGllbnQgZm9yIA0KdGhlIGZhbiBhY3R1YXRv ciBzZXJ2ZXIuDQoNClRoZSBjbGllbnQgd2l0aCB0aGUgdGVtcGVyYXR1cmUgc2Vuc29yIHNl bmRzIGEgcmVwcmVzZW50YXRpb24gb2YgdGhlIA0KY3VycmVudCB0ZW1wZXJhdHVyZSB2YWx1 ZXMgdG8gYSByZXNvdXJjZSBvbiB0aGUgYWdncmVnYXRpb24gc2VydmVyIA0Kd2hlbmV2ZXIg dGhlIHRlbXBlcmF0dXJlIGNoYW5nZXMuIFRoZSBhZ2dyZWdhdGlvbiBzZXJ2ZXIgdGhlbiBh Y3RzIGFzIGEgDQpjbGllbnQgdG8gc2VuZCB0aGUgYWdncmVnYXRlZCB0ZW1wZXJhdHVyZSB2 YWx1ZXMgdG8gYSByZXNvdXJjZSBvbiB0aGUgDQpmYW4gYWN0dWF0b3Igc2VydmVyLg0KDQoj IyBUZW1wZXJhdHVyZSBTZW5zb3IgU2VydmVyIGFuZCBGYW4gQWN0dWF0b3IgQ2xpZW50IENv bW11bmljYXRpbmcgZGlyZWN0bHkNCg0KVGVtcGVyYXR1cmUgc2Vuc29ycyBhcmUgbG9jYXRl ZCBvbiBhIHNlcnZlci4gVGhlIGZhbiBhY3R1YXRvciBpcyBsb2NhdGVkIA0Kb24gYSBjbGll bnQuIFRoZSBmcnVpdCB2ZW5kb3IgaXMgYSByZXNvdXJjZSBvd25lciwgdGhlIGNvbnRhaW5l ciBvd25lciANCmlzIGEgY2xpZW50IG93bmVyLg0KDQpUaGUgY2xpZW50IHdpdGggdGhlIGZh biBhY3R1YXRvciByZXF1ZXN0cyB0aGUgY3VycmVudCBzZW5zb3IgdmFsdWVzIA0KZGlyZWN0 bHkgZnJvbSB0aGUgbmVhcmVzdCB0ZW1wZXJhdHVyZSBzZW5zb3IuIEl0IHVzZXMgb2JzZXJ2 ZSB0byBnZXQgDQpyZWd1bGFyIHVwZGF0ZXMgb2YgdGhlIHJlc291cmNlIHJlcHJlc2VudGF0 aW9uLiBUaGUgZmFuIGNhbiByZWFjdCANCmRpcmVjdGx5IHRvIGxvY2FsIHRlbXBlcmF0dXJl IGNoYW5nZXMgYW5kIHRodXMgYWxsb3dzIGZvciBhbiBvcHRpbWFsIA0KdGVtcGVyYXR1cmUg YXQgZGlmZmVyZW50IHBsYWNlcyB3aXRoaW4gYSBjb250YWluZXIuDQoNCiMjIFRlbXBlcmF0 dXJlIFNlbnNvciBDbGllbnQgYW5kIEZhbiBBY3R1YXRvciBTZXJ2ZXIgQ29tbXVuaWNhdGlu ZyBkaXJlY3RseQ0KDQpUZW1wZXJhdHVyZSBzZW5zb3JzIGFyZSBsb2NhdGVkIG9uIGEgY2xp ZW50LiBUaGUgZmFuIGFjdHVhdG9yIGlzIGxvY2F0ZWQgDQpvbiBhIHNlcnZlci4gVGhlIGZy dWl0IHZlbmRvciBpcyBhIENsaWVudCBPd25lciwgdGhlIGNvbnRhaW5lciBvd25lciBpcyAN CmEgUmVzb3VyY2UgT3duZXIuDQoNClRoZSBjbGllbnQgd2l0aCB0aGUgdGVtcGVyYXR1cmUg c2Vuc29yIHNlbmRzIGEgcmVwcmVzZW50YXRpb24gb2YgdGhlIA0KY3VycmVudCB0ZW1wZXJh dHVyZSB2YWx1ZXMgZGlyZWN0bHkgdG8gYSByZXNvdXJjZSBvbiB0aGUgZmFuIGFjdHVhdG9y IA0Kc2VydmVyLiBUaGUgZmFuIGNhbiByZWFjdCBkaXJlY3RseSB0byBsb2NhbCB0ZW1wZXJh dHVyZSBjaGFuZ2VzIGFzIA0KZGVzY3JpYmVkIGFib3ZlLg0KDQoNCkJlc3QgcmVnYXJkcywN ClN0ZWZmaQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KQWNlIG1haWxpbmcgbGlzdA0KQWNlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZQ== ------=_NextPart_54E45DBC_0C34AA90_72E91761 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 Jmd0O8KgSXTCoGlzwqBub3TCoG9wdGlvbmFswqB0b8Kgc29sdmXCoHRoZcKgVTEuMsKgcHJv YmxlbS48YnI+PGJyPkl0IHNlZW1zIHRoYXQgdGhpcyBpcyB0aGUgbWFpbiBkaXNhZ3JlZW1l bnQgYmV0ZXdlZW4gZWFjaCBvdGhlci48YnI+PGJyPkFzIEhhbm5lcyBtZW50aW9uZWQsIHRo aXMgaXMgYWN0dWFsbHkgYWJvdXQgcmVxdWlyZW1lbnRzLjxicj48YnI+SW4gbGFzdCBGMkYg bWVldGluZywgdGhlcmUgd2VyZSBzb21lIGNvbW1lbnRzIHRvIHJlbW92ZSByZXF1aXJlbWVu dHMgaW4gdGhlIHVzZSBjYXNlIGRvY3VtZW50Ljxicj48YnI+SSBzdWdnZXN0IHRoYXQgd2Ug ZG9uJ3QgdGFsayB0b28gbXVjaCBhYm91dCByZXF1aXJlbWVudCBhdCB0aGlzIHN0YWdlLjxi cj48YnI+S2VwZW5nPGJyPjxici8+PGJyLz4tLS0tLS0tLS0tLS0tLS0tLS0g5Y6f5aeL6YKu 5Lu2IC0tLS0tLS0tLS0tLS0tLS0tLTxici8+PGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB4 OyBiYWNrZ3JvdW5kOiBub25lIHJlcGVhdCBzY3JvbGwgMCUgcmdiKDIzOSwgMjM5LCAyMzkp OyBwYWRkaW5nOiA4cHg7Ij48ZGl2IGlkPSJtZW51X3NlbmRlciI+PGI+5Y+R5Lu25Lq6Ojwv Yj4mbmJzcDsiU3RlZmFuaWUgR2VyZGVzIiAmbHQ7Z2VyZGVzQHR6aS5kZSZndDs7PC9kaXY+ PGRpdj48Yj7lj5HpgIHml7bpl7Q6PC9iPiZuYnNwOzIwMTXlubQy5pyIMTjml6Uo5pif5pyf 5LiJKSAxOjQwPC9kaXY+PGRpdj48Yj7mlLbku7bkuro6PC9iPiZuYnNwOyJH77+977+9cmFu IFNlbGFuZGVyIiAmbHQ7Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tJmd0Ozs8L2Rpdj48 ZGl2PjxiPuaKhOmAgTo8L2I+Jm5ic3A7IkFjZUBpZXRmLm9yZyIgJmx0O0FjZUBpZXRmLm9y ZyZndDs7PC9kaXY+PGRpdj48Yj7kuLvpopg6PC9iPiZuYnNwO1tBY2VdIFZhcmlhbnRzICh3 YXM6IFJlOiBGd2Q6IEktRCBBY3Rpb246ZHJhZnQtaWV0Zi1hY2UtdXNlY2FzZXMtMDIudHh0 KTwvZGl2PjwvZGl2Pjxici8+PGJyLz5IaSBH77+977+9cmFuLDxiciAgLz48YnIgIC8+T24g MDIvMTYvMjAxNSAwODoyMSBQTSwgR++/ve+/vXJhbiBTZWxhbmRlciB3cm90ZTo8YnIgIC8+ Jmd0OyBIaSBTdGVmZmksPGJyICAvPiZndDs8YnIgIC8+Jmd0OyBBYm91dCB0aGUgQ2hhcnRl cjogSWYgeW91IGFzayBhYm91dCBwZW9wbGUgd2hhdCAiYXV0aG9yaXplZCBhY2Nlc3MgdG88 YnIgIC8+Jmd0OyByZXNvdXJjZXMgaWRlbnRpZmllZCBieSBhIFVSSSBhbmQgaG9zdGVkIG9u IGE8YnIgIC8+Jmd0OyByZXNvdXJjZSBzZXJ2ZXLigJ0gbWVhbnMsIEkgdGhpbmsgbWFueSB3 b3VsZCBtYWtlIHRoZSBpbnRlcnByZXRhdGlvbiBpbiBVMS4xPGJyICAvPiZndDsgYW5kIHZl cnkgZmV3LCBpZiBhbnksIHdvdWxkIG1ha2UgdGhlIGludGVycHJldGF0aW9uIG9mIFUxLjIu IFN0YXRpbmcgdGhhdDxiciAgLz4mZ3Q7IHRoZSBjaGFydGVyIHN1cHBvcnRzIHlvdXIgY2xh aW0gaXMgSU1ITyBhbiBvdmVyLWludGVycHJldGF0aW9uLjxiciAgLz4mZ3Q7PGJyICAvPiZn dDsgVGhlcmUgYXJlIGFsc28gb3RoZXIgInByb2JsZW1z4oCdIG9mIHRoZSBDbGllbnQgT3du ZXJzLCBsaWtlIHRoZSBleGFtcGxlcyBJPGJyICAvPiZndDsgbWVudGlvbmVkIGluPGJyICAv PiZndDsgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2FjZS9jdXJyZW50 L21zZzAwOTg5Lmh0bWwuIFRoZTxiciAgLz4mZ3Q7IGFzc3VtcHRpb24gdGhhdCBVMS4yIHNo b3VsZCBiZSBzb2x2ZWQgd2l0aCBhY2Nlc3MgY29udHJvbCBwb2xpY2llcyAoaWY8YnIgIC8+ Jmd0OyB0aGF0IGlzIGltcGxpZWQpIGlzIGFyYml0cmFyeS48YnIgIC8+Jmd0OzxiciAgLz4m Z3Q7IEFib3V0IHJlcXVpcmVtZW50IHZzIHByb2JsZW06IElmIGEgY2FuZGlkYXRlIHNvbHV0 aW9uIGRvZXMgbm90IHNvbHZlPGJyICAvPiZndDsgcHJvYmxlbSBVMS4xIHRoYXQgaXMgbm90 IGFjY2VwdGFibGUuIEhvd2V2ZXIsIHdlIHNob3VsZCBub3QgZGlzY3JpbWluYXRlPGJyICAv PiZndDsgc29sdXRpb25zIHdoaWNoIGRvZXMgbm90IHNvbHZlIFUxLjIgd2l0aCBhY2Nlc3Mg Y29udHJvbCBwb2xpY2llcy4gSWYgd2U8YnIgIC8+Jmd0OyBoYXZlIHRoaXMgZm9ybXVsYXRp b24sIGl0IHNob3VsZCBiZSBtYWRlIGNsZWFyIHRoYXQgVTEuMiBpcyBvcHRpb25hbC48YnIg IC8+PGJyICAvPkl0IGlzIG5vdCBvcHRpb25hbCB0byBzb2x2ZSB0aGUgVTEuMiBwcm9ibGVt LiBJbiBzb21lIGNhc2VzIDxiciAgLz5hdXRob3JpemF0aW9uIHByb2JsZW1zIG1pZ2h0IGJl IHNvbHZlZCBieSBpbXBsaWNpdCBhdXRob3JpemF0aW9uLiBXZSBjYW4gPGJyICAvPnBvaW50 IHRoaXMgb3V0IGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucy4gV2UgY2FuIGFkZCB0 aGUgZm9sbG93aW5nIDxiciAgLz50byAzLjI6IEVuZHBvaW50cyBuZWVkIHRvIGJlIGVuYWJs ZWQgdG8gZW5mb3JjZSB0aGUgYXV0aG9yaXphdGlvbiA8YnIgIC8+cG9saWNpZXMgb2YgdGhl aXIgcHJpbmNpcGFscy4gSW4gc29tZSBjYXNlcywgYXV0aG9yaXphdGlvbiBwcm9ibGVtcyA8 YnIgIC8+bWlnaHQgYmVpIHNvbHZlZCBieSBpbXBsaWNpdCBhdXRob3JpemF0aW9uIChhbGwg YXV0aGVudGljYXRlZCBlbnRpdGllcyA8YnIgIC8+YXJlIGF1dGhvcml6ZWQpLjxiciAgLz48 YnIgIC8+PGJyICAvPiZndDs8YnIgIC8+Jmd0OyBZb3Ugc2hvdWxkIGtlZXAgInN1Y2ggYXMg dGhlIGZydWl0IHZlbmRvciBhbmQgY29udGFpbmVyIG93bmVy4oCdIGV0Yy4gaW4gdGhlPGJy ICAvPiZndDsgZm9ybXVsYXRpb24sIGp1c3QgYXMgeW91IGhhZCBpbiB5b3VyIHByZXZpb3Vz IHZlcnNpb24uIE9uZSBtYWpvciBwb2ludDxiciAgLz4mZ3Q7IHdpdGggdGhlIHByb2JsZW0g Zm9ybXVsYXRpb24gaXMgdG8gZXhwbGFpbiB0aGUgdGVybWlub2xvZ3kgaW4gdGVybXMgb2Yg dGhlPGJyICAvPiZndDsgYWN0b3JzIG9mIHRoZSB1c2UgY2FzZS48YnIgIC8+PGJyICAvPldl IHdpbGwgbm90IGJlIGFibGUgdG8gZGVjaWRlIHdoZXRoZXIgYSBmcnVpdCB2ZW5kb3Igd2ls bCBpbiBldmVyeSBjYXNlIDxiciAgLz5iZSBhIGNsaWVudCBvd25lciBvciBhIHJlc291cmNl IG93bmVyLiBUbyBtYWtlIHRoaXMgbW9yZSBjbGVhciwgd2UgY2FuIDxiciAgLz5hZGQgdGhl IGZvbGxvd2luZyBzZWN0aW9uIHRvIHRoZSBjb250YWluZXIgdXNlIGNhc2UgKEkgdGhpbmsg dGhpcyBpcyBhIDxiciAgLz51c2VmdWwgZXhlcmNpc2Ugc2luY2UgaXQgc2hvd3MgdGhlIHZh cmlvdXMgcG9zc2libGUgc2V0dGluZ3MpOjxiciAgLz48YnIgIC8+IyBWYXJpYW50czxiciAg Lz48YnIgIC8+QXMgbWVudGlvbmVkIGluIHNlY3Rpb24gMiwgdGhlcmUgYXJlIHZhcmlvdXMg cmVhc29ucyBmb3IgYXNzaWduaW5nIGEgPGJyICAvPmZ1bmN0aW9uIChDb0FQIGNsaWVudCBv ciBzZXJ2ZXIpIHRvIGEgZGV2aWNlLiBUaGlzIHNlY3Rpb24gbGlzdHMgPGJyICAvPnBvc3Np YmxlIHNldHRpbmdzIGZvciB0aGUgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIGEgdGVtcGVyYXR1 cmUgc2Vuc29yIGFuZCA8YnIgIC8+YSBmYW4gYWN0dWF0b3IuPGJyICAvPjxiciAgLz4jIyBU ZW1wZXJhdHVyZSBTZW5zb3IgYW5kIEZhbiBBY3R1YXRvciBTZXJ2ZXJzPGJyICAvPjxiciAg Lz5UZW1wZXJhdHVyZSBzZW5zb3JzIGFuZCBmYW4gYWN0dWF0b3JzIGFyZSBzZXJ2ZXJzLCBh biBhZ2dyZWdhdGlvbiBzZXJ2ZXIgPGJyICAvPnRoYXQgYmVsb25ncyB0byB0aGUgY29udGFp bmVyIG93bmVyIGlzIHRoZSBjbGllbnQuIFRoZXJlZm9yZSwgdGhlIGZydWl0IDxiciAgLz52 ZW5kb3IgaXMgYSBSZXNvdXJjZSBPd25lci4gVGhlIGNvbnRhaW5lciBvd25lciBpcyBhIFJl c291cmNlIE93bmVyIGFuZCA8YnIgIC8+YSBDbGllbnQgT3duZXIuPGJyICAvPjxiciAgLz5U ZW1wZXJhdHVyZSBzZW5zb3JzIGFyZSByZXNvdXJjZXMgb24gaW5kaXZpZHVhbCBDb0FQIHNl cnZlcnMgdGhhdCBiZWxvbmcgPGJyICAvPnRvIHRoZSBmcnVpdCB2ZW5kb3IuIFRoZSBDb0FQ IGNsaWVudCBpcyBhbiBhZ2dyZWdhdGlvbiBzZXJ2ZXIgdGhhdCA8YnIgIC8+cmVxdWVzdHMg dGhlIHRlbXBlcmF0dXJlIHZhbHVlcyBmcm9tIHRoZSBzZXJ2ZXJzIGFuZCBjb21wdXRlcyBh IDxiciAgLz50ZW1wZXJhdHVyZSBzZXR0aW5nIGZyb20gdGhlc2UgcmVzdWx0cy4gVGhlIHJl c3VsdCBpcyB0aGVuIHRyYW5zbWl0dGVkIDxiciAgLz50byB0aGUgdmVudGlsYXRpb24gc3lz dGVtIG9mIHRoZSBjb250YWluZXIgb3duZXIuPGJyICAvPjxiciAgLz4jIyBUZW1wZXJhdHVy ZSBTZW5zb3IgYW5kIEZhbiBBY3R1YXRvciBDbGllbnRzPGJyICAvPjxiciAgLz5UZW1wZXJh dHVyZSBzZW5zb3JzIGFuZCBmYW4gYWN0dWF0b3JzIGFyZSBsb2NhdGVkIG9uIGNsaWVudHMu IEFuIDxiciAgLz5hZ2dyZWdhdGlvbiBzZXJ2ZXIgdGhhdCBiZWxvbmdzIHRvIHRoZSBjb250 YWluZXIgb3duZXIgaXMgYSBzZXJ2ZXIuIFRoZSA8YnIgIC8+ZnJ1aXQgdmVuZG9yIGlzIGEg Q2xpZW50IE93bmVyLiBUaGUgY29udGFpbmVyIG93bmVyIGlzIGEgQ2xpZW50IE93bmVyIDxi ciAgLz5hbmQgYSBSZXNvdXJjZSBPd25lci48YnIgIC8+PGJyICAvPlRoZSBjbGllbnRzIHdp dGggdGhlIHRlbXBlcmF0dXJlIHNlbnNvcnMgc2VuZCBhIHJlcHJlc2VudGF0aW9uIG9mIHRo ZSA8YnIgIC8+Y3VycmVudCB0ZW1wZXJhdHVyZSB2YWx1ZXMgdG8gYSByZXNvdXJjZSBvbiB0 aGUgYWdncmVnYXRpb24gc2VydmVyIDxiciAgLz53aGVuZXZlciB0aGUgdGVtcGVyYXR1cmUg Y2hhbmdlcy4gVGhlIGNsaWVudCB0aGF0IGNvbnRyb2xzIHRoZSBmYW4gPGJyICAvPmFjdHVh dG9yIHJlcXVlc3RzIHRoZSBhZ2dyZWdhdGVkIHRlbXBlcmF0dXJlIHZhbHVlcyBmcm9tIHRo ZSBhZ2dyZWdhdGlvbiA8YnIgIC8+c2VydmVyLiBJdCB1c2VzIG9ic2VydmUgdG8gcmVjZWl2 ZSByZXNvdXJjZSByZXByZXNlbnRhdGlvbnMgcGVyaW9kaWNhbGx5LjxiciAgLz48YnIgIC8+ IyMgVGVtcGVyYXR1cmUgU2Vuc29yIENsaWVudCBhbmQgRmFuIEFjdHVhdG9yIFNlcnZlcjxi ciAgLz48YnIgIC8+VGVtcGVyYXR1cmUgc2Vuc29ycyBhcmUgbG9jYXRlZCBvbiBhIGNsaWVu dC4gVGhlIGZhbiBhY3R1YXRvciBpcyBsb2NhdGVkIDxiciAgLz5vbiBhIHNlcnZlci4gQW4g YWdncmVnYXRpb24gc2VydmVyIHRoYXQgYmVsb25ncyB0byB0aGUgY29udGFpbmVyIG93bmVy IDxiciAgLz5hY3RzIGFzIGEgcmVzb3VyY2Ugc2VydmVyIGZvciB0aGUgdGVtcGVyYXR1cmUg c2Vuc29yIGFuZCBhcyBhIGNsaWVudCBmb3IgPGJyICAvPnRoZSBmYW4gYWN0dWF0b3Igc2Vy dmVyLjxiciAgLz48YnIgIC8+VGhlIGNsaWVudCB3aXRoIHRoZSB0ZW1wZXJhdHVyZSBzZW5z b3Igc2VuZHMgYSByZXByZXNlbnRhdGlvbiBvZiB0aGUgPGJyICAvPmN1cnJlbnQgdGVtcGVy YXR1cmUgdmFsdWVzIHRvIGEgcmVzb3VyY2Ugb24gdGhlIGFnZ3JlZ2F0aW9uIHNlcnZlciA8 YnIgIC8+d2hlbmV2ZXIgdGhlIHRlbXBlcmF0dXJlIGNoYW5nZXMuIFRoZSBhZ2dyZWdhdGlv biBzZXJ2ZXIgdGhlbiBhY3RzIGFzIGEgPGJyICAvPmNsaWVudCB0byBzZW5kIHRoZSBhZ2dy ZWdhdGVkIHRlbXBlcmF0dXJlIHZhbHVlcyB0byBhIHJlc291cmNlIG9uIHRoZSA8YnIgIC8+ ZmFuIGFjdHVhdG9yIHNlcnZlci48YnIgIC8+PGJyICAvPiMjIFRlbXBlcmF0dXJlIFNlbnNv ciBTZXJ2ZXIgYW5kIEZhbiBBY3R1YXRvciBDbGllbnQgQ29tbXVuaWNhdGluZyBkaXJlY3Rs eTxiciAgLz48YnIgIC8+VGVtcGVyYXR1cmUgc2Vuc29ycyBhcmUgbG9jYXRlZCBvbiBhIHNl cnZlci4gVGhlIGZhbiBhY3R1YXRvciBpcyBsb2NhdGVkIDxiciAgLz5vbiBhIGNsaWVudC4g VGhlIGZydWl0IHZlbmRvciBpcyBhIHJlc291cmNlIG93bmVyLCB0aGUgY29udGFpbmVyIG93 bmVyIDxiciAgLz5pcyBhIGNsaWVudCBvd25lci48YnIgIC8+PGJyICAvPlRoZSBjbGllbnQg d2l0aCB0aGUgZmFuIGFjdHVhdG9yIHJlcXVlc3RzIHRoZSBjdXJyZW50IHNlbnNvciB2YWx1 ZXMgPGJyICAvPmRpcmVjdGx5IGZyb20gdGhlIG5lYXJlc3QgdGVtcGVyYXR1cmUgc2Vuc29y LiBJdCB1c2VzIG9ic2VydmUgdG8gZ2V0IDxiciAgLz5yZWd1bGFyIHVwZGF0ZXMgb2YgdGhl IHJlc291cmNlIHJlcHJlc2VudGF0aW9uLiBUaGUgZmFuIGNhbiByZWFjdCA8YnIgIC8+ZGly ZWN0bHkgdG8gbG9jYWwgdGVtcGVyYXR1cmUgY2hhbmdlcyBhbmQgdGh1cyBhbGxvd3MgZm9y IGFuIG9wdGltYWwgPGJyICAvPnRlbXBlcmF0dXJlIGF0IGRpZmZlcmVudCBwbGFjZXMgd2l0 aGluIGEgY29udGFpbmVyLjxiciAgLz48YnIgIC8+IyMgVGVtcGVyYXR1cmUgU2Vuc29yIENs aWVudCBhbmQgRmFuIEFjdHVhdG9yIFNlcnZlciBDb21tdW5pY2F0aW5nIGRpcmVjdGx5PGJy ICAvPjxiciAgLz5UZW1wZXJhdHVyZSBzZW5zb3JzIGFyZSBsb2NhdGVkIG9uIGEgY2xpZW50 LiBUaGUgZmFuIGFjdHVhdG9yIGlzIGxvY2F0ZWQgPGJyICAvPm9uIGEgc2VydmVyLiBUaGUg ZnJ1aXQgdmVuZG9yIGlzIGEgQ2xpZW50IE93bmVyLCB0aGUgY29udGFpbmVyIG93bmVyIGlz IDxiciAgLz5hIFJlc291cmNlIE93bmVyLjxiciAgLz48YnIgIC8+VGhlIGNsaWVudCB3aXRo IHRoZSB0ZW1wZXJhdHVyZSBzZW5zb3Igc2VuZHMgYSByZXByZXNlbnRhdGlvbiBvZiB0aGUg PGJyICAvPmN1cnJlbnQgdGVtcGVyYXR1cmUgdmFsdWVzIGRpcmVjdGx5IHRvIGEgcmVzb3Vy Y2Ugb24gdGhlIGZhbiBhY3R1YXRvciA8YnIgIC8+c2VydmVyLiBUaGUgZmFuIGNhbiByZWFj dCBkaXJlY3RseSB0byBsb2NhbCB0ZW1wZXJhdHVyZSBjaGFuZ2VzIGFzIDxiciAgLz5kZXNj cmliZWQgYWJvdmUuPGJyICAvPjxiciAgLz48YnIgIC8+QmVzdCByZWdhcmRzLDxiciAgLz5T dGVmZmk8YnIgIC8+PGJyICAvPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyICAvPkFjZSBtYWlsaW5nIGxpc3Q8YnIgIC8+QWNlQGlldGYub3Jn PGJyICAvPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlPGJyICAv Pg== ------=_NextPart_54E45DBC_0C34AA90_72E91761-- From nobody Wed Feb 18 01:48: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 D209E1A8546 for ; Wed, 18 Feb 2015 01:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WULOU2eLFltW for ; Wed, 18 Feb 2015 01:48:48 -0800 (PST) Received: from outbox.sics.se (outbox.sics.se [193.10.64.137]) by ietfa.amsl.com (Postfix) with ESMTP id 4933F1A702C for ; Wed, 18 Feb 2015 01:48:48 -0800 (PST) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [192.36.171.201]) by outbox.sics.se (Postfix) with ESMTPS id E5118174 for ; Wed, 18 Feb 2015 10:48:40 +0100 (CET) Received: from norm.sics.se (norm.sics.se [193.10.64.192]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id t1I9me1F031551 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 18 Feb 2015 10:48:40 +0100 Received: from [192.168.0.108] (unknown [85.235.11.178]) by norm.sics.se (Postfix) with ESMTPSA id 384C88D for ; Wed, 18 Feb 2015 10:48:40 +0100 (CET) Message-ID: <54E45FE4.4040800@sics.se> Date: Wed, 18 Feb 2015 10:48:20 +0100 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: ace@ietf.org References: <20150205095841.19111.5154.idtracker@ietfa.amsl.com> <54D341F6.9040109@tzi.de> <54D8D0C5.6030101@tzi.de> <54DB8097.4030206@tzi.de> <54DCB601.3070307@tzi.de> <54DE2721.40304@tzi.de> <54E230D5.8090104@tzi.de> <54E37CFD.9010208@tzi.de> <54E44CA6.40000@tzi.org> <54E45744.3050106@gmx.net> In-Reply-To: <54E45744.3050106@gmx.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060008090600050107080004" X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sics-se:default, sics-se:default, base:default, @@RPTN) X-p0f-Info: os=Linux 2.2.x-3.x, link=Ethernet or modem X-CanIt-Geo: =?UTF-8?Q?ip=3D85.235.11.178; _country=3DSE; _region=3DSk=C3=A5ne; _city=3DLund; _latitude=3D55.7028; _longitude=3D13.1927; _http://maps.google.com/maps=3Fq=3D55.7028,13.1927&z=3D6?= X-CanItPRO-Stream: outbound-sics-se:outbound (inherits from outbound-sics-se:default, sics-se:default, base:default) X-Canit-Stats-ID: 09NRJMEp4 - 6b5403e68df2 - 20150218 X-Antispam-Training-Forget: https://canit.sunet.se/canit/b.php?i=09NRJMEp4&m=6b5403e68df2&t=20150218&c=f X-Antispam-Training-Nonspam: https://canit.sunet.se/canit/b.php?i=09NRJMEp4&m=6b5403e68df2&t=20150218&c=n X-Antispam-Training-Spam: https://canit.sunet.se/canit/b.php?i=09NRJMEp4&m=6b5403e68df2&t=20150218&c=s X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 85.235.11.178 is neither permitted nor denied by domain ludwig@sics.se) receiver=e-mailfilter01.sunet.se; client-ip=85.235.11.178; envelope-from=; helo=norm.sics.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: Subject: Re: [Ace] Variants X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Feb 2015 09:48:52 -0000 This is a cryptographically signed message in MIME format. --------------ms060008090600050107080004 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 02/18/2015 10:11 AM, Hannes Tschofenig wrote: > Hi Carsten, Hi Steffi, G=F6ran, Olaf, > =2E.. > I would suggest to acknowledge the limitations of the use case approach= > and let this issue rest for a little. During this time I hope we can > recruit a few other working group participants to review the use case > document and to share their views with us on the list. Maybe we get a > few additional perspectives on the topic. > > Ciao > Hannes > Getting additional perspectives would indeed help resolving this situatio= n. /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 --------------ms060008090600050107080004 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVDCC BhgwggUAoAMCAQICAwyGmDANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTE1MDEwODA4MzkwNloXDTE2MDEwOTIyNDEzMFowODEXMBUGA1UE AwwObHVkd2lnQHNpY3Muc2UxHTAbBgkqhkiG9w0BCQEWDmx1ZHdpZ0BzaWNzLnNlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxUHisC6rgXFsBHHBGo8ulz/cLX3gX5Ufhcwo rp+7djzMMuKPM1KOHq0bjWhmFe8ly8CzWdk2NS600t7IEBQWJiHLsdc12UqmNswQUpD7oqkR 1nRGT6leAHYTWapkR+nczZ2NxD+H7u4ZWVIZg0DFiTqtY8ghYHHYYy8BBoc/jHG78X4+JJAg s5XOa0gVl7W38vDvVpo14xhWEBGjzPk9WxWirqAF66PF+JEu2JD9LzFbpEq829SRXJMFB9wp oQNlH0UQ01/2sWCIBxPpHuEjxEF/V3Z/F2VsNTy4zvYrd+/MYO3w30F+bWQNZsMHEkTW1pEh iz7rQPWTBXoO8Fv0wQIDAQABo4IC1DCCAtAwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTqvKspqEm0E4R1sgsABYKk 6xDJqDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZBgNVHREEEjAQgQ5sdWR3 aWdAc2ljcy5zZTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcC AjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0 aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5 aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQEFBQADggEBAGXwFsbSfv4mMWqIk64CoxuR6ozo7J37igca7d9tpKIzVIp6xp7Zt+a+J9X3 1r4zgMRFnZJWQ5hy82W/fVDeG9i3NGMM6p7DNUrGjTbVHd11BQtbUOG9MSlyWKQbmt3Q1ElC f4SRLAQot5SPryLR2FTxQuFkMOrcDzVxNxnMgatOM2fAO8KS0H+wX+I7gC3pEnbg/eMqNgU+ Ktbc2y9naDNmLNLN65s8TT9xZyoQEn9S1oU8Xnh596OMu49Eccws8Ny+vAGESIHG4bqhMSjj rmDilL1Wj9nQahmBnID5oZD5g9s9KyqxiZIGNnowYYOpCrSeITZ1b7wg50dC8ySojnYwggY0 MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEw MjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0d Lep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiU fsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5Dp IpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuC YKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/ MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0j BBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzAB hhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nm c2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9 eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukD FUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyi kfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8Cnykh ExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b 970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCD z+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqA SfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNb BIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBth HSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+ UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAwyGmDAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTAyMTgwOTQ4MjBaMCMGCSqGSIb3DQEJBDEW BBSi5YrKb9BSAXmZ73LKQ6iesMTzaDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDDIaYMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJKoZIhvcNAQEBBQAE ggEAfEnZgOGi4AD1ZKWO9OllDIofKY969AfQndXvuuqLiSJjn24R+XxEYKT0GK6QLuW4wUfE /sT3gv+Mn9GbHoYGTQXa+RiptgSJ017NqXKf4c10afdoD47DxNTPw+PLEs38ngFLt5EiNWyO DOgzxw6Fr16B4w/1AZqTx6327x55giFYotmPJtZUTw1nQuoUsMFXWcSN6qHQC07E6stDjyTF SYFy0eZqj4zfoYzej/5xVHOaH8+uVhj565fQnC8NwU5eCbcK9sYGk9h9k5uSvJkD5cc6rUxL t8Fh9ZgNpPEuU0K4hY27c54TSpac5XVEGZLdGntBneh44Gchpngv0m7/ggAAAAAAAA== --------------ms060008090600050107080004-- From nobody Wed Feb 18 02:39: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 F375C1A9123 for ; Wed, 18 Feb 2015 02:39:26 -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 x8YZnS7TlBCR for ; Wed, 18 Feb 2015 02:39:25 -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 0F7D61A9122 for ; Wed, 18 Feb 2015 02:39:24 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-42-54e46bdb91ac Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B9.ED.24955.BDB64E45; Wed, 18 Feb 2015 11:39:23 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.27]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0210.002; Wed, 18 Feb 2015 11:39:22 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Hannes Tschofenig , Carsten Bormann , Kepeng Li Thread-Topic: [Ace] Variants Thread-Index: AQHQS1SRv5sT5XMb5EiUB7uGMGCZY5z2DlkAgAApT4A= Date: Wed, 18 Feb 2015 10:39:22 +0000 Message-ID: References: <20150205095841.19111.5154.idtracker@ietfa.amsl.com> <54D341F6.9040109@tzi.de> <54D8D0C5.6030101@tzi.de> <54DB8097.4030206@tzi.de> <54DCB601.3070307@tzi.de> <54DE2721.40304@tzi.de> <54E230D5.8090104@tzi.de> <54E37CFD.9010208@tzi.de> <54E44CA6.40000@tzi.org> <54E45744.3050106@gmx.net> In-Reply-To: <54E45744.3050106@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.16] Content-Type: text/plain; charset="utf-8" Content-ID: <8715DB237DFB164BAC010E6E84FBA2EF@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNIsWRmVeSWpSXmKPExsUyM+Jvje7t7CchBnduCVt8/9bDbHFkyl1W i40X7zJaLN15j9Xi8vwiB1aPiW8/sngs3rSfzWPJkp9MHtvefmX2mLYoM4A1issmJTUnsyy1 SN8ugStj2Z7LLAU/hCru/f3E3MC4Q6iLkZNDQsBE4uiqm2wQtpjEhXvrgWwuDiGBI4wSc34f YoRwFjNK/Om9xgxSxSbgIvGg4RFTFyMHh4hAtcT7ZkaQMLOAk8SLp79ZQcLCAtISi26FgYRF BGQkjrxtZ4GwrSS+bTkDtotFQFVi6vVuVhCbV8BCYvKnY1CrPrNI/PjexwSS4BRQl7h48TlY AyPQcd9PrWGC2CUucevJfCaIowUkluw5zwxhi0q8fPwPbKiogJ7EyutNUI8pSuw8284Mchuz gKbE+l36EGOsJW5/uwp1vqLElO6H7BD3CEqcnPmEZQKjxCwk22YhdM9C0j0LSfcsJN0LGFlX MYoWpxYn5aYbGeulFmUmFxfn5+nlpZZsYgTG7sEtv1V3MF5+43iIUYCDUYmHt8DiSYgQa2JZ cWXuIUZpDhYlcV4740MhQgLpiSWp2ampBalF8UWlOanFhxiZODilGhjdjkXrlj+qWBz5QDgk PsXFf8lLD+urG0616X+ds5ZRe8OunScTF03bdj/43jOT+6+an2uqT1+t5lgYPlP5dE70up9h HHbhk/ZPcT789+kNn9D+0J97Qha5Vk7k0vH1YXnz86XXJ+sE6UuL3j+uUvFnn8lg9tTHoOO0 kcjdhMZ9W9guBC3W0dupxFKckWioxVxUnAgAWCj52r4CAAA= Archived-At: Cc: Stefanie Gerdes , "Ace@ietf.org" Subject: Re: [Ace] Variants X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Feb 2015 10:39:27 -0000 DQpIaSBDYXJzdGVuLCBIYW5uZXMsIEtlcGVuZw0KDQpJ4oCZbSBmaW5lIHdpdGggbGV0dGluZyB0 aGlzIHJlc3QgZm9yIGEgd2hpbGUsIGJ1dCBhcyBDYXJzdGVuIG5vdGVkLCB0aGUNCmN1cnJlbnQg dmVyc2lvbiBvZiB0aGUgZHJhZnQgaXMgcHJvbW90aW5nIHRoZSBzb2x1dGlvbiBwcm9wb3NlZCBi eSBvbmUgb2YNCnRoZSBlZGl0b3JzIG9mIHRoZSBkcmFmdCwgYW5kIGlzIG5vdCByZXByZXNlbnRp bmcgdGhlIHZpZXdzIG9mIGFsbA0KYXV0aG9ycy4gSXQgd291bGQgYmUgZ29vZCBpZiB0aGUgRGFs bGFzLXZlcnNpb24gb2YgdGhlIGRyYWZ0IGNvbnRhaW5lZA0Kc29tZSBpbmZvcm1hdGlvbiBtYWtp bmcgdGhpcyBjbGVhciwgZWl0aGVyIGluIGVhY2ggc2VjdGlvbiBpbmRpY2F0aW5nDQp3aGljaCB0 ZXJtcyBhbmQgcmVxdWlyZW1lbnRzIGFyZSBpbiBkaXNjdXNzaW9uIChhcyBwcm9wb3NlZCBpbiB0 aGUNCnByZXZpb3VzIHRocmVhZCksIG9yIGEgc2VwYXJhdGUgc2VjdGlvbiBvdXRsaW5pbmcgdGhl IGRpc2FncmVlbWVudC4NCg0KQmVzdCByZWdhcmRzLA0KR8O2cmFuDQoNCg0KT24gMjAxNS0wMi0x OCAxMDoxMSwgIkhhbm5lcyBUc2Nob2ZlbmlnIiA8aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4g d3JvdGU6DQoNCj5IaSBDYXJzdGVuLCBIaSBTdGVmZmksIEfDtnJhbiwgT2xhZiwNCj4NCj5JIGZl YXIgaXQgaXMgdmVyeSBkaWZmaWN1bHQgdG8gZGVzY3JpYmUgc2NlbmFyaW9zIGluIHN1Y2ggYSB3 YXkgdGhhdA0KPnRoZXkgaGF2ZSBub3RoaW5nIHRvLWRvIHdpdGggdGhlIHNvbHV0aW9ucy4NCj4N Cj5BcyBzdWNoLCBpdCBpcyBxdWl0ZSBuYXR1cmFsIHRoYXQgdGhlIGRpZmZlcmVudCBzb2x1dGlv biBwcmVmZXJlbmNlcw0KPnN1cmZhY2UgYXMgb25lIHRyaWVzIHRvIHByb3ZpZGUgbW9yZSBkZXRh aWxzIGFuZCBpbmNsdWRlIHJlcXVpcmVtZW50cyAoKikuDQo+DQo+SSB3b3VsZCBzdWdnZXN0IHRv IGFja25vd2xlZGdlIHRoZSBsaW1pdGF0aW9ucyBvZiB0aGUgdXNlIGNhc2UgYXBwcm9hY2gNCj5h bmQgbGV0IHRoaXMgaXNzdWUgcmVzdCBmb3IgYSBsaXR0bGUuIER1cmluZyB0aGlzIHRpbWUgSSBo b3BlIHdlIGNhbg0KPnJlY3J1aXQgYSBmZXcgb3RoZXIgd29ya2luZyBncm91cCBwYXJ0aWNpcGFu dHMgdG8gcmV2aWV3IHRoZSB1c2UgY2FzZQ0KPmRvY3VtZW50IGFuZCB0byBzaGFyZSB0aGVpciB2 aWV3cyB3aXRoIHVzIG9uIHRoZSBsaXN0LiBNYXliZSB3ZSBnZXQgYQ0KPmZldyBhZGRpdGlvbmFs IHBlcnNwZWN0aXZlcyBvbiB0aGUgdG9waWMuDQo+DQo+Q2lhbw0KPkhhbm5lcw0KPg0KPigqKTog VGhpcyB1c2UgY2FzZSBkb2N1bWVudCBhY3R1YWxseSBjb250YWlucyByZXF1aXJlbWVudHMuIFRo ZXkgYXJlDQo+bGFibGVkIGFzICdVWC5YJyBhbmQgYXJlIGNvbnRhaW5lZCBpbiB0aGUgJ0F1dGhv cml6YXRpb24gUHJvYmxlbXMNCj5TdW1tYXJ5JyBzZWN0aW9ucy4NCj4NCj5PbiAwMi8xOC8yMDE1 IDA5OjI2IEFNLCBDYXJzdGVuIEJvcm1hbm4gd3JvdGU6DQo+PiBFYWNoIHBhcnRpY2lwYW50IHRy eWluZyB0byBjaGFuZ2UgdGhlIHJlcXVpcmVtZW50cyB0byBzdWl0IHRoZWlyDQo+PiBmYXZvcml0 ZSBzb2x1dGlvbi4NCj4+IA0KPj4gVGhpcyBpcyBub3Qgb25seSB3cm9uZywgYnV0IGFsc28gbWlz Z3VpZGVkOiBhIHVzZSBjYXNlIGRvY3VtZW50IGlzIG5vdCBhDQo+PiByZXF1aXJlbWVudHMgZG9j dW1lbnQuDQo+PiANCj4+IENhbiB3ZSBub3cgcGxlYXNlIGZpbmlzaCB0aGUgdXNlIGNhc2VzPw0K DQo= From nobody Wed Feb 18 02:52: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 E3B8B1A9122 for ; Wed, 18 Feb 2015 02:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rwd6URppu3dY for ; Wed, 18 Feb 2015 02:52:49 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1A561A911E for ; Wed, 18 Feb 2015 02:52:48 -0800 (PST) Received: from [192.168.131.129] ([80.92.119.127]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LoVvG-1Xw88y1nr8-00gWrz; Wed, 18 Feb 2015 11:52:38 +0100 Message-ID: <54E46EE7.8010604@gmx.net> Date: Wed, 18 Feb 2015 11:52:23 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= , Carsten Bormann , Kepeng Li References: <20150205095841.19111.5154.idtracker@ietfa.amsl.com> <54D341F6.9040109@tzi.de> <54D8D0C5.6030101@tzi.de> <54DB8097.4030206@tzi.de> <54DCB601.3070307@tzi.de> <54DE2721.40304@tzi.de> <54E230D5.8090104@tzi.de> <54E37CFD.9010208@tzi.de> <54E44CA6.40000@tzi.org> <54E45744.3050106@gmx.net> In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HU7kTiGCaimcEpOAp30i0X0gvcLAgbLA9" X-Provags-ID: V03:K0:wVs0gBauoeawa+VRyA7HbzHMCC2CGolEaVBwhW4l6KoWjMNwFOQ hCab0tcFxmcTe44+WN4wfyWIJUlocsQqe9ZCDTPSGZf+mmeisEP2hf+HDpaywyGPlTSYHgB 57i49jcCpP+r8GnUQFXHuLl6O8jlakPv2Yd8XijoQPkAoUsCbk54BuL0SXyKejCB+5kMQbI JC3AzaX2Ntb3/eruvn5rA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: Stefanie Gerdes , "Ace@ietf.org" Subject: Re: [Ace] Variants X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Feb 2015 10:52:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HU7kTiGCaimcEpOAp30i0X0gvcLAgbLA9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I am fully aware of this, G=C3=B6ran. We just solicit more fedback from the rest of the group and then change the text accordingly. So, there will be a new version before the Dallas meeting submission deadline. Ciao Hannes On 02/18/2015 11:39 AM, G=C3=B6ran Selander wrote: >=20 > Hi Carsten, Hannes, Kepeng >=20 > I=E2=80=99m fine with letting this rest for a while, but as Carsten not= ed, the > current version of the draft is promoting the solution proposed by one = of > the editors of the draft, and is not representing the views of all > authors. It would be good if the Dallas-version of the draft contained > some information making this clear, either in each section indicating > which terms and requirements are in discussion (as proposed in the > previous thread), or a separate section outlining the disagreement. >=20 > Best regards, > G=C3=B6ran >=20 >=20 > On 2015-02-18 10:11, "Hannes Tschofenig" wr= ote: >=20 >> Hi Carsten, Hi Steffi, G=C3=B6ran, Olaf, >> >> I fear it is very difficult to describe scenarios in such a way that >> they have nothing to-do with the solutions. >> >> As such, it is quite natural that the different solution preferences >> surface as one tries to provide more details and include requirements = (*). >> >> I would suggest to acknowledge the limitations of the use case approac= h >> and let this issue rest for a little. During this time I hope we can >> recruit a few other working group participants to review the use case >> document and to share their views with us on the list. Maybe we get a >> few additional perspectives on the topic. >> >> Ciao >> Hannes >> >> (*): This use case document actually contains requirements. They are >> labled as 'UX.X' and are contained in the 'Authorization Problems >> Summary' sections. >> >> On 02/18/2015 09:26 AM, Carsten Bormann wrote: >>> Each participant trying to change the requirements to suit their >>> favorite solution. >>> >>> This is not only wrong, but also misguided: a use case document is no= t a >>> requirements document. >>> >>> Can we now please finish the use cases? >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --HU7kTiGCaimcEpOAp30i0X0gvcLAgbLA9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU5G7nAAoJEGhJURNOOiAtJw8H/iIHXDFV4A1rGAKV5+rf62tF AtdAuYTB87s+Q5G/Ftx8vA6ATPh93E6YwHYIUKGsbys58B7XeZW5W79bpt8pQnuU vN0QdkxQPMeWAhRcCSClfnZpAcip3P85Ztuno9wTnCazQBFR6JKYSaHp7Q3FtDJ4 q02C0VUlWaFj/hooyBBParqsVw79MfgobglUpuFZFBfcjiGOA34V8xfidItgp2IO chZAGLik0fv+D2qYxHFDngxdQEmmarJ8JFO8cH+K5BIiBVFn1gf4nF6/v9ZSvCvO fCxo0vnXRkWlJwyzVjKYLPVhc1HN2J4sOFM+ig7YZQGaLY4IPNmruYHbAosWoZ8= =C4UA -----END PGP SIGNATURE----- --HU7kTiGCaimcEpOAp30i0X0gvcLAgbLA9-- From nobody Wed Feb 18 03: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 07AE21A911F for ; Wed, 18 Feb 2015 03:06:06 -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 tQ7NpjjV2_my for ; Wed, 18 Feb 2015 03:06:04 -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 414761A1A96 for ; Wed, 18 Feb 2015 03:06:04 -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 t1IB5sF0001772; Wed, 18 Feb 2015 12:05:54 +0100 (CET) Received: from aung.tzi.org (unknown [IPv6:2001:638:708:30da:b891:9d56:d6e8:508a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3knGSL1ZfBz2QNM; Wed, 18 Feb 2015 12:05:54 +0100 (CET) From: Olaf Bergmann To: Hannes Tschofenig References: <20150205095841.19111.5154.idtracker@ietfa.amsl.com> <54D341F6.9040109@tzi.de> <54D8D0C5.6030101@tzi.de> <54DB8097.4030206@tzi.de> <54DCB601.3070307@tzi.de> <54DE2721.40304@tzi.de> <54E230D5.8090104@tzi.de> <54E37CFD.9010208@tzi.de> <54E44CA6.40000@tzi.org> <54E45744.3050106@gmx.net> <54E46EE7.8010604@gmx.net> Date: Wed, 18 Feb 2015 12:05:53 +0100 In-Reply-To: <54E46EE7.8010604@gmx.net> (Hannes Tschofenig's message of "Wed, 18 Feb 2015 11:52:23 +0100") Message-ID: <87oaorjx7y.fsf@tzi.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Stefanie Gerdes , Carsten Bormann , =?utf-8?Q?G=C3=B6ran?= Selander , "Ace@ietf.org" , Kepeng Li Subject: Re: [Ace] Variants X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Feb 2015 11:06:06 -0000 Hannes Tschofenig writes: > I am fully aware of this, G=C3=B6ran. I do not think so. As Steffi with a patience of a saint tries to explain is that the current text intentionally avoids any spin into a particular direction. Removing the description of existing problems means promoting a particular solution that ignores their existence. As I said, there is always the option to deliberately (but not accidently!) decided that a particular problem should not be reckoned in a solution design. Gr=C3=BC=C3=9Fe Olaf From nobody Wed Feb 18 06:24: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 97EB21A87A1 for ; Wed, 18 Feb 2015 06:24:42 -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 yC5_O7Sf74fx for ; Wed, 18 Feb 2015 06:24:40 -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 E6E6D1A87F0 for ; Wed, 18 Feb 2015 06:24:39 -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 t1IEOYfE001785; Wed, 18 Feb 2015 15:24:34 +0100 (CET) Received: from [IPv6:2001:638:708:30da:e913:338:6731:c8b7] (unknown [IPv6:2001:638:708:30da:e913:338:6731:c8b7]) (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 3knLsZ4tRmz2PVX; Wed, 18 Feb 2015 15:24:34 +0100 (CET) Message-ID: <54E4A09C.7060506@tzi.de> Date: Wed, 18 Feb 2015 15:24:28 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= References: <20150205095841.19111.5154.idtracker@ietfa.amsl.com> <54D341F6.9040109@tzi.de> <54D8D0C5.6030101@tzi.de> <54DB8097.4030206@tzi.de> <54DCB601.3070307@tzi.de> <54DE2721.40304@tzi.de> <54E230D5.8090104@tzi.de> <54E37CFD.9010208@tzi.de> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Variants X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Feb 2015 14:24:42 -0000 Hi Göran, On 02/18/2015 09:17 AM, Göran Selander wrote: > Hi Steffi, > > Your last mail make me hesitate whether we will progress beyond the first > use case before Dallas. > > We’ve spent a good month discussing terminology and applying it to the > first use case. I initially challenged the terminology and whether the > term “Resource” (and thereby the other terms) is well defined. The term resource is defined in rfc2616 as "A network data object or service that can be identified by a URI". In CoAP, clients send requests "to request an action (using a Method Code) on a resource (identified by a URI) on a server." (RFC7252). > We agreed > that it is well defined and we made the exercise together on the first use > case. We disagree on U1.1 and replaced it with two problem statements, > here is your latest proposal > > "We can split up the first problem into two problems: > > U1.1: Resource Owners want to grant different access rights for their > resources to different parties. > U1.2: Client Owners want to define for their clients if and how they are > allowed to access resources hosted on a Resource Server." > > Now you present a new section with implementation specific variants > including "aggregation servers” etc. which does not state what the > resources are. Obviously, one actor can be resource owner in one case and > client owner in another, but this doesn’t invalidate that the resources > are the temperature and the fan settings. Temperature values and fan settings are resources on CoAP servers that can be accessed by clients. Clients can send data to these resources and receive data from resources. The resource itself is located on the server. To define who the Client Owners are in a specific use case, we need to find out who the client and the server is in the use case. These are implementation specific, as you noted, which is why we state earlier in the document that the definition of the function of a device is not in scope of the document. Since it seems to be very important to you do define who Resource Owners and Client Owners are, I made the exercise to analyze the possible settings. As you can see, there are various possibilities if the temperature sensor that belongs to the fruit vendor is a client or a server and if the fan actuator that belongs to the container owner is a client or a server. The variants section therefore demonstrates that it is not possible to define for the use case in general who the Client Owners are. I think these variants are helpful to understand the variety of settings better. Defining who the Resource Owner is in a use case is even more difficult since the resource hosted on a server might not belong to the server owner (although the server owner is an indication). Therefore, every party that appears in the conversation can be a possible Resource Owner and there may be even more candidates in a real implementation. Defining them in a way that they fit to a specific solution is not a reasonable solution. > Could we please note that, and > that and the resource owners are fruit vendor and container owner, > respectively? For example > > U1.1: Resource Owners, such as fruit vendors and container owners, want to > grant different access rights to different parties for their respective > resources, such as temperatures and fan settings. I don't see evidence for the fact that the fruit vendor and container owner are always Resource Owners. > > As a side note, I will be travelling next week with limited email access. > I would like to have a version of this draft that is representing the > views of the authors, or expresses the disagreements in the draft, before > the cutoff. I think the disagreements are well presented on the mailing list. I don't think it is useful to put the discussion into the draft. > > One comment inline. > > Best Regards, > Göran > > On 2015-02-17 18:40, "Stefanie Gerdes" wrote: > >> Hi Göran, >> >> On 02/16/2015 08:21 PM, Göran Selander wrote: >>> Hi Steffi, >>> >>> About the Charter: If you ask about people what "authorized access to >>> resources identified by a URI and hosted on a >>> resource server” means, I think many would make the interpretation in >>> U1.1 >>> and very few, if any, would make the interpretation of U1.2. Stating >>> that >>> the charter supports your claim is IMHO an over-interpretation. >>> >>> There are also other "problems” of the Client Owners, like the examples >>> I >>> mentioned in >>> http://www.ietf.org/mail-archive/web/ace/current/msg00989.html. The >>> assumption that U1.2 should be solved with access control policies (if >>> that is implied) is arbitrary. >>> >>> About requirement vs problem: If a candidate solution does not solve >>> problem U1.1 that is not acceptable. However, we should not discriminate >>> solutions which does not solve U1.2 with access control policies. If we >>> have this formulation, it should be made clear that U1.2 is optional. >> >> It is not optional to solve the U1.2 problem. > > > Yes, we disagree about this. My view is that it must be optional to solve > the problem on the client side with access control policies. See recent > discussion with Olaf. As long as the “Client Owner” is defined in terms of > setting access rights, U1.2 is optional. > > Please note the disagreement in the draft. U1.2 describes a problem. A problem cannot be optional. It is there or it is not there. Since we agree that U1.2 is a problem I don't know what the disagreement you mention is about. Best regards, Steffi From nobody Wed Feb 18 06:36: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 BD3121A87F0 for ; Wed, 18 Feb 2015 06:36:02 -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 rA6x0NRVfPrc for ; Wed, 18 Feb 2015 06:36:01 -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 7EDA61A87DE for ; Wed, 18 Feb 2015 06:36: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 t1IEZuui027095; Wed, 18 Feb 2015 15:35:56 +0100 (CET) Received: from [IPv6:2001:638:708:30da:e913:338:6731:c8b7] (unknown [IPv6:2001:638:708:30da:e913:338:6731:c8b7]) (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 3knM6h1wvGz2PXW; Wed, 18 Feb 2015 15:35:56 +0100 (CET) Message-ID: <54E4A34C.6040209@tzi.de> Date: Wed, 18 Feb 2015 15:35:56 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Kepeng Li <1095318589@qq.com>, "goran.selander" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Ace Subject: Re: [Ace] Variants (was: Re: Fwd: I-D Action:draft-ietf-ace-usecase X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Feb 2015 14:36:02 -0000 Hi Kepeng, On 02/18/2015 10:39 AM, Kepeng Li wrote: >> It is not optional to solve the U1.2 problem. > > It seems that this is the main disagreement beteween each other. > > As Hannes mentioned, this is actually about requirements. > > In last F2F meeting, there were some comments to remove requirements in the use case document. > > I suggest that we don't talk too much about requirement at this stage. Yes, thank you. That is the reason why I proposed to just list the problems. From what I understood, we agree that U1.2 is a problem. It therefore should be listed in the problem summary section. I suggested to add text to section 3.2 (Configuration of Access Permissions) that indicates that the listed problems can be solved in different ways. Where possible, the use cases document uses neutral terminology such as "principal" to make sure that we don't indicate a specific solution. Replacing the terminology by solution specific terms that are not deducible from the use cases is not useful. Best regards, Steffi From nobody Wed Feb 18 06:43: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 D952F1A8932 for ; Wed, 18 Feb 2015 06:43:24 -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 1cEaL3fBJ9uF for ; Wed, 18 Feb 2015 06:43:22 -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 129B81A87D7 for ; Wed, 18 Feb 2015 06:43:21 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-5b-54e4a507162a Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 2E.FC.04076.705A4E45; Wed, 18 Feb 2015 15:43:19 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.27]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0210.002; Wed, 18 Feb 2015 15:43:19 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Stefanie Gerdes Thread-Topic: Variants Thread-Index: AQHQS4agZQOl8Ok+P02EjjNtlCMEmZz2e2uA Date: Wed, 18 Feb 2015 14:43:18 +0000 Message-ID: References: <20150205095841.19111.5154.idtracker@ietfa.amsl.com> <54D341F6.9040109@tzi.de> <54D8D0C5.6030101@tzi.de> <54DB8097.4030206@tzi.de> <54DCB601.3070307@tzi.de> <54DE2721.40304@tzi.de> <54E230D5.8090104@tzi.de> <54E37CFD.9010208@tzi.de> <54E4A09C.7060506@tzi.de> In-Reply-To: <54E4A09C.7060506@tzi.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="utf-8" Content-ID: <22DB056A4B91384FBC92A6BAF679F1EC@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZGfG3Rpd96ZMQg43nDC2+f+thtth48S6j A5PHkiU/mTy2vf3KHMAUxWWTkpqTWZZapG+XwJXxcIJ/wSzHirknFzI2MB6x72Lk5JAQMJE4 efQJK4QtJnHh3nq2LkYuDiGBI4wSi5+uZ4VwFjNKfHncC1bFJuAi8aDhEROILSKgLPF78Scw m1lAUWL3rLPsILawgKjEkaltQPUcQDViEh+adCBMI4n9l+JAKlgEVCUmXn/GDGLzClhI3Pm6 lgVi1U0WieXbprKA1HMKqEk8eWsNUsMINOX7qTVQm8Qlbj2ZzwRxs4DEkj3nmSFsUYmXj/+B XSkqoCex8noTG0RcUeLq9OVMICOZBTQl1u/ShxhjLTFjI8haiOOndD9khzhHUOLkzCcsExgl ZiHZNguhexaS7llIumch6V7AyLqKUbQ4tbg4N93ISC+1KDO5uDg/Ty8vtWQTIzD+Dm75bbWD 8eBzx0OMAhyMSjy8BgxPQoRYE8uKK3MPMUpzsCiJ89oZHwoREkhPLEnNTk0tSC2KLyrNSS0+ xMjEwSnVwFjIza4SaLzY3rUpIst329O7G38f9D3yvPHts0c6/4PC9qzfbyqwR37pFdnMVUr/ D3bzLHh24gSj68F1JkLX367nOvlMsViEz11wz+GLb5cEaLU7/Wmwu/05+tfJBlbeVbUKYbvs rfM+K/UcjlNcwPXxBLPdwhmhn3kud2TWpynOceqffWOG/HMlluKMREMt5qLiRADy+BwMoAIA AA== Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Variants X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Feb 2015 14:43:25 -0000 SGkgU3RlZmZpLA0KDQpJIHdhaXQgd2l0aCByZXBseWluZyB0byB5b3VyIGNvbW1lbnRzLCBzaG91 bGQgdGhleSBzdGlsbCBiZSByZWxldmFudCwNCnVudGlsIHRoZSByZXZpZXcgaW4gYSBsYXJnZXIg Z3JvdXAuDQoNCkJlc3QgcmVnYXJkcywNCkfDtnJhbg0KDQoNCk9uIDIwMTUtMDItMTggMTU6MjQs ICJTdGVmYW5pZSBHZXJkZXMiIDxnZXJkZXNAdHppLmRlPiB3cm90ZToNCg0KPkhpIEfDtnJhbiwN Cj4NCj4NCj5PbiAwMi8xOC8yMDE1IDA5OjE3IEFNLCBHw7ZyYW4gU2VsYW5kZXIgd3JvdGU6DQo+ PiBIaSBTdGVmZmksDQo+Pg0KPj4gWW91ciBsYXN0IG1haWwgbWFrZSBtZSBoZXNpdGF0ZSB3aGV0 aGVyIHdlIHdpbGwgcHJvZ3Jlc3MgYmV5b25kIHRoZQ0KPj5maXJzdA0KPj4gdXNlIGNhc2UgYmVm b3JlIERhbGxhcy4NCj4+DQo+PiBXZeKAmXZlIHNwZW50IGEgZ29vZCBtb250aCBkaXNjdXNzaW5n IHRlcm1pbm9sb2d5IGFuZCBhcHBseWluZyBpdCB0byB0aGUNCj4+IGZpcnN0IHVzZSBjYXNlLiBJ IGluaXRpYWxseSBjaGFsbGVuZ2VkIHRoZSB0ZXJtaW5vbG9neSBhbmQgd2hldGhlciB0aGUNCj4+ IHRlcm0g4oCcUmVzb3VyY2XigJ0gKGFuZCB0aGVyZWJ5IHRoZSBvdGhlciB0ZXJtcykgaXMgd2Vs bCBkZWZpbmVkLg0KPg0KPlRoZSB0ZXJtIHJlc291cmNlIGlzIGRlZmluZWQgaW4gcmZjMjYxNiBh cyAiQSBuZXR3b3JrIGRhdGEgb2JqZWN0IG9yDQo+c2VydmljZSB0aGF0IGNhbiBiZSBpZGVudGlm aWVkIGJ5IGEgVVJJIi4gSW4gQ29BUCwgY2xpZW50cyBzZW5kIHJlcXVlc3RzDQo+InRvIHJlcXVl c3QgYW4gYWN0aW9uICh1c2luZyBhIE1ldGhvZCBDb2RlKSBvbiBhIHJlc291cmNlIChpZGVudGlm aWVkIGJ5DQo+YSBVUkkpIG9uIGEgc2VydmVyLiIgKFJGQzcyNTIpLg0KPg0KPj4gV2UgYWdyZWVk DQo+PiB0aGF0IGl0IGlzIHdlbGwgZGVmaW5lZCBhbmQgd2UgbWFkZSB0aGUgZXhlcmNpc2UgdG9n ZXRoZXIgb24gdGhlIGZpcnN0DQo+PnVzZQ0KPj4gY2FzZS4gV2UgZGlzYWdyZWUgb24gVTEuMSBh bmQgcmVwbGFjZWQgaXQgd2l0aCB0d28gcHJvYmxlbSBzdGF0ZW1lbnRzLA0KPj4gaGVyZSBpcyB5 b3VyIGxhdGVzdCBwcm9wb3NhbA0KPj4NCj4+ICJXZSBjYW4gc3BsaXQgdXAgdGhlIGZpcnN0IHBy b2JsZW0gaW50byB0d28gcHJvYmxlbXM6DQo+Pg0KPj4gVTEuMTogUmVzb3VyY2UgT3duZXJzIHdh bnQgdG8gZ3JhbnQgZGlmZmVyZW50IGFjY2VzcyByaWdodHMgZm9yIHRoZWlyDQo+PiByZXNvdXJj ZXMgdG8gZGlmZmVyZW50IHBhcnRpZXMuDQo+PiBVMS4yOiBDbGllbnQgT3duZXJzIHdhbnQgdG8g ZGVmaW5lIGZvciB0aGVpciBjbGllbnRzIGlmIGFuZCBob3cgdGhleSBhcmUNCj4+IGFsbG93ZWQg dG8gYWNjZXNzIHJlc291cmNlcyBob3N0ZWQgb24gYSBSZXNvdXJjZSBTZXJ2ZXIuIg0KPj4NCj4+ IE5vdyB5b3UgcHJlc2VudCBhIG5ldyBzZWN0aW9uIHdpdGggaW1wbGVtZW50YXRpb24gc3BlY2lm aWMgdmFyaWFudHMNCj4+IGluY2x1ZGluZyAiYWdncmVnYXRpb24gc2VydmVyc+KAnSBldGMuIHdo aWNoIGRvZXMgbm90IHN0YXRlIHdoYXQgdGhlDQo+PiByZXNvdXJjZXMgYXJlLiBPYnZpb3VzbHks IG9uZSBhY3RvciBjYW4gYmUgcmVzb3VyY2Ugb3duZXIgaW4gb25lIGNhc2UNCj4+YW5kDQo+PiBj bGllbnQgb3duZXIgaW4gYW5vdGhlciwgYnV0IHRoaXMgZG9lc27igJl0IGludmFsaWRhdGUgdGhh dCB0aGUgcmVzb3VyY2VzDQo+PiBhcmUgdGhlIHRlbXBlcmF0dXJlIGFuZCB0aGUgZmFuIHNldHRp bmdzLg0KPg0KPlRlbXBlcmF0dXJlIHZhbHVlcyBhbmQgZmFuIHNldHRpbmdzIGFyZSByZXNvdXJj ZXMgb24gQ29BUCBzZXJ2ZXJzIHRoYXQNCj5jYW4gYmUgYWNjZXNzZWQgYnkgY2xpZW50cy4gQ2xp ZW50cyBjYW4gc2VuZCBkYXRhIHRvIHRoZXNlIHJlc291cmNlcyBhbmQNCj5yZWNlaXZlIGRhdGEg ZnJvbSByZXNvdXJjZXMuIFRoZSByZXNvdXJjZSBpdHNlbGYgaXMgbG9jYXRlZCBvbiB0aGUgc2Vy dmVyLg0KPg0KPlRvIGRlZmluZSB3aG8gdGhlIENsaWVudCBPd25lcnMgYXJlIGluIGEgc3BlY2lm aWMgdXNlIGNhc2UsIHdlIG5lZWQgdG8NCj5maW5kIG91dCB3aG8gdGhlIGNsaWVudCBhbmQgdGhl IHNlcnZlciBpcyBpbiB0aGUgdXNlIGNhc2UuIFRoZXNlIGFyZQ0KPmltcGxlbWVudGF0aW9uIHNw ZWNpZmljLCBhcyB5b3Ugbm90ZWQsIHdoaWNoIGlzIHdoeSB3ZSBzdGF0ZSBlYXJsaWVyIGluDQo+ dGhlIGRvY3VtZW50IHRoYXQgdGhlIGRlZmluaXRpb24gb2YgdGhlIGZ1bmN0aW9uIG9mIGEgZGV2 aWNlIGlzIG5vdCBpbg0KPnNjb3BlIG9mIHRoZSBkb2N1bWVudC4NCj4NCj5TaW5jZSBpdCBzZWVt cyB0byBiZSB2ZXJ5IGltcG9ydGFudCB0byB5b3UgZG8gZGVmaW5lIHdobyBSZXNvdXJjZSBPd25l cnMNCj5hbmQgQ2xpZW50IE93bmVycyBhcmUsIEkgbWFkZSB0aGUgZXhlcmNpc2UgdG8gYW5hbHl6 ZSB0aGUgcG9zc2libGUNCj5zZXR0aW5ncy4gQXMgeW91IGNhbiBzZWUsIHRoZXJlIGFyZSB2YXJp b3VzIHBvc3NpYmlsaXRpZXMgaWYgdGhlDQo+dGVtcGVyYXR1cmUgc2Vuc29yIHRoYXQgYmVsb25n cyB0byB0aGUgZnJ1aXQgdmVuZG9yIGlzIGEgY2xpZW50IG9yIGENCj5zZXJ2ZXIgYW5kIGlmIHRo ZSBmYW4gYWN0dWF0b3IgdGhhdCBiZWxvbmdzIHRvIHRoZSBjb250YWluZXIgb3duZXIgaXMgYQ0K PmNsaWVudCBvciBhIHNlcnZlci4gVGhlIHZhcmlhbnRzIHNlY3Rpb24gdGhlcmVmb3JlIGRlbW9u c3RyYXRlcyB0aGF0IGl0DQo+aXMgbm90IHBvc3NpYmxlIHRvIGRlZmluZSBmb3IgdGhlIHVzZSBj YXNlIGluIGdlbmVyYWwgd2hvIHRoZSBDbGllbnQNCj5Pd25lcnMgYXJlLiBJIHRoaW5rIHRoZXNl IHZhcmlhbnRzIGFyZSBoZWxwZnVsIHRvIHVuZGVyc3RhbmQgdGhlIHZhcmlldHkNCj5vZiBzZXR0 aW5ncyBiZXR0ZXIuDQo+DQo+RGVmaW5pbmcgd2hvIHRoZSBSZXNvdXJjZSBPd25lciBpcyBpbiBh IHVzZSBjYXNlIGlzIGV2ZW4gbW9yZSBkaWZmaWN1bHQNCj5zaW5jZSB0aGUgcmVzb3VyY2UgaG9z dGVkIG9uIGEgc2VydmVyIG1pZ2h0IG5vdCBiZWxvbmcgdG8gdGhlIHNlcnZlcg0KPm93bmVyIChh bHRob3VnaCB0aGUgc2VydmVyIG93bmVyIGlzIGFuIGluZGljYXRpb24pLiBUaGVyZWZvcmUsIGV2 ZXJ5DQo+cGFydHkgdGhhdCBhcHBlYXJzIGluIHRoZSBjb252ZXJzYXRpb24gY2FuIGJlIGEgcG9z c2libGUgUmVzb3VyY2UgT3duZXINCj5hbmQgdGhlcmUgbWF5IGJlIGV2ZW4gbW9yZSBjYW5kaWRh dGVzIGluIGEgcmVhbCBpbXBsZW1lbnRhdGlvbi4gRGVmaW5pbmcNCj50aGVtIGluIGEgd2F5IHRo YXQgdGhleSBmaXQgdG8gYSBzcGVjaWZpYyBzb2x1dGlvbiBpcyBub3QgYSByZWFzb25hYmxlDQo+ c29sdXRpb24uDQo+DQo+PiBDb3VsZCB3ZSBwbGVhc2Ugbm90ZSB0aGF0LCBhbmQNCj4+IHRoYXQg YW5kIHRoZSByZXNvdXJjZSBvd25lcnMgYXJlIGZydWl0IHZlbmRvciBhbmQgY29udGFpbmVyIG93 bmVyLA0KPj4gcmVzcGVjdGl2ZWx5PyBGb3IgZXhhbXBsZQ0KPj4NCj4+IFUxLjE6IFJlc291cmNl IE93bmVycywgc3VjaCBhcyBmcnVpdCB2ZW5kb3JzIGFuZCBjb250YWluZXIgb3duZXJzLCB3YW50 DQo+PnRvDQo+PiBncmFudCBkaWZmZXJlbnQgYWNjZXNzIHJpZ2h0cyB0byBkaWZmZXJlbnQgcGFy dGllcyBmb3IgdGhlaXIgcmVzcGVjdGl2ZQ0KPj4gcmVzb3VyY2VzLCBzdWNoIGFzIHRlbXBlcmF0 dXJlcyBhbmQgZmFuIHNldHRpbmdzLg0KPg0KPkkgZG9uJ3Qgc2VlIGV2aWRlbmNlIGZvciB0aGUg ZmFjdCB0aGF0IHRoZSBmcnVpdCB2ZW5kb3IgYW5kIGNvbnRhaW5lcg0KPm93bmVyIGFyZSBhbHdh eXMgUmVzb3VyY2UgT3duZXJzLg0KPg0KPj4NCj4+IEFzIGEgc2lkZSBub3RlLCBJIHdpbGwgYmUg dHJhdmVsbGluZyBuZXh0IHdlZWsgd2l0aCBsaW1pdGVkIGVtYWlsDQo+PmFjY2Vzcy4NCj4+IEkg d291bGQgbGlrZSB0byBoYXZlIGEgdmVyc2lvbiBvZiB0aGlzIGRyYWZ0IHRoYXQgaXMgcmVwcmVz ZW50aW5nIHRoZQ0KPj4gdmlld3Mgb2YgdGhlIGF1dGhvcnMsIG9yIGV4cHJlc3NlcyB0aGUgZGlz YWdyZWVtZW50cyBpbiB0aGUgZHJhZnQsDQo+PmJlZm9yZQ0KPj4gdGhlIGN1dG9mZi4NCj4NCj5J IHRoaW5rIHRoZSBkaXNhZ3JlZW1lbnRzIGFyZSB3ZWxsIHByZXNlbnRlZCBvbiB0aGUgbWFpbGlu ZyBsaXN0LiBJDQo+ZG9uJ3QgdGhpbmsgaXQgaXMgdXNlZnVsIHRvIHB1dCB0aGUgZGlzY3Vzc2lv biBpbnRvIHRoZSBkcmFmdC4NCj4NCj4+DQo+PiBPbmUgY29tbWVudCBpbmxpbmUuDQo+Pg0KPj4g QmVzdCBSZWdhcmRzLA0KPj4gR8O2cmFuDQo+Pg0KPj4gT24gMjAxNS0wMi0xNyAxODo0MCwgIlN0 ZWZhbmllIEdlcmRlcyIgPGdlcmRlc0B0emkuZGU+IHdyb3RlOg0KPj4NCj4+PiBIaSBHw7ZyYW4s DQo+Pj4NCj4+PiBPbiAwMi8xNi8yMDE1IDA4OjIxIFBNLCBHw7ZyYW4gU2VsYW5kZXIgd3JvdGU6 DQo+Pj4+IEhpIFN0ZWZmaSwNCj4+Pj4NCj4+Pj4gQWJvdXQgdGhlIENoYXJ0ZXI6IElmIHlvdSBh c2sgYWJvdXQgcGVvcGxlIHdoYXQgImF1dGhvcml6ZWQgYWNjZXNzIHRvDQo+Pj4+IHJlc291cmNl cyBpZGVudGlmaWVkIGJ5IGEgVVJJIGFuZCBob3N0ZWQgb24gYQ0KPj4+PiByZXNvdXJjZSBzZXJ2 ZXLigJ0gbWVhbnMsIEkgdGhpbmsgbWFueSB3b3VsZCBtYWtlIHRoZSBpbnRlcnByZXRhdGlvbiBp bg0KPj4+PiBVMS4xDQo+Pj4+IGFuZCB2ZXJ5IGZldywgaWYgYW55LCB3b3VsZCBtYWtlIHRoZSBp bnRlcnByZXRhdGlvbiBvZiBVMS4yLiBTdGF0aW5nDQo+Pj4+IHRoYXQNCj4+Pj4gdGhlIGNoYXJ0 ZXIgc3VwcG9ydHMgeW91ciBjbGFpbSBpcyBJTUhPIGFuIG92ZXItaW50ZXJwcmV0YXRpb24uDQo+ Pj4+DQo+Pj4+IFRoZXJlIGFyZSBhbHNvIG90aGVyICJwcm9ibGVtc+KAnSBvZiB0aGUgQ2xpZW50 IE93bmVycywgbGlrZSB0aGUNCj4+Pj5leGFtcGxlcw0KPj4+PiBJDQo+Pj4+IG1lbnRpb25lZCBp bg0KPj4+PiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvYWNlL2N1cnJlbnQv bXNnMDA5ODkuaHRtbC4gVGhlDQo+Pj4+IGFzc3VtcHRpb24gdGhhdCBVMS4yIHNob3VsZCBiZSBz b2x2ZWQgd2l0aCBhY2Nlc3MgY29udHJvbCBwb2xpY2llcyAoaWYNCj4+Pj4gdGhhdCBpcyBpbXBs aWVkKSBpcyBhcmJpdHJhcnkuDQo+Pj4+DQo+Pj4+IEFib3V0IHJlcXVpcmVtZW50IHZzIHByb2Js ZW06IElmIGEgY2FuZGlkYXRlIHNvbHV0aW9uIGRvZXMgbm90IHNvbHZlDQo+Pj4+IHByb2JsZW0g VTEuMSB0aGF0IGlzIG5vdCBhY2NlcHRhYmxlLiBIb3dldmVyLCB3ZSBzaG91bGQgbm90DQo+Pj4+ ZGlzY3JpbWluYXRlDQo+Pj4+IHNvbHV0aW9ucyB3aGljaCBkb2VzIG5vdCBzb2x2ZSBVMS4yIHdp dGggYWNjZXNzIGNvbnRyb2wgcG9saWNpZXMuIElmDQo+Pj4+d2UNCj4+Pj4gaGF2ZSB0aGlzIGZv cm11bGF0aW9uLCBpdCBzaG91bGQgYmUgbWFkZSBjbGVhciB0aGF0IFUxLjIgaXMgb3B0aW9uYWwu DQo+Pj4NCj4+PiBJdCBpcyBub3Qgb3B0aW9uYWwgdG8gc29sdmUgdGhlIFUxLjIgcHJvYmxlbS4N Cj4+DQo+Pg0KPj4gWWVzLCB3ZSBkaXNhZ3JlZSBhYm91dCB0aGlzLiBNeSB2aWV3IGlzIHRoYXQg aXQgbXVzdCBiZSBvcHRpb25hbCB0bw0KPj5zb2x2ZQ0KPj4gdGhlIHByb2JsZW0gb24gdGhlIGNs aWVudCBzaWRlIHdpdGggYWNjZXNzIGNvbnRyb2wgcG9saWNpZXMuIFNlZSByZWNlbnQNCj4+IGRp c2N1c3Npb24gd2l0aCBPbGFmLiBBcyBsb25nIGFzIHRoZSDigJxDbGllbnQgT3duZXLigJ0gaXMg ZGVmaW5lZCBpbiB0ZXJtcw0KPj5vZg0KPj4gc2V0dGluZyBhY2Nlc3MgcmlnaHRzLCBVMS4yIGlz IG9wdGlvbmFsLg0KPj4NCj4+IFBsZWFzZSBub3RlIHRoZSBkaXNhZ3JlZW1lbnQgaW4gdGhlIGRy YWZ0Lg0KPg0KPlUxLjIgZGVzY3JpYmVzIGEgcHJvYmxlbS4gQSBwcm9ibGVtIGNhbm5vdCBiZSBv cHRpb25hbC4gSXQgaXMgdGhlcmUgb3INCj5pdCBpcyBub3QgdGhlcmUuIFNpbmNlIHdlIGFncmVl IHRoYXQgVTEuMiBpcyBhIHByb2JsZW0gSSBkb24ndCBrbm93IHdoYXQNCj50aGUgZGlzYWdyZWVt ZW50IHlvdSBtZW50aW9uIGlzIGFib3V0Lg0KPg0KPkJlc3QgcmVnYXJkcywNCj5TdGVmZmkNCg0K From nobody Sat Feb 21 06:21: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 E4C3F1A1A2E; Sat, 21 Feb 2015 06:21:21 -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 EtlNkE2sZONs; Sat, 21 Feb 2015 06:21:19 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4805C1A7000; Sat, 21 Feb 2015 06:21:19 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t1LELFbN017140; Sat, 21 Feb 2015 15:21:15 +0100 (CET) Received: from alma.local (p5DC7E14D.dip0.t-ipconnect.de [93.199.225.77]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3kqBfM082rz2QKR; Sat, 21 Feb 2015 15:21:14 +0100 (CET) Message-ID: <54E89471.9000106@tzi.org> Date: Sat, 21 Feb 2015 15:21:37 +0100 From: Carsten Bormann User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: dtls-iot@ietf.org, core , ace@ietf.org, "6lo@ietf.org WG" <6lo@ietf.org>, t2trg@irtf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [Ace] Constrained Node/Network Cluster @ IETF92, early draft version X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 14:21:22 -0000 A first draft version of the IETF92 agenda is out. ** THIS IS GOING TO CHANGE ** for conflict resolution, so please don't make travel arrangements based on it. Here is my usual eclectic condensed agenda built from that. There are no ROLL or DICE meetings in the agenda this time. Again, the Constrained Node/Network group meetings are nicely spread out over the week, with a peak on Wednesday. I also put in the weekend meeting of the proposed Thing-to-thing Research Group ; I hope to have details for this on Monday. All times are CDT (UTC-0500) (use https://datatracker.ietf.org/meeting/agenda-utc and press the button to get your local time in case you want to listen in from remote). Grüße, Carsten SATURDAY, March 21, 2015 1300-1800 Session I (TBD) IRTF*** t2trg Proposed Thing-to-thing Research Group SUNDAY, March 22, 2015 0900-1500 Session II (TBD) IRTF*** t2trg Proposed Thing-to-thing Research Group MONDAY, March 23, 2015 0900-1130 Morning Session I Venetian APP appsawg Applications Area Working Group WG - Combined with APPSAREA International INT 6man IPv6 Maintenance WG 1300-1500 Afternoon Session I International INT dnssd Extensions for Scalable DNS Service Discovery WG Parisian TSV taps Transport Services WG 1520-1650 Afternoon Session II Parisian APP uta Using TLS in Applications WG Continental INT *** 6tisch IPv6 over the TSCH mode of IEEE 802.15.4e WG Far East RAI webpush Web-Based Push Notifications WG Gold TSV tsvarea Transport Area Open Meeting TUESDAY, March 24, 2015 0900-1130 Morning Session I International INT homenet Home Networking WG Parisian SEC tokbind Token Binding WG 1300-1500 Afternoon Session I Oak APP httpbis Hypertext Transfer Protocol WG Parisian SEC *** ace Authentication and Authorization for Constrained Environments WG 1520-1720 Afternoon Session II International INT *** 6lo IPv6 over Networks of Resource-constrained Nodes WG Oak OPS anima Autonomic Networking Integrated Model and Approach WG Parisian TSV tsvwg Transport Area Working Group WG 1730-1830 Afternoon Session III Royal SEC jose Javascript Object Signing and Encryption WG WEDNESDAY, March 25, 2015 0900-1130 Morning Session I International TSV spud Session Protocol for User Datagrams BOF 1300-1500 Afternoon Session I International OPS v6ops IPv6 Operations WG Venetian RTG bier Bit Indexed Explicit Replication WG Royal SEC oauth Web Authorization Protocol WG 1520-1620 Afternoon Session II Oak INT *** lwig Light-Weight Implementation Guidance WG Venetian SEC acme Automated Certificate Management Environment BOF THURSDAY, March 26, 2015 0900-1130 Morning Session I Continental INT *** 6tisch IPv6 over the TSCH mode of IEEE 802.15.4e WG Gold OPS v6ops IPv6 Operations WG Oak SEC tls Transport Layer Security WG Venetian TSV rmcat RTP Media Congestion Avoidance Techniques WG 1300-1500 Afternoon Session I International SEC saag Security Area Open Meeting Parisian TSV tsvwg Transport Area Working Group WG 1520-1720 Afternoon Session II Oak APP *** core Constrained RESTful Environments WG Gold RTG rtgarea Routing Area Open Meeting Parisian TSV tcpinc TCP Increased Security WG 1740-1840 Afternoon Session III Venetian INT intarea Internet Area Working Group WG Continental SEC httpauth Hypertext Transfer Protocol Authentication WG FRIDAY, March 27, 2015 0900-1130 Morning Session I Far East APP *** core Constrained RESTful Environments WG 1150-1320 Afternoon Session I Parisian OPS anima Autonomic Networking Integrated Model and Approach WG Venetian TSV tsvarea Transport Area Open Meeting From nobody Fri Feb 27 17:16: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 9F2D51A1B20 for ; Fri, 27 Feb 2015 17:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.451 X-Spam-Level: X-Spam-Status: No, score=0.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, 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 WyQspQB7q0pw for ; Fri, 27 Feb 2015 17:16:14 -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 462881A1B21 for ; Fri, 27 Feb 2015 17:16:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1425086172; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=t/c4B/S1MPOZDc1uAj0p2VLDySI64QfNRiYajORUAZE=; b=d7ho09m8PgMU74N+0UdDBa38CrNWgI4bce3OclszfcWGg0C642vWEsP8dnps6a4vUpDxRFaZz9JA0N4z42Ouw4wJ0x5p/D7cXzSiOD+tQgcGqDvPVdy15GMteZ/zTCsC+IqEybvSntnVjWW0SWb5xcHy8ouy+W/XO30PJbnFAd0= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R131e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41g03024; MF=kepeng.lkp@alibaba-inc.com; PH=DS; RN=1; RT=1; SR=0; Received: from 10.1.148.174(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.74.186) by smtp.aliyun-inc.com(127.0.0.1); Sat, 28 Feb 2015 09:16:10 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Sat, 28 Feb 2015 09:16:07 +0800 From: "Kepeng Li" To: "ace@ietf.org" Message-ID: Thread-Topic: ace - Requested session has been scheduled for IETF 92 References: <20150227222723.22539.5266.idtracker@ietfa.amsl.com> In-Reply-To: <20150227222723.22539.5266.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Subject: [Ace] FW: ace - Requested session has been scheduled for IETF 92 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2015 01:16:15 -0000 =D4=DA 28/2/15 6:27 am=A3=AC ""IETF Secretariat"" =D0=B4=C8=EB: >Dear Kepeng Li, > >The session(s) that you have requested have been scheduled. >Below is the scheduled session information followed by >the original request. > >ace Session 1 (2:00:00) > Tuesday, Afternoon Session I 1300-1500 > Room Name: Parisian size: 200 > --------------------------------------------- > =20 > > >Request Information: > > >--------------------------------------------------------- >Working Group Name: Authentication and Authorization for Constrained >Environments >Area Name: Security Area >Session Requester: Kepeng Li > >Number of Sessions: 1 >Length of Session(s): 2 Hours >Number of Attendees: 100 >Conflicts to Avoid: > First Priority: core dice oauth saag lwig > > > > >Special Requests: > Avoid entire APP and SEC areas. >---------------------------------------------------------