From nobody Sun May 3 23:43:17 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 142843A0C3C for ; Sun, 3 May 2020 23:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 5Q4QaWEdo-ty for ; Sun, 3 May 2020 23:43:13 -0700 (PDT) Received: from weald2.air.saab.se (weald2.air.saab.se [136.163.212.4]) (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 0FCC13A0C3D for ; Sun, 3 May 2020 23:43:02 -0700 (PDT) Received: from mailhub2.air.saab.se ([136.163.213.5]) by weald2.air.saab.se (8.14.4/8.14.4) with ESMTP id 0446gnBj025734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 May 2020 08:42:49 +0200 Received: from corpappl16349.corp.saab.se (corpappl16349.corp.saab.se [10.12.12.112]) by mailhub2.air.saab.se (8.13.8/8.13.8) with ESMTP id 0446gY8t026988 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 May 2020 08:42:34 +0200 Received: from corpappl16593.corp.saab.se (10.12.12.125) by corpappl16349.corp.saab.se (10.12.12.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Mon, 4 May 2020 08:42:34 +0200 Received: from corpappl16593.corp.saab.se ([fe80::b4c9:ca69:a80d:fa3]) by corpappl16593.corp.saab.se ([fe80::b4c9:ca69:a80d:fa3%4]) with mapi id 15.01.1847.009; Mon, 4 May 2020 08:42:34 +0200 From: Seitz Ludwig To: "consultancy@vanderstok.org" , Jim Schaad CC: "'Ace'" Thread-Topic: [Ace] draft-ietf-ace-oauth-authz Thread-Index: AQHWHrytAFclswHm7kqaQRCF7GbsM6iRqECAgAED/ACABNRcQA== Date: Mon, 4 May 2020 06:42:34 +0000 Message-ID: <6cab8f7fcdbf441fbc3ca747cfb09a72@combitech.se> References: <56d31e581571721e176b59db20e08c23@bbhmail.nl> <00f101d61f03$a26bb920$e7432b60$@augustcellars.com> <0873a3115cab89036002cf42b1c97608@bbhmail.nl> In-Reply-To: <0873a3115cab89036002cf42b1c97608@bbhmail.nl> Accept-Language: en-SE, sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.12.13.198] Content-Type: multipart/alternative; boundary="_000_6cab8f7fcdbf441fbc3ca747cfb09a72combitechse_" MIME-Version: 1.0 X-Saab-MailScanner-Information: Please contact the ISP for more information X-Saab-MailScanner-ID: 0446gY8t026988 X-Saab-MailScanner: Found to be clean X-Saab-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.498, required 5, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -0.50, HTML_MESSAGE 0.00, SURBL_BLOCKED 1.00, URIBL_BLOCKED 0.00) X-Saab-MailScanner-From: ludwig.seitz@combitech.se X-Saab-MailScanner-Watermark: 1589179355.36516@h31Z06ZE7p5szP8oRmoa8Q X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (weald2.air.saab.se [136.163.212.4]); Mon, 04 May 2020 08:42:49 +0200 (CEST) Archived-At: Subject: Re: [Ace] draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 04 May 2020 06:43:16 -0000 --_000_6cab8f7fcdbf441fbc3ca747cfb09a72combitechse_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rm9yIHRoZSBzYWtlIG9mIGdldHRpbmcgdGhlIGRvY3VtZW50IGZpbmlzaGVkIGJlZm9yZSBJIGRp ZSBvZiBvbGQgYWdlIDstKSB3b3VsZCBpdCBiZSBwb3NzaWJsZSB0byBzcGVjaWZ5IHRoaXMgaW4g YSBzZXBhcmF0ZSBkb2N1bWVudD8NCg0KL0x1ZHdpZw0KDQpGcm9tOiBBY2UgPGFjZS1ib3VuY2Vz QGlldGYub3JnPiBPbiBCZWhhbGYgT2YgUGV0ZXIgdmFuIGRlciBTdG9rDQpTZW50OiBkZW4gMSBt YWogMjAyMCAwODo1Ng0KVG86IEppbSBTY2hhYWQgPGlldGZAYXVndXN0Y2VsbGFycy5jb20+DQpD YzogY29uc3VsdGFuY3lAdmFuZGVyc3Rvay5vcmc7ICdBY2UnIDxhY2VAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSZTogW0FjZV0gZHJhZnQtaWV0Zi1hY2Utb2F1dGgtYXV0aHoNCg0KSEkgSmltLA0KDQpJ IHRyeSB0byBhbnN3ZXIgeW91ciBxdWVzdGlvbiwNCg0KV2hlbiBJIHdhbnQgdG8gYWNjZXNzIGFu IE9DRiBkZXZpY2UgSSBjYW4gZmluZCBpdHMgSVAgYWRkcmVzcyB0aHJvdWdoIHNlcnZpY2UgZGlz Y292ZXJ5IChyZmM3MjUyIHNlY3Rpb24gNykgdXNpbmcgYW4gcnQtdmFsdWUgcmVnaXN0ZXJlZCBh dCB0aGUgSUFOQSBjb3JlIHBhcmFtZXRlcnMgcmVnaXN0cnkuDQpGb3IgZXhhbXBsZSwgd2hlbiBJ IHdhbnQgdG8gaW5pdGlhbGl6ZSB0aGUgQVMgSSBoYXZlIHRvIHR5cGUgaW4gdGhlIElQIGFkZHJl c3Mgb2YgdGhlIEFTLg0KRnJvbSB0aGF0IG1vbWVudCBvbiBrZXlzIGFuZCBjZXJ0aWZpY2F0ZXMg Y2FuIGJlIGNvbXBhcmVkIHRvIGNvbnRpbnVlIGluaXRpYWxpemF0aW9uLg0KDQpVc2luZyBzZXJ2 aWNlIGRpc2NvdmVyeSBjYW4gYXV0b21hdGUgdGhhdCBwcm9jZXNzLg0KDQpNeSByZXF1ZXN0IGlz IHRoYXQgYXV0aHogZHJhZnQgcmVnaXN0ZXJzIGFuIHJ0LXZhbHVlIGluIGNvcmUgcGFyYW1ldGVy cyByZWdpc3RyeSBmb3Igc2VydmljZSBkaXNjb3Zlcnkgb2YgdGhlIEFTLA0KdW5sZXNzIGEgZGlm ZmVyZW50IHByb2Nlc3MgaGFzIGFscmVhZHkgYmVlbiBlc3RhYmxpc2hlZCBmb3IgQVMgaW5pdGlh bGl6YXRpb24uDQoNCk1hbnkgdGhhbmtzLA0KDQpwZXRlcg0KDQoNCkppbSBTY2hhYWQgc2NocmVl ZiBvcCAyMDIwLTA0LTMwIDE3OjI1Og0KDQoNCldoYXQgZG8geW91IGV4cGVjdCB0byBzZWU/ICAg QnkgZGVmYXVsdCBhIGNsaWVudCBuZWVkcyB0byBrbm93IHRoYXQgc29tZXRoaW5nIGlzIGFuIEFT IGFuZCBoYXZlIGEga2V5IHRvIGludGVyYWN0IHdpdGggdGhhdCBBUy4NCg0KDQoNCkppbQ0KDQoN Cg0KDQoNCkZyb206IEFjZSA8YWNlLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmFjZS1ib3VuY2Vz QGlldGYub3JnPj4gT24gQmVoYWxmIE9mIFBldGVyIHZhbiBkZXIgU3Rvaw0KU2VudDogV2VkbmVz ZGF5LCBBcHJpbCAyOSwgMjAyMCAxMTo1NyBQTQ0KVG86IEFjZSA8YWNlQGlldGYub3JnPG1haWx0 bzphY2VAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW0FjZV0gZHJhZnQtaWV0Zi1hY2Utb2F1dGgtYXV0 aHoNCg0KDQoNCkhpIGF1dGh6IGF1dGhvcnMsLA0KDQpXaGlsZSBpbXBsZW1lbnRpbmcgYSB2ZXJz aW9uIG9mIEFTLCBJIG5vdGljZWQgdGhhdCB0aGVyZSBpcyBubyByZXNvdXJjZSB0eXBlIChydCkg cmVnaXN0ZXJlZCBmb3IgLy53ZWxsLWtub3duL2NvcmUgZGlzY292ZXJ5Lg0KSXMgdGhpcyB2b2x1 bnRhcnk/DQpJZiBub3QsIGNhbiBpdCBzdGlsbCBiZSBhZGRlZD8NCg0KdGhhbmtzLA0KDQpwZXRl cg0KDQotLQ0KDQpQZXRlciB2YW4gZGVyIFN0b2sNCnZhbmRlcnN0b2sgY29uc3VsdGFuY3kNCm1h aWx0bzogY29uc3VsdGFuY3lAdmFuZGVyc3Rvay5vcmc8bWFpbHRvOmNvbnN1bHRhbmN5QHZhbmRl cnN0b2sub3JnPiwgc3Rva2NvbnNAYmJobWFpbC5ubDxtYWlsdG86c3Rva2NvbnNAYmJobWFpbC5u bD4NCnd3dzogd3d3LnZhbmRlcnN0b2sub3JnPGh0dHA6Ly93d3cudmFuZGVyc3Rvay5vcmc+DQp0 ZWwgTkw6ICszMSgwKTQ5MjQ3NDY3MyAgICAgRjogKzMzKDApOTY2MDE1MjQ4DQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpBY2UgbWFpbGluZyBsaXN0 DQpBY2VAaWV0Zi5vcmc8bWFpbHRvOkFjZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vYWNlDQo= --_000_6cab8f7fcdbf441fbc3ca747cfb09a72combitechse_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow Y207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz ZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LHNlcmlmO30NCnAudjFtc29ub3JtYWwsIGxpLnYxbXNvbm9ybWFsLCBkaXYudjFtc29ub3JtYWwN Cgl7bXNvLXN0eWxlLW5hbWU6djFtc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJn aW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjt9DQpzcGFuLnYxbXNvaHlwZXJsaW5rDQoJe21zby1zdHlsZS1uYW1lOnYx bXNvaHlwZXJsaW5rO30NCnNwYW4udjFlbWFpbHN0eWxlMTgNCgl7bXNvLXN0eWxlLW5hbWU6djFl bWFpbHN0eWxlMTg7fQ0KcC52MW1zb25vcm1hbDEsIGxpLnYxbXNvbm9ybWFsMSwgZGl2LnYxbXNv bm9ybWFsMQ0KCXttc28tc3R5bGUtbmFtZTp2MW1zb25vcm1hbDE7DQoJbWFyZ2luOjBjbTsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLnYxbXNvaHlwZXJsaW5rMQ0KCXttc28tc3R5bGUt bmFtZTp2MW1zb2h5cGVybGluazE7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJs dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI2DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2 MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Rm9yIHRoZSBzYWtlIG9mIGdldHRpbmcgdGhlIGRvY3VtZW50IGZpbmlzaGVkIGJl Zm9yZSBJIGRpZSBvZiBvbGQgYWdlIDstKSB3b3VsZCBpdCBiZSBwb3NzaWJsZSB0byBzcGVjaWZ5 IHRoaXMgaW4gYSBzZXBhcmF0ZSBkb2N1bWVudD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPi9MdWR3aWc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+IEFjZSAmbHQ7YWNlLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7DQo8Yj5PbiBCZWhhbGYg T2YgPC9iPlBldGVyIHZhbiBkZXIgU3Rvazxicj4NCjxiPlNlbnQ6PC9iPiBkZW4gMSBtYWogMjAy MCAwODo1Njxicj4NCjxiPlRvOjwvYj4gSmltIFNjaGFhZCAmbHQ7aWV0ZkBhdWd1c3RjZWxsYXJz LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IGNvbnN1bHRhbmN5QHZhbmRlcnN0b2sub3JnOyAnQWNl JyAmbHQ7YWNlQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0FjZV0gZHJh ZnQtaWV0Zi1hY2Utb2F1dGgtYXV0aHo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPkhJIEppbSw8YnI+DQo8YnI+DQpJIHRyeSB0 byBhbnN3ZXIgeW91ciBxdWVzdGlvbiw8YnI+DQo8YnI+DQpXaGVuIEkgd2FudCB0byBhY2Nlc3Mg YW4gT0NGIGRldmljZSBJIGNhbiBmaW5kIGl0cyBJUCBhZGRyZXNzIHRocm91Z2ggc2VydmljZSBk aXNjb3ZlcnkgKHJmYzcyNTIgc2VjdGlvbiA3KSB1c2luZyBhbiBydC12YWx1ZSByZWdpc3RlcmVk IGF0IHRoZSBJQU5BIGNvcmUgcGFyYW1ldGVycyByZWdpc3RyeS48YnI+DQpGb3IgZXhhbXBsZSwg d2hlbiBJIHdhbnQgdG8gaW5pdGlhbGl6ZSB0aGUgQVMgSSBoYXZlIHRvIHR5cGUgaW4gdGhlIElQ IGFkZHJlc3Mgb2YgdGhlIEFTLjxicj4NCkZyb20gdGhhdCBtb21lbnQgb24ga2V5cyBhbmQgY2Vy dGlmaWNhdGVzIGNhbiBiZSBjb21wYXJlZCB0byBjb250aW51ZSBpbml0aWFsaXphdGlvbi48YnI+ DQo8YnI+DQpVc2luZyBzZXJ2aWNlIGRpc2NvdmVyeSBjYW4gYXV0b21hdGUgdGhhdCBwcm9jZXNz Ljxicj4NCjxicj4NCk15IHJlcXVlc3QgaXMgdGhhdCBhdXRoeiBkcmFmdCByZWdpc3RlcnMgYW4g cnQtdmFsdWUgaW4gY29yZSBwYXJhbWV0ZXJzIHJlZ2lzdHJ5IGZvciBzZXJ2aWNlIGRpc2NvdmVy eSBvZiB0aGUgQVMsPGJyPg0KdW5sZXNzIGEgZGlmZmVyZW50IHByb2Nlc3MgaGFzIGFscmVhZHkg YmVlbiBlc3RhYmxpc2hlZCBmb3IgQVMgaW5pdGlhbGl6YXRpb24uPGJyPg0KPGJyPg0KTWFueSB0 aGFua3MsPGJyPg0KPGJyPg0KcGV0ZXI8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJk YW5hJnF1b3Q7LHNhbnMtc2VyaWYiPkppbSBTY2hhYWQgc2NocmVlZiBvcCAyMDIwLTA0LTMwIDE3 OjI1OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjMTAxMEZGIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNS4w cHQ7bWFyZ2luLWxlZnQ6MGNtO21hcmdpbi1yaWdodDowY20iPg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICMxMDEwRkYgMS41cHQ7cGFkZGluZzowY20g MGNtIDBjbSA1LjBwdDttYXJnaW4tbGVmdDowY207bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjMTAxMEZGIDEuNXB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNS4wcHQ7bWFyZ2luLWxlZnQ6MGNtO21hcmdpbi1yaWdodDowY20i Pg0KPGRpdiBpZD0icmVwbHlib2R5MSI+DQo8ZGl2Pg0KPHAgY2xhc3M9InYxbXNvbm9ybWFsMSI+ V2hhdCBkbyB5b3UgZXhwZWN0IHRvIHNlZT8mbmJzcDsmbmJzcDsgQnkgZGVmYXVsdCBhIGNsaWVu dCBuZWVkcyB0byBrbm93IHRoYXQgc29tZXRoaW5nIGlzIGFuIEFTIGFuZCBoYXZlIGEga2V5IHRv IGludGVyYWN0IHdpdGggdGhhdCBBUy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJ2MW1zb25v cm1hbDEiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9InYxbXNvbm9ybWFsMSI+Smlt PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0idjFtc29ub3JtYWwxIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJ2MW1zb25vcm1hbDEiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBw dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJ2MW1zb25vcm1hbDEiPjxz dHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+RnJvbTo8L3NwYW4+PC9zdHJvbmc+IEFjZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFjZS1i b3VuY2VzQGlldGYub3JnIj5hY2UtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7DQo8c3Ryb25nPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk9u IEJlaGFsZiBPZiA8L3NwYW4+PC9zdHJvbmc+UGV0ZXIgdmFuIGRlciBTdG9rPGJyPg0KPHN0cm9u Zz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5TZW50Ojwvc3Bhbj48L3N0cm9uZz4gV2VkbmVzZGF5LCBBcHJpbCAyOSwgMjAyMCAxMTo1NyBQ TTxicj4NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+VG86PC9zcGFuPjwvc3Ryb25nPiBBY2UgJmx0OzxhIGhyZWY9Im1haWx0 bzphY2VAaWV0Zi5vcmciPmFjZUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHN0cm9uZz48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TdWJqZWN0 Ojwvc3Bhbj48L3N0cm9uZz4gW0FjZV0gZHJhZnQtaWV0Zi1hY2Utb2F1dGgtYXV0aHo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0idjFtc29ub3JtYWwxIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJ2MW1zb25vcm1hbDEiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+ SGkgYXV0aHogYXV0aG9ycywsPGJyPg0KPGJyPg0KV2hpbGUgaW1wbGVtZW50aW5nIGEgdmVyc2lv biBvZiBBUywgSSBub3RpY2VkIHRoYXQgdGhlcmUgaXMgbm8gcmVzb3VyY2UgdHlwZSAocnQpIHJl Z2lzdGVyZWQgZm9yIC8ud2VsbC1rbm93bi9jb3JlIGRpc2NvdmVyeS48YnI+DQpJcyB0aGlzIHZv bHVudGFyeT88YnI+DQpJZiBub3QsIGNhbiBpdCBzdGlsbCBiZSBhZGRlZD88YnI+DQo8YnI+DQp0 aGFua3MsPGJyPg0KPGJyPg0KcGV0ZXIgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBpZD0i djFzaWduYXR1cmUiPg0KPHAgY2xhc3M9InYxbXNvbm9ybWFsMSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj4t LQ0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJ2MW1zb25vcm1hbDEi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij5QZXRlciB2YW4gZGVyIFN0b2s8YnI+DQp2YW5kZXJzdG9rIGNvbnN1bHRhbmN5 PGJyPg0KbWFpbHRvOiA8YSBocmVmPSJtYWlsdG86Y29uc3VsdGFuY3lAdmFuZGVyc3Rvay5vcmci PmNvbnN1bHRhbmN5QHZhbmRlcnN0b2sub3JnPC9hPiwNCjxhIGhyZWY9Im1haWx0bzpzdG9rY29u c0BiYmhtYWlsLm5sIj5zdG9rY29uc0BiYmhtYWlsLm5sPC9hPjxicj4NCnd3dzogPGEgaHJlZj0i aHR0cDovL3d3dy52YW5kZXJzdG9rLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnd3dy52YW5kZXJzdG9r Lm9yZzwvYT48YnI+DQp0ZWwgTkw6ICYjNDM7MzEoMCk0OTI0NzQ2NzMgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7RjogJiM0MzszMygwKTk2NjAxNTI0ODwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KQWNlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpB Y2VAaWV0Zi5vcmciPkFjZUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6cab8f7fcdbf441fbc3ca747cfb09a72combitechse_-- From nobody Sun May 3 23:52:03 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 634C33A0CB2 for ; Sun, 3 May 2020 23:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 gp-EPJI1iYdC for ; Sun, 3 May 2020 23:51:57 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A91DF3A0C37 for ; Sun, 3 May 2020 23:51:57 -0700 (PDT) Received: from client-0127.vpn.uni-bremen.de (client-0127.vpn.uni-bremen.de [134.102.107.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49FtnQ442Xzyyg; Mon, 4 May 2020 08:51:54 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <6cab8f7fcdbf441fbc3ca747cfb09a72@combitech.se> Date: Mon, 4 May 2020 08:51:54 +0200 Cc: peter van der Stok , Jim Schaad , Ace X-Mao-Original-Outgoing-Id: 610267914.0958951-13b31278f0bb7d30f20143c3b58a81d1 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56d31e581571721e176b59db20e08c23@bbhmail.nl> <00f101d61f03$a26bb920$e7432b60$@augustcellars.com> <0873a3115cab89036002cf42b1c97608@bbhmail.nl> <6cab8f7fcdbf441fbc3ca747cfb09a72@combitech.se> To: Seitz Ludwig X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Ace] draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 04 May 2020 06:52:01 -0000 On 2020-05-04, at 08:42, Seitz Ludwig wrote: >=20 > For the sake of getting the document finished before I die of old age = ;-) would it be possible to specify this in a separate document? I think there may be multiple of these RT registrations, because the = fact that a resource is part of an AS is only part of the information = that is needed: The RT could tell us more about the way the AS wants to = be used. I think that is a strong argument to *not* do these RT registrations in = the framework, because we will not have enough imagination to catch them = all. So my recommendation would indeed be a separate document. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon May 4 00:15:14 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A443A0CFF for ; Mon, 4 May 2020 00:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bbhmail.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aVuLqsVwd7J for ; Mon, 4 May 2020 00:15:11 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0174.hostedemail.com [216.40.44.174]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6334F3A0CFE for ; Mon, 4 May 2020 00:15:11 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay03.hostedemail.com (Postfix) with ESMTP id 0C198801B132; Mon, 4 May 2020 07:15:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h= mime-version:content-type:date:from:to:cc:subject:reply-to :in-reply-to:references:message-id; s=key; bh=W6Jcmyg0/eAXNSB0fA eiyXlmgYzA8V3g5ILGBUyopmQ=; b=NXVJmcp92VRa7ukQkoDKdVgp0ibSPj2SID ts0xJNher7O03nDZ3pOTpJj/aAq7RP4gMkPGURm6CAl2LvbmWjj07yEHUV3hBzbk C8OnQL0VBoJAPgW8LFALtGx5VLjocKhoVFzOjT+5YJIlPseEDtmPJvTLWNkgRrOE lX0XfCxcY= X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, -10, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, , RULES_HIT:41:72:152:355:379:582:599:800:960:962:967:973:983:988:989:1152:1189:1208:1212:1221:1260:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1534:1542:1575:1588:1589:1592:1594:1711:1730:1776:1792:2068:2069:2198:2199:2525:2553:2561:2564:2682:2685:2693:2827:2859:2892:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3352:3622:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:4321:4860:5007:6248:6261:6299:6657:6659:6678:7903:8603:9010:9025:9036:9177:10004:10400:10848:11232:11658:11783:11914:12043:12050:12109:12114:12291:12379:12438:12683:12740:12895:13071:13139:13161:13229:13846:13972:14093:14095:14096:14180:14181:14721:21060:21080:21433:21451:21627:21740:21939:30004:30054:30060:30075:30090:30091, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:0, DNSBL:none, Custom_rules:0:0:0, LFtime:1, LUA_SUMMARY:none X-HE-Tag: feet76_4a299dfbc3d04 X-Filterd-Recvd-Size: 4964 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf02.hostedemail.com (Postfix) with ESMTPA; Mon, 4 May 2020 07:15:09 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_3e7e5f0fe6909e544b09d18222a91d88" Date: Mon, 04 May 2020 09:15:08 +0200 From: Peter van der Stok To: Carsten Bormann Cc: Seitz Ludwig , Jim Schaad , peter van der Stok , Ace Reply-To: consultancy@vanderstok.org In-Reply-To: References: <56d31e581571721e176b59db20e08c23@bbhmail.nl> <00f101d61f03$a26bb920$e7432b60$@augustcellars.com> <0873a3115cab89036002cf42b1c97608@bbhmail.nl> <6cab8f7fcdbf441fbc3ca747cfb09a72@combitech.se> User-Agent: Roundcube Webmail/1.4-rc2 Message-ID: <0dd6734f0465e6917e5b94b578bb43db@bbhmail.nl> X-Sender: stokcons@bbhmail.nl Organization: vanderstok consultancy X-Originating-IP: [5.206.216.229] Archived-At: Subject: Re: [Ace] draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 04 May 2020 07:15:13 -0000 --=_3e7e5f0fe6909e544b09d18222a91d88 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed Hi Carsten, The imagination will not have finished its work in 10 yeras time if coap and the authorization will enjoy the success they merit. Also I don't see anybody being ready to start such a document the coming month. Do you see another document in which a first set of these registrations can be added? FYI, today I do my iplementation and (to my regret) will invent something of my own. cheerio, Peter Carsten Bormann schreef op 2020-05-04 08:51: > On 2020-05-04, at 08:42, Seitz Ludwig wrote: > >> For the sake of getting the document finished before I die of old age ;-) would it be possible to specify this in a separate document? > > I think there may be multiple of these RT registrations, because the fact that a resource is part of an AS is only part of the information that is needed: The RT could tell us more about the way the AS wants to be used. > > I think that is a strong argument to *not* do these RT registrations in the framework, because we will not have enough imagination to catch them all. > > So my recommendation would indeed be a separate document. > > Grüße, Carsten > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --=_3e7e5f0fe6909e544b09d18222a91d88 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi Carsten,

The imagination will not have finished its work in 1= 0 yeras time if coap and the authorization will enjoy the success they meri= t.
Also I don't see anybody being ready to start such  a document= the coming month.
Do you see another document in which a first set of= these registrations can be added?

FYI, today I do my iplementat= ion and (to my regret) will invent something of my own. 

ch= eerio,

Peter

Carsten Bormann schreef op 2020-05-04 08:51:

= On 2020-05-04, at 08:42, Seitz Ludwig <ludwig.seitz@combitech.se> wrote:

For the sake of getting the document finished be= fore I die of old age ;-) would it be possible to specify this in a separat= e document?

I think there may be multiple of these RT registrations, because the = fact that a resource is part of an AS is only part of the information that = is needed: The RT could tell us more about the way the AS wants to be used= =2E

I think that is a strong argument to *not* do these RT regis= trations in the framework, because we will not have enough imagination to c= atch them all.

So my recommendation would indeed be a separate d= ocument.

Grüße, Carsten

__________________= _____________________________
Ace mailing list
Ace@ietf.org
https://www.ie= tf.org/mailman/listinfo/ace
--=_3e7e5f0fe6909e544b09d18222a91d88-- From nobody Mon May 4 00:21:12 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A83D63A0D10 for ; Mon, 4 May 2020 00:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 aBoMCyfzbm70 for ; Mon, 4 May 2020 00:21:08 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52FEB3A0D0E for ; Mon, 4 May 2020 00:21:08 -0700 (PDT) Received: from wangari.tzi.org (p54BDED4C.dip0.t-ipconnect.de [84.189.237.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49FvR6620Yzyyy; Mon, 4 May 2020 09:21:06 +0200 (CEST) From: Olaf Bergmann To: Peter van der Stok Cc: Jim Schaad , consultancy@vanderstok.org, "'Ace'" References: <56d31e581571721e176b59db20e08c23@bbhmail.nl> <00f101d61f03$a26bb920$e7432b60$@augustcellars.com> <0873a3115cab89036002cf42b1c97608@bbhmail.nl> Date: Mon, 04 May 2020 09:21:06 +0200 In-Reply-To: <0873a3115cab89036002cf42b1c97608@bbhmail.nl> (Peter van der Stok's message of "Fri, 01 May 2020 08:56:20 +0200") Message-ID: <87mu6o6u8t.fsf@wangari> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ace] draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 04 May 2020 07:21:11 -0000 Hi Peter, Peter van der Stok writes: > When I want to access an OCF device I can find its IP address through > service discovery (rfc7252 section 7) using an rt-value registered at > the IANA core parameters registry. For example, when I want to > initialize the AS I have to type in the IP address of the AS. From > that moment on keys and certificates can be compared to continue > initialization. > > Using service discovery can automate that process. > > My request is that authz draft registers an rt-value in core > parameters registry for service discovery of the AS, unless a > different process has already been established for AS initialization. That is exaclty what originally has been done in section 9 of draft-gerdes-ace-dcaf-authorize [1]. Somehow, this got lost in the process. [1] https://tools.ietf.org/html/draft-gerdes-ace-dcaf-authorize-04#page-30 Gr=C3=BC=C3=9Fe Olaf From nobody Mon May 4 00:21:31 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A403A0D10 for ; Mon, 4 May 2020 00:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 93oHhixn4BM6 for ; Mon, 4 May 2020 00:21:27 -0700 (PDT) Received: from weald2.air.saab.se (weald2.air.saab.se [136.163.212.4]) (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 99DE53A0D16 for ; Mon, 4 May 2020 00:21:25 -0700 (PDT) Received: from mailhub2.air.saab.se ([136.163.213.5]) by weald2.air.saab.se (8.14.4/8.14.4) with ESMTP id 0447LHfG011982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 May 2020 09:21:17 +0200 Received: from corpappl16589.corp.saab.se (corpappl16589.corp.saab.se [10.12.12.95]) by mailhub2.air.saab.se (8.13.8/8.13.8) with ESMTP id 0447KDYY005909 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 May 2020 09:20:13 +0200 Received: from corpappl16593.corp.saab.se (10.12.12.125) by corpappl16589.corp.saab.se (10.12.12.95) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Mon, 4 May 2020 09:20:13 +0200 Received: from corpappl16593.corp.saab.se ([fe80::b4c9:ca69:a80d:fa3]) by corpappl16593.corp.saab.se ([fe80::b4c9:ca69:a80d:fa3%4]) with mapi id 15.01.1847.009; Mon, 4 May 2020 09:20:13 +0200 From: Seitz Ludwig To: "consultancy@vanderstok.org" , Carsten Bormann CC: Jim Schaad , Ace Thread-Topic: [Ace] draft-ietf-ace-oauth-authz Thread-Index: AQHWHrytAFclswHm7kqaQRCF7GbsM6iRqECAgAED/ACABNRcQP//4WUAgAAGfgCAACKdgA== Date: Mon, 4 May 2020 07:20:12 +0000 Message-ID: <9c8449d42036493fa67bd5b3adf2ac8d@combitech.se> References: <56d31e581571721e176b59db20e08c23@bbhmail.nl> <00f101d61f03$a26bb920$e7432b60$@augustcellars.com> <0873a3115cab89036002cf42b1c97608@bbhmail.nl> <6cab8f7fcdbf441fbc3ca747cfb09a72@combitech.se> <0dd6734f0465e6917e5b94b578bb43db@bbhmail.nl> In-Reply-To: <0dd6734f0465e6917e5b94b578bb43db@bbhmail.nl> Accept-Language: en-SE, sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.12.13.198] Content-Type: multipart/alternative; boundary="_000_9c8449d42036493fa67bd5b3adf2ac8dcombitechse_" MIME-Version: 1.0 X-Saab-MailScanner-Information: Please contact the ISP for more information X-Saab-MailScanner-ID: 0447KDYY005909 X-Saab-MailScanner: Found to be clean X-Saab-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=0.002, required 5, autolearn=not spam, ALL_TRUSTED -1.00, HTML_MESSAGE 0.00, SURBL_BLOCKED 1.00, URIBL_BLOCKED 0.00) X-Saab-MailScanner-From: ludwig.seitz@combitech.se X-Saab-MailScanner-Watermark: 1589181614.65757@WeQ9v8UG1/YVneS4hz54/g X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (weald2.air.saab.se [136.163.212.4]); Mon, 04 May 2020 09:21:17 +0200 (CEST) Archived-At: Subject: Re: [Ace] draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 04 May 2020 07:21:30 -0000 --_000_9c8449d42036493fa67bd5b3adf2ac8dcombitechse_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGV0ZXIsDQoNCldoeSBub3QgZG9jdW1lbnQgd2hhdCB5b3UgaW52ZW50IGluIGEgZHJhZnQ/IFRv IG1lIGl0IHdvdWxkIGJlIGEgZ29vZCBzdGFydGluZyBwb2ludC4NCg0KL0x1ZHdpZw0KDQpGcm9t OiBQZXRlciB2YW4gZGVyIFN0b2sgPHN0b2tjb25zQGJiaG1haWwubmw+DQpTZW50OiBkZW4gNCBt YWogMjAyMCAwOToxNQ0KVG86IENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPg0KQ2M6IFNl aXR6IEx1ZHdpZyA8bHVkd2lnLnNlaXR6QGNvbWJpdGVjaC5zZT47IEppbSBTY2hhYWQgPGlldGZA YXVndXN0Y2VsbGFycy5jb20+OyBwZXRlciB2YW4gZGVyIFN0b2sgPGNvbnN1bHRhbmN5QHZhbmRl cnN0b2sub3JnPjsgQWNlIDxhY2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0FjZV0gZHJhZnQt aWV0Zi1hY2Utb2F1dGgtYXV0aHoNCg0KSGkgQ2Fyc3RlbiwNCg0KVGhlIGltYWdpbmF0aW9uIHdp bGwgbm90IGhhdmUgZmluaXNoZWQgaXRzIHdvcmsgaW4gMTAgeWVyYXMgdGltZSBpZiBjb2FwIGFu ZCB0aGUgYXV0aG9yaXphdGlvbiB3aWxsIGVuam95IHRoZSBzdWNjZXNzIHRoZXkgbWVyaXQuDQpB bHNvIEkgZG9uJ3Qgc2VlIGFueWJvZHkgYmVpbmcgcmVhZHkgdG8gc3RhcnQgc3VjaCAgYSBkb2N1 bWVudCB0aGUgY29taW5nIG1vbnRoLg0KRG8geW91IHNlZSBhbm90aGVyIGRvY3VtZW50IGluIHdo aWNoIGEgZmlyc3Qgc2V0IG9mIHRoZXNlIHJlZ2lzdHJhdGlvbnMgY2FuIGJlIGFkZGVkPw0KDQpG WUksIHRvZGF5IEkgZG8gbXkgaXBsZW1lbnRhdGlvbiBhbmQgKHRvIG15IHJlZ3JldCkgd2lsbCBp bnZlbnQgc29tZXRoaW5nIG9mIG15IG93bi4NCg0KY2hlZXJpbywNCg0KUGV0ZXINCg0KDQpDYXJz dGVuIEJvcm1hbm4gc2NocmVlZiBvcCAyMDIwLTA1LTA0IDA4OjUxOg0KT24gMjAyMC0wNS0wNCwg YXQgMDg6NDIsIFNlaXR6IEx1ZHdpZyA8bHVkd2lnLnNlaXR6QGNvbWJpdGVjaC5zZTxtYWlsdG86 bHVkd2lnLnNlaXR6QGNvbWJpdGVjaC5zZT4+IHdyb3RlOg0KDQpGb3IgdGhlIHNha2Ugb2YgZ2V0 dGluZyB0aGUgZG9jdW1lbnQgZmluaXNoZWQgYmVmb3JlIEkgZGllIG9mIG9sZCBhZ2UgOy0pIHdv dWxkIGl0IGJlIHBvc3NpYmxlIHRvIHNwZWNpZnkgdGhpcyBpbiBhIHNlcGFyYXRlIGRvY3VtZW50 Pw0KDQpJIHRoaW5rIHRoZXJlIG1heSBiZSBtdWx0aXBsZSBvZiB0aGVzZSBSVCByZWdpc3RyYXRp b25zLCBiZWNhdXNlIHRoZSBmYWN0IHRoYXQgYSByZXNvdXJjZSBpcyBwYXJ0IG9mIGFuIEFTIGlz IG9ubHkgcGFydCBvZiB0aGUgaW5mb3JtYXRpb24gdGhhdCBpcyBuZWVkZWQ6IFRoZSBSVCBjb3Vs ZCB0ZWxsIHVzIG1vcmUgYWJvdXQgdGhlIHdheSB0aGUgQVMgd2FudHMgdG8gYmUgdXNlZC4NCg0K SSB0aGluayB0aGF0IGlzIGEgc3Ryb25nIGFyZ3VtZW50IHRvICpub3QqIGRvIHRoZXNlIFJUIHJl Z2lzdHJhdGlvbnMgaW4gdGhlIGZyYW1ld29yaywgYmVjYXVzZSB3ZSB3aWxsIG5vdCBoYXZlIGVu b3VnaCBpbWFnaW5hdGlvbiB0byBjYXRjaCB0aGVtIGFsbC4NCg0KU28gbXkgcmVjb21tZW5kYXRp b24gd291bGQgaW5kZWVkIGJlIGEgc2VwYXJhdGUgZG9jdW1lbnQuDQoNCkdyw7zDn2UsIENhcnN0 ZW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkFj ZSBtYWlsaW5nIGxpc3QNCkFjZUBpZXRmLm9yZzxtYWlsdG86QWNlQGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UNCg== --_000_9c8449d42036493fa67bd5b3adf2ac8dcombitechse_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow Y207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz ZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UGV0ZXIs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5XaHkgbm90IGRvY3Vt ZW50IHdoYXQgeW91IGludmVudCBpbiBhIGRyYWZ0PyBUbyBtZSBpdCB3b3VsZCBiZSBhIGdvb2Qg c3RhcnRpbmcgcG9pbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij4vTHVkd2lnPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBQZXRl ciB2YW4gZGVyIFN0b2sgJmx0O3N0b2tjb25zQGJiaG1haWwubmwmZ3Q7DQo8YnI+DQo8Yj5TZW50 OjwvYj4gZGVuIDQgbWFqIDIwMjAgMDk6MTU8YnI+DQo8Yj5Ubzo8L2I+IENhcnN0ZW4gQm9ybWFu biAmbHQ7Y2Fib0B0emkub3JnJmd0Ozxicj4NCjxiPkNjOjwvYj4gU2VpdHogTHVkd2lnICZsdDts dWR3aWcuc2VpdHpAY29tYml0ZWNoLnNlJmd0OzsgSmltIFNjaGFhZCAmbHQ7aWV0ZkBhdWd1c3Rj ZWxsYXJzLmNvbSZndDs7IHBldGVyIHZhbiBkZXIgU3RvayAmbHQ7Y29uc3VsdGFuY3lAdmFuZGVy c3Rvay5vcmcmZ3Q7OyBBY2UgJmx0O2FjZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtBY2VdIGRyYWZ0LWlldGYtYWNlLW9hdXRoLWF1dGh6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5IaSBDYXJzdGVu LDxicj4NCjxicj4NClRoZSBpbWFnaW5hdGlvbiB3aWxsIG5vdCBoYXZlIGZpbmlzaGVkIGl0cyB3 b3JrIGluIDEwIHllcmFzIHRpbWUgaWYgY29hcCBhbmQgdGhlIGF1dGhvcml6YXRpb24gd2lsbCBl bmpveSB0aGUgc3VjY2VzcyB0aGV5IG1lcml0Ljxicj4NCkFsc28gSSBkb24ndCBzZWUgYW55Ym9k eSBiZWluZyByZWFkeSB0byBzdGFydCBzdWNoJm5ic3A7IGEgZG9jdW1lbnQgdGhlIGNvbWluZyBt b250aC48YnI+DQpEbyB5b3Ugc2VlIGFub3RoZXIgZG9jdW1lbnQgaW4gd2hpY2ggYSBmaXJzdCBz ZXQgb2YgdGhlc2UgcmVnaXN0cmF0aW9ucyBjYW4gYmUgYWRkZWQ/PGJyPg0KPGJyPg0KRllJLCB0 b2RheSBJIGRvIG15IGlwbGVtZW50YXRpb24gYW5kICh0byBteSByZWdyZXQpIHdpbGwgaW52ZW50 IHNvbWV0aGluZyBvZiBteSBvd24uJm5ic3A7PGJyPg0KPGJyPg0KY2hlZXJpbyw8YnI+DQo8YnI+ DQpQZXRlcjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1z ZXJpZiI+Q2Fyc3RlbiBCb3JtYW5uIHNjaHJlZWYgb3AgMjAyMC0wNS0wNCAwODo1MTo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgIzEwMTBGRiAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDUuMHB0O21hcmdpbi1s ZWZ0OjBjbTttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+T24gMjAyMC0wNS0wNCwgYXQgMDg6NDIsIFNlaXR6IEx1ZHdpZyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmx1ZHdpZy5zZWl0ekBjb21iaXRlY2guc2UiPmx1ZHdpZy5zZWl0ekBjb21iaXRl Y2guc2U8L2E+Jmd0OyB3cm90ZToNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjMTAxMEZGIDEuNXB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNS4wcHQ7bWFyZ2luLWxlZnQ6MGNtO21hcmdpbi1yaWdodDowY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCkZvciB0aGUgc2FrZSBvZiBnZXR0 aW5nIHRoZSBkb2N1bWVudCBmaW5pc2hlZCBiZWZvcmUgSSBkaWUgb2Ygb2xkIGFnZSA7LSkgd291 bGQgaXQgYmUgcG9zc2libGUgdG8gc3BlY2lmeSB0aGlzIGluIGEgc2VwYXJhdGUgZG9jdW1lbnQ/ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPjxicj4NCkkgdGhpbmsgdGhlcmUgbWF5IGJlIG11bHRpcGxlIG9mIHRoZXNl IFJUIHJlZ2lzdHJhdGlvbnMsIGJlY2F1c2UgdGhlIGZhY3QgdGhhdCBhIHJlc291cmNlIGlzIHBh cnQgb2YgYW4gQVMgaXMgb25seSBwYXJ0IG9mIHRoZSBpbmZvcm1hdGlvbiB0aGF0IGlzIG5lZWRl ZDogVGhlIFJUIGNvdWxkIHRlbGwgdXMgbW9yZSBhYm91dCB0aGUgd2F5IHRoZSBBUyB3YW50cyB0 byBiZSB1c2VkLjxicj4NCjxicj4NCkkgdGhpbmsgdGhhdCBpcyBhIHN0cm9uZyBhcmd1bWVudCB0 byAqbm90KiBkbyB0aGVzZSBSVCByZWdpc3RyYXRpb25zIGluIHRoZSBmcmFtZXdvcmssIGJlY2F1 c2Ugd2Ugd2lsbCBub3QgaGF2ZSBlbm91Z2ggaW1hZ2luYXRpb24gdG8gY2F0Y2ggdGhlbSBhbGwu PGJyPg0KPGJyPg0KU28gbXkgcmVjb21tZW5kYXRpb24gd291bGQgaW5kZWVkIGJlIGEgc2VwYXJh dGUgZG9jdW1lbnQuPGJyPg0KPGJyPg0KR3LDvMOfZSwgQ2Fyc3Rlbjxicj4NCjxicj4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KQWNlIG1haWxp bmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpBY2VAaWV0Zi5vcmciPkFjZUBpZXRmLm9yZzwv YT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Fj ZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v YWNlPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9c8449d42036493fa67bd5b3adf2ac8dcombitechse_-- From nobody Mon May 4 00:42:51 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 049803A0D2B; Mon, 4 May 2020 00:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwTuqZqqjzLf; Mon, 4 May 2020 00:42:46 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2079.outbound.protection.outlook.com [40.107.21.79]) (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 232363A0D28; Mon, 4 May 2020 00:42:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GZ76euCQjoFKWuaNGmyhVjMS4VVjTNviEG2bFUX0N18/l1QLBwc+eqDKAduMZl3I6U3UsDKujLtkUaL2jOu4AMNFLo4WWaQYBlI5AF/68/KXO81ZEtaONPaGkiDU2sxiQiP5tCxypeB6kuO2tXgFm9Klj3bB3FOROY/xRtDN/CS9Eu2l+k7HXPTU6O/jb9P4EgMMEcwo7Cg74hO906MJLWT3EiBWDW3cAlDlF6clHQixNIgYLeE7AO+8PjU7k9lqvvq1cpLXSQG0EQ1H4RcYBVXcdRERY8gLlyuZJC6iseAp2e7rlmJvqxOnyYjI5R0Ct0sl9lWZalt6syIlebhXWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5lTkkMs9964C0qrIjdMKZ/WCZWCGA9ZuGV92NMrUbcc=; b=b6b/etdva4YmSjxZRKnA9u1TrtstB095tXHZ7bqTdXw3MyKF0DJ9UM5dEeTMYH3tnAmxVSQkA+OwLrTfiJGd7KesktbObqC7VIfKgMbP3h9rilDCHN7MaUn3Ej3TUfm0QAsfT036/TGSed8sQxF4WPzhh5IKF0GyCyYjDwn84olqga5p2KYLdQ67CkNE9zl6EVkwwAnKCnq4A7y8IB+aglaZuIVHVP1W808+TsgbA2K0qMH00a3OYUHQoLKcFg5K+VsyPtJY7QwIwZjk+RB4zh7Bps8QMZt7bmRzuielJI1v8g8/l9dt7zmYrofRsaNx5/7ammH3GzYbN6kBs/iALQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5lTkkMs9964C0qrIjdMKZ/WCZWCGA9ZuGV92NMrUbcc=; b=QSj3AHAWkso0qTrcn25J4qzHl7DUekb2nxICRDg0abZ3ssA6Nee8Av+cG38CRWZF6m4AFd43ipRm9u3Gkn2A9ZyOxiTfXBbK0v+j3xjxXSY/SSkFKPUGxw+lLl/8LfrZ4Aca+XRsKYpiaczZZP1phSEd5+26fKb1vflVP0fzA70= Received: from AM7PR07MB6945.eurprd07.prod.outlook.com (2603:10a6:20b:1bf::11) by AM7PR07MB6945.eurprd07.prod.outlook.com (2603:10a6:20b:1bf::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.18; Mon, 4 May 2020 07:42:42 +0000 Received: from AM7PR07MB6945.eurprd07.prod.outlook.com ([fe80::55ba:3006:67fc:f931]) by AM7PR07MB6945.eurprd07.prod.outlook.com ([fe80::55ba:3006:67fc:f931%7]) with mapi id 15.20.2979.024; Mon, 4 May 2020 07:42:42 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Laurence Lundblade , "cose@ietf.org" , "ace@ietf.org" , "ace-chairs@ietf.org" , "cose-chairs@ietf.org" , Benjamin Kaduk CC: =?utf-8?B?Sm9lbCBIw7ZnbHVuZA==?= Thread-Topic: [Ace] [COSE] draft-raza-ace-cbor-certificates-04.txt Thread-Index: AQHWHL9/AQkz8jksrU+IVD0bq1nzAqiOdicAgAN8fICABcSUAA== Date: Mon, 4 May 2020 07:42:42 +0000 Message-ID: References: <8B4A9572-3770-416E-B937-1902AFC07DA7@island-resort.com> <964634A4-7B61-4CEF-8ED0-6A9A48D984CD@ericsson.com> <3BB4FFA8-AABD-4520-9B21-1F0B0CAFB08C@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: island-resort.com; dkim=none (message not signed) header.d=none;island-resort.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.85] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1c58777e-8b71-4e00-888e-08d7effebaad x-ms-traffictypediagnostic: AM7PR07MB6945: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 03932714EB x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xVjQRVJwjWPwgvULWEiuH+XtKUy/iw1+xjpAMM70xhGjLmTn8vGK7fVamrxDfJ3UQATSHCaeW+jvUZDSXrjS5QqWMNWBItwVBK3sgK4vtlv/pgiMHpDzlskNBCqUw7L2r3rc9x9XQPlkK0v5ZywBIpTACh5D3zsl+D88qBIxEl4l+Qz7E3wiw9nm+LjcgzKnr2X/zJJOySuRZJKJc/C/Vm7FDZAs7uCrp2J3dDHbhnlV6naPxx58fVKjSYsz90yJ1w/+NKnVmchK5hMA8x3oySYvSelAsTfjtPsR08EGwAthjEyxBcsBNmHIjI6M1LAJ9dHF0KMJKE0CTZExuYKlxB8oqQUZ6wt7ABsvUM7MtBe2747+tWtacay774OB+SkklWs3eb+qoW3pr7ToidqaDxpcFirhu9FHCNAgaiogVUGqnYJCpAplh31TYFOCzl3mKtWoZ668BZ0b3bRDK2RwslhM+UZiUykBG5C0g8p5RlVa7Bzeb8mYHhurh43rd3SinTa6SgqJqphqYsavHKJfEw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB6945.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(39860400002)(396003)(136003)(366004)(85182001)(36756003)(2906002)(186003)(85202003)(71200400001)(6486002)(53546011)(8936002)(8676002)(26005)(6506007)(316002)(110136005)(4326008)(6512007)(66946007)(966005)(478600001)(66574012)(33656002)(66556008)(66476007)(76116006)(5660300002)(66446008)(64756008)(86362001)(2616005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: fzL3WARG+P3TJyofjCHtIk73LxdZRZ4CsXcd75k19MzdOpqYDazwP1Mn6C0WOlBBkUgSxVFkcvzfrGAIJYJLW8zZe/clGWNJaxYE4uZpQO+4f/LsKUC3sUSdYAyqgNas+niugEui95pYae3urbh4DhEamKzmULoBdJUNMJZrBPGYL6Kb27qd1zquf1jwfymHr8NG+lILVvyzmqXIycE9bumeadBo58bnQfgWBqPvn9TULjwLYBEVF1S0LC/fMHXHIB+Lacm+8PSuY5CAUVg9/RTDdNBTtkDVDSVdjSb/lZUVn5Usw+K9ZVSGRjKs896agJ29oRKXzYf4OPkPY/R+U/iYDyHv/K7f3zkowAl8X2f0vQHmhFEtC3rNPviPZ9nMFBFx5OBwPnu0/S/p2ScisU7lu+4XCoK14oqIpPrIUAkPkM/+aj8Cu0qeC5O0ILIuoEkz/TxRXQpXUt7uM2Qfel7ZheHobMCZtjPiid28NU7Ic65tjBL8s/hS/u0YEnhaf30HSVZErfv5aSWxUf7zXVQ6D/g2A9g+MirXLzGKx1GlPYdfk+H50bjz6jp61WBf0F++/J9WVbloynwzfYPuDXl0grEoKJ3+XRbljZ1TrlQiUTuAo02v3aZNHpS1yyblnmoV6jQUyvyj87UF7reovjaIPzMcNglAmL5Fjuu1fJbkByP51FAVjloQqYT4RDzYNMFAhqwaeGT2Z98/pHJtYSx8I0T6P47dWQOWoetPvr2MITs8dMrwwUxcctajx0kbT/q1dghbN+2Qhz8b93/C8URyIY3h3FDYf+ODElEHXGM= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CE4654CA93F046F79768C3F67166A3FFericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1c58777e-8b71-4e00-888e-08d7effebaad X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2020 07:42:42.8204 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ovmrP30zwHWf9SWLqiDLkZVTBvHlwUem9z5Cefw/270aw9Kkt1lOm4twhftHoHxdoPR2Pbz94pb95gzA+7ec2dmtVvwchhP8BbEa6er95MQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6945 Archived-At: Subject: Re: [Ace] [COSE] draft-raza-ace-cbor-certificates-04.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 04 May 2020 07:42:49 -0000 --_000_CE4654CA93F046F79768C3F67166A3FFericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTGF1cmVuY2UsIGFuZCBhbGwsDQoNClRoYW5rcyBmb3IgcHJvdmlkaW5nIGEgdGF4b25vbXku IEFzIG1lbnRpb25lZCwgdHlwZSAwIGlzIGNsZWFybHkgaW4gdGhlIGN1cnJlbnQgZHJhZnQgQ09T RSBjaGFydGVyLCBhbmQgd2Ugc2VlIGFsc28gdGhlIG5lZWQgZm9yIGEgcmVwcmVzZW50YXRpb24g b2YgdGhlIFguNTA5IHByb2ZpbGUgaW4gUkZDIDc5MjUgd2hpY2ggcmVsaWV2ZXMgY29uc3RyYWlu ZWQgZGV2aWNlcyBmcm9tIGltcGxlbWVudGluZyBERVIvQVNOLjEgZW5jb2RpbmcgYXMgd2VsbCBh cyByZS1lbmNvZGluZy9kZWNvbXByZXNzaW5nIGluIG9yZGVyIHRvIHZlcmlmeS4gV2hldGhlciB0 aGlzIGlzIHR5cGUgMSBhcyBwcm9wb3NlZCBpbiB0aGUgZHJhZnQsIG9yIHR5cGUgMiBhcyB5b3Ug cHJvcG9zZSwgaXMgb3BlbiBmb3IgZGlzY3Vzc2lvbi4gSSBiZWxpZXZlIEkgc3BlYWsgb24gYmVo YWxmIG9mIHRoZSBhdXRob3JzIGhlcmUuDQoNCkEgcXVlc3Rpb24gZm9yIHRoZSBjaGFpcnMgYW5k IEFEOiBJcyBpdC9jYW4gaXQgYmUgaW4gdGhlIHNjb3BlIG9mIENPU0Ugb3IgQUNFIHRvIGRlZmlu ZSB0eXBlIDEvMj8gT3IgZG8geW91IG5lZWQgbW9yZSBzaG93IG9mIGludGVyZXN0IGZyb20gdGhl IGNvbW11bml0eSB0byBzZWUgaWYgdGhpcyBpcyB3b3J0aCBwdXJzdWluZyBhdCBhbGw/DQoNCkfD tnJhbg0KDQoNCg0KRnJvbTogTGF1cmVuY2UgTHVuZGJsYWRlIDxsZ2xAaXNsYW5kLXJlc29ydC5j b20+DQpEYXRlOiBUaHVyc2RheSwgMzAgQXByaWwgMjAyMCBhdCAxOTozOA0KVG86IEfDtnJhbiBT ZWxhbmRlciA8Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tPg0KQ2M6IEfDtnJhbiBTZWxhbmRl ciA8Z29yYW4uc2VsYW5kZXI9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc+LCBKb2VsIEjD tmdsdW5kIDxqb2VsLmhvZ2x1bmRAZ21haWwuY29tPiwgImNvc2VAaWV0Zi5vcmciIDxjb3NlQGll dGYub3JnPiwgImFjZUBpZXRmLm9yZyIgPGFjZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbQWNl XSBbQ09TRV0gZHJhZnQtcmF6YS1hY2UtY2Jvci1jZXJ0aWZpY2F0ZXMtMDQudHh0DQoNCkhpIEfD tnJhbiwNCg0KSSB1bmRlcnN0YW5kIHlvdXIgdHdvIHR5cGVzIG9mIG5hdGl2ZSBDQk9SIGNlcnRz LCBhbmQgcmFpc2UgeW91IGJ5IG9uZS4gSeKAmXZlIGFzc3VtZWQgQ09TRSBiZWNhdXNlIGl0IHNl ZW1zIGEgY2xlYXIgY2hvaWNlIHRvIG1lIChubyBzaXplIGlzc3VlLCBjb2RlIHJlIHVzZSkuDQoN CjApIENvbXByZXNzZWQvcmUtZW5jb2RlZA0KLSBVc2VzIENCT1IgU2VxdWVuY2UgdGhhdCBleGFj dGx5IG1pcnJvcnMgWC41MDkgZnJvbSBSYXphIGRyYWZ0DQotIFJlZHVjZXMgc2l6ZSBvZiBjZXJ0 LCBidXQgaW5jcmVhc2VkIGNvZGUgY29tcGxleGl0eTsgYm90aCBDQk9SIGFuZCBERVIgZW5jb2Rp bmcgLyBkZWNvZGluZyBuZWVkZWQNCi0gQ2FuIHRyYW5zZm9ybSB0by9mcm9tIFguNTA5IG1lY2hh bmljYWxseSB3aXRob3V0IHRoZSBwcml2YXRlIGtleQ0KDQoxKSBDT1NFICsgTWlycm9yaW5nIHdp dGggQ0JPUiBTZXF1ZW5jZSBmcm9tIFJhemEgZHJhZnQNCi0gVXNlcyB0aGUgQ0JPUiBzZXF1ZW5j ZSB0aGF0IGV4YWN0bHkgbWlycm9ycyBYLjUwOQ0KLSBSZWR1Y2VzIHNpemUgb2YgY2VydCBhbmQg bG93ZXJzIGNvZGUgY29tcGxleGl0eTsgbm8gREVSIGVuY29kaW5nIC8gZGVjb2RpbmcNCi0gTXVz dCBoYXZlIHByaXZhdGUga2V5IHRvIGdlbmVyYXRlOyBtdXN0IGJlIGdlbmVyYXRlZCBieSB0aGUg Q0ENCg0KMikgQ09TRSArIE1pcnJvcmluZyB3aXRoIENXVCBDbGFpbXMNCi0gQSBzZXQgb2YgQ1dU IGNsYWltcyBhcmUgZGVmaW5lZCB0aGF0IGV4YWN0bHkgbWlycm9yIFguNTA5IGZpZWxkcw0KLSBS ZWR1Y2VzIHNpemUgb2YgY2VydCBhbmQgbG93ZXJzIGNvZGUgY29tcGxleGl0eTsgbm8gREVSIGVu Y29kaW5nIC8gZGVjb2Rpbmc7IGNhbiByZSB1c2Ugc29tZSBDV1QgY29kZQ0KLSBNdXN0IGhhdmUg cHJpdmF0ZSBrZXkgdG8gZ2VuZXJhdGU7IG11c3QgYmUgZ2VuZXJhdGVkIGJ5IHRoZSBDQQ0KDQoz KSBDT1NFICsgSW1wcm92ZWQgQ1dUIENsYWltcw0KLSBBIHNldCBvZiBDV1QgY2xhaW1zIHRoYXQg ZG9u4oCZdCBuZWNlc3NhcmlseSBtaXJyb3IgWC41MDkgZXhhY3RseSwgYnV0IGdpdmUgc2ltaWxh ciBzZW1hbnRpY3MNCi0gUmVkdWNlcyBzaXplIG9mIGNlcnQgYW5kIGxvd2VycyBjb2RlIGNvbXBs ZXhpdHk7IG5vIERFUiBlbmNvZGluZyAvIGRlY29kaW5nOyBjYW4gcmUgdXNlIHNvbWUgQ1dUIGNv ZGUNCi0gTXVzdCBoYXZlIHByaXZhdGUga2V5IHRvIGdlbmVyYXRlOyBtdXN0IGJlIGdlbmVyYXRl ZCBieSB0aGUgQ0ENCg0KSSB3YXMgZGVmaW5pdGVseSB0YWxraW5nIGFib3V0IDMpIGluIG15IGxh c3QgZW1haWwuIEl0IGlzIGNsZWFybHkgbm90IGluIHRoZSBjaGFydGVyLg0KDQpTbyBtYXliZSB0 aGUgZGViYXRlIGlzIGJldHdlZW4gMSkgYW5kIDIpLiBCb3RoIGFyZSBpbiB0aGUgY2hhcnRlci4g U29tZSBhZHZhbnRhZ2VzIG9mIDIpIGFyZToNCi0gQ2FuIHJlIHVzZSBzb21lIG9mIHRoZSBDV1Qg Y29kZQ0KLSBDYW4gbW92ZSB0byAzKSBpbmNyZW1lbnRhbGx5IHdoZW4gdGhlIHRpbWUgY29tZXMN Ci0gQ2FuIGRyb3AgZmllbGRzIHRoYXQgYXJlIG5vdCB1c2VkIHBvc3NpYmx5IGdpdmluZyB0aGUg c21hbGxlc3QgY2VydCBzaXplIG9uIHRoZSB3aXJlIG9mIGFueSBvZiB0aGUgb3B0aW9ucw0KDQpM TA0KDQoNCg0KDQpPbiBBcHIgMjgsIDIwMjAsIGF0IDM6MjMgQU0sIEfDtnJhbiBTZWxhbmRlciA8 Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tPG1haWx0bzpnb3Jhbi5zZWxhbmRlckBlcmljc3Nv bi5jb20+PiB3cm90ZToNCg0KSGkgTGF1cmVuY2UsDQoNClRoYW5rcyBmb3Igc2hhcmluZyB5b3Vy IHRob3VnaHRzLiBJdCBzZWVtcyB3ZSBhcmUgd29ya2luZyBvbiBzbGlnaHRseSBkaWZmZXJlbnQg cGF0aHMuDQoNClRoZSBwYXJ0IHlvdSBjYWxsZWQg4oCcQ29tcHJlc3NlZCBDZXJ0c+KAnSBpcyBh bHJlYWR5IGluIHRoZSBkcmFmdCBDT1NFIGNoYXJ0ZXIgd2hlcmUgaXQgaXMgcmVmZXJyZWQgdG8g YXMg4oCcQSBDQk9SIGVuY29kaW5nIG9mIHRoZSBjb21wcmVzc2VkIGNlcnRpZmljYXRlIHByb2Zp bGUgZGVmaW5lZCBpbiBSRkMgNzkyNeKAnSBzbyB3ZSBjYW4gbGVhdmUgdGhhdCBvdXQgZm9yIG5v dy4NCg0KTXkgY29tbWVudCB3YXMgYWJvdXQgdGhlIG90aGVyIHBhcnQsIHdoYXQgd2UgYm90aCBj YWxsIOKAnG5hdGl2ZSBDQk9SIGNlcnRpZmljYXRlc+KAnSBidXQgbWVhbiBkaWZmZXJlbnQgdGhp bmdzLiBXaGF0IGlzIGNhbGxlZCBuYXRpdmUgaW4NCmRyYWZ0LXJhemEtYWNlLWNib3ItY2VydGlm aWNhdGVzIGlzIG5vdCBpbnRlbmRlZCBhcyBhIGNlcnRpZmljYXRlIGZvcm1hdCBicmVha2luZyB3 aXRoIFguNTA5LiBXaGlsZSB0aGVyZSBhcmUgbWFueSBwb3RlbnRpYWwgaW1wcm92ZW1lbnRzIHRv IG1ha2Ugb24gWC41MDksIHRoZXJlIGlzIGEgcmVzaXN0YW5jZSBhZ2FpbnN0IG5ldyBjZXJ0aWZp Y2F0ZSBhcmNoaXRlY3R1cmVzIGFzIHdhcyBjbGVhciB3aGVuIHRoaXMgd2FzIGJyb3VnaHQgdXAg aW4gU2VjZGlzcGF0Y2ggYXQgSUVURiAxMDQgYSB5ZWFyIGFnby4gQXMgbWVudGlvbmVkIHByZXZp b3VzbHksIHdoYXQgd2UgbWVhbiBieSDigJxuYXRpdmUgQ0JPUuKAnSBpcyB0aGUgbG9zc2xlc3Mg Y29tcHJlc3Npb24gb2YgdGhlIGNlcnRpZmljYXRlIHByb2ZpbGUgb2YgWC41MDkgaW50byBhIENC T1IgZW5jb2RlZCBmb3JtYXQsIGJ1dCBzaWduaW5nIG92ZXIgdGhlIENCT1IgaW5zdGVhZCBvZiBv biB0aGUgdW5jb21wcmVzc2VkIGRhdGEuIEluIHRoaXMgd2F5IGl0IGlzIHBvc3NpYmxlIHRvIGRl ZmluZSBhIGJpamVjdGlvbiBiZXR3ZWVuIG5hdGl2ZSBDQk9SIGNlcnRpZmljYXRlcyBhbmQgcHJv ZmlsZWQgWC41MDkgY2VydGlmaWNhdGVzIOKAkyB0aGUgcGF5bG9hZCBvZiB0aGUgY29tcHJlc3Nl ZCB2ZXJzaW9uIG9mIHRoZSBsYXR0ZXIgd291bGQgYmUgaWRlbnRpY2FsIHRvIHRoZSBmb3JtZXIu IFNvIHRoZSBuYXRpdmUgQ0JPUiBjZXJ0aWZpY2F0ZXMgYXJlIGEgZmFpdGhmdWwgcmVwcmVzZW50 YXRpb24gb2YgdGhlc2UgcHJvZmlsZWQgWC41MDkgY2VydGlmaWNhdGVzLCB1c2luZyB0aGUgc2Ft ZSBwYXlsb2FkIGFzIGluIHRoZSBDQk9SIGNvbXByZXNzaW9uIHNjaGVtZS4NCg0KSW4gY29udHJh c3QgdG8gdGhlIGNvbXByZXNzaW9uIHNjaGVtZSwgYSBjb252ZXJzaW9uIGJldHdlZW4gbmF0aXZl IENCT1IgYW5kIFguNTA5IHJlcHJlc2VudGF0aW9ucyByZXF1aXJlcyBhY2Nlc3MgdG8gdGhlIHBy aXZhdGUgc2lnbmF0dXJlIGtleS4NClRoZXJlZm9yZSBhIG1peCBvZiBYLjUwOSBhbmQgbmF0aXZl IENCT1Igd291bGQgcmVxdWlyZSBtdWx0aXBsZSBoYW5kbGVycyBhdCB0aGUgYmFja2VuZCAocGFy c2luZyB0aGUgcGF5bG9hZCB3b3VsZCBiZSB0aGUgc2FtZSkuIERlZGljYXRlZCBkZXBsb3ltZW50 cyBjb3VsZCBvZiBjb3Vyc2UgdXNlIG5hdGl2ZSBDQk9SIGNlcnRpZmljYXRlcyBleGNsdXNpdmVs eS4NCg0KSW4gdGhlIHNhbWUgd2F5IGl0IHdvdWxkIGJlIHBvc3NpYmxlIHRvIGluc3RlYWQgZGVm aW5lIGEgQ09TRV9TaWduMSBhbmQvb3IgYSBDV1QgcmVwcmVzZW50aW5nIHRoZXNlIHByb2ZpbGVk IFguNTA5IGNlcnRpZmljYXRlcywgdGhpcyBpcyB3aGF0IEkgdGhvdWdodCB5b3Ugd2VyZSBhc2tp bmcgYWJvdXQgYnV0IGFwcGFyZW50bHkgbm90LiBUaGF0IHdvdWxkIGJlIGFuIGFsdGVybmF0aXZl IGFzIGxvbmcgYXMgd2UgY2FuIGRlY2lkZSBvbiBleGFjdGx5IG9uZSBvZiB0aGVzZSByZXByZXNl bnRhdGlvbnMuDQoNClRoZXJlIGFyZSBhIGxvdCBvZiBmdW4gdGhpbmdzIHRvIGRvIGluIHRoaXMg c3BhY2UsIG15IGNvbmNlcm4gaXMgaG93IHRvIGdldCBvdXQgYSBzdGFuZGFyZC4gVHJ5aW5nIHRv IHJlcGxhY2UgWC41MDkgZG9lc27igJl0IHNlZW0gbGlrZSBhIHByb21pc2luZyB3YXkgZm9yd2Fy ZCBJ4oCZbSBhZnJhaWQgLiAuIC4NCg0KR8O2cmFuDQoNCg0KRnJvbTogQWNlIDxhY2UtYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86YWNlLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgTGF1 cmVuY2UgTHVuZGJsYWRlIDxsZ2xAaXNsYW5kLXJlc29ydC5jb208bWFpbHRvOmxnbEBpc2xhbmQt cmVzb3J0LmNvbT4+DQpEYXRlOiBNb25kYXksIDI3IEFwcmlsIDIwMjAgYXQgMjA6MTMNClRvOiBH w7ZyYW4gU2VsYW5kZXIgPGdvcmFuLnNlbGFuZGVyPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYu b3JnPG1haWx0bzpnb3Jhbi5zZWxhbmRlcj00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz4+ DQpDYzogSm9lbCBIw7ZnbHVuZCA8am9lbC5ob2dsdW5kQGdtYWlsLmNvbTxtYWlsdG86am9lbC5o b2dsdW5kQGdtYWlsLmNvbT4+LCAiY29zZUBpZXRmLm9yZzxtYWlsdG86Y29zZUBpZXRmLm9yZz4i IDxjb3NlQGlldGYub3JnPG1haWx0bzpjb3NlQGlldGYub3JnPj4sICJhY2VAaWV0Zi5vcmc8bWFp bHRvOmFjZUBpZXRmLm9yZz4iIDxhY2VAaWV0Zi5vcmc8bWFpbHRvOmFjZUBpZXRmLm9yZz4+DQpT dWJqZWN0OiBSZTogW0FjZV0gW0NPU0VdIGRyYWZ0LXJhemEtYWNlLWNib3ItY2VydGlmaWNhdGVz LTA0LnR4dA0KDQoNCk9uIEFwciAyNywgMjAyMCwgYXQgNTowMCBBTSwgR8O2cmFuIFNlbGFuZGVy IDxnb3Jhbi5zZWxhbmRlcj00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86Z29y YW4uc2VsYW5kZXI9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCg0KW0dT XSBUaGUgcmF0aW9uYWxlIGZvciBuYXRpdmUgQ0JPUiBjZXJ0aWZpY2F0ZXMgaXMgdG8gcmV1c2Ug dGhlIHNhbWUgZW5jb2RpbmcgYXMgaW4gdGhlIGNvbXByZXNzaW9uIHNjaGVtZSBkZWZpbmVkIGZv ciBSRkMgNzkyNSwgYnV0IHNpZ25pbmcgdGhlIENCT1IgaW5zdGVhZCBvZiBzaWduaW5nIHRoZSB1 bmNvbXByZXNzZWQgZGF0YS4gVGhpcyBwcm92aWRlcyBhIHJvYWRtYXAgd2l0aCBtaW5pbWFsIGNo YW5nZXMgd2hlbiBtb3ZpbmcgZnJvbSBjb21wcmVzc2VkIHRvIG5hdGl2ZSBDQk9SIGNlcnRpZmlj YXRlcy4NCg0KSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IHRoZSBvdmVyaGVhZCBvZiBDT1NFX1NpZ24x IG9yIENXVCBpcyBub3QgbWFqb3IgYW5kIHRoZXNlIHBvaW50cyBhcmUgb3BlbiBmb3IgZGlzY3Vz c2lvbi4gVGhlIG1vcmUgaW1wb3J0YW50IHF1ZXN0aW9uIGlzIHdoZXJlIHRoaXMgc2hvdWxkIGJl IHN0YW5kYXJkaXplZC4gVGhlIGNvbXByZXNzaW9uIHNjaGVtZSBpcyBub3cgaW5jbHVkZWQgaW4g dGhlIG5ldyBkcmFmdCBjaGFydGVyIGZvciBDT1NFOg0KaHR0cHM6Ly9naXRodWIuY29tL2Nvc2Ut d2cvQ2hhcnRlci9ibG9iL21hc3Rlci9DaGFydGVyLm1kPGh0dHBzOi8vcHJvdGVjdDIuZmlyZWV5 ZS5jb20vdjEvdXJsP2s9ZGQxMjc3MDktODE5YmQ4YzAtZGQxMjM3OTItMGNjNDdhZDkzZTFjLTVi NmJhZTg0YWJjNWM0YTAmcT0xJmU9NWJiNDEyZmEtZWMxZC00NGEwLThkYmEtYzY2ODQ0ZDFiNzk3 JnU9aHR0cHMlM0ElMkYlMkZnaXRodWIuY29tJTJGY29zZS13ZyUyRkNoYXJ0ZXIlMkZibG9iJTJG bWFzdGVyJTJGQ2hhcnRlci5tZD4NClRoZSBjaGFydGVyIGlzIGN1cnJlbnRseSBub3QgZXhwbGlj aXRseSBzdXBwb3J0aW5nIG5hdGl2ZSBDQk9SIGNlcnRpZmljYXRlcy4gSWYgeW91IHRoaW5rIGl0 IHNob3VsZCwgaW4gc29tZSB2YXJpYW50LCB0aGVuIHRoaXMgaXMgYSBnb29kIHRpbWUgdG8gcmFp c2UgeW91ciB2b2ljZS4NCg0KVG8gZ28gc3RyYWlnaHQgdG8gdGhlIGlzc3VlLCBJIHRoaW5rIGEg ZGVzaWduaW5nIGEgbmF0aXZlIENCT1IgY2VydCBzaG91bGQgYmUgYXBwcm9hY2hlZCBkaWZmZXJl bnRseSB0aGFuIGNvbXByZXNzaW5nIC8gcmUtZW5jb2RpbmcgYW4gWC41MDkgY2VydDoNCg0KUmUt ZW5jb2RpbmcNCi0gU2l6ZSBpcyBpbXBvcnRhbnQNCi0gRXhhY3QgY29tcGF0aWJpbGl0eSBpcyBy ZXF1aXJlZA0KLSBOZWFyIHplcm8gY2hhbmdlIHRvIGZpZWxkcyBhbmQgc2VtYW50aWNzDQoNCk5h dGl2ZSBDQk9SIENlcnQNCi0gQ2xlYW4gdXAgc29tZSBvZiB0aGUgbWVzcyBpbiBYLjUwOTsgaXQg aXMgYW4gb2xkIHN0YW5kYXJkIHdpdGggYSBsb3Qgb2YgY3J1ZnQgYW5kIGJhZ2dhZ2UNCi0gUmUg ZGVzaWduIGV4dGVuc2lvbnMgc28gdGhleSBhcmUgaW4gQ0JPUiBmb3JtYXQNCi0gTWFrZSBtYW55 IG9mIHRoZSBmaWVsZHMgb3B0aW9uYWwsIGZvciBleGFtcGxlIG5vdCBiZWZvcmUgY2FuIG9mdGVu IGJlIGxlZnQgb2ZmLCBtYXliZSBldmVuIHNlcmlhbCBudW1iZXINCi0gQXZvaWQgRE4gc3RydWN0 dXJlIGZvciBpc3N1ZXIgYW5kIHN1YmplY3QgZm9yIG1vc3QgdXNlIGNhc2VzDQotIFVzZSBtb2Rl cm4gZm9ybWF0cyBsaWtlIENPU0UgYW5kIENXVCBhbmQgQ09TRV9LZXkNCi0gU2l6ZSBpcyBpbXBv cnRhbnQsIGJ1dCBmYXIgZnJvbSB0aGUgb25seSBnb2FsIChzb21lIHNpemUgcmVkdWN0aW9ucywg bGlrZSBvcHRpb25hbCBmaWVsZHMgd2lsbCBiZSBwb3NzaWJsZSBoZXJlIHRoYXQgYXJlIG5vdCBw b3NzaWJsZSB3aXRoIHJlLWVuY29kaW5nKQ0KLSBDb21wYXRpYmlsaXR5IG1hdHRlcnMsIGJ1dCBu b3QgaW4gdGhlIHNhbWUgd2F5DQoNClNlZW1zIGxpa2UgdGhlIHJpZ2h0IHRoaW5nIHRvIGRvIGhl cmUgaXMgdG8gcmVtb3ZlIG5hdGl2ZSBDQk9SIGNlcnRzIGZyb20gdGhpcyBkb2N1bWVudCBhbmQg anVzdCBmb2N1cyBvbiBjb21wcmVzc2lvbiBhbmQgcmUtZW5jb2RpbmcuIE1heWJlIGV2ZW4gY2Fs bCB0aGVtIOKAnENvbXByZXNzZWQgQ2VydHPigJ0gcmF0aGVyIHRoYW4g4oCcQ0JPUiBDZXJ0c+KA nS4uIFdoZXJlIHRoYXQgd29yayBzaG91bGQgZ28gaXMgYWJvdmUgbXkgcGF5IGdyYWRlLg0KDQoN CkJVVCwgbXkgbWFpbiBpbnRlcmVzdCBoZXJlIHJlbGF0ZXMgdG8gQ1dUIGFuZCBFQVQuIENXVCBz ZWVtcyBsaWtlIGEgcmVhbGx5IGdvb2QgY2hvaWNlIG9uIHdoaWNoIHRvIGJhc2UgYSBuYXRpdmUg Q0JPUiBjZXJ0LiBTb21lIG9mIHRoZSBmaWVsZHMgZm9yIGFuIFguNTA5IGNlcnQgYXJlIGFscmVh ZHkgZGVmaW5lZCBpbiBDV1QgKHN1YmplY3QsIGlzc3VlciwgZXhwaXJhdGlvbiwgbm90LWJlZm9y ZSkuIEl0IGhhcyBhbiBleHRlbnNpb24gbWVjaGFuaXNtIGJ1aWx0IGluIGFscmVhZHkgaW4gdGhl IENXVCBJQU5BIHJlZ2lzdHJ5LiBUaGUgY3J5cHRvIGFuZCBzaWduaW5nIGFyZSB3ZWxsLWhhbmRs ZWQgYnkgQ1dU4oCZcyB1c2Ugb2YgQ09TRS4NCg0KSW4gd29yayB0byBmaXQgRUFUPGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJhdHMtZWF0LTAzPiBpbiBhcyBhIENXVCwg YSBmZXcgaXNzdWVzIGhhdmUgY29tZSB1cCDigJQgaG93IGZpZWxkcyAvIGNsYWltcyBhcmUgbWFu YWdlZCBhbmQgcmVnaXN0ZXJlZCB3aXRoIElBTkEsIGxhYmVsIHNwYWNlcyBhbmQgb3RoZXIuICBB bGwgdGhlc2UgaXNzdWVzIHdvdWxkIGFwcGx5IHRvIENXVC9DT1NFL0NCT1ItYmFzZWQgY2VydGlm aWNhdGUgYXMgd2VsbC4NCg0KVG8gbmFtZSBqdXN0IG9uZSBpc3N1ZSwgaW4gQ1dUIHRoZSBleHBp cmF0aW9uIGRhdGUvdGltZSBjYW4gYmUgYSBmbG9hdGluZy1wb2ludCBudW1iZXIsIHdoaWNoIGlz IGJ1cmRlbnNvbWUsIG5vdCB1c2VmdWwuIFNob3VsZCB3ZSBjaGFuZ2UgQ1dUIHRvIGRpc2FsbG93 IG9yIHNob3VsZCBpdCBqdXN0IGJlIGRpc2FsbG93ZWQgd2hlbiBhIENXVCBpcyB1c2VkIGFzIGFu IEVBVCBhbmQgd2hlbiBpdCBpcyB1c2VkIGFzIGEgQ2VydD8NCg0KSeKAmW0gYWxzbyBleGNpdGVk IGF0IHRoZSBpZGVhIG9mIHJlIHVzaW5nIENXVCBpbiBhIHNpbXBsZSBmb3JtIHNvIHRoZXJlIGlz IHJlIHVzZSBvZiBjb2RlIGJldHdlZW4gQ1dULCBFQVQgYW5kIG5hdGl2ZSBDQk9SIGNlcnRzLiBJ 4oCZdmUgc3RhcnRlZCBwbGF5aW5nIHdpdGggYW4gaW1wbGVtZW50YXRpb24gbGlrZSB0aGlzLg0K DQpMTA0KDQoNCg== --_000_CE4654CA93F046F79768C3F67166A3FFericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0 ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93 dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9ImVuLVNFIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBMYXVyZW5jZSwgYW5kIGFsbCw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJTViIgc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFua3MgZm9yIHByb3ZpZGluZyBhIHRheG9ub215LiBB cyBtZW50aW9uZWQsIHR5cGUgMCBpcyBjbGVhcmx5IGluIHRoZSBjdXJyZW50IGRyYWZ0IENPU0Ug Y2hhcnRlciwgYW5kIHdlIHNlZSBhbHNvIHRoZSBuZWVkIGZvciBhIHJlcHJlc2VudGF0aW9uIG9m IHRoZSBYLjUwOSBwcm9maWxlIGluIFJGQyA3OTI1IHdoaWNoDQogcmVsaWV2ZXMgY29uc3RyYWlu ZWQgZGV2aWNlcyBmcm9tIGltcGxlbWVudGluZyBERVIvQVNOLjEgZW5jb2RpbmcgYXMgd2VsbCBh cyByZS1lbmNvZGluZy9kZWNvbXByZXNzaW5nIGluIG9yZGVyIHRvIHZlcmlmeS4gV2hldGhlciB0 aGlzIGlzIHR5cGUgMSBhcyBwcm9wb3NlZCBpbiB0aGUgZHJhZnQsIG9yIHR5cGUgMiBhcyB5b3Ug cHJvcG9zZSwgaXMgb3BlbiBmb3IgZGlzY3Vzc2lvbi4gSSBiZWxpZXZlIEkgc3BlYWsgb24gYmVo YWxmIG9mIHRoZQ0KIGF1dGhvcnMgPC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIj5oZXJlLiA8L3NwYW4+DQo8L3NwYW4+PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNw YW4gbGFuZz0iRU4tVVMiPkEgcXVlc3Rpb24gZm9yIHRoZSBjaGFpcnMgYW5kIEFEOiBJcyBpdC9j YW4gaXQgYmUgaW4gdGhlIHNjb3BlIG9mIENPU0Ugb3IgQUNFIHRvIGRlZmluZSB0eXBlIDEvMj8g T3IgZG8geW91IG5lZWQgbW9yZSBzaG93IG9mIGludGVyZXN0IGZyb20gdGhlIGNvbW11bml0eSB0 byBzZWUgaWYgdGhpcyBpcyB3b3J0aCBwdXJzdWluZw0KIGF0IGFsbD88bzpwPjwvbzpwPjwvc3Bh bj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1VUyI+R8O2cmFuPG86cD48L286cD48L3NwYW4+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5MYXVyZW5jZSBMdW5kYmxh ZGUgJmx0O2xnbEBpc2xhbmQtcmVzb3J0LmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VGh1cnNk YXksIDMwIEFwcmlsIDIwMjAgYXQgMTk6Mzg8YnI+DQo8Yj5UbzogPC9iPkfDtnJhbiBTZWxhbmRl ciAmbHQ7Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+R8O2 cmFuIFNlbGFuZGVyICZsdDtnb3Jhbi5zZWxhbmRlcj00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRm Lm9yZyZndDssIEpvZWwgSMO2Z2x1bmQgJmx0O2pvZWwuaG9nbHVuZEBnbWFpbC5jb20mZ3Q7LCAm cXVvdDtjb3NlQGlldGYub3JnJnF1b3Q7ICZsdDtjb3NlQGlldGYub3JnJmd0OywgJnF1b3Q7YWNl QGlldGYub3JnJnF1b3Q7ICZsdDthY2VAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9i PlJlOiBbQWNlXSBbQ09TRV0gZHJhZnQtcmF6YS1hY2UtY2Jvci1jZXJ0aWZpY2F0ZXMtMDQudHh0 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij5IaSZuYnNwO0fDtnJhbiw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+SSB1bmRlcnN0YW5kIHlvdXIgdHdvIHR5cGVzIG9mIG5hdGl2ZSBDQk9SIGNl cnRzLCBhbmQgcmFpc2UgeW91IGJ5IG9uZS4gSeKAmXZlIGFzc3VtZWQgQ09TRSBiZWNhdXNlIGl0 IHNlZW1zIGEgY2xlYXIgY2hvaWNlIHRvIG1lIChubyBzaXplIGlzc3VlLCBjb2RlIHJlIHVzZSku PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi1sZWZ0OjMwLjBwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48dT4w KSBDb21wcmVzc2VkL3JlLWVuY29kZWQ8L3U+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4tIFVzZXMg Q0JPUiBTZXF1ZW5jZSB0aGF0IGV4YWN0bHkgbWlycm9ycyBYLjUwOSBmcm9tIFJhemEgZHJhZnQ8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPi0gUmVkdWNlcyBzaXplIG9mIGNlcnQsIGJ1dCBpbmNyZWFz ZWQgY29kZSBjb21wbGV4aXR5OyBib3RoIENCT1IgYW5kIERFUiBlbmNvZGluZyAvIGRlY29kaW5n IG5lZWRlZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+LSBDYW4gdHJhbnNmb3JtIHRvL2Zyb20gWC41 MDkgbWVjaGFuaWNhbGx5IHdpdGhvdXQgdGhlIHByaXZhdGUga2V5PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjx1PjEpIENPU0UgJiM0MzsgTWlycm9y aW5nIHdpdGggQ0JPUiBTZXF1ZW5jZSBmcm9tIFJhemEmbmJzcDtkcmFmdDwvdT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPi0gVXNlcyB0aGUgQ0JPUiBzZXF1ZW5jZSB0aGF0IGV4YWN0bHkgbWlycm9y cyBYLjUwOTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+LSBSZWR1Y2VzIHNpemUgb2YgY2VydCBhbmQg bG93ZXJzIGNvZGUgY29tcGxleGl0eTsgbm8gREVSIGVuY29kaW5nIC8gZGVjb2Rpbmc8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPi0gTXVzdCBoYXZlIHByaXZhdGUga2V5IHRvIGdlbmVyYXRlOyBtdXN0 IGJlIGdlbmVyYXRlZCBieSB0aGUgQ0E8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+PHU+MikgQ09TRSAmIzQzOyBNaXJyb3Jpbmcgd2l0aCBDV1QgQ2xh aW1zPC91PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+LSBBIHNldCBvZiBDV1QgY2xhaW1zIGFyZSBk ZWZpbmVkIHRoYXQgZXhhY3RseSBtaXJyb3IgWC41MDkgZmllbGRzPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+LSBSZWR1Y2VzIHNpemUgb2YgY2VydCBhbmQgbG93ZXJzIGNvZGUgY29tcGxl eGl0eTsgbm8gREVSIGVuY29kaW5nIC8gZGVjb2Rpbmc7IGNhbiByZSB1c2Ugc29tZSBDV1QgY29k ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+LSBNdXN0IGhhdmUgcHJpdmF0 ZSBrZXkgdG8gZ2VuZXJhdGU7IG11c3QgYmUgZ2VuZXJhdGVkIGJ5IHRoZSBDQTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 dT4zKSBDT1NFICYjNDM7IEltcHJvdmVkIENXVCBDbGFpbXM8L3U+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij4tIEEgc2V0IG9mIENXVCBjbGFpbXMgdGhhdCBkb27igJl0IG5l Y2Vzc2FyaWx5IG1pcnJvciBYLjUwOSBleGFjdGx5LCBidXQgZ2l2ZSBzaW1pbGFyIHNlbWFudGlj czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPi0gUmVkdWNlcyBz aXplIG9mIGNlcnQgYW5kIGxvd2VycyBjb2RlIGNvbXBsZXhpdHk7IG5vIERFUiBlbmNvZGluZyAv IGRlY29kaW5nOyBjYW4gcmUgdXNlIHNvbWUgQ1dUIGNvZGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+LSBNdXN0IGhhdmUgcHJpdmF0ZSBrZXkgdG8gZ2VuZXJh dGU7IG11c3QgYmUgZ2VuZXJhdGVkIGJ5IHRoZSBDQTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkkgd2FzIGRlZmluaXRlbHkgdGFsa2lu ZyBhYm91dCAzKSBpbiBteSBsYXN0IGVtYWlsLiBJdCBpcyBjbGVhcmx5IG5vdCBpbiB0aGUgY2hh cnRlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ U28gbWF5YmUgdGhlIGRlYmF0ZSBpcyBiZXR3ZWVuIDEpIGFuZCAyKS4gQm90aCBhcmUgaW4gdGhl IGNoYXJ0ZXIuIFNvbWUgYWR2YW50YWdlcyBvZiAyKSBhcmU6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij4tIENhbiByZSB1c2Ugc29tZSBvZiB0aGUgQ1dUIGNvZGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi Pi0gQ2FuIG1vdmUgdG8gMykgaW5jcmVtZW50YWxseSB3aGVuIHRoZSB0aW1lIGNvbWVzPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij4tIENhbiBkcm9wIGZpZWxkcyB0aGF0IGFyZSBub3QgdXNlZCBwb3Nz aWJseSBnaXZpbmcgdGhlIHNtYWxsZXN0IGNlcnQgc2l6ZSBvbiB0aGUgd2lyZSBvZiBhbnkgb2Yg dGhlIG9wdGlvbnM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+TEw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPk9uIEFwciAyOCwgMjAyMCwgYXQgMzoyMyBBTSwgR8O2cmFuIFNlbGFuZGVyICZsdDs8YSBo cmVmPSJtYWlsdG86Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tIj5nb3Jhbi5zZWxhbmRlckBl cmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBMYXVyZW5jZSw8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rcyBmb3Igc2hhcmluZyB5b3Vy IHRob3VnaHRzLiBJdCBzZWVtcyB3ZSBhcmUgd29ya2luZyBvbiBzbGlnaHRseSBkaWZmZXJlbnQg cGF0aHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUg cGFydCB5b3UgY2FsbGVkIOKAnENvbXByZXNzZWQgQ2VydHPigJ0gaXMgYWxyZWFkeSBpbiB0aGUg ZHJhZnQgQ09TRSBjaGFydGVyIHdoZXJlIGl0IGlzIHJlZmVycmVkIHRvIGFzIOKAnDwvc3Bhbj5B IENCT1IgZW5jb2Rpbmcgb2YgdGhlIGNvbXByZXNzZWQgY2VydGlmaWNhdGUgcHJvZmlsZSBkZWZp bmVkIGluIFJGQyA3OTI1PHNwYW4gbGFuZz0iRU4tVVMiPuKAnQ0KIHNvIHdlIGNhbiBsZWF2ZSB0 aGF0IG91dCBmb3Igbm93Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+TXkgY29tbWVudCB3YXMgYWJvdXQgdGhlIG90aGVyIHBhcnQsIHdoYXQgd2UgYm90aCBj YWxsIOKAnG5hdGl2ZSBDQk9SIGNlcnRpZmljYXRlc+KAnSBidXQgbWVhbiBkaWZmZXJlbnQgdGhp bmdzLiBXaGF0IGlzIGNhbGxlZCBuYXRpdmUgaW48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij5kcmFmdC1yYXphLWFjZS1jYm9yLWNlcnRpZmljYXRlczxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+aXMgbm90IGludGVu ZGVkIGFzIGEgY2VydGlmaWNhdGUgZm9ybWF0IGJyZWFraW5nIHdpdGggWC41MDkuIFdoaWxlIHRo ZXJlIGFyZSBtYW55IHBvdGVudGlhbCBpbXByb3ZlbWVudHMgdG8gbWFrZSBvbg0KIFguNTA5LCB0 aGVyZSBpcyBhIHJlc2lzdGFuY2UgYWdhaW5zdCBuZXcgY2VydGlmaWNhdGUgYXJjaGl0ZWN0dXJl cyBhcyB3YXMgY2xlYXIgd2hlbiB0aGlzIHdhcyBicm91Z2h0IHVwIGluIFNlY2Rpc3BhdGNoIGF0 IElFVEYgMTA0IGEgeWVhciBhZ28uIEFzIG1lbnRpb25lZCBwcmV2aW91c2x5LCB3aGF0IHdlIG1l YW4gYnkg4oCcbmF0aXZlIENCT1LigJ0gaXMgdGhlIGxvc3NsZXNzIGNvbXByZXNzaW9uIG9mIHRo ZSBjZXJ0aWZpY2F0ZSBwcm9maWxlIG9mDQogWC41MDkgaW50byBhIENCT1IgZW5jb2RlZCBmb3Jt YXQsIGJ1dCBzaWduaW5nIG92ZXIgdGhlIENCT1IgaW5zdGVhZCBvZiBvbiB0aGUgdW5jb21wcmVz c2VkIGRhdGEuIEluIHRoaXMgd2F5IGl0IGlzIHBvc3NpYmxlIHRvIGRlZmluZSBhIGJpamVjdGlv biBiZXR3ZWVuIG5hdGl2ZSBDQk9SIGNlcnRpZmljYXRlcyBhbmQgcHJvZmlsZWQgWC41MDkgY2Vy dGlmaWNhdGVzIOKAkyB0aGUgcGF5bG9hZCBvZiB0aGUgY29tcHJlc3NlZCB2ZXJzaW9uIG9mIHRo ZQ0KIGxhdHRlciB3b3VsZCBiZSBpZGVudGljYWwgdG8gdGhlIGZvcm1lci4gU28gdGhlIG5hdGl2 ZSBDQk9SIGNlcnRpZmljYXRlcyBhcmUgYSBmYWl0aGZ1bCByZXByZXNlbnRhdGlvbiBvZiB0aGVz ZSBwcm9maWxlZCBYLjUwOSBjZXJ0aWZpY2F0ZXMsIHVzaW5nIHRoZSBzYW1lIHBheWxvYWQgYXMg aW4gdGhlIENCT1IgY29tcHJlc3Npb24gc2NoZW1lLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+SW4gY29udHJhc3QgdG8gdGhlIGNvbXByZXNzaW9uIHNjaGVt ZSwgYSBjb252ZXJzaW9uIGJldHdlZW4gbmF0aXZlIENCT1IgYW5kIFguNTA5IHJlcHJlc2VudGF0 aW9ucyByZXF1aXJlcyBhY2Nlc3MgdG8gdGhlIHByaXZhdGUgc2lnbmF0dXJlIGtleS48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+VGhlcmVmb3JlIGEgbWl4 IG9mIFguNTA5IGFuZCBuYXRpdmUgQ0JPUiB3b3VsZCByZXF1aXJlIG11bHRpcGxlIGhhbmRsZXJz IGF0IHRoZSBiYWNrZW5kIChwYXJzaW5nIHRoZSBwYXlsb2FkIHdvdWxkIGJlIHRoZSBzYW1lKS4g RGVkaWNhdGVkIGRlcGxveW1lbnRzIGNvdWxkIG9mIGNvdXJzZSB1c2UgbmF0aXZlIENCT1IgY2Vy dGlmaWNhdGVzDQogZXhjbHVzaXZlbHkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFu IGxhbmc9IkVOLVVTIj5JbiB0aGUgc2FtZSB3YXkgaXQgd291bGQgYmUgcG9zc2libGUgdG8gaW5z dGVhZCBkZWZpbmUgYSBDT1NFX1NpZ24xIGFuZC9vciBhIENXVCByZXByZXNlbnRpbmcgdGhlc2Ug cHJvZmlsZWQgWC41MDkgY2VydGlmaWNhdGVzLCB0aGlzIGlzIHdoYXQgSSB0aG91Z2h0IHlvdSB3 ZXJlIGFza2luZyBhYm91dCBidXQgYXBwYXJlbnRseSBub3QuDQogVGhhdCB3b3VsZCBiZSBhbiBh bHRlcm5hdGl2ZSBhcyBsb25nIGFzIHdlIGNhbiBkZWNpZGUgb24gZXhhY3RseSBvbmUgb2YgdGhl c2UgcmVwcmVzZW50YXRpb25zLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5n PSJFTi1VUyI+VGhlcmUgYXJlIGEgbG90IG9mIGZ1biB0aGluZ3MgdG8gZG8gaW4gdGhpcyBzcGFj ZSwgbXkgY29uY2VybiBpcyBob3cgdG8gZ2V0IG91dCBhIHN0YW5kYXJkLiBUcnlpbmcgdG8gcmVw bGFjZSBYLjUwOSBkb2VzbuKAmXQgc2VlbSBsaWtlIGEgcHJvbWlzaW5nIHdheSBmb3J3YXJkIEni gJltIGFmcmFpZCAuIC4gLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+R8O2cmFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8ZGl2IHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkZyb206PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFjZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFjZS1ib3Vu Y2VzQGlldGYub3JnIj5hY2UtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBM YXVyZW5jZQ0KIEx1bmRibGFkZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxnbEBpc2xhbmQtcmVzb3J0 LmNvbSI+bGdsQGlzbGFuZC1yZXNvcnQuY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+TW9uZGF5LCAyNyBB cHJpbCAyMDIwIGF0IDIwOjEzPGJyPg0KPGI+VG86PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5Hw7ZyYW4gU2VsYW5kZXIgJmx0OzxhIGhyZWY9Im1h aWx0bzpnb3Jhbi5zZWxhbmRlcj00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZyI+Z29yYW4u c2VsYW5kZXI9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkNj OjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+Sm9l bCBIw7ZnbHVuZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpvZWwuaG9nbHVuZEBnbWFpbC5jb20iPmpv ZWwuaG9nbHVuZEBnbWFpbC5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmNvc2VA aWV0Zi5vcmciPmNvc2VAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Y29z ZUBpZXRmLm9yZyI+Y29zZUBpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86 YWNlQGlldGYub3JnIj5hY2VAaWV0Zi5vcmc8L2E+JnF1b3Q7DQogJmx0OzxhIGhyZWY9Im1haWx0 bzphY2VAaWV0Zi5vcmciPmFjZUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPlJlOiBbQWNl XSBbQ09TRV0gZHJhZnQtcmF6YS1hY2UtY2Jvci1jZXJ0aWZpY2F0ZXMtMDQudHh0PC9zcGFuPjxi cj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gQXByIDI3LCAyMDIwLCBhdCA1OjAw IEFNLCBHw7ZyYW4gU2VsYW5kZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpnb3Jhbi5zZWxhbmRlcj00 MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZyI+Z29yYW4uc2VsYW5kZXI9NDBlcmljc3Nvbi5j b21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj5bR1NdIFRoZSByYXRpb25hbGUgZm9yIG5hdGl2ZSBDQk9SIGNlcnRpZmljYXRlcyBp cyB0byByZXVzZSB0aGUgc2FtZSBlbmNvZGluZyBhcyBpbiB0aGUgY29tcHJlc3Npb24gc2NoZW1l IGRlZmluZWQgZm9yIFJGQyA3OTI1LCBidXQgc2lnbmluZyB0aGUgQ0JPUiBpbnN0ZWFkIG9mIHNp Z25pbmcgdGhlIHVuY29tcHJlc3NlZCBkYXRhLg0KIFRoaXMgcHJvdmlkZXMgYSByb2FkbWFwIHdp dGggbWluaW1hbCBjaGFuZ2VzIHdoZW4gbW92aW5nIGZyb20gY29tcHJlc3NlZCB0byBuYXRpdmUg Q0JPUiBjZXJ0aWZpY2F0ZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGFncmVlIHdpdGggeW91IHRoYXQg dGhlIG92ZXJoZWFkIG9mIENPU0VfU2lnbjEgb3IgQ1dUIGlzIG5vdCBtYWpvciBhbmQgdGhlc2Ug cG9pbnRzIGFyZSBvcGVuIGZvciBkaXNjdXNzaW9uLiBUaGUgbW9yZSBpbXBvcnRhbnQgcXVlc3Rp b24gaXMgd2hlcmUgdGhpcyBzaG91bGQgYmUgc3RhbmRhcmRpemVkLiBUaGUgY29tcHJlc3Npb24N CiBzY2hlbWUgaXMgbm93IGluY2x1ZGVkIGluIHRoZSBuZXcgZHJhZnQgY2hhcnRlciBmb3IgQ09T RTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48YSBocmVmPSJodHRwczovL3Byb3RlY3QyLmZpcmVleWUuY29tL3Yx L3VybD9rPWRkMTI3NzA5LTgxOWJkOGMwLWRkMTIzNzkyLTBjYzQ3YWQ5M2UxYy01YjZiYWU4NGFi YzVjNGEwJmFtcDtxPTEmYW1wO2U9NWJiNDEyZmEtZWMxZC00NGEwLThkYmEtYzY2ODQ0ZDFiNzk3 JmFtcDt1PWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRmNvc2Utd2clMkZDaGFydGVyJTJGYmxv YiUyRm1hc3RlciUyRkNoYXJ0ZXIubWQiPmh0dHBzOi8vZ2l0aHViLmNvbS9jb3NlLXdnL0NoYXJ0 ZXIvYmxvYi9tYXN0ZXIvQ2hhcnRlci5tZDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5U aGUgY2hhcnRlciBpcyBjdXJyZW50bHkgbm90IGV4cGxpY2l0bHkgc3VwcG9ydGluZyBuYXRpdmUg Q0JPUiBjZXJ0aWZpY2F0ZXMuIElmIHlvdSB0aGluayBpdCBzaG91bGQsIGluIHNvbWUgdmFyaWFu dCwgdGhlbiB0aGlzIGlzIGEgZ29vZCB0aW1lIHRvIHJhaXNlIHlvdXIgdm9pY2UuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VG8gZ28gc3RyYWlnaHQgdG8gdGhl IGlzc3VlLCBJIHRoaW5rIGEgZGVzaWduaW5nIGEgbmF0aXZlIENCT1IgY2VydCBzaG91bGQgYmUg YXBwcm9hY2hlZCBkaWZmZXJlbnRseSB0aGFuIGNvbXByZXNzaW5nIC8gcmUtZW5jb2RpbmcgYW4g WC41MDkgY2VydDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHU+UmUtZW5jb2Rpbmc8L3U+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij4tIFNpemUgaXMgaW1wb3J0YW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4tIEV4YWN0IGNvbXBhdGliaWxpdHkgaXMgcmVx dWlyZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPi0gTmVhciB6ZXJvIGNoYW5nZSB0byBmaWVsZHMgYW5kIHNlbWFudGljczxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48dT5OYXRpdmUgQ0JPUiBDZXJ0PC91PjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+LSBDbGVh biB1cCBzb21lIG9mIHRoZSBtZXNzIGluIFguNTA5OyBpdCBpcyBhbiBvbGQgc3RhbmRhcmQgd2l0 aCBhIGxvdCBvZiBjcnVmdCBhbmQgYmFnZ2FnZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+LSBSZSBkZXNpZ24gZXh0ZW5zaW9u cyBzbyB0aGV5IGFyZSBpbiBDQk9SIGZvcm1hdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+LSBNYWtlIG1hbnkgb2YgdGhlIGZp ZWxkcyBvcHRpb25hbCwgZm9yIGV4YW1wbGUgbm90IGJlZm9yZSBjYW4gb2Z0ZW4gYmUgbGVmdCBv ZmYsIG1heWJlIGV2ZW4gc2VyaWFsIG51bWJlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+LSBBdm9pZCBETiBzdHJ1Y3R1cmUg Zm9yIGlzc3VlciBhbmQgc3ViamVjdCBmb3IgbW9zdCB1c2UgY2FzZXM8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPi0gVXNlIG1v ZGVybiBmb3JtYXRzIGxpa2UgQ09TRSBhbmQgQ1dUIGFuZCBDT1NFX0tleTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+LSBTaXpl IGlzIGltcG9ydGFudCwgYnV0IGZhciBmcm9tIHRoZSBvbmx5IGdvYWwgKHNvbWUgc2l6ZSByZWR1 Y3Rpb25zLCBsaWtlIG9wdGlvbmFsIGZpZWxkcyB3aWxsIGJlIHBvc3NpYmxlIGhlcmUgdGhhdCBh cmUgbm90IHBvc3NpYmxlIHdpdGggcmUtZW5jb2RpbmcpPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4tIENvbXBhdGliaWxpdHkg bWF0dGVycywgYnV0IG5vdCBpbiB0aGUgc2FtZSB3YXk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+U2Vl bXMgbGlrZSB0aGUgcmlnaHQgdGhpbmcgdG8gZG8gaGVyZSBpcyB0byByZW1vdmUgbmF0aXZlIENC T1IgY2VydHMgZnJvbSB0aGlzIGRvY3VtZW50IGFuZCBqdXN0IGZvY3VzIG9uIGNvbXByZXNzaW9u IGFuZCByZS1lbmNvZGluZy4gTWF5YmUgZXZlbiBjYWxsIHRoZW0g4oCcQ29tcHJlc3NlZCBDZXJ0 c+KAnSByYXRoZXIgdGhhbiDigJxDQk9SIENlcnRz4oCdLi4gV2hlcmUgdGhhdA0KIHdvcmsgc2hv dWxkIGdvIGlzIGFib3ZlIG15IHBheSBncmFkZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5CVVQsIG15IG1haW4gaW50ZXJl c3QgaGVyZSByZWxhdGVzIHRvIENXVCBhbmQgRUFULiBDV1Qgc2VlbXMgbGlrZSBhIHJlYWxseSBn b29kIGNob2ljZSBvbiB3aGljaCB0byBiYXNlIGEgbmF0aXZlIENCT1IgY2VydC4gU29tZSBvZiB0 aGUgZmllbGRzIGZvciBhbiBYLjUwOSBjZXJ0IGFyZSBhbHJlYWR5IGRlZmluZWQgaW4gQ1dUIChz dWJqZWN0LCBpc3N1ZXIsIGV4cGlyYXRpb24sDQogbm90LWJlZm9yZSkuIEl0IGhhcyBhbiBleHRl bnNpb24gbWVjaGFuaXNtIGJ1aWx0IGluIGFscmVhZHkgaW4gdGhlIENXVCBJQU5BIHJlZ2lzdHJ5 LiBUaGUgY3J5cHRvIGFuZCBzaWduaW5nIGFyZSB3ZWxsLWhhbmRsZWQgYnkgQ1dU4oCZcyB1c2Ug b2YgQ09TRS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SW4gd29yayB0byBmaXQmbmJzcDs8YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1yYXRzLWVhdC0wMyI+RUFU PC9hPiZuYnNwO2luIGFzIGEgQ1dULCBhIGZldyBpc3N1ZXMgaGF2ZSBjb21lIHVwIOKAlCBob3cg ZmllbGRzIC8gY2xhaW1zIGFyZSBtYW5hZ2VkIGFuZCByZWdpc3RlcmVkIHdpdGggSUFOQSwgbGFi ZWwgc3BhY2VzIGFuZCBvdGhlci4gJm5ic3A7QWxsDQogdGhlc2UgaXNzdWVzIHdvdWxkIGFwcGx5 IHRvIENXVC9DT1NFL0NCT1ItYmFzZWQgY2VydGlmaWNhdGUgYXMgd2VsbC4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+VG8gbmFtZSBqdXN0IG9uZSBpc3N1ZSwgaW4gQ1dUIHRoZSBleHBpcmF0 aW9uIGRhdGUvdGltZSBjYW4gYmUgYSBmbG9hdGluZy1wb2ludCBudW1iZXIsIHdoaWNoIGlzIGJ1 cmRlbnNvbWUsIG5vdCB1c2VmdWwuIFNob3VsZCB3ZSBjaGFuZ2UgQ1dUIHRvIGRpc2FsbG93IG9y IHNob3VsZCBpdCBqdXN0IGJlIGRpc2FsbG93ZWQgd2hlbiBhIENXVCBpcyB1c2VkIGFzIGFuDQog RUFUIGFuZCB3aGVuIGl0IGlzIHVzZWQgYXMgYSBDZXJ0PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5J 4oCZbSBhbHNvIGV4Y2l0ZWQgYXQgdGhlIGlkZWEgb2YgcmUgdXNpbmcgQ1dUIGluIGEgc2ltcGxl IGZvcm0gc28gdGhlcmUgaXMgcmUgdXNlIG9mIGNvZGUgYmV0d2VlbiBDV1QsIEVBVCBhbmQgbmF0 aXZlIENCT1IgY2VydHMuIEnigJl2ZSBzdGFydGVkIHBsYXlpbmcgd2l0aCBhbiBpbXBsZW1lbnRh dGlvbiBsaWtlIHRoaXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkxMPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CE4654CA93F046F79768C3F67166A3FFericssoncom_-- From nobody Mon May 4 04:18:57 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD82D3A07BA; Mon, 4 May 2020 04:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06FbIrAz-JmZ; Mon, 4 May 2020 04:18:50 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40050.outbound.protection.outlook.com [40.107.4.50]) (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 0A2273A07B9; Mon, 4 May 2020 04:18:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=g4uFPGHQHRx7qd/rYjRnkcHDAFAEs3iZ+ARnZ68sfB/0GVwrgNcMTrv7sscFphl7qu5Op4upf89mY/LGOXbEUcwak/BpSYo+nkbvetHs26xjzEtv/ybzVekhU8wacQ54ppltxgNVC12/oytg4DhEYpOlz0m4sz4JiAzPyi8xVk9P0Wc9U5mKs9OR61ehDowT4LJFxJeyA/ub6sJIFSkVzIUqqiO4dpMEYbJVZwp99uphAOz4UvKdKkGQyZHdKxX6t3VhdmKIH+j8WAX31zYTDzlQIMKbrg9RMc5iIRgFxOrYgwbkga0SoCTdSpZhJ2Q+3/R1caRiU/HSdWZiMW04XA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=W0W8OQ5oZbDGu4g/k2z1M3dJ9cjH1Z0bgIk9FPhLyRY=; b=dy4qiqoNj1PwA+YG/93TVKxkEqIinKu77cn5MyqWLOAlDClUc621o002xrRj9YnIaFSjDPVGBzqAZuYlQqFpxREiI1KHgE9cZRPa+1RUA//1o0yjlGVyAfoCJSqoyOh67hSl7QkOX/nQj2zancwAvEOZUJfwG3n26eC435v7UBfZluXLRH1/K7KZhZeBv1Yh40Y0i3+TfAKyvBSJGAgllMYjUjlfB2Kxan9OBlaCJ6Opw8gmV26jnaa8lZlws8oyjc5KCvZQ57LtmZce1obIqr3+g6+mjpsgTPzh5llcL2GspcT1aspXJFcsnEH1g19orKpeuGFKNqeZifvCOJ+XnA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=W0W8OQ5oZbDGu4g/k2z1M3dJ9cjH1Z0bgIk9FPhLyRY=; b=rlbMP7fIOndXqzejp355F7zqhBRjVWsKiwpBmn5vpeI7T9ZfdCZus46ToX2TuTRblSlz5OK/S205n9GfkTduIaHRta7sGoxkSBp3cd92yY6YhimlXt9fbf2mvY+KaF4FcIKsCdoLZcfSlh1vvW21UWvlfcaXlH/hcQ2dW4ayVJg= Received: from AM7PR07MB6945.eurprd07.prod.outlook.com (2603:10a6:20b:1bf::11) by AM7PR07MB6293.eurprd07.prod.outlook.com (2603:10a6:20b:133::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.24; Mon, 4 May 2020 11:18:47 +0000 Received: from AM7PR07MB6945.eurprd07.prod.outlook.com ([fe80::55ba:3006:67fc:f931]) by AM7PR07MB6945.eurprd07.prod.outlook.com ([fe80::55ba:3006:67fc:f931%7]) with mapi id 15.20.2979.024; Mon, 4 May 2020 11:18:47 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "core@ietf.org" , "ace@ietf.org" Thread-Topic: Multicast notifications for distributing public keys to other group members Thread-Index: AQHWIgXHzV9mp3zMoEOsNx4hgbX4VQ== Date: Mon, 4 May 2020 11:18:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.85] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f70fc3b8-1b52-4f5e-3cd5-08d7f01cea65 x-ms-traffictypediagnostic: AM7PR07MB6293: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03932714EB x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: HNpGAPv8gknM+3eltCia/nUUre5/vdfRezKYdxXvwdCWdThQ1JXstViHzaaDCRkR0/V7W78Gp5zRmuMuH91+CzvJAZhOQkKtOA9clYeDUJJ0xnTA27yy0+Mbl4HWt/eAunJtIrzmayd6dYWfiXxWQGkLohkrH2SUOd897EH4to276cacyULdkMwF8QnJtmzR9co5fwNUyrcy3JZ0hWDf9uflbkdEpL0Y3p2Iy+GRRVZv1Xd8Ydvhb4ufAePb7FvLQ+xEUfcUqF0B4fBWSvW/933o6Bb0Z8I1yM5ncHqosiWZ17rEGsQ1o0ffO+wFdn5H52rCskeGMuK+p8wRw6ngt/9WcPkmYlsmZ8s25KX/7ccTOg6uDaSe23Qfk6/c/kwlMrJbhVk8FoVUn0nGDJoZ3+xp/09RmXxsoSI8FGRKOs59E7ImXJUhDQXo5L7Px5C64RiTkqsunF9N05U8TSg6u/y3TQNOAhVjYJ6YwcKTnflGxsRqTxBj2XbTneverVY1SS7gtmcOW5T84ro0ZLy/DQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB6945.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(136003)(346002)(396003)(39860400002)(376002)(86362001)(15650500001)(76116006)(83080400001)(66446008)(66476007)(478600001)(6506007)(66556008)(450100002)(64756008)(26005)(186003)(66946007)(85182001)(2616005)(966005)(2906002)(85202003)(6512007)(5660300002)(71200400001)(36756003)(316002)(110136005)(66574012)(8676002)(8936002)(33656002)(6486002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: L2/BKP3SC/E/uNHDbcgYy7HIDXRgEGkt3mku7RP6exNa7o0B+XYjVKwe6uvuG07gOq9s4et+XyhUWhTlymlQ5HrXLX1WEmDrcatdvEAOyALj9zxmvME3fW/s1kFHtNtCA6BWOCNqslFRMHn3vFtpP3UnbarZiIOiVdZRs4EfTbEy8LpbMzXkW3I3oaZst1mpk/43pbaXLEUK91mnU5QGQFGUEYS1k9VbNG5klOfA95w1Gt0A7W5LnWkW7AXR+N1t9KhxIm0MMlogFDAQhwX+6LiTRbVUGLTZff+U2NKdNQjU22lJNaZsOfZpsnMaG+SiYqsk/NESXNh6Q4BLP/it4DlBjYJAWkjqAg1P+XgD4hJsST63jGJbCnE2i8WqZ9wcDWZ/kolCLJVfd0g9r/w8x9pMJFImUd5Jqm1WPd5whWRtFRuZjA1XH2aEaHvryqhU8R5h4AdFwTQIwca7mkKNX4wqZIUI2nRinUxWjePRf6vKYVVDrgDDTzciIh4PnfdxQvxAua481mjqZ32/KNMg0LauBOU3TGYGIcYSxU6xQ1y3GarqUayoFgq6mwSzrIHIzV0Rmk+hkdOg3RCQP/pYWw467aW/o+/2Lp2N7lAvkD/xU33MkJ8KeoScpirib9IrfI48/6LMLAgQaOIzC9i2iwFq5sPH1yWS6spcoEwL3dXsdaVI/jntXX18VXCQXOG/Axt9owBJO3EJV8kX75sx0h9zdWntS73tziVT2T7wBe6E/+pjY3fM9CYn1VNmWkIExIltFizFNwgnwICmKlP59IQkMEmPpWKLBPLRMhXnv7g= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <3E46990F4CE77A448017D45AF59815A5@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: f70fc3b8-1b52-4f5e-3cd5-08d7f01cea65 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2020 11:18:47.7741 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4qENbUXI0z6xBo5B9nlOUTj6DcfyiJwBjy1SHaVxj308RBOS5Pm9pTTw4D17MoWIwv5L7TWOAawNh/OnAxeRHiP0hnh7IT8+NFjEKWCITp4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6293 Archived-At: Subject: [Ace] Multicast notifications for distributing public keys to other group members X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 04 May 2020 11:18:52 -0000 DQpEZWFyIENvUkUgYW5kIEFDRSwNCg0KQXBvbG9naWVzIGZvciBjcm9zcy1wb3N0aW5nLCB0aGlz IGNvbmNlcm5zIHRoZSBzZWN1cml0eSBmb3IgQ29BUCBncm91cCBjb21tdW5pY2F0aW9ucyAod2hp Y2ggaXMgYSBDb1JFIGRyYWZ0KSBhbmQgdGhlIGN1cnJlbnQgc3BlY2lmaWVkIG1ldGhvZCB0byBy ZXRyaWV2ZSBwdWJsaWMga2V5cyBmb3IgZ3JvdXAgY29tbXVuaWNhdGlvbiAod2hpY2ggaXMgYW4g QUNFIGRyYWZ0KS4NCg0KV2hlbiBhIG5vZGUgam9pbnMgYSBncm91cCBbMF0gdGhlcmUgaXMgYSBu ZWVkIGZvciBncm91cCBtZW1iZXJzIHRvIGdldCBpdHMgcHVibGljIGtleS4gU2VjdGlvbiA0LjUg b2YgdGhlIGN1cnJlbnQgR2l0aHViIHZlcnNpb24gb2YgZHJhZnQtaWV0Zi1hY2Uta2V5LWdyb3Vw Y29tbSAiS2V5IFByb3Zpc2lvbmluZyBmb3IgR3JvdXAgQ29tbXVuaWNhdGlvbiB1c2luZyBBQ0Ui IFsxXSBkZXNjcmliZXMgcHJvY2VkdXJlcyBmb3IgcmV0cmlldmluZyB0aGUgcHVibGljIGtleXMs IGJ5IGFjY2Vzc2luZyB0aGUgcmVzb3VyY2UgImFjZS1ncm91cC9HUk9VUE5BTUUvcHViLWtleSIg aW4gdGhlIEtEQy4gU2VjdGlvbiA0LjMgaW4gdGhlIHNhbWUgZG9jdW1lbnQgZGVzY3JpYmVzIHRo ZSBwcm9jZWR1cmUgdG8gIm1ha2UgdGhlIC4uLiByZXNvdXJjZSBPYnNlcnZhYmxlLCBhbmQgc2Vu ZCBub3RpZmljYXRpb25zIHRvIENsaWVudHMgd2hlbiB0aGUga2V5aW5nIG1hdGVyaWFsIGlzIHVw ZGF0ZWQiLg0KDQoxLiBUaGUgdXNlIG9mIG5vdGlmaWNhdGlvbnMgaXMgZ29vZCB0byBhdm9pZCBz aW1pbGFyIHJlcXVlc3RzIGZyb20gc2V2ZXJhbCBub2RlcyBpbiB0aGVzZSBjYXNlcy4gQnV0IHRo ZSBwcm9jZWR1cmUgaXMgb25seSBtZW50aW9uZWQgYnJpZWZseSBhcyBxdW90ZWQgYWJvdmUuIFdv dWxkIGl0IGJlIHBvc3NpYmxlIHRvIGV4cGFuZCBvbiB0aGlzIGFuZCBtYWtlIGl0IGEgcmVjb21t ZW5kZWQgbWVjaGFuaXNtIGluIHRoaXMgZHJhZnQsIG9yIGFsdGVybmF0aXZlbHksIGEgc2VwYXJh dGUgZHJhZnQ/DQoNCjIuIElmIHRoZSBudW1iZXIgb2YgbWVtYmVycyBpbiB0aGUgZ3JvdXAgaXMg bGFyZ2UsIGl0IHdvdWxkIGJlIGV2ZW4gYmV0dGVyIHRvIHNlbmQganVzdCBvbmUgbXVsdGljYXN0 IG5vdGlmaWNhdGlvbiBbMl0gaW5zdGVhZCBvZiBtYW55IG5vdGlmaWNhdGlvbnMgd2l0aCB0aGUg c2FtZSBjb250ZW50LCBidXQgdGhpcyByZXF1aXJlcyB0aGUgc2VuZGluZyBub2RlIHRvIGJlIG1l bWJlciBvZiB0aGUgZ3JvdXAuIFRoZSBHcm91cCBNYW5hZ2VyIGlzIHRoZSBhdXRob3JpemVkIHBh cnR5IGRpc3RyaWJ1dGluZyBwdWJsaWMga2V5cyB0byBub2RlcyBvZiB0aGUgZ3JvdXAsIGJ1dCB3 ZSBkb24ndCB0aGluayBvZiBpdCBhcyBtZW1iZXIgb2YgdGhhdCBncm91cC4gSXMgaXQgd29ydGgg dG8gbWFrZSB0aGUgR00gYSBncm91cCBtZW1iZXIgYnkgZGVmYXVsdCB0byBlbmFibGUgdGhlIHVz ZSBvZiBbMl0gZm9yIGRpc3RyaWJ1dGlvbiBvZiB0aGUgcHVibGljIGtleSBvZiBhIChyZS0pam9p bmluZyBub2RlPyAgDQoNCkfDtnJhbg0KDQpbMF0gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtY29yZS1ncm91cGNvbW0tYmlzDQpbMV0gaHR0cHM6Ly9hY2Utd2cuZ2l0aHVi LmlvL2FjZS1rZXktZ3JvdXBjb21tL2RyYWZ0LWlldGYtYWNlLWtleS1ncm91cGNvbW0uaHRtbCNu YW1lLXJldHJpZXZhbC1vZi1wdWJsaWMta2V5cy1hbg0KWzJdIGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC10aWxvY2EtY29yZS1vYnNlcnZlLW11bHRpY2FzdC1ub3RpZmljYXRpb25z DQoNCg0K From nobody Mon May 4 11:16:00 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 286F83A11B1; Mon, 4 May 2020 11:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDAiQwZeVya3; Mon, 4 May 2020 11:15:51 -0700 (PDT) Received: from mail-vk1-xa30.google.com (mail-vk1-xa30.google.com [IPv6:2607:f8b0:4864:20::a30]) (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 C229B3A1187; Mon, 4 May 2020 11:15:50 -0700 (PDT) Received: by mail-vk1-xa30.google.com with SMTP id j1so30823vkc.2; Mon, 04 May 2020 11:15:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=rq1XqkyOde4cWcpzMBHpbZmHLhdTcE9aQAoLHtlp7es=; b=Q4g8CAB3NviCsJ2g4lBrJhvJdtOcXpsRFLES3KNm94d6fB/KixkHtEfRQT7B6DSTsy i5SxQzeH3OvFlpwyWGC3mhZJl2c1fG4jDn8h3lIHHWHRHjnP5i8k61OxDazF5yCIxl9i GzmuDImZBX8UY22UHGJU0cOXWe6GZhBKwF3TkONyDOyQql8wImKzEJsCCDdwA9BWHPJb diu3i+ecI1hqfw7JRzqUtiHoM3uzSWX4MKSA9DXkZWfxtmwDjSV7uqnzqZJUH8EpNNUx cjHRhIrNbUxPzp1yy2/Ep0H2s9RopFCqDyHFnOXvzv4vO3TkL1yXWFlJQl3lfUAHkNJU QvXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=rq1XqkyOde4cWcpzMBHpbZmHLhdTcE9aQAoLHtlp7es=; b=Pxj0UslkSxYm3A81wfPlb42bcdzh7W8Em034FmlhkPpoERsTUgMhoAMHa/29jUM2Pk plG4Zo336CjbNfv0O/XY+ypyDvPXq2eDRfX457DWel+34lNBXYEyPwFWXhKNdzpFPBsE pMEkT5fzLVRskRxx4gvwM7GwpHaN85Ys5C6lKNtG+4kHNi82ZIPky8nTa87K4dMbNZBW sSA5HtoMHCEOvUD1wUxdBrZj6utH23WWpxEolChhNN/dB3EQvx4rlUr/LLKw2IqKQRcW zgJ/QY5VFcXwnWsgjfjTZTD+zWg7BGtg0tvYAZ0H5/oBSKNZwwxYkgUCjQBSWJRJU9ev qrUA== X-Gm-Message-State: AGi0PuZgVWe3XWJBcbUrdUnHEGD6WyAV4BB+YuFqw+zEnkFJI//Lv2zB UKENwPF5Sb3zKBh/B9wxW0QL+jGWUGphUKN76pi+XBVG X-Google-Smtp-Source: APiQypJR6p0dTWUbWhBusbj4IiWxpe7h029zOZlFdmzO9idkaoSA23mbBMWSxcaDFCarXVYeX0Fiuq/ps0VTtTodX0Q= X-Received: by 2002:a1f:938f:: with SMTP id v137mr515513vkd.55.1588616149431; Mon, 04 May 2020 11:15:49 -0700 (PDT) MIME-Version: 1.0 References: <158857581528.28405.17372040856513106617@ietfa.amsl.com> In-Reply-To: <158857581528.28405.17372040856513106617@ietfa.amsl.com> From: Daniel Migault Date: Mon, 4 May 2020 14:15:38 -0400 Message-ID: To: curdle , tm-rid@ietf.org, IETF-Calsify , Ace Wg , tzdist-bis@ietf.org Content-Type: multipart/alternative; boundary="0000000000004578dd05a4d6850b" Archived-At: Subject: [Ace] Fwd: Reminder: Survey on planning for possible online IETF meetings X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 04 May 2020 18:15:55 -0000 --0000000000004578dd05a4d6850b Content-Type: text/plain; charset="UTF-8" Hi, The IETF Executive Director and leadership need community input on how to handle virtual meetings. Please feel free to complete the survey. Thanks, Daniel ---------- Forwarded message --------- From: IETF Executive Director Date: Mon, May 4, 2020 at 3:04 AM Subject: Reminder: Survey on planning for possible online IETF meetings To: IETF Announcement List This is a reminder that we need the IETF community to help us plan for the possibility that one or more upcoming IETF meetings in 2020 and possibly 2021 may not be able to go ahead in person. You can help us with this by filling out the following survey: https://www.surveymonkey.com/r/5328FFJ So far we have 114 responses and we would ideally like 500 or more. The survey contains the following pages and will take 15-20 minutes to complete: 1. Welcome 2. Online IETF 107 and the subsequent virtual interims 3. Replacing a cancelled in-person meeting 4. Online meeting format and timezone 5. Replicating humming 6. Replicating the hallway environment 7. Fees 8. Thanks and anything else We run the survey in anonymous mode which means that we only see data that you explicitly provide. Thank you in advance for your help. -- Alissa Cooper, IETF Chair Jay Daley, IETF Executive Director Colin Perkins, IRTF Chair _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce -- Daniel Migault Ericsson --0000000000004578dd05a4d6850b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

The IETF Executive Direc= tor and leadership need community input on how to handle virtual meetings. = Please feel free to complete the=C2=A0 survey.

Thanks,
Daniel

---------- Forwarded message ---------<= br>From: IETF Executive Dir= ector <exec-director@ietf.org>
Date: Mon, May 4, 2020 at 3:0= 4 AM
Subject: Reminder: Survey on planning for possible online IETF meet= ings
To: IETF Announcement List <ietf-announce@ietf.org>


This is a reminder th= at we need the IETF community to help us plan for the possibility that one = or more upcoming IETF meetings in 2020 and possibly 2021 may not be able to= go ahead in person.=C2=A0 You can help us with this by filling out the fol= lowing survey:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.surveymonkey.com/r/532= 8FFJ

So far we have 114 responses and we would ideally like 500 or more.

The survey contains the following pages and will take 15-20 minutes to comp= lete:

1. Welcome
2. Online IETF 107 and the subsequent virtual interims
3. Replacing a cancelled in-person meeting
4. Online meeting format and timezone
5. Replicating humming
6. Replicating the hallway environment
7. Fees
8. Thanks and anything else

We run the survey in anonymous mode which means that we only see data that = you explicitly provide.

Thank you in advance for your help.

--
Alissa Cooper, IETF Chair
Jay Daley, IETF Executive Director
Colin Perkins, IRTF Chair

_______________________________________________
IETF-Announce mailing list
IETF-Announce@i= etf.org
https://www.ietf.org/mailman/listinfo/ietf-announ= ce


--
Dani= el Migault
Ericsson
--0000000000004578dd05a4d6850b-- From nobody Mon May 4 21:09:43 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F41E3A0BA3 for ; Mon, 4 May 2020 21:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 Cnxl0aGhu_zc for ; Mon, 4 May 2020 21:09:40 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 A400B3A13B4 for ; Mon, 4 May 2020 21:09:32 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 04549H1W031797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 5 May 2020 00:09:20 -0400 Date: Mon, 4 May 2020 21:09:17 -0700 From: Benjamin Kaduk To: Olaf Bergmann Cc: Peter van der Stok , Jim Schaad , consultancy@vanderstok.org, "'Ace'" Message-ID: <20200505040917.GM27494@kduck.mit.edu> References: <56d31e581571721e176b59db20e08c23@bbhmail.nl> <00f101d61f03$a26bb920$e7432b60$@augustcellars.com> <0873a3115cab89036002cf42b1c97608@bbhmail.nl> <87mu6o6u8t.fsf@wangari> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87mu6o6u8t.fsf@wangari> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Ace] draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 05 May 2020 04:09:42 -0000 On Mon, May 04, 2020 at 09:21:06AM +0200, Olaf Bergmann wrote: > Hi Peter, > > Peter van der Stok writes: > > > When I want to access an OCF device I can find its IP address through > > service discovery (rfc7252 section 7) using an rt-value registered at > > the IANA core parameters registry. For example, when I want to > > initialize the AS I have to type in the IP address of the AS. From > > that moment on keys and certificates can be compared to continue > > initialization. > > > > Using service discovery can automate that process. > > > > My request is that authz draft registers an rt-value in core > > parameters registry for service discovery of the AS, unless a > > different process has already been established for AS initialization. > > That is exaclty what originally has been done in section 9 of > draft-gerdes-ace-dcaf-authorize [1]. Somehow, this got lost in the > process. I think I'm still a little confused as to what good being able to "discover" that the network says something is an AS is, without some prior trust and/or key material for that AS. How would the necessary trust be established as part of such a discovery scheme? Thanks, Ben From nobody Mon May 4 21:55:12 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E243A13D3 for ; Mon, 4 May 2020 21:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 IeUOLpQiEXYa for ; Mon, 4 May 2020 21:55:08 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 345A03A13B9 for ; Mon, 4 May 2020 21:55:07 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 4 May 2020 21:55:02 -0700 From: Jim Schaad To: 'Benjamin Kaduk' , 'Olaf Bergmann' CC: 'Peter van der Stok' , , 'Ace' References: <56d31e581571721e176b59db20e08c23@bbhmail.nl> <00f101d61f03$a26bb920$e7432b60$@augustcellars.com> <0873a3115cab89036002cf42b1c97608@bbhmail.nl> <87mu6o6u8t.fsf@wangari> <20200505040917.GM27494@kduck.mit.edu> In-Reply-To: <20200505040917.GM27494@kduck.mit.edu> Date: Mon, 4 May 2020 21:54:59 -0700 Message-ID: <02f001d62299$56718830$03549890$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJvvEQrX2wOjMB2/s9A8vau6YKJYgFtua5lAwDjVtQCw58eHwIqARfCpxrXnpA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 05 May 2020 04:55:11 -0000 I have much the same problem. While a client could find an AS which would authenticate the client, I don't know how the client would establish any degree of trust in the AS which is going to give it tokens. If you have already put a local public key for the AS into the client, then you might as well put in a name for the AS as well. I suppose you could get by with a shared secret but that does not seem to be a good way to build up the system. Jim -----Original Message----- From: Benjamin Kaduk Sent: Monday, May 4, 2020 9:09 PM To: Olaf Bergmann Cc: Peter van der Stok ; Jim Schaad ; consultancy@vanderstok.org; 'Ace' Subject: Re: [Ace] draft-ietf-ace-oauth-authz On Mon, May 04, 2020 at 09:21:06AM +0200, Olaf Bergmann wrote: > Hi Peter, > > Peter van der Stok writes: > > > When I want to access an OCF device I can find its IP address > > through service discovery (rfc7252 section 7) using an rt-value > > registered at the IANA core parameters registry. For example, when > > I want to initialize the AS I have to type in the IP address of the > > AS. From that moment on keys and certificates can be compared to > > continue initialization. > > > > Using service discovery can automate that process. > > > > My request is that authz draft registers an rt-value in core > > parameters registry for service discovery of the AS, unless a > > different process has already been established for AS initialization. > > That is exaclty what originally has been done in section 9 of > draft-gerdes-ace-dcaf-authorize [1]. Somehow, this got lost in the > process. I think I'm still a little confused as to what good being able to "discover" that the network says something is an AS is, without some prior trust and/or key material for that AS. How would the necessary trust be established as part of such a discovery scheme? Thanks, Ben From nobody Mon May 4 22:38:27 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBD23A1402 for ; Mon, 4 May 2020 22:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 tWpq1wYsmgll for ; Mon, 4 May 2020 22:38:24 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BA1F3A0C14 for ; Mon, 4 May 2020 22:38:24 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49GT655W0Rzyfp; Tue, 5 May 2020 07:38:21 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <02f001d62299$56718830$03549890$@augustcellars.com> Date: Tue, 5 May 2020 07:38:20 +0200 Cc: Benjamin Kaduk , Olaf Bergmann , Peter van der Stok , peter van der Stok , Ace X-Mao-Original-Outgoing-Id: 610349900.590312-983d5c287a0a506e7cef1bf7eac81eb8 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56d31e581571721e176b59db20e08c23@bbhmail.nl> <00f101d61f03$a26bb920$e7432b60$@augustcellars.com> <0873a3115cab89036002cf42b1c97608@bbhmail.nl> <87mu6o6u8t.fsf@wangari> <20200505040917.GM27494@kduck.mit.edu> <02f001d62299$56718830$03549890$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Ace] draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 05 May 2020 05:38:27 -0000 On 2020-05-05, at 06:54, Jim Schaad wrote: >=20 > I have much the same problem. While a client could find an AS which = would > authenticate the client, I don't know how the client would establish = any > degree of trust in the AS which is going to give it tokens. =20 Hence the four-corner model [1]. Gr=C3=BC=C3=9Fe, Carsten [1]: https://tools.ietf.org/html/draft-ietf-ace-actors From nobody Tue May 5 00:26:11 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238343A15BB for ; Tue, 5 May 2020 00:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bbhmail.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XI5LtH6BnHxO for ; Tue, 5 May 2020 00:26:08 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0049.hostedemail.com [216.40.44.49]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFEA73A15B7 for ; Tue, 5 May 2020 00:26:00 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay04.hostedemail.com (Postfix) with ESMTP id 672DD180A734E; Tue, 5 May 2020 07:25:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h= mime-version:content-type:date:from:to:cc:subject:reply-to :in-reply-to:references:message-id; s=key; bh=sKmU2xSqAKM+RQ+0sN CgFzxMvD+ljg2XNhCO5sMCNOU=; b=p+LMol+juS/oGDwG1cumFu5ZI0oXvZEuBy 6EfozReg75cP8JHvZVVVGLUz6fIq6FfVrIUeM8vE8YxHeyGCPR1nncbcySdv+bG6 e0H7Vqgf8ogpMALKpmPx29OSgygiuWIsKP+yQW/UVmV0QxKLNp/JVX/TXA7Jc+QB PaIFAPzys= X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, , RULES_HIT:41:72:152:355:379:582:599:800:960:962:967:973:983:988:989:1152:1189:1208:1221:1260:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1535:1543:1575:1588:1589:1592:1594:1711:1730:1776:1792:2198:2199:2553:2559:2562:2693:2892:2898:2900:2901:3138:3139:3140:3141:3142:3354:3622:3865:3866:3867:3868:3870:3871:3872:3874:4118:4250:4321:4362:5007:6248:6261:6298:6657:6659:6678:7903:8603:9177:10004:10400:11232:11658:11914:12043:12109:12114:12663:12740:12895:13071:13139:13160:13161:13229:13618:13972:14093:14180:14181:14721:21060:21063:21080:21324:21433:21451:21625:21740:21809:21939:21990:30003:30054:30070:30075:30090:30091, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:0, DNSBL:none, Custom_rules:0:0:0, LFtime:1, LUA_SUMMARY:none X-HE-Tag: door31_515a778447c48 X-Filterd-Recvd-Size: 7159 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf13.hostedemail.com (Postfix) with ESMTPA; Tue, 5 May 2020 07:25:59 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_b09fab2e85da488408819cda56d2d4ec" Date: Tue, 05 May 2020 09:25:58 +0200 From: Peter van der Stok To: Benjamin Kaduk Cc: Olaf Bergmann , Jim Schaad , 'Ace' Reply-To: consultancy@vanderstok.org In-Reply-To: <20200505040917.GM27494@kduck.mit.edu> References: <56d31e581571721e176b59db20e08c23@bbhmail.nl> <00f101d61f03$a26bb920$e7432b60$@augustcellars.com> <0873a3115cab89036002cf42b1c97608@bbhmail.nl> <87mu6o6u8t.fsf@wangari> <20200505040917.GM27494@kduck.mit.edu> User-Agent: Roundcube Webmail/1.4-rc2 Message-ID: <90932754f76d8978bdb8a30c794e5343@bbhmail.nl> X-Sender: stokcons@bbhmail.nl Organization: vanderstok consultancy X-Originating-IP: [5.206.216.229] Archived-At: Subject: Re: [Ace] draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 05 May 2020 07:26:10 -0000 --=_b09fab2e85da488408819cda56d2d4ec Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8; format=flowed HI all, I agree about the authorization/trust problem. My request concerns something more trivial. Suppose we have this new network with a set of servers, an (AS) (may be more) and a controller. The servers, controller and AS may have used BRSKI to enter the network. The servers will only provide their service when a token has been sent. The AS is completely empty, not aware of the servers or its clients. The controller wants to fill the AS with the necessary information. Both controller and AS have agreed on an initialization protocol, and are equipped with the necessary secrets. (A protocol to be standardized in general, but not my concen here) Now, what IP address does the controller use to start the communication? Typing in the IP address is a possibility, switching off all other devices is another, etc... I hoped that a coap discovery could be used such that the controller learns the IP address of the AS. When several AS servers are present, the controller can access each one of them out till it accesses the AS with the correct credentials. I hope my request has become a bit clearer. Peter Benjamin Kaduk schreef op 2020-05-05 06:09: > On Mon, May 04, 2020 at 09:21:06AM +0200, Olaf Bergmann wrote: Hi Peter, > > Peter van der Stok writes: > > When I want to access an OCF device I can find its IP address through > service discovery (rfc7252 section 7) using an rt-value registered at > the IANA core parameters registry. For example, when I want to > initialize the AS I have to type in the IP address of the AS. From > that moment on keys and certificates can be compared to continue > initialization. > > Using service discovery can automate that process. > > My request is that authz draft registers an rt-value in core > parameters registry for service discovery of the AS, unless a > different process has already been established for AS initialization. > That is exaclty what originally has been done in section 9 of > draft-gerdes-ace-dcaf-authorize [1]. Somehow, this got lost in the > process. I think I'm still a little confused as to what good being able to "discover" that the network says something is an AS is, without some prior trust and/or key material for that AS. How would the necessary trust be established as part of such a discovery scheme? Thanks, Ben --=_b09fab2e85da488408819cda56d2d4ec Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 HI all,

I agree about the authorization/trust problem.
My r= equest concerns something more trivial.

Suppose we have this new= network with a set of servers, an (AS) (may be more) and a controller.
The servers, controller and AS may have used BRSKI to enter the network= =2E
The servers will only provide their service when a token has been = sent.
The AS is completely empty, not aware of the servers or its clie= nts.
The controller wants to fill the AS with the necessary informatio= n.

Both controller and AS have agreed on an initialization proto= col, and are equipped with the necessary secrets. (A protocol to be standar= dized in general, but not my concen here)

Now, what IP address d= oes the controller use to start the communication?

Typing in the= IP address is a possibility, switching off all other devices is another, e= tc...
I hoped that a coap discovery could be used such that the contro= ller learns the IP address of the AS.

When several AS servers ar= e present, the controller can access each one of them out till it accesses = the AS with the correct credentials.

I hope my request has becom= e a bit clearer.

Peter

Benjamin Kaduk schreef op 2020-05-05 06:09:

= On Mon, May 04, 2020 at 09:21:06AM +0200, Olaf Bergmann wrote:
Hi Peter,

Peter van der Stok <stokcons@bbhmail.nl> writes:

When I want to access an OCF device I can find its IP = address through
service discovery (rfc7252 section 7) using an rt-valu= e registered at
the IANA core parameters registry.  For example, = when I want to
initialize the AS I have to type in the IP address of t= he AS.  From
that moment on keys and certificates can be compared= to continue
initialization.

Using service discovery can au= tomate that process.

My request is that authz draft registers an= rt-value in core
parameters registry for service discovery of the AS,= unless a
different process has already been established for AS initia= lization.

That is exaclty what originally has been done in section 9 of
dr= aft-gerdes-ace-dcaf-authorize [1]. Somehow, this got lost in the
proce= ss.

I think I'm still a little confused as to what good being able to
"discover" that the network says something is an AS is, without some prio= r
trust and/or key material for that AS.  How would the necessary= trust be
established as part of such a discovery scheme?

T= hanks,

Ben
--=_b09fab2e85da488408819cda56d2d4ec-- From nobody Tue May 5 06:37:06 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96D443A0794; Tue, 5 May 2020 06:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrRzeJE6TL8Y; Tue, 5 May 2020 06:36:47 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60062.outbound.protection.outlook.com [40.107.6.62]) (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 2ADA43A0789; Tue, 5 May 2020 06:36:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MALKsU9rv3zcGEDCk6pSDs+rMEMSGNNbpk04rcWnxKmozdhfwkSL0OinntqL/2RdMN25xh5vzHIgRzCqdm1I/GCvGva4zWYZ/2cnN4T+b0dSjlKNuQFSgLWt3S5V8RogPQJ1idKUFE/M0OGrVT+Lc7llqPUtyfXNiOZHBvB8yGVjZClBAJYfThOYjX4LuStmAX7Mop3hXop4N1ZI5LYBH8rGY8tGbXfGFatRhzxzDTefLMOrKDwhL4sPQulDNz+Qmngkgfl7l3cbLHsvIxXcJPT9YNeM4vvd20gsKcKnaw4QQ2X85VGAC8kPfash8lExk6SjRmTGV3j83+hg7F14Mg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=v80f1YDTI0yJErMc8t+RkKBxZcDIXEVrF7DNaGjgYhQ=; b=NPNsBcmVz/79+Z3cf6rWg2cjhwSyPzFQVQUz7fXnXlidoqORvYtvKyE/bwBL+pB5/6t0IxxMsYG8KAmliGMmmiUfu5Rh4+EGZgoOljCK5ZVaKVGgbiBqsn4KQ6JRvvNHj+orLFDAVDeXvBbZ5TPCxrmKGksCICZ/mjcsI7jCfET20ISd2q6Y4ec/5DKV3ZkelVwHXuZPEGd0JsqKqCXWO6Dslo6iA144IMQ373yexAiB2VWqcSdMrXWud6toSVwmZF60wba0lZIYHKEheey4sYMt32AoRl/bhn4DpmPECpre1V8foc36s5jD8/Qp5ADEUOorS1mbAheQ/BvAqq0h2w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=v80f1YDTI0yJErMc8t+RkKBxZcDIXEVrF7DNaGjgYhQ=; b=KfxehdzynxG1+7foXY/GfHL7DjmYq1S8vpjjnlyFHRwl1fNCttcu8RImPMAfMcx1VUO7yfcsPcpKPIhJxt8MbMRl1aRyCblQ14urxr6XTC41Vn5uh61VvTyVzqekoFayJ3XUjp6B8K/WpzuhDKqXZGuixBQfURQM63pPGm0cpsk= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) by HE1PR0702MB3593.eurprd07.prod.outlook.com (2603:10a6:7:7e::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.22; Tue, 5 May 2020 13:36:43 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::f0bb:b1ae:bf22:4526]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::f0bb:b1ae:bf22:4526%6]) with mapi id 15.20.2979.025; Tue, 5 May 2020 13:36:43 +0000 From: Francesca Palombini To: Ace Wg , Benjamin Kaduk , Jim Schaad CC: "draft-ietf-ace-dtls-authorize@ietf.org" , "draft-ietf-ace-oscore-profile@ietf.org" Thread-Topic: Update of access rights Thread-Index: AQHWIuI1Lkw8gf+fQkGotEAa9X56JQ== Date: Tue, 5 May 2020 13:36:41 +0000 Message-ID: <8063D003-2C48-4157-B80E-B7AF3D2099FC@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: abc8bba4-aa67-44ea-08dc-08d7f0f9595b x-ms-traffictypediagnostic: HE1PR0702MB3593: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0394259C80 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: OW7v8+YgRSQd7xwBRIG6ppADz5rqFraCyDDIpTBBwycub6fy5tcatUX7Z0F8Z0IN/P6sKlYrgtBbY5rfuGR7rfn1DWPztWTyFF8FEJ/E2tHqej5KVg5mD3nCVH0OrkNo6QBXdW3JnaZ+bpToTaNbTqfIzHKoW/fHKwvwH/7bGuFpHxtOrSw8+FxQ4jqdp1M7Q4o5ciRChIA35ugmGt78W+OjKaFJNX+yrNMKSPx3I8nhazyoTJ7XwswUgzpMFr/UNefSkr3FKQX7DJS03bxkkhvAto+fZeGE5Oz8J3qn6x4qBHdQJFPaXCbYQzVTwQsUdsosbE2jCJmZFsyalRQSBw3YYdHeGtYCWZSRNQKx0PtqIGfSNyEXViVmDOE2MN5eBJ8TllIoGkQKqUy4BiBPynkap7dC3SaMnUemJn0azJqopYl+Xe/NnKko9EKzFQxYGeYu6a7fDH88G3CGqKgiWORrMlQ/BMGQ8GvrKGcZmnj8VM1EKe5TkujzYxnqfqB6M8xwuYC7ejrY5X4nZhXI4UTWxTaskc+nnvG6fAPAoQS/elf94lrTD22sf0xASJMT5MS0N7sn5mKDL5K/LVtIkOdCFMeg+bX2jrRBxH94n3A= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3818.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(39860400002)(136003)(366004)(396003)(33430700001)(186003)(6486002)(26005)(6506007)(4326008)(15650500001)(6512007)(66946007)(76116006)(71200400001)(66556008)(66476007)(2906002)(64756008)(66446008)(44832011)(2616005)(33656002)(36756003)(86362001)(478600001)(3480700007)(5660300002)(8936002)(54906003)(316002)(33440700001)(110136005)(8676002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: klAY0nCQKL9e9R1rHlxDovRHRu+kKjUcfAPYqp/6XrsF1xjvHZTmy7zd8QQlaZQhEbQofgPhzUMxqEfPaw4kpqtoQMapMcmRFABa8OtNeWUunG0UWMjeeaLG/l9D5ClPhthtOVZm+Z3xY05EXaHLJh02uJ9HBMlt8WOW696Im48EdkSCu74Km2KZKTOWGHKo2UAbTPry3Q3DwKoR1PRgfK7UOt1VxtxLMe4qJ8f6vxbFDTDh9WU4HIyTspaPtgKwKKlbNPwffc8oi0vseB56hQk6YZ7JCr9agq6Ct9glbKScHBsjpctuOmm0INdwYp3t7UbCtXPWUBnGw0pyCEEplJ1MViT0f0ievi3zHEpckWU/jcOAtq18+nCZjMubirx5KB+NZzuDngywWusQ0J/i17xPorGUSJGDQnxzkxUmaezIRXf22cGv8OzvuFUVV15bXONKkZXtuxBZX6JgMhAYG8DOla4GF8FDG+NFLzALu2KUGw/PmeFxB91gdGFWk4Ur36a2GOFbZdew45RAk8Qo9yhU+cgt8W3QG4Yo8//piah3IPtWSe5XXuGn4ATg3oi6p3vMwM67vtZ4etrBtwSHVrrRYv/X9arYW3j1v5W4n6xnPfZkv0qZupReECT1bHzZZDtmiWHv77U+fdfHD5f8S0KfCX/QGF40Oeu0Sshw1U5sw7XIRHmwSl1rDBBPUqVrIYIVST6flazT39NL7SagPfi3B8REfKkOo1q5Y6zNEfyBFkvZKm+O+kpWGV08wmAuLdaawFMvBUOpXzvlwSio39pYbXEfHYHUV9Mi5UgbcB4HS31EKAQRYkjvPd++/3c6 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: abc8bba4-aa67-44ea-08dc-08d7f0f9595b X-MS-Exchange-CrossTenant-originalarrivaltime: 05 May 2020 13:36:43.0936 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: E76347tpB4yQp3q5am6j1gX5IprOPYQrs+Y/kEpWLc6W3JYNOy57CcfBM0/N+SsFGDT7DWAP5W3gfFIg/K3V/xIG1p2s2H3egGVr/q0isFayJgYj2h3DPD+FypqRLEZg X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3593 Archived-At: Subject: [Ace] Update of access rights X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 05 May 2020 13:36:50 -0000 SGkgQWNlIGNoYWlycywgRFRMUyBhdXRob3JzLCBBY2UgZnJhbWV3b3JrIGF1dGhvcnMsIEJlbiwN Cg0KVEw7RFI6IHdlIHByb3Bvc2Ugc29tZSBjaGFuZ2VzIG9uIHRoZSBPU0NPUkUgcHJvZmlsZSBm b3IgdGhlICJ1cGRhdGUgb2YgYWNjZXNzIHJpZ2h0cyIgc2NlbmFyaW8uIFdlIGhhdmUgY29tbWVu dHMgZm9yIHRoZSBEVExTIHByb2ZpbGUgYW5kIHRoZSBBQ0UgZnJhbWV3b3JrIHJlZ2FyZGluZyB0 aGlzIHNjZW5hcmlvLCBhbmQgd2UgYXNrIGZvciBmZWVkYmFjayBmcm9tIEFDRSBPU0NPUkUgaW1w bGVtZW50ZXJzIGFuZCBBY2UgaW4gZ2VuZXJhbC4NCg0KSW4gYW4gYXR0ZW1wdCB0byBhbnN3ZXIg SmltJ3MgKGh0dHBzOi8vZ2l0aHViLmNvbS9hY2Utd2cvYWNlLW9zY29yZS1wcm9maWxlL2lzc3Vl cy8yMCkgYW5kIEJlbidzIChodHRwczovL2dpdGh1Yi5jb20vYWNlLXdnL2FjZS1vc2NvcmUtcHJv ZmlsZS9wdWxsLzMwKSByZXZpZXcgb2YgdGhlIE9TQ09SRSBwcm9maWxlLCB3ZSBoYXZlIGJlZW4g dGhpbmtpbmcgbW9yZSBhYm91dCB0aGUgY2FzZSBvZiB1cGRhdGluZyBhY2Nlc3MgcmlnaHRzLiBU aGlzIGhhcyByZXZlYWxlZCB0byB1cyBhdXRob3JzIHRoYXQgc29tZXRoaW5nIGlzIG1pc3Npbmcg ZnJvbSB0aGUgZG9jdW1lbnQsIGFuZCBJIGJlbGlldmUgdGhhdCB0aGlzIHBhcnQgaXMgbm90IGV4 cGxpY2l0bHkgY292ZXJlZCBpbiB0aGUgRFRMUyBwcm9maWxlIGVpdGhlciwgaGVuY2UgdGhpcyBl bWFpbC4gDQoNClRoaXMgaXMgdGhlIHNjZW5hcmlvLCBhbmQgd2hhdCBpcyBjdXJyZW50bHkgZGVm aW5lZCBpbiB0aGUgT1NDT1JFIHByb2ZpbGU6DQoNCjEuIENsaWVudCByZXRyaWV2ZXMgYWNjZXNz IHRva2VuIFQxIGZyb20gQVMNCjIuIENsaWVudCBwb3N0cyBUMSB0byBSUywgdG9nZXRoZXIgd2l0 aCBub25jZSBOMQ0KMy4gUlMgcmVwbGllcyB3aXRoIDIuMDEgYW5kIG5vbmNlIE4yDQo0LiBDbGll bnQgYW5kIFJTIGRlcml2ZSBPU0NPUkUgU2VjIEN0eCAiU2VjMSIgZnJvbSBUMSAoIm9zYyIgb2Jq ZWN0KSwgTjEsIE4yDQo1LiBDbGllbnQgdXNlcyBTZWMxIHRvIHByb3RlY3QgaXRzIHJlcXVlc3Qg dG8gUlMNCjYuIFJTIHVzZXMgU2VjMSB0byB2ZXJpZnkgcmVxdWVzdC4gVmVyaWZpY2F0aW9uIHN1 Y2Nlc3MgPT4gU2VjMSBpcyB2YWxpZGF0ZWQgYW5kIGFzc29jaWF0ZWQgd2l0aCBUMSAoYXQgdGhl IFJTKQ0KLS0tLQ0KNy4gQ2xpZW50IHdhbnRzIHRvIHVwZGF0ZSBpdHMgYWNjZXNzIHJpZ2h0czog cmV0cmlldmVzIFQyIGZyb20gQVMuIE5vdGUgdGhhdCB0aGlzIFQyIGhhcyBkaWZmZXJlbnQgYXV0 aG9yaXphdGlvbiBpbmZvLCBidXQgZG9lcyBub3QgY29udGFpbiBpbnB1dCBrZXlpbmcgbWF0ZXJp YWwgKCJvc2MiKSwgb25seSBhIHJlZmVyZW5jZSB0byBpZGVudGlmeSBTZWMxICgia2lkIiBpbiAi Y25mIikNCjguIENsaWVudCBwb3N0cyBUMiB0byBSUywgdG9nZXRoZXIgd2l0aCBub25jZSBOMScN CjkuIFJTIHJlcGxpZXMgd2l0aCAyLjAxIGFuZCBub25jZSBOMicNCjEwLiBDbGllbnQgYW5kIFJT IGRlcml2ZSBPU0NPUkUgU2VjIEN0eCAiU2VjMiIgZnJvbSBUMSBrZXlpbmcgaW5wdXQgbWF0ZXJp YWwgKCJvc2MiIG9iamVjdCksIE4xJywgTjInDQoxMS4gQ2xpZW50IHVzZXMgU2VjMiB0byBwcm90 ZWN0IGl0cyByZXF1ZXN0IHRvIFJTDQoxMi4gUlMgdXNlcyBTZWMyIHRvIHZlcmlmeSByZXF1ZXN0 LiBWZXJpZmljYXRpb24gc3VjY2VzcyA9PiBTZWMyIGlzIHZhbGlkYXRlZCBhbmQgYXNzb2NpYXRl ZCB3aXRoIFQyIChhdCB0aGUgUlMpIDsgVDEgaXMgcmVtb3ZlZCA7IFNlYzEgaXMgcmVtb3ZlZA0K DQpJbiB0aGUgZG9jdW1lbnQgcmlnaHQgbm93LCB3ZSBhcmUgbWlzc2luZyB0aGUgZXhhY3QgZGVz Y3JpcHRpb24gb2YgaG93IGluIDguIFJTIGlkZW50aWZpZXMgdGhhdCB0aGlzIGlzIGFuIHVwZGF0 ZSBvZiBhY2Nlc3MgcmlnaHRzIGZvciBDLCBhaW1pbmcgYXQgcmVwbGFjaW5nIFQxLiBXZSBwcm9w b3NlIHRvIGFkZCB0ZXh0IHN0YXRpbmcgdGhhdCAoaW4gMy4gYW5kIDkuKSBSUyBNVVNUIGNoZWNr IHRoZSBraWQgKGluIHRoZSAia2lkIiBpbiB0aGUgImNuZiIgb2YgdGhlIGFjY2VzcyB0b2tlbiks IGFuZCBtYXRjaCBpdCB3aXRoIGV4aXN0aW5nIHNlY3VyaXR5IGNvbnRleHRzLCB0byByZWFsaXpl IHRoYXQgdGhpcyBpcyBhbiB1cGRhdGUgZm9yIGFuIGV4aXN0aW5nIHRva2VuIGFzc29jaWF0ZWQg dG8gdGhlIHNlYyBjdHggaWRlbnRpZmllZCBieSBraWQuDQoNCk1vcmVvdmVyLCB3aGlsZSBjb21w YXJpbmcgd2l0aCBEVExTIHByb2ZpbGUsIHdlIHJlYWxpemVkIHRoZXJlIGlzIG5vIHJlYXNvbiBm b3Igd2hpY2ggOC4gc2hvdWxkIGJlIHNlbnQgdW5wcm90ZWN0ZWQuIEluIGZhY3QsIGRvaW5nIHNv IG9wZW5zIHVwIHRvIHBvc3NpYmxlIGF0dGFja3Mgd2hlcmUgYW4gb2xkIHVwZGF0ZSAodG9rZW4g bm9uIGV4cGlyZWQpIGlzIHJlLWluamVjdGVkIHRvIHRoZSBSUyBieSBhbiBhZHZlcnNhcnk6DQoN CiogQ2xpZW50IHNlbmRzIFQxIHRvIFJTICAtLT4gYWNjZXB0ZWQNCiogQ2xpZW50IHNlbmRzIHVw ZGF0ZSBvZiBhY2Nlc3MgcmlnaHRzIFQyIC0tPiBhY2NlcHRlZA0KKiBDbGllbnQgc2VuZHMgdXBk YXRlIG9mIGFjY2VzcyByaWdodHMgVDMgLS0+IGFjY2VwdGVkDQoqIE1hbGljaW91cyBub2RlIHJl LXNlbmRzIFQyIC0tPiBhY2NlcHRlZA0KDQpPZiBjb3Vyc2UgdGhhdCBjb3VsZCBiZSBtaXRpZ2F0 ZWQgd2l0aCBleHBpcmF0aW9uIHRpbWVzIGFuZCB3aXRoIGNoZWNraW5nICJpc3N1ZWQgYXQgdGlt ZSIgZmllbGQgKHdoaWNoIGlzIG9wdGlvbmFsKS4gQnV0IHdlIGJlbGlldmUgZXZlbiB0aG91Z2gg dGhlc2UgYXJlIGdvb2QgcG9pbnRzICh3aGljaCBtaWdodCBhY3R1YWxseSBiZSB3b3J0aCBhZGRp bmcgdG8gdGhlIGZyYW1ld29yayksIHNlbmRpbmcgdGhlIHRva2VuIHRvIHRoZSBSUyBvdmVyIHRo ZSBleGlzdGluZyBwcm90ZWN0ZWQgY2hhbm5lbCBzb2x2ZXMgdGhpcyBpc3N1ZS4gU28gd2UgcHJv cG9zZSB0aGF0IDguIGlzIHByb3RlY3RlZCB3aXRoIE9TQ09SRSBhbmQgU2VjIEN0eCBTZWMxLiBG b3IgRFRMUyBhdXRob3JzOiBJIGJlbGlldmUgSmltIGhhcyBleHRyYXBvbGF0ZWQgZnJvbSB5b3Vy IGRvY3VtZW50IHRoYXQgdGhhdCBpcyB0aGUgY2FzZSBmb3IgdGhlIERUTFMgcHJvZmlsZSBhbHJl YWR5LCBpLmUuIFBPU1QgdG9rZW4gdG8gUlMgZm9yIHVwZGF0ZSBvZiBhY2Nlc3MgcmlnaHRzIGlz IG92ZXIgRFRMUzsgSSB0aGluayBpdCB3b3VsZCBiZSB3b3J0aCBleHBsaWNpdGx5IHN0YXRpbmcg dGhhdCBpbiB0aGUgRFRMUyBwcm9maWxlLg0KDQpBZGRpdGlvbmFsbHksIGFuYWxvZ291c2x5IHRv IERUTFMgd2hlcmUgdGhlIHNhbWUgY2hhbm5lbCBpcyBrZXB0IGV2ZW4gaWYgYWNjZXNzIHJpZ2h0 cyBhcmUgdXBkYXRlZCwgSSBkbyBub3Qgc2VlIGFueSByZWFzb24gYXQgdGhpcyBwb2ludCB0byBo YXZlIHRoZSBlbmRwb2ludHMgcmUtZGVyaXZlIGEgbmV3IHNlY3VyaXR5IGNvbnRleHQuIFRoaXMg aXMgdGhlIGJpZ2dlc3QgY2hhbmdlIEkgcHJvcG9zZSwgYW5kIGNhbiBiZSBzdW1tYXJpemVkIGJ5 IHJlcGxhY2luZyB0aGUgcG9pbnRzIGFib3ZlIGFzIGZvbGxvd3M6DQoNCjcuIENsaWVudCB3YW50 cyB0byB1cGRhdGUgaXRzIGFjY2VzcyByaWdodHM6IHJldHJpZXZlcyBUMiBmcm9tIEFTLiBOb3Rl IHRoYXQgdGhpcyBUMiBoYXMgZGlmZmVyZW50IGF1dGhvcml6YXRpb24gaW5mbywgYnV0IGRvZXMg bm90IGNvbnRhaW4gaW5wdXQga2V5aW5nIG1hdGVyaWFsLCBvbmx5IGEgcmVmZXJlbmNlIHRvIGlk ZW50aWZ5IFNlYzEgDQo4LiBDbGllbnQgcG9zdHMgVDIgdG8gUlMsICp3aXRob3V0IG5vbmNlKiAq cHJvdGVjdGVkIHdpdGggU2VjMSoNCjkuIFJTICp2ZXJpZmllcyB0aGF0IHRoaXMgaXMgYW4gdXBk YXRlIG9mIGFjY2VzcyByaWdodCwgcmVwbGFjaW5nIFQxIChhc3NvY2lhdGVkIHdpdGggU2VjMSkg OyBTZWMxIGlzIGFzc29jaWF0ZWQgd2l0aCBUMjsgVDEgaXMgcmVtb3ZlZCAqOyBSUyByZXBsaWVz IHdpdGggMi4wMSAqd2l0aG91dCBub25jZSogKnByb3RlY3RlZCB3aXRoIFNlYzEqDQoxMC4gQ2xp ZW50IHVzZXMgKlNlYzEqIHRvIHByb3RlY3QgaXRzIHJlcXVlc3QgdG8gUlMNCg0KSSBjYW4gYWxy ZWFkeSBzZWUgdGhlIG9iamVjdGlvbiBmcm9tIGltcGxlbWVudGVyczogdGhlIGF1dGh6LWluZm8g ZW5kcG9pbnQgYXQgdGhlIFJTIGJlY29tZXMgYWNjZXNzaWJsZSBib3RoIHVucHJvdGVjdGVkIChp biBjYXNlIHRoZSBDbGllbnQgaXMgcG9zdGluZyBhIHRva2VuIGZvciB0aGUgZmlyc3QgdGltZSwg cG9pbnRzIDEuIHRvIDYuKSBhbmQgcHJvdGVjdGVkIChpbiBjYXNlIENsaWVudCBuZWVkcyB0byB1 cGRhdGUgcmlnaHRzLCBwb2ludHMgNy4gdG8gMTAuKSBJIGJlbGlldmUgdGhhdCBkZWZpbmluZyBh IE5FVyBlbmRwb2ludCBhdCB0aGUgUlMgZm9yIHRoZSAidXBkYXRlIHJpZ2h0cyIgbWVjaGFuaXNt IHdvdWxkIGJlIHRoZSBiZXN0IHNvbHV0aW9uLCBidXQgSSB1bmRlcnN0YW5kIHRoYXQgd291bGQg cmVxdWlyZSBtb2RpZmljYXRpb25zIHRvIHRoZSBmcmFtZXdvcmsgdGhhdCBMdWR3aWcgcHJvYmFi bHkgd291bGQgbm90IHdhbnQgdG8gZG8sIGFzIGl0IG1pZ2h0IGRlbGF5IHRoZSBkb2N1bWVudC4g SSB0aGluayB0aGVzZSB3b3VsZCBpbiBwcmFjdGljZSBiZSAyIGRpZmZlcmVudCBlbmRwb2ludHMg d2l0aCB0aGUgc2FtZSBVUkksIG9uZSBPU0NPUkUgcHJvdGVjdGVkIGFuZCBvbmUgdW5wcm90ZWN0 ZWQuIEJ1dCBJIG5lZWQgbW9yZSBpbnB1dCBmcm9tIG91ciBpbXBsZW1lbnRlcnMgdG8ga25vdyBp ZiB0aGlzIGFic29sdXRlbHkgY2Fubm90IGJlIGRvbmUuDQoNCk91ciBwcm9wb3NhbDoNCkFuIFJT IHJlY2VpdmluZyBhIHRva2VuIChwb2ludCAyIGFuZCA4KSBNVVNUIGNoZWNrIHRoZSBraWQgb2Yg dGhlIHRva2VuIGFnYWluc3QgZXhpc3Rpbmcgc2VjdXJpdHkgY29udGV4dHMuIElmIGEgbWF0Y2gg aXMgZm91bmQsIGJ1dCB0aGUgUE9TVCB3YXMgdW5wcm90ZWN0ZWQsIHJlamVjdC4gSWYgYSBtYXRj aCBpcyBmb3VuZCBBTkQgdGhlIFBPU1Qgd2FzIHByb3RlY3RlZCB1c2luZyB0aGF0IHNhbWUgU2Vj IEN0eCBpZGVudGlmaWVkIGJ5IGtpZCwgdXBkYXRlIGFjY2VzcyByaWdodHMuIElmIGEgbWF0Y2gg aXMgbm90IGZvdW5kLCBkZXJpdmUgc2VjIGN0eCBhcyBkZWZpbmVkIGJlZm9yZS4gVGhlc2UgMiBl bmRwb2ludHMgYWxzbyByZXF1aXJlIGRpZmZlcmVudCBwYXlsb2FkOiBwb3N0aW5nIHRoZSB0b2tl biBmb3IgdGhlIGZpcnN0IHRpbWUgdW5wcm90ZWN0ZWQgcmVxdWlyZXMgYSBub25jZSwgcG9zdGlu ZyBhbiB1cGRhdGUgdXNpbmcgT1NDT1JFIGRvZXMgbm90IChhbmQgdGhlIG5vbmNlIHdpbGwgYmUg ZGlzY2FyZGVkIGlmIHNlbnQpLiANCg0KRG9pbmcgc28gYW5zd2VycyBCZW4ncyBwb2ludCBhYm91 dCAyIHRva2VucyBiZWluZyBzYXZlZCBhdCB0aGUgUlMgYXQgdGhlIHNhbWUgdGltZSwgd2hpbGUg U2VjMiBpcyBub3QgeWV0IHZhbGlkYXRlZCAoYmV0d2VlbiA4LiBhbmQgMTIuIGFib3ZlKSwgc2lu Y2UgaXQgcmVtb3ZlcyBTZWMyIGFsdG9nZXRoZXIuIEFzIHNvb24gYXMgVDIgaXMgdmVyaWZpZWQs IFQxIGNhbiBiZSByZXBsYWNlZCB3aXRoIFQyLg0KDQpGaW5hbCBwb2ludDogd2hhdCBoYXBwZW5z IGlmIHRoZSBDbGllbnQgcG9zdHMgYSBzZWNvbmQgdG9rZW4gVDIgKHRvIHVucHJvdGVjdGVkIGF1 dGh6LWluZm8pIHdoaWNoIGNvbnRhaW5zIGEgZGlmZmVyZW50ICJvc2MiIG9iamVjdCwgZGlmZmVy ZW50IGtpZCBldGMuIFRoZSBSUyB3aWxsIG5vdCBiZSBhYmxlIHRvIGlkZW50aWZ5IHRoaXMgQ2xp ZW50IGFzIHNvbWVvbmUgaXQgYWxyZWFkeSBoYXMgYSBzZWMgYXNzb2NpYXRpb24gd2l0aCwgYW5k IGl0IHdpbGwgc2V0IHVwIGEgZGlmZmVyZW50IFNlYyBDdHggd2l0aCBpdC4gSSB0aGluayB0aGlz IGlzIE9LLCBhcyBmb3IgaXQgdG8gYmUgYWNjZXB0ZWQsIHRoZSBBUyBoYWQgdG8gcHJvdmlkZSBz dWNoIGEgdG9rZW4uIFRoZSBmcmFtZXdvcmsgUkVDT01NRU5EUyB0aGF0IGFuIFJTIHN0b3JlcyBv bmx5IG9uZSB0b2tlbiBwZXIgcHJvb2Ytb2YtcG9zc2Vzc2lvbiBrZXksIHdoaWNoIHdvdWxkIHN0 aWxsIGJlIHZhbGlkLCBhcyBkaWZmZXJlbnQgdG9rZW5zIHdvdWxkIGJlIGFzc29jaWF0ZWQgdG8g ZGlmZmVyZW50IFNlYyBjdHhzLg0KDQpBbnkgZmVlZGJhY2sgb3IgY29tbWVudCBpcyBhcHByZWNp YXRlZC4gDQoNClRoYW5rcywNCkZyYW5jZXNjYQ0KDQoNCg0K From nobody Tue May 5 07:07:58 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12ADF3A07A5; Tue, 5 May 2020 07:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 pF5TmQFQfVPc; Tue, 5 May 2020 07:07:53 -0700 (PDT) Received: from weald.air.saab.se (weald.air.saab.se [136.163.212.3]) (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 B45193A07A9; Tue, 5 May 2020 07:07:51 -0700 (PDT) Received: from mailhub2.air.saab.se ([136.163.213.5]) by weald.air.saab.se (8.14.4/8.14.4) with ESMTP id 045E75H8009756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 5 May 2020 16:07:05 +0200 DKIM-Filter: OpenDKIM Filter v2.11.0 weald.air.saab.se 045E75H8009756 Received: from corpappl16592.corp.saab.se (corpappl16592.corp.saab.se [10.12.12.98]) by mailhub2.air.saab.se (8.13.8/8.13.8) with ESMTP id 045E6qjK001028 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 May 2020 16:06:52 +0200 Received: from corpappl16593.corp.saab.se (10.12.12.125) by corpappl16592.corp.saab.se (10.12.12.98) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Tue, 5 May 2020 16:06:52 +0200 Received: from corpappl16593.corp.saab.se ([fe80::b4c9:ca69:a80d:fa3]) by corpappl16593.corp.saab.se ([fe80::b4c9:ca69:a80d:fa3%4]) with mapi id 15.01.1847.009; Tue, 5 May 2020 16:06:52 +0200 From: Seitz Ludwig To: Francesca Palombini , Ace Wg , Benjamin Kaduk , Jim Schaad CC: "draft-ietf-ace-dtls-authorize@ietf.org" , "draft-ietf-ace-oscore-profile@ietf.org" Thread-Topic: Update of access rights Thread-Index: AQHWIuI1Lkw8gf+fQkGotEAa9X56JaiZhN0A Date: Tue, 5 May 2020 14:06:51 +0000 Message-ID: <3a43784230a343cabb594b30a08dee96@combitech.se> References: <8063D003-2C48-4157-B80E-B7AF3D2099FC@ericsson.com> In-Reply-To: <8063D003-2C48-4157-B80E-B7AF3D2099FC@ericsson.com> Accept-Language: en-SE, sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.12.13.199] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Saab-MailScanner-Information: Please contact the ISP for more information X-Saab-MailScanner-ID: 045E6qjK001028 X-Saab-MailScanner: Found to be clean X-Saab-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.498, required 5, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -0.50, SURBL_BLOCKED 0.00, URIBL_BLOCKED 0.00) X-Saab-MailScanner-From: ludwig.seitz@combitech.se X-Saab-MailScanner-Watermark: 1589292413.44973@0Gut6Rg3MDqBKkZ0At8BrQ X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (weald.air.saab.se [136.163.212.3]); Tue, 05 May 2020 16:07:06 +0200 (CEST) Archived-At: Subject: Re: [Ace] Update of access rights X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 05 May 2020 14:07:57 -0000 SGVsbG8gRnJhbmNlc2NhLA0KDQpJIGhhdmUgbm90IGZvbGxvd2VkIHRoaXMgZGlzY3Vzc2lvbiBp biBkZXRhaWwgc28gZXhjdXNlIG1lIGlmIEkgbWlzc2VkIGFuIGltcG9ydGFudCBkZXRhaWwuIFRo YXQgc2FpZDogSSBjYW5ub3QgdW5kZXJzdGFuZCB3aHkgeW91IHdvdWxkIHdhbnQgdG8gbmVnb3Rp YXRlIGEgbmV3IGNvbnRleHQgaW4gc3RlcCA4IGJ5IHNlbmRpbmcgTjEnPyBBdCB0aGF0IHBvaW50 IHlvdSBoYXZlIGEgZnVuY3Rpb25hbCBPU0NPUkUgY29udGV4dCBlc3RhYmxpc2hlZCBhbmQgY291 bGQganVzdCBzZW5kIFQyIGFzc29jaWF0ZWQgdG8gdGhlIHNhbWUgY29udGV4dCBTZWMxLiBUaGF0 IGlzIGhvdyBJIGFzc3VtZWQgaXQgd291bGQgd29yaywgaWYgdGhhdCBpcyBub3QgY2xlYXIgd2Ug bmVlZCB0byBhZGQgdGV4dCB0byB0aGUgcHJvZmlsZXMgdG8gY2xhcmlmeS4NCg0KSXQgaXMgYSBi aXQgY29tcGxpY2F0ZWQgY29kZS13aXNlIHRvIGhhdmUgYW4gZW5kcG9pbnQgdGhhdCBpcyBhY2Nl c3NpYmxlIGJvdGggdW5wcm90ZWN0ZWQgYW5kIHdpdGggT1NDT1JFLCBidXQgSSB0aGluayBpdCBp cyBmZWFzaWJsZSAoaG93ZXZlciBub3QgYmUgbXkgaW4gdGhlIEFDRS1KYXZhIGNvZGViYXNlLCBA TWFyY28/KS4NCg0KL0x1ZHdpZw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog RnJhbmNlc2NhIFBhbG9tYmluaSA8ZnJhbmNlc2NhLnBhbG9tYmluaUBlcmljc3Nvbi5jb20+IA0K U2VudDogZGVuIDUgbWFqIDIwMjAgMTU6MzcNClRvOiBBY2UgV2cgPGFjZUBpZXRmLm9yZz47IEJl bmphbWluIEthZHVrIDxrYWR1a0BtaXQuZWR1PjsgSmltIFNjaGFhZCA8aWV0ZkBhdWd1c3RjZWxs YXJzLmNvbT4NCkNjOiBkcmFmdC1pZXRmLWFjZS1kdGxzLWF1dGhvcml6ZUBpZXRmLm9yZzsgZHJh ZnQtaWV0Zi1hY2Utb3Njb3JlLXByb2ZpbGVAaWV0Zi5vcmcNClN1YmplY3Q6IFVwZGF0ZSBvZiBh Y2Nlc3MgcmlnaHRzDQoNCkhpIEFjZSBjaGFpcnMsIERUTFMgYXV0aG9ycywgQWNlIGZyYW1ld29y ayBhdXRob3JzLCBCZW4sDQoNClRMO0RSOiB3ZSBwcm9wb3NlIHNvbWUgY2hhbmdlcyBvbiB0aGUg T1NDT1JFIHByb2ZpbGUgZm9yIHRoZSAidXBkYXRlIG9mIGFjY2VzcyByaWdodHMiIHNjZW5hcmlv LiBXZSBoYXZlIGNvbW1lbnRzIGZvciB0aGUgRFRMUyBwcm9maWxlIGFuZCB0aGUgQUNFIGZyYW1l d29yayByZWdhcmRpbmcgdGhpcyBzY2VuYXJpbywgYW5kIHdlIGFzayBmb3IgZmVlZGJhY2sgZnJv bSBBQ0UgT1NDT1JFIGltcGxlbWVudGVycyBhbmQgQWNlIGluIGdlbmVyYWwuDQoNCkluIGFuIGF0 dGVtcHQgdG8gYW5zd2VyIEppbSdzIChodHRwczovL2dpdGh1Yi5jb20vYWNlLXdnL2FjZS1vc2Nv cmUtcHJvZmlsZS9pc3N1ZXMvMjApIGFuZCBCZW4ncyAoaHR0cHM6Ly9naXRodWIuY29tL2FjZS13 Zy9hY2Utb3Njb3JlLXByb2ZpbGUvcHVsbC8zMCkgcmV2aWV3IG9mIHRoZSBPU0NPUkUgcHJvZmls ZSwgd2UgaGF2ZSBiZWVuIHRoaW5raW5nIG1vcmUgYWJvdXQgdGhlIGNhc2Ugb2YgdXBkYXRpbmcg YWNjZXNzIHJpZ2h0cy4gVGhpcyBoYXMgcmV2ZWFsZWQgdG8gdXMgYXV0aG9ycyB0aGF0IHNvbWV0 aGluZyBpcyBtaXNzaW5nIGZyb20gdGhlIGRvY3VtZW50LCBhbmQgSSBiZWxpZXZlIHRoYXQgdGhp cyBwYXJ0IGlzIG5vdCBleHBsaWNpdGx5IGNvdmVyZWQgaW4gdGhlIERUTFMgcHJvZmlsZSBlaXRo ZXIsIGhlbmNlIHRoaXMgZW1haWwuIA0KDQpUaGlzIGlzIHRoZSBzY2VuYXJpbywgYW5kIHdoYXQg aXMgY3VycmVudGx5IGRlZmluZWQgaW4gdGhlIE9TQ09SRSBwcm9maWxlOg0KDQoxLiBDbGllbnQg cmV0cmlldmVzIGFjY2VzcyB0b2tlbiBUMSBmcm9tIEFTIDIuIENsaWVudCBwb3N0cyBUMSB0byBS UywgdG9nZXRoZXIgd2l0aCBub25jZSBOMSAzLiBSUyByZXBsaWVzIHdpdGggMi4wMSBhbmQgbm9u Y2UgTjIgNC4gQ2xpZW50IGFuZCBSUyBkZXJpdmUgT1NDT1JFIFNlYyBDdHggIlNlYzEiIGZyb20g VDEgKCJvc2MiIG9iamVjdCksIE4xLCBOMiA1LiBDbGllbnQgdXNlcyBTZWMxIHRvIHByb3RlY3Qg aXRzIHJlcXVlc3QgdG8gUlMgNi4gUlMgdXNlcyBTZWMxIHRvIHZlcmlmeSByZXF1ZXN0LiBWZXJp ZmljYXRpb24gc3VjY2VzcyA9PiBTZWMxIGlzIHZhbGlkYXRlZCBhbmQgYXNzb2NpYXRlZCB3aXRo IFQxIChhdCB0aGUgUlMpDQotLS0tDQo3LiBDbGllbnQgd2FudHMgdG8gdXBkYXRlIGl0cyBhY2Nl c3MgcmlnaHRzOiByZXRyaWV2ZXMgVDIgZnJvbSBBUy4gTm90ZSB0aGF0IHRoaXMgVDIgaGFzIGRp ZmZlcmVudCBhdXRob3JpemF0aW9uIGluZm8sIGJ1dCBkb2VzIG5vdCBjb250YWluIGlucHV0IGtl eWluZyBtYXRlcmlhbCAoIm9zYyIpLCBvbmx5IGEgcmVmZXJlbmNlIHRvIGlkZW50aWZ5IFNlYzEg KCJraWQiIGluICJjbmYiKSA4LiBDbGllbnQgcG9zdHMgVDIgdG8gUlMsIHRvZ2V0aGVyIHdpdGgg bm9uY2UgTjEnDQo5LiBSUyByZXBsaWVzIHdpdGggMi4wMSBhbmQgbm9uY2UgTjInDQoxMC4gQ2xp ZW50IGFuZCBSUyBkZXJpdmUgT1NDT1JFIFNlYyBDdHggIlNlYzIiIGZyb20gVDEga2V5aW5nIGlu cHV0IG1hdGVyaWFsICgib3NjIiBvYmplY3QpLCBOMScsIE4yJw0KMTEuIENsaWVudCB1c2VzIFNl YzIgdG8gcHJvdGVjdCBpdHMgcmVxdWVzdCB0byBSUyAxMi4gUlMgdXNlcyBTZWMyIHRvIHZlcmlm eSByZXF1ZXN0LiBWZXJpZmljYXRpb24gc3VjY2VzcyA9PiBTZWMyIGlzIHZhbGlkYXRlZCBhbmQg YXNzb2NpYXRlZCB3aXRoIFQyIChhdCB0aGUgUlMpIDsgVDEgaXMgcmVtb3ZlZCA7IFNlYzEgaXMg cmVtb3ZlZA0KDQpJbiB0aGUgZG9jdW1lbnQgcmlnaHQgbm93LCB3ZSBhcmUgbWlzc2luZyB0aGUg ZXhhY3QgZGVzY3JpcHRpb24gb2YgaG93IGluIDguIFJTIGlkZW50aWZpZXMgdGhhdCB0aGlzIGlz IGFuIHVwZGF0ZSBvZiBhY2Nlc3MgcmlnaHRzIGZvciBDLCBhaW1pbmcgYXQgcmVwbGFjaW5nIFQx LiBXZSBwcm9wb3NlIHRvIGFkZCB0ZXh0IHN0YXRpbmcgdGhhdCAoaW4gMy4gYW5kIDkuKSBSUyBN VVNUIGNoZWNrIHRoZSBraWQgKGluIHRoZSAia2lkIiBpbiB0aGUgImNuZiIgb2YgdGhlIGFjY2Vz cyB0b2tlbiksIGFuZCBtYXRjaCBpdCB3aXRoIGV4aXN0aW5nIHNlY3VyaXR5IGNvbnRleHRzLCB0 byByZWFsaXplIHRoYXQgdGhpcyBpcyBhbiB1cGRhdGUgZm9yIGFuIGV4aXN0aW5nIHRva2VuIGFz c29jaWF0ZWQgdG8gdGhlIHNlYyBjdHggaWRlbnRpZmllZCBieSBraWQuDQoNCk1vcmVvdmVyLCB3 aGlsZSBjb21wYXJpbmcgd2l0aCBEVExTIHByb2ZpbGUsIHdlIHJlYWxpemVkIHRoZXJlIGlzIG5v IHJlYXNvbiBmb3Igd2hpY2ggOC4gc2hvdWxkIGJlIHNlbnQgdW5wcm90ZWN0ZWQuIEluIGZhY3Qs IGRvaW5nIHNvIG9wZW5zIHVwIHRvIHBvc3NpYmxlIGF0dGFja3Mgd2hlcmUgYW4gb2xkIHVwZGF0 ZSAodG9rZW4gbm9uIGV4cGlyZWQpIGlzIHJlLWluamVjdGVkIHRvIHRoZSBSUyBieSBhbiBhZHZl cnNhcnk6DQoNCiogQ2xpZW50IHNlbmRzIFQxIHRvIFJTICAtLT4gYWNjZXB0ZWQNCiogQ2xpZW50 IHNlbmRzIHVwZGF0ZSBvZiBhY2Nlc3MgcmlnaHRzIFQyIC0tPiBhY2NlcHRlZA0KKiBDbGllbnQg c2VuZHMgdXBkYXRlIG9mIGFjY2VzcyByaWdodHMgVDMgLS0+IGFjY2VwdGVkDQoqIE1hbGljaW91 cyBub2RlIHJlLXNlbmRzIFQyIC0tPiBhY2NlcHRlZA0KDQpPZiBjb3Vyc2UgdGhhdCBjb3VsZCBi ZSBtaXRpZ2F0ZWQgd2l0aCBleHBpcmF0aW9uIHRpbWVzIGFuZCB3aXRoIGNoZWNraW5nICJpc3N1 ZWQgYXQgdGltZSIgZmllbGQgKHdoaWNoIGlzIG9wdGlvbmFsKS4gQnV0IHdlIGJlbGlldmUgZXZl biB0aG91Z2ggdGhlc2UgYXJlIGdvb2QgcG9pbnRzICh3aGljaCBtaWdodCBhY3R1YWxseSBiZSB3 b3J0aCBhZGRpbmcgdG8gdGhlIGZyYW1ld29yayksIHNlbmRpbmcgdGhlIHRva2VuIHRvIHRoZSBS UyBvdmVyIHRoZSBleGlzdGluZyBwcm90ZWN0ZWQgY2hhbm5lbCBzb2x2ZXMgdGhpcyBpc3N1ZS4g U28gd2UgcHJvcG9zZSB0aGF0IDguIGlzIHByb3RlY3RlZCB3aXRoIE9TQ09SRSBhbmQgU2VjIEN0 eCBTZWMxLiBGb3IgRFRMUyBhdXRob3JzOiBJIGJlbGlldmUgSmltIGhhcyBleHRyYXBvbGF0ZWQg ZnJvbSB5b3VyIGRvY3VtZW50IHRoYXQgdGhhdCBpcyB0aGUgY2FzZSBmb3IgdGhlIERUTFMgcHJv ZmlsZSBhbHJlYWR5LCBpLmUuIFBPU1QgdG9rZW4gdG8gUlMgZm9yIHVwZGF0ZSBvZiBhY2Nlc3Mg cmlnaHRzIGlzIG92ZXIgRFRMUzsgSSB0aGluayBpdCB3b3VsZCBiZSB3b3J0aCBleHBsaWNpdGx5 IHN0YXRpbmcgdGhhdCBpbiB0aGUgRFRMUyBwcm9maWxlLg0KDQpBZGRpdGlvbmFsbHksIGFuYWxv Z291c2x5IHRvIERUTFMgd2hlcmUgdGhlIHNhbWUgY2hhbm5lbCBpcyBrZXB0IGV2ZW4gaWYgYWNj ZXNzIHJpZ2h0cyBhcmUgdXBkYXRlZCwgSSBkbyBub3Qgc2VlIGFueSByZWFzb24gYXQgdGhpcyBw b2ludCB0byBoYXZlIHRoZSBlbmRwb2ludHMgcmUtZGVyaXZlIGEgbmV3IHNlY3VyaXR5IGNvbnRl eHQuIFRoaXMgaXMgdGhlIGJpZ2dlc3QgY2hhbmdlIEkgcHJvcG9zZSwgYW5kIGNhbiBiZSBzdW1t YXJpemVkIGJ5IHJlcGxhY2luZyB0aGUgcG9pbnRzIGFib3ZlIGFzIGZvbGxvd3M6DQoNCjcuIENs aWVudCB3YW50cyB0byB1cGRhdGUgaXRzIGFjY2VzcyByaWdodHM6IHJldHJpZXZlcyBUMiBmcm9t IEFTLiBOb3RlIHRoYXQgdGhpcyBUMiBoYXMgZGlmZmVyZW50IGF1dGhvcml6YXRpb24gaW5mbywg YnV0IGRvZXMgbm90IGNvbnRhaW4gaW5wdXQga2V5aW5nIG1hdGVyaWFsLCBvbmx5IGEgcmVmZXJl bmNlIHRvIGlkZW50aWZ5IFNlYzEgOC4gQ2xpZW50IHBvc3RzIFQyIHRvIFJTLCAqd2l0aG91dCBu b25jZSogKnByb3RlY3RlZCB3aXRoIFNlYzEqIDkuIFJTICp2ZXJpZmllcyB0aGF0IHRoaXMgaXMg YW4gdXBkYXRlIG9mIGFjY2VzcyByaWdodCwgcmVwbGFjaW5nIFQxIChhc3NvY2lhdGVkIHdpdGgg U2VjMSkgOyBTZWMxIGlzIGFzc29jaWF0ZWQgd2l0aCBUMjsgVDEgaXMgcmVtb3ZlZCAqOyBSUyBy ZXBsaWVzIHdpdGggMi4wMSAqd2l0aG91dCBub25jZSogKnByb3RlY3RlZCB3aXRoIFNlYzEqIDEw LiBDbGllbnQgdXNlcyAqU2VjMSogdG8gcHJvdGVjdCBpdHMgcmVxdWVzdCB0byBSUw0KDQpJIGNh biBhbHJlYWR5IHNlZSB0aGUgb2JqZWN0aW9uIGZyb20gaW1wbGVtZW50ZXJzOiB0aGUgYXV0aHot aW5mbyBlbmRwb2ludCBhdCB0aGUgUlMgYmVjb21lcyBhY2Nlc3NpYmxlIGJvdGggdW5wcm90ZWN0 ZWQgKGluIGNhc2UgdGhlIENsaWVudCBpcyBwb3N0aW5nIGEgdG9rZW4gZm9yIHRoZSBmaXJzdCB0 aW1lLCBwb2ludHMgMS4gdG8gNi4pIGFuZCBwcm90ZWN0ZWQgKGluIGNhc2UgQ2xpZW50IG5lZWRz IHRvIHVwZGF0ZSByaWdodHMsIHBvaW50cyA3LiB0byAxMC4pIEkgYmVsaWV2ZSB0aGF0IGRlZmlu aW5nIGEgTkVXIGVuZHBvaW50IGF0IHRoZSBSUyBmb3IgdGhlICJ1cGRhdGUgcmlnaHRzIiBtZWNo YW5pc20gd291bGQgYmUgdGhlIGJlc3Qgc29sdXRpb24sIGJ1dCBJIHVuZGVyc3RhbmQgdGhhdCB3 b3VsZCByZXF1aXJlIG1vZGlmaWNhdGlvbnMgdG8gdGhlIGZyYW1ld29yayB0aGF0IEx1ZHdpZyBw cm9iYWJseSB3b3VsZCBub3Qgd2FudCB0byBkbywgYXMgaXQgbWlnaHQgZGVsYXkgdGhlIGRvY3Vt ZW50LiBJIHRoaW5rIHRoZXNlIHdvdWxkIGluIHByYWN0aWNlIGJlIDIgZGlmZmVyZW50IGVuZHBv aW50cyB3aXRoIHRoZSBzYW1lIFVSSSwgb25lIE9TQ09SRSBwcm90ZWN0ZWQgYW5kIG9uZSB1bnBy b3RlY3RlZC4gQnV0IEkgbmVlZCBtb3JlIGlucHV0IGZyb20gb3VyIGltcGxlbWVudGVycyB0byBr bm93IGlmIHRoaXMgYWJzb2x1dGVseSBjYW5ub3QgYmUgZG9uZS4NCg0KT3VyIHByb3Bvc2FsOg0K QW4gUlMgcmVjZWl2aW5nIGEgdG9rZW4gKHBvaW50IDIgYW5kIDgpIE1VU1QgY2hlY2sgdGhlIGtp ZCBvZiB0aGUgdG9rZW4gYWdhaW5zdCBleGlzdGluZyBzZWN1cml0eSBjb250ZXh0cy4gSWYgYSBt YXRjaCBpcyBmb3VuZCwgYnV0IHRoZSBQT1NUIHdhcyB1bnByb3RlY3RlZCwgcmVqZWN0LiBJZiBh IG1hdGNoIGlzIGZvdW5kIEFORCB0aGUgUE9TVCB3YXMgcHJvdGVjdGVkIHVzaW5nIHRoYXQgc2Ft ZSBTZWMgQ3R4IGlkZW50aWZpZWQgYnkga2lkLCB1cGRhdGUgYWNjZXNzIHJpZ2h0cy4gSWYgYSBt YXRjaCBpcyBub3QgZm91bmQsIGRlcml2ZSBzZWMgY3R4IGFzIGRlZmluZWQgYmVmb3JlLiBUaGVz ZSAyIGVuZHBvaW50cyBhbHNvIHJlcXVpcmUgZGlmZmVyZW50IHBheWxvYWQ6IHBvc3RpbmcgdGhl IHRva2VuIGZvciB0aGUgZmlyc3QgdGltZSB1bnByb3RlY3RlZCByZXF1aXJlcyBhIG5vbmNlLCBw b3N0aW5nIGFuIHVwZGF0ZSB1c2luZyBPU0NPUkUgZG9lcyBub3QgKGFuZCB0aGUgbm9uY2Ugd2ls bCBiZSBkaXNjYXJkZWQgaWYgc2VudCkuIA0KDQpEb2luZyBzbyBhbnN3ZXJzIEJlbidzIHBvaW50 IGFib3V0IDIgdG9rZW5zIGJlaW5nIHNhdmVkIGF0IHRoZSBSUyBhdCB0aGUgc2FtZSB0aW1lLCB3 aGlsZSBTZWMyIGlzIG5vdCB5ZXQgdmFsaWRhdGVkIChiZXR3ZWVuIDguIGFuZCAxMi4gYWJvdmUp LCBzaW5jZSBpdCByZW1vdmVzIFNlYzIgYWx0b2dldGhlci4gQXMgc29vbiBhcyBUMiBpcyB2ZXJp ZmllZCwgVDEgY2FuIGJlIHJlcGxhY2VkIHdpdGggVDIuDQoNCkZpbmFsIHBvaW50OiB3aGF0IGhh cHBlbnMgaWYgdGhlIENsaWVudCBwb3N0cyBhIHNlY29uZCB0b2tlbiBUMiAodG8gdW5wcm90ZWN0 ZWQgYXV0aHotaW5mbykgd2hpY2ggY29udGFpbnMgYSBkaWZmZXJlbnQgIm9zYyIgb2JqZWN0LCBk aWZmZXJlbnQga2lkIGV0Yy4gVGhlIFJTIHdpbGwgbm90IGJlIGFibGUgdG8gaWRlbnRpZnkgdGhp cyBDbGllbnQgYXMgc29tZW9uZSBpdCBhbHJlYWR5IGhhcyBhIHNlYyBhc3NvY2lhdGlvbiB3aXRo LCBhbmQgaXQgd2lsbCBzZXQgdXAgYSBkaWZmZXJlbnQgU2VjIEN0eCB3aXRoIGl0LiBJIHRoaW5r IHRoaXMgaXMgT0ssIGFzIGZvciBpdCB0byBiZSBhY2NlcHRlZCwgdGhlIEFTIGhhZCB0byBwcm92 aWRlIHN1Y2ggYSB0b2tlbi4gVGhlIGZyYW1ld29yayBSRUNPTU1FTkRTIHRoYXQgYW4gUlMgc3Rv cmVzIG9ubHkgb25lIHRva2VuIHBlciBwcm9vZi1vZi1wb3NzZXNzaW9uIGtleSwgd2hpY2ggd291 bGQgc3RpbGwgYmUgdmFsaWQsIGFzIGRpZmZlcmVudCB0b2tlbnMgd291bGQgYmUgYXNzb2NpYXRl ZCB0byBkaWZmZXJlbnQgU2VjIGN0eHMuDQoNCkFueSBmZWVkYmFjayBvciBjb21tZW50IGlzIGFw cHJlY2lhdGVkLiANCg0KVGhhbmtzLA0KRnJhbmNlc2NhDQoNCg0KDQo= From nobody Tue May 5 07:13:47 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90ED93A0400; Tue, 5 May 2020 07:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2B6GDY0vD7z; Tue, 5 May 2020 07:13:43 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2088.outbound.protection.outlook.com [40.107.21.88]) (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 CBFE73A07A9; Tue, 5 May 2020 07:13:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nFax10Tr872yRp7auaVkcWy5WCdZcNvAF7r6ndBJuzS+apkwPqF2mcsA47VIGvJH3wRDEmVAvwBYGXh4MotSIDLM7sT2AeD6G7C9pBPLdcLEubSPdCh4wg6igfGL3p4/5VRb3HRqWibvMrWmTtGRVz1Ny4TrsQcS8c57udVryxo9Yog0UczHwRtbX7rugoPwwp5vgpw7OlByoCpJIE62yuYmxTsu9yp55Vo7G0mmZXc3Yfo4OWgC3VVPZJBWRTFwVN6DKKffkAn9mBRLg2ykexRvYzMZB6ifW2oJglJb/AI7VPzpcT7BAXzBCALwCDRh777mZ9tKMVsXnsVexCywZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ArxsTcJBeklPvZXPhaIbtu/aFjj/Bz2Ss46uYmOYfRg=; b=Iz3gg/VjV24+nKFR8eFHKUgmjEjIYZehK2H/h1SVs5bQaf8CDhCIze22L24NqJhuy07g5XnOz2MEz897dBpxgs4BtJJMfSOfoEStXJtI7TVanm5k4/ekU9YPandOv2cUvWz3mdj+7iY9z6PZwzi8hiUSsHe8X3IQX4Tv1w2/Gvc10VopD/x4t5QTexGD31wF9E7grdw3hZ0e6IDr8N1fb14aTHJnsWLTS+FU2gJgvBoHoqBtkP9Ad37M7kJkCcHELUEroODKCbmkoR0ymY8Nw4ik0T++u8thE7FZH+3SzdTwG+LZwnSNbatbEja96kBzS3rsfoQesT/ZAOLuxarLug== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ArxsTcJBeklPvZXPhaIbtu/aFjj/Bz2Ss46uYmOYfRg=; b=gn2S/IyaVHQLUUHKNqQSCPlvloXqFXtQgqBUeiNqRqIBdO5cgXLCpCuAxHWqrzrt1g99bmtjBLun9+FWcfGsBRuZ7HDNDcRKZ9Frev4Ybb9jVoQs0yB73mlw+doKO2QbgS9ypKF/4zO9x1V63doOfmK+ebgNwUHBIEqvnt6y79Q= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) by HE1PR0702MB3690.eurprd07.prod.outlook.com (2603:10a6:7:7e::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.18; Tue, 5 May 2020 14:13:40 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::f0bb:b1ae:bf22:4526]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::f0bb:b1ae:bf22:4526%6]) with mapi id 15.20.2979.025; Tue, 5 May 2020 14:13:39 +0000 From: Francesca Palombini To: Seitz Ludwig , Ace Wg , Benjamin Kaduk , Jim Schaad CC: "draft-ietf-ace-dtls-authorize@ietf.org" , "draft-ietf-ace-oscore-profile@ietf.org" Thread-Topic: Update of access rights Thread-Index: AQHWIuI1Lkw8gf+fQkGotEAa9X56JaiZhN0AgAAlpIA= Date: Tue, 5 May 2020 14:13:39 +0000 Message-ID: References: <8063D003-2C48-4157-B80E-B7AF3D2099FC@ericsson.com> <3a43784230a343cabb594b30a08dee96@combitech.se> In-Reply-To: <3a43784230a343cabb594b30a08dee96@combitech.se> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: combitech.se; dkim=none (message not signed) header.d=none;combitech.se; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2a6045f7-2642-4451-97e4-08d7f0fe8299 x-ms-traffictypediagnostic: HE1PR0702MB3690: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0394259C80 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: GawhEqx8zoX0cuoBs4jH8KQwDlJRxMpoLxX/iRO2kzN5qpCv6de/qr77ENqryd2+/q+6sGYHwzPTtSis8gU8xiSJtD87oSCBqD44qr6AJy8NHAxgDpZ3SrFTKjZTDo+NlYQv2GPF2ZJOhkAVZg4oiwpQP+S96D1k9EM+O0HYSG2LEYaoaJHRzQih/WrWwhGWiNnC5T3idsxHAEl0wjej0QkDlLW1zj70EsMsX/kou0tnUxJEoY83ldzmY3ROGiHs/4/3l1ifmWL7QPThlBx1O52/A91ZqVMrLwbPawkuTJ8o84FxNkGz8vDnxn34y0UNyYYSRzhdz/Jnq+Aj32p2p64Q9sFovawhpkaS1n/NC6tIC15hkHMEdR2rXykotU74TARpeNuenhjYHV4RN9dTsbEFybJWTUTii8esPesxNn6jhU97y3OBQ6yYnsmfV6Fbymht3Dlq6pQ2MlOKrDlzTXacOQ8b8NudqkmzMIHKVrz0OB7rnSZz4PwDEohn9k7heYrrw/eow7FKlIW3QcjY1/dEiFMPwMTwvi0vRBqz64eIDBVVyTAa1IBptEb5fQaLi6jzJe4F9a79UD3khtn5MUM3cWKhCwpRd+5RL+AtFEc= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3818.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(366004)(396003)(346002)(136003)(39860400002)(33430700001)(316002)(6512007)(4326008)(86362001)(53546011)(6506007)(15650500001)(110136005)(54906003)(33656002)(2906002)(8936002)(8676002)(6486002)(2616005)(44832011)(3480700007)(66556008)(5660300002)(66476007)(64756008)(66446008)(76116006)(36756003)(66946007)(186003)(26005)(478600001)(33440700001)(71200400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: Sj5bjalj8ZA4++l0qLQBE/QA3h7iXQs0nGaIzZDpjWTq9SLWI4H0VeSHAn663yOyjavbHSKvaBINv4qSZX58hTS7zGQWJZ2bFL3KUBiv9pCrZB0OP5/BjXlyZD3I2iYOXsggPl9xLBwVDDADMGyCENY+0pohErz4kOpe8Lc+WIhOcqgSmEWebDA/EILRvNfGHs2DnTVpEdXuhw3pArjyYugsmX3i+XzNe9tTMbcV9vC3OExBolwSanQmFTxyYAE2sjW8tlfhQt+3PDD6zlT7a1J7boqU5tqxTtiEo59Cp9pF9bst/NwZKeIDLP/deuwYwH9YPj6KJ8cvk6BvxgBeDs00TQMK3kxwu5Juh4abuEu76LvuAvqCA8G997b/mtmCM5YLlqKyVEFxDaeyCdiv7+9sBqFz4zdWLn10Mm378zzUsR9S825kY7PO0Gxjqxl0xLSJkIyrb0Q0nUfQMbjNoVl37wPv66jSDNwKVD4a9bQq/3kwnwHVR/4Kyo+YncpIDNrzTdpw23vk1Lm1VTcI6Aox9PqYK1Hn5x8sxGp+xHAyRS+hGKzkgrZDFTBObfZ825J4XNDy6VKxSXYILdOQYwPlKTk2FuuTZn4G3nZjrxVEXLjw9rHfHlgZdAhTJzc/SCC0n21earR/glATrUWZn/tzr9fbNaV9euBbvwoEJtksQ5ubOaU6+iReU4oL2crhYFbXb+8FplXmbsshJtCu1q7AyZff6IRfNaVNPdeEwNHSvpXfUNQGc1tonw/m3UgOHXdj3i6+kGg6BzgJQapBGvzK1Sp3Svf0dPxTT2TfZZwHXkYQp4yHrlE+wLUNW4Z9 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <34BD9AAF728BEE4589468C492B539F7D@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2a6045f7-2642-4451-97e4-08d7f0fe8299 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 May 2020 14:13:39.8048 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: XaOTM0DN5FJISkYtbter9dtMg9FF8I/XXOlSPwyuRGOatMyhGl7JfaM/C4gh5m4evIeyuFWL1c0Zge89hTqG/KlmGv2scaoGvL145x9g3mC27X62Avw0u1ws4VHCclsW X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3690 Archived-At: Subject: Re: [Ace] Update of access rights X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 05 May 2020 14:13:46 -0000 SGkgTHVkd2lnLA0KDQpXaGF0IHlvdSBzdGF0ZSBpcyBpbiBmYWN0IHRoZSBjaGFuZ2UgcHJvcG9z ZWQgYmVsb3csIEknbSBoYXBweSB5b3Ugc3VwcG9ydCBtYWtpbmcgdGhpcyBjaGFuZ2UuIFRoZSBy ZWFzb24gd2h5IGl0IGRvZXMgbm90IHdvcmsgdGhhdCB3YXkgYWxyZWFkeSBpcyBiZWNhdXNlIG9m IHRoZSB3YXkgYXV0aHotaW5mbyBpcyBkZWZpbmVkIGZvciB0aGUgImdlbmVyYWwiIGNhc2UgKGV4 Y2hhbmdlIG9mIG5vbmNlcyBpcyBuZWNlc3NhcnksIGFuZCBkZXJpdmF0aW9uIG9mIHNlYyBjdHgp LiBUaGUgY2hhbmdlIEkgYW0gbWFraW5nIHN1Z2dlc3RzIHRvIGRpZmZlcmVudGlhdGUgcHJvY2Vz c2luZyBiZXR3ZWVuIHRoaXMgZ2VuZXJhbCBjYXNlIGFuZCB0aGUgdXBkYXRlIGNhc2UsIGJ1dCBk b2luZyBzbyB3aXRob3V0IHJlYWNoaW5nIGEgZGlmZmVyZW50IGVuZHBvaW50LCAod2hpY2ggaW4g bXkgb3BpbmlvbiB3b3VsZCBoYXZlIGJlZW4gdGhlIGNsZWFuZXIgc29sdXRpb24pIG1pZ2h0IGJl IHNsaWdodGx5IGFubm95aW5nIGZvciBpbXBsZW1lbnRlcnMsIGFzIHlvdSBhbHNvIG1lbnRpb24u DQoNCkZyYW5jZXNjYQ0KDQrvu79PbiAwNS8wNS8yMDIwLCAxNjowNywgIlNlaXR6IEx1ZHdpZyIg PGx1ZHdpZy5zZWl0ekBjb21iaXRlY2guc2U+IHdyb3RlOg0KDQogICAgSGVsbG8gRnJhbmNlc2Nh LA0KDQogICAgSSBoYXZlIG5vdCBmb2xsb3dlZCB0aGlzIGRpc2N1c3Npb24gaW4gZGV0YWlsIHNv IGV4Y3VzZSBtZSBpZiBJIG1pc3NlZCBhbiBpbXBvcnRhbnQgZGV0YWlsLiBUaGF0IHNhaWQ6IEkg Y2Fubm90IHVuZGVyc3RhbmQgd2h5IHlvdSB3b3VsZCB3YW50IHRvIG5lZ290aWF0ZSBhIG5ldyBj b250ZXh0IGluIHN0ZXAgOCBieSBzZW5kaW5nIE4xJz8gQXQgdGhhdCBwb2ludCB5b3UgaGF2ZSBh IGZ1bmN0aW9uYWwgT1NDT1JFIGNvbnRleHQgZXN0YWJsaXNoZWQgYW5kIGNvdWxkIGp1c3Qgc2Vu ZCBUMiBhc3NvY2lhdGVkIHRvIHRoZSBzYW1lIGNvbnRleHQgU2VjMS4gVGhhdCBpcyBob3cgSSBh c3N1bWVkIGl0IHdvdWxkIHdvcmssIGlmIHRoYXQgaXMgbm90IGNsZWFyIHdlIG5lZWQgdG8gYWRk IHRleHQgdG8gdGhlIHByb2ZpbGVzIHRvIGNsYXJpZnkuDQoNCiAgICBJdCBpcyBhIGJpdCBjb21w bGljYXRlZCBjb2RlLXdpc2UgdG8gaGF2ZSBhbiBlbmRwb2ludCB0aGF0IGlzIGFjY2Vzc2libGUg Ym90aCB1bnByb3RlY3RlZCBhbmQgd2l0aCBPU0NPUkUsIGJ1dCBJIHRoaW5rIGl0IGlzIGZlYXNp YmxlIChob3dldmVyIG5vdCBiZSBteSBpbiB0aGUgQUNFLUphdmEgY29kZWJhc2UsIEBNYXJjbz8p Lg0KDQogICAgL0x1ZHdpZw0KDQogICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCiAgICBG cm9tOiBGcmFuY2VzY2EgUGFsb21iaW5pIDxmcmFuY2VzY2EucGFsb21iaW5pQGVyaWNzc29uLmNv bT4gDQogICAgU2VudDogZGVuIDUgbWFqIDIwMjAgMTU6MzcNCiAgICBUbzogQWNlIFdnIDxhY2VA aWV0Zi5vcmc+OyBCZW5qYW1pbiBLYWR1ayA8a2FkdWtAbWl0LmVkdT47IEppbSBTY2hhYWQgPGll dGZAYXVndXN0Y2VsbGFycy5jb20+DQogICAgQ2M6IGRyYWZ0LWlldGYtYWNlLWR0bHMtYXV0aG9y aXplQGlldGYub3JnOyBkcmFmdC1pZXRmLWFjZS1vc2NvcmUtcHJvZmlsZUBpZXRmLm9yZw0KICAg IFN1YmplY3Q6IFVwZGF0ZSBvZiBhY2Nlc3MgcmlnaHRzDQoNCiAgICBIaSBBY2UgY2hhaXJzLCBE VExTIGF1dGhvcnMsIEFjZSBmcmFtZXdvcmsgYXV0aG9ycywgQmVuLA0KDQogICAgVEw7RFI6IHdl IHByb3Bvc2Ugc29tZSBjaGFuZ2VzIG9uIHRoZSBPU0NPUkUgcHJvZmlsZSBmb3IgdGhlICJ1cGRh dGUgb2YgYWNjZXNzIHJpZ2h0cyIgc2NlbmFyaW8uIFdlIGhhdmUgY29tbWVudHMgZm9yIHRoZSBE VExTIHByb2ZpbGUgYW5kIHRoZSBBQ0UgZnJhbWV3b3JrIHJlZ2FyZGluZyB0aGlzIHNjZW5hcmlv LCBhbmQgd2UgYXNrIGZvciBmZWVkYmFjayBmcm9tIEFDRSBPU0NPUkUgaW1wbGVtZW50ZXJzIGFu ZCBBY2UgaW4gZ2VuZXJhbC4NCg0KICAgIEluIGFuIGF0dGVtcHQgdG8gYW5zd2VyIEppbSdzICho dHRwczovL3Byb3RlY3QyLmZpcmVleWUuY29tL3YxL3VybD9rPTE3YTRmZTBmLTQ5MDQ0NDYxLTE3 YTRiZTk0LTg2YjE4ODZjZmE2NC0wMGY5YzBiMmExYThkOGNiJnE9MSZlPThhNjE5YzQzLTFhYjYt NDE0Zi1iNTc2LTY1MTE0ODgxNTNlOSZ1PWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRmFjZS13 ZyUyRmFjZS1vc2NvcmUtcHJvZmlsZSUyRmlzc3VlcyUyRjIwKSBhbmQgQmVuJ3MgKGh0dHBzOi8v cHJvdGVjdDIuZmlyZWV5ZS5jb20vdjEvdXJsP2s9MzcxYzNhM2YtNjliYzgwNTEtMzcxYzdhYTQt ODZiMTg4NmNmYTY0LTk0MTBmYzY0NWE4NjU3ODEmcT0xJmU9OGE2MTljNDMtMWFiNi00MTRmLWI1 NzYtNjUxMTQ4ODE1M2U5JnU9aHR0cHMlM0ElMkYlMkZnaXRodWIuY29tJTJGYWNlLXdnJTJGYWNl LW9zY29yZS1wcm9maWxlJTJGcHVsbCUyRjMwKSByZXZpZXcgb2YgdGhlIE9TQ09SRSBwcm9maWxl LCB3ZSBoYXZlIGJlZW4gdGhpbmtpbmcgbW9yZSBhYm91dCB0aGUgY2FzZSBvZiB1cGRhdGluZyBh Y2Nlc3MgcmlnaHRzLiBUaGlzIGhhcyByZXZlYWxlZCB0byB1cyBhdXRob3JzIHRoYXQgc29tZXRo aW5nIGlzIG1pc3NpbmcgZnJvbSB0aGUgZG9jdW1lbnQsIGFuZCBJIGJlbGlldmUgdGhhdCB0aGlz IHBhcnQgaXMgbm90IGV4cGxpY2l0bHkgY292ZXJlZCBpbiB0aGUgRFRMUyBwcm9maWxlIGVpdGhl ciwgaGVuY2UgdGhpcyBlbWFpbC4gDQoNCiAgICBUaGlzIGlzIHRoZSBzY2VuYXJpbywgYW5kIHdo YXQgaXMgY3VycmVudGx5IGRlZmluZWQgaW4gdGhlIE9TQ09SRSBwcm9maWxlOg0KDQogICAgMS4g Q2xpZW50IHJldHJpZXZlcyBhY2Nlc3MgdG9rZW4gVDEgZnJvbSBBUyAyLiBDbGllbnQgcG9zdHMg VDEgdG8gUlMsIHRvZ2V0aGVyIHdpdGggbm9uY2UgTjEgMy4gUlMgcmVwbGllcyB3aXRoIDIuMDEg YW5kIG5vbmNlIE4yIDQuIENsaWVudCBhbmQgUlMgZGVyaXZlIE9TQ09SRSBTZWMgQ3R4ICJTZWMx IiBmcm9tIFQxICgib3NjIiBvYmplY3QpLCBOMSwgTjIgNS4gQ2xpZW50IHVzZXMgU2VjMSB0byBw cm90ZWN0IGl0cyByZXF1ZXN0IHRvIFJTIDYuIFJTIHVzZXMgU2VjMSB0byB2ZXJpZnkgcmVxdWVz dC4gVmVyaWZpY2F0aW9uIHN1Y2Nlc3MgPT4gU2VjMSBpcyB2YWxpZGF0ZWQgYW5kIGFzc29jaWF0 ZWQgd2l0aCBUMSAoYXQgdGhlIFJTKQ0KICAgIC0tLS0NCiAgICA3LiBDbGllbnQgd2FudHMgdG8g dXBkYXRlIGl0cyBhY2Nlc3MgcmlnaHRzOiByZXRyaWV2ZXMgVDIgZnJvbSBBUy4gTm90ZSB0aGF0 IHRoaXMgVDIgaGFzIGRpZmZlcmVudCBhdXRob3JpemF0aW9uIGluZm8sIGJ1dCBkb2VzIG5vdCBj b250YWluIGlucHV0IGtleWluZyBtYXRlcmlhbCAoIm9zYyIpLCBvbmx5IGEgcmVmZXJlbmNlIHRv IGlkZW50aWZ5IFNlYzEgKCJraWQiIGluICJjbmYiKSA4LiBDbGllbnQgcG9zdHMgVDIgdG8gUlMs IHRvZ2V0aGVyIHdpdGggbm9uY2UgTjEnDQogICAgOS4gUlMgcmVwbGllcyB3aXRoIDIuMDEgYW5k IG5vbmNlIE4yJw0KICAgIDEwLiBDbGllbnQgYW5kIFJTIGRlcml2ZSBPU0NPUkUgU2VjIEN0eCAi U2VjMiIgZnJvbSBUMSBrZXlpbmcgaW5wdXQgbWF0ZXJpYWwgKCJvc2MiIG9iamVjdCksIE4xJywg TjInDQogICAgMTEuIENsaWVudCB1c2VzIFNlYzIgdG8gcHJvdGVjdCBpdHMgcmVxdWVzdCB0byBS UyAxMi4gUlMgdXNlcyBTZWMyIHRvIHZlcmlmeSByZXF1ZXN0LiBWZXJpZmljYXRpb24gc3VjY2Vz cyA9PiBTZWMyIGlzIHZhbGlkYXRlZCBhbmQgYXNzb2NpYXRlZCB3aXRoIFQyIChhdCB0aGUgUlMp IDsgVDEgaXMgcmVtb3ZlZCA7IFNlYzEgaXMgcmVtb3ZlZA0KDQogICAgSW4gdGhlIGRvY3VtZW50 IHJpZ2h0IG5vdywgd2UgYXJlIG1pc3NpbmcgdGhlIGV4YWN0IGRlc2NyaXB0aW9uIG9mIGhvdyBp biA4LiBSUyBpZGVudGlmaWVzIHRoYXQgdGhpcyBpcyBhbiB1cGRhdGUgb2YgYWNjZXNzIHJpZ2h0 cyBmb3IgQywgYWltaW5nIGF0IHJlcGxhY2luZyBUMS4gV2UgcHJvcG9zZSB0byBhZGQgdGV4dCBz dGF0aW5nIHRoYXQgKGluIDMuIGFuZCA5LikgUlMgTVVTVCBjaGVjayB0aGUga2lkIChpbiB0aGUg ImtpZCIgaW4gdGhlICJjbmYiIG9mIHRoZSBhY2Nlc3MgdG9rZW4pLCBhbmQgbWF0Y2ggaXQgd2l0 aCBleGlzdGluZyBzZWN1cml0eSBjb250ZXh0cywgdG8gcmVhbGl6ZSB0aGF0IHRoaXMgaXMgYW4g dXBkYXRlIGZvciBhbiBleGlzdGluZyB0b2tlbiBhc3NvY2lhdGVkIHRvIHRoZSBzZWMgY3R4IGlk ZW50aWZpZWQgYnkga2lkLg0KDQogICAgTW9yZW92ZXIsIHdoaWxlIGNvbXBhcmluZyB3aXRoIERU TFMgcHJvZmlsZSwgd2UgcmVhbGl6ZWQgdGhlcmUgaXMgbm8gcmVhc29uIGZvciB3aGljaCA4LiBz aG91bGQgYmUgc2VudCB1bnByb3RlY3RlZC4gSW4gZmFjdCwgZG9pbmcgc28gb3BlbnMgdXAgdG8g cG9zc2libGUgYXR0YWNrcyB3aGVyZSBhbiBvbGQgdXBkYXRlICh0b2tlbiBub24gZXhwaXJlZCkg aXMgcmUtaW5qZWN0ZWQgdG8gdGhlIFJTIGJ5IGFuIGFkdmVyc2FyeToNCg0KICAgICogQ2xpZW50 IHNlbmRzIFQxIHRvIFJTICAtLT4gYWNjZXB0ZWQNCiAgICAqIENsaWVudCBzZW5kcyB1cGRhdGUg b2YgYWNjZXNzIHJpZ2h0cyBUMiAtLT4gYWNjZXB0ZWQNCiAgICAqIENsaWVudCBzZW5kcyB1cGRh dGUgb2YgYWNjZXNzIHJpZ2h0cyBUMyAtLT4gYWNjZXB0ZWQNCiAgICAqIE1hbGljaW91cyBub2Rl IHJlLXNlbmRzIFQyIC0tPiBhY2NlcHRlZA0KDQogICAgT2YgY291cnNlIHRoYXQgY291bGQgYmUg bWl0aWdhdGVkIHdpdGggZXhwaXJhdGlvbiB0aW1lcyBhbmQgd2l0aCBjaGVja2luZyAiaXNzdWVk IGF0IHRpbWUiIGZpZWxkICh3aGljaCBpcyBvcHRpb25hbCkuIEJ1dCB3ZSBiZWxpZXZlIGV2ZW4g dGhvdWdoIHRoZXNlIGFyZSBnb29kIHBvaW50cyAod2hpY2ggbWlnaHQgYWN0dWFsbHkgYmUgd29y dGggYWRkaW5nIHRvIHRoZSBmcmFtZXdvcmspLCBzZW5kaW5nIHRoZSB0b2tlbiB0byB0aGUgUlMg b3ZlciB0aGUgZXhpc3RpbmcgcHJvdGVjdGVkIGNoYW5uZWwgc29sdmVzIHRoaXMgaXNzdWUuIFNv IHdlIHByb3Bvc2UgdGhhdCA4LiBpcyBwcm90ZWN0ZWQgd2l0aCBPU0NPUkUgYW5kIFNlYyBDdHgg U2VjMS4gRm9yIERUTFMgYXV0aG9yczogSSBiZWxpZXZlIEppbSBoYXMgZXh0cmFwb2xhdGVkIGZy b20geW91ciBkb2N1bWVudCB0aGF0IHRoYXQgaXMgdGhlIGNhc2UgZm9yIHRoZSBEVExTIHByb2Zp bGUgYWxyZWFkeSwgaS5lLiBQT1NUIHRva2VuIHRvIFJTIGZvciB1cGRhdGUgb2YgYWNjZXNzIHJp Z2h0cyBpcyBvdmVyIERUTFM7IEkgdGhpbmsgaXQgd291bGQgYmUgd29ydGggZXhwbGljaXRseSBz dGF0aW5nIHRoYXQgaW4gdGhlIERUTFMgcHJvZmlsZS4NCg0KICAgIEFkZGl0aW9uYWxseSwgYW5h bG9nb3VzbHkgdG8gRFRMUyB3aGVyZSB0aGUgc2FtZSBjaGFubmVsIGlzIGtlcHQgZXZlbiBpZiBh Y2Nlc3MgcmlnaHRzIGFyZSB1cGRhdGVkLCBJIGRvIG5vdCBzZWUgYW55IHJlYXNvbiBhdCB0aGlz IHBvaW50IHRvIGhhdmUgdGhlIGVuZHBvaW50cyByZS1kZXJpdmUgYSBuZXcgc2VjdXJpdHkgY29u dGV4dC4gVGhpcyBpcyB0aGUgYmlnZ2VzdCBjaGFuZ2UgSSBwcm9wb3NlLCBhbmQgY2FuIGJlIHN1 bW1hcml6ZWQgYnkgcmVwbGFjaW5nIHRoZSBwb2ludHMgYWJvdmUgYXMgZm9sbG93czoNCg0KICAg IDcuIENsaWVudCB3YW50cyB0byB1cGRhdGUgaXRzIGFjY2VzcyByaWdodHM6IHJldHJpZXZlcyBU MiBmcm9tIEFTLiBOb3RlIHRoYXQgdGhpcyBUMiBoYXMgZGlmZmVyZW50IGF1dGhvcml6YXRpb24g aW5mbywgYnV0IGRvZXMgbm90IGNvbnRhaW4gaW5wdXQga2V5aW5nIG1hdGVyaWFsLCBvbmx5IGEg cmVmZXJlbmNlIHRvIGlkZW50aWZ5IFNlYzEgOC4gQ2xpZW50IHBvc3RzIFQyIHRvIFJTLCAqd2l0 aG91dCBub25jZSogKnByb3RlY3RlZCB3aXRoIFNlYzEqIDkuIFJTICp2ZXJpZmllcyB0aGF0IHRo aXMgaXMgYW4gdXBkYXRlIG9mIGFjY2VzcyByaWdodCwgcmVwbGFjaW5nIFQxIChhc3NvY2lhdGVk IHdpdGggU2VjMSkgOyBTZWMxIGlzIGFzc29jaWF0ZWQgd2l0aCBUMjsgVDEgaXMgcmVtb3ZlZCAq OyBSUyByZXBsaWVzIHdpdGggMi4wMSAqd2l0aG91dCBub25jZSogKnByb3RlY3RlZCB3aXRoIFNl YzEqIDEwLiBDbGllbnQgdXNlcyAqU2VjMSogdG8gcHJvdGVjdCBpdHMgcmVxdWVzdCB0byBSUw0K DQogICAgSSBjYW4gYWxyZWFkeSBzZWUgdGhlIG9iamVjdGlvbiBmcm9tIGltcGxlbWVudGVyczog dGhlIGF1dGh6LWluZm8gZW5kcG9pbnQgYXQgdGhlIFJTIGJlY29tZXMgYWNjZXNzaWJsZSBib3Ro IHVucHJvdGVjdGVkIChpbiBjYXNlIHRoZSBDbGllbnQgaXMgcG9zdGluZyBhIHRva2VuIGZvciB0 aGUgZmlyc3QgdGltZSwgcG9pbnRzIDEuIHRvIDYuKSBhbmQgcHJvdGVjdGVkIChpbiBjYXNlIENs aWVudCBuZWVkcyB0byB1cGRhdGUgcmlnaHRzLCBwb2ludHMgNy4gdG8gMTAuKSBJIGJlbGlldmUg dGhhdCBkZWZpbmluZyBhIE5FVyBlbmRwb2ludCBhdCB0aGUgUlMgZm9yIHRoZSAidXBkYXRlIHJp Z2h0cyIgbWVjaGFuaXNtIHdvdWxkIGJlIHRoZSBiZXN0IHNvbHV0aW9uLCBidXQgSSB1bmRlcnN0 YW5kIHRoYXQgd291bGQgcmVxdWlyZSBtb2RpZmljYXRpb25zIHRvIHRoZSBmcmFtZXdvcmsgdGhh dCBMdWR3aWcgcHJvYmFibHkgd291bGQgbm90IHdhbnQgdG8gZG8sIGFzIGl0IG1pZ2h0IGRlbGF5 IHRoZSBkb2N1bWVudC4gSSB0aGluayB0aGVzZSB3b3VsZCBpbiBwcmFjdGljZSBiZSAyIGRpZmZl cmVudCBlbmRwb2ludHMgd2l0aCB0aGUgc2FtZSBVUkksIG9uZSBPU0NPUkUgcHJvdGVjdGVkIGFu ZCBvbmUgdW5wcm90ZWN0ZWQuIEJ1dCBJIG5lZWQgbW9yZSBpbnB1dCBmcm9tIG91ciBpbXBsZW1l bnRlcnMgdG8ga25vdyBpZiB0aGlzIGFic29sdXRlbHkgY2Fubm90IGJlIGRvbmUuDQoNCiAgICBP dXIgcHJvcG9zYWw6DQogICAgQW4gUlMgcmVjZWl2aW5nIGEgdG9rZW4gKHBvaW50IDIgYW5kIDgp IE1VU1QgY2hlY2sgdGhlIGtpZCBvZiB0aGUgdG9rZW4gYWdhaW5zdCBleGlzdGluZyBzZWN1cml0 eSBjb250ZXh0cy4gSWYgYSBtYXRjaCBpcyBmb3VuZCwgYnV0IHRoZSBQT1NUIHdhcyB1bnByb3Rl Y3RlZCwgcmVqZWN0LiBJZiBhIG1hdGNoIGlzIGZvdW5kIEFORCB0aGUgUE9TVCB3YXMgcHJvdGVj dGVkIHVzaW5nIHRoYXQgc2FtZSBTZWMgQ3R4IGlkZW50aWZpZWQgYnkga2lkLCB1cGRhdGUgYWNj ZXNzIHJpZ2h0cy4gSWYgYSBtYXRjaCBpcyBub3QgZm91bmQsIGRlcml2ZSBzZWMgY3R4IGFzIGRl ZmluZWQgYmVmb3JlLiBUaGVzZSAyIGVuZHBvaW50cyBhbHNvIHJlcXVpcmUgZGlmZmVyZW50IHBh eWxvYWQ6IHBvc3RpbmcgdGhlIHRva2VuIGZvciB0aGUgZmlyc3QgdGltZSB1bnByb3RlY3RlZCBy ZXF1aXJlcyBhIG5vbmNlLCBwb3N0aW5nIGFuIHVwZGF0ZSB1c2luZyBPU0NPUkUgZG9lcyBub3Qg KGFuZCB0aGUgbm9uY2Ugd2lsbCBiZSBkaXNjYXJkZWQgaWYgc2VudCkuIA0KDQogICAgRG9pbmcg c28gYW5zd2VycyBCZW4ncyBwb2ludCBhYm91dCAyIHRva2VucyBiZWluZyBzYXZlZCBhdCB0aGUg UlMgYXQgdGhlIHNhbWUgdGltZSwgd2hpbGUgU2VjMiBpcyBub3QgeWV0IHZhbGlkYXRlZCAoYmV0 d2VlbiA4LiBhbmQgMTIuIGFib3ZlKSwgc2luY2UgaXQgcmVtb3ZlcyBTZWMyIGFsdG9nZXRoZXIu IEFzIHNvb24gYXMgVDIgaXMgdmVyaWZpZWQsIFQxIGNhbiBiZSByZXBsYWNlZCB3aXRoIFQyLg0K DQogICAgRmluYWwgcG9pbnQ6IHdoYXQgaGFwcGVucyBpZiB0aGUgQ2xpZW50IHBvc3RzIGEgc2Vj b25kIHRva2VuIFQyICh0byB1bnByb3RlY3RlZCBhdXRoei1pbmZvKSB3aGljaCBjb250YWlucyBh IGRpZmZlcmVudCAib3NjIiBvYmplY3QsIGRpZmZlcmVudCBraWQgZXRjLiBUaGUgUlMgd2lsbCBu b3QgYmUgYWJsZSB0byBpZGVudGlmeSB0aGlzIENsaWVudCBhcyBzb21lb25lIGl0IGFscmVhZHkg aGFzIGEgc2VjIGFzc29jaWF0aW9uIHdpdGgsIGFuZCBpdCB3aWxsIHNldCB1cCBhIGRpZmZlcmVu dCBTZWMgQ3R4IHdpdGggaXQuIEkgdGhpbmsgdGhpcyBpcyBPSywgYXMgZm9yIGl0IHRvIGJlIGFj Y2VwdGVkLCB0aGUgQVMgaGFkIHRvIHByb3ZpZGUgc3VjaCBhIHRva2VuLiBUaGUgZnJhbWV3b3Jr IFJFQ09NTUVORFMgdGhhdCBhbiBSUyBzdG9yZXMgb25seSBvbmUgdG9rZW4gcGVyIHByb29mLW9m LXBvc3Nlc3Npb24ga2V5LCB3aGljaCB3b3VsZCBzdGlsbCBiZSB2YWxpZCwgYXMgZGlmZmVyZW50 IHRva2VucyB3b3VsZCBiZSBhc3NvY2lhdGVkIHRvIGRpZmZlcmVudCBTZWMgY3R4cy4NCg0KICAg IEFueSBmZWVkYmFjayBvciBjb21tZW50IGlzIGFwcHJlY2lhdGVkLiANCg0KICAgIFRoYW5rcywN CiAgICBGcmFuY2VzY2ENCg0KDQoNCg0K From nobody Tue May 5 08:39:26 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 332CA3A0878 for ; Tue, 5 May 2020 08:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 EkVML-g1mgks for ; Tue, 5 May 2020 08:39:22 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D4963A085E for ; Tue, 5 May 2020 08:39:22 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 5 May 2020 08:39:16 -0700 From: Jim Schaad To: 'Carsten Bormann' CC: 'Benjamin Kaduk' , 'Olaf Bergmann' , 'Peter van der Stok' , 'peter van der Stok' , 'Ace' References: <56d31e581571721e176b59db20e08c23@bbhmail.nl> <00f101d61f03$a26bb920$e7432b60$@augustcellars.com> <0873a3115cab89036002cf42b1c97608@bbhmail.nl> <87mu6o6u8t.fsf@wangari> <20200505040917.GM27494@kduck.mit.edu> <02f001d62299$56718830$03549890$@augustcellars.com> In-Reply-To: Date: Tue, 5 May 2020 08:39:13 -0700 Message-ID: <034001d622f3$5606eca0$0214c5e0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJvvEQrX2wOjMB2/s9A8vau6YKJYgFtua5lAwDjVtQCw58eHwIqARfCAhrUIdYCSb3ZUqb4ZlYA Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 05 May 2020 15:39:25 -0000 I don't see how the four-corner model solves the issue that I = highlighted. If the client does not have a key for any local AS, then = nothing helps. The four-corner model deals with the issue of the client = and the RS not trusting the same AS, but the different AS entities trust = each other on the back side. Getting trust in a local AS seems to be a bootstrapping problem. Jim -----Original Message----- From: Carsten Bormann =20 Sent: Monday, May 4, 2020 10:38 PM To: Jim Schaad Cc: Benjamin Kaduk ; Olaf Bergmann ; = Peter van der Stok ; peter van der Stok = ; Ace Subject: Re: [Ace] draft-ietf-ace-oauth-authz On 2020-05-05, at 06:54, Jim Schaad wrote: >=20 > I have much the same problem. While a client could find an AS which=20 > would authenticate the client, I don't know how the client would=20 > establish any degree of trust in the AS which is going to give it = tokens. Hence the four-corner model [1]. Gr=C3=BC=C3=9Fe, Carsten [1]: https://tools.ietf.org/html/draft-ietf-ace-actors From nobody Tue May 5 08:44:11 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD72F3A0944 for ; Tue, 5 May 2020 08:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 FwryC-fcOddW for ; Tue, 5 May 2020 08:44:03 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 795073A0868 for ; Tue, 5 May 2020 08:44:02 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 5 May 2020 08:43:56 -0700 From: Jim Schaad To: , 'Benjamin Kaduk' CC: 'Olaf Bergmann' , 'Ace' References: <56d31e581571721e176b59db20e08c23@bbhmail.nl> <00f101d61f03$a26bb920$e7432b60$@augustcellars.com> <0873a3115cab89036002cf42b1c97608@bbhmail.nl> <87mu6o6u8t.fsf@wangari> <20200505040917.GM27494@kduck.mit.edu> <90932754f76d8978bdb8a30c794e5343@bbhmail.nl> In-Reply-To: <90932754f76d8978bdb8a30c794e5343@bbhmail.nl> Date: Tue, 5 May 2020 08:43:53 -0700 Message-ID: <034101d622f3$fd0c5710$f7250530$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0342_01D622B9.50AE4260" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJvvEQrX2wOjMB2/s9A8vau6YKJYgFtua5lAwDjVtQCw58eHwIqARfCAbwk2VWnDawBIA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 05 May 2020 15:44:10 -0000 ------=_NextPart_000_0342_01D622B9.50AE4260 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thanks Peter, that makes things a lot clearer. However I think that you = are not asking for who is an AS, but who is an AS that has a particular = interface. It would make more sense to define a new interface = identifier for the upload/control protocol rather than just identifying = who is an AS. =20 Jim =20 =20 From: Ace On Behalf Of Peter van der Stok Sent: Tuesday, May 5, 2020 12:26 AM To: Benjamin Kaduk Cc: Jim Schaad ; Olaf Bergmann = ; 'Ace' Subject: Re: [Ace] draft-ietf-ace-oauth-authz =20 HI all, I agree about the authorization/trust problem. My request concerns something more trivial. Suppose we have this new network with a set of servers, an (AS) (may be = more) and a controller. The servers, controller and AS may have used BRSKI to enter the network. The servers will only provide their service when a token has been sent. The AS is completely empty, not aware of the servers or its clients. The controller wants to fill the AS with the necessary information. Both controller and AS have agreed on an initialization protocol, and = are equipped with the necessary secrets. (A protocol to be standardized = in general, but not my concen here) Now, what IP address does the controller use to start the communication? Typing in the IP address is a possibility, switching off all other = devices is another, etc... I hoped that a coap discovery could be used such that the controller = learns the IP address of the AS. When several AS servers are present, the controller can access each one = of them out till it accesses the AS with the correct credentials. I hope my request has become a bit clearer. Peter Benjamin Kaduk schreef op 2020-05-05 06:09: On Mon, May 04, 2020 at 09:21:06AM +0200, Olaf Bergmann wrote:=20 Hi Peter, Peter van der Stok > = writes: When I want to access an OCF device I can find its IP address through service discovery (rfc7252 section 7) using an rt-value registered at the IANA core parameters registry. For example, when I want to initialize the AS I have to type in the IP address of the AS. From that moment on keys and certificates can be compared to continue initialization. Using service discovery can automate that process. My request is that authz draft registers an rt-value in core parameters registry for service discovery of the AS, unless a different process has already been established for AS initialization. That is exaclty what originally has been done in section 9 of draft-gerdes-ace-dcaf-authorize [1]. Somehow, this got lost in the process. I think I'm still a little confused as to what good being able to "discover" that the network says something is an AS is, without some = prior trust and/or key material for that AS. How would the necessary trust be established as part of such a discovery scheme? Thanks, Ben ------=_NextPart_000_0342_01D622B9.50AE4260 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Thanks = Peter, that makes things a lot clearer.=C2=A0 However I think that you = are not asking for who is an AS, but who is an AS that has a particular = interface.=C2=A0 It would make more sense to define a new interface = identifier for the upload/control protocol rather than just identifying = who is an AS.

 

Jim

 

 

From: Ace = <ace-bounces@ietf.org> On Behalf Of Peter van der = Stok
Sent: Tuesday, May 5, 2020 12:26 AM
To: = Benjamin Kaduk <kaduk@mit.edu>
Cc: Jim Schaad = <ietf@augustcellars.com>; Olaf Bergmann <bergmann@tzi.org>; = 'Ace' <ace@ietf.org>
Subject: Re: [Ace] = draft-ietf-ace-oauth-authz

 

HI = all,

I agree about the authorization/trust problem.
My request = concerns something more trivial.

Suppose we have this new network = with a set of servers, an (AS) (may be more) and a controller.
The = servers, controller and AS may have used BRSKI to enter the = network.
The servers will only provide their service when a token has = been sent.
The AS is completely empty, not aware of the servers or = its clients.
The controller wants to fill the AS with the necessary = information.

Both controller and AS have agreed on an = initialization protocol, and are equipped with the necessary secrets. (A = protocol to be standardized in general, but not my concen = here)

Now, what IP address does the controller use to start the = communication?

Typing in the IP address is a possibility, = switching off all other devices is another, etc...
I hoped that a = coap discovery could be used such that the controller learns the IP = address of the AS.

When several AS servers are present, the = controller can access each one of them out till it accesses the AS with = the correct credentials.

I hope my request has become a bit = clearer.

Peter

Benjamin = Kaduk schreef op 2020-05-05 06:09:

On Mon, May 04, = 2020 at 09:21:06AM +0200, Olaf Bergmann wrote: =

Hi = Peter,

Peter van der Stok <stokcons@bbhmail.nl> = writes:


When I want to = access an OCF device I can find its IP address through
service = discovery (rfc7252 section 7) using an rt-value registered at
the = IANA core parameters registry.  For example, when I want = to
initialize the AS I have to type in the IP address of the AS. =  From
that moment on keys and certificates can be compared to = continue
initialization.

Using service discovery can automate = that process.

My request is that authz draft registers an = rt-value in core
parameters registry for service discovery of the AS, = unless a
different process has already been established for AS = initialization.


That is exaclty what originally has been done in section 9 = of
draft-gerdes-ace-dcaf-authorize [1]. Somehow, this got lost in = the
process.


I think I'm still a little confused as to what good being able = to
"discover" that the network says something is an AS is, = without some prior
trust and/or key material for that AS.  How = would the necessary trust be
established as part of such a discovery = scheme?

Thanks,

Ben

------=_NextPart_000_0342_01D622B9.50AE4260-- From nobody Tue May 5 09:01:07 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7A2A3A0854 for ; Tue, 5 May 2020 09:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 rgh_PkE3j2ts for ; Tue, 5 May 2020 09:01:04 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E8CF3A085E for ; Tue, 5 May 2020 09:01:03 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7206D3818F; Tue, 5 May 2020 11:59:04 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C2C9D4660; Tue, 5 May 2020 12:01:02 -0400 (EDT) From: Michael Richardson To: Francesca Palombini , Ace Wg In-Reply-To: <8063D003-2C48-4157-B80E-B7AF3D2099FC@ericsson.com> References: <8063D003-2C48-4157-B80E-B7AF3D2099FC@ericsson.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Ace] Update of access rights X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 05 May 2020 16:01:06 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Francesca Palombini w= rote: > 7. Client wants to update its access rights: retrieves T2 from AS. No= te > that this T2 has different authorization info, but does not contain > input keying material ("osc"), only a reference to identify Sec1 ("ki= d" Is there an assumption that the access rights(T2) >=3D access rights(T1)? > Moreover, while comparing with DTLS profile, we realized there is no > reason for which 8. should be sent unprotected. In fact, doing so ope= ns > up to possible attacks where an old update (token non expired) is > re-injected to the RS by an adversary: I agree and I see your point. Thank you for explaining it so well. My question is whether step 8 results in Sec Ctx sec1 being deleted? Could Client want to keep it alive in the case that T1 and T2 actually do different things? =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl6xjb4ACgkQgItw+93Q 3WX4GQf/e+5LFl9bR7zRe0d0G3PhuPNGOQiEZgdSHuDl2z6SrG2+2Rv4CVRGNSI4 jEjR4GAgXFwmFnySKTWlReJDQmQMJhkd3aP4GLWrzf9FPL+3GZibAUg4QDMse9Pf EZonIQJq1RO14NHzABcU3M7bCJH+UbzgZn92KF4COLe3BJURV5r925FVftrxBsQN zjCBkU/BQfYHYGo+M2WLwWoX/hQ/smEY6OP0ii+UvJHTI1cO2k0q0f+llFf1i2/H HbzHI+QQstXXdXnan3YoCZwzIvxINOcdKVAJJkHq2X2cZfVvx0VZAL6n5e4X9QD1 c2seQFIaxcD9pYeNehlc0loZzIROxw== =kH3G -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue May 5 10:11:30 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C97B03A0A05 for ; Tue, 5 May 2020 10:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bbhmail.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bjy4y3QJqBDe for ; Tue, 5 May 2020 10:11:24 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0206.hostedemail.com [216.40.44.206]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A42383A09FD for ; Tue, 5 May 2020 10:11:24 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay04.hostedemail.com (Postfix) with ESMTP id 5FA00180A6310; Tue, 5 May 2020 17:11:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h= mime-version:content-type:date:from:to:cc:subject:reply-to :in-reply-to:references:message-id; s=key; bh=kx7YskG/oKLlktIsxR d3Gh3Y50ZV3QDf0ZgI3G3PtsU=; b=aXb8h2kZ8YuqJTBnL/tcj34lRgyydeANwW jjmPe7ls7FOhAYYJI3RxjGOU4+9F8rX8kzALjHmwqaft9gSlB9/VCa/IUZXLco0n BT+kvbiu+qYfdek+tKBJpA+TqnMEYs+YIM7qjK7ROLxcL8KhcYadPQMxgjOX5jPT Wp7Xqnn8E= X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, , RULES_HIT:1:2:41:72:152:355:379:582:599:800:960:962:967:973:983:988:989:1152:1189:1208:1221:1260:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1575:1588:1589:1592:1594:1605:1730:1775:1792:2198:2199:2526:2527:2551:2553:2557:2559:2562:2693:2892:2898:2900:2901:2902:2917:2924:2926:3138:3139:3140:3141:3142:3586:3622:3769:3865:3866:3867:3868:3870:3871:3872:3873:3874:4049:4250:4321:4362:4379:5007:6248:6261:6298:6657:6659:6678:7576:7903:8583:8603:8957:9036:9080:9177:9545:10004:10026:10848:11232:11656:11657:11658:11914:12043:12050:12109:12114:12663:12740:12895:13139:13436:13972:14196:21060:21063:21080:21324:21433:21451:21499:21625:21740:21809:21939:21990:30003:30054:30070:30075:30090:30091, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:0, DNSBL:none, Custom_rules:0:0:0, LFtime:2, LUA_SUMMARY:none X-HE-Tag: month81_635e4ef940648 X-Filterd-Recvd-Size: 11581 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf09.hostedemail.com (Postfix) with ESMTPA; Tue, 5 May 2020 17:11:22 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_89c3a29a31e7b48d47b310a8036e5c15" Date: Tue, 05 May 2020 19:11:22 +0200 From: Peter van der Stok To: Jim Schaad Cc: consultancy@vanderstok.org, 'Benjamin Kaduk' , 'Olaf Bergmann' , 'Ace' Reply-To: consultancy@vanderstok.org In-Reply-To: <034101d622f3$fd0c5710$f7250530$@augustcellars.com> References: <56d31e581571721e176b59db20e08c23@bbhmail.nl> <00f101d61f03$a26bb920$e7432b60$@augustcellars.com> <0873a3115cab89036002cf42b1c97608@bbhmail.nl> <87mu6o6u8t.fsf@wangari> <20200505040917.GM27494@kduck.mit.edu> <90932754f76d8978bdb8a30c794e5343@bbhmail.nl> <034101d622f3$fd0c5710$f7250530$@augustcellars.com> User-Agent: Roundcube Webmail/1.4-rc2 Message-ID: X-Sender: stokcons@bbhmail.nl Organization: vanderstok consultancy X-Originating-IP: [5.206.216.229] Archived-At: Subject: Re: [Ace] draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 05 May 2020 17:11:27 -0000 --=_89c3a29a31e7b48d47b310a8036e5c15 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8; format=flowed HI Jim, Agree. That's a new draft then with an rt value for a given upload protocol. Peter Jim Schaad schreef op 2020-05-05 17:43: >> > Thanks Peter, that makes things a lot clearer. However I think that you are not asking for who is an AS, but who is an AS that has a particular interface. It would make more sense to define a new interface identifier for the upload/control protocol rather than just identifying who is an AS. > > Jim > > From: Ace On Behalf Of Peter van der Stok > Sent: Tuesday, May 5, 2020 12:26 AM > To: Benjamin Kaduk > Cc: Jim Schaad ; Olaf Bergmann ; 'Ace' > Subject: Re: [Ace] draft-ietf-ace-oauth-authz > > HI all, > > I agree about the authorization/trust problem. > My request concerns something more trivial. > > Suppose we have this new network with a set of servers, an (AS) (may be more) and a controller. > The servers, controller and AS may have used BRSKI to enter the network. > The servers will only provide their service when a token has been sent. > The AS is completely empty, not aware of the servers or its clients. > The controller wants to fill the AS with the necessary information. > > Both controller and AS have agreed on an initialization protocol, and are equipped with the necessary secrets. (A protocol to be standardized in general, but not my concen here) > > Now, what IP address does the controller use to start the communication? > > Typing in the IP address is a possibility, switching off all other devices is another, etc... > I hoped that a coap discovery could be used such that the controller learns the IP address of the AS. > > When several AS servers are present, the controller can access each one of them out till it accesses the AS with the correct credentials. > > I hope my request has become a bit clearer. > > Peter > > Benjamin Kaduk schreef op 2020-05-05 06:09: > > On Mon, May 04, 2020 at 09:21:06AM +0200, Olaf Bergmann wrote: > > Hi Peter, > > Peter van der Stok writes: > > When I want to access an OCF device I can find its IP address through > service discovery (rfc7252 section 7) using an rt-value registered at > the IANA core parameters registry. For example, when I want to > initialize the AS I have to type in the IP address of the AS. From > that moment on keys and certificates can be compared to continue > initialization. > > Using service discovery can automate that process. > > My request is that authz draft registers an rt-value in core > parameters registry for service discovery of the AS, unless a > different process has already been established for AS initialization. > > That is exaclty what originally has been done in section 9 of > draft-gerdes-ace-dcaf-authorize [1]. Somehow, this got lost in the > process. I think I'm still a little confused as to what good being able to "discover" that the network says something is an AS is, without some prior trust and/or key material for that AS. How would the necessary trust be established as part of such a discovery scheme? Thanks, Ben --=_89c3a29a31e7b48d47b310a8036e5c15 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 HI Jim,

Agree.
That's a new draft then with an rt value for= a given upload protocol.


Peter

Jim Schaad schreef op 2020-05-05 17:43:

 

Thanks Peter, that makes things a lot clearer.&nbs= p; However I think that you are not asking for who is an AS, but who is an = AS that has a particular interface.  It would make more sense to defin= e a new interface identifier for the upload/control protocol rather than ju= st identifying who is an AS.

 

Jim

 

 

From: Ace <ace-bounces@ietf.or= g> On Behalf Of Peter van der Stok
Sent: Tuesday, May 5, 2020 12:26 AM
To: Benjamin Ka= duk <kaduk@mit.edu>
Cc: Jim Schaad <ietf@aug= ustcellars.com>; Olaf Bergmann <bergmann@tzi.org>; 'Ace' <ace@i= etf.org>
Subject: Re: [Ace] draft-ietf-ace-oauth-a= uthz

 

HI all,

I agree about the authorization/trus= t problem.
My request concerns something more trivial.

Supp= ose we have this new network with a set of servers, an (AS) (may be more) a= nd a controller.
The servers, controller and AS may have used BRSKI to= enter the network.
The servers will only provide their service when a= token has been sent.
The AS is completely empty, not aware of the ser= vers or its clients.
The controller wants to fill the AS with the nece= ssary information.

Both controller and AS have agreed on an init= ialization protocol, and are equipped with the necessary secrets. (A protoc= ol to be standardized in general, but not my concen here)

Now, w= hat IP address does the controller use to start the communication?
Typing in the IP address is a possibility, switching off all other devic= es is another, etc...
I hoped that a coap discovery could be used such= that the controller learns the IP address of the AS.

When sever= al AS servers are present, the controller can access each one of them out t= ill it accesses the AS with the correct credentials.

I hope my r= equest has become a bit clearer.

Peter

Be= njamin Kaduk schreef op 2020-05-05 06:09:

On Mon, May 04, 2020 at 09:21:06AM +0200, Olaf Bergmann wrote:=

Hi Peter,

Peter van der Stok <stokcons@bbhmail.nl> writes:=


When I want to access an OCF device I can find its IP address = through
service discovery (rfc7252 section 7) using an rt-value regist= ered at
the IANA core parameters registry.  For example, when I w= ant to
initialize the AS I have to type in the IP address of the AS. &= nbsp;From
that moment on keys and certificates can be compared to cont= inue
initialization.

Using service discovery can automate t= hat process.

My request is that authz draft registers an rt-valu= e in core
parameters registry for service discovery of the AS, unless = a
different process has already been established for AS initialization= =2E


That is exaclty what originally has been done in section= 9 of
draft-gerdes-ace-dcaf-authorize [1]. Somehow, this got lost in t= he
process.


I think I'm still a little confused as to what good bein= g able to
"discover" that the network says something is an AS is, with= out some prior
trust and/or key material for that AS.  How would = the necessary trust be
established as part of such a discovery scheme?=

Thanks,

Ben

--=_89c3a29a31e7b48d47b310a8036e5c15-- From nobody Tue May 5 10:35:56 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F33A33A0AD7 for ; Tue, 5 May 2020 10:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YHchNsdwUdK for ; Tue, 5 May 2020 10:35:54 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30045.outbound.protection.outlook.com [40.107.3.45]) (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 0D8393A0AD5 for ; Tue, 5 May 2020 10:35:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A8jk4WcIN15tZ35V/rsmppjD5P0G+YFd5If4cVAr4rRQEd2n5dfJ4gs2iJkG5UF04hYEVJk7I4zLthpEoqc/S/w4ssLJy3WsAMTNmz4NqOb0Lf7GWXfMSeZUGGMSzpXZBsAjI3lwVhKnXU4WjkCcQYpvRk6FILtE1Ap1KQuBBJif+H3IrJKpdbrLAV9sVkBxCjbI0Ex/QBuOX/GJtiAuhE/e2l0VY+ii2pq9naYCLxuX+FjUtfwIVZ33OwJ9fPzAIKcoT9du9p3SNqwQaAJGJ/GFxPr8XJ57Wuf91wr51neAupX55WWS58XfWG3sn6XYFEK798cjUVfJRh5Xz+Lqog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nS/rTWHKnkFwdYi5rBKbfQg2hncDk7sH1tvC5swNZFU=; b=grRxCKW7ho1KrvtV+2Yo57VJZmOa8xG1MR9740Qa1X2BVG3XT54eoirgc577Y8iY31quR6oCC/edNu7kQ2JN39i2o4CIZrzJqOYCz91yZ0iJhFCViW0XkwzZVQnZ6rNlCq/30YNseCyR1RzCLj8EjDCvImBoV8+BGuFhDsMCK+jkBeVl+vXXKfu7fz87HEwpNmW6lEp/Z1mdZu5NU84spZMHlPAyJFBrOwdc+zBnUlBZYQaQz21SCqswNBDbWrbLTzbbK7aLRO5ODAwc612rpwohYKSyguJNFqWzvxlCy/+PZWlTv6oVUhhfhN7VpZO5A7tKBi4imbIfUGraLvTltQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nS/rTWHKnkFwdYi5rBKbfQg2hncDk7sH1tvC5swNZFU=; b=Cn2HgnVnnA99I73ZflFoalNlIu898HW9ovowwx219L54qczK7vekF1ghzWlGAtsFljz69+URsRGb9V/09Rm1ANi0F4rKERccxFuZMVunvyyKVtgy2ZYcMoXFzkWqKILyqcsjyfAAh8AZpZKCLp9qkrX8zsF3Gu3F/T3hCs+SL2U= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) by HE1PR0702MB3740.eurprd07.prod.outlook.com (2603:10a6:7:81::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.24; Tue, 5 May 2020 17:35:51 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::f0bb:b1ae:bf22:4526]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::f0bb:b1ae:bf22:4526%6]) with mapi id 15.20.2979.025; Tue, 5 May 2020 17:35:51 +0000 From: Francesca Palombini To: Michael Richardson , Ace Wg Thread-Topic: [Ace] Update of access rights Thread-Index: AQHWIuI1Lkw8gf+fQkGotEAa9X56JaiZpvsAgAA8BAA= Date: Tue, 5 May 2020 17:35:51 +0000 Message-ID: References: <8063D003-2C48-4157-B80E-B7AF3D2099FC@ericsson.com> <20680.1588694462@localhost> In-Reply-To: <20680.1588694462@localhost> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6d371730-9404-4cdd-af23-08d7f11ac1b6 x-ms-traffictypediagnostic: HE1PR0702MB3740: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0394259C80 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: uUy/HRMmgpfBRdnVgXC51OtpfJARVg8/dViVs/EgvNKKgYRFgXBBBZ353cuAl7y74aLtewW40CQFsN6zgyERtAGb0vxIxHiPTFBOWjJLkN/PWVu1Ua+OmXnGPhm2AGGf7iFrZuEopkK+H0xG/kMxmsUW5nTwg7nrl8AsAaoddjrrtbx9F7pk/Ayfplc323YOXos8LNqsChnl4Sep+0ng7ea0Fshvqq2jyXvzE3GUW2sNv1KBAfh7Cuhz+YNTK5a23Wdvwgv/ifnE55YfEUvfyPv0kQ5HgSjPgpixTNVBxBBMtRP70NNuv6MTcuFqtQ5oASaVRv8wJ6fjlW+Pm0B4mlW5GEhO/RhiNlwO6pYm0uhFAGMoqzF9ZRmVFwd+emuE/UCjBC5s+Ri3NQTLRF4T3roN4MHxCHH4sOO0xeJ1FBU8sY+X2fex/I784G6suuv95KEs9UwbtHyjrzKGhiO7Oaa1+Ua1CuDAev8XTgKd2LM0c1OGr2GQyMBej0SHcrLnDJlA1rgZPjYmSM2wqoFpQw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3818.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(33430700001)(26005)(86362001)(44832011)(36756003)(6506007)(498600001)(15650500001)(2616005)(33656002)(110136005)(8936002)(76116006)(2906002)(66946007)(71200400001)(8676002)(66446008)(6512007)(5660300002)(33440700001)(186003)(64756008)(66476007)(6486002)(66556008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: qBmcjpr9g56F9I0f0XUIt01RpGRgjtU1KhMEFH4ECvCG8JlqW27mnuqkEl6nWkZPqu5ZCClBeX80FLAAkC8RY+vpxSZ9kAuRO40gjdIvv4N/wnbRFctMugBkOcV2kgHO9Q44JdmS5AeY1QT4ug9CMrcqSKlWrobkFoUMppbF1rQfC/k7qaEPPvYzTr2Q+O4j8sXwuYXkguUARKkTUYmKANL//djNNXhkC40VE/8YX3yPRA9QQi3LS6UhMVYapyzsY/7T8Fjzx6bdYR/RtQIF6X+LkzE3sJo9/cJZkDYGQ3xXrY2skjmgYzD4WlnkOQq6xDl7Mq9rTACC0pQ+UDhlrSMfhlZVB2N8O+0Cv3VieKUmgvHBWiwdmyz8d9W8Rt6xf8fU1cVPrGMuR8kMN+vr65wvNNLW46YUiSm2kfvW5fnkZEvrsxopywB/haPDeL99id4lAjc0JCDCsExMeboVuapoVGf39EfBgpNSLqGxKKqb3/sjfdXNN0AKTE/62tfJhImOtLKtuclCCMO3lyru887k1Ak/v9voDo96rdhxD4xfWABUM64u7CU6Mdc8tT/a57FVwddnBKwWB6Tx6/qmYSgbCBck61w5qEtq0cSxmSLrUz6Q7twWPo6jTa9tSZhO/Z1bWhGRBuXFk1LWZWIOqE/Z00r7Yg0dUHn4RzUe/TOZJAXaVn1eaxO8Ps5zkrJlC70jCgQcULMNdnTkmy4PAWLr3ybDLaPAXlmuyvqO+PCEodOCK2JoD14OgL8c5Nt0+RVdvpmALDUfR5yYEp+k8RcMJfIrCv6yT/eXhB4L21FprnxIs/mgJUCiVGJN+VM0 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6d371730-9404-4cdd-af23-08d7f11ac1b6 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 May 2020 17:35:51.6464 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: usyMCa4W4+TExqCmTsn8aEs+V9vnXYNcXGfmRGl0kFUrZx9cjX7+cpFzfto22Di4v9W6y+bLcWqKR3KwoofoPtg/Y69hjLJyvECA4q1J+q9NI1DUZPJdiPaykDRe7puf X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3740 Archived-At: Subject: Re: [Ace] Update of access rights X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 05 May 2020 17:35:56 -0000 SGkgTWljaGFlbCwNCg0K77u/T24gMDUvMDUvMjAyMCwgMTg6MDEsICJBY2Ugb24gYmVoYWxmIG9m IE1pY2hhZWwgUmljaGFyZHNvbiIgPGFjZS1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBt Y3IraWV0ZkBzYW5kZWxtYW4uY2E+IHdyb3RlOg0KDQoNCiAgICBGcmFuY2VzY2EgUGFsb21iaW5p IDxmcmFuY2VzY2EucGFsb21iaW5pPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnPiB3cm90 ZToNCiAgICAgICAgPiA3LiBDbGllbnQgd2FudHMgdG8gdXBkYXRlIGl0cyBhY2Nlc3MgcmlnaHRz OiByZXRyaWV2ZXMgVDIgZnJvbSBBUy4gTm90ZQ0KICAgICAgICA+IHRoYXQgdGhpcyBUMiBoYXMg ZGlmZmVyZW50IGF1dGhvcml6YXRpb24gaW5mbywgYnV0IGRvZXMgbm90IGNvbnRhaW4NCiAgICAg ICAgPiBpbnB1dCBrZXlpbmcgbWF0ZXJpYWwgKCJvc2MiKSwgb25seSBhIHJlZmVyZW5jZSB0byBp ZGVudGlmeSBTZWMxICgia2lkIg0KDQogICAgSXMgdGhlcmUgYW4gYXNzdW1wdGlvbiB0aGF0IHRo ZSBhY2Nlc3MgcmlnaHRzKFQyKSA+PSBhY2Nlc3MgcmlnaHRzKFQxKT8NCg0KRlA6IE5vLiBCdXQg YXQgdGhlIHNhbWUgdGltZSBpZiBhY2Nlc3MgcmlnaHRzKFQyKSBpcyBhIHN1YnNldCBvZiBhY2Nl c3MgcmlnaHRzKFQxKSwgdGhlbiB0aGVyZSBpcyBubyBwb2ludCBpbiB0aGUgY2xpZW50IHJlcXVl c3RpbmcgVDIgZnJvbSB0aGUgQVMuLi4gVGhlc2UgY291bGQgYmUgYSBkaXNqb2ludCBzZXRzIG9m IGFjY2VzcyByaWdodHMuDQoNCiAgICAgICAgPiBNb3Jlb3Zlciwgd2hpbGUgY29tcGFyaW5nIHdp dGggRFRMUyBwcm9maWxlLCB3ZSByZWFsaXplZCB0aGVyZSBpcyBubw0KICAgICAgICA+IHJlYXNv biBmb3Igd2hpY2ggOC4gc2hvdWxkIGJlIHNlbnQgdW5wcm90ZWN0ZWQuIEluIGZhY3QsIGRvaW5n IHNvIG9wZW5zDQogICAgICAgID4gdXAgdG8gcG9zc2libGUgYXR0YWNrcyB3aGVyZSBhbiBvbGQg dXBkYXRlICh0b2tlbiBub24gZXhwaXJlZCkgaXMNCiAgICAgICAgPiByZS1pbmplY3RlZCB0byB0 aGUgUlMgYnkgYW4gYWR2ZXJzYXJ5Og0KDQogICAgSSBhZ3JlZSBhbmQgSSBzZWUgeW91ciBwb2lu dC4NCiAgICBUaGFuayB5b3UgZm9yIGV4cGxhaW5pbmcgaXQgc28gd2VsbC4NCg0KRlA6IFRoYW5r IHlvdSEgSSB0cmllZCB0byBiZSBhcyBjbGVhciBhcyBwb3NzaWJsZSA6KQ0KDQogICAgTXkgcXVl c3Rpb24gaXMgd2hldGhlciBzdGVwIDggcmVzdWx0cyBpbiBTZWMgQ3R4IHNlYzEgYmVpbmcgZGVs ZXRlZD8NCiAgICBDb3VsZCBDbGllbnQgd2FudCB0byBrZWVwIGl0IGFsaXZlIGluIHRoZSBjYXNl IHRoYXQgVDEgYW5kIFQyIGFjdHVhbGx5IGRvDQogICAgZGlmZmVyZW50IHRoaW5ncz8NCg0KRlA6 IEFzIGN1cnJlbnRseSBkZWZpbmVkIGluIHRoZSBkb2N1bWVudCwgeWVzLCBTZWMxIGVuZHMgdXAg YmVpbmcgZGVsZXRlZCBhcyBzb29uIGFzIFNlYzIgaXMgdmFsaWRhdGVkIChpLmUuIGEgcmVxdWVz dCBpcyBjb3JyZWN0bHkgZGVjcnlwdGVkIGJ5IHRoZSByZWNlaXZpbmcgZW5kcG9pbnQgdXNpbmcg U2VjMikuIElmIFQxIGFuZCBUMiBkbyBkaWZmZXJlbnQgdGhpbmdzIGFuZCB0aGUgY2xpZW50IHdh bnRzIHRvIChhbmQgaXMgYWxsb3dlZCB0byAtIFQxIGlzIG5vdCBleHBpcmVkIG9yIHJldm9rZWQg Zm9yIHNvbWUgcmVhc29uKSBrZWVwIFQxIGFsaXZlLCB0aGVuIHdlIGFyZSBub3QgaW4gdGhlIGNh c2Ugb2YgInVwZGF0ZSBvZiBhY2Nlc3MgcmlnaHRzIiwgaS5lLiB0aGUgY2FzZSB3aGVyZSBUMiBy ZXBsYWNlcyBUMS4gTXkgIkZpbmFsIHBvaW50IiB3YXMgdG8gY292ZXIgZXhhY3RseSB0aGUgY2Fz ZSB5b3UgbWVudGlvbiwgd2hlcmUgVDEgYW5kIFQyIGFyZSB1c2VkIHRvIGRlcml2ZSAyIGRpZmZl cmVudCBzZWN1cml0eSBjb250ZXh0cywgd2hlcmUgdGhlIFJTIGRvZXMgbm90IHJlYWxpemUgdGhl eSBjb21lIGZyb20gdGhlIHNhbWUgQ2xpZW50LiBJdCBpcyB1cCB0byB0aGUgQVMgdG8gbWFrZSBz dXJlIHRoYXQgVDEgYW5kIFQyIGFyZSBkaXNqb2ludHM6IHdoeSB3b3VsZCB0aGUgQVMgZXZlbiBz ZW5kIDIgZGlmZmVyZW50IHRva2VucyB0aGF0IGNvdmVyIHBhcnQgb2Ygb3IgdGhlIGVudGlyZSBz YW1lIHNjb3BlIGF0IHRoZSBzYW1lIFJTIHRvIHRoZSBzYW1lIGNsaWVudD8gQnkgdGhlIHdheSwg aWYgaXQgaXMgbm90IGFscmVhZHkgaW4gdGhlcmUsIEkgdGhpbmsgdGhhdCB0aGF0IGlzIGFub3Ro ZXIgZXhjZWxsZW50IGNvbnNpZGVyYXRpb24gcG9pbnQgZm9yIHRoZSBBY2UgZnJhbWV3b3JrLg0K DQpUaGFua3MsDQpGcmFuY2VzY2ENCg0KICAgIC0tIA0KICAgIF0gICAgICAgICAgICAgICBOZXZl ciB0ZWxsIG1lIHRoZSBvZGRzISAgICAgICAgICAgICAgICAgfCBpcHY2IG1lc2ggbmV0d29ya3Mg Ww0KICAgIF0gICBNaWNoYWVsIFJpY2hhcmRzb24sIFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3JrcyAg ICAgICAgfCAgICBJb1QgYXJjaGl0ZWN0ICAgWw0KICAgIF0gICAgIG1jckBzYW5kZWxtYW4uY2Eg ICAgIFsNCg0KDQo= From nobody Tue May 5 11:07:36 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9EF13A0B6A for ; Tue, 5 May 2020 11:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 PIlQBe4Xqf8w for ; Tue, 5 May 2020 11:07:26 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C66E3A0B6D for ; Tue, 5 May 2020 11:07:23 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 195923818F; Tue, 5 May 2020 14:05:23 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8634571E; Tue, 5 May 2020 14:07:21 -0400 (EDT) From: Michael Richardson To: Jim Schaad , 'Ace' In-Reply-To: <02f001d62299$56718830$03549890$@augustcellars.com> References: <56d31e581571721e176b59db20e08c23@bbhmail.nl> <00f101d61f03$a26bb920$e7432b60$@augustcellars.com> <0873a3115cab89036002cf42b1c97608@bbhmail.nl> <87mu6o6u8t.fsf@wangari> <20200505040917.GM27494@kduck.mit.edu> <02f001d62299$56718830$03549890$@augustcellars.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Ace] draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 05 May 2020 18:07:32 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Jim Schaad wrote: > I have much the same problem. While a client could find an AS which > would authenticate the client, I don't know how the client would > establish any degree of trust in the AS which is going to give it > tokens. Is your question that you don't know how to trust that the AS is the correct AS for RS-foo? > If you have already put a local public key for the AS into the > client, then you might as well put in a name for the AS as well. I > suppose you could get by with a shared secret but that does not seem = to > be a good way to build up the system. Maybe there are redundant instances of the AS, or maybe there are multiple = ways (thus different IP addresses) by which to reach the AS. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl6xq1kACgkQgItw+93Q 3WWumAf+PlZx6725rOe1fSaUNQdHoHdiyX9tAGa4dQhsLCVQB2fYQJvs7TU5R/WC gysxGM9Vj+kawBdaa3g5WQ2PXSHUy2gNxw4U+biik9zM+60LXdJjr5TgUtjQB+84 pST4AYSYksXQd2xCxitE7eSVtVpd7r/oZ0MbqykzNRcn4QwuFOZr9MzrfUwDzfUb qm0SUyA0EDfIVpJKKmRGEdN1KzzGTs0APflKkKWnMJzWchuyRJoKKFnvYFpik9f1 wlFZABJx/NSklB+sQRt0sOGXjOffAWvs3DdBkA6KesWDeOOnDStlYdJS9FIBFtjm X007DWc+firFTHUYAM9dLOeGZUvbEQ== =k0dN -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue May 5 19:38:51 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F353A0CFE for ; Tue, 5 May 2020 19:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 bEK7uY5ELdYH for ; Tue, 5 May 2020 19:38:48 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCEAF3A0CB5 for ; Tue, 5 May 2020 19:38:47 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 5 May 2020 19:38:41 -0700 From: Jim Schaad To: 'Michael Richardson' , 'Ace' References: <56d31e581571721e176b59db20e08c23@bbhmail.nl> <00f101d61f03$a26bb920$e7432b60$@augustcellars.com> <0873a3115cab89036002cf42b1c97608@bbhmail.nl> <87mu6o6u8t.fsf@wangari> <20200505040917.GM27494@kduck.mit.edu> <02f001d62299$56718830$03549890$@augustcellars.com> <14777.1588702041@localhost> In-Reply-To: <14777.1588702041@localhost> Date: Tue, 5 May 2020 19:38:38 -0700 Message-ID: <039801d6234f$744229d0$5cc67d70$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJvvEQrX2wOjMB2/s9A8vau6YKJYgFtua5lAwDjVtQCw58eHwIqARfCAhrUIdYCU/X116b4R6Wg Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 06 May 2020 02:38:50 -0000 -----Original Message----- From: Michael Richardson Sent: Tuesday, May 5, 2020 11:07 AM To: Jim Schaad ; 'Ace' Subject: Re: [Ace] draft-ietf-ace-oauth-authz Jim Schaad wrote: > I have much the same problem. While a client could find an AS which > would authenticate the client, I don't know how the client would > establish any degree of trust in the AS which is going to give it > tokens. Is your question that you don't know how to trust that the AS is the correct AS for RS-foo? [JLS] No, my question is how do I know to trust the AS period. I don't have a key to establish a secure session with the AS. I guess doing full X.509 certificate processing would be an answer, but that could be difficult in the event of a key compromise. > If you have already put a local public key for the AS into the > client, then you might as well put in a name for the AS as well. I > suppose you could get by with a shared secret but that does not seem to > be a good way to build up the system. Maybe there are redundant instances of the AS, or maybe there are multiple ways (thus different IP addresses) by which to reach the AS. [JLS] It could be that there are redundant instances of the AS, but then you have the problem of either doing key sharing between all of them or needing the ability to validate the key assigned to each of them. If you have different addresses, that might be interesting, but you are going to need to do trial connections to each possible AS found until you get one that works. Jim -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- From nobody Tue May 5 21:09:16 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 705663A0D37 for ; Tue, 5 May 2020 21:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 r3xNN2nVqr71 for ; Tue, 5 May 2020 21:09:11 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69BB93A0D36 for ; Tue, 5 May 2020 21:09:11 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49H34d1GkjzyY5; Wed, 6 May 2020 06:09:05 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <034001d622f3$5606eca0$0214c5e0$@augustcellars.com> Date: Wed, 6 May 2020 06:09:04 +0200 Cc: Benjamin Kaduk , Olaf Bergmann , Peter van der Stok , peter van der Stok , Ace X-Mao-Original-Outgoing-Id: 610430944.5459141-18c93633d0b7f102029677e0743cf36f Content-Transfer-Encoding: quoted-printable Message-Id: References: <56d31e581571721e176b59db20e08c23@bbhmail.nl> <00f101d61f03$a26bb920$e7432b60$@augustcellars.com> <0873a3115cab89036002cf42b1c97608@bbhmail.nl> <87mu6o6u8t.fsf@wangari> <20200505040917.GM27494@kduck.mit.edu> <02f001d62299$56718830$03549890$@augustcellars.com> <034001d622f3$5606eca0$0214c5e0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Ace] draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 06 May 2020 04:09:15 -0000 On 2020-05-05, at 17:39, Jim Schaad wrote: >=20 > I don't see how the four-corner model solves the issue that I = highlighted. If the client does not have a key for any local AS, then = nothing helps. The four-corner model deals with the issue of the client = and the RS not trusting the same AS, but the different AS entities trust = each other on the back side. >=20 > Getting trust in a local AS seems to be a bootstrapping problem. If you only have one security domain, there is no benefit. But in general is it much easier to bootstrap a device once into its own = security domain, instead of having to do the bootstrapping again and = again for each server that device needs to access. Gr=C3=BC=C3=9Fe, Carsten >=20 > Jim >=20 >=20 > -----Original Message----- > From: Carsten Bormann =20 > Sent: Monday, May 4, 2020 10:38 PM > To: Jim Schaad > Cc: Benjamin Kaduk ; Olaf Bergmann ; = Peter van der Stok ; peter van der Stok = ; Ace > Subject: Re: [Ace] draft-ietf-ace-oauth-authz >=20 > On 2020-05-05, at 06:54, Jim Schaad wrote: >>=20 >> I have much the same problem. While a client could find an AS which=20= >> would authenticate the client, I don't know how the client would=20 >> establish any degree of trust in the AS which is going to give it = tokens. >=20 > Hence the four-corner model [1]. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > [1]: https://tools.ietf.org/html/draft-ietf-ace-actors >=20 From nobody Wed May 6 08:47:38 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2E73A081A for ; Wed, 6 May 2020 08:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 oWz3yo37H92C for ; Wed, 6 May 2020 08:47:33 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A89B33A07F5 for ; Wed, 6 May 2020 08:47:33 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 88D953818F; Wed, 6 May 2020 11:45:33 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id ACF395C; Wed, 6 May 2020 11:47:32 -0400 (EDT) From: Michael Richardson To: Carsten Bormann , Ace In-Reply-To: References: <56d31e581571721e176b59db20e08c23@bbhmail.nl> <00f101d61f03$a26bb920$e7432b60$@augustcellars.com> <0873a3115cab89036002cf42b1c97608@bbhmail.nl> <87mu6o6u8t.fsf@wangari> <20200505040917.GM27494@kduck.mit.edu> <02f001d62299$56718830$03549890$@augustcellars.com> <034001d622f3$5606eca0$0214c5e0$@augustcellars.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Ace] draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 06 May 2020 15:47:36 -0000 --=-=-= Content-Type: text/plain Carsten Bormann wrote: >> I don't see how the four-corner model solves the issue that I >> highlighted. If the client does not have a key for any local AS, then >> nothing helps. The four-corner model deals with the issue of the >> client and the RS not trusting the same AS, but the different AS >> entities trust each other on the back side. >> >> Getting trust in a local AS seems to be a bootstrapping problem. > If you only have one security domain, there is no benefit. But in > general is it much easier to bootstrap a device once into its own > security domain, instead of having to do the bootstrapping again and > again for each server that device needs to access. That was my understanding. The four corner removes the problem of how C trusts RS to a problem of how does C ask CAS whether it can trust RS. Which could involve significant layers of PKI or human override (or pixie dust). -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl6y3BQACgkQgItw+93Q 3WWg9QgAtrOBmcxlgP9SEKrgBvCh9n49HwWyQISvXxaulnTzrVwwZ6dVrkFRnEZw dKsdtHvLDdGe+JKclEZZshkzpSJarB/ehefQoRpuuo8lMII+lh9X12VOwx8wKTTm 7apPQd4tuVaSrnGN5klHySMrXPAGSRsnD3BicVMjxMDzZTehz9eV+ENF7G0amby2 MeLagGCM0EF5nE963WcwRku0Xugl7HiokUR3GR08NtrvSHnb8tM48H7w3qq2X3sP iGVB5J0DyfKv/CxqpjQ8dr7On84kF8uzPrXqoAAmnN09AxvR2LgaEnCaQsuoOVwK DZCPsodwplmz+5lFYsVp9YZciGo0eQ== =IQlE -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed May 6 08:58:30 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A5A3A0871 for ; Wed, 6 May 2020 08:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 b929bTHYtSL2 for ; Wed, 6 May 2020 08:58:24 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A8853A0B69 for ; Wed, 6 May 2020 08:58:24 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9816C3818F; Wed, 6 May 2020 11:56:23 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B3CF45C; Wed, 6 May 2020 11:58:22 -0400 (EDT) From: Michael Richardson To: Francesca Palombini cc: Ace Wg In-Reply-To: References: <8063D003-2C48-4157-B80E-B7AF3D2099FC@ericsson.com> <20680.1588694462@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Ace] Update of access rights X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 06 May 2020 15:58:28 -0000 --=-=-= Content-Type: text/plain Francesca Palombini wrote: mcr> Is there an assumption that the access rights(T2) >= access mcr> rights(T1)? > FP: No. But at the same time if access rights(T2) is a subset of access > rights(T1), then there is no point in the client requesting T2 from the > AS... These could be a disjoint sets of access rights. There are some cases here. T2 is a superset of T1. Everything makes sense. T2 is a subset of T1. I to think about this. T2 is complete disjoint of T1. T2 is the union of a subnet of T1, and some new set of rights T2B. That is, partial overlap, but T2 not superset of T1. > FP: As currently defined in the document, yes, Sec1 ends up being > deleted as soon as Sec2 is validated (i.e. a request is correctly > decrypted by the receiving endpoint using Sec2). If T1 and T2 do > different things and the client wants to (and is allowed to - T1 is not > expired or revoked for some reason) keep T1 alive, then we are not in > the case of "update of access rights", i.e. the case where T2 replaces > T1. My "Final point" was to cover exactly the case you mention, where > T1 and T2 are used to derive 2 different security contexts, where the > RS does not realize they come from the same Client. It is up to the AS > to make sure that T1 and T2 are disjoints: why would the AS even send 2 > different tokens that cover part of or the entire same scope at the > same RS to the same client? By the way, if it is not already in there, > I think that that is another excellent consideration point for the Ace > framework. Client could be vaguely "multi-tenant", having a common security substrate. That's why there could be 2 different tokens. Think intelligent speakers that can learn "skills". One skill operates the stereo, and wants to adjust living room lighting for appropriate mood. (/me deletes off-colour joke about South Park) The other skill is the sleep aid, and just wants to dim all lights to near darkness, but should not operate stereo. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl6y3p4ACgkQgItw+93Q 3WWQ4Qf/e895EHGlvJEKPceoMY6v1z0ttHZX/x5Rnr012Uyl4NAQ/pE6bOMY+fhC ctzx4rpW1VYQbaisj+8N1ESh97ilU/shY51F21pkcuAUFkSwTvQem3f5Vk21FpvM +UJr96IZzk+bjqb8/1Wcy6VU7Eqznr0vkCzW+BthJ8FhMTKcM2wt6bp/eb17Kii/ OVwLqPM1Jl+KWwR0nSCCIrFZFrVg8uRpLj3tYHu8mlsHbF/OEFFxF1mtzaTiqsRn KaySVD5wWqiSdrPFwlJJaKJavD0T2mD6vPlqElHbP2f5m+iwDT1S/tCHOZOXvOvX OpbZZR8EiksZ5mfydNrD6BZyLgWoTA== =/jhH -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat May 9 20:56:32 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 385CD3A040B; Sat, 9 May 2020 20:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Tkncamp4GWvv; Sat, 9 May 2020 20:56:26 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 8151C3A040A; Sat, 9 May 2020 20:56:25 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 04A3uF8X020166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 9 May 2020 23:56:17 -0400 Date: Sat, 9 May 2020 20:56:15 -0700 From: Benjamin Kaduk To: Francesca Palombini Cc: Ace Wg , Jim Schaad , "draft-ietf-ace-dtls-authorize@ietf.org" , "draft-ietf-ace-oscore-profile@ietf.org" Message-ID: <20200510035544.GG27494@kduck.mit.edu> References: <8063D003-2C48-4157-B80E-B7AF3D2099FC@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8063D003-2C48-4157-B80E-B7AF3D2099FC@ericsson.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Ace] Update of access rights X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2020 03:56:30 -0000 Hi Francesca, Thanks for assembling this very nice writeup: I think it's quite helpful to get clarity, given that Ludwig thought this was already the case but I couldn't come to that conclusion based on my review of the document. I just have one (maybe nitpicky) comment: when identifying things by 'kid' we have to account for the possibility of collisions, so probably we should talk about the "same key". Assuming I've retained correctly Jim's teachings, at least...this one I've had trouble with :) Thanks again, Ben On Tue, May 05, 2020 at 01:36:41PM +0000, Francesca Palombini wrote: > Hi Ace chairs, DTLS authors, Ace framework authors, Ben, > > TL;DR: we propose some changes on the OSCORE profile for the "update of access rights" scenario. We have comments for the DTLS profile and the ACE framework regarding this scenario, and we ask for feedback from ACE OSCORE implementers and Ace in general. > > In an attempt to answer Jim's (https://github.com/ace-wg/ace-oscore-profile/issues/20) and Ben's (https://github.com/ace-wg/ace-oscore-profile/pull/30) review of the OSCORE profile, we have been thinking more about the case of updating access rights. This has revealed to us authors that something is missing from the document, and I believe that this part is not explicitly covered in the DTLS profile either, hence this email. > > This is the scenario, and what is currently defined in the OSCORE profile: > > 1. Client retrieves access token T1 from AS > 2. Client posts T1 to RS, together with nonce N1 > 3. RS replies with 2.01 and nonce N2 > 4. Client and RS derive OSCORE Sec Ctx "Sec1" from T1 ("osc" object), N1, N2 > 5. Client uses Sec1 to protect its request to RS > 6. RS uses Sec1 to verify request. Verification success => Sec1 is validated and associated with T1 (at the RS) > ---- > 7. Client wants to update its access rights: retrieves T2 from AS. Note that this T2 has different authorization info, but does not contain input keying material ("osc"), only a reference to identify Sec1 ("kid" in "cnf") > 8. Client posts T2 to RS, together with nonce N1' > 9. RS replies with 2.01 and nonce N2' > 10. Client and RS derive OSCORE Sec Ctx "Sec2" from T1 keying input material ("osc" object), N1', N2' > 11. Client uses Sec2 to protect its request to RS > 12. RS uses Sec2 to verify request. Verification success => Sec2 is validated and associated with T2 (at the RS) ; T1 is removed ; Sec1 is removed > > In the document right now, we are missing the exact description of how in 8. RS identifies that this is an update of access rights for C, aiming at replacing T1. We propose to add text stating that (in 3. and 9.) RS MUST check the kid (in the "kid" in the "cnf" of the access token), and match it with existing security contexts, to realize that this is an update for an existing token associated to the sec ctx identified by kid. > > Moreover, while comparing with DTLS profile, we realized there is no reason for which 8. should be sent unprotected. In fact, doing so opens up to possible attacks where an old update (token non expired) is re-injected to the RS by an adversary: > > * Client sends T1 to RS --> accepted > * Client sends update of access rights T2 --> accepted > * Client sends update of access rights T3 --> accepted > * Malicious node re-sends T2 --> accepted > > Of course that could be mitigated with expiration times and with checking "issued at time" field (which is optional). But we believe even though these are good points (which might actually be worth adding to the framework), sending the token to the RS over the existing protected channel solves this issue. So we propose that 8. is protected with OSCORE and Sec Ctx Sec1. For DTLS authors: I believe Jim has extrapolated from your document that that is the case for the DTLS profile already, i.e. POST token to RS for update of access rights is over DTLS; I think it would be worth explicitly stating that in the DTLS profile. > > Additionally, analogously to DTLS where the same channel is kept even if access rights are updated, I do not see any reason at this point to have the endpoints re-derive a new security context. This is the biggest change I propose, and can be summarized by replacing the points above as follows: > > 7. Client wants to update its access rights: retrieves T2 from AS. Note that this T2 has different authorization info, but does not contain input keying material, only a reference to identify Sec1 > 8. Client posts T2 to RS, *without nonce* *protected with Sec1* > 9. RS *verifies that this is an update of access right, replacing T1 (associated with Sec1) ; Sec1 is associated with T2; T1 is removed *; RS replies with 2.01 *without nonce* *protected with Sec1* > 10. Client uses *Sec1* to protect its request to RS > > I can already see the objection from implementers: the authz-info endpoint at the RS becomes accessible both unprotected (in case the Client is posting a token for the first time, points 1. to 6.) and protected (in case Client needs to update rights, points 7. to 10.) I believe that defining a NEW endpoint at the RS for the "update rights" mechanism would be the best solution, but I understand that would require modifications to the framework that Ludwig probably would not want to do, as it might delay the document. I think these would in practice be 2 different endpoints with the same URI, one OSCORE protected and one unprotected. But I need more input from our implementers to know if this absolutely cannot be done. > > Our proposal: > An RS receiving a token (point 2 and 8) MUST check the kid of the token against existing security contexts. If a match is found, but the POST was unprotected, reject. If a match is found AND the POST was protected using that same Sec Ctx identified by kid, update access rights. If a match is not found, derive sec ctx as defined before. These 2 endpoints also require different payload: posting the token for the first time unprotected requires a nonce, posting an update using OSCORE does not (and the nonce will be discarded if sent). > > Doing so answers Ben's point about 2 tokens being saved at the RS at the same time, while Sec2 is not yet validated (between 8. and 12. above), since it removes Sec2 altogether. As soon as T2 is verified, T1 can be replaced with T2. > > Final point: what happens if the Client posts a second token T2 (to unprotected authz-info) which contains a different "osc" object, different kid etc. The RS will not be able to identify this Client as someone it already has a sec association with, and it will set up a different Sec Ctx with it. I think this is OK, as for it to be accepted, the AS had to provide such a token. The framework RECOMMENDS that an RS stores only one token per proof-of-possession key, which would still be valid, as different tokens would be associated to different Sec ctxs. > > Any feedback or comment is appreciated. > > Thanks, > Francesca > > > From nobody Mon May 11 08:11:46 2020 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A07FE3A00B0; Mon, 11 May 2020 08:11:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.129.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <158920988253.10641.4871241146889650561@ietfa.amsl.com> Date: Mon, 11 May 2020 08:11:22 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-key-groupcomm-06.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 15:11:23 -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 WG of the IETF. Title : Key Provisioning for Group Communication using ACE Authors : Francesca Palombini Marco Tiloca Filename : draft-ietf-ace-key-groupcomm-06.txt Pages : 57 Date : 2020-05-11 Abstract: This document defines message formats and procedures for requesting and distributing group keying material using the ACE framework, to protect communications between group members. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-06 https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-key-groupcomm-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 11 08:30:30 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C2C3A07A1 for ; Mon, 11 May 2020 08:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRt27ab6n0RV for ; Mon, 11 May 2020 08:30:26 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20068.outbound.protection.outlook.com [40.107.2.68]) (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 7F0073A085C for ; Mon, 11 May 2020 08:30:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ae7zOemS4DCqXxADlEW0lRZoxg+aVBsxeQiuQRuPxIYkocBLTegIQbRBZgGZPpB1N4BgF7KcthSzZApe96BbbSgofN+NdRMFTw3L2J/t++V5LY3TMJ44NX4g5Kt5IV9aH6uAFzDCa+CnHmH6qp5aWgRmelZglqJCUe7CnwipPVDqSRLNpNaQMPidcckTHpornfHQluZaKpxGEvkr76WpmCpzfnxW6cOvG0PEbGi+ltvTT7etflG4KBVRJMPcKQ0GiZMv3mX1phHqKdLVLT0gKjQUdUQ28txbI/IBiwSDuby6XlNevXGYUfDBYPukzv1OalPn8iMb/L0nUCDGt5Zx1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iCuBG+q47zzBhs/k65GzO0cFDkzgRCXnbBd/3TJOMqA=; b=eGv6stEwRlsadcDo6H+JncSg4dyHabanTA6z1MxOONgB7KU7Sh6eocF9MMMsBcSP6C7bPSS2ZVtjEEu5vC2bp6jLYjVsOMZp6/7NW6mDanOGK4FN+swWdtOSE2HrO4B6wn2Om4edgPs0R68vohjCErSv20frV+DEU2bf9QHDmnHM1AEnlN/ulcjNaGJrPcUaZ2JcW/Cfa42R8313T37sybEUBalzxND7d+2cYH9QjbgB1a+w5DdXEkYOVNxXshjXgV6anshxKPcAidd9D7RlCuHFeVIK8Tc9N/JEv7t3p0mMxtjtfDOAvHwnuE8i1oKuFrHqzdgRuz/cAoNrwZIGUw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iCuBG+q47zzBhs/k65GzO0cFDkzgRCXnbBd/3TJOMqA=; b=LEv/AmG/4HitDcZZVXrPPXYm9oOsqy6sr+HeXb5f7085c7/Bg/B6gnizmZ8W06JU6uTehbum8Mh5pIACc6bHH9dW+XPD1WRIbsUSANLCyHXDzdyyGT+grQNluqfUIuq6nAAnno61gXx2JOWGWqKWE7qorCN3nMhgowBLMnHLbC4= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) by HE1PR0702MB3548.eurprd07.prod.outlook.com (2603:10a6:7:8b::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.17; Mon, 11 May 2020 15:30:16 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::f0bb:b1ae:bf22:4526]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::f0bb:b1ae:bf22:4526%6]) with mapi id 15.20.2979.033; Mon, 11 May 2020 15:30:16 +0000 From: Francesca Palombini To: "ace@ietf.org" Thread-Topic: [Ace] I-D Action: draft-ietf-ace-key-groupcomm-06.txt Thread-Index: AQHWJ6Z4VkrCf3iWMECknZgEPuKKvqijJF4A Date: Mon, 11 May 2020 15:30:16 +0000 Message-ID: <06C202E2-68CB-4B8F-92E2-6BA5D15AE01A@ericsson.com> References: <158920988253.10641.4871241146889650561@ietfa.amsl.com> In-Reply-To: <158920988253.10641.4871241146889650561@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5c0e8b47-a886-4ce7-cc2e-08d7f5c034fc x-ms-traffictypediagnostic: HE1PR0702MB3548: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 04004D94E2 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: fUmfumKlSE1mbE554vIK+1QPDWB22qes5MJ7t7gNaoWufq77jcoPARwKdt8T8MQJ+rl7WrcGcqY+/Ze64iaG08xlW9MBcOrwZ0Tx5Sf9r6eLlRsGACbqXgttXh1tvZtxL/44D18SP9Du69zbFLwm9QNoONfPLe63WKEKLluEq0pjAbDkZT6pW5mct597dedNnLUl2iZJX6abnWmL3rxrSoETUIY4/gtzT+WZ+36af6P5bR6TkgyOMiDHFNZxnoR9K7U88EI0RVbJ5enHstAVxNrt3LvS+bjAhKVQOsr7AkhCmupjr1+HbYtV4Xje1rnvuoS2uBtBDN/KBtZtc1n9jgQtrieo8IkT3SHvJflEV0WiglBPvW2UkGXMKn2HGXxnG/AKIQSdxDDxkoORUBq3YoRRmC4iccgsW5QIvJFAgCc1SO4Y/rWaMKuacqkez0qxTAlVBd9wJ/ohgpTxIcENKr1Iu1vxHU42AXgxhQY8ICnXe9kYjTWkXyNPQe5q6irGKJNxoEvivPr9pL0WakNWVAtDc9UzYG3AF+5EBrJSgaJ32yqTvSJiNHke42F8/08YaOSOlYPYk6h9PsVGrYAAoHZroAqaIvugoSIh2nbeXQ4= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3818.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(346002)(39860400002)(396003)(366004)(136003)(33430700001)(44832011)(76116006)(2906002)(6916009)(26005)(64756008)(66556008)(5660300002)(186003)(71200400001)(8676002)(66446008)(8936002)(66574014)(33440700001)(966005)(86362001)(6506007)(478600001)(6512007)(2616005)(66946007)(36756003)(66476007)(33656002)(316002)(6486002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: IRPvju+OA6ONWptFLkZPtS8xiRrszSLo7tw1KhBUbiSos1SZ76xvY6eyY0N7Y/HM+wNSyvCav6r7HN5iTInvdripwsQjNphPAMlUoR18JBMiRLjcDQ+tKMe2bzrxHo1vX9qWcw1BzpD4qL3OAta62/qM87APjYu+vgsudpfIJj+9XoKprEKe2qINsoBhn+vbkRGRrGmE+iR/lF/c9DsTdFh+b4RgJ3esrH69hPGj5AVs6JOOSJj3Ee5nOxZOujDoybzw/TY892tOakV9bAt6k9TprUsxg+MPRSSVKdg2H+RhYhWzI5Drp5Chf/VL6ewixaZWrHRZbABtXLj3QiueJfFXFECmjDCq/0T91jDuPeTmhjOf6yJxH1skfHT05o4KvGECSq6X05ux7BcFOhmk2lVrg+rk1aemO2QOj4rd5DlDxJBcvYv9g20mMZ/vC4dYvG4zkhcssInOHJ6brvMWdDGRX8Xijoq1mGSVs9OX1KVvizbuS16wit/bfUDz/gkK x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <89B2482DF90A9346B88BBA7E38B89DAF@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5c0e8b47-a886-4ce7-cc2e-08d7f5c034fc X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2020 15:30:16.6883 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: f+V84/o8DOgLVpi9LGHA0Z/O0sqqP9hB3y87w/9coWt1gioijx7qjT0dySu4Ae6rgdYGFcWdrDigDjeQkLLx4ygBzRecodB3+XODOObTg2a0Id7g58tOvyGERo3Gf7/S X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3548 Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-key-groupcomm-06.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 11 May 2020 15:30:28 -0000 SGkgYWxsLA0KDQpXZSBqdXN0IHN1Ym1pdHRlZCBhbiB1cGRhdGUgdG8gdGhlIGFjZS1rZXktZ3Jv dXBjb21tIGRvY3VtZW50LCBhcyBwcm9taXNlZCBkdXJpbmcgbGFzdCBpbnRlcmltLg0KDQpUaGlz IHVwZGF0ZSBjb3ZlcnMgdGhlIHBvaW50cyBkaXNjdXNzZWQgZHVyaW5nIHRoZSBtZWV0aW5nLCBh bmQgYSBjb3VwbGUgbW9yZSBjbGFyaWZpY2F0aW9uIHBvaW50cyB0aGF0IHRoZSBhdXRob3JzIGJl bGlldmVkIG5lY2Vzc2FyeS4gWW91IGNhbiBzZWUgYWxsIHRoZSBjb21taXRzIGluIHRoZSBQUjog aHR0cHM6Ly9naXRodWIuY29tL2FjZS13Zy9hY2Uta2V5LWdyb3VwY29tbS9wdWxsLzkzIC4NCg0K RmVlZGJhY2sgaXMgd2VsY29tZSENClRoYW5rcywNCkZyYW5jZXNjYQ0KDQrvu79PbiAxMS8wNS8y MDIwLCAxNzoxMSwgIkFjZSBvbiBiZWhhbGYgb2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiA8 YWNlLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9y Zz4gd3JvdGU6DQoNCg0KICAgIEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9t IHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCiAgICBUaGlzIGRyYWZ0 IGlzIGEgd29yayBpdGVtIG9mIHRoZSBBdXRoZW50aWNhdGlvbiBhbmQgQXV0aG9yaXphdGlvbiBm b3IgQ29uc3RyYWluZWQgRW52aXJvbm1lbnRzIFdHIG9mIHRoZSBJRVRGLg0KDQogICAgICAgICAg ICBUaXRsZSAgICAgICAgICAgOiBLZXkgUHJvdmlzaW9uaW5nIGZvciBHcm91cCBDb21tdW5pY2F0 aW9uIHVzaW5nIEFDRQ0KICAgICAgICAgICAgQXV0aG9ycyAgICAgICAgIDogRnJhbmNlc2NhIFBh bG9tYmluaQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWFyY28gVGlsb2NhDQogICAg CUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtYWNlLWtleS1ncm91cGNvbW0tMDYudHh0DQog ICAgCVBhZ2VzICAgICAgICAgICA6IDU3DQogICAgCURhdGUgICAgICAgICAgICA6IDIwMjAtMDUt MTENCg0KICAgIEFic3RyYWN0Og0KICAgICAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBtZXNzYWdl IGZvcm1hdHMgYW5kIHByb2NlZHVyZXMgZm9yIHJlcXVlc3RpbmcNCiAgICAgICBhbmQgZGlzdHJp YnV0aW5nIGdyb3VwIGtleWluZyBtYXRlcmlhbCB1c2luZyB0aGUgQUNFIGZyYW1ld29yaywgdG8N CiAgICAgICBwcm90ZWN0IGNvbW11bmljYXRpb25zIGJldHdlZW4gZ3JvdXAgbWVtYmVycy4NCg0K DQogICAgVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6 DQogICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1hY2Uta2V5 LWdyb3VwY29tbS8NCg0KICAgIFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWls YWJsZSBhdDoNCiAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hY2Ut a2V5LWdyb3VwY29tbS0wNg0KICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0 bWwvZHJhZnQtaWV0Zi1hY2Uta2V5LWdyb3VwY29tbS0wNg0KDQogICAgQSBkaWZmIGZyb20gdGhl IHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KICAgIGh0dHBzOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWFjZS1rZXktZ3JvdXBjb21tLTA2DQoNCg0KICAg IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRo ZSB0aW1lIG9mIHN1Ym1pc3Npb24NCiAgICB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQg ZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQogICAgSW50ZXJuZXQtRHJh ZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KICAgIGZ0cDovL2Z0 cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoNCg0KICAgIF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgQWNlIG1haWxpbmcgbGlzdA0KICAgIEFj ZUBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNl DQoNCg== From nobody Mon May 11 09:28:06 2020 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C205A3A0975; Mon, 11 May 2020 09:26:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.129.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <158921438070.12655.4465969317306070305@ietfa.amsl.com> Date: Mon, 11 May 2020 09:26:20 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-key-groupcomm-oscore-06.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 16:26:21 -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 WG of the IETF. Title : Key Management for OSCORE Groups in ACE Authors : Marco Tiloca Jiye Park Francesca Palombini Filename : draft-ietf-ace-key-groupcomm-oscore-06.txt Pages : 40 Date : 2020-05-11 Abstract: This specification defines an application profile of the ACE framework for Authentication and Authorization, to request and provision keying material in group communication scenarios that are based on CoAP and secured with Group Object Security for Constrained RESTful Environments (OSCORE). This application profile delegates the authentication and authorization of Clients that join an OSCORE group through a Resource Server acting as Group Manager for that group. This application profile leverages protocol-specific transport profiles of ACE to achieve communication security, server authentication and proof-of-possession for a key owned by the Client and bound to an OAuth 2.0 access token. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm-oscore/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore-06 https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-oscore-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-key-groupcomm-oscore-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 11 09:34:19 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C21D3A0A4D for ; Mon, 11 May 2020 09:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96aRoyU2uaXX for ; Mon, 11 May 2020 09:34:12 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2079.outbound.protection.outlook.com [40.107.20.79]) (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 431CF3A0A3E for ; Mon, 11 May 2020 09:34:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Zv2tjTKciO3r5CVXRrLYfhup1CcZLpHlu6XQUbsjMr9l8MfYEJmwqYwduo3kz1ybnOxb6srn7U2IeIIi/NrNuY8m+bAIT0HYLgtobEWSpeNnDAm59kE/igQnffiRHMoX9fjMBW8N6eQdr5vM+Ol0P7ShQfrZ+yyDl4HyNsyWilT0ecfZGWh5Z2zj6JpPdAXWsuZvJHeLrZp4+ooMgJK2/4yinBpR3qjIIpuCWSQHT1tgFLc0kw8P2UJusqVDJ80pL6+zRVUBoDJiEkSszkPwkxUIxgAkKpS5GHiDAlUO+rBnsa4UvZ6S64W7C//f/iqGW4pC80IBseWlaSHjQuj34w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PP+jayqk3CE3LAHZTuwqTb1185ROx96/tLw5UIhyrNk=; b=M0NckoDPnqnz54mcPQIEDOZJDl/7ixvhUgwXS5vLHN048fb0K1TPNwnoOe+HZHgCx5/1fsXDoPg0qxaVLRilCR23VCtFUSWeyZCeF8r+idRnmEkIp/dARlKpO6cbT8kew/rERCSopX5hNW6rO6FQIYrRYKJXZaDhMNtfRAiSACJCihzgKYVnzO7qy39G+lwkzqU1r75fPYYVHseoK8AhxemMfQDik4uq+bBuf5c9DAapCYvA9506XkOM2CF2oyJ8XKCIjlNFbjNHxtrnyPCPS3vinR+xINhmiQBkMefyIPor+eKfM6EyQmr7Ieaca3xXAq+Eoux5EnXNeEzITX+9ng== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PP+jayqk3CE3LAHZTuwqTb1185ROx96/tLw5UIhyrNk=; b=cptKkTF9288FF4wEKqKE5K5l0t4lG6ZNk/sSvJ6GWhlJFh/QNGq7bWWg6stU0vST4CPUnls1rw+9D5U9C4NHH4HlZThELKKD/g+TV6ln9unJdamtN8BrXJrGZYTJ04ohb9WdzZCKYfDvJd8LJKU6IWDpTCPQb15VXmuQIMwKccI= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.34; Mon, 11 May 2020 16:34:09 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::5db5:cc81:e984:7c27]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::5db5:cc81:e984:7c27%7]) with mapi id 15.20.2979.033; Mon, 11 May 2020 16:34:09 +0000 To: ace@ietf.org References: <158921438070.12655.4465969317306070305@ietfa.amsl.com> From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: <4f2676ea-cbd7-14b9-743f-6d9f89075955@ri.se> Date: Mon, 11 May 2020 18:34:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 In-Reply-To: <158921438070.12655.4465969317306070305@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ea7MtEzQyJ1WaUPhMuGv3N2UzTzkxy7Ft" X-ClientProxiedBy: HE1PR0402CA0040.eurprd04.prod.outlook.com (2603:10a6:7:7c::29) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.8.13] (213.232.87.177) by HE1PR0402CA0040.eurprd04.prod.outlook.com (2603:10a6:7:7c::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.27 via Frontend Transport; Mon, 11 May 2020 16:34:08 +0000 X-Originating-IP: [213.232.87.177] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 28b35952-49c5-4768-857e-08d7f5c9210c X-MS-TrafficTypeDiagnostic: VI1P189MB0398: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-Forefront-PRVS: 04004D94E2 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: /FbOe0Jm4MIiTzklUvc8XybPZLMIubEs78469dmPQj7p0wfnJVYiIe75XEwUS1DDcWdIyYjMdA96sp5hE2EAnXoUqOtKuKwcvVSVTdeF/RYyWCe0VSygs25iWt6JcV/au1cwivEGs7Vvmm6j0ZGH7huJi/UhL8e9hLVTYzWB1QsUKyrBL8cW3rZ+xDPgA2Yy165dD4lTcY6MkUCT0YdkiZheo2lVTg73yKD9xY+2serjFQ+F71dBaOsf65q8wkOGM/wBMOI10bNYFh9UTluKH6eOkZNeARi27L++QM0d8U23hjH+ED/mvqHiQQ9GYiIZJLRGOcTJ7J/ljov/5cKrVhZztD4FdEzdj8juM7rheUXQW/vGBKU+mAvxkka+mxNKFUfTYatuqkJlbkz2flUJ4V8XZVZL0RQp6VtdPfDMZL6gOylnMG8jwR8s+jGTrRhBjMSOJA8+9B1Cg7fri8qGsi+9MmfAy6EaaGWtNnSQ+PhmRDRgJvQ2CJGXefMWkjigSPKxdb92HFb/Rcp84CjF0eJ/Aur7EDFG7crpEMii2JLHu2LeJoEXZ15RVHDafmCE7TxMPH3E0QcmnLNaH2ge69O/k0JEUb6KHpR18NkuUgdKBx0nr2r6qVj05XCC0Ktm X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1P189MB0398.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(366004)(346002)(376002)(39860400002)(33430700001)(21480400003)(235185007)(36756003)(52116002)(2906002)(8936002)(33964004)(26005)(16526019)(186003)(8676002)(31696002)(6666004)(31686004)(86362001)(33440700001)(478600001)(16576012)(966005)(6486002)(316002)(66574014)(5660300002)(53546011)(66946007)(2616005)(66476007)(66556008)(956004)(44832011)(6916009)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: JogGPyQONqAot7MIx8U3HwW9t5jl1b022HWCwh5MnBYaX8xCAcpfjFw6txGpxp1qAyuJTIEm71ztzhxh5YZ2w29QlMBJAOVzQqUJU74McyTVfkKppBdfSn2Z2GnHqlACB9FGccWP8/ROFg9uxefkrUrQwiz8eEX91rkj0K3UtKs/0Bvrndzlalx54ZURKQuUWK4otcrlhFJUyRDJqnbIwY7beoRmWciTo6yDQuuczIkdE+NNgTiuYVbMjLoY/BcVA/RB8cx3muFTKVJ5dj6TaXHvrGxSMe1f9qV3IV4SxjWHSzfnZyhyIDxNqvC8JTFET5XNX4nJCJ6/Ooc3jqE5oNWeg9h0tyGBP2lHU1LcAw+8VFdWFvivpg/DjqamGlsFA9sHrLSsN71Ik+hSirO84Ezwm/EEGzTyjdCgwFPtfS5j65OEw3+5MspG3rvcZwHxgmb8Lfb0E3OuLaOuqr/emviNnwKehuShB+NijdmoTj0= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 28b35952-49c5-4768-857e-08d7f5c9210c X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 May 2020 16:34:08.9583 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: tZhyQkdZkcEOYT0DB79vLzXWgFSKHFyRA2aFAN7FkhNWivneCtcMzJs20zIvkAeehvUSqAHcHUmjjOhn37lNoA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0398 Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-key-groupcomm-oscore-06.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 11 May 2020 16:34:17 -0000 --ea7MtEzQyJ1WaUPhMuGv3N2UzTzkxy7Ft Content-Type: multipart/mixed; boundary="EuZjwH2IeyRcx1307LAZ7gnPvATjyY0Rs" --EuZjwH2IeyRcx1307LAZ7gnPvATjyY0Rs Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hello ACE, We have just submitted a new version of ace-key-groupcomm-oscore , addressing the points discussed at the latest virtual meeting. All commits are in the PR at: https://github.com/ace-wg/ace-key-groupcomm-oscore/pull/39 Thanks, /Marco On 2020-05-11 18:26, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the Authentication and Authorization for C= onstrained Environments WG of the IETF. > > Title : Key Management for OSCORE Groups in ACE > Authors : Marco Tiloca > Jiye Park > Francesca Palombini > Filename : draft-ietf-ace-key-groupcomm-oscore-06.txt > Pages : 40 > Date : 2020-05-11 > > Abstract: > This specification defines an application profile of the ACE > framework for Authentication and Authorization, to request and > provision keying material in group communication scenarios that are > based on CoAP and secured with Group Object Security for Constrained= > RESTful Environments (OSCORE). This application profile delegates > the authentication and authorization of Clients that join an OSCORE > group through a Resource Server acting as Group Manager for that > group. This application profile leverages protocol-specific > transport profiles of ACE to achieve communication security, server > authentication and proof-of-possession for a key owned by the Client= > and bound to an OAuth 2.0 access token. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm-oscore/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore-06 > https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-osco= re-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-key-groupcomm-oscore= -06 > > > Please note that it may take a couple of minutes from the time of submi= ssion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --EuZjwH2IeyRcx1307LAZ7gnPvATjyY0Rs-- --ea7MtEzQyJ1WaUPhMuGv3N2UzTzkxy7Ft Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl65fnkACgkQ7iZktA5Y 2kOxIwf/TpzvIL3CatPIB8VQPChcTrgTRBm5fi2cl9BqEH9CZu7m4B8Y4m8dcGui IS0sDVkY5q4P+BVtosTkuDQ7BMSeePxy9GgBA4Npi9ICIgk0HScCwgwK8ujrqHU4 nzsxcUKXcJGR5rD+fUNP+ysVqp3O02/Ri47pzLE593qKeDpDMRrhxtWJ4dXMJfYo ZiTjwm22mN9ANAu3TGPjlv578OghnOMrwVQvT8EGSm1O2cMo6rCnrEkzGiuBvOkE qvD+7mlDDxgMJ8U/SFTLPE+TBF3js88G/cTy0x9xdjgutxk+XR7dzG2zvO6qvL9M G6+tqpjN3jy093O5MpvplHf8YlDVEg== =FK2o -----END PGP SIGNATURE----- --ea7MtEzQyJ1WaUPhMuGv3N2UzTzkxy7Ft-- From nobody Mon May 11 09:48:17 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD773A0ADE for ; Mon, 11 May 2020 09:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nePP4RRBTDhb for ; Mon, 11 May 2020 09:48:05 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60076.outbound.protection.outlook.com [40.107.6.76]) (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 95A883A0ACD for ; Mon, 11 May 2020 09:48:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SvK/OS6+9RyVxX/A8IwVm4T7OWZ8c/aPjV3+Cg95mUAX9lInOi+1b74Xk50cJ9VknXCYDtiZc89kgKDC3vdDnlLQpv2X/KrMtvYoqe6p3RQG7PDIHNwB0vAIuTQXQIEzv6oW/Ca+Kic+xbT4f8iS3qpza1RW303iKKwE0QEmXABBC5fybkFSHV24FwaXLE68yRHm1Q2/yzNLLwiWAJcnu9bj8oulP5eZQnAXm+JgF2L1e38haKtfeFtSJrOiOZ5ZYKqdhcyV0Bl0hjbk+/Now9ml3BVHdPzWjUhPbRkxNT44juMzU+OBJdEnD1zmaQJuliFE6q1NJg1aMw0k+Uhp0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Re8x7tby/57OtDzuFH9f9WH1JpOZf5ZDE8mauMN44IE=; b=MVLUk+8KJPi5TfMRgcFiusvXHMKx9lM9EdAkugSFmvNMBstKPMtGuGhbRCE9UFeZ8WxoSG7q07GwkBzOAnz9k2fQ3cV2sOEdUFOJ9Vb6XqzY3qeHGzv73WsvVJ4dTIVifKHWWZ0n5dvmZP9o+V+bJsHqBSCVmJusNixtcxH82dngUVw+HEwnQmOHo5dVlMRuCBqeFw/jv3+ZxsiK6nbj+XU0i4t/l8n9mLiiNTgTi6g2mSFchUdGq598sVqluDTqNZ9DcdAu/uE+EvIaVgA1sqHyLEuvTxnh2JAOeynQLqfw2MeOcXxD/uwmhNFkF/Ulehl9f/efIeas+sn1MEwTPA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Re8x7tby/57OtDzuFH9f9WH1JpOZf5ZDE8mauMN44IE=; b=IejbWCAqIlVTvG7KyfwI5N1FSkAEZ5IzDdZL50S1JPNmMsUDAzJE5CWWE5vZgkKKpHVijO1pACxZ6NHF/caLuhBiBwcgYGtYRnvVI/xkK5AHbMi7EVCwTa4lizHLhXzZvgBPTt9AmODVBpmBUejvRcoHcmq6mGdCfR7EK5uevbk= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) by VI1P189MB0527.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:30::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.26; Mon, 11 May 2020 16:48:01 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::5db5:cc81:e984:7c27]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::5db5:cc81:e984:7c27%7]) with mapi id 15.20.2979.033; Mon, 11 May 2020 16:48:01 +0000 To: Jim Schaad References: <008001d5fb12$c1d36f20$457a4d60$@augustcellars.com> Cc: 'Ace Wg' From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: <2dd400e8-a9b7-2996-39f3-6e1fb45a2e41@ri.se> Date: Mon, 11 May 2020 18:47:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 In-Reply-To: <008001d5fb12$c1d36f20$457a4d60$@augustcellars.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PtUd5E7eKDQG4IwY5u9BYAXYe3JDEjImi" X-ClientProxiedBy: HE1PR05CA0243.eurprd05.prod.outlook.com (2603:10a6:3:fb::19) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.8.13] (213.232.87.177) by HE1PR05CA0243.eurprd05.prod.outlook.com (2603:10a6:3:fb::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.26 via Frontend Transport; Mon, 11 May 2020 16:48:00 +0000 X-Originating-IP: [213.232.87.177] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 85bc98aa-f3fa-428d-d590-08d7f5cb113f X-MS-TrafficTypeDiagnostic: VI1P189MB0527: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 04004D94E2 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: y/+pmvz05daAa9fu6opfSbXLeLbvGNHfgwknr5Uv3c8Od7MC0/AcM3mWyiq0X5LcFw23DyRWCsnhk1XATit9UDMTE7pvU7H8Yg5ENe+57T4EXtWxtLL1EKjaIdJ5rVVuKSUup/IbJqU/5g8Bpc0Nz4XsftnLmQ1pARYDvfifJvKvNuHdmmJmuodFhWf6ktu+QlWN48IiygfWRscbhtZUJAGDeWGWWtq4Dr67LclKBY9NSalyTjJQbgxOlXS1HPLvYgtnCnZonRLHtMESnYMo9WojKuUYVKt+OfXvKXSNk1dldA/fJ7/0txKLBPQw813bHmJ/g3TKJ0fsGtt+FTXa+ZFCWQiAK1oSJ/zG1jBVwjDqYsc4/yAf3vsgfpXakRta4oPiZzBx2hCoM7kffzoYST2y3C6yCcgvKSarEfb5stEO8oTm2zGYEQsgr7s0s0vD6rosnNrWUvVLD8f7Vrqv38ru3JogrUcyziOhWCsKX5IXAbHodnkUHgIqYXXKBZ+Q1J2IytGepr+0r9i0Smoa/qOVqlDAV7iHaZIA0IsdsBQ1VwP6a74NaucT8n4Gm4QDJWNInVf4RXr5IzJ1EftbJSeipcCAW2PkJwaEQrPZroWV5sgfRX8BqLPi1kEnwgumiSG8ewsibfGC85JCI1683w== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1P189MB0398.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(376002)(346002)(396003)(39860400002)(366004)(33430700001)(66946007)(30864003)(66574014)(316002)(8676002)(5660300002)(16576012)(8936002)(6666004)(16526019)(26005)(186003)(4326008)(166002)(36756003)(966005)(478600001)(53546011)(33964004)(52116002)(33440700001)(2906002)(956004)(31686004)(31696002)(2616005)(66476007)(235185007)(21480400003)(66556008)(6916009)(44832011)(86362001)(6486002)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: iLMLWRpgBAluDPRAHR0Hzv7Hdq3GFuFAx9mC+AtfpZ0ezD51+5aoKrhIe1xKTPMjny6axe0KovuPspHnGGT1iMND5AoM9jeg7ILleZjcGUmGDMC338ny31OuKCX2OVqLsIde2+gy7Co4gvPo9TS7CG74pYXTIxRos3uxzosecjfRMyJNbV7K6dgpiT0ZYc7jG6KMxiTzVO3pTRN/i1xb9ICouC35Sa7RHud1jD6CqriGoes0wGHKWZj4L7VGt/qierghJkpFxIuEQBQlIqiP68C7Ow+jZaS8Goaer5NSA8bWFWu0E5izRlOIYwTTu/oGFXHgfd9RxUgKBsR5qTxq2/1kWyNNIIX72ee3MxlIFnv9DZWSfJzPa0xgG/On9Jfgb9TDgGTvaDmJ72cUA1ku4zJ1x4wIw7geFBQi8bZxDyU6/At/s2YS+XQ1Yq9noI7vql2c48XoSdTwrx/w5rRaWqEFdY9nKO2bTcfpBCWb/W0= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 85bc98aa-f3fa-428d-d590-08d7f5cb113f X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 May 2020 16:48:01.6214 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: xH7WY1hhG/EJcPWLmhnsCgFpwkvkfN94r+gk3ybAkTgFDrDgOrMK2sndJeLe/cQTcMz/V2QFjQ6Kr5+zF3Q2FQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0527 Archived-At: Subject: Re: [Ace] FW: Review of draft-ietf-ace-key-groupcomm-oscore-05 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 11 May 2020 16:48:14 -0000 --PtUd5E7eKDQG4IwY5u9BYAXYe3JDEjImi Content-Type: multipart/mixed; boundary="Z1k2GMZH2kTkUVEOzZX3CrjbKBiKcv1Nz" --Z1k2GMZH2kTkUVEOzZX3CrjbKBiKcv1Nz Content-Type: multipart/alternative; boundary="------------E2924A2982ACF92ABE497D84" Content-Language: en-US This is a multi-part message in MIME format. --------------E2924A2982ACF92ABE497D84 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Jim, The latest version -06 submitted today should have addressed all your comments below. https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore-06 Please, see replies inline. Thanks a lot for this review! Best, /Marco On 2020-03-15 22:43, Jim Schaad wrote: > Forgot to cc the group > > -----Original Message----- > From: Jim Schaad =20 > Sent: Sunday, March 15, 2020 1:48 PM > To: 'draft-ietf-ace-key-groupcomm-oscore@ietf.org' > > Subject: Review of draft-ietf-ace-key-groupcomm-oscore-05 > > * Introduction: In para 2, the second sentence needs to be re-written.= If > you remove the subclause, then you get "This relies on a Group Manager = where > members exchange CoAP messages secured with Group OSCORE." Which is w= rong. =3D=3D>MT We have rephrased the text as: =E2=80=9CThis relies on a Group Manager, w= hich is responsible for managing an OSCORE group, and enables the group members to exchange CoAP messages secured with Group OSCORE.=E2=80=9D <=3D=3D > > * Section 2 - The following is a problematic statement " All communica= tions > between the involved entities rely on the CoAP protocol and MUST be > secured." For something like MQTT you want to be able to do it in JSON= /HTTP =3D=3D>MT Rephrased as: =E2=80=9CAll communications between the involved entities M= UST be secured.=E2=80=9D <=3D=3D > > * Section 2.2 - I think it might be worthwhile in para 3 to give the re= ason > for needing a new group identifier - This is because of the conflict in= name > between group identifier of OSCORE and group identifier of > ace-key-groupcomm. You have not yet stated that they are different thi= ngs. =3D=3D>MT Now the first bullet point on the Gid clarifies that it is OSCORE-related information, and highlights the difference from the group name in Section 1.1. <=3D=3D > > * Section 3.1 - I think I said this before but ["requester", "monitor"]= > seems to be a bit of an oxymoron. Anybody who is either a requester or= a > responder can be a monitor without advertising the fact. =3D=3D>MT We have removed this combination of roles. It=E2=80=99s true that if the joining node is requester or requester+moni= tor , it has in either case to provide its own public key and may want to retrieve the other members=E2=80=99. So there is no difference in terms o= f key provisioning either. <=3D=3D > > * Section 3.1 - The table in figure 1 is currently not usable due to t= he > definition of scope in ace-key-groupcomm. =3D=3D>MT This should now be fine, since Section 3.1 of ace-key-groupcomm is admitting flexibility in the encoding of group name and roles, left to the application profile as per REQ1 and REQ2. In this document, REQ1 is defining group names to be encoded as CBOR text strings, while REQ2 is defining roles to be encoded as abbreviating CBOR integers. <=3D=3D > > * Section 3.1 - The framework allows for the scope and the audience to = be > implicit for an endpoint that is only doing one thing. Are you sure yo= u > want to eliminate that option? =3D=3D>MT Right. In the revised text, we don=E2=80=99t mention =E2=80=98audience=E2= =80=99 anymore, while we detail the content of =E2=80=98scope=E2=80=99 if present. <=3D=3D > > * Section 4 - I think you probably want to justify the reason for chan= ging > the base name of the resource. Also the same comments that I made in > ace-key-groupcomm about registering as a well-known are going to exist = if > you really want it to be fixed. =3D=3D>MT That was an oversight. The segment group-manager/ was supposed to be group-oscore/ , as in the operations described in the following sections.= On the second part of the comment, this resource just inherits the Interface Description (if=3D) Link Target Attribute value =E2=80=9Cace-gr= oup=E2=80=9D introduced in Section 4.1 of ace-key-groupcomm and registered in Section 8.9 of that same document. <=3D=3D > > * Section 5.2 - scope should not be a mandatory element in the request = - it > is implicit in the path name and the scope in the token. =3D=3D>MT Ok, we have made scope optional in the joining request, by simply not mentioning it anymore. Then the MAY contain from ace-key-groupcomm applies here. The last path segment is fine for the GM to understand the group at hand, then the corresponding allowed roles are also retrievable from the stored token claims. <=3D=3D > > * Section 5.2.1 - Is this a place where we need to look at replay? I = don't > think so because of the cryptographic wrapper, but we need to have that= > discussion in the document. Which indicates a pointer from this sectio= n to > where that discussion is. =3D=3D>MT At the end of the section, we have added a pointer to the new Section 17.3, whose content was already included as part of Section 17.2. <=3D=3D > > * Section 5.4 - cs_alg should refer to the IANA registries not the COSE= > document - what if there is a new signature algorithm, like say RSA. =3D=3D>MT Done. <=3D=3D > > * Section 6 - is it an error for a monitor to provide a public key? Af= ter > all an invalid signature would not need to be checked. To make life e= ven > more fun, does the rsnonce need to be provided on a token post? =3D=3D>MT We have added text under the first bullet point, to explain that it is not an error, and the Group Manager just silently ignores =E2=80=98cnonce= =E2=80=99, =E2=80=98client_cred=E2=80=99 and =E2=80=98client_cred_verify=E2=80=99, i= n case the joining node has =E2=80=9Cmonitor=E2=80=9D as single authorized role. As to the second question, we have also added some text in Section 5.1. That is, when responding to a Token POST, the Group Manager does not need to return 'kdcchallenge' (was rsnonce) to the client, if =E2=80=98sc= ope=E2=80=99 in the posted Access Token indicates only the role =E2=80=9Cmonitor=E2=80=9D= or only the role =E2=80=9Cverifier=E2=80=9D, for each of the specified groups. The fi= nal choice to take advantage of this optimization is left to the implementor. <=3D=3D > > * Section 8 - For bullet 2.a - Is there a reason why this does not do t= he > rekey and return the new key material rather than returning an error? =3D=3D>MT Ok, we have rephrased the text as: =E2=80=9CThe Group Manager rekeys the = OSCORE group. That is, the Group Manager generates new group keying material (see Section 16) and replies to the group member with the same group rekeying message defined in Section 16, providing the new group keying material. Then, the Group Manager rekeys the rest of the OSCORE group, as discussed in Section 16.=E2=80=9D <=3D=3D > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --------------E2924A2982ACF92ABE497D84 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Jim,

The latest version -06 submitted today should have addressed all your comments below.

https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore-06=

Please, see replies inline. Thanks a lot for this review!

Best,
/Marco

On 2020-03-15 22:43, Jim Schaad wrote:= 
Forgot to cc the group

-----Original Message-----
From: Jim Schaad <ietf@augustcellars.com>=20
Sent: Sunday, March 15, 2020 1:48 PM
To: 'draft-ietf-ace-key-groupcomm-oscore@ietf.o=
rg'
<draft-ietf-ace-key-groupcomm-oscore@ietf.org&g=
t;
Subject: Review of draft-ietf-ace-key-groupcomm-oscore-05

* Introduction:  In para 2, the second sentence needs to be re-written.  =
If
you remove the subclause, then you get "This relies on a Group Manager wh=
ere
members exchange   CoAP messages secured with Group OSCORE." Which is wro=
ng.

=3D=3D>MT
We have rephrased the text as: =E2=80=9CThis relies on a Group Manage= r, which is responsible for managing an OSCORE group, and enables the gro= up members to exchange CoAP messages secured with Group OSCORE.=E2=80=9D<= /span>
<=3D=3D


* Section 2 -  The following is a problematic statement " All communicati=
ons
between the involved entities rely on the CoAP protocol and MUST be
secured."  For something like MQTT you want to be able to do it in JSON/H=
TTP

=3D=3D>MT

Rephrased as: =E2=80=9CAll communications between the involved enti= ties MUST be secured.=E2=80=9D

<=3D=3D


* Section 2.2 - I think it might be worthwhile in para 3 to give the reas=
on
for needing a new group identifier - This is because of the conflict in n=
ame
between group identifier of OSCORE and group identifier of
ace-key-groupcomm.  You have not yet stated that they are different thing=
s.

=3D=3D>MT
Now the first bullet point on the Gid clarifies that it is OSCORE-rel= ated information, and highlights the difference from the group name in Se= ction 1.1.
<=3D=3D


* Section 3.1 - I think I said this before but ["requester", "monitor"]
seems to be a bit of an oxymoron.  Anybody who is either a requester or a=

responder can be a monitor without advertising the fact.

=3D=3D>MT

We have removed this combination of roles.


It=E2=80=99s true that if the joining node is requester or requester+= monitor , it has in either case to provide its own public key and may wan= t to retrieve the other members=E2=80=99. So there is no difference in te= rms of key provisioning either.

<=3D=3D


* Section 3.1 -  The table in figure 1 is currently not usable due to the=

definition of scope in ace-key-groupcomm.

=3D=3D>MT

This should now be fine, since Section 3.1 of ace-key-groupcomm is = admitting flexibility in the encoding of group name and roles, left to th= e application profile as per REQ1 and REQ2.


In this document, REQ1 is defining group names to be encoded as CBOR = text strings, while REQ2 is defining roles to be encoded as abbreviating = CBOR integers.

<=3D=3D


* Section 3.1 - The framework allows for the scope and the audience to be=

implicit for an endpoint that is only doing one thing.  Are you sure you
want to eliminate that option?

=3D=3D>MT
Right. In the revised text, we don=E2=80=99t mention =E2=80=98audienc= e=E2=80=99 anymore, while we detail the content of =E2=80=98scope=E2=80=99= if present.
<=3D=3D


* Section  4 - I think you probably want to justify the reason for changi=
ng
the base name of the resource.  Also the same comments that I made in
ace-key-groupcomm about registering as a well-known are going to exist if=

you really want it to be fixed.

=3D=3D>MT

That was an oversight. The segment group-manager/ was supposed to b= e group-oscore/ , as in the operations described in the following section= s.


On the second part of the comment, this resource just inherits the In= terface Description (if=3D) Link Target Attribute value =E2=80=9Cace-grou= p=E2=80=9D introduced in Section 4.1 of ace-key-groupcomm and registered = in Section 8.9 of that same document.

<=3D=3D


* Section 5.2 - scope should not be a mandatory element in the request - =
it
is implicit in the path name and the scope in the token.

=3D=3D>MT
Ok, we have made scope optional in the joining request, by simply not= mentioning it anymore. Then the MAY contain from ace-key-groupcomm appli= es here.
The last path segment is fine for the GM to understand the group at h= and, then the corresponding allowed roles are also retrievable from the s= tored token claims. <=3D=3D


* Section 5.2.1 -  Is this a place where we need to look at replay?  I do=
n't
think so because of the cryptographic wrapper, but we need to have that
discussion in the document.  Which indicates a pointer from this section =
to
where that discussion is.

=3D=3D>MT
At the end of the section, we have added a pointer to the new Section= 17.3, whose content was already included as part of Section 17.2.=
<=3D=3D


* Section 5.4 - cs_alg should refer to the IANA registries not the COSE
document - what if there is a new signature algorithm, like say RSA.

=3D=3D>MT
Done.
<=3D=3D


* Section 6 - is it an error for a monitor to provide a public key?  Afte=
r
all an invalid signature would not need to be checked.   To make life eve=
n
more fun, does the rsnonce need to be provided on a token post?

=3D=3D>MT

We have added text under the first bullet point, to explain that it= is not an error, and the Group Manager just silently ignores =E2=80=98cn= once=E2=80=99, =E2=80=98client_cred=E2=80=99 and =E2=80=98client_cred_ver= ify=E2=80=99, in case the joining node has =E2=80=9Cmonitor=E2=80=9D as s= ingle authorized role.


As to the second question, we have also added some text in Section 5.= 1. That is, when responding to a Token POST, the Group Manager does not n= eed to return 'kdcchallenge' (was rsnonce) to the client, if =E2=80=98sco= pe=E2=80=99 in the posted Access Token indicates only the role =E2=80=9Cm= onitor=E2=80=9D or only the role =E2=80=9Cverifier=E2=80=9D, for each of = the specified groups. The final choice to take advantage of this optimiza= tion is left to the implementor.

<=3D=3D


* Section 8 - For bullet 2.a - Is there a reason why this does not do the=

rekey and return the new key material rather than returning an error?

=3D=3D>MT
Ok, we have rephrased the text as: =E2=80=9CThe Group Manager rekeys = the OSCORE group. That is, the Group Manager generates new group keying m= aterial (see Section 16) and replies to the group member with the same gr= oup rekeying message defined in Section 16, providing the new group keyin= g material. Then, the Group Manager rekeys the rest of the OSCORE group, = as discussed in Section 16.=E2=80=9D
<=3D=3D




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


--=20
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistag=C3=A5ngen 16
SE-164 40 Kista (Sweden)

Phone: +46 (0)70 60 46 501
https://www=
=2Eri.se
--------------E2924A2982ACF92ABE497D84-- --Z1k2GMZH2kTkUVEOzZX3CrjbKBiKcv1Nz-- --PtUd5E7eKDQG4IwY5u9BYAXYe3JDEjImi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl65gbcACgkQ7iZktA5Y 2kPf4Af+JPowB6v2qYhbzJDoBE09SlCthJxu+8zoGNKL6YgHHJsFxNiPdQwReDVp 7NhKo4zgju0Iw8tSxJXqgYpuVZ/dU2sIBgdFOLFhCV/wLbWKX7Fiaj5ws+Ser48G vYheEnocggTiypTHRQjLFM41GJZ1ru1M/M9DMvj++ZKFX170wCWOCl62xSwS4jyP sv6+PcM61fq5OKzZkrF5DugOzDFO/NXgXJ/r8GWcj+aPmmXMi6wfu6UifZV+EoPn AndaWqiCROQbxAdqJ3V16lL1pmW6u0mXz+/ipztaR+J3jTtT/CB0bElrQMjm8z7Y E0+xEzVbQCqBKkmni1epF0rJVWmSkQ== =3eYn -----END PGP SIGNATURE----- --PtUd5E7eKDQG4IwY5u9BYAXYe3JDEjImi-- From nobody Wed May 13 09:08:42 2020 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1EE3A1079; Wed, 13 May 2020 09:08:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.130.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <158938612045.18743.6550353162888279128@ietfa.amsl.com> Date: Wed, 13 May 2020 09:08:40 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-dtls-authorize-10.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 16:08:41 -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 WG of the IETF. Title : Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) Authors : Stefanie Gerdes Olaf Bergmann Carsten Bormann Göran Selander Ludwig Seitz Filename : draft-ietf-ace-dtls-authorize-10.txt Pages : 26 Date : 2020-05-13 Abstract: This specification defines a profile of the ACE framework that allows constrained servers to delegate client authentication and authorization. The protocol relies on DTLS version 1.2 for communication security between entities in a constrained network using either raw public keys or pre-shared keys. A resource- constrained server can use this protocol to delegate 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-ietf-ace-dtls-authorize/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-dtls-authorize-10 https://datatracker.ietf.org/doc/html/draft-ietf-ace-dtls-authorize-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-dtls-authorize-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 13 09:11:35 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF3D23A1108 for ; Wed, 13 May 2020 09:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 zxr33b4QMrns for ; Wed, 13 May 2020 09:11:27 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C87B3A1079 for ; Wed, 13 May 2020 09:11:27 -0700 (PDT) Received: from wangari.tzi.org (p54BDED4C.dip0.t-ipconnect.de [84.189.237.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49Mfms4cDyzyRg for ; Wed, 13 May 2020 18:11:25 +0200 (CEST) From: Olaf Bergmann To: ace@ietf.org References: <158938612045.18743.6550353162888279128@ietfa.amsl.com> Date: Wed, 13 May 2020 18:11:25 +0200 In-Reply-To: <158938612045.18743.6550353162888279128@ietfa.amsl.com> (internet-drafts's message of "Wed, 13 May 2020 09:08:40 -0700") Message-ID: <87r1vnn7bm.fsf@wangari> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-dtls-authorize-10.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 13 May 2020 16:11:34 -0000 Dear ACE working group, we now have submitted version -10 of the DTLS profile draft, including the recent comments from Ben's review (see separate emails). Gr=C3=BC=C3=9Fe Olaf internet-drafts@ietf.org writes: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Authentication and Authorization for Con= strained Environments WG of the IETF. > > Title : Datagram Transport Layer Security (DTLS) Profil= e for Authentication and Authorization for Constrained Environments (ACE) > Authors : Stefanie Gerdes > Olaf Bergmann > Carsten Bormann > G=C3=B6ran Selander > Ludwig Seitz > Filename : draft-ietf-ace-dtls-authorize-10.txt > Pages : 26 > Date : 2020-05-13 > > Abstract: > This specification defines a profile of the ACE framework that allows > constrained servers to delegate client authentication and > authorization. The protocol relies on DTLS version 1.2 for > communication security between entities in a constrained network > using either raw public keys or pre-shared keys. A resource- > constrained server can use this protocol to delegate 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-ietf-ace-dtls-authorize/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ace-dtls-authorize-10 > https://datatracker.ietf.org/doc/html/draft-ietf-ace-dtls-authorize-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-dtls-authorize-10 > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Wed May 13 09:18:45 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2638E3A1027; Wed, 13 May 2020 09:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 9N5ipZr6akrf; Wed, 13 May 2020 09:18:32 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BB7E3A1024; Wed, 13 May 2020 09:18:31 -0700 (PDT) Received: from wangari.tzi.org (p54BDED4C.dip0.t-ipconnect.de [84.189.237.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49Mfwy2r3XzysZ; Wed, 13 May 2020 18:18:26 +0200 (CEST) From: Olaf Bergmann To: Benjamin Kaduk Cc: ace@ietf.org, draft-ietf-ace-dtls-authorize.all@ietf.org References: <20200102234020.GI35479@kduck.mit.edu> <87pnca9gyx.fsf@wangari> <20200429011210.GC27494@kduck.mit.edu> Date: Wed, 13 May 2020 18:18:25 +0200 In-Reply-To: <20200429011210.GC27494@kduck.mit.edu> (Benjamin Kaduk's message of "Tue, 28 Apr 2020 18:12:10 -0700") Message-ID: <87mu6bn6zy.fsf@wangari> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 13 May 2020 16:18:44 -0000 Hi Ben, Benjamin Kaduk writes: > Please go ahead and upload a new version to the datatracker when you get a > chance; I do have some further comments below. Thanks again for the detailed response. I have just submitted version -10 that includes changes to your previous comments as well as the suggestions below: > On Tue, Apr 14, 2020 at 06:20:38PM +0200, Olaf Bergmann wrote: >> Ben, >>=20 >> Thanks again for the thorough review of the ACE DTLS profile and my >> sincere apologies for the long time it took to process. Please find our >> comments inline. As this comprises a lot of changes, the proposed text >> already has been included in the Editor's copy [1]. Our proposals for >> new text are in the section-by-section comments. >>=20 >> [1] https://ace-wg.github.io/ace-dtls-profile/ >>=20 >> Benjamin Kaduk writes: >>=20 >> > Hi all, >> > >> > Some high-level remarks before delving into the section-by-section >> > comments: >> > >> > This document is pretty clearly DTLS 1.2-specific -- it talks about >> > particular protocol messages, message fields, and cipher suites that >> > simply do not apply to DTLS 1.3. In order to use this profile with DT= LS >> > 1.3, we'd need to specify the analogous behavior/requirements to these >> > (including standalone signature schemes and key-exchange groups, which >> > are now both separately negotiated from the cipher suite). >> > Given that DTLS 1.3 is past WGLC and only a few documents behind this >> > one in my review queue, it seems fairly prudent to spend some time and >> > cover how DTLS 1.3 would work here, since otherwise this document will >> > become stale shortly after (or even before!) its publication as an RFC. >> > >> > There's probably some additional discussion to include about the usage= of >> > key identifiers in this document versus the potential uses described in >> > the core framework. Specifically, the framework reminds us that "no >> > assumptions should be made that it is unique in the domains of either >> > the client or the RS" yet this document is using the kid as input to a >> > KDF that produces keys that must be unique across all clients, and >> > allowing live/instant authorization updates based on matching "kid". >> > How shall we resolve this apparent conflict? >> > >> > We also are potentially in violation of the framework's requirements >> > with respect to the independent selection of profiles for client/AS and >> > client/RS interactions -- at present, when DTLS+RPK is used for >> > client/RS, we require that DTLS+RPK is also used for client/AS, in ord= er >> > to prove possession of the key. We could perhaps weasel our way out by >> > saying that the framework's requirement applies at the profile >> > granularity, and with symmetric PSK we can be fully independent, but we >> > still need to say something about this property and the interaction wi= th >> > the framework's requirements. >> > >> > This profile is mostly applicable to the client/RS communications and >> > feels like it only provides some of the picture for use with client/AS >> > interactions. (It doesn't really say much of anything about RS/AS >> > interactions.) The introductory discussion does not do a great job of >> > painting that picture, and I'd like to see it more clearly introduced >> > that the bulk of our coverage is for the client/RS interaction. We al= so >> > lean heavily on the existing out-of-band configuration and key material >> > shared between client and AS to secure the client/AS communications; we >> > could probably tighten up the discussion about exactly what parameters >> > of client/AS communication are specified by this profile. >>=20 >> The introduction has been revised according to your suggested text, see >> below. We also have included some text on the out-of-band configuration >> in a new subsection in the security considerations. The important thing >> here really are the client/RS and client/AS interactions. Regarding >> client/AS, much of this is out of scope as there are certain >> OAuth-related assumptions on how these entities get in touch with each >> other; neither the framework nor the profile can do much about it >> without creating a new enrollment protocol. Regarding the RS/AS >> interaction, there is normative language that describes what each of >> these entities needs to do in each protocol step covered by the >> document. The necessary out-of-band configuration again is described in >> the new subsection in the security considerations as well as some >> clarifications in the text, see below. >>=20 >> > We do not say anything about DTLS session resumption (or renegotiation, >> > though not talking about that one is perfectly fine); that's a fairly >> > core DTLS concept that we should give some guidance on. >>=20 >> Not sure if we really need to but if you think this is necessary, we can >> comment on this, of course. > > I think we need to give some guidance about what the semantics are if/when > it happens. My inclination would be to say that DTLS resumption can be > used to amortize the cost of a handshake, but DTLS 1.2 resumption does not > provide forward secrecy and also does not provide an opportunity for the > client to prove possession of the PoP key, so servers will want to > periodically force a full handshake according to their authentication > requirements. I'd also be inclined to forbid renegotiation entirely. True, especially because RFC 7925 requires resumption to be implemented. The security considerations now advise against session resumptions and renegotiation as you have suggested. The Security Considerations section now has been structured in sub-sections for clarity. >> > Looking through Appendix C ("Requirements on Profiles") of the >> > framework, do we want to say anything about: >> > >> > - using the client credentials grant with this profile, as that's IIRC >> > the only example we show >>=20 >> Do you think we need to say anything here? The actual grant used to >> make the client known to the AS is out of scope for the profile as >> long as the requirements given here are met. > > I don't think we strictly need to, no. > >> > - require that DTLS be used in a mode that provides replay protection >>=20 >> Added as a requirement in Section 2. >>=20 >> > - when the client uses the authz-info endpoint instead of the >> > "psk_identity" field to convey the token to the RS, how does the RS >> > know which client is connecting (and thus what PSK to use), and what >> > does the client actually *put* in the "psk_identity" field? (The >> > other aspects of "how to select a proof-of-possession protocol" seem >> > to fall out naturally from the DTLS usage.) >>=20 >> We have included more explanatory text in section 3.3.1 on how this is >> supposed to work. > > It looks like we now say the client "MUST include an access token that > indicates the kid contained in the uploaded access token as psk_identity", > which seems to be talking about two different access tokens. Is one of > them uploaded to authz-info and the other used to populate the > "psk_identity" field? The following sentences seem to imply that, but the > quoted sentence is hard to parse. Perhaps just "The client then needs to > indicate during the DTLS handshake which previously uploaded access token > it intends to use." That proposed text drops the "MUST", so maybe we wou= ld > want to put that back in the later sentence(s). Agreed. The text now reads: OLD: The client then MUST include an access token that indicates the `kid` contained in the uploaded access token as `psk_identity`. To do so, it creates=E2=80=A6 NEW: The client then needs to indicate during the DTLS handshake which previously uploaded access token it intends to use. To do so, it MUST create=E2=80=A6 >> > - whether/how introspection is used? >>=20 >> We have added text stating that token introspection may be used but is >> out of scope for the profile spec. >>=20 >> > - give more details of what this profile mandates when used for >> > client/AS interactions (as mentioned above) >>=20 >> This should be covered now, see detailed responses below. >>=20 >> > - explicitly state that the authz-info endpoint is unprotected (or that >> > it might be protected if, e.g., the RS has a trustable certificate >> > that would be used instead of RPK or PSK, or by supplying the >> > token as the "psk_identity" when symmetric PoP is used, or by only >> > doing server-authentication with RPK as known by the client by the >> > rs_cnf access information >>=20 >> I am not sure which security gain we would yield by trustable >> certificates: The client does not need to authenticate the resource >> server for the authz-info upload. The important aspect here is that the >> access token must be integrity-protected by the AS and encrypted if it >> contains information to be kept confidential (esp. a shared secret but >> possibly other data as well). We have added some text on this to the >> security considerations. > > It looks like this will be enough to meet the requirements from the > framework (though I'm not looking at an actual diff so I'm not 100% sure). > >> > And now, on to the section-by-section comments. >> > >> > Section 1 >> > >> > a DTLS session. The communication between client and authorization >> > server may also be secured with DTLS. This specification supports >> > DTLS with Raw Public Keys (RPK) [RFC7250] and with Pre-Shared Keys >> > (PSK) [RFC4279]. >> > >> > [DTLS 1.3 will inherit TLS 1.3's built-in support for (so-called >> > "external") PSKs.] >>=20 >> (See general discussion on wether DTLS 1.3 needs to be addressed at this >> time.) >>=20 >> > The DTLS handshake requires the client and server to prove that they >> > can use certain keying material. In the RPK mode, the client proves >> > with the DTLS handshake that it can use the RPK bound to the token >> > and the server shows that it can use a certain RPK. The access tok= en >> > must be presented to the resource server. For the RPK mode, the >> > access token needs to be uploaded to the resource server before the >> > handshake is initiated, as described in Section 5.8.1 of the ACE >> > framework [I-D.ietf-ace-oauth-authz]. >> > >> > This seems to be making some implicit assumptions about the message fl= ow >> > that have not yet been covered by this document and are only somewhat >> > covered by the core framework spec. I'd propose: >> > >> > % The ACE framework requires that client and server mutually >> > % authenticate each other before any other protocol exchanges take >> > % place. >>=20 >> Actually, this is not true: The client can upload data to the >> resource server's authorization endpoint without authentication. I >> suggest to rephrase this as "The ACE framework requires that client >> and server mutually authenticate each other before any application >> data is exchanged.", see below. > > Good catch, thanks! > >> > % In order for DTLS to provide mutual authentication, both >> > % client and server must prove their ability to use certain keying >> > % material (tied to the authenticated identity) as part of the DTLS >> > % handshake. The AS assists in this process by incorporating key >> > % material (or information about key material) into the access token, >> > % which is considered a "proof of possession" token. In the RPK mode, >> > % the client proves that it can use the RPK bound to the token and the >> > % server shows that it can use a certain RPK (as indicated by the AS = to >> > % the client). The resource server needs access to the token in order >> > % to complete this exchange. For the RPK mode, the access token needs >> > % to be uploaded to the resource server before the handshake is >> > % initiated, as described in Section 5.8.1 of the ACE framework >> > % [I-D.ietf-ace-oauth-authz]. >> > >> > though I recognize that my text tends to be a bit more verbose than is >> > strictly needed, so please feel free to edit it down. >>=20 >> We propose the following change: >>=20 >> OLD: >>=20 >> The DTLS handshake requires the client and server to prove that they >> can use certain keying material. In the RPK mode, the client proves >> with the DTLS handshake that it can use the RPK bound to the token >> and the server shows that it can use a certain RPK. The access token >> must be presented to the resource server. For the RPK mode, the >> access token needs to be uploaded to the resource server before the >> handshake is initiated, as described in Section 5.8.1 of the ACE >> framework {{I-D.ietf-ace-oauth-authz}}. >>=20 >> NEW: >>=20 >> The ACE framework requires that client and server mutually >> authenticate each other before any application data is exchanged. >> DTLS enables mutual authentication if both client and server prove >> their ability to use certain keying material in the DTLS handshake. >> The authorization server assists in this process on the server side >> by incorporating keying material (or information about keying >> material) into the access token, which is considered a "proof of >> possession" token. >>=20 >> In the RPK mode, the client proves that it can use the RPK bound to >> the token and the server shows that it can use a certain RPK (as >> indicated by the authorization server to the client). >>=20 >> The resource server needs access to the token in order to complete >> this exchange. For the RPK mode, the client must upload the access >> token to the resource server before initiating the handshake, as >> described in Section 5.8.1 of the ACE framework >> {{I-D.ietf-ace-oauth-authz}}. > > This looks good. > >> > Section 2 >> > >> > The CoAP-DTLS profile for ACE specifies the transfer of >> > authentication information and, if necessary, authorization >> > information between the client (C) and the resource server (RS) >> > during setup of a DTLS session for CoAP messaging. It also specifi= es >> > how C can use CoAP over DTLS to retrieve an access token from the >> > authorization server (AS) for a protected resource hosted on the >> > resource server. >> > >> > I suggest reiterating that "As specified in Section 6.7 of >> > [I-D.ietf-ace-oauth-authz], use of DTLS for one or both of these >> > interactions is completely independent". >>=20 >> done >>=20 >> > To determine the AS in charge of a resource hosted at the RS, C MAY >> > send an initial Unauthorized Resource Request message to the RS. T= he >> > >> > This is part of the core framework, so the "MAY" may be overkill. >> > (Lowercase "can" would do just fine.) >>=20 >> done >>=20 >> > Once the client knows the authorization server's address, it can se= nd >> > an access token request to the token endpoint at the AS as specified >> > >> > Hmm. There's some level of "the client needs to have already been >> > configured that that AS is a valid AS" verification that's done here, >> > but I'm not sure if that's too much detail to include at this stage >> > (since we're really just summarizing the framework here). >>=20 >> Yes, there has been a discussion on this. The issue with this three >> corner model is that the client needs a pretty tight relationship with >> the AS, meaning that it must be able to recognize an AS depicted in the >> AS Request Creation Hints as trustworthy. >>=20 >> > in [I-D.ietf-ace-oauth-authz]. As the access token request as well >> > as the response may contain confidential data, the communication >> > between the client and the authorization server MUST be >> > >> > (This "MUST" is already a requirement from the core framework, so we >> > don't necessarily need to repeat it as normative language.) >>=20 >> Okay, changed to lower case. >>=20 >> > confidentiality-protected and ensure authenticity. C may have been >> > registered at the AS via the OAuth 2.0 client registration mechanism >> > as outlined in Section 5.3 of [I-D.ietf-ace-oauth-authz]. >> > >> > Section 5.3 of oauth-authz says that registration is "out of scope"; is >> > this still the right reference? >>=20 >> It is the correct reference but unfortunately, Section 5.3 of the >> framework document just says that "Authentication of the client is >> mandatory". The issue here is that the framework as well as OAuth >> requires a prior registration of the client. Otherwise, the AS would not >> be able to authorize the client in the three corner model. Not including >> the reference would mean to repeat the requirement of client >> registration here. > > Okay. > >> > [I-D.ietf-ace-oauth-authz]. In case the client uses a symmetric >> > proof-of-possession key in the DTLS handshake, the procedure as abo= ve >> > MAY be used, or alternatively, the access token MAY instead be >> > transferred in the DTLS ClientKeyExchange message (see >> > Section 3.3.1). >> > >> > (This is not DTLS 1.3-compatible.) >>=20 >> Agreed. This would need a change if we decided to add-in support for >> DTLS 1.3. >>=20 >> > Section 3 >> > >> > secured. Depending on the used CoAP security mode (see also >> > Section 9 of [RFC7252], the Client-to-AS request, AS-to-Client >> > response and DTLS session establishment carry slightly different >> > information. [...] >> > >> > At this point in the document it's pretty unclear what "Client-to-AS >> > request", "AS-to-Client response", and "DTLS session establishment" are >> > and how they relate to each other. >>=20 >> The "Client-to-AS request" and "AS-to-Client response" are introduced by >> the ACE framework document. Maybe an explicit reference helps to avoid >> confusion. >>=20 >> OLD: >>=20 >> Depending on the used CoAP security mode (see also Section 9 of >> {{RFC7252}}, the Client-to-AS request, AS-to-Client response and DTLS >> session establishment carry slightly different >> information. {{rpk-mode}} addresses the use of raw public keys while >> {{psk-mode}} defines how pre-shared keys are used in this profile. >>=20 >> NEW: >>=20 >> Depending on the used CoAP security mode (see also Section 9 of >> {{RFC7252}}, the Client-to-AS request, AS-to-Client response (see >> Section 5.6 of {{I-D.ietf-ace-oauth-authz}}) and DTLS session >> establishment carry slightly different information. {{rpk-mode}} > > Thanks! > >> > Also, it seems like the behavior in Section 3.2 and 3.3 are relating to >> > the mode used for the client/RS interactions, which relates to the >> > client/AS interactions only in the form of how PoP information is bound >> > to/with the token. >>=20 >> I am not sure if there is anything else to say about the client/AS >> interactions that is not covered by the framework. >>=20 >> > Section 3.1 >> > >> > establish a secure communication channel. C MUST securely have >> > obtained keying material to communicate with AS. Furthermore, C MU= ST >> > verify that AS is authorized to provide access tokens (including >> > authorization information) about RS to C. Also, AS MUST securely >> > have obtained keying material for C, and obtained authorization rul= es >> > approved by the resource owner (RO) concerning C and RS that relate >> > to this keying material. [...] >> > >> > The way this is written right now, we're going to get lots of questions >> > from reviewers about "how does this happen?" and for more details about >> > it. We are effectively assuming that this stuff is all provisioned >> > already as part of the device configuration or during enrollment, we >> > should say something about these being requirements on device >> > provisioning, not on the operation of the ACE protocol. >>=20 >> The following new text has been added for clarification: >>=20 >> NEW: >>=20 >> This profile assumes that the keying material to secure this >> communication channel has securely been obtained either by manual >> configuration or in an automated provisioning process. > > Thanks! > >> > between C and AS is bootstrapped is not part of this document. C a= nd >> > AS MUST ensure the confidentiality, integrity and authenticity of a= ll >> > exchanged messages. >> > >> > I think this is also restating requirements from the core framework, a= nd >> > may not need normative language in this manner. >>=20 >> done >>=20 >> > Section 3.2 >> > >> > I know that the section heading says "RawPublicKey Mode" already, but >> > I'd recommend adding a sentence in the preface that repeats that "When >> > the client and RS use RawPublicKey authentication, the procedure is as >> > follows"; we might get complaints otherwise that we are saying that the >> > client MUST do things that are not universal requirements. >> > (Section 3.3 does already have something like this for the symmetric-k= ey >> > case.) >>=20 >> done >>=20 >> > previously made known to the authorization server. To prove that t= he >> > client is in possession of this key, C MUST use the same keying >> > material that it uses to secure the communication with AS, e.g., the >> > DTLS session. >> > >> > This seems in conflict with the core framework's requirement that the >> > client/AS profile and client/RS profile are severable. >>=20 >> This profile explicitly specifies the communication flow between C and >> AS on one side and between C and RS on the other. As both legs are part >> of this profile, there is no combination of profiles involved. In that >> regard, there is no such assumption as indicated in Section 6.7 of the >> framework. >>=20 >> *) https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-33#section-6= .7 >>=20 >> We could weaken the security here by removing the "To prove"-statement. >> However, it is advisable not to do this because by using the keying >> material in the C/AS communication, C shows that it is actually in >> possession of the respective private key. This would raise the bar for >> the client to retrieve access tokens in the name of other clients. >>=20 >> The preferred alternative would be replace MUST with SHOULD: >>=20 >> OLD: >>=20 >> previously made known to the authorization server. To prove that the >> client is in possession of this key, C MUST use the same keying >> material that it uses to secure the communication with AS, e.g., the >> DTLS session. >>=20 >> NEW: >>=20 >> previously made known to the authorization server. To prove that the >> client is in possession of this key, C SHOULD use the same keying >> material that it uses to secure the communication with AS, e.g., the >> DTLS session. > > That seems like it's going in the right direction, but I'm not sure it's > the precise change we want. Basically, we need to keep the requirement > that the client prove possession of the key, and we want the recommended > way to be to use it for DTLS with the AS, but we can't require that the > client use DTLS to talk to the AS, because we "MUST NOT depend on the > assumption that the profile is used for all the different types of > interactions". So perhaps > > NEWNEW: > > % previously made known to the authorization server. It is RECOMMENDED th= at > % C use DTLS with the same keying material to secure the communication wi= th > % AS, proving possession of the key as part of the token request, but oth= er > % mechanisms for proving possession of the key may be defined in the > % future. Done. >>=20 >> > AS MUST check if the client that it communicates with is associated >> > with the RPK in the cnf object before issuing an access token to it. >> > >> > Earlier in the section we noted a requirement to prove possession of t= he >> > key by using it in DTLS; why is there a separate "association" >> > requirement? >>=20 >> This is the same rationale as above. The AS needs some way to decide >> which authorization rules apply to the requesting client. There was a >> discussion on the mailing list that the client may use a different RPK >> in the communication with AS than it uses in the communication with the >> resource server. AS then must ensure two things: First, that the >> authorization decision coded into the access token applies to the RPK >> provided by C. Second, that the access token is transferred to the same >> C. >>=20 >> The following text has been added to the Security Considerations to >> explain the problems that arise from using different RPKs for the C/AS >> and C/RS communication: >>=20 >> NEW: >>=20 >> The authorization server must ascertain that the keying material >> for the client that it provides to the resource server actually is >> associated with this client. Malicious clients may hand over >> access tokens containing their own access permissions to other >> entities. This problem cannot be completely >> eliminated. Nevertheless, in RPK mode it should not be possible >> for clients to request access tokens for arbitrary public keys, >> since that would allow the client to relay tokens without the need >> to share its own credentials with others. The authorization server > > I think this sentence could probably be wordsmithed some more, though I > don't have a concrete proposal at the moment. It does seem like we might > want to discuss this scenario more in terms of "identity misbinding" than > "relay tokens", though. (We had a SAAG talk at IETF 104 about misbinding > attacks on device pairing, which is not quite the same, but shares some of > the concepts.) Okay. This is the only comment I did not yet address in the text. We might want to keep this in mind for -11. >> therefore should at some point validate that the client can >> actually use the private key corresponding to the client's public >> key. > > Why is this only "should", vs. (e.g.) "needs to"? I am perfectly happy with the stronger "needs to" and changed the text accordingly. > >>=20 >> > also, nit: "The AS". >>=20 >> done >>=20 >> > which case it does not have to be sent. The response also contains >> > an access token and an "rs_cnf" parameter containing information >> > about the public key that is used by the resource server. AS MUST >> > >> > nit(?): is the "rs_cnf" parameter always mandatory? (Or only when >> > DTLS-RPK is used for client-RS interactions?) >>=20 >> Done as follows: >>=20 >> OLD: >>=20 >> The response also contains an access token and an "rs_cnf" >> parameter containing information about the public key that is used >> by the resource server. AS MUST ascertain that the RPK specified >> in "rs_cnf" belongs to the resource server that C wants to >> communicate with. >>=20 >> NEW: >>=20 >> The response also contains an access token with information about >> the public key that is used by the resource server. The > > This sounds like "the information[...]" is part of the access token; maybe > "along with"? What is meant here is that the information is contained in the access token. The misleading part is that the AT contains information about the client's RPK that the resource server uses to recognize the client in the subsequent communication. I have changed this sentence to: NEW: The response also contains an access token with information for the resource server about the client's public key. >> authorization server MUST return in its response the parameter >> "rs_cnf" unless it is certain that the client already knows the >> public key of the resource server. The authorization server MUST >> ascertain that the RPK specified in "rs_cnf" belongs to the resource >> server that the client wants to communicate with. >>=20 >> > nit: "The AS" again (and throughought, to a large extent). >>=20 >> [Okay, we will change these for I-D submission.] >>=20 >> > server that C wants to communicate with. AS MUST protect the >> > integrity of the token. If the access token contains confidential >> > data, AS MUST also protect the confidentiality of the access token. >> > >> > This requirement ("protect the integrity of the token") feels a little >> > underspecified, as it doesn't say protection over what workflow or who >> > will verify the integrity (the RS). >>=20 >> done, by adding >>=20 >> NEW: >>=20 >> to ensure that the resource server can detect unauthorized changes. >>=20 >> > C MUST ascertain that the access token response belongs to a certain >> > previously sent access token request, as the request may specify the >> > resource server with which C wants to communicate. >> > >> > nit: I recomment rewording "belongs to", perhaps as "corresponds to". >> > DTLS can provide this guarantee when configured to do so, though it is >> > not a guaranteed property from DTLS. >>=20 >> Changed to: >>=20 >> OLD: >>=20 >> C MUST ascertain that the access token response corresponds to a >> certain previously sent access token request,... >>=20 >> NEW: >>=20 >> the client MUST check if the access token response is bound to a >> certain previously sent access token request, >>=20 >> > We'll probably get some grief about the "access_token" contents in the >> > example not being valid CBOR, due to the parenthetical comment. We >> > could probably put a note in the preface that the value is truncated f= or >> > readability. Also, nit: "the client's" with article and apostrophe. >>=20 >> Okay. For now, I have put in a disclaimer into the description of the >> two examples where this occurs. > > Thanks! > >> > Section 3.2.1 >> > >> > Before the client initiates the DTLS handshake with the resource >> > server, C MUST send a "POST" request containing the new access token >> > to the authz-info resource hosted by the resource server. After the >> > client >> > >> > nit: we don't require single-use tokens, so "new" is probably overkill; >> > just "its access token" should suffice. >> > nit: formatting issue with spurious line break here. >>=20 >> done >>=20 >> > server. To use the RawPublicKey mode, the client MUST specify the >> > public key that AS defined in the "cnf" field of the access token >> > response in the SubjectPublicKeyInfo structure in the DTLS handshake >> > as specified in [RFC7250]. >> > >> > IIRC the access token response does not have to include a "cnf" field >> > (e.g., if the AS accepts the req_cnf from the request), so "defined in >> > the field of the response" doesn't seem like quite the right wording. >>=20 >> Done: >>=20 >> OLD: >>=20 >> To use the RawPublicKey mode, the client MUST specify the public >> key that AS defined in the `cnf` field of the access token response >> in the SubjectPublicKeyInfo structure in the DTLS handshake as >> specified in {{RFC7250}}. >>=20 >> NEW: >>=20 >> The client MUST use its correct public key in the DTLS >> handshake. If the authorization server has specified a `cnf` field >> in the access token response, the client MUST use this >> key. Otherwise, the client MUST use the public key that it >> specified in the `req_cnf` of the access token request. The client >> MUST specify this public key in the SubjectPublicKeyInfo structure >> of the DTLS handshake as described in [RFC7250]. >>=20 >> > An implementation that supports the RPK mode of this profile MUST at >> > least support the ciphersuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 >> > >> > I understand that making the full-width-tag ciphersuite MTI would >> > exclude some devices, though it feels like some recommendation to use >> > the full-length tag when possible would be appropriate. That said, I = do >> > see that RFC 7252 makes no such remark, and thus consistency would have >> > us not say anything either. >>=20 >> We have now included more text on the tag length in the Security >> Considerations, see below. > > Thanks; I think that text strikes a good balance. > >> > [RFC7251] with the ed25519 curve (cf. [RFC8032], [RFC8422]). >> > >> > Just to be clear: ed25519 is an ECDSA algorithm; the corresponding ECD= HE >> > operation is called x25519, and both algorithms make use of the >> > elliptical curve known as curve25519. Since we are using both ECDHE a= nd >> > ECDSA, it's probably simplest to just refer to "curve25519", though >> > mentioning both ed25519 and x25519 would also work. >>=20 >> This has been a WG decision at some point but the authors agree that >> curve25519 is the best to go for and propose the following change which >> also gets rid of the ugly note in favor of more coherent text: >>=20 >> OLD: >>=20 >> An implementation that supports the RPK mode of this profile MUST >> at least support the ciphersuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 >> [RFC7251] with the ed25519 curve (cf. [RFC8032], [RFC8422]). >>=20 >> NEW: >>=20 >> To be consistent with {{RFC7252}} which allows for shortened MAC >> tags in constrained environments, an implementation that supports >> the RPK mode of this profile MUST at least support the ciphersuite >> TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_CCM\_8 {{RFC7251}}. As discussed >> in {{RFC7748}}, new ECC curves have been defined recently that are >> considered superior to the so-called NIST curves. This specification >> therefore mandates implementation support for curve25519 >> (cf. {{RFC8032}}, {{RFC8422}}) as this curve said to be efficient >> and less dangerous regarding implementation errors than the >> secp256r1 curve mandated in {{RFC7252}}. >>=20 >> > RS MUST check if the access token is still valid, if RS is the >> > intended destination, i.e., the audience, of the token, and if the >> > token was issued by an authorized AS. The access token is >> > >> > nit: "i.e., the audience" is in effect a parenthetical, so using commas >> > to offset it inside a comma-separated list is potentially confusing; I= 'd >> > suggest using actual parentheses instead of commas around it. >>=20 >> done >>=20 >> > reference to this key. If the authorization server has no certain >> > knowledge that the Client's key is already known to the resource >> > server, the Client's public key MUST be included in the access >> > token's "cnf" parameter. If CBOR web tokens [RFC8392] are used as >> > recommended in [I-D.ietf-ace-oauth-authz], keys MUST be encoded as >> > specified in [I-D.ietf-ace-cwt-proof-of-possession]. RS MUST use t= he >> > >> > Is talking about """the access token's "cnf" parameter" consistent with >> > allowing the use of non-CWT (non-JWT) token formats? >>=20 >> This has been addressed by adding the following paragraph to the >> introduction: >>=20 >> NEW: >>=20 >> As recommended in Section 5.8 of [I-D.ietf-ace-oauth-authz], this >> specification uses CBOR web tokens to convey claims within an >> access token issued by the server. While other formats could be >> used as well, those are out of scope for this document. > > I think that will work; thanks. > >> > keying material in the handshake that AS specified in the rs_cnf >> > parameter in the access token. Thus, the handshake only finishes if >> > C and RS are able to use their respective keying material. >> > >> > I suggest being explicit about "the DTLS handshake with the client", >> > perhaps as "MUST use in the DLTS handshake with the client the keying >> > material that the AS specified in the rs_cnf parameter in the access >> > token". >>=20 >> Done, see next comment. >>=20 >> > The same caveat about "parameter in the access token" >> > applies here, though I guess there is an additional complication for >> > "rs_cnf" in that it's an token response parameter but I don't remember >> > that we say a huge amount about it also being included in the token >> > itself -- the token response is directed to the client but the token is >> > directed to the RS. >>=20 >> As we have found, the mailing list discussion concluded that the access >> token does not contain an rs_cnf claim at all. This occurrence most >> likely was an artefact. This now has been changed as follows: >>=20 >> OLD: >>=20 >> RS MUST use the keying material in the handshake that AS specified >> in the rs_cnf parameter in the access token. Thus, the handshake >> only finishes if C and RS are able to use their respective keying >> material. >>=20 >> NEW: >>=20 >> The resource server MUST use its own raw public key in the DTLS >> handshake with the client. If the resource server has several raw >> public keys, it must already know which key it is supposed to use >> with this client. How this is achieved is not part of this profile. >>=20 >> > Section 3.3 >> > >> > token. AS MUST check if the identifier refers to a symmetric key >> > that was previously generated by AS as a shared secret for the >> > communication between this client and the resource server. >> > >> > "What does the AS do if this check fails?" >>=20 >> The following text has been added to avoid additional roundtrips for the >> client: >>=20 >> NEW: >>=20 >> If no such symmetric key was found, the AS MUST generate a new >> symmetric key that is returned in its response to the client. > > :) > >> > The authorization server MUST determine the authorization rules for >> > the C it communicates with as defined by RO and generate the access >> > >> > nit: it's surprising to see "authorization server" spelled out in the >> > same sentence as "C" and "RO" (which, incidentally, we don't seem to u= se >> > in abbreviation form anywhere other than where we define it). >>=20 >> There has been some discussion about the short forms. We will >> harmonize this before submitting the next I-D version. > > Okay, thanks. > >> > wants to communicate with. Also, AS MUST protect the integrity of >> > the access token. If the token contains confidential data such as >> > the symmetric key, the confidentiality of the token MUST also be >> > protected. Depending on the requested token type and algorithm in >> > >> > (same comment about "protect the integrity" or "protect" as for the RPK >> > case.) >>=20 >> Done, by adding: >>=20 >> NEW: >>=20 >> to ensure that the resource server can detect unauthorized changes. >>=20 >> > that is to be used between C and the resource server. The access >> > token MUST be bound to the same symmetric key by means of the cnf >> > claim. >> > >> > Now we call it a "claim" rather than a "token parameter", but this aga= in >> > seems to be implicitly assuming CWT/JWT for tokens. >>=20 >> We distinguish between the (semantic) information conveyed by an access >> token of the syntactic description of data objects. To make this more >> explicit, we now have added some text in the Terminology section that >> refers to the same usage of the term 'claim' as in the framework >> document. > > Thank you! > >> > (Also, this "MUST" seems like something that the framework should >> > guarantee and not a new requirement that the DTLS profile imposes.) >>=20 >> As this as been a bit misleading as well, it has been rephrased as >> follows: >>=20 >> OLD: >>=20 >> The access token MUST be bound to the same symmetric key by means >> of the cnf claim. >>=20 >> NEW: >>=20 >> To convey the same secret to the resource server, the >> authorization server either includes it directly in the access >> token by means of the `cnf` claim or it provides sufficient >> information to enable the resource server to derive the key from >> the access token using key derivation. >>=20 >> > Figure 5: Example Access Token Request, symmetric PoP-key >> > >> > Maybe we could include "(implicit)" in the caption, since symmetric PoP >> > key is the default. >>=20 >> done >>=20 >> > An example access token response is illustrated in Figure 6. In th= is >> > >> > Is it accurate to say "A corresponding example access token response"? >> > It's nice to the reader if we can tie the examples together like that. >>=20 >> done >>=20 >> > Is the "Max-Age" usage in Figure 6 typical? (Also, similar comment >> > about having the parenthetical comment in the example body vs. preface= .) >>=20 >> New text was added as follows to clarify that inconsistencies with >> cached responses should be avoided. For a more realistic example, the >> value of Max-Age in the examples has been decreased to be sufficiently >> below expires_in: >>=20 >> NEW: >>=20 >> Caching proxies process the Max-Age option in the CoAP response >> which has a default value of 60 seconds (Section 5.6.1 of >> [RFC7252]). The authorization server SHOULD adjust the Max-Age >> option such that it does not exceed the `expires_in` parameter to >> avoid stale responses. >>=20 >> > token_type : pop, >> > >> > Didn't we switch this to being capitalized as "PoP"? >>=20 >> done >>=20 >> > "COSE_Encrypt0" structure. The AS MUST use the keying material >> > shared with the RS to encrypt the token. >> > >> > nit: I suggest s/shared with/it shares with/ >>=20 >> done >>=20 >> > We should probably say something about why the kid in Figure 7 is >> > different from the one in Figure 6. >>=20 >> As it seems more clear if both examples use the same kid, this now has >> been harmonized. >>=20 >> > 4.00 Bad Request >> > Content-Format: application/ace+cbor >> > Payload: >> > { >> > error : invalid_request >> > } >> > >> > Figure 8: Example Access Token Response With Reject >> > >> > RFC 6749's description of "invalid_request" seems to imply that it's >> > mostly about malformed requests, as opposed to the AS deciding that the >> > client is not authorized for any access to the requested resource (whi= ch >> > is maybe what's implied by the previous paragraph). This is not >> > necessarily a problem, but perhaps we could make the text and example >> > more consistent. >>=20 >> This example is actually about malformed requests (4.00). We now have >> added text to clarify this. > > Ah, looks good :) > >> > The method for how the resource server determines the symmetric key >> > from an access token containing only a key identifier is application >> > specific, the remainder of this section provides one example. >> > >> > nit: hyphenate "application-specific", and this is a comma splice. >>=20 >> done >>=20 >> > resource server. This key needs to be securely stored and processed >> > in the same way as the key used to protect the communication between >> > AS and RS. >> > >> > nit: is this better as "processed" or "protected"? >>=20 >> "processed" because this part is about the handling not the >> characteristics of the data. >>=20 >> > The fields in the context information "COSE_KDF_Context" >> > (Section 11.2 of [RFC8152]) have the following values: >> > >> > o AlgorithmID =3D "ACE-CoAP-DTLS-key-derivation" >> > >> > RFC 8152 says that these AlgorithmID values come from the COSE >> > Algorithms registry, which this does not (unless we register it there, >> > which we don't currently). Also, since the output is used directly for >> > DTLS PSK, I don't think the "key-derivation" portion is needed. >> > >> > o PartyUInfo =3D PartyVInfo =3D ( null, null, null ) >> > >> > (8152 seems to prefer "nil" over "null".) >> > >> > o keyDataLength needs to be defined by the application >> > >> > o protected MUST be a zero length bstr >> > >> > o other is a zero length bstr >> > >> > (These three are all members of the "SuppPubInfo" field, which is not >> > very clear from how we include them in the same list as top-level >> > fields.) >>=20 >> The example now has updated and rephrased according to HKDF usage. > > The formatting/discussion looks good, but I'll need to cross-check the da= ta > structures once the new revision is uploaded. > >> > Section 3.3.1 >> > >> > When a client receives an access token response from an authorizati= on >> > server, C MUST ascertain that the access token response belongs to a >> > certain previously sent access token request, as the request may >> > specify the resource server with which C wants to communicate. >> > >> > (Same bit about "belongs to".) >>=20 >> done >>=20 >> > If a resource server receives a ClientKeyExchange message that >> > contains a "psk_identity" with a length greater zero, it uses the >> > contents as index for its key store (i.e., treat the contents as key >> > >> > (This is not DTLS 1.3-compatible.) >>=20 >> See side discussion on DTLS versions. >>=20 >> > nits: "greater than", "as an index", "as a key identifier" >>=20 >> done >>=20 >> > identifier). The resource server MUST check if it has one or more >> > access tokens that are associated with the specified key. >> > >> > I don't understand this sentence -- isn't the access token the precise >> > contents of the "psk_identity" field, so that there would be a key >> > associated with the access token, not the other way around? >>=20 >> Now clarified that the psk_identity must contain the opaque access >> token: >>=20 >> OLD: >>=20 >> Alternatively, the client MAY provide the most recent access >> token in the `psk_identity` field of the ClientKeyExchange >> message. To do so, the client MUST treat the contents of the >> `access_token` field from the AS-to-Client response as opaque data >> and not perform any re-coding. >>=20 >> Note: >> As stated in Section 4.2 of [RFC7925], the PSK identity should be >> treated as binary data in the Internet of Things space and not >> assumed to have a human-readable form of any sort. >>=20 >> NEW: >>=20 >> As an alternative to the access token upload, the client can >> provide the most recent access token in the `psk_identity` field of >> the ClientKeyExchange message. To do so, the client MUST treat the >> contents of the `access_token` field from the AS-to-Client response >> as opaque data as specified in Section 4.2 of [RFC7925] and not >> perform any re-coding. This allows the resource server to retrieve >> the shared secret directly from the `cnf` claim of the access >> token. >>=20 >> > If no key with a matching identifier is found, the resource server >> > MAY process the contents of the "psk_identity" field as access token >> > >> > Similarly here, the causality feels reversed. >>=20 >> Hopefully, this has been sufficiently clarified by the previous >> comment. Moreover, the following change is proposed to emphasize the >> aforementioned behavior of RS. The access token now must always be >> parsed but may contain a kid for an already known key: > > I think I confused myself with the previous diff, but your description he= re > and the text in the editor's copy seem to make sense, so I'm willing to s= ay > that I got confused earlier and move on. > >> OLD: >>=20 >> If a resource server receives a ClientKeyExchange message that >> contains a `psk_identity` with a length greater than zero, it uses >> the contents as an index for its key store[...] >>=20 >> [...] session setup is terminated with an `illegal_parameter` DTLS >> alert message. >>=20=20=20=20 >> NEW:=20 >>=20 >> If a resource server receives a ClientKeyExchange message that >> contains a `psk_identity` with a length greater than zero, it MUST >> process the contents of the `psk_identity` field as access token >> that is stored with the authorization information endpoint, before >> continuing the DTLS handshake. If the contents of the >> `psk_identity` do not yield a valid access token for the requesting >> client, the resource server aborts the DTLS handshake with an >> `illegal_parameter` alert. >>=20 >> > continuing the DTLS handshake. If the contents of the "psk_identit= y" >> > do not yield a valid access token for the requesting client, the DT= LS >> > session setup is terminated with an "illegal_parameter" DTLS alert >> > message. >> > >> > I think "the RS aborts the DTLS handshake with an 'illegal_parameter' = alert" >> > would be more conventional phrasing. >>=20 >> done >>=20 >> > Note2: According to [RFC7252], CoAP implementations MUST support t= he >> > ciphersuite TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]. A client is >> > therefore expected to offer at least this ciphersuite to the >> > resource server. >> > >> > Do we want to say anything about the (EC)DHE variants? Short-lived ac= cess >> > tokens with the AS generating new symmetric keys can provide similar >> > forward-secrecy properties to using DHE, but there is in general a tre= nd >> > in the IETF towards defaulting to providing forward secrecy in key >> > exchanges. >>=20 >> Yes, this makes a lot of sense. We have added the following text to >> the Security Considerations to give advice: >>=20 >> NEW: >>=20 >> The PSK mode of this profile offers a distribution mechanism to >> convey authorization tokens together with a shared secret to a >> client and a server. As this specification aims at constrained >> devices and uses CoAP [RFC7252] as transfer protocol, at least the >> ciphersuite TLS\_PSK\_WITH\_AES\_128\_CCM\_8 {{RFC6655}} should be >> supported. The access tokens and the corresponding shared secrets >> generated by the authorization server are expected to be >> sufficiently short-lived to provide similar forward-secrecy >> properties to using ephemeral Diffie-Hellman (DHE) key exchange >> mechanisms. For longer-lived access tokens, DHE ciphersuites should >> be used. > > Nicely said! > >> > When RS receives an access token, RS MUST check if the access token >> > is still valid, if RS is the intended destination, i.e., the audien= ce >> > of the token, and if the token was issued by an authorized AS. This >> > >> > As above, "i.e., the audience of the token" would probably be better >> > when offset in parentheses than by commas. >>=20 >> done >>=20 >> > While the client can retrieve the shared secret from the contents of >> > the "cnf" parameter in the AS-to-Client response, the resource serv= er >> > uses the information contained in the "cnf" claim of the access tok= en >> > to determine the actual secret when no explicit "kid" was provided = in >> > the "psk_identity" field. If key derivation is used, the RS uses t= he >> > "COSE_KDF_Context" information as described above. >> > >> > "psk_identity" is a field in ClientKeyExchange, and we say that its >> > contents are the raw access token for our usage. It does not have a >> > direct COSE structure for this talk of "kid" to make much sense without >> > further explanation. >>=20 >> Yes, this is misleading. We propose the following to clarify the >> processing of access tokens (independent whether this has been uploaded >> or carried in the psk_identity) on the RS: >>=20 >> OLD: >>=20 >> While the client can retrieve the shared secret from the contents >> of the `cnf` parameter in the AS-to-Client response, the resource >> server uses the information contained in the `cnf` claim of the >> access token to determine the actual secret when no explicit `kid` >> was provided in the `psk_identity` field. If key derivation is >> used, the RS uses the `COSE_KDF_Context` information as described >> above. >>=20 >> NEW: >>=20 >> While the client can retrieve the shared secret from the contents >> of the `cnf` parameter in the AS-to-Client response, the resource >> server uses the information contained in the `cnf` claim of the >> access token to determine the actual secret. To retrieve the `cnf` >> claim and determine the shared secret for the session between the >> client and the resource server, the resource server first has to >> decrypt the access token if it is enclosed in a `COSE_Encrypt0` >> structure and then parse the access token. The parsed access >> token then is associated with the `kid` for the contained shared >> secret, if any. If key derivation is used, the resource server >> calculates the shared secret from the `COSE_KDF_Context` >> information as described above. >>=20 >> > Section 3.4 >> > >> > We may get some requests for a more explicit definition of what the >> > "authorization information" tied to a client is. >> > >> > Once a DTLS channel has been established as described in Section 3.2 >> > and Section 3.3, respectively, the client is authorized to access >> > >> > nit: I think "or" is more appropriate to join the sections listed, as >> > only one is applicable to a given connection. >>=20 >> done >>=20 >> > With the successful establishment of the DTLS channel, C and RS have >> > proven that they can use their respective keying material. An acce= ss >> > token that is bound to the client's keying material is associated >> > with the channel. Any request that the resource server receives on >> > this channel MUST be checked against these authorization rules. RS >> > >> > nit: I'd s/these/the following/ >>=20 >> done >>=20 >> > MUST check for every request if the access token is still valid. >> > Incoming CoAP requests that are not authorized with respect to any >> > access token that is associated with the client MUST be rejected by >> > the resource server with 4.01 response as described in Section 5.1.1 >> > of [I-D.ietf-ace-oauth-authz]. >> > >> > "any access token" implies there might be more than one, though I seem >> > to recall discussion of updated tokens overwriting any previous one, so >> > that only one token per client is active at any given time. What did = we >> > end up settling on? >>=20 >> done >>=20 >> OLD: >>=20 >> Any request that the resource server receives on this channel MUST >> be checked against these authorization rules. RS MUST check for >> every request if the access token is still valid. Incoming CoAP >> requests that are not authorized with respect to any access token >> that is associated with the client MUST be rejected by the resource >> server with 4.01 response as described in Section 5.1.1 of >> [I-D.ietf-ace-oauth-authz]. >>=20 >> NEW: >>=20 >> According to section 5.8.1 of [I-D.ietf-ace-oauth-authz], there >> should be only one access token for each client. New access tokens >> issued by the authorization server are supposed to replace >> previously issued access tokens for the respective client. The >> resource server therefore must have a common understanding with >> the authorization server how access tokens are ordered. >>=20 >> Any request that the resource server receives on a DTLS channel >> that is tied to an access token via its keying material MUST be >> checked against the authorization rules that can be determined >> with the access token. The resource server MUST check for every >> request if the access token is still valid. Incoming CoAP requests >> that are not authorized with respect to any access token that is >> associated with the client MUST be rejected by the resource server >> with 4.01 response. The response MAY include AS Request Creation >> Hints as described in Section 5.1.1 of [I-D.ietf-ace-oauth-authz]. > > I think this is good; it repeats the hints from the core framework that > getting things right with multiple active tokens is hard, but doesn't > strictly forbid it. > >> > Also, the referenced framework Section 5.1.1 does not actually mandate >> > the 4.01 response code. >>=20 >> Fixed in the proposed text for the previous comment: We now require the >> 4.01 and do not imply that this is required by section 5.1.1 of the >> framework document which is silent on the proper response codes. >>=20 >> > The resource server SHOULD treat an incoming CoAP request as >> > authorized if the following holds: >> > >> > We could say more about this "SHOULD" (or change the way we discuss it) >> > -- is it the minimum baseline of checks and additional checks may be >> > applied, or do some of them not apply in some cases, or ...? >>=20 >> These are the minimum checks that the RS needs to do. The following >> proposal should make this clearer: >>=20 >> OLD: >>=20 >> The resource server SHOULD treat an incoming CoAP request as >> authorized if the following holds: >>=20 >> NEW: >>=20 >> The resource server MUST only accept an incoming CoAP request as >> authorized if the following holds: > > That's good. I didn't think very hard about whether adding a brief note > after the list along the lines of "additional checks may be applied > according to local policy" would add value; it may well go without saying. > >> > Incoming CoAP requests received on a secure DTLS channel that are n= ot >> > thus authorized MUST be rejected according to Section 5.8.2 of >> > [I-D.ietf-ace-oauth-authz] >> > >> > We may also get some questions asking about what the difference is >> > between the "not authorized with respect to any access token" in the >> > previous quoted snippet" and "not thus authorized" in this quoted >> > snippet. >>=20 >> We hope that the previous change should have fixed this as well. > > That seems likely :) > >> > The client cannot always know a priori if an Authorized Resource >> > Request will succeed. It MUST check the validity of its keying >> > material before sending a request or processing a response. If the >> > >> > What does "check the validity of its keying material" mean? >>=20 >> The following change should make this more clear as the only thing that >> the client can do is to check if the keying material is still valid: >>=20 >> OLD: >>=20 >> The client cannot always know a priori if an Authorized Resource >> Request will succeed. It MUST check the validity of its keying >> material before sending a request or processing a response. >>=20 >> NEW: >>=20 >> The client MUST ascertain that its keying material is still valid >> before sending a request or processing a response. >>=20 >>=20 >> > client repeatedly gets error responses containing AS Creation Hints >> > (cf. Section 5.1.2 of [I-D.ietf-ace-oauth-authz] as response to its >> > requests, it SHOULD request a new access token from the authorizati= on >> > server in order to continue communication with the resource server. >> > >> > Why should this only be done in the case of *repeatedly* getting such >> > error responses; I thought the idea of the AS Request Creation Hints w= as >> > to take immediate effect. >>=20 >> Correct. The intention was to deal with the race condition for the >> upload mechanism. But as this affects different communication channels, >> it is safe to just remove the word "repeatedly": >>=20 >> OLD: >>=20 >> client repeatedly gets error responses containing AS Creation Hints >>=20 >> NEW: >>=20 >> client gets an error response containing AS Request Creation Hints >>=20 >> > (Also, nit: s/AS Creation Hints/AS Request Creation Hints/.) >>=20 >> done >>=20 >> > Section 4 >> > >> > The client can update the authorization information stored at the >> > resource server at any time without changing an established DTLS >> > session. To do so, the Client requests a new access token from the >> > authorization server for the intended action on the respective >> > resource and uploads this access token to the authz-info resource on >> > the resource server. >> > >> > I suggest adding another sentence similar to "Because ACE tokens are >> > proof-of-possession tokens, the updated authorization information only >> > takes immediate effect if such proof has already been provided, e.g., = if >> > the PoP key associated with the new token is the same as the one >> > currently in use." This is further detailed in the following >> > paragraphs, but not stated concretely as a key principle. >>=20 >> The term "ACE tokens" may be a bit misleading. In this profile, we >> always use PoP tokens. Our proposal is to move the note from the end >> upwards: >>=20 >> OLD: >>=20 >> The client can update... >>=20 >> NEW: >>=20 >> Resource servers must only use a new access token to update the >> authorization information for a DTLS session if the keying >> material that is bound to the token is the same that was used in >> the DTLS handshake. By associating the access tokens with the >> identifier of an existing DTLS session, the authorization >> information can be updated without changing the cryptographic keys >> for the DTLS communication between the client and the resource >> server, i.e. an existing session can be used with updated >> permissions. > > This looks like it will work; I can handle the lack of my preferred > phrasing about the "proof has already been provided" :) > >> The client can therefore update... >>=20 >> > Section 5 >> > >> > DTLS sessions that have been established in accordance with this >> > profile are always tied to a specific access token. As this token >> > >> > Doesn't the dynamic authorization update mechanism allow that token to >> > be swapped out during the lifetime of the connection? >> > Also, as a terminology point, I think "DTLS association" is more >> > appropriate than "DTLS session" for what we describe, since the token = is >> > is tied to the client and consulted at the start of the handshake, as >> > opposed to being a property of the DTLS session and carried across >> > resumptions. >>=20 >> We propose the following text as a clarification. This also takes >> into account the "session" vs. "association" part which looks a bit >> weird. If we come to the conclusion that this is a better term, we >> would have to revise the rest of the document accordingly: >>=20 >> OLD: >>=20 >> DTLS sessions that have been established in accordance with this >> profile are always tied to a specific access token. As this token >> may become invalid at any time (e.g. because it has expired), the >> session may become useless at some point. A resource server >> therefore MUST terminate existing DTLS sessions after the access >> token for this session has been deleted. >>=20 >> NEW: >>=20 >> The resource server MUST delete access tokens that are no longer >> valid. DTLS associations that have been setup in accordance with >> this profile are always tied to specific tokens (which may be >> exchanged with a dynamic update as described in Section 4). As >> tokens may become invalid at any time (e.g. because they have >> expired), the association may become useless at some point. A >> resource server therefore MUST terminate existing DTLS association >> after the last access token associated with this association has >> expired. > > This looks good (modulo the nit: comma after "e.g."). Fixed, thanks! >> > may become invalid at any time (e.g. because it has expired), the >> > session may become useless at some point. A resource server >> > therefore MUST terminate existing DTLS sessions after the access >> > token for this session has been deleted. >> > >> > I assume that using "been deleted" vs. "has expired" is a deliberate >> > choice? If we don't say anything else about when to delete tokens, it >> > doesn't post much of a requirement, though. >>=20 >> Good point. This is missing in Section 3.4. We now have added an >> explicit requirement to remove expired (or otherwise invalid) access >> tokens: >>=20 >> OLD: >>=20 >> The resource server MUST check for every request if the access >> token is still valid. >>=20 >> NEW: >>=20 >> The resource server MUST check for every request if the access >> token is still valid. If the token has expired, the resource >> server MUST remove it. > > Ah, thanks. > >> > Section 6 >> > >> > endpoint. The use of CoAP and DTLS for this communication is >> > RECOMMENDED in this profile, other protocols (such as HTTP and TLS = or >> > CoAP and OSCORE) MAY be used instead. >> > >> > nit: comma splice >>=20 >> done >>=20 >> > Also, we could potentially refer to the OSCORE profile document here >> > (informatively). >>=20 >> done >>=20 >> > If other means of securing the communication with the AS are used, >> > the security protocol MUST fulfill the communication security >> > requirements in Section 6.2 of [I-D.ietf-ace-oauth-authz]. >> > >> > I suggest phrasing more like "the communication security requirements >> > from Section 6.2 of [I-D.ietf-ace-oauth-authz] remain applicable", sin= ce >> > there's no need to add another MUST to the ones already in the framewo= rk >> > document. >>=20 >> Done, although "remain applicable" seems a bit weak. >>=20 >> > Section 7 >> > >> > I have a few suggestions for potential additions to this section as we= ll >> > as comments on the existing contents. >> > >> > We might consider adding a brief note about the use of 8-byte >> > authentication tags in DTLS ciphers and how that affects the risk >> > profile. >>=20 >> Done. New text has been added as follows. >>=20 >> NEW: >>=20 >> As this specification targets at constrained environments, message >> payloads exchanged between the client and the resource server are >> expected to be small and rare. CoAP {{RFC7252}} mandates the >> implementation of cipher suites with abbreviated, 8-byte tags for >> message integrity protection. For consistency, this profile requires >> implementation of the same cipher suites. For application scenarios >> where the cost of full-width authentication tags is low compared to >> the overall amount of data being transmitted, the use of cipher >> suites with 16-byte integrity protection tags is preferred. >>=20 >> > The use of "live" authorization upgrades on an existing DTLS connection >> > by posting a new token to the authz-info endpoint does not provide much >> > guarantee about the order in which operations occur (and thus which >> > authorization info is used to process a given client request), >> > especially in the face of an attacker that can delay and reorder >> > packets. This does not necessarily mean that we should not bother to >> > define that mechanism, but we should point out that there is only a we= ak >> > ordering property provided, note that other mechanisms should be used >> > when strict serialization is important, and caution that when the >> > later-issued token contains a reduction in authorization from the >> > initial token, it is impossible to guarantee that the reduction in >> > authorization will take effect prior to the expiration of the original >> > token. >>=20 >> Exactly! To address this, the following text has been added to the >> Security Considerations: >>=20 >> NEW: >>=20 >> Even when a single access token per client is used, an attacker >> could compromise the dynamic update mechanism for existing DTLS >> connections by delaying or reordering packets destined for the >> authz-info endpoint. Thus, the order in which operations occur at >> the resource server (and thus which authorization info is used to >> process a given client request) cannot be guaranteed. Especially >> in the presence of later-issued access tokens that reduce the >> client's permissions from the initial access token, it is >> impossible to guarantee that the reduction in authorization will >> take effect prior to the expiration of the original token. >>=20 >> > We rely heavily on the AS to accurately provide binding of raw key >> > material to authorization information and endpoint identinty; I think >> > this is a stronger reliance than just that implied by the core >> > architecture, and so might merit a mention here. (This relates to all >> > the checks about "MUST check that [client/...] is associated with >> > [RPK/PSK]" that appear throughout the document.) >>=20 >> We are not sure if this is specific to this profile. For any profile >> within the ACE framework, the AS must know C and RS and must know their >> keys. In this profile, we just describe what the AS needs to do to >> address these requirements. > > Okay. > >> > I'd also suggest reiterating all the places where we rely on out-of-ba= nd >> > configuration, as there's always a risk of such configuration becoming >> > stale (or getting attacked directly). >>=20 >> Most parts of the document already now do this. We have added an >> additional remark in Section 3.1 to ensure that the client checks that >> the authorization information about the AS is still valid. >> We have also added a new subsection to the Security Considerations that >> describes the configuration and authorization information that must >> be provided to the authorization server, the resource server, and the >> client outside of the ACE DTLS profile. >>=20 >> NEW: >>=20 >> 7.1 Out-of-Band Configuration >>=20 >> To communicate securely, the authorization server, the client and >> the resource server require certain information that must be >> exchanged outside the protocol flow described in this >> document. The authorization server must have obtained >> authorization information concerning the client and the resource >> server that is approved by the resource owner as well as >> corresponding keying material. The resource server must have >> received authorization information approved by the resource owner >> concerning its authorization managers and the respective keying > > (Do we use the phrase "authorization manager" elsewhere?) > >> material. The client must have obtained authorization information >> concerning the authorization server approved by its owner as well >> as the corresponding keying material. Also, the client's owner >> must have approved of the client's communication with the resource >> server. The client and the authorization server must have obtained >> a common understanding how this resource server is identified to >> ensure that the client obtains access token and keying material >> for the correct resource server. If the client is provided with a >> raw public key for the resource server, it must be ascertained to >> which resource server (which identifier and authorization >> information) the key is associated. All authorization information >> and keying material must be kept up to date. >>=20 >> > I'd consider reiterating that when the KDF scheme is in use between RS >> > and AS, that kid uniqueness is paramount, as using the same kid for >> > multiple clients and the same RS would have potentially disasterous >> > consequences in that case. >>=20 >> Not sure if this is specific to the key generation through KDF, as the >> kid is typically used to find the access token that was uploaded to the >> auth-info endpoint? > > I think it is specific to key generation through KDF, but let me try to > walk through it. > > Up in Section 3.3 we talk about a case where the AS and RS are assumed to > share a key derivation key that's used to derive symmetric keys for the RS > to share with the client. The KDF input is the IKM and the 'info' (since > 'salt' is empty), and the IKM is just that same "key derivation key". So > the only input to HKDF that changes for different clients (and the same R= S) > is the 'info'. The 'info', in turn contains a string constant 'type' plus > the 'kid' and (presumably fixed) output length. If I'm reading this > correctly, the 'kid' is the only HKDF input that varies between clients, = so > if the 'kid' was reused for different clients, the AS and RS would derive > the same symmetric key for those distinct client/RS pairs. Furthermore, > since the AS returns the actual symmetric key to the client in the token > response, that means that the symmetric key is shared by *three* parties > (vs. just client and RS, ignoring in the count the AS which knows > everything). I guess technically this is not the scenario forbidden by t= he > core framework (which is to have the same symmetric key used at multiple > RSes, but it still is bad hygeine and would let one client impersonate the > other. > > In cases not using the KDF, the 'kid' is just a hint to finding the actual > key, and the actual key is assumed to be constructed uniquely by the AS > each time. Thank you, this is absolutely true. I have now changed the input for the key derivation mechanism in the sense of what originally has been specified in draft-gerdes-ace-dcaf-authorize, i.e., including the access token as input to the KDF. This enables the authorization server to include a certain amount of unifying attributes in the info parameter, esp. with a randomly generated kid and the iat claim. I would have loved to have a claim type for carrying a nonce in the access token=E2=80=A6 >> > Similarly (though this is inherent to symmetric PoP and may not actual= ly >> > need reiterating), when we use symmetric PSKs for PoP, they lose almost >> > all value if any given PSK is known to more than one client or RS. (T= he >> > secdir review on the framework has us putting in MUST-level requiremen= ts >> > to not share further than that, so it seems pretty reasonable to not >> > duplicate that warning here.) >>=20 >> Okay. This was one of things that we deemed obvious=E2=80=A6 >>=20 >> > This document specifies a profile for the Authentication and >> > Authorization for Constrained Environments (ACE) framework >> > [I-D.ietf-ace-oauth-authz]. As it follows this framework's general >> > approach, the general security considerations from section 6 also >> > apply to this profile. >> > >> > (The HTMLized link will only do the right thing if you use the redunda= nt >> > "section 6 of [I-D.ietf-ace-oauth-authz]".) >>=20 >> done > > Though I guess we're on v3 XML now (yay! very pretty!), which hopefully > does not have the same artificial limitations. > >> > The use of multiple access tokens for a single client increases the >> > strain on the resource server as it must consider every access token >> > and calculate the actual permissions of the client. Also, tokens m= ay >> > contradict each other which may lead the server to enforce wrong >> > permissions. If one of the access tokens expires earlier than >> > others, the resulting permissions may offer insufficient protection. >> > Developers SHOULD avoid using multiple access tokens for a client. >> > >> > I think I touched on this above; did we want to make a stronger >> > statement about "only one active token per client"? >>=20 >> At the time this was written, the framework document was pretty unclear >> about this. Now, it would be possible to have multiple access tokens for >> a client if you knew how to merge the authorization rules. We have >> changed the update mechanism to clearly state that a new token replaces >> the old one. The question is if we still need this paragraph. > > I think the discussion is still valid and the only thing I'm not sure abo= ut > is whether the last sentence is needed. As there is no guidance so far on how permission sets in access tokens are to be combined properly it seems to be wise at least to advise against. >> > Section 8 >> > >> > information as possible in an unencrypted response. When a DTLS >> > session between the client and the resource server already exists, >> > more detailed information MAY be included with an error response to >> > provide the client with sufficient information to react on that >> > particular error. >> > >> > I'd suggest adding a caveat like "an authenticated client" or >> > "a known client", since DTLS itself does not guarantee that the client >> > is not an attacker. >>=20 >> done >>=20 >> > Section 9 >> > >> > Profile ID: 1 >> > >> > I think this has to be merely a "suggested value", as IANA will control >> > the actual allocations, in the absence of a reservation of this value = in >> > the framework document. >>=20 >> done >>=20 >> > Section 10.1 >> > >> > We don't currently reference RFC 7925 in any way that would require it >> > to be a normative reference. We probably should, though -- somehow pu= ll >> > in that we require/recommend conformance with that profile of DTLS. >>=20 >> We are not sure if there is anything special about RFC 7925 that we >> explicitly want to point out. However, as we have the requirement of >> treating the access token in the psk_identity as opaque binary data, we >> have moved the reference RFC 7925 into the normative section. > > Okay, thanks. > >> > Section 10.2 >> > >> > I think RFCs 7250, 7251, and 8422 need to be normative. >>=20 >> done Actually, I had to revert this for the informational RFC 7251 as the idnits tool did not allow the downref from normative. Gr=C3=BC=C3=9Fe Olaf From nobody Wed May 13 20:17:26 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E69A3A0935 for ; Wed, 13 May 2020 20:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGMilW7XgANa for ; Wed, 13 May 2020 20:17:22 -0700 (PDT) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (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 2E0A73A094B for ; Wed, 13 May 2020 20:17:22 -0700 (PDT) Received: by mail-vs1-xe33.google.com with SMTP id a5so1113545vsm.7 for ; Wed, 13 May 2020 20:17:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=5rWrCdPPXSRbmUNSAnu4LyKkl7J0QBRo4Z41TlAu2OA=; b=ZdNNDUjmcptuAsxT+tTWh79Z1xMNvVgEcQ+C/X3BXZYcj1DsN1djzyEDWtKDZ3kwI0 biOaNmoZ4pmEOzZ8baZb2GML1oPIlsUbSn+tceB2T3Xk/82+yPBfW8IzP7mACFKjrD9g 57B+58cofIdSyJHI1IQSimGhy5RNwFN3UdWGm8P2Xom54MUjZtvQhXf493AVnaIREaZq 01f7z7FQZJ74PKW9vB8G18kDRLtQ8hafnq645X2V9s2cw26xwMMl39osliMukUz0SN6D KLa/gNN/jzK/7CrMEn7v+/rHr71lSgE9iDUH2g1uqRDYlZUM/cdIMie0k8+rLwThCckn MyYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=5rWrCdPPXSRbmUNSAnu4LyKkl7J0QBRo4Z41TlAu2OA=; b=c9RAdClUBaK0fxifgbnf92zNpilO95Y3eJZZxfWnB74JpRcjEG5NmMeHaIUS796vC6 mtPQyFs4xLCX5t7s2xRAxcGGedGL8kEZMw8jjfVhKNKJrazOBYxl6/a8Qmer7SR+Y7Zq aZeoXs9unAYG87hVyaPjdBBYoN465fD7UGgkmlnjf3ALhMTA6up1ZAv8OFEFsykEhYWT VfFvDW+wlKLq0YPC4uqpk/ujV5GACTIdiHzeln2NPf7USb6uBMRVku7ECx7xVdDJ/93p CG9LPP/eDZVqKu1jNnr4kRk0bzd4/aLf06YDng00etl7W3rspymGd8C8kpR3BKAUd497 a5Zw== X-Gm-Message-State: AOAM530bIkw2iNdaxCXb8LkYHhnpu9Zw5IFSQ6oWeWnv2UbpbYKpZh8P fM16jsSIJIZrKypS5QxdmGQAFaWYhAn1T4nc8JVb0Q== X-Google-Smtp-Source: ABdhPJw5fLAyXKSSEeZQ/j3f2sU7EkAyv6KP1aXIAfzwQ24/kiX5xbOPiBn2YTUkx9G+zqi3oN1GciuF9xOTc6Cqx+k= X-Received: by 2002:a67:fc46:: with SMTP id p6mr1891141vsq.169.1589426240791; Wed, 13 May 2020 20:17:20 -0700 (PDT) MIME-Version: 1.0 References: <158743514464.14263.8072013608148073068@ietfa.amsl.com> In-Reply-To: <158743514464.14263.8072013608148073068@ietfa.amsl.com> From: Daniel Migault Date: Wed, 13 May 2020 23:17:09 -0400 Message-ID: To: Ace Wg Content-Type: multipart/alternative; boundary="0000000000007aa89a05a5932268" Archived-At: Subject: [Ace] Fwd: Authentication and Authorization for Constrained Environments (ace) WG Virtual Meeting: 2020-05-18 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 14 May 2020 03:17:24 -0000 --0000000000007aa89a05a5932268 Content-Type: text/plain; charset="UTF-8" Hi, This is a reminder that we have an interim meeting Monday May 18. We are preparing the agenda, so please let the chairs know if you are willing to present. Please also upload you slides here by Sunday 23:59 anywhere in the world. https://datatracker.ietf.org/meeting/interim-2020-ace-06/session/ace Information on the meeting: https://datatracker.ietf.org/meeting/interim-2020-ace-06/session/ace Yours, Jim and Daniel ---------- Forwarded message --------- From: IESG Secretary Date: Mon, Apr 20, 2020 at 10:12 PM Subject: [Ace] Authentication and Authorization for Constrained Environments (ace) WG Virtual Meeting: 2020-05-18 To: IETF-Announce Cc: The Authentication and Authorization for Constrained Environments (ace) Working Group will hold a virtual interim meeting on 2020-05-18 from 10:00 to 11:30 America/New_York (14:00 to 15:30 UTC). Agenda: (No agenda submitted) Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=md8728a7cd7aa263c70a3c712da89f3ee _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace -- Daniel Migault Ericsson --0000000000007aa89a05a5932268 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

This is a reminder that we ha= ve an interim meeting Monday May 18. We are preparing=C2=A0the agenda, so p= lease let the chairs know if you are willing to present.=C2=A0
Please also upload you slides here by Sunday 23:59 anywhere in= the world.

Information on the= meeting:

Yours,=C2= =A0
Jim and Daniel=C2=A0=C2=A0

=
---------- Forwarded message --------= -
From: IESG Secretary <i= esg-secretary@ietf.org>
Date: Mon, Apr 20, 2020 at 10:12 P= M
Subject: [Ace] Authentication and Authorization for Constrained Enviro= nments (ace) WG Virtual Meeting: 2020-05-18
To: IETF-Announce <ietf-announce@ietf.org>
Cc: = <ace@ietf.org>


T= he Authentication and Authorization for Constrained Environments (ace) Work= ing Group will hold
a virtual interim meeting on 2020-05-18 from 10:00 to 11:30 America/New_Yor= k (14:00 to 15:30 UTC).

Agenda:
(No agenda submitted)

Information about remote participation:
https://ietf.webex.com/iet= f/j.php?MTID=3Dmd8728a7cd7aa263c70a3c712da89f3ee

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


--
Dani= el Migault
Ericsson
--0000000000007aa89a05a5932268-- From nobody Thu May 14 05:21:01 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092673A09CB for ; Thu, 14 May 2020 05:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.173, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYb0hZqsM9xd for ; Thu, 14 May 2020 05:20:55 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130079.outbound.protection.outlook.com [40.107.13.79]) (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 6BA803A09CA for ; Thu, 14 May 2020 05:20:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dg9M9LlAm6+ms0tllXorfICUvlIbCEvMZQV2r7PqxSwIRrh9OJQiS+Z8JzmBhfm+jwe9qWKqU4Z34nQc0XGbSwnXjX4+DvBzgEK19T7BQzxwU70+8Bxqp/t1skc3W0zlWA/uI4jZy4TNNv92sDFFmtYbUNWEwVKnL6/6JmPYFofyILWTqNSyRUq35vrFDH9duYOavyYjuwAIhGZKZynuT+F/pevygvq3xjASRsrXMlAxhGJBw0CQOCPrJbpDlrt5fQAnYu7TBI6emicNFJNCUAZ7ueixoWkS56/GrZb/VAusTCIhjSmWPlepUGh5Bt5IXs1LmkzgiGx5WST+bxiD2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6Ly8NRvERlIZ2WIfAFIw4S1FqD+vzMP+45Qtvipz69A=; b=finORcLQgnpiQExGn3yj1B9LITLNrjoHso2dC8ALzPQDQpcm8lWUUMQ/tpLUVfQINXnpRvScOXBstEILVeR6VGyW9pNDjH9y5T/ToRf7e/d0562BfYeD37ATONSL3NR9GFqO8n9PkcTtRwklssKXVTQNWMc3SWrmyNLllHCPuMTEYZOvSsYYZPayrkKUBrmGy1qrMlzn4FCT0cn+TeJ4fvUAtKgnPc3FQN1sGC9UtYSJzLOWLnPVFO9Ocd9vl8S+TgWutQSmWMvTG0pbFBXiZZyWLoDAW5F+HDu2U76cxUTvPErKEMI7id1CoHHDutduiXy6X5a3scnVO8CAHqctnw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6Ly8NRvERlIZ2WIfAFIw4S1FqD+vzMP+45Qtvipz69A=; b=XIDRaqh4Ms2M2u2Ak3GCDAic7nG7LIdk4HtTHxn6WN3vJd0E9nc91fI4ZiP7q6Ts0NxzZqbyrpqrr1td7IUbhGFzNfPszOLkPMDM1sKpU3patrMtJkW4+oYyb/4Qtiuwp/RerbW1sxNantrrM9aPH1OaX/qXKMB6Sh5tOrDZMnA= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) by HE1PR0702MB3788.eurprd07.prod.outlook.com (2603:10a6:7:8a::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.11; Thu, 14 May 2020 12:20:52 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::f0bb:b1ae:bf22:4526]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::f0bb:b1ae:bf22:4526%6]) with mapi id 15.20.2979.033; Thu, 14 May 2020 12:20:52 +0000 From: Francesca Palombini To: Daniel Migault , Ace Wg Thread-Topic: [Ace] Fwd: Authentication and Authorization for Constrained Environments (ace) WG Virtual Meeting: 2020-05-18 Thread-Index: AQHWKZ45U/sK7sFrdUWHLwxr7cYhDainooGA Date: Thu, 14 May 2020 12:20:51 +0000 Message-ID: <70B616BF-0F8F-47FB-801B-546D15148223@ericsson.com> References: <158743514464.14263.8072013608148073068@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.37.20051002 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 43eb8a21-5f92-49a2-28bf-08d7f8013e52 x-ms-traffictypediagnostic: HE1PR0702MB3788: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 040359335D x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: LAZh5QUmjU+EBUBXltqq3U3++FdY2cijg60/JIg7v74JGJ+Fv+IhZUaJ+ugBrmcTloCKvDvi+KcgHdHYDyADEtpbD4fEpjXGs4vuwbpK/1lGYvyriUMUMjNxgUyQz2Oay1KUhpV1taNvA7NlP2ue5Ft9VkBL1W57Sw8R6wVP3YXgQWIUrVzDhfnvNLb1sp4r5hFbAzM1SGoHIC6xFhU1/gU3jQgLEcUq5uCDegJKA0Vtx1UMPg+QFMACAt3wcdgCMWoH5mTBV5QS8llBQSMW9psZpYR0gVaiadYT5NIFgSd1XyEs4MDqSYExWO/PK2W+vLW2nAOTjOsA0QrXf/7FrDYDJU1eDUBAZ8Xy2CbHXUn1yocR6vt5eakNCsPf1/v+125X0rQYPbmZUk5/ImW2oA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3818.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(136003)(366004)(39860400002)(376002)(346002)(36756003)(66446008)(64756008)(86362001)(5660300002)(76116006)(66556008)(66946007)(66476007)(166002)(2906002)(71200400001)(6486002)(8676002)(8936002)(9326002)(44832011)(53546011)(6506007)(478600001)(26005)(6512007)(33656002)(16799955002)(316002)(2616005)(966005)(110136005)(186003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: XitjE4A8erHotDfBdbxr8vAEUDq46oeINKYUVDXk91HWJZqX9RZ4eK3C+5XvRSQ8fL8E0icnwvbR/0Tg9mX0CvNbJS5yWzdSnKN4hQUeyV5zod9V0Ox4wYX44tkaIaMmUWGRnkxiSvDIHNAbUc7AOwAD2QrjTSpn5RuJ74TH4R51LCHb/Sdbz4SExlrS4JRgvxFf4XAX32omy2NaY7FbDAXvZWMdySFmZkUwv+nRiJAn0knAiexNMKoRwLWMhXQwfpS4x/JvAx78CNMOWVD90SiG97bEVZgbOIpwsKb3LP7Xxhq2lA1xpcD1tclRa4oFYcIpLxP7ffZ6PfB4XPumX5gqLSiVWzMixSKBu7WDYishTCeYqK/up0rYO0Uuiuq3jp1pz0EVIdtvLjQ/pEkz1kC38QM9cgzc5UfO/m3TWJ784bLiRT+KdoInfxRJIGx+GB7yPEkee/CVxtImyujZ01Cw3xUnKtwj2Oktk5Z0EwBw6PewtjhJ+mhQ3RszQ/YD x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_70B616BF0F8F47FB801B546D15148223ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 43eb8a21-5f92-49a2-28bf-08d7f8013e52 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2020 12:20:51.9112 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: j3QuPVtt/shzDOqMx9ayVJm6Wld7zw2Ps6zjr18H/dK/pY4TjOBXapCVC/pBjIoV+vd9DT14CdmbN3HM23egXeSnTL+Fbh1ZHThlqbfGVmuRDd0ZzEHoCk4A0/DPOPYU X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3788 Archived-At: Subject: Re: [Ace] Fwd: Authentication and Authorization for Constrained Environments (ace) WG Virtual Meeting: 2020-05-18 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 14 May 2020 12:21:00 -0000 --_000_70B616BF0F8F47FB801B546D15148223ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCknigJlkIGxpa2UgdG8gdGFrZSBzb21lIHRpbWUgdG8gZ2V0IGEgY29uY2x1c2lvbiBv biB0aGUg4oCcVXBkYXRlIG9mIGFjY2VzcyByaWdodHPigJ0gZGlzY3Vzc2lvbiBzdGFydGVkIGhl cmU6IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvYWNlL2RMa1ctTVlIWGZa cW10WTdBUDdaQkRKcHhPdy8NCih0aGUgcmVzdWx0IG9mIHRoaXMgZGlzY3Vzc2lvbiB3b3VsZCBo YXZlIGFuIGltcGFjdCBvbiBhY2UgZnJhbWV3b3JrIGFuZCBwcm9maWxlcykuDQoNCknigJlkIGFs c28gbGlrZSB0byB0YWxrIGFib3V0IGFjZS1rZXktZ3JvdXBjb21tLTA2IGFuZCBkaXNjdXNzIG9w ZW4gcG9pbnRzLiBJIHdpbGwgc3VibWl0IHNsaWRlcy4NCg0KVGhhbmtzLA0KRnJhbmNlc2NhDQoN Cg0KRnJvbTogQWNlIDxhY2UtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIERhbmllbCBN aWdhdWx0IDxtZ2x0LmlldGZAZ21haWwuY29tPg0KRGF0ZTogVGh1cnNkYXksIDE0IE1heSAyMDIw IGF0IDA1OjE3DQpUbzogQWNlIFdnIDxhY2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbQWNlXSBGd2Q6 IEF1dGhlbnRpY2F0aW9uIGFuZCBBdXRob3JpemF0aW9uIGZvciBDb25zdHJhaW5lZCBFbnZpcm9u bWVudHMgKGFjZSkgV0cgVmlydHVhbCBNZWV0aW5nOiAyMDIwLTA1LTE4DQoNCkhpLA0KDQpUaGlz IGlzIGEgcmVtaW5kZXIgdGhhdCB3ZSBoYXZlIGFuIGludGVyaW0gbWVldGluZyBNb25kYXkgTWF5 IDE4LiBXZSBhcmUgcHJlcGFyaW5nIHRoZSBhZ2VuZGEsIHNvIHBsZWFzZSBsZXQgdGhlIGNoYWly cyBrbm93IGlmIHlvdSBhcmUgd2lsbGluZyB0byBwcmVzZW50Lg0KDQpQbGVhc2UgYWxzbyB1cGxv YWQgeW91IHNsaWRlcyBoZXJlIGJ5IFN1bmRheSAyMzo1OSBhbnl3aGVyZSBpbiB0aGUgd29ybGQu DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvaW50ZXJpbS0yMDIwLWFjZS0w Ni9zZXNzaW9uL2FjZQ0KDQpJbmZvcm1hdGlvbiBvbiB0aGUgbWVldGluZzoNCmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy9pbnRlcmltLTIwMjAtYWNlLTA2L3Nlc3Npb24vYWNl DQoNCllvdXJzLA0KSmltIGFuZCBEYW5pZWwNCi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2Ug LS0tLS0tLS0tDQpGcm9tOiBJRVNHIFNlY3JldGFyeSA8aWVzZy1zZWNyZXRhcnlAaWV0Zi5vcmc8 bWFpbHRvOmllc2ctc2VjcmV0YXJ5QGlldGYub3JnPj4NCkRhdGU6IE1vbiwgQXByIDIwLCAyMDIw IGF0IDEwOjEyIFBNDQpTdWJqZWN0OiBbQWNlXSBBdXRoZW50aWNhdGlvbiBhbmQgQXV0aG9yaXph dGlvbiBmb3IgQ29uc3RyYWluZWQgRW52aXJvbm1lbnRzIChhY2UpIFdHIFZpcnR1YWwgTWVldGlu ZzogMjAyMC0wNS0xOA0KVG86IElFVEYtQW5ub3VuY2UgPGlldGYtYW5ub3VuY2VAaWV0Zi5vcmc8 bWFpbHRvOmlldGYtYW5ub3VuY2VAaWV0Zi5vcmc+Pg0KQ2M6IDxhY2VAaWV0Zi5vcmc8bWFpbHRv OmFjZUBpZXRmLm9yZz4+DQoNCg0KVGhlIEF1dGhlbnRpY2F0aW9uIGFuZCBBdXRob3JpemF0aW9u IGZvciBDb25zdHJhaW5lZCBFbnZpcm9ubWVudHMgKGFjZSkgV29ya2luZyBHcm91cCB3aWxsIGhv bGQNCmEgdmlydHVhbCBpbnRlcmltIG1lZXRpbmcgb24gMjAyMC0wNS0xOCBmcm9tIDEwOjAwIHRv IDExOjMwIEFtZXJpY2EvTmV3X1lvcmsgKDE0OjAwIHRvIDE1OjMwIFVUQykuDQoNCkFnZW5kYToN CihObyBhZ2VuZGEgc3VibWl0dGVkKQ0KDQpJbmZvcm1hdGlvbiBhYm91dCByZW1vdGUgcGFydGlj aXBhdGlvbjoNCmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW1kODcyOGE3 Y2Q3YWEyNjNjNzBhM2M3MTJkYTg5ZjNlZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KQWNlIG1haWxpbmcgbGlzdA0KQWNlQGlldGYub3JnPG1haWx0 bzpBY2VAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Fj ZQ0KDQoNCi0tDQpEYW5pZWwgTWlnYXVsdA0KRXJpY3Nzb24NCg== --_000_70B616BF0F8F47FB801B546D15148223ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <042E9FDE5A7FAE488BEB605A6CDFA15D@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0Ii IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPknigJlkIGxpa2UgdG8gdGFrZSBzb21lIHRpbWUgdG8gZ2V0IGEgY29u Y2x1c2lvbiBvbiB0aGUg4oCcVXBkYXRlIG9mIGFjY2VzcyByaWdodHPigJ0gZGlzY3Vzc2lvbiBz dGFydGVkIGhlcmU6DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9y Zy9hcmNoL21zZy9hY2UvZExrVy1NWUhYZlpxbXRZN0FQN1pCREpweE93LyI+aHR0cHM6Ly9tYWls YXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9hY2UvZExrVy1NWUhYZlpxbXRZN0FQN1pCREpweE93 LzwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+KHRoZSByZXN1bHQgb2YgdGhpcyBkaXNjdXNzaW9u IHdvdWxkIGhhdmUgYW4gaW1wYWN0IG9uIGFjZSBmcmFtZXdvcmsgYW5kIHByb2ZpbGVzKS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+SeKAmWQgYWxzbyBsaWtlIHRvIHRhbGsgYWJvdXQgYWNlLWtleS1ncm91cGNvbW0tMDYgYW5k IGRpc2N1c3Mgb3BlbiBwb2ludHMuIEkgd2lsbCBzdWJtaXQgc2xpZGVzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFua3Ms PGJyPg0KRnJhbmNlc2NhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr Ij5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpi bGFjayI+QWNlICZsdDthY2UtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIERhbmll bCBNaWdhdWx0ICZsdDttZ2x0LmlldGZAZ21haWwuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5U aHVyc2RheSwgMTQgTWF5IDIwMjAgYXQgMDU6MTc8YnI+DQo8Yj5UbzogPC9iPkFjZSBXZyAmbHQ7 YWNlQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bQWNlXSBGd2Q6IEF1dGhlbnRp Y2F0aW9uIGFuZCBBdXRob3JpemF0aW9uIGZvciBDb25zdHJhaW5lZCBFbnZpcm9ubWVudHMgKGFj ZSkgV0cgVmlydHVhbCBNZWV0aW5nOiAyMDIwLTA1LTE4PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5IaSwmbmJzcDsgPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5UaGlzIGlzIGEgcmVtaW5kZXIgdGhhdCB3 ZSBoYXZlIGFuIGludGVyaW0gbWVldGluZyBNb25kYXkgTWF5IDE4LiBXZSBhcmUgcHJlcGFyaW5n Jm5ic3A7dGhlIGFnZW5kYSwgc28gcGxlYXNlIGxldCB0aGUgY2hhaXJzIGtub3cgaWYgeW91IGFy ZSB3aWxsaW5nIHRvIHByZXNlbnQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPlBsZWFzZSBhbHNvIHVwbG9hZCB5b3Ugc2xpZGVzIGhlcmUg YnkgU3VuZGF5IDIzOjU5IGFueXdoZXJlIGluIHRoZSB3b3JsZC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy9pbnRlcmlt LTIwMjAtYWNlLTA2L3Nlc3Npb24vYWNlIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21l ZXRpbmcvaW50ZXJpbS0yMDIwLWFjZS0wNi9zZXNzaW9uL2FjZTwvYT4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SW5mb3JtYXRpb24gb24g dGhlIG1lZXRpbmc6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL21lZXRpbmcvaW50ZXJpbS0yMDIwLWFjZS0wNi9zZXNzaW9uL2FjZSI+ aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nL2ludGVyaW0tMjAyMC1hY2UtMDYv c2Vzc2lvbi9hY2U8L2E+Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPllvdXJzLCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDow Y207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDozNi4w cHQiPg0KSmltIGFuZCBEYW5pZWwmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+LS0t LS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS08YnI+DQpGcm9tOiA8c3Ryb25nPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPklF U0cgU2VjcmV0YXJ5PC9zcGFuPjwvc3Ryb25nPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmllc2ctc2Vj cmV0YXJ5QGlldGYub3JnIj5pZXNnLXNlY3JldGFyeUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KRGF0 ZTogTW9uLCBBcHIgMjAsIDIwMjAgYXQgMTA6MTIgUE08YnI+DQpTdWJqZWN0OiBbQWNlXSBBdXRo ZW50aWNhdGlvbiBhbmQgQXV0aG9yaXphdGlvbiBmb3IgQ29uc3RyYWluZWQgRW52aXJvbm1lbnRz IChhY2UpIFdHIFZpcnR1YWwgTWVldGluZzogMjAyMC0wNS0xODxicj4NClRvOiBJRVRGLUFubm91 bmNlICZsdDs8YSBocmVmPSJtYWlsdG86aWV0Zi1hbm5vdW5jZUBpZXRmLm9yZyI+aWV0Zi1hbm5v dW5jZUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KQ2M6ICZsdDs8YSBocmVmPSJtYWlsdG86YWNlQGll dGYub3JnIj5hY2VAaWV0Zi5vcmc8L2E+Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48YnI+DQo8YnI+DQpU aGUgQXV0aGVudGljYXRpb24gYW5kIEF1dGhvcml6YXRpb24gZm9yIENvbnN0cmFpbmVkIEVudmly b25tZW50cyAoYWNlKSBXb3JraW5nIEdyb3VwIHdpbGwgaG9sZDxicj4NCmEgdmlydHVhbCBpbnRl cmltIG1lZXRpbmcgb24gMjAyMC0wNS0xOCBmcm9tIDEwOjAwIHRvIDExOjMwIEFtZXJpY2EvTmV3 X1lvcmsgKDE0OjAwIHRvIDE1OjMwIFVUQykuPGJyPg0KPGJyPg0KQWdlbmRhOjxicj4NCihObyBh Z2VuZGEgc3VibWl0dGVkKTxicj4NCjxicj4NCkluZm9ybWF0aW9uIGFib3V0IHJlbW90ZSBwYXJ0 aWNpcGF0aW9uOjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBo cD9NVElEPW1kODcyOGE3Y2Q3YWEyNjNjNzBhM2M3MTJkYTg5ZjNlZSIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW1kODcyOGE3Y2Q3YWEyNjNj NzBhM2M3MTJkYTg5ZjNlZTwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCkFjZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86QWNlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+QWNlQGlldGYub3JnPC9hPjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2U8 L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkRhbmllbCBN aWdhdWx0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5Fcmljc3NvbjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_70B616BF0F8F47FB801B546D15148223ericssoncom_-- From nobody Sat May 16 19:37:48 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9713A0CC2 for ; Sat, 16 May 2020 19:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 Q0Amr20a6tQg for ; Sat, 16 May 2020 19:37:45 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C6C83A0CC1 for ; Sat, 16 May 2020 19:37:44 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 16 May 2020 19:37:35 -0700 From: Jim Schaad To: 'Ace Wg' References: <158743514464.14263.8072013608148073068@ietfa.amsl.com> In-Reply-To: Date: Sat, 16 May 2020 19:37:33 -0700 Message-ID: <000d01d62bf4$1f708250$5e5186f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01D62BB9.73137F10" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQE/uaPiKQgvpCD+JDHTFstbbTy1lgI3hMxwqca4VrA= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] Fwd: Authentication and Authorization for Constrained Environments (ace) WG Virtual Meeting: 2020-05-18 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2020 02:37:46 -0000 ------=_NextPart_000_000E_01D62BB9.73137F10 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Agenda has been uploaded to the meeting. Note that the list of = upcoming meetings seems to have changed it=E2=80=99s set of links and = for me is not giving a jabber room link nor a WebEx link. Information = on both can be found in the agenda. =20 Jim =20 From: Ace On Behalf Of Daniel Migault Sent: Wednesday, May 13, 2020 8:17 PM To: Ace Wg Subject: [Ace] Fwd: Authentication and Authorization for Constrained = Environments (ace) WG Virtual Meeting: 2020-05-18 =20 Hi,=20 =20 This is a reminder that we have an interim meeting Monday May 18. We are = preparing the agenda, so please let the chairs know if you are willing = to present.=20 =20 Please also upload you slides here by Sunday 23:59 anywhere in the = world. https://datatracker.ietf.org/meeting/interim-2020-ace-06/session/ace=20 =20 Information on the meeting: https://datatracker.ietf.org/meeting/interim-2020-ace-06/session/ace =20 =20 Yours,=20 Jim and Daniel =20 ---------- Forwarded message --------- From: IESG Secretary > Date: Mon, Apr 20, 2020 at 10:12 PM Subject: [Ace] Authentication and Authorization for Constrained = Environments (ace) WG Virtual Meeting: 2020-05-18 To: IETF-Announce > Cc: > The Authentication and Authorization for Constrained Environments (ace) = Working Group will hold a virtual interim meeting on 2020-05-18 from 10:00 to 11:30 = America/New_York (14:00 to 15:30 UTC). Agenda: (No agenda submitted) Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=3Dmd8728a7cd7aa263c70a3c712da89f3e= e _______________________________________________ Ace mailing list Ace@ietf.org =20 https://www.ietf.org/mailman/listinfo/ace =20 --=20 Daniel Migault Ericsson ------=_NextPart_000_000E_01D62BB9.73137F10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Agenda has = been uploaded to the meeting.=C2=A0=C2=A0 Note that the list of upcoming = meetings seems to have changed it=E2=80=99s set of links and for me is = not giving a jabber room link nor a WebEx link. =C2=A0Information on = =C2=A0both can be found in the agenda.

 

Jim

 

From: Ace = <ace-bounces@ietf.org> On Behalf Of Daniel = Migault
Sent: Wednesday, May 13, 2020 8:17 PM
To: = Ace Wg <ace@ietf.org>
Subject: [Ace] Fwd: Authentication = and Authorization for Constrained Environments (ace) WG Virtual Meeting: = 2020-05-18

 

Hi, 

 

This is a reminder that we have an interim meeting = Monday May 18. We are preparing the agenda, so please let the = chairs know if you are willing to = present. 

 

Please also upload you slides here by Sunday 23:59 = anywhere in the world.

 

Information on the = meeting:

 

Yours, 

Jim and = Daniel  

---------- Forwarded message ---------
From: = IESG = Secretary <iesg-secretary@ietf.org>Date: Mon, Apr 20, 2020 at 10:12 PM
Subject: [Ace] Authentication = and Authorization for Constrained Environments (ace) WG Virtual Meeting: = 2020-05-18
To: IETF-Announce <ietf-announce@ietf.org>
= Cc: <ace@ietf.org>



The Authentication and Authorization for = Constrained Environments (ace) Working Group will hold
a virtual = interim meeting on 2020-05-18 from 10:00 to 11:30 America/New_York = (14:00 to 15:30 UTC).

Agenda:
(No agenda = submitted)

Information about remote participation:
https://ietf.webex.com/ietf/j.php?MTID=3Dmd8728a7cd7aa2= 63c70a3c712da89f3ee

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


 

-- =

Daniel = Migault

Ericsson

------=_NextPart_000_000E_01D62BB9.73137F10-- From nobody Sun May 17 20:21:48 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D68C3A088C for ; Sun, 17 May 2020 20:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 CQE26s7ivr19 for ; Sun, 17 May 2020 20:21:46 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B47AB3A0889 for ; Sun, 17 May 2020 20:21:45 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 17 May 2020 20:21:38 -0700 From: Jim Schaad To: 'Francesca Palombini' CC: 'Ace Wg' References: <8063D003-2C48-4157-B80E-B7AF3D2099FC@ericsson.com> <20680.1588694462@localhost> <29287.1588780702@localhost> In-Reply-To: <29287.1588780702@localhost> Date: Sun, 17 May 2020 20:21:35 -0700 Message-ID: <006401d62cc3$70d795f0$5286c1d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQHYz/rnI4HjFcemc1imkKmWhr9LqwIHn/F4Acb/RDkDYpVdMahuW8jw X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] Update of access rights X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 18 May 2020 03:21:48 -0000 I have not had a chance to think this out and get all of the implications right, but my understanding is that what we were trying to avoid was having the same secret key/public key present on the RS in more than one token. This simplifies what the RS needs to do. However, I am now under the impression that having the RS deal with multiple tokens with the same public key might be less of an issue than trying to make some decisions on what tokens are supposed to supersede other tokens. One of the ways that this might be avoided is to push the problem to where it, in some sense, belongs. The AS should be able to make this type of decision if a token is supposed to replace an existing token or not and it has more knowledge about what tokens are associated with what keys. If we go back and say - the AS should include a CWTID in the token and then define a new claim which says - This token supersedes the token(s) with CWTID values of "x", "y" and "z". Jim From nobody Sun May 17 23:32:29 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085B53A0884 for ; Sun, 17 May 2020 23:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 uhXDI4tpMAqN for ; Sun, 17 May 2020 23:32:25 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAAC93A0881 for ; Sun, 17 May 2020 23:32:24 -0700 (PDT) Received: from wangari.tzi.org (p54bded4c.dip0.t-ipconnect.de [84.189.237.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49QThQ2myfzyWg; Mon, 18 May 2020 08:32:22 +0200 (CEST) From: Olaf Bergmann To: Jim Schaad Cc: "'Francesca Palombini'" , "'Ace Wg'" References: <8063D003-2C48-4157-B80E-B7AF3D2099FC@ericsson.com> <20680.1588694462@localhost> <29287.1588780702@localhost> <006401d62cc3$70d795f0$5286c1d0$@augustcellars.com> Date: Mon, 18 May 2020 08:32:21 +0200 In-Reply-To: <006401d62cc3$70d795f0$5286c1d0$@augustcellars.com> (Jim Schaad's message of "Sun, 17 May 2020 20:21:35 -0700") Message-ID: <87eerhkb2i.fsf@wangari> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ace] Update of access rights X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 18 May 2020 06:32:28 -0000 Hi Jim, Jim Schaad writes: > define a new claim which says - This token supersedes the token(s) > with CWTID values of "x", "y" and "z". Isn't this the same as token revocation with all its implications? I would prefer strict token ordering combined with a sound revocation mechanism. In both scenarios, you would still have the issue that the client forwards the superseding token/revocation message if it has a benefit from doing so. Gr=C3=BC=C3=9Fe Olaf From nobody Sun May 17 23:49:47 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 162E23A08A6 for ; Sun, 17 May 2020 23:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 gV8xkGf5I2Hb for ; Sun, 17 May 2020 23:49:42 -0700 (PDT) Received: from weald2.air.saab.se (weald2.air.saab.se [136.163.212.4]) (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 8E5E13A08A3 for ; Sun, 17 May 2020 23:49:41 -0700 (PDT) Received: from mailhub1.air.saab.se ([136.163.213.4]) by weald2.air.saab.se (8.14.4/8.14.4) with ESMTP id 04I6nV4l005940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 18 May 2020 08:49:31 +0200 DKIM-Filter: OpenDKIM Filter v2.11.0 weald2.air.saab.se 04I6nV4l005940 Received: from corpappl16350.corp.saab.se (corpappl16350.corp.saab.se [10.12.12.113]) by mailhub1.air.saab.se (8.13.8/8.13.8) with ESMTP id 04I6mxbm022533 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 18 May 2020 08:49:00 +0200 Received: from corpappl16593.corp.saab.se (10.12.12.125) by corpappl16350.corp.saab.se (10.12.12.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Mon, 18 May 2020 08:48:59 +0200 Received: from corpappl16593.corp.saab.se ([fe80::b4c9:ca69:a80d:fa3]) by corpappl16593.corp.saab.se ([fe80::b4c9:ca69:a80d:fa3%4]) with mapi id 15.01.1847.009; Mon, 18 May 2020 08:48:59 +0200 From: Seitz Ludwig To: Jim Schaad , "'Francesca Palombini'" CC: "'Ace Wg'" Thread-Topic: [Ace] Update of access rights Thread-Index: AQHWIuI1Lkw8gf+fQkGotEAa9X56JaiZhXQAgAAafoCAAXcYAIASCIiAgABYuGA= Date: Mon, 18 May 2020 06:48:59 +0000 Message-ID: References: <8063D003-2C48-4157-B80E-B7AF3D2099FC@ericsson.com> <20680.1588694462@localhost> <29287.1588780702@localhost> <006401d62cc3$70d795f0$5286c1d0$@augustcellars.com> In-Reply-To: <006401d62cc3$70d795f0$5286c1d0$@augustcellars.com> Accept-Language: en-SE, sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.12.13.211] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Saab-MailScanner-Information: Please contact the ISP for more information X-Saab-MailScanner-ID: 04I6mxbm022533 X-Saab-MailScanner: Found to be clean X-Saab-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=1.561, required 5, ALL_TRUSTED -1.00, SARE_MLB_Stock6 1.56, SURBL_BLOCKED 1.00, URIBL_BLOCKED 0.00) X-Saab-MailScanner-SpamScore: s X-Saab-MailScanner-From: ludwig.seitz@combitech.se X-Saab-MailScanner-Watermark: 1590389340.26303@KexJLY5R5FLVFcUqviazkQ X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (weald2.air.saab.se [136.163.212.4]); Mon, 18 May 2020 08:49:31 +0200 (CEST) Archived-At: Subject: Re: [Ace] Update of access rights X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 18 May 2020 06:49:45 -0000 Hi Jim, This sounds over-engineered to me.=20 If we go for introducing new claims (or putting requirements on existing on= es like 'cti'), I would suggest to EITHER Use the solution recommended in the framework today: One token per pop-key,= new token overwrites old token, adding a strict ordering, e.g. by requirin= g that the AS uses a incremented number in the cti claim (or a new claim if we don't w= ant to use cti for that). This would introduce part of what Olaf suggested= , i.e. a strict ordering. OR=20 Go with Olaf's full suggestion and introduce a revocation mechanism. /Ludwig -----Original Message----- From: Ace On Behalf Of Jim Schaad Sent: den 18 maj 2020 05:22 To: 'Francesca Palombini' Cc: 'Ace Wg' Subject: Re: [Ace] Update of access rights I have not had a chance to think this out and get all of the implications r= ight, but my understanding is that what we were trying to avoid was having = the same secret key/public key present on the RS in more than one token. This simplifies what the RS needs to do. However, I am now under the impre= ssion that having the RS deal with multiple tokens with the same public key= might be less of an issue than trying to make some decisions on what token= s are supposed to supersede other tokens. One of the ways that this might be avoided is to push the problem to where = it, in some sense, belongs. The AS should be able to make this type of dec= ision if a token is supposed to replace an existing token or not and it has= more knowledge about what tokens are associated with what keys. If we go = back and say - the AS should include a CWTID in the token and then define a= new claim which says - This token supersedes the token(s) with CWTID value= s of "x", "y" and "z". =20 Jim _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Mon May 18 04:41:02 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 352C93A0B12 for ; Mon, 18 May 2020 04:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 xbzkeX1r7IvU for ; Mon, 18 May 2020 04:40:58 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A5A03A0B10 for ; Mon, 18 May 2020 04:40:58 -0700 (PDT) Received: from [192.168.217.119] (p548dc699.dip0.t-ipconnect.de [84.141.198.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49QcXS2MBWzyY9; Mon, 18 May 2020 13:40:56 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <2553abc4-aa8d-2c51-f0fe-1e14cd6ac1e9@ri.se> Date: Mon, 18 May 2020 13:40:55 +0200 Cc: Ace Wg X-Mao-Original-Outgoing-Id: 611494855.639276-58539704c5245c3e7f3f245e12107661 Content-Transfer-Encoding: quoted-printable Message-Id: References: <158378192037.5591.12867128151701682367@ietfa.amsl.com> <2553abc4-aa8d-2c51-f0fe-1e14cd6ac1e9@ri.se> To: Marco Tiloca X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Ace] [ace] Fwd: New Version Notification for draft-tiloca-ace-revoked-token-notification-01.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 18 May 2020 11:41:01 -0000 >=20 > Comments are very welcome. (1) I can=E2=80=99t parse the binary representation of the String value of ENCODED_TOKEN, which would depend on the used charset. What charset? JSON does not have a charset. (I=E2=80=99m probably = misreading this.) What *is* the =E2=80=9CString value of ENCODED_TOKEN=E2=80=9D? (2) query parameters: diff=3Dtrue and N=3DI are a bit redundant to each = other. If you have N, you need to have diff=3Dtrue, which therefore can = be omitted. diff=3DI or diff (no equals sign) would therefore be = simpler forms of this. (3) Re CDDL: I read this as token-hash =3D bytes trl =3D [* token-hash] diff-entry =3D {removed =3D> trl, added =3D> trl} diff =3D [* diff-entry] removed =3D 0 added =3D 1 I would simplify diff-entry as a record instead of a struct ( = https://tools.ietf.org/html/rfc8610#section-2 ): diff-entry =3D [removed: trl, added: trl] i.e., leave out the labels and rely on the order in the array. I didn=E2=80=99t make up CDDL for the registration response, as I = don=E2=80=99t know what the =E2=80=9C=E2=80=A6=E2=80=9D is. (4) Why do we need all that precision what was added and removed when? (5) On the diff stream, please see also STP:=20 https://tools.ietf.org/html/draft-bormann-t2trg-stp-03 Gr=C3=BC=C3=9Fe, Carsten From nobody Mon May 18 06:13:49 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC633A0B46 for ; Mon, 18 May 2020 06:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 2InNdN3GsPHu for ; Mon, 18 May 2020 06:13:46 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A20F3A0ABE for ; Mon, 18 May 2020 06:13:45 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 18 May 2020 06:13:20 -0700 From: Jim Schaad To: 'Olaf Bergmann' CC: 'Francesca Palombini' , 'Ace Wg' References: <8063D003-2C48-4157-B80E-B7AF3D2099FC@ericsson.com> <20680.1588694462@localhost> <29287.1588780702@localhost> <006401d62cc3$70d795f0$5286c1d0$@augustcellars.com> <87eerhkb2i.fsf@wangari> In-Reply-To: <87eerhkb2i.fsf@wangari> Date: Mon, 18 May 2020 06:13:18 -0700 Message-ID: <008a01d62d16$1a934d80$4fb9e880$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQHYz/rnI4HjFcemc1imkKmWhr9LqwIHn/F4Acb/RDkDYpVdMQHR58enAwOeLE+oSFVQgA== X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] Update of access rights X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 18 May 2020 13:13:48 -0000 As I said, I have not fully thought it out. A better way to state this = might be - this token uses the same key as rather than implying = overriding. -----Original Message----- From: Olaf Bergmann =20 Sent: Sunday, May 17, 2020 11:32 PM To: Jim Schaad Cc: 'Francesca Palombini' ; 'Ace Wg' = Subject: Re: [Ace] Update of access rights Hi Jim, Jim Schaad writes: > define a new claim which says - This token supersedes the token(s)=20 > with CWTID values of "x", "y" and "z". Isn't this the same as token revocation with all its implications? I = would prefer strict token ordering combined with a sound revocation = mechanism. In both scenarios, you would still have the issue that the = client forwards the superseding token/revocation message if it has a = benefit from doing so. Gr=C3=BC=C3=9Fe Olaf From nobody Mon May 18 08:21:44 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB2A33A0765 for ; Mon, 18 May 2020 08:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 EwuhltLrrErL for ; Mon, 18 May 2020 08:21:41 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB28B3A053E for ; Mon, 18 May 2020 08:21:40 -0700 (PDT) Received: from [192.168.217.119] (p548dc699.dip0.t-ipconnect.de [84.141.198.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49QjR65d2YzybZ; Mon, 18 May 2020 17:21:38 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 611508098.2229871-50011e8fa52f5359aa98047e9ab2c652 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 18 May 2020 17:21:38 +0200 Message-Id: To: Ace Wg X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [Ace] AIF as a suggestion in key-groupcomm; AIF in MQTT X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 18 May 2020 15:21:43 -0000 As I said today, the role of AIF [1] in ACE documents can only be as a = suggestion, or as a starting point, because it assumes that the = (resource) names are static, and something application-specific has to = be added for more dynamic names. The current MQTT proposal [2] is different in three ways: (1) it has different verbs (publish, subscribe) (2) it uses topic filters instead of resource names (3) it uses a text-based syntax. I think that (3) has all the usual problems, so I would recommend = against this. (1) and (2) can be mapped to the structure of AIF without any pain, and = I would recommend for this. In summary, essence, AIF could be made useful as the base suggestion for = MQTT as well as REST, with the refinement for verbs and filters retained = in the current draft. Gr=C3=BC=C3=9Fe, Carsten [1]: https://tools.ietf.org/html/draft-bormann-core-ace-aif [2]: = https://tools.ietf.org/html/draft-ietf-ace-mqtt-tls-profile-04#section-3= From nobody Mon May 18 08:47:23 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135613A0809 for ; Mon, 18 May 2020 08:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 mgmeNdGsamCT for ; Mon, 18 May 2020 08:47:21 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9EFD3A0816 for ; Mon, 18 May 2020 08:47:20 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 18 May 2020 08:47:12 -0700 From: Jim Schaad To: 'Ace Wg' Date: Mon, 18 May 2020 08:47:10 -0700 Message-ID: <009301d62d2b$9908e930$cb1abb90$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AdYtK45xWwDiBV7FR52+xcGhtMO+QA== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Ace] Interim minutes X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 18 May 2020 15:47:22 -0000 I have posted the minutes - review and comment as appropriate. From nobody Mon May 18 09:12:20 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2561F3A082A for ; Mon, 18 May 2020 09:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 ZtaEuvD1gvrI for ; Mon, 18 May 2020 09:12:16 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 728E53A083B for ; Mon, 18 May 2020 09:12:16 -0700 (PDT) Received: from [192.168.217.119] (p548dc699.dip0.t-ipconnect.de [84.141.198.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49QkYW01kXzybZ; Mon, 18 May 2020 18:12:14 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Mon, 18 May 2020 18:12:14 +0200 X-Mao-Original-Outgoing-Id: 611511133.987774-3b8484438d8a6f736a9d018ff44f302e Content-Transfer-Encoding: quoted-printable Message-Id: <6E0205F6-250C-433C-A09F-C0F2E0E44D00@tzi.org> References: To: Ace Wg X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Ace] AIF as a suggestion in key-groupcomm; AIF in MQTT X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 18 May 2020 16:12:19 -0000 On 2020-05-18, at 17:21, Carsten Bormann wrote: >=20 > [1]: https://tools.ietf.org/html/draft-bormann-core-ace-aif Benjamin reminds me that this has -core- as the crucial third word of = the draft name. I hope that doesn=E2=80=99t get in the way if we decide to pick this up = as an (informational) ACE document (I could resubmit this under a = different name, but that would be confusing). Or we (ACE) could actually decide to throw this back over the fence to = CoRE? Gr=C3=BC=C3=9Fe, Carsten From nobody Mon May 18 13:43:23 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10D53A0C66 for ; Mon, 18 May 2020 13:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 g1UiABZm0u2Q for ; Mon, 18 May 2020 13:43:20 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61AC33A08E0 for ; Mon, 18 May 2020 13:43:20 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 18 May 2020 13:43:11 -0700 From: Jim Schaad To: 'Carsten Bormann' , 'Ace Wg' References: <6E0205F6-250C-433C-A09F-C0F2E0E44D00@tzi.org> In-Reply-To: <6E0205F6-250C-433C-A09F-C0F2E0E44D00@tzi.org> Date: Mon, 18 May 2020 13:43:09 -0700 Message-ID: <00aa01d62d54$f26cd5d0$d7468170$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQIwPzJEXwhD6Q4/OYYYLiL0BLKOowLavOMZp+NVaqA= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] AIF as a suggestion in key-groupcomm; AIF in MQTT X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 18 May 2020 20:43:22 -0000 That is not an issue. If you ask for adoption, we can adopt any draft = with any name. -----Original Message----- From: Ace On Behalf Of Carsten Bormann Sent: Monday, May 18, 2020 9:12 AM To: Ace Wg Subject: Re: [Ace] AIF as a suggestion in key-groupcomm; AIF in MQTT On 2020-05-18, at 17:21, Carsten Bormann wrote: >=20 > [1]: https://tools.ietf.org/html/draft-bormann-core-ace-aif Benjamin reminds me that this has -core- as the crucial third word of = the draft name. I hope that doesn=E2=80=99t get in the way if we decide to pick this up = as an (informational) ACE document (I could resubmit this under a = different name, but that would be confusing). Or we (ACE) could actually decide to throw this back over the fence to = CoRE? Gr=C3=BC=C3=9Fe, Carsten _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Thu May 21 11:49:42 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B70A43A0602 for ; Thu, 21 May 2020 11:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEbIppfBDDvI for ; Thu, 21 May 2020 11:49:35 -0700 (PDT) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 5C20C3A065A for ; Thu, 21 May 2020 11:49:35 -0700 (PDT) Received: by mail-vs1-xe32.google.com with SMTP id u7so4679695vsp.7 for ; Thu, 21 May 2020 11:49:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=z6NmPDwMuFAV3os6HrWun9sYI5iFOWlnDlS43EwRJU4=; b=RLRYJQDXgqODO6ihkqt8H7hAc0E7BRTvGk8gu2M5FSnaI1nhmX46tmheIiszgMmkkO /YW9CvN8L7RIBnRprwHzY/qkMm0VLeQlsJunS9ihStRMh9dBgzBJAB2NPMNkFjyL62y0 OkLBJYEZLWFn4+T/MohLrC7BNIgQos+U2uWz1EFwUFLgMTvDSGzjGdEKEXsHXhQudLne 05dQWxOCNqlX1YGXt6Ud0ll03dnHgdAHP+0so2C0f65f84gtXm27fxZIpS6WFtbXWRvR +RinXpjeVK25ZYOrJDXUu4Fk10OeG+jFzh8hY59r/2XPQ+Rzq+mi4br8RHJhScYvknsq LFlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=z6NmPDwMuFAV3os6HrWun9sYI5iFOWlnDlS43EwRJU4=; b=boneLNX+SyhRzuedGGpO/b+m/a18WnNvGxQpNfnPa8xpwWH7wc/dAMlbvzgQwA6VuN RfkENH+mGuZW/iUv8TWqJe+gOOuJslMx3qQr9VMnzSj7Ur5+Z9KUG9SnBrmKm0fiDhC8 zillnKy1guQqCB4uVaysHBkeYlt4P+mChLvr3n5VcPYWG/MU+yFGPwilU+bfku2snH3t Bl/w1LPkIhwwSl3Gfg5bfzJ7UXX3mfkz2CWxlkZuxAzFPNAzd4D+9OFsXPXMiybWzzCl 69yDhhDEus6b6ecFYTX7IhnauqrL3QLibcONL+mKaIAoR6iB+OQyf/FMpumH7ggEEUnr skMQ== X-Gm-Message-State: AOAM532Q0Ix67UT8nbynYXUFTS5e+nbqj+NHQ5aHLceoymuNPTIlcKOI Bmt1S2qHIBJEBYPNWgVPVTxLf7t7b4jXjvFJWDYplMK1 X-Google-Smtp-Source: ABdhPJxdHvDhTIcWpcv44lmaM0VhcOE5JoKKlhxkIg75rOBXfX6qawIXs1GMtqdOPKNkoOgQok24XIWdX8F6UR5/4Pw= X-Received: by 2002:a67:cb96:: with SMTP id h22mr8642825vsl.97.1590086973120; Thu, 21 May 2020 11:49:33 -0700 (PDT) MIME-Version: 1.0 From: Daniel Migault Date: Thu, 21 May 2020 14:49:21 -0400 Message-ID: To: Ace Wg Content-Type: multipart/alternative; boundary="00000000000031e31b05a62cf946" Archived-At: Subject: [Ace] questions on draft-ietf-ace-key-groupcomm-06 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 21 May 2020 18:49:40 -0000 --00000000000031e31b05a62cf946 Content-Type: text/plain; charset="UTF-8" Hi, Please find some questions / comments regarding the draft draft-ietf-ace-key-groupcomm-06. I suspect that most of the questions are clarifications for me to better understand the context. Yours, Daniel Key Provisioning for Group Communication using ACE draft-ietf-ace-key-groupcomm-06 [...] 2. Overview +------------+ +-----------+ | AS | | KDC | | | .-------->| | +------------+ / +-----------+ ^ / | / v / +-----------+ +------------+ / +------------+ |+-----------+ | Client |<-' | Dispatcher | ||+-----------+ | |<-------->| (RS) |<------->|| Group | +------------+ +------------+ +| members | +-----------+ Figure 1: Key Distribution Participants The following participants (see Figure 1) take part in the authorization and key distribution. * Client (C): node that wants to join the group communication. It can request write and/or read rights. * Authorization Server (AS): same as AS in the ACE Framework; it enforces access policies, and knows if a node is allowed to join a given group with write and/or read rights. * Key Distribution Center (KDC): maintains the keying material to protect group communications, and provides it to Clients authorized to join a given group. During the first part of the exchange (Section 3), it takes the role of the RS in the ACE Framework. During the second part (Section 4), which is not based on the ACE Framework, it distributes the keying material. In Palombini & Tiloca Expires 12 November 2020 [Page 4] Internet-Draft Key Provisioning for Group Communication May 2020 addition, it provides the latest keying material to group members when requested or, if required by the application, when membership changes. The figure indicates the dispatcher as the RS. I have the impression that in our case the KDC could be seen as the RS that provides the necessary material to access the dispatcher. From the text it seems that no authorisation control is performed at the dispatcher, access is granted by the ownership of the (shared) keying material. For that reason I am wondering why do we consider the dispatcher as the RS instead of the KDC. * Dispatcher: entity through which the Clients communicate with the group and which distributes messages to the group members. Examples of dispatchers are: the Broker node in a pub-sub setting; a relayer node for group communication that delivers group messages as multiple unicast messages to all group members; an implicit entity as in a multicast communication setting, where messages are transmitted to a multicast IP address and delivered on the transport channel. This document specifies a mechanism for: * Authorizing a new node to join the group (Section 3), and providing it with the group keying material to communicate with the other group members (Section 4). * A node to leave the group of for the KDC to remove a current member of the group (Section 5). * Retrieving keying material as a current group member (Section 4.3 and Section 4.4). * Renewing and re-distributing the group keying material (rekeying) upon a membership change in the group (Section 4.9 and Section 5). Figure 2 provides a high level overview of the message flow for a node joining a group communication setting, which can be expanded as follows. 1. The joining node requests an Access Token from the AS, in order to access a specific group-membership resource on the KDC and hence join the associated group. The joining node will start or continue using a secure communication association with the KDC, according to the response from the AS. "continue using a secure communication" is here I think to indicate that establishment of a new secure communication is not necessary. If that is correct, we we could clarify that by adding the communication to the AS is secured. 2. The joining node transfers authentication and authorization information to the KDC, by posting the obtained Access Token to the /authz-info endpoint at the KDC. After that, a joining node MUST have a secure communication association established with the KDC, before starting to join a group under that KDC. Possible ways to provide a secure communication association are DTLS [RFC6347] and OSCORE [RFC8613]. The relation between the KDC (application) and the secure transport or communication is not entiorely clear to me. A secure communication includes authentication of the peers and encryption of the traffic. I suppose that encryption is performed by DTLS or OSCORE, but I am wondering if authentication and authorization are performed by the DTLS layer or by the KDC application. I have the impression that KDC is entirely relying on DTLS/OSCORE for encryption and authentication/authorisation because the text seems to assume that authz-info may be not protected. I thus assume authorization is characterized by the ability to set a DTLS/OSCORE session. Of course other information will be needed by the KDC (scope for exampel). If this use case makes sense, it might be good to clarify the interactions between dtls-authorized works, in particular how these access tokens ( the merged access token) are/is used. The other alternative could be to set an unauthenticated DTLS/OSCORE and then proceed to the communication of the access token. [ ...] 3. Authorization to Join a Group This section describes in detail the format of messages exchanged by the participants when a node requests access to a group. This exchange is based on ACE [I-D.ietf-ace-oauth-authz]. As defined in [I-D.ietf-ace-oauth-authz], the Client requests from the AS an authorization to join the group through the KDC (see Section 3.1). If the request is approved and authorization is granted, the AS provides the Client with a proof-of-possession access token and parameters to securely communicate with the KDC (see Section 3.2). Communications between the Client and the AS MUST be secured, as defined by the transport profile of ACE used. The Content-Format used in the messages is the one specified by the used transport profile of ACE (e.g. application/ace+cbor for the first two messages and application/cwt for the third message, depending on the format of the access token). At that point, I assume that Client to AS communication is secured via a standard DTLS session. I am wondering if the POST can be unsecured or is send over a secure channel. The transport profile of ACE also defines a number of details such as the communication and security protocols used with the KDC (see Appendix C of [I-D.ietf-ace-oauth-authz]). Figure 3 gives an overview of the exchange described above. Client AS KDC | | | |---- Authorization Request: POST /token ------>| | | | | |<--- Authorization Response: 2.01 (Created) ---| | | | | |----- POST Token: POST /authz-info --------------->| | | Figure 3: Message Flow of Join Authorization 3.1. Authorization Request The Authorization Request sent from the Client to the AS is as defined in Section 5.6.1 of [I-D.ietf-ace-oauth-authz] and MAY contain the following parameters, which, if included, MUST have the corresponding values: I believe that some parameters are mandatory. If that is the case, it would be good to explain which parameters are optional or mandatory. * 'scope', containing the identifier of the specific group(s), or topic(s) in the case of pub-sub, that the Client wishes to access, and optionally the role(s) that the Client wishes to take. Palombini & Tiloca Expires 12 November 2020 [Page 7] Internet-Draft Key Provisioning for Group Communication May 2020 This value is a CBOR byte string, encoding a CBOR array of one or more entries. from the text above I understand that the value is the output of a CBOR object, which somehow requires the CBOR compression to be run twice. I might be missing something, but it seems unclear to me why this should be different from: This value is an array of one or more entries. This is my understanding from the text: scope = [ entry, entry ] entry = [group_id, ([ role, role, ] )] An entry has as value a CBOR array, which contains: - As first element, the identifier of the specific group or topic. - Optionally, as second element, the role (or CBOR array of roles) that the Client wishes to take in the group. This element is optional since roles may have been pre-assigned to the Client, as associated to its verifiable identity credentials. Alternatively, the application may have defined a single, well-known role for the target resource(s) and audience(s). In each entry, the encoding of the group or topic identifier (REQ1) and of the role identifiers (REQ2) is application specific, and part of the requirements for the application profile. Maybe it would worth specifying the reference the REQ refer to. [...] 3.2. Authorization Response The Authorization Response sent from the AS to the Client is as defined in Section 5.6.2 of [I-D.ietf-ace-oauth-authz] and MUST contain the following parameters: * 'access_token', containing the proof-of-possession access token. * 'cnf' if symmetric keys are used, not present if asymmetric keys are used. This parameter is defined in Section 3.2 of [I-D.ietf-ace-oauth-params] and contains the symmetric proof-of- possession key that the Client is supposed to use with the KDC. * 'rs_cnf' if asymmetric keys are used, not present if symmetric keys are used. This parameter is as defined in Section 3.2 of [I-D.ietf-ace-oauth-params] and contains information about the public key of the KDC. * 'expires_in', contains the lifetime in seconds of the access token. This parameter MAY be omitted if the application defines how the expiration time is communicated to the Client via other means, or if it establishes a default value. Additionally, the Authorization Response MAY contain the following parameters, which, if included, MUST have the corresponding values: * 'scope' containing the granted scope, if different from the scope requested by the client. This parameter has the same format and encoding of 'scope' in the Authorization Request, defined in Section 3.1. * Other additional parameters as defined in [I-D.ietf-ace-oauth-authz], if necessary. The proof-of-possession access token (in 'access_token' above) MUST contain the following parameters: Palombini & Tiloca Expires 12 November 2020 [Page 9] Internet-Draft Key Provisioning for Group Communication May 2020 * a confirmation claim (see for example 'cnf' defined in Section 3.1 of [RFC8747] for CWT); * an expiration time claim (see for example 'exp' defined in Section 3.1.4 of [RFC8392] for CWT); * a scope claim (see for example 'scope' registered in Section 8.13 of [I-D.ietf-ace-oauth-authz] for CWT). This claim has the same encoding as 'scope' parameter above. Additionally, this claim has the same value of the 'scope' parameter if the parameter is present in the message, or it takes the value of 'scope' in the Authorization Request otherwise. The access token MAY additionally contain other claims that the transport profile of ACE requires, or other optional parameters. As in [I-D.ietf-ace-oauth-authz], these parameters are included in the payload, which is formatted as a CBOR map. The Content-Format "application/ace+cbor" is used. When receiving an Authorization Request from a Client that was previously authorized, and for which the AS still owns a valid non expired access token, the AS MAY reply with that token. Note that it is up to application profiles of ACE to make sure that re-posting the same token does not cause re-use of keying material between nodes (for example, that is done with the use of random nonces in [I-D.ietf-ace-oscore-profile]). I am wondering if it is expected the client reads the values contained in the access_token. I suppose not, and even when the acces_token is not encrypted the client is supposed to pass the access token as opaque data to the KDC. Is that correct ? I am also wondering how the AS could inform which transport are available to the KDC. What is a little bit unclear to me is when the access token is combined with another access token from the transport layer. I suppose that the two tokens are "merged" in some ways and I am wondering if the transport access token is expected to include those of the upper layers in our case the KDC. 3.3. Token Post The Client sends a CoAP POST request including the access token to the KDC, as specified in Section 5.8.1 of [I-D.ietf-ace-oauth-authz]. If the specific transport profile of ACE defines it, the Client MAY use a different endpoint than /authz-info at the KDC to post the access token to. I think the overview section mentions application/cwt is used for that exchange. I think it might be helpful to specify that post uses application/cwt since later we indicate that application/ace+cbor may carry another meaning. It might worth updating this section as well. I also have the impression that the response to the post is called "AS Request Creation Hints". If that is correct, the designation is misleading, as hints are not targeting the AS in the case. Maybe that would be good to indicate this is this exchange that is being considered with a different meaning as it has been defined in the framework. If that is still correct, I am wondering how the client can make a difference between the AS Request Creation Hints as a Response that provides additional information related to the group communication. In particular I am wondering if parameters are used to distinguish these two responses. Optionally, the Client might want to request necessary information concerning the public keys in the group, as well as concerning the algorithm and related parameters for computing signatures in the group. In such a case, the joining node MAY ask for that information to the KDC in this same request. To this end, it sends the CoAP POST request to the /authz-info endpoint using the Content-Format "application/ace+cbor". The payload of the message MUST be formatted as a CBOR map, including the access token and the following parameters: * 'sign_info' defined in Section 3.3.1. Palombini & Tiloca Expires 12 November 2020 [Page 10] Internet-Draft Key Provisioning for Group Communication May 2020 * 'pub_key_enc' defined in Section 3.3.2, encoding the CBOR simple value Null, to require information on the exact encoding of public keys used in the group. Alternatively, the joining node may retrieve this information by other means. After successful verification, the Client is authorized to receive I am wondering if the verification goes beyond the signature validation. The remaining of the text seems also to assume that ace+cbor is used. Is that correct ? the group keying material from the KDC and join the group. In particular, the KDC replies to the Client with a 2.01 (Created) response, using Content-Format "application/ace+cbor" defined in Section 8.14 of [I-D.ietf-ace-oauth-authz]. The payload of the 2.01 response is a CBOR map. If the access token contains a role that requires the Client to send its own public key to the KDC when joining the group, the CBOR map MUST include the parameter 'kdcchallenge' defined in Section Section 3.3.3, specifying a dedicated challenge N_S generated by the KDC. I am wondering how the client provides the public key, and I am wondering if the public key is not provided through the access_token to the KDC. If that would be correct, it seems then that the key is provided by the AS or the access token instead of the client. Maybe the public keys are those of the members of the group. The Client uses this challenge to prove possession of its own private key (see the 'client_cred_verify' parameter in Section 4). I have not yet read section 4, but it seems that additional exchanges are performed that goes beyond the Token post exchange. If my understanding is correct, I am wondering if that description fits the title of this section. Note that the payload format of the response deviates from the default as defined in the ACE framework (see Section 5.8.1 of [I-D.ietf-ace-oauth-authz]). The KDC MUST store the 'kdcchallenge' value associated to the Client at least until it receives a join request from it (see Section 4.2), to be able to verify the proof of possession. The same challenge MAY be reused several times by the Client, to generate new proof of possessions, e.g. in case of update of the public key, or to join a different group with a different key, so it is RECOMMENDED that the KDC keeps storing the 'kdcchallenge' after the first join is processed as well. If the KDC has already discarded the 'kdcchallenge', that will trigger an error response with a newly generated 'kdcchallenge' that the client can use to restart the join process, as specified in Section 4.2. If either of 'sign_info' or 'pub_key_enc' were included in the request, the KDC MAY include the 'sign_info' parameter defined in Section 3.3.1, optionally including the 'pub_key_enc' parameter Section 3.3.2. The 'sign_info' parameter MUST be present if the POST request included the 'sign_info' parameter and/or the pub_key_enc with value Null. The encoding of the 'sign_info' parameter in the response is defined in Section 3.3.2. Note that the field 'id' takes the value of the group identifier for which the 'sign_info' applies to, in this specification. Palombini & Tiloca Expires 12 November 2020 [Page 11] Internet-Draft Key Provisioning for Group Communication May 2020 Note that the CBOR map specified as payload of the 2.01 (Created) response may include further parameters, e.g. according to the signalled transport profile of ACE. Applications of this specification MAY define alternative specific negotiations of parameter values for signature algorithm and signature keys, if 'sign_info' and 'pub_key_enc' are not used (OPT2). 3.3.1. 'sign_info' Parameter The 'sign_info' parameter is an OPTIONAL parameter of the AS Request Creation Hints message defined in Section 5.1.2. of [I-D.ietf-ace-oauth-authz]. The text can be read as 'sign_info' is defined in Section 5.1.2. I believe that clarifying the response is designated in the framework as AS Request Creation Hints but has a different meaning here may solve this issue. [...] 3.3.2. 'pub_key_enc' Parameter The 'pub_key_enc' parameter is an OPTIONAL parameter of the AS Request Creation Hints message defined in Section 5.1.2. of [I-D.ietf-ace-oauth-authz]. This parameter contains information about the exact encoding of public keys to be used between the Client and the RS. Its exact content is application specific. In this specification and in application profiles building on it, this parameter is used to ask the KDC information about the encoding of public keys used in the group. The CDDL notation of the 'pub_key_enc' parameter formatted as in the request is given below. pub_key_enc_req = nil It is not entirely clear to me what pub_key_enc is about. It is the format of the public key itself or the encryption algorithm ? Then it is unclear to me which public key is referred to. "public keys used in the group" make me think of a private/public key that is shared by all members of the group. This public key is used with the RS, that is the dispatcher, not to authenticate the client. Am I correct ? 3.3.3. 'kdcchallenge' Parameter The 'kdcchallenge' parameter is an OPTIONAL parameter of the AS Request Creation Hints message defined in Section 5.1.2. of [I-D.ietf-ace-oauth-authz]. This parameter contains a challenge generated by the KDC and provided to the Client. The Client may use this challenge to prove possession of its own private key in the Joining Request ((see the 'client_cred_verify' parameter in Section 4). I suppose that will be clarified in section , but of "its own private key" make me think that the key in question is to authenticate the client, instead of the key used for the group. If that is correct, it is unclear to me why there is a need to authenticate the client and why this should not be performed instead by the AS. It seems I am missing something here. 4. Keying Material Provisioning and Group Membership Management [...] Upon receiving a request from a Client, the KDC MUST check that it is storing a valid access token from that Client for the group identifier assiciated associated to the endpoint. If that is not the case, i.e. the KDC does not store a valid access token or this is not valid for that Client for the group identifier at hand, the KDC MUST respond to the Client with a 4.01 (Unauthorized) error message. 4.1. Interface at the KDC The KDC is configured with the following resources. Note that the root url-path "ace-group" given here are default names: implementations are not required to use these names, and can define their own instead. The Interface Description (if=) Link Target Attribute value ace-group is registered (Section 8.9) and can be used to describe this inferface. interface. -- Daniel Migault Ericsson --00000000000031e31b05a62cf946 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Please find some questions / = comments regarding the draft=C2=A0draft-ietf-ace-key-groupcomm-06. I suspec= t that most of the questions are clarifications for me to better understand= the context.=C2=A0=C2=A0

Yours,=C2=A0
Daniel



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Key Provision= ing for Group Communication using ACE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-ace-key-groupcomm-06
[...= ]

2.=C2=A0 Overview

=C2=A0 =C2=A0 =C2=A0 =C2=A0+------------+= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-----------= +
=C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 AS =C2=A0 =C2=A0 | =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0KDC = =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0.-------->| =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0+------------+ =C2=A0 =C2= =A0 =C2=A0 / =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-----------+
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 /
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0v =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 / =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------= +
=C2=A0 =C2=A0 =C2=A0 =C2=A0+------------+ =C2=A0 / =C2=A0 =C2=A0 =C2= =A0+------------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0|+-----------+
=C2=A0 =C2= =A0 =C2=A0 =C2=A0| =C2=A0 Client =C2=A0 |<-' =C2=A0 =C2=A0 =C2=A0 | = Dispatcher | =C2=A0 =C2=A0 =C2=A0 =C2=A0||+-----------+
=C2=A0 =C2=A0 = =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-------->| = =C2=A0 =C2=A0(RS) =C2=A0 =C2=A0|<------->|| =C2=A0 Group =C2=A0 |
= =C2=A0 =C2=A0 =C2=A0 =C2=A0+------------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+------------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 +| =C2=A0members =C2=A0|
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-----------+

=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure 1: Key Dist= ribution Participants

=C2=A0 =C2=A0The following participants (see F= igure 1) take part in the
=C2=A0 =C2=A0authorization and key distributio= n.

=C2=A0 =C2=A0* =C2=A0Client (C): node that wants to join the grou= p communication.=C2=A0 It
=C2=A0 =C2=A0 =C2=A0 can request write and/or = read rights.

=C2=A0 =C2=A0* =C2=A0Authorization Server (AS): same as= AS in the ACE Framework; it
=C2=A0 =C2=A0 =C2=A0 enforces access polici= es, and knows if a node is allowed to join a
=C2=A0 =C2=A0 =C2=A0 given = group with write and/or read rights.

=C2=A0 =C2=A0* =C2=A0Key Distri= bution Center (KDC): maintains the keying material to
=C2=A0 =C2=A0 =C2= =A0 protect group communications, and provides it to Clients
=C2=A0 =C2= =A0 =C2=A0 authorized to join a given group.=C2=A0 During the first part of= the
=C2=A0 =C2=A0 =C2=A0 exchange (Section 3), it takes the role of the= RS in the ACE
=C2=A0 =C2=A0 =C2=A0 Framework.=C2=A0 During the second p= art (Section 4), which is not based
=C2=A0 =C2=A0 =C2=A0 on the ACE Fram= ework, it distributes the keying material.=C2=A0 In



Palombin= i & Tiloca =C2=A0 =C2=A0 =C2=A0Expires 12 November 2020 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 4]
=0C
Internet-Draft = =C2=A0Key Provisioning for Group Communication =C2=A0 =C2=A0 =C2=A0 =C2=A0M= ay 2020


=C2=A0 =C2=A0 =C2=A0 addition, it provides the latest ke= ying material to group members
=C2=A0 =C2=A0 =C2=A0 when requested or, i= f required by the application, when membership
=C2=A0 =C2=A0 =C2=A0 chan= ges.

<mglt>

The figure indicates the dispatcher as the = RS. =C2=A0I
have the impression that in our case the KDC could
be see= n as the RS that provides the necessary
material to access the dispatche= r.=C2=A0 From the text
it seems that no authorisation control is
perf= ormed at the dispatcher, access is granted by
the ownership of the (shar= ed) keying material.
For that reason I am wondering why do we considerthe dispatcher as the RS instead of the KDC.

</mglt>
=C2=A0 =C2=A0* =C2=A0Dispatcher: entity through which the Clients communic= ate with the
=C2=A0 =C2=A0 =C2=A0 group and which distributes messages t= o the group members.
=C2=A0 =C2=A0 =C2=A0 Examples of dispatchers are: t= he Broker node in a pub-sub setting;
=C2=A0 =C2=A0 =C2=A0 a relayer node= for group communication that delivers group
=C2=A0 =C2=A0 =C2=A0 messag= es as multiple unicast messages to all group members; an
=C2=A0 =C2=A0 = =C2=A0 implicit entity as in a multicast communication setting, where
= =C2=A0 =C2=A0 =C2=A0 messages are transmitted to a multicast IP address and= delivered
=C2=A0 =C2=A0 =C2=A0 on the transport channel.

=C2=A0 = =C2=A0This document specifies a mechanism for:

=C2=A0 =C2=A0* =C2=A0= Authorizing a new node to join the group (Section 3), and
=C2=A0 =C2=A0 = =C2=A0 providing it with the group keying material to communicate with
= =C2=A0 =C2=A0 =C2=A0 the other group members (Section 4).

=C2=A0 =C2= =A0* =C2=A0A node to leave the group of for the KDC to remove a current
= =C2=A0 =C2=A0 =C2=A0 member of the group (Section 5).

=C2=A0 =C2=A0*= =C2=A0Retrieving keying material as a current group member (Section 4.3=C2=A0 =C2=A0 =C2=A0 and Section 4.4).

=C2=A0 =C2=A0* =C2=A0Renewin= g and re-distributing the group keying material (rekeying)
=C2=A0 =C2=A0= =C2=A0 upon a membership change in the group (Section 4.9 and Section 5).<= br>
=C2=A0 =C2=A0Figure 2 provides a high level overview of the message = flow for a
=C2=A0 =C2=A0node joining a group communication setting, whic= h can be expanded as
=C2=A0 =C2=A0follows.

=C2=A0 =C2=A01.=C2=A0 = The joining node requests an Access Token from the AS, in order
=C2=A0 = =C2=A0 =C2=A0 =C2=A0to access a specific group-membership resource on the K= DC and
=C2=A0 =C2=A0 =C2=A0 =C2=A0hence join the associated group.=C2=A0= The joining node will start or
=C2=A0 =C2=A0 =C2=A0 =C2=A0continue usin= g a secure communication association with the KDC,
=C2=A0 =C2=A0 =C2=A0 = =C2=A0according to the response from the AS.
<mglt>

"c= ontinue using a secure communication" is here I
think to indicate t= hat establishment of a new
secure communication is not necessary.=C2=A0 = If that is
correct, we we could clarify that by adding the
communicat= ion to the AS is secured.

</mglt>

=C2=A0 =C2=A02.=C2= =A0 The joining node transfers authentication and authorization
=C2=A0 = =C2=A0 =C2=A0 =C2=A0information to the KDC, by posting the obtained Access = Token to
=C2=A0 =C2=A0 =C2=A0 =C2=A0the /authz-info endpoint at the KDC.= =C2=A0 After that, a joining node
=C2=A0 =C2=A0 =C2=A0 =C2=A0MUST have a= secure communication association established with the
=C2=A0 =C2=A0 =C2= =A0 =C2=A0KDC, before starting to join a group under that KDC.=C2=A0 Possib= le
=C2=A0 =C2=A0 =C2=A0 =C2=A0ways to provide a secure communication ass= ociation are DTLS
=C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC6347] and OSCORE [RFC86= 13].

<mglt>

The relation between the KDC (application) = and the
secure transport or communication is not entiorely
clear to m= e.=C2=A0 A secure communication includes
authentication of the peers and= encryption of the
traffic.=C2=A0 I suppose that encryption is performed=
by DTLS or OSCORE, but I am wondering if
authentication and authoriz= ation are performed by
the DTLS layer or by the KDC application.=C2=A0 I= have
the impression that KDC is entirely relying on
DTLS/OSCORE for = encryption and
authentication/authorisation because the text
seems to= assume that authz-info may be not
protected.=C2=A0 I thus assume author= ization is
characterized by the ability to set a DTLS/OSCORE
session.= =C2=A0 Of course other information will be
needed by the KDC (scope for = exampel).=C2=A0 If this
use case makes sense, it might be good to clarif= y
the interactions between dtls-authorized works, in
particular how t= hese access tokens ( the merged
access token) =C2=A0are/is used.=C2=A0 T= he other alternative
could be to set an unauthenticated DTLS/OSCORE and<= br>then proceed to the communication of the access
token.

</m= glt>


[ ...]

3.=C2=A0 Authorization to Join a Group
=
=C2=A0 =C2=A0This section describes in detail the format of messages ex= changed by
=C2=A0 =C2=A0the participants when a node requests access to = a group.=C2=A0 This
=C2=A0 =C2=A0exchange is based on ACE [I-D.ietf-ace-= oauth-authz].

=C2=A0 =C2=A0As defined in [I-D.ietf-ace-oauth-authz],= the Client requests from
=C2=A0 =C2=A0the AS an authorization to join t= he group through the KDC (see
=C2=A0 =C2=A0Section 3.1).=C2=A0 If the re= quest is approved and authorization is
=C2=A0 =C2=A0granted, the AS prov= ides the Client with a proof-of-possession access
=C2=A0 =C2=A0token and= parameters to securely communicate with the KDC (see
=C2=A0 =C2=A0Secti= on 3.2).

=C2=A0 =C2=A0Communications between the Client and the AS M= UST be secured, as
=C2=A0 =C2=A0defined by the transport profile of ACE = used.=C2=A0 The Content-Format
=C2=A0 =C2=A0used in the messages is the = one specified by the used transport
=C2=A0 =C2=A0profile of ACE (e.g. ap= plication/ace+cbor for the first two messages
=C2=A0 =C2=A0and applicati= on/cwt for the third message, depending on the format of
=C2=A0 =C2=A0th= e access token).

<mglt>

At that point, I assume that Cl= ient to AS
communication is secured via a standard DTLS
session.=C2= =A0 I am wondering if the POST can be
unsecured or is send over a secure= channel. =C2=A0

</mglt>


The transport profile of = ACE also defines a
=C2=A0 =C2=A0number of details such as the communicat= ion and security protocols
=C2=A0 =C2=A0used with the KDC (see Appendix = C of [I-D.ietf-ace-oauth-authz]).

=C2=A0 =C2=A0Figure 3 gives an ove= rview of the exchange described above.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Client =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0AS =C2=A0KDC
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 | =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |----= Authorization Request: POST /token ------>| =C2=A0 |
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 |
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |<--- Authorization Response: 2.01 (Created) --= -| =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |----- POST Token: P= OST /authz-info --------------->|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Figure 3: Message Flow of Join Authorization
3.1.=C2=A0 Authorization Request

=C2=A0 =C2=A0The Authorization Re= quest sent from the Client to the AS is as
=C2=A0 =C2=A0defined in Secti= on 5.6.1 of [I-D.ietf-ace-oauth-authz] and MAY
=C2=A0 =C2=A0contain the = following parameters, which, if included, MUST have the
=C2=A0 =C2=A0cor= responding values:

<mglt>

I believe that some parameter= s are mandatory. If
that is the case, it would be good to explain
whi= ch parameters are optional or mandatory. =C2=A0

</mglt>
=C2=A0 =C2=A0* =C2=A0'scope', containing the identifier of the sp= ecific group(s), or
=C2=A0 =C2=A0 =C2=A0 topic(s) in the case of pub-sub= , that the Client wishes to access,
=C2=A0 =C2=A0 =C2=A0 and optionally = the role(s) that the Client wishes to take.



Palombini & = Tiloca =C2=A0 =C2=A0 =C2=A0Expires 12 November 2020 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 7]
=0C
Internet-Draft =C2=A0K= ey Provisioning for Group Communication =C2=A0 =C2=A0 =C2=A0 =C2=A0May 2020=


=C2=A0 =C2=A0 =C2=A0 This value is a CBOR byte string, encoding= a CBOR array of one or
=C2=A0 =C2=A0 =C2=A0 more entries.

<mg= lt>

from the text above I understand that the value is
the out= put of a CBOR object, which somehow
requires the CBOR compression to be = run twice. =C2=A0I
might be missing something, but it seems unclear
t= o me why this should be different from: This
value is an array of one or= more entries.

This is my understanding from the text:
scope =3D= [ entry, entry ]

entry =3D [group_id, ([ role, role, ] )]
</m= glt>

=C2=A0 =C2=A0 =C2=A0 An entry has as value a CBOR array, whi= ch contains:

=C2=A0 =C2=A0 =C2=A0 - =C2=A0As first element, the iden= tifier of the specific group or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0topic.=

=C2=A0 =C2=A0 =C2=A0 - =C2=A0Optionally, as second element, the rol= e (or CBOR array of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0roles) that the Cl= ient wishes to take in the group.=C2=A0 This
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0element is optional since roles may have been pre-assigned to
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the Client, as associated to its verifiable = identity
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0credentials.=C2=A0 Alternativ= ely, the application may have defined a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0single, well-known role for the target resource(s) and
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0audience(s).

=C2=A0 =C2=A0 =C2=A0 In each entry,= the encoding of the group or topic identifier
=C2=A0 =C2=A0 =C2=A0 (REQ= 1) and of the role identifiers (REQ2) is application specific,
=C2=A0 = =C2=A0 =C2=A0 and part of the requirements for the application profile.
=
<mglt>

Maybe it would worth specifying the reference theREQ refer to.

</mglt>

[...]

3.2.=C2=A0 Author= ization Response

=C2=A0 =C2=A0The Authorization Response sent from t= he AS to the Client is as
=C2=A0 =C2=A0defined in Section 5.6.2 of [I-D.= ietf-ace-oauth-authz] and MUST
=C2=A0 =C2=A0contain the following parame= ters:

=C2=A0 =C2=A0* =C2=A0'access_token', containing the pr= oof-of-possession access token.

=C2=A0 =C2=A0* =C2=A0'cnf' i= f symmetric keys are used, not present if asymmetric keys
=C2=A0 =C2=A0 = =C2=A0 are used.=C2=A0 This parameter is defined in Section 3.2 of
=C2= =A0 =C2=A0 =C2=A0 [I-D.ietf-ace-oauth-params] and contains the symmetric pr= oof-of-
=C2=A0 =C2=A0 =C2=A0 possession key that the Client is supposed = to use with the KDC.

=C2=A0 =C2=A0* =C2=A0'rs_cnf' if asymme= tric keys are used, not present if symmetric
=C2=A0 =C2=A0 =C2=A0 keys a= re used.=C2=A0 This parameter is as defined in Section 3.2 of
=C2=A0 =C2= =A0 =C2=A0 [I-D.ietf-ace-oauth-params] and contains information about the=C2=A0 =C2=A0 =C2=A0 public key of the KDC.

=C2=A0 =C2=A0* =C2=A0&= #39;expires_in', contains the lifetime in seconds of the access
=C2= =A0 =C2=A0 =C2=A0 token.=C2=A0 This parameter MAY be omitted if the applica= tion defines
=C2=A0 =C2=A0 =C2=A0 how the expiration time is communicate= d to the Client via other
=C2=A0 =C2=A0 =C2=A0 means, or if it establish= es a default value.

=C2=A0 =C2=A0Additionally, the Authorization Res= ponse MAY contain the following
=C2=A0 =C2=A0parameters, which, if inclu= ded, MUST have the corresponding values:

=C2=A0 =C2=A0* =C2=A0's= cope' containing the granted scope, if different from the scope
=C2= =A0 =C2=A0 =C2=A0 requested by the client.=C2=A0 This parameter has the sam= e format and
=C2=A0 =C2=A0 =C2=A0 encoding of 'scope' in the Aut= horization Request, defined in
=C2=A0 =C2=A0 =C2=A0 Section 3.1.

= =C2=A0 =C2=A0* =C2=A0Other additional parameters as defined in
=C2=A0 = =C2=A0 =C2=A0 [I-D.ietf-ace-oauth-authz], if necessary.

=C2=A0 =C2= =A0The proof-of-possession access token (in 'access_token' above) M= UST
=C2=A0 =C2=A0contain the following parameters:




Pa= lombini & Tiloca =C2=A0 =C2=A0 =C2=A0Expires 12 November 2020 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 9]
=0C
Internet= -Draft =C2=A0Key Provisioning for Group Communication =C2=A0 =C2=A0 =C2=A0 = =C2=A0May 2020


=C2=A0 =C2=A0* =C2=A0a confirmation claim (see fo= r example 'cnf' defined in Section 3.1
=C2=A0 =C2=A0 =C2=A0 of [= RFC8747] for CWT);

=C2=A0 =C2=A0* =C2=A0an expiration time claim (se= e for example 'exp' defined in
=C2=A0 =C2=A0 =C2=A0 Section 3.1.= 4 of [RFC8392] for CWT);

=C2=A0 =C2=A0* =C2=A0a scope claim (see for= example 'scope' registered in Section 8.13
=C2=A0 =C2=A0 =C2=A0= of [I-D.ietf-ace-oauth-authz] for CWT).=C2=A0 This claim has the same
= =C2=A0 =C2=A0 =C2=A0 encoding as 'scope' parameter above.=C2=A0 Add= itionally, this claim has
=C2=A0 =C2=A0 =C2=A0 the same value of the = 9;scope' parameter if the parameter is
=C2=A0 =C2=A0 =C2=A0 present = in the message, or it takes the value of 'scope' in the
=C2=A0 = =C2=A0 =C2=A0 Authorization Request otherwise.

=C2=A0 =C2=A0The acce= ss token MAY additionally contain other claims that the
=C2=A0 =C2=A0tra= nsport profile of ACE requires, or other optional parameters.

=C2=A0= =C2=A0As in [I-D.ietf-ace-oauth-authz], these parameters are included in=C2=A0 =C2=A0the payload, which is formatted as a CBOR map.=C2=A0 The Con= tent-Format
=C2=A0 =C2=A0"application/ace+cbor" is used.
=C2=A0 =C2=A0When receiving an Authorization Request from a Client that w= as
=C2=A0 =C2=A0previously authorized, and for which the AS still owns a= valid non
=C2=A0 =C2=A0expired access token, the AS MAY reply with that= token.=C2=A0 Note that it
=C2=A0 =C2=A0is up to application profiles of= ACE to make sure that re-posting the
=C2=A0 =C2=A0same token does not c= ause re-use of keying material between nodes
=C2=A0 =C2=A0(for example, = that is done with the use of random nonces in
=C2=A0 =C2=A0[I-D.ietf-ace= -oscore-profile]).


<mglt>

I am wondering if it is e= xpected the client reads
the values contained in the access_token. =C2= =A0I
suppose not, and even when the acces_token is not
encrypted the = client is supposed to pass the
access token as opaque data to the KDC.= =C2=A0 Is that
correct ?

I am also wondering how the AS could inf= orm which
transport are available to the KDC.

What is a little b= it unclear to me is when the
access token is combined with another acces= s token
from the transport layer. I suppose that the two
tokens are &= quot;merged" in some ways and I am
wondering if the transport acces= s token is
expected to include those of the upper layers in
our case = the KDC.

</mglt>

3.3.=C2=A0 Token Post

=C2=A0 = =C2=A0The Client sends a CoAP POST request including the access token to=C2=A0 =C2=A0the KDC, as specified in Section 5.8.1 of [I-D.ietf-ace-oauth= -authz].
=C2=A0 =C2=A0If the specific transport profile of ACE defines i= t, the Client MAY
=C2=A0 =C2=A0use a different endpoint than /authz-info= at the KDC to post the
=C2=A0 =C2=A0access token to.

<mglt>= ;

I think the overview section mentions
application/cwt is used f= or that exchange. =C2=A0I
think it might be helpful to specify that post=
uses application/cwt since later we indicate that
application/ace+cb= or may carry another meaning.
It might worth updating this section as we= ll. =C2=A0

I also have the impression that the response to
the po= st is called "AS Request Creation Hints".
If that is correct, = the designation is misleading,
as hints are not targeting the AS in the = case.
Maybe that would be good to indicate this is this
exchange that= is being considered with a different
meaning as it has been defined in = the framework.
If that is still correct, I am wondering how the
clien= t can make a difference between the AS
Request Creation Hints as a Respo= nse that provides
additional information related to the group
communi= cation.=C2=A0 In particular I am wondering if
parameters are used to dis= tinguish these two
responses. =C2=A0

</mglt>


=C2= =A0 =C2=A0Optionally, the Client might want to request necessary informatio= n
=C2=A0 =C2=A0concerning the public keys in the group, as well as conce= rning the
=C2=A0 =C2=A0algorithm and related parameters for computing si= gnatures in the
=C2=A0 =C2=A0group.=C2=A0 In such a case, the joining no= de MAY ask for that information
=C2=A0 =C2=A0to the KDC in this same req= uest.=C2=A0 To this end, it sends the CoAP POST
=C2=A0 =C2=A0request to = the /authz-info endpoint using the Content-Format
=C2=A0 =C2=A0"app= lication/ace+cbor".=C2=A0 The payload of the message MUST be formatted=
=C2=A0 =C2=A0as a CBOR map, including the access token and the followin= g
=C2=A0 =C2=A0parameters:

=C2=A0 =C2=A0* =C2=A0'sign_info= 9; defined in Section 3.3.1.




Palombini & Tiloca =C2= =A0 =C2=A0 =C2=A0Expires 12 November 2020 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 [Page 10]
=0C
Internet-Draft =C2=A0Key Provisioning= for Group Communication =C2=A0 =C2=A0 =C2=A0 =C2=A0May 2020


=C2= =A0 =C2=A0* =C2=A0'pub_key_enc' defined in Section 3.3.2, encoding = the CBOR simple
=C2=A0 =C2=A0 =C2=A0 value Null, to require information = on the exact encoding of public
=C2=A0 =C2=A0 =C2=A0 keys used in the gr= oup.

=C2=A0 =C2=A0Alternatively, the joining node may retrieve this = information by
=C2=A0 =C2=A0other means.

=C2=A0 =C2=A0After succe= ssful verification, the Client is authorized to receive

<mglt>=

I am wondering if the verification goes beyond the
signature val= idation.
The remaining of the text seems also to assume
that ace+cbo= r is used. Is that correct ?

</mglt>

=C2=A0 =C2=A0the = group keying material from the KDC and join the group.=C2=A0 In
=C2=A0 = =C2=A0particular, the KDC replies to the Client with a 2.01 (Created)
= =C2=A0 =C2=A0response, using Content-Format "application/ace+cbor"= ; defined in
=C2=A0 =C2=A0Section 8.14 of [I-D.ietf-ace-oauth-authz].
=C2=A0 =C2=A0The payload of the 2.01 response is a CBOR map.=C2=A0 If = the access token
=C2=A0 =C2=A0contains a role that requires the Client t= o send its own public key
=C2=A0 =C2=A0to the KDC when joining the group= , the CBOR map MUST include the
=C2=A0 =C2=A0parameter 'kdcchallenge= ' defined in Section Section 3.3.3, specifying
=C2=A0 =C2=A0a dedica= ted challenge N_S generated by the KDC. =C2=A0

<mglt>

I= am wondering how the client provides the public
key, and I am wondering= if the public key is not
provided through the access_token to the KDC.= =C2=A0 If
that would be correct, it seems then that the key
is provid= ed by the AS or the access token instead
of the client.=C2=A0 Maybe the = public keys are those of
the members of the group.

</mglt>=

=C2=A0 =C2=A0The Client uses this
=C2=A0 =C2=A0challenge to prov= e possession of its own private key (see the
=C2=A0 =C2=A0'client_cr= ed_verify' parameter in Section 4).

<mglt>

I have = not yet read section 4, but it seems that
additional exchanges are perfo= rmed that goes
beyond the Token post exchange.=C2=A0 If my
understand= ing is correct, I am wondering if that
description fits the title of thi= s section.

</mglt>

Note that the payload
=C2=A0 =C2= =A0format of the response deviates from the default as defined in the
= =C2=A0 =C2=A0ACE framework (see Section 5.8.1 of [I-D.ietf-ace-oauth-authz]= ).

=C2=A0 =C2=A0The KDC MUST store the 'kdcchallenge' value = associated to the Client
=C2=A0 =C2=A0at least until it receives a join = request from it (see Section 4.2),
=C2=A0 =C2=A0to be able to verify the= proof of possession.=C2=A0 The same challenge MAY
=C2=A0 =C2=A0be reuse= d several times by the Client, to generate new proof of
=C2=A0 =C2=A0pos= sessions, e.g. in case of update of the public key, or to join a
=C2=A0 = =C2=A0different group with a different key, so it is RECOMMENDED that the=C2=A0 =C2=A0KDC keeps storing the 'kdcchallenge' after the first= join is
=C2=A0 =C2=A0processed as well.=C2=A0 If the KDC has already di= scarded the
=C2=A0 =C2=A0'kdcchallenge', that will trigger an er= ror response with a newly
=C2=A0 =C2=A0generated 'kdcchallenge' = that the client can use to restart the join
=C2=A0 =C2=A0process, as spe= cified in Section 4.2.

=C2=A0 =C2=A0If either of 'sign_info'= or 'pub_key_enc' were included in the
=C2=A0 =C2=A0request, the= KDC MAY include the 'sign_info' parameter defined in
=C2=A0 =C2= =A0Section 3.3.1, optionally including the 'pub_key_enc' parameter<= br>=C2=A0 =C2=A0Section 3.3.2.

=C2=A0 =C2=A0The 'sign_info' = parameter MUST be present if the POST request
=C2=A0 =C2=A0included the = 'sign_info' parameter and/or the pub_key_enc with value
=C2=A0 = =C2=A0Null.=C2=A0 The encoding of the 'sign_info' parameter in the = response is
=C2=A0 =C2=A0defined in Section 3.3.2.=C2=A0 Note that the f= ield 'id' takes the value
=C2=A0 =C2=A0of the group identifier f= or which the 'sign_info' applies to, in this
=C2=A0 =C2=A0specif= ication.





Palombini & Tiloca =C2=A0 =C2=A0 =C2=A0= Expires 12 November 2020 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [= Page 11]
=0C
Internet-Draft =C2=A0Key Provisioning for Group Communic= ation =C2=A0 =C2=A0 =C2=A0 =C2=A0May 2020


=C2=A0 =C2=A0Note that= the CBOR map specified as payload of the 2.01 (Created)
=C2=A0 =C2=A0re= sponse may include further parameters, e.g. according to the
=C2=A0 =C2= =A0signalled transport profile of ACE.

=C2=A0 =C2=A0Applications of = this specification MAY define alternative specific
=C2=A0 =C2=A0negotiat= ions of parameter values for signature algorithm and
=C2=A0 =C2=A0signat= ure keys, if 'sign_info' and 'pub_key_enc' are not used (OP= T2).

3.3.1. =C2=A0'sign_info' Parameter

=C2=A0 =C2=A0= The 'sign_info' parameter is an OPTIONAL parameter of the AS Reques= t
=C2=A0 =C2=A0Creation Hints message defined in Section 5.1.2. of
= =C2=A0 =C2=A0[I-D.ietf-ace-oauth-authz].

<mglt>

The tex= t can be read as 'sign_info' is defined in
Section 5.1.2.=C2=A0 = I believe that clarifying the
response is designated in the framework as= AS
Request Creation Hints but has a different meaning
here may solve= this issue.

</mglt>

[...]

3.3.2. =C2=A0'pub= _key_enc' Parameter

=C2=A0 =C2=A0The 'pub_key_enc' param= eter is an OPTIONAL parameter of the AS
=C2=A0 =C2=A0Request Creation Hi= nts message defined in Section 5.1.2. of
=C2=A0 =C2=A0[I-D.ietf-ace-oaut= h-authz].=C2=A0 This parameter contains information
=C2=A0 =C2=A0about t= he exact encoding of public keys to be used between the Client
=C2=A0 = =C2=A0and the RS.=C2=A0 Its exact content is application specific.

= =C2=A0 =C2=A0In this specification and in application profiles building on = it,
=C2=A0 =C2=A0this parameter is used to ask the KDC information about= the encoding
=C2=A0 =C2=A0of public keys used in the group.

=C2= =A0 =C2=A0The CDDL notation of the 'pub_key_enc' parameter formatte= d as in the
=C2=A0 =C2=A0request is given below.

=C2=A0 =C2=A0 = =C2=A0 pub_key_enc_req =3D nil

<mglt>

It is not entirel= y clear to me what pub_key_enc is
about. It is the format of the public = key itself
or the encryption algorithm ?

Then it is unclear to me= which public key is
referred to. =C2=A0"public keys used in the gr= oup" make
me think of a private/public key that is shared by
all= members of the group.=C2=A0 This public key is used
with the RS, that i= s the dispatcher, not to
authenticate the client. Am I correct ?

= </mglt>


3.3.3. =C2=A0'kdcchallenge' Parameter
<= br>=C2=A0 =C2=A0The 'kdcchallenge' parameter is an OPTIONAL paramet= er of the AS
=C2=A0 =C2=A0Request Creation Hints message defined in Sect= ion 5.1.2. of
=C2=A0 =C2=A0[I-D.ietf-ace-oauth-authz].=C2=A0 This parame= ter contains a challenge
=C2=A0 =C2=A0generated by the KDC and provided = to the Client.=C2=A0 The Client may use
=C2=A0 =C2=A0this challenge to p= rove possession of its own private key in the
=C2=A0 =C2=A0Joining Reque= st ((see the 'client_cred_verify' parameter in
=C2=A0 =C2=A0Sect= ion 4).

<mglt>

I suppose that will be clarified in sect= ion , but
of "its own private key" make me think that the
k= ey in question is to authenticate the client,
instead of the key used fo= r the group.

If that is correct, it is unclear to me why there
i= s a need to authenticate the client and why this
should not be performed= instead by the AS.=C2=A0 It
seems I am missing something here.

= </mglt>

4.=C2=A0 Keying Material Provisioning and Group Member= ship Management

[...]

=C2=A0 =C2=A0Upon receiving a request f= rom a Client, the KDC MUST check that it is
=C2=A0 =C2=A0storing a valid= access token from that Client for the group
=C2=A0 =C2=A0identifier ass= iciated
<mglt>
associated
</mglt>

to the endpo= int.=C2=A0 If that is not the case, i.e.
=C2=A0 =C2=A0the KDC does not s= tore a valid access token or this is not valid for
=C2=A0 =C2=A0that Cli= ent for the group identifier at hand, the KDC MUST respond to
=C2=A0 =C2= =A0the Client with a 4.01 (Unauthorized) error message.

4.1.=C2=A0 I= nterface at the KDC

=C2=A0 =C2=A0The KDC is configured with the foll= owing resources.=C2=A0 Note that the
=C2=A0 =C2=A0root url-path "ac= e-group" given here are default names:
=C2=A0 =C2=A0implementations= are not required to use these names, and can define
=C2=A0 =C2=A0their = own instead.=C2=A0 The Interface Description (if=3D) Link Target
=C2=A0 = =C2=A0Attribute value ace-group is registered (Section 8.9) and can be used=
=C2=A0 =C2=A0to describe this inferface.
<mglt>
interface.<= br></mglt>


--
Dani= el Migault
Ericsson
--00000000000031e31b05a62cf946-- From nobody Mon May 25 13:46:57 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0B363A05A0; Mon, 25 May 2020 13:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 JjjBU4zIcT5M; Mon, 25 May 2020 13:46:53 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C30B43A0484; Mon, 25 May 2020 13:46:49 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 25 May 2020 13:46:40 -0700 From: Jim Schaad To: CC: 'Ace Wg' Date: Mon, 25 May 2020 13:46:38 -0700 Message-ID: <031c01d632d5$98158ba0$c840a2e0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AdYySg6qaQ1K2nGySeOKYIC/kF1pfw== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Ace] Review on draft-bormann-core-ace-aif-07 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 25 May 2020 20:46:55 -0000 * Section 2 - I would like more clarification on the subject as being derived implicitly from the armor and is a single entity rather than multiple entities. If we think that we want to do multiple subjects then that needs to be discussed. * Section 2.1 - The model does not current deal with the question of queries and how they would be permitted for a non-query object. * How do we ant to look at doing the generalization for the structure provided. There are two things to look at: 1. The object identifier: It makes sense for a good many things for this to be an absolute-path. However for other things this would be some type of identifier. With both the GroupKDC and with MQTT this identifier is a string. In the MQTT case the string has defined wild card behavior. Part of the question is how much does the object naming scheme need to be identified to the client, the AS and the RS. 2. The permissible actions: For a coap addressed device, it makes sense for this to be based on the set of coap verbs and the compressed bit string makes a great deal of sense. However for both GroupKDC and MQTT these verbs are not the same and thus cannot be compressed in the same manner. What I would like to see is a structure defined that can be used in a number of situations, but which the details are going to be very object dependent. authorization-info = [ * authorization] authorization = [ object: object-identifier, permissions: [* permission-name] | uint .bits methods ] permission-name = tstr One option would be to allow the methods to be object dependent this means that you could have "methods = &( PUBLISH: 0, SUBSCRIBE: 1)" for the MQTT case. The advantage of this is that it provides better compressions, but it also means that one needs to know what the enumeration is for each different type of object. I don't know if this means that one needs to start having a registry to deal with people adding verbs to a particular interface. I also don't know what it would mean if they were interface specific and an object supported two different interfaces. Nits: Section 2 - para 2 s/on object/an object/ Jim From nobody Mon May 25 19:53:57 2020 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F09873A0B34; Mon, 25 May 2020 19:53:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: mglt.ietf@gmail.com, kaduk@mit.edu, ace-chairs@ietf.org, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159046163233.28591.17144704183242046318@ietfa.amsl.com> Date: Mon, 25 May 2020 19:53:52 -0700 Archived-At: Subject: [Ace] ace - New Meeting Session Request for IETF 108 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2020 02:53:54 -0000 A new meeting session request has just been submitted by Daniel Migault, a Chair of the ace working group. --------------------------------------------------------- Working Group Name: Authentication and Authorization for Constrained Environments Area Name: Security Area Session Requester: Daniel Migault Number of Sessions: 1 Length of Session(s): 100 Minutes Number of Attendees: 15 Conflicts to Avoid: Chair Conflict: lamps calext drip Technology Overlap: lake tls oauth homenet t2trg suit core cose People who must be present: Daniel Migault Jim Schaad Benjamin Kaduk Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue May 26 20:01:28 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F093A0D6B for ; Tue, 26 May 2020 20:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvGk_RJJgJkY for ; Tue, 26 May 2020 20:01:25 -0700 (PDT) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (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 5E1983A0D66 for ; Tue, 26 May 2020 20:01:25 -0700 (PDT) Received: by mail-ua1-x92c.google.com with SMTP id g7so7941248uap.7 for ; Tue, 26 May 2020 20:01:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=N4nPfUDEoeCDiRE2IOlAeJW/KPw4WpZXZd8uPgh0pyw=; b=dkJp7sUvnAXkv+vYH2GKXRERkzpV8KeCs+JkQ1P9BQ7M2EQPvKcrlR9yYBHsJUcDew rjbuUJIvKkmE0KooSyAQE8f1b3vG2LBgi2qeDW/KSbPmte3bAvnkOZlJUTlbjR0yXQZ3 LPLIYgnzvYwTkTYwKIM+5Q9VQpqqhPeILC8VkFGlIvu464RYUUTbSbUWjdeTCFgejBtG OEwwXdW+zG8cn0hLBYzzpVJ7xoRE/YjVQbMls/9mv0NJl3eF8PWiz91ktxo4qPVi8YLG Kep2oIde8wlOUYRZFfHOyHc0UIB/XTc0ioh9ZsVdzhwfAbtiRlbs5yrK/+uWUTXE2mkp kbVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=N4nPfUDEoeCDiRE2IOlAeJW/KPw4WpZXZd8uPgh0pyw=; b=UhiruTM1c2smqD6I6Pi4RDJ+RaI7AwVOlnZyTpC6/u3wz+JK6HUzXiZXaortYMT9SB Fvp8Iy7RWjzqfyLG/SonXzs2OBuLmocKgupWmgCNCUvcFGaaqR2eRIbGrd58ryrRrZ7Z CpUmzOi7Q1fklOPEMPN57HLoi1lImpvuSSEy3njWk2Op5p4gJD3YJ6ooqLw9AcQm7/Io KVVpH4/J60AuqyvuXwaaJt5jzYE++ESUSGjZMI7Qi1F/6jdecY5KR6TsinFhy3TcB3b0 +mm5TsEa7kGP40rBWH+/gH+gXuPVHv7Jf6IuxhPmB310g/3M3w/OJXDMm6e6ycX+hADm Qu4A== X-Gm-Message-State: AOAM531XmAWHysOk7Ccep+yZUfOAIrzXSWN0Sbz8W3pu5hiy98S4vMFP I2SDd8WOkAl6+beUzsIxX0e2zCw1TYPveW1Ae70nLHfZ X-Google-Smtp-Source: ABdhPJyc4SVsE/7Ue8Jolj6q7D1AEwJ6hdcYoEDGccwdnUVxfQJ3KJCPACvICGvAh1LeEd9RE+9T/XsafLkaZ2iXj18= X-Received: by 2002:ab0:6713:: with SMTP id q19mr3102273uam.114.1590548483064; Tue, 26 May 2020 20:01:23 -0700 (PDT) MIME-Version: 1.0 From: Daniel Migault Date: Tue, 26 May 2020 23:01:12 -0400 Message-ID: To: Ace Wg Content-Type: multipart/alternative; boundary="00000000000054c96405a6986d77" Archived-At: Subject: [Ace] June 22 interim meeting X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 27 May 2020 03:01:27 -0000 --00000000000054c96405a6986d77 Content-Type: text/plain; charset="UTF-8" Hi, Ace has planned an interim meeting on June 22 [1]. The provisional agenda is available here [2] and feel free to update it with updated links to slides as well as items. The current copy is provided below: Yours, Jim and Daniel [1] https://datatracker.ietf.org/meeting/interim-2020-ace-07/session/ace [2] https://etherpad.ietf.org:9009/p/notes-ietf-interim-2020-ace-07-ace?useMonospaceFont=true Administrative AD held documents draft-ietf-ace-dtls-authorize-10 draft-ietf-ace-oauth-authz-33 draft-ietf-ace-oauth-params-13 draft-ietf-ace-oscore-profile-10 Marco's non WG documents - Admin Interface - draft-tiloca-ace-oscore-gm-admin - Marco Tiloca (10 min) document: https://datatracker.ietf.org/doc/draft-tiloca-ace-oscore-gm-admin/ slides: https://datatracker.ietf.org/meeting/interim-2020-ace-06/materials/slides-interim-2020-ace-06-sessa-20200518-ace-oscore-gm-admin - Revoked Access Tokens - Marco Tiloca (10 min) document: https://datatracker.ietf.org/doc/draft-tiloca-ace-revoked-token-notification/ slides: https://datatracker.ietf.org/meeting/interim-2020-ace-06/materials/slides-interim-2020-ace-06-sessa-20200518-ace-revoked-token-notification MQTT document (WGL ready version expected) document: https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/ Group Keying Documents - Framework - Francesca Palombini document: https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/ slides: XXX - OSCORE - Marco Tiloca (15 min) document: https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm-oscore/ slides: https://datatracker.ietf.org/meeting/interim-2020-ace-06/materials/slides-interim-2020-ace-06-sessa-20200518-ace-key-groupcomm-oscore - PubSub ( if document is being updated ) document: https://datatracker.ietf.org/doc/draft-ietf-ace-pubsub-profile/ -- Daniel Migault Ericsson --00000000000054c96405a6986d77 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

<= span class=3D"gmail-" style=3D"box-sizing:border-box;margin:0px;padding:0px= ;line-height:17.5px">Ace has planned an interim meeting on June 22 [1]. The provisional agenda is available here [2] and feel free to update i= t with updated links to slides as well as items.


The current copy is provided below:

Yours,
Jim and Daniel


Administrat= ive

AD held doc= uments
=C2=A0 draft-iet= f-ace-dtls-authorize-10
=C2=A0 draft-ietf-ace-oauth-authz-33
=C2=A0 draft-ietf-ace-oauth-params-13
=C2=A0 draft-ietf-ace-oscore-profile-10

Marco's non WG d= ocuments=C2=A0

= - Admin Interface - draft-tiloca-ace-oscore-gm-admin - Marco Tiloca (10 min= )

- Revoked Access Tokens -=C2=A0 Marco Tiloca (10 mi= n)
=C2=A0 document:
=C2=A0 slid= es:
=C2=A0 ht= tps://datatracker.ietf.org/meeting/interim-2020-ace-06/materials/slides-int= erim-2020-ace-06-sessa-20200518-ace-revoked-token-notification

MQTT document (WGL re= ady version expected)

Group Keying Documents
- Framework -=C2=A0 Francesca Palombini
=C2=A0 document: <= a href=3D"https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/" r= el=3D"noreferrer noopener" style=3D"box-sizing:border-box;margin:0px;paddin= g:0px;background-color:transparent;color:inherit">https://datatracker.ietf.= org/doc/draft-ietf-ace-key-groupcomm/
=C2=A0 slides: XXX

- OSCORE -=C2=A0 Marco Tiloca (15 min)
<= div id=3D"gmail-magicdomid41" class=3D"gmail-ace-line" style=3D"box-sizing:= border-box;margin:0px;padding:0px;color:rgb(62,62,62);font-family:monospace= ;font-size:14px">=C2=A0 document:

- PubSub ( if doc= ument is being updated )
--
Daniel Migault
Ericsson
--00000000000054c96405a6986d77-- From nobody Wed May 27 09:35:46 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 897CE3A0747 for ; Wed, 27 May 2020 09:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=0.1] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kp6felvy4HmC for ; Wed, 27 May 2020 09:35:43 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750053.outbound.protection.outlook.com [40.107.75.53]) (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 E02863A0659 for ; Wed, 27 May 2020 09:35:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QQCtvfToA4hzCh76VUdT1dGfN6gMsxoMMYDSHGS8r+TcGe3hQKV0Ott55KnKk8dPE7fhVRxacAdOYNfXLdEOLilFADfdwlNj3FxWbBybXoR2RdZecU5OUKqmT60ob4x2Rbg9ZlPLqKsIN52MNeeK9yD55SpDMnURMOSYUxY4D4S5bool/p5ta5vQJQGNKHfRoSpo3KpEVV8dFUF5oLUSGUr3LqqvOlFaXx6CddGJgI7bMDxIsKfLjS7CJvl08Zaxx1vDdASpGkfTxOOj45R4OmooVClz44L6W3SIji4Wxe1SxE4o8Zaoy+sBnFlpaAMyXNd1qTD3owMDihB/PEHJFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cVPho7gs6z7tO0F0UTTOR8it7QLv3K+ayJcdNzWKkp0=; b=eE3r1hHnm4F01kkPZjU4rbjpcZ0GMccr4m185civU9+09YRd9RjrbMOYyW6YmH2q2HGB2Kok64TS02g8U/n1YGzr1Ui5LBArIfx3Q1MNzsTHJUm5i2/VqB9/YgZbEtp+2yASPAxNuf27ulqCuRjAPbLOfI0ndSJ50iDQ1Vhevbo4HpJ+fcSMVCqHErLahYxHfPUx+LyKV0zqyVRJRppnZHd7PMKlQTZtKXpYrSfsaUSE+yxyZqYb5/rF/k3xnJoIyVPkNd/EuFEakCURNuzExsC/CnVRNqNXkKQBjNDbn+Jz/YOu5p7aQ3mPPjsoylfxc2K1x1Wx3DEL9F0k2mSiLQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ietf.org; dkim=pass header.d=ietf.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cVPho7gs6z7tO0F0UTTOR8it7QLv3K+ayJcdNzWKkp0=; b=me2CcROtLZOSboksoheAYOHwpR28NWdfPQy/38nNirvTv/mPDmZ5tfljHg8WBHC/2YjqHG8cJ5Luxc68RFMlQm4LbBS3uLNv4/HkaE02HVBLPGoaN21vBiPfnVtKZWKatlxn5v1vOb9aIY5gKt75rvT3+zRpdMR89qJ6Fl80eLg= Received: from SA0PR15MB3791.namprd15.prod.outlook.com (2603:10b6:806:8d::10) by SA0PR15MB3967.namprd15.prod.outlook.com (2603:10b6:806:8c::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.19; Wed, 27 May 2020 16:35:40 +0000 Received: from SA0PR15MB3791.namprd15.prod.outlook.com ([fe80::1de5:cb5a:2993:706b]) by SA0PR15MB3791.namprd15.prod.outlook.com ([fe80::1de5:cb5a:2993:706b%6]) with mapi id 15.20.3021.030; Wed, 27 May 2020 16:35:40 +0000 From: Jim Schaad To: "ace@ietf.org" Thread-Topic: Webex meeting invitation: ACE interim 07 Thread-Index: AQHWNERjMduDb2CrWkCINDvVi51bnw== Sender: Daniel Migault Date: Wed, 27 May 2020 16:35:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-publictraffictype: Email authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ietf.org; x-ms-exchange-messagesentrepresentingtype: 2 x-ms-exchange-meetingforward-message: Forward x-ms-exchange-calendar-series-instance-id: BAAAAIIA4AB0xbcQGoLgCAAAAAAAAAAAAAAAAAAAAAAAAAAAMQAAAHZDYWwtVWlkAQAAAGE1Yjk4OWEzLWYzZDQtNDRkNS05MDUwLTkzMGU5NTg1Y2FlZgA= x-originating-ip: [96.22.11.129] x-ms-office365-filtering-correlation-id: fbd5ce64-4bdf-474c-3426-08d8025bfe5d x-ms-traffictypediagnostic: SA0PR15MB3967:MeetingMessage x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4125; x-forefront-prvs: 04163EF38A x-ms-exchange-senderadcheck: 2 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: B17RQUM98xOEmApAH0EQWeVxrWA3r6UyZtY3fNG/0xqew6ihtC/3iOgm6YnuxeZvufrVNUfXf4JMFTZ/i07XhlQEYvgWYsyJ99jIIJZrOQVG/4P/la2Lz/x5676HlfO94Gk0GsQMbE0pcv3FBNK7kDG/KXmX9y8Yub1OA3urs7FnCcerq8VA8xsFr0hFFgGLGVU1J7iHpYoUO2kguO4ENpKJYZulZpdQ+waWjcYtHH2pBy5IZcndVfCwGa2QqdtFG1+PUZ1WEMr9Q5ZZtX+kAqkF1cbHP6ZLB6FfKa+mFUTRNeZNlUD0aEiV//7uU5BMpRKxe63STGa4uPEDzLyQd4KWspNSHhO0QUvyr+HZOIpuXilEoQo4rIeasa0BJKnLkQw0OiyaX1hwyZLDLN3iWw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA0PR15MB3791.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(136003)(396003)(346002)(376002)(39860400002)(33656002)(16799955002)(166002)(42882007)(9686003)(316002)(83380400001)(6916009)(2940100002)(7846003)(99936003)(71200400001)(6506007)(8936002)(53546011)(6636002)(66476007)(66616009)(66446008)(2906002)(76116006)(66946007)(19627405001)(45080400002)(7696005)(64756008)(26005)(186003)(5660300002)(4744005)(8676002)(52536014)(83170400001)(66556008)(478600001)(966005)(55016002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: Mg8+Tg3iqWWUjQcR/7gVABLeMj4ZCy3cevfJo7yfJqTgjuElzvy+9SVLontxef3UUlacMecB+45SQ+ABedfqxL+SR521PV8H4ykibuTxUvT5dLK7ngo77Bhht6LjH+iia128eLapIfwSjkVXI2Ruha4V6ZPtysF7zzhRhChWSwIeQhrTRR5zeDvFEU8g4mUllsT33KL1fPYOw6S16K6f6vajipCa4tUyo4jwoccjKvM3o5xf6GdbU3GlAiuYxe8HvGEx5B8oGXDi5FPzhkbt52ZeW42SqNErSvYhyLMMGCI9bvFNWl4VYFIxzzOs7R8FfWJHP1ko4oqwNVF7abP1gKh1oXS8RSol9OGp9lR2BG3Z4n2ZbcouiPzN6/KQ3Am5e28PDqlRWlCS5E6iI8mB/umPoLi0eZ9lHENIPfIiDg3AsW5eZHtaMFQLwt6HwVUpCcuqDm2RYUejxGiUijX7E0AVpjioUMokrRJdIk0MEXk= x-ms-exchange-transport-forked: True Content-Type: multipart/mixed; boundary="_005_SA0PR15MB37912F464265A81ADA3BBDB6E3B10SA0PR15MB3791namp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: fbd5ce64-4bdf-474c-3426-08d8025bfe5d X-MS-Exchange-CrossTenant-originalarrivaltime: 27 May 2020 16:35:40.3595 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 25rBsRYfTD3billCTVBJWYSm4n/ml5/75BBF8mp4an20CDui/7mZVdtifYCfZdRpXFU77E+3m7HMEHy3G9HMw+mcC1EUR9uxf9OjUre7ffU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR15MB3967 Archived-At: Subject: [Ace] FW: Webex meeting invitation: ACE interim 07 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 27 May 2020 16:35:45 -0000 --_005_SA0PR15MB37912F464265A81ADA3BBDB6E3B10SA0PR15MB3791namp_ Content-Type: multipart/alternative; boundary="_000_SA0PR15MB37912F464265A81ADA3BBDB6E3B10SA0PR15MB3791namp_" --_000_SA0PR15MB37912F464265A81ADA3BBDB6E3B10SA0PR15MB3791namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -----Original Appointment----- From: Jim Schaad Sent: Wednesday, May 27, 2020 12:32 PM To: Jim Schaad; Daniel Migault Subject: Webex meeting invitation: ACE interim 07 When: Monday, June 22, 2020 2:00 PM-3:30 PM Atlantic/Reykjavik. Where: https://ietf.webex.com/ietf/j.php?MTID=3Dmf10e2f04280cf225c5d2374973= df48b5 Jim Schaad invites you to join this Webex meeting. Meeting number (access code): 161 348 3825 Meeting password: d54fSbDXHb6 Monday, June 22, 2020 2:00 pm | (UTC+00:00) Monrovia, Reykjavik | 1 hr 30 mins Join meeting Join by phone Tap to call in from a mobile device (attendees only) 1-650-479-3208 Call-in tol= l number (US/Canada) Global call-in numbers Join from a video system or application Dial 1613483825@ietf.webex.com<%20sip:1613483825@ietf.webex.com> You can also dial 173.243.2.68 and enter your meeting number. Join using Microsoft Lync or Microsoft Skype for Business Dial 1613483825.ietf@lync.webex.com<%20sip:1613483825.ietf@lync.webex.com> Need help? Go to http://help.webex.com --_000_SA0PR15MB37912F464265A81ADA3BBDB6E3B10SA0PR15MB3791namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

 

-----Original Appointment-----
From: Jim Schaad <ace-chairs@ietf.org>
Sent: Wednesday, May 27, 2020 12:32 PM
To: Jim Schaad; Daniel Migault
Subject: Webex meeting invitation: ACE interim 07
When: Monday, June 22, 2020 2:00 PM-3:30 PM Atlantic/Reykjavik.
Where: https://ietf.webex.com/ietf/j.php?MTID=3Dmf10e2f04280cf225c5d= 2374973df48b5

 

 

Jim Schaad invites you to join this Webex meeting.

 

 

 

Meeting number (access code): 161 348 3825

 

Meeting password: d54fSbDXHb6

 

 

 

Monday, June 22, 2020

2:00 pm  |  (UTC+00:00) Monrovia, Reyk= javik  |  1 hr 30 mins

 

 

 

Join meeting

 

 

 

Join by phone

Tap to call in from a mobile device (attendees only)=

1-650-479-3208&= nbsp;Call-in toll number (US/Canada)

Global call-in numbers

 

 

 

Join from a video system or application<= /p>

Dial 1613483825@ietf.webex.co= m

You can also dial 173.243.2.68 and enter your meeting number.<= o:p>

 

 

 

Join using Microsoft Lync or Microsoft Skype for Business=

Dial 1613483825.ietf@lync.web= ex.com

 

Need help? Go to http://help.webex.com

 

 

--_000_SA0PR15MB37912F464265A81ADA3BBDB6E3B10SA0PR15MB3791namp_ Content-Type: text/calendar; charset="utf-8"; method=REQUEST Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpNRVRIT0Q6UkVRVUVTVA0KUFJPRElEOk1pY3Jvc29mdCBFeGNoYW5n ZSBTZXJ2ZXIgMjAxMA0KVkVSU0lPTjoyLjANCkJFR0lOOlZUSU1FWk9ORQ0KVFpJRDpBdGxhbnRp Yy9SZXlramF2aWsNCkJFR0lOOlNUQU5EQVJEDQpEVFNUQVJUOjE2MDEwMTAxVDAwMDAwMA0KVFpP RkZTRVRGUk9NOiswMDAwDQpUWk9GRlNFVFRPOiswMDAwDQpFTkQ6U1RBTkRBUkQNCkJFR0lOOkRB WUxJR0hUDQpEVFNUQVJUOjE2MDEwMTAxVDAwMDAwMA0KVFpPRkZTRVRGUk9NOiswMDAwDQpUWk9G RlNFVFRPOiswMDAwDQpFTkQ6REFZTElHSFQNCkVORDpWVElNRVpPTkUNCkJFR0lOOlZFVkVOVA0K T1JHQU5JWkVSO0NOPUppbSBTY2hhYWQ7U0VOVC1CWT0ibWFpbHRvOmRhbmllbC5taWdhdWx0QGVy aWNzc29uLmNvbSI6bWFpbHRvOmENCiBjZS1jaGFpcnNAaWV0Zi5vcmcNCkFUVEVOREVFO1JPTEU9 UkVRLVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049YWNlQGll dGYubw0KIHJnOm1haWx0bzphY2VAaWV0Zi5vcmcNCkFUVEFDSDpDSUQ6MzkxMThBMkJFMkY3Q0Q0 Mjk0QjQ1MTI5RDEzQTczNURAbmFtcHJkMTUucHJvZC5vdXRsb29rLmNvbQ0KREVTQ1JJUFRJT047 TEFOR1VBR0U9ZW4tVVM6XG5cbi0tLS0tT3JpZ2luYWwgQXBwb2ludG1lbnQtLS0tLVxuRnJvbTog SmltIFNjDQogaGFhZCA8YWNlLWNoYWlyc0BpZXRmLm9yZz5cblNlbnQ6IFdlZG5lc2RheVwsIE1h eSAyN1wsIDIwMjAgMTI6MzIgUE1cblRvOiANCiBKaW0gU2NoYWFkXDsgRGFuaWVsIE1pZ2F1bHRc blN1YmplY3Q6IFdlYmV4IG1lZXRpbmcgaW52aXRhdGlvbjogQUNFIGludGVyaQ0KIG0gMDdcbldo ZW46IE1vbmRheVwsIEp1bmUgMjJcLCAyMDIwIDI6MDAgUE0tMzozMCBQTSBBdGxhbnRpYy9SZXlr amF2aWsuXG5XDQogaGVyZTogaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9 bWYxMGUyZjA0MjgwY2YyMjVjNWQyMzc0OTczZGYNCiA0OGI1XG5cblxuSmltIFNjaGFhZCBpbnZp dGVzIHlvdSB0byBqb2luIHRoaXMgV2ViZXggbWVldGluZy5cblxuXG5cbk1lZXRpbg0KIGcgbnVt YmVyIChhY2Nlc3MgY29kZSk6IDE2MSAzNDggMzgyNVxuXG5NZWV0aW5nIHBhc3N3b3JkOiBkNTRm U2JEWEhiNlxuXG5cDQogblxuTW9uZGF5XCwgSnVuZSAyMlwsIDIwMjBcbjI6MDAgcG0gIHwgIChV VEMrMDA6MDApIE1vbnJvdmlhXCwgUmV5a2phdmlrICANCiB8ICAxIGhyIDMwIG1pbnNcblxuXG5c bkpvaW4gbWVldGluZzxodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRA0KID1t ZjEwZTJmMDQyODBjZjIyNWM1ZDIzNzQ5NzNkZjQ4YjU+XG5cblxuXG5Kb2luIGJ5IHBob25lXG5U YXAgdG8gY2FsbCBpbiBmDQogcm9tIGEgbW9iaWxlIGRldmljZSAoYXR0ZW5kZWVzIG9ubHkpXG4x LTY1MC00NzktMzIwODx0ZWw6JTJCMS02NTAtNDc5LTMyMDgNCiBcLFwsKjAxKjE2MTM0ODM4MjUl MjMlMjMqMDEqPiBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpXG5HbG9iYWwgY2FsbA0K IC1pbiBudW1iZXJzPGh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9nbG9iYWxjYWxsaW4ucGhw P01USUQ9bTI5MTJhMjQyNGQ3DQogYzRjN2U1MjJjNjkxZTY4YTVhYWJkPlxuXG5cblxuSm9pbiBm cm9tIGEgdmlkZW8gc3lzdGVtIG9yIGFwcGxpY2F0aW9uXG5EaWENCiBsIDE2MTM0ODM4MjVAaWV0 Zi53ZWJleC5jb208JTIwc2lwOjE2MTM0ODM4MjVAaWV0Zi53ZWJleC5jb20+XG5Zb3UgY2FuIGFs cw0KIG8gZGlhbCAxNzMuMjQzLjIuNjggYW5kIGVudGVyIHlvdXIgbWVldGluZyBudW1iZXIuXG5c blxuXG5Kb2luIHVzaW5nIE1pY3JvDQogc29mdCBMeW5jIG9yIE1pY3Jvc29mdCBTa3lwZSBmb3Ig QnVzaW5lc3NcbkRpYWwgMTYxMzQ4MzgyNS5pZXRmQGx5bmMud2ViZXgNCiAuY29tPCUyMHNpcDox NjEzNDgzODI1LmlldGZAbHluYy53ZWJleC5jb20+XG5cbk5lZWQgaGVscD8gR28gdG8gaHR0cDov L2hlbA0KIHAud2ViZXguY29tXG5cblxuDQpVSUQ6YTViOTg5YTMtZjNkNC00NGQ1LTkwNTAtOTMw ZTk1ODVjYWVmDQpTVU1NQVJZO0xBTkdVQUdFPWVuLVVTOkZXOiBXZWJleCBtZWV0aW5nIGludml0 YXRpb246IEFDRSBpbnRlcmltIDA3DQpEVFNUQVJUO1RaSUQ9QXRsYW50aWMvUmV5a2phdmlrOjIw MjAwNjIyVDE0MDAwMA0KRFRFTkQ7VFpJRD1BdGxhbnRpYy9SZXlramF2aWs6MjAyMDA2MjJUMTUz MDAwDQpDTEFTUzpQVUJMSUMNClBSSU9SSVRZOjUNCkRUU1RBTVA6MjAyMDA1MjdUMTYzMjA0Wg0K VFJBTlNQOk9QQVFVRQ0KU1RBVFVTOkNPTkZJUk1FRA0KU0VRVUVOQ0U6MTU5MDU5NzEyNA0KTE9D QVRJT047TEFOR1VBR0U9ZW4tVVM6aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01U SUQ9bWYxMGUyZjA0MjgwDQogY2YyMjVjNWQyMzc0OTczZGY0OGI1DQpYLU1JQ1JPU09GVC1DRE8t QVBQVC1TRVFVRU5DRToxNTkwNTk3MTI0DQpYLU1JQ1JPU09GVC1DRE8tT1dORVJBUFBUSUQ6MA0K WC1NSUNST1NPRlQtQ0RPLUJVU1lTVEFUVVM6VEVOVEFUSVZFDQpYLU1JQ1JPU09GVC1DRE8tSU5U RU5ERURTVEFUVVM6QlVTWQ0KWC1NSUNST1NPRlQtQ0RPLUFMTERBWUVWRU5UOkZBTFNFDQpYLU1J Q1JPU09GVC1DRE8tSU1QT1JUQU5DRToxDQpYLU1JQ1JPU09GVC1DRE8tSU5TVFRZUEU6MA0KWC1N SUNST1NPRlQtRE9OT1RGT1JXQVJETUVFVElORzpGQUxTRQ0KWC1NSUNST1NPRlQtRElTQUxMT1ct Q09VTlRFUjpGQUxTRQ0KWC1NSUNST1NPRlQtTE9DQVRJT05TOlt7IkRpc3BsYXlOYW1lIjoiaHR0 cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01UDQogSUQ9bWYxMGUyZjA0MjgwY2YyMjVj NWQyMzc0OTczZGY0OGI1IlwsIkxvY2F0aW9uQW5ub3RhdGlvbiI6IiJcLCJMb2NhdGlvblUNCiBy aSI6IiJcLCJMb2NhdGlvblN0cmVldCI6IiJcLCJMb2NhdGlvbkNpdHkiOiIiXCwiTG9jYXRpb25T dGF0ZSI6IiJcLCJMb2NhdA0KIGlvbkNvdW50cnkiOiIiXCwiTG9jYXRpb25Qb3N0YWxDb2RlIjoi IlwsIkxvY2F0aW9uRnVsbEFkZHJlc3MiOiIifV0NCkJFR0lOOlZBTEFSTQ0KREVTQ1JJUFRJT046 UkVNSU5ERVINClRSSUdHRVI7UkVMQVRFRD1TVEFSVDotUFQ1TQ0KQUNUSU9OOkRJU1BMQVkNCkVO RDpWQUxBUk0NCkVORDpWRVZFTlQNCkVORDpWQ0FMRU5EQVINCg== --_000_SA0PR15MB37912F464265A81ADA3BBDB6E3B10SA0PR15MB3791namp_-- --_005_SA0PR15MB37912F464265A81ADA3BBDB6E3B10SA0PR15MB3791namp_ Content-Type: application/octet-stream; name="Webex_Meeting.ics" Content-Description: Webex_Meeting.ics Content-Disposition: attachment; filename="Webex_Meeting.ics"; size=6857; creation-date="Wed, 27 May 2020 16:32:18 GMT"; modification-date="Wed, 27 May 2020 16:32:18 GMT" Content-ID: <39118A2BE2F7CD4294B45129D13A735D@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkF0bGFudGljL1JleWtqYXZpaw0KVFpVUkw6aHR0cDovL3R6dXJsLm9yZy96 b25laW5mby1vdXRsb29rL0F0bGFudGljL1JleWtqYXZpaw0KWC1MSUMtTE9DQVRJT046QXRsYW50 aWMvUmV5a2phdmlrDQpCRUdJTjpTVEFOREFSRA0KVFpPRkZTRVRGUk9NOiswMDAwDQpUWk9GRlNF VFRPOiswMDAwDQpUWk5BTUU6R01UDQpEVFNUQVJUOjE5NzAwMTAxVDAwMDAwMA0KRU5EOlNUQU5E QVJEDQpFTkQ6VlRJTUVaT05FDQpCRUdJTjpWRVZFTlQNCkRUU1RBTVA6MjAyMDA1MjdUMTYzMjA0 Wg0KQVRURU5ERUU7Q049ImRhbmllbC5taWdhdWx0QGVyaWNzc29uLmNvbSI7Uk9MRT1SRVEtUEFS VElDSVBBTlQ7UlNWUD1UUlVFOk1BSUxUTzpkYW5pZWwubWlnYXVsdEBlcmljc3Nvbi5jb20NCk9S R0FOSVpFUjtDTj0iSmltIFNjaGFhZCI6TUFJTFRPOmFjZS1jaGFpcnNAaWV0Zi5vcmcNCkRUU1RB UlQ7VFpJRD1BdGxhbnRpYy9SZXlramF2aWs6MjAyMDA2MjJUMTQwMDAwDQpEVEVORDtUWklEPUF0 bGFudGljL1JleWtqYXZpazoyMDIwMDYyMlQxNTMwMDANCkxPQ0FUSU9OOmh0dHBzOi8vaWV0Zi53 ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW1mMTBlMmYwNDI4MGNmMjI1YzVkMjM3NDk3M2RmNDhi NQ0KVFJBTlNQOk9QQVFVRQ0KU0VRVUVOQ0U6MTU5MDU5NzEyNA0KVUlEOmE1Yjk4OWEzLWYzZDQt NDRkNS05MDUwLTkzMGU5NTg1Y2FlZg0KREVTQ1JJUFRJT046XG5cblxuXG5KT0lOIFdFQkVYIE1F RVRJTkdcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW1mMTBlMmYwNDI4 MGNmMjI1YzVkMjM3NDk3M2RmNDhiNVxuTWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogMTYx IDM0OCAzODI1XG5cblxuTWVldGluZyBwYXNzd29yZDogZDU0ZlNiRFhIYjZcblxuXG5cbkpPSU4g QlkgUEhPTkVcbjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSlc blRhcCBoZXJlIHRvIGNhbGwgKG1vYmlsZSBwaG9uZXMgb25seSwgaG9zdHMgbm90IHN1cHBvcnRl ZCk6IHRlbDolMkIxLTY1MC00NzktMzIwOCwsKjAxKjE2MTM0ODM4MjUlMjMlMjMqMDEqXG5cbkds b2JhbCBjYWxsLWluIG51bWJlcnNcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9nbG9iYWxj YWxsaW4ucGhwP01USUQ9bTI5MTJhMjQyNGQ3YzRjN2U1MjJjNjkxZTY4YTVhYWJkXG5cblxuSk9J TiBGUk9NIEEgVklERU8gU1lTVEVNIE9SIEFQUExJQ0FUSU9OXG5EaWFsIHNpcDoxNjEzNDgzODI1 QGlldGYud2ViZXguY29tXG5Zb3UgY2FuIGFsc28gZGlhbCAxNzMuMjQzLjIuNjggYW5kIGVudGVy IHlvdXIgbWVldGluZyBudW1iZXIuXG5cblxuSm9pbiB1c2luZyBNaWNyb3NvZnQgTHluYyBvciBN aWNyb3NvZnQgU2t5cGUgZm9yIEJ1c2luZXNzXG5EaWFsIHNpcDoxNjEzNDgzODI1LmlldGZAbHlu Yy53ZWJleC5jb21cblxuXG5cbkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/XG5odHRwczovL2NvbGxh Ym9yYXRpb25oZWxwLmNpc2NvLmNvbS9hcnRpY2xlL1dCWDAwMDAyOTA1NVxuXG5cbklNUE9SVEFO VCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJleCBzZXJ2aWNlIGFsbG93cyBhdWRp byBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVj b3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpv aW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVj b3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNz IHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi5c bg0KWC1BTFQtREVTQztGTVRUWVBFPXRleHQvaHRtbDo8c3R5bGUgdHlwZT0idGV4dC9jc3MiPlxu KiB7XG4gICAgcGFkZGluZzogMDsgICAgbWFyZ2luOiAwO31cbnRhYmxlIHtcbglib3JkZXItY29s bGFwc2U6IHNlcGFyYXRlOyB3aWR0aCA9MTAwJTsJYm9yZGVyOiAwOwlib3JkZXItc3BhY2luZzog MDt9XG5cbnRyIHtcbglsaW5lLWhlaWdodDogMThweDt9XG5cbmEsIHRkIHtcbglmb250LXNpemU6 IDE0cHg7CWZvbnQtZmFtaWx5OiBBcmlhbDsJY29sb3I6ICMzMzM7CXdvcmQtd3JhcDogYnJlYWst d29yZDsJd29yZC1icmVhazogbm9ybWFsOwlwYWRkaW5nOiAwO31cblxuLnRpdGxlIHtcbglmb250 LXNpemU6IDI4cHg7fVxuXG4uaW1hZ2Uge1xuCXdpZHRoOiBhdXRvOwltYXgtd2lkdGg6IGF1dG87 fVxuXG4uZm9vdGVyIHtcbgl3aWR0aDogNjA0cHg7fVxuXG4ubWFpbiB7XG5cbn1AbWVkaWEgc2Ny ZWVuIGFuZCAobWF4LWRldmljZS13aWR0aDogODAwcHgpIHtcbgkudGl0bGUge1xuCQlmb250LXNp emU6IDIycHggIWltcG9ydGFudDsJfVxuCS5pbWFnZSB7XG4JCXdpZHRoOiBhdXRvICFpbXBvcnRh bnQ7CQltYXgtd2lkdGg6IDEwMCUgIWltcG9ydGFudDsJfVxuCS5mb290ZXIge1xuCQl3aWR0aDog MTAwJSAhaW1wb3J0YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1wb3J0YW50XG4JfVxuCS5tYWlu IHtcbgkJd2lkdGg6IDEwMCUgIWltcG9ydGFudDsJCW1heC13aWR0aDogNjA0cHggIWltcG9ydGFu dFxuCX1cbn1cbjwvc3R5bGU+XG5cbjx0YWJsZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0icGFk ZGluZzogMDsgbWFyZ2luOiAwOyBib3JkZXI6IDA7IHdpZHRoOiAxMDAlOyIgYWxpZ249ImxlZnQi PlxuCTx0ciBzdHlsZT0iaGVpZ2h0OiAyOHB4Ij48dGQ+Jm5ic3A7PC90ZD48L3RyPlxuCTx0cj5c bgkJPHRkIGFsaWduPSJsZWZ0IiBzdHlsZT0icGFkZGluZzogMCAyMHB4OyBtYXJnaW46IDAiPlxu CQkJPCEtLTx0YWJsZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0iYm9yZGVyOiAwcHg7IHdpZHRo OiAxMDAlOyBwYWRkaW5nLWxlZnQ6IDUwcHg7IHBhZGRpbmctcmlnaHQ6IDUwcHg7IiBhbGlnbj0i bGVmdCIgY2xhc3M9Im1haW4iPlxuCQkJCTx0cj5cbgkJCQkJPHRkIGFsaWduPSJjZW50ZXIiIHZh bGlnbj0idG9wIiA+Jm5ic3A7CQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4JCQk8L3RhYmxlPi0tPlxu XG5cblxuXG5cbgkJCTx0YWJsZT5cbgkJCQk8dHI+XG4JCQkJCTx0ZD5cbgkJCQkJCTxGT05UIFNJ WkU9IjQiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+V2hlbiBpdCdzIHRpbWUsIGpvaW4g dGhlIFdlYmV4IG1lZXRpbmcgaGVyZS48L0ZPTlQ+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJ CQk8dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+ Jm5ic3A7PC90ZD48L3RyPlxuCQkJCTx0cj5cbgkJCQkJPHRkPlxuCQkJCQkJPEZPTlQgU0laRT0i MiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNv ZGUpOiAxNjEgMzQ4IDM4MjU8L0ZPTlQ+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJCTwvdGFi bGU+XG4JCQlcbgkJCTx0YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2 IiBGQUNFPSJhcmlhbCI+TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0la RT0iMiIgIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+ZDU0ZlNiRFhIYjY8L0ZPTlQ+PC90 ZD48L3RyPjwvdGFibGU+XG5cbiAgICAgICAgPHRhYmxlPlxuICAgICAgICAJPHRyIHN0eWxlPSJs aW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90 cj5cbgkJCTx0cj5cbgkJCQk8dGQgc3R5bGU9IndpZHRoOmF1dG8haW1wb3J0YW50OyAiPlxuCQkJ CQk8dGFibGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiIHN0eWxl PSJ3aWR0aDphdXRvO3dpZHRoOmF1dG8haW1wb3J0YW50O2JhY2tncm91bmQtY29sb3I6IzQzQTk0 MjsgYm9yZGVyOjBweCBzb2xpZCAjNDNBOTQyOyBib3JkZXItcmFkaXVzOjI1cHg7IG1pbi13aWR0 aDoxNjBweCFpbXBvcnRhbnQ7Ij5cbgkJCQkJCTx0cj5cbgkJCQkJCQk8dGQgYWxpZ249ImNlbnRl ciIgc3R5bGU9InBhZGRpbmc6MTBweCAzNnB4OyI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4 LmNvbS9pZXRmL2oucGhwP01USUQ9bWYxMGUyZjA0MjgwY2YyMjVjNWQyMzc0OTczZGY0OGI1IiBz dHlsZT0iY29sb3I6I0ZGRkZGRjsgZm9udC1zaXplOjIwcHg7IHRleHQtZGVjb3JhdGlvbjpub25l OyI+Sm9pbiBtZWV0aW5nPC9hPjwvdGQ+XG4JCQkJCQk8L3RyPlxuCQkJCQk8L3RhYmxlPlxuCQkJ CTwvdGQ+XG4JCQk8L3RyPlxuCQk8L3RhYmxlPlxuXG4gPEZPTlQgc2l6ZT0iMiIgQ09MT1I9IiNG RjAwMDAiIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7Ij48L0ZPTlQ+XG48Rk9OVCBTSVpFPSIx IiBGQUNFPSJBUklBTCI+Jm5ic3A7PEJSPiZuYnNwOzxCUj48L0ZPTlQ+XG5cbiZuYnNwOyA8QlI+ PEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2 IiBGQUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwvRk9OVD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpF PSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxiPjxhIGhyZWY9J3RlbDolMkIxLTY1 MC00NzktMzIwOCwsKjAxKjE2MTM0ODM4MjUlMjMlMjMqMDEqJyBzdHlsZT0nY29sb3I6IzAwQUZG OTsgIHRleHQtZGVjb3JhdGlvbjpub25lOyBmb250LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAx NHB4O2xpbmUtaGVpZ2h0OiAyNHB4Oyc+MS02NTAtNDc5LTMyMDg8L2E+PC9iPiBDYWxsLWluIHRv bGwgbnVtYmVyIChVUy9DYW5hZGEpPC9GT05UPiAmbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENP TE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNv bS9pZXRmL2dsb2JhbGNhbGxpbi5waHA/TVRJRD1tMjkxMmEyNDI0ZDdjNGM3ZTUyMmM2OTFlNjhh NWFhYmQiIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtmb250LXNpemU6MTRweDtjb2xvcjoj MDBBRkY5Ij5HbG9iYWwgY2FsbC1pbiBudW1iZXJzPC9hPjwvRk9OVD4mbmJzcDsgPEJSPjxCUj48 QlI+XG5cbjx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJo ZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+XG5cbjxGT05UIFNJWkU9IjQiIEZB Q0U9IkFSSUFMIj48Rk9OVCBTSVpFPSIzIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkpv aW4gZnJvbSBhIHZpZGVvIHN5c3RlbSBvciBhcHBsaWNhdGlvbjwvRk9OVD48QlI+PEZPTlQgU0la RT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5EaWFsPC9GT05UPiA8YSBocmVmPSJz aXA6MTYxMzQ4MzgyNUBpZXRmLndlYmV4LmNvbSI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiMwMEFG RjkiIEZBQ0U9ImFyaWFsIj4xNjEzNDgzODI1QGlldGYud2ViZXguY29tPC9GT05UPjwvYT4mbmJz cDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+WW91IGNh biBhbHNvIGRpYWwgMTczLjI0My4yLjY4IGFuZCBlbnRlciB5b3VyIG1lZXRpbmcgbnVtYmVyLjwv Rk9OVD4gJm5ic3A7IDxCUj48L0ZPTlQ+Jm5ic3A7IDxCUj5cblxuPHRhYmxlIGNlbGxwYWRkaW5n PSIwIiBjZWxsc3BhY2luZz0iMCI+PHRyPjx0ZCAgc3R5bGU9ImNvbG9yOiAjMDAwMDAwOyBmb250 LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxMnB4OyBmb250LXdlaWdodDogYm9sZDsgbGluZS1o ZWlnaHQ6IDI0cHg7Ij48Yj5Kb2luIHVzaW5nIE1pY3Jvc29mdCBMeW5jIG9yIE1pY3Jvc29mdCBT a3lwZSBmb3IgQnVzaW5lc3M8L2I+PC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRk IHN0eWxlPSJjb2xvcjogIzMzMzMzMzsgZm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6IDE0 cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+RGlhbCA8YSBocmVmPSIgc2lwOjE2MTM0ODM4MjUuaWV0 ZkBseW5jLndlYmV4LmNvbSIgICBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Y29sb3I6IzAw QUZGOSI+MTYxMzQ4MzgyNS5pZXRmQGx5bmMud2ViZXguY29tPC9hPjwvdGQ+PC90cj48L3RhYmxl PlxuXG4JCQk8dGFibGUgc3R5bGU9IndpZHRoOiAxMDAlOyIgYWxpZ249ImxlZnQiIGNsYXNzPSJt YWluIj5cbiAgICAgICAgICAgICAgICA8dHIgc3R5bGU9ImhlaWdodDogNzJweCI+PHRkPiZuYnNw OzwvdGQ+PC90cj5cbgkJCQk8dHI+XG4JCQkJCTx0ZCBzdHlsZT0iaGVpZ2h0OiAyNHB4OyBjb2xv cjogIzAwMDAwMDsgZm9udC1mYW1pbHk6QXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWln aHQ6IDI0cHg7Ij5OZWVkIGhlbHA/IEdvIHRvIDxhIGhyZWY9Imh0dHA6Ly9oZWxwLndlYmV4LmNv bSIgc3R5bGU9ImNvbG9yOiMwNDlGRDk7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+aHR0cDovL2hl bHAud2ViZXguY29tPC9hPlxuCQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4gICAgICAgICAgICAgICAg PHRyIHN0eWxlPSJoZWlnaHQ6IDQ0cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JCQk8L3RhYmxl PlxuCQk8L3RkPlxuCTwvdHI+XG48L3RhYmxlPlxuDQpTVU1NQVJZOkFDRSBpbnRlcmltIDA3DQpQ UklPUklUWTo1DQpDTEFTUzpQVUJMSUMNCkJFR0lOOlZBTEFSTQ0KVFJJR0dFUjotUFQ1TQ0KQUNU SU9OOkRJU1BMQVkNCkRFU0NSSVBUSU9OOlJlbWluZGVyDQpFTkQ6VkFMQVJNDQpFTkQ6VkVWRU5U DQpFTkQ6VkNBTEVOREFSDQo= --_005_SA0PR15MB37912F464265A81ADA3BBDB6E3B10SA0PR15MB3791namp_-- From nobody Wed May 27 16:42:47 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582973A0DAE; Wed, 27 May 2020 16:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 AF3vmT1v-87O; Wed, 27 May 2020 16:42:34 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 5E3B93A0DB1; Wed, 27 May 2020 16:42:33 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 04RNgSxu029348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 27 May 2020 19:42:31 -0400 Date: Wed, 27 May 2020 16:42:27 -0700 From: Benjamin Kaduk To: Olaf Bergmann Cc: ace@ietf.org, draft-ietf-ace-dtls-authorize.all@ietf.org Message-ID: <20200527234227.GD58497@kduck.mit.edu> References: <20200102234020.GI35479@kduck.mit.edu> <87pnca9gyx.fsf@wangari> <20200429011210.GC27494@kduck.mit.edu> <87mu6bn6zy.fsf@wangari> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87mu6bn6zy.fsf@wangari> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 27 May 2020 23:42:42 -0000 On Wed, May 13, 2020 at 06:18:25PM +0200, Olaf Bergmann wrote: > Hi Ben, > > Benjamin Kaduk writes: > > > Please go ahead and upload a new version to the datatracker when you get a > > chance; I do have some further comments below. > > Thanks again for the detailed response. I have just submitted version > -10 that includes changes to your previous comments as well as the > suggestions below: Thanks! I think we will probably need an -11 fairly soon, though, given the remaining comments I have. A couple general remarks looking at the -09-to-10 diff (not all new in the -10, so I guess I missed it the first time around): In Section 3.2.1, I suggest applying: OLD: [...] If CBOR web tokens [RFC8392] are used as recommended in [I-D.ietf-ace-oauth-authz] [...] NEW: [...] If CBOR web tokens [RFC8392] are used (as recommended in [I-D.ietf-ace-oauth-authz]) [...] Making this a parenthetical statement makes it clear that the conditional for "keys MUST be encoded" is "CWT are used" and separate from the recommendation to do so. Also in 3.2.1, we now have these two statements in fairly close proximity: [RFC8747]. The resource server MUST use its own raw public key in the DTLS handshake with the client. If the resource server has several raw public keys, it must already know which key it is supposed to use with this client. How this is achieved is not part of this profile. The resource server MUST use the keying material that the authorizations server has specified in the "cnf" parameter in the access token for the DTLS handshake with the client. Thus, the which seems a bit redundant and potentially in conflict. Can we consolidate this requirement a bit? In Section 3.3: To convey the same secret to the resource server, the authorization server either includes it directly in the access token by means of the "cnf" claim or it provides sufficient information to enable the resource server to derive the key from the access token using key derivation. This text could be read as prohibiting using token introspection to obtain the C/RS shared key (if I remember correctly about "claim" being a CWT thing and not a more generic term for a parameter associated with a token). I don't think that's the intent, so perhaps a wording tweak is in order. In Section 3.3.1: If a resource server receives a ClientKeyExchange message that contains a "psk_identity" with a length greater than zero, it MUST process the contents of the "psk_identity" field as access token that is stored with the authorization information endpoint, before continuing the DTLS handshake. If the contents of the "psk_identity" do not yield a valid access token for the requesting client, the resource server aborts the DTLS handshake with an "illegal_parameter" alert. The way this was reworded seems to imply that any "psk_identity" with positive length is a full access token (as would have been uploaded to the authz-info endpoint), which prevents the case previously described where the identity is just a COSE_Key with the 'kid' from "rs_cnf". So I think we still need some kind of description of two potential interpretations of the "psk_identity". In section 3.4, we updated the text about "a common understanding" between RS and AS about how access tokens are ordered, and reworded the text about checking authorization on every request. I think we could say a little bit more about how there is not a strict guarantee of processing order for requests and authorization updates, so requests that occur around the time of an authorization update might be processed using either the old or new authorization rules. Even just referencing Section 7.2 would be enough. (more inline) > > On Tue, Apr 14, 2020 at 06:20:38PM +0200, Olaf Bergmann wrote: > >> Ben, > >> > >> Thanks again for the thorough review of the ACE DTLS profile and my > >> sincere apologies for the long time it took to process. Please find our > >> comments inline. As this comprises a lot of changes, the proposed text > >> already has been included in the Editor's copy [1]. Our proposals for > >> new text are in the section-by-section comments. > >> > >> [1] https://ace-wg.github.io/ace-dtls-profile/ > >> > >> Benjamin Kaduk writes: > >> > >> > Hi all, > >> > > >> > Some high-level remarks before delving into the section-by-section > >> > comments: > >> > > >> > This document is pretty clearly DTLS 1.2-specific -- it talks about > >> > particular protocol messages, message fields, and cipher suites that > >> > simply do not apply to DTLS 1.3. In order to use this profile with DTLS > >> > 1.3, we'd need to specify the analogous behavior/requirements to these > >> > (including standalone signature schemes and key-exchange groups, which > >> > are now both separately negotiated from the cipher suite). > >> > Given that DTLS 1.3 is past WGLC and only a few documents behind this > >> > one in my review queue, it seems fairly prudent to spend some time and > >> > cover how DTLS 1.3 would work here, since otherwise this document will > >> > become stale shortly after (or even before!) its publication as an RFC. Is anyone working on a DTLS 1.3 version? > >> > There's probably some additional discussion to include about the usage of > >> > key identifiers in this document versus the potential uses described in > >> > the core framework. Specifically, the framework reminds us that "no > >> > assumptions should be made that it is unique in the domains of either > >> > the client or the RS" yet this document is using the kid as input to a > >> > KDF that produces keys that must be unique across all clients, and > >> > allowing live/instant authorization updates based on matching "kid". > >> > How shall we resolve this apparent conflict? > >> > > >> > We also are potentially in violation of the framework's requirements > >> > with respect to the independent selection of profiles for client/AS and > >> > client/RS interactions -- at present, when DTLS+RPK is used for > >> > client/RS, we require that DTLS+RPK is also used for client/AS, in order > >> > to prove possession of the key. We could perhaps weasel our way out by > >> > saying that the framework's requirement applies at the profile > >> > granularity, and with symmetric PSK we can be fully independent, but we > >> > still need to say something about this property and the interaction with > >> > the framework's requirements. > >> > > >> > This profile is mostly applicable to the client/RS communications and > >> > feels like it only provides some of the picture for use with client/AS > >> > interactions. (It doesn't really say much of anything about RS/AS > >> > interactions.) The introductory discussion does not do a great job of > >> > painting that picture, and I'd like to see it more clearly introduced > >> > that the bulk of our coverage is for the client/RS interaction. We also > >> > lean heavily on the existing out-of-band configuration and key material > >> > shared between client and AS to secure the client/AS communications; we > >> > could probably tighten up the discussion about exactly what parameters > >> > of client/AS communication are specified by this profile. > >> > >> The introduction has been revised according to your suggested text, see > >> below. We also have included some text on the out-of-band configuration > >> in a new subsection in the security considerations. The important thing > >> here really are the client/RS and client/AS interactions. Regarding > >> client/AS, much of this is out of scope as there are certain > >> OAuth-related assumptions on how these entities get in touch with each > >> other; neither the framework nor the profile can do much about it > >> without creating a new enrollment protocol. Regarding the RS/AS > >> interaction, there is normative language that describes what each of > >> these entities needs to do in each protocol step covered by the > >> document. The necessary out-of-band configuration again is described in > >> the new subsection in the security considerations as well as some > >> clarifications in the text, see below. > >> > >> > We do not say anything about DTLS session resumption (or renegotiation, > >> > though not talking about that one is perfectly fine); that's a fairly > >> > core DTLS concept that we should give some guidance on. > >> > >> Not sure if we really need to but if you think this is necessary, we can > >> comment on this, of course. > > > > I think we need to give some guidance about what the semantics are if/when > > it happens. My inclination would be to say that DTLS resumption can be > > used to amortize the cost of a handshake, but DTLS 1.2 resumption does not > > provide forward secrecy and also does not provide an opportunity for the > > client to prove possession of the PoP key, so servers will want to > > periodically force a full handshake according to their authentication > > requirements. I'd also be inclined to forbid renegotiation entirely. > > True, especially because RFC 7925 requires resumption to be > implemented. The security considerations now advise against session > resumptions and renegotiation as you have suggested. The Security > Considerations section now has been structured in sub-sections for > clarity. The discussion in the -10 is reasonable (and the stated motivation of having a fresh proof of possession is fairly compelling), though to be clear, my initial "inclination" above was just to forbid renegotiation but allow resumption. > >> > Looking through Appendix C ("Requirements on Profiles") of the > >> > framework, do we want to say anything about: > >> > > >> > - using the client credentials grant with this profile, as that's IIRC > >> > the only example we show > >> > >> Do you think we need to say anything here? The actual grant used to > >> make the client known to the AS is out of scope for the profile as > >> long as the requirements given here are met. > > > > I don't think we strictly need to, no. > > > >> > - require that DTLS be used in a mode that provides replay protection > >> > >> Added as a requirement in Section 2. > >> > >> > - when the client uses the authz-info endpoint instead of the > >> > "psk_identity" field to convey the token to the RS, how does the RS > >> > know which client is connecting (and thus what PSK to use), and what > >> > does the client actually *put* in the "psk_identity" field? (The > >> > other aspects of "how to select a proof-of-possession protocol" seem > >> > to fall out naturally from the DTLS usage.) > >> > >> We have included more explanatory text in section 3.3.1 on how this is > >> supposed to work. > > > > It looks like we now say the client "MUST include an access token that > > indicates the kid contained in the uploaded access token as psk_identity", > > which seems to be talking about two different access tokens. Is one of > > them uploaded to authz-info and the other used to populate the > > "psk_identity" field? The following sentences seem to imply that, but the > > quoted sentence is hard to parse. Perhaps just "The client then needs to > > indicate during the DTLS handshake which previously uploaded access token > > it intends to use." That proposed text drops the "MUST", so maybe we would > > want to put that back in the later sentence(s). > > Agreed. The text now reads: > > OLD: > > The client then MUST include an access token that indicates the > `kid` contained in the uploaded access token as `psk_identity`. > To do so, it creates… > > NEW: > > The client then needs to indicate during the DTLS handshake which > previously uploaded access token it intends to use. To do so, it > MUST create… > > >> > - whether/how introspection is used? > >> > >> We have added text stating that token introspection may be used but is > >> out of scope for the profile spec. > >> > >> > - give more details of what this profile mandates when used for > >> > client/AS interactions (as mentioned above) > >> > >> This should be covered now, see detailed responses below. > >> > >> > - explicitly state that the authz-info endpoint is unprotected (or that > >> > it might be protected if, e.g., the RS has a trustable certificate > >> > that would be used instead of RPK or PSK, or by supplying the > >> > token as the "psk_identity" when symmetric PoP is used, or by only > >> > doing server-authentication with RPK as known by the client by the > >> > rs_cnf access information > >> > >> I am not sure which security gain we would yield by trustable > >> certificates: The client does not need to authenticate the resource > >> server for the authz-info upload. The important aspect here is that the > >> access token must be integrity-protected by the AS and encrypted if it > >> contains information to be kept confidential (esp. a shared secret but > >> possibly other data as well). We have added some text on this to the > >> security considerations. > > > > It looks like this will be enough to meet the requirements from the > > framework (though I'm not looking at an actual diff so I'm not 100% sure). > > > >> > And now, on to the section-by-section comments. > >> > > >> > Section 1 > >> > > >> > a DTLS session. The communication between client and authorization > >> > server may also be secured with DTLS. This specification supports > >> > DTLS with Raw Public Keys (RPK) [RFC7250] and with Pre-Shared Keys > >> > (PSK) [RFC4279]. > >> > > >> > [DTLS 1.3 will inherit TLS 1.3's built-in support for (so-called > >> > "external") PSKs.] > >> > >> (See general discussion on wether DTLS 1.3 needs to be addressed at this > >> time.) > >> > >> > The DTLS handshake requires the client and server to prove that they > >> > can use certain keying material. In the RPK mode, the client proves > >> > with the DTLS handshake that it can use the RPK bound to the token > >> > and the server shows that it can use a certain RPK. The access token > >> > must be presented to the resource server. For the RPK mode, the > >> > access token needs to be uploaded to the resource server before the > >> > handshake is initiated, as described in Section 5.8.1 of the ACE > >> > framework [I-D.ietf-ace-oauth-authz]. > >> > > >> > This seems to be making some implicit assumptions about the message flow > >> > that have not yet been covered by this document and are only somewhat > >> > covered by the core framework spec. I'd propose: > >> > > >> > % The ACE framework requires that client and server mutually > >> > % authenticate each other before any other protocol exchanges take > >> > % place. > >> > >> Actually, this is not true: The client can upload data to the > >> resource server's authorization endpoint without authentication. I > >> suggest to rephrase this as "The ACE framework requires that client > >> and server mutually authenticate each other before any application > >> data is exchanged.", see below. > > > > Good catch, thanks! > > > >> > % In order for DTLS to provide mutual authentication, both > >> > % client and server must prove their ability to use certain keying > >> > % material (tied to the authenticated identity) as part of the DTLS > >> > % handshake. The AS assists in this process by incorporating key > >> > % material (or information about key material) into the access token, > >> > % which is considered a "proof of possession" token. In the RPK mode, > >> > % the client proves that it can use the RPK bound to the token and the > >> > % server shows that it can use a certain RPK (as indicated by the AS to > >> > % the client). The resource server needs access to the token in order > >> > % to complete this exchange. For the RPK mode, the access token needs > >> > % to be uploaded to the resource server before the handshake is > >> > % initiated, as described in Section 5.8.1 of the ACE framework > >> > % [I-D.ietf-ace-oauth-authz]. > >> > > >> > though I recognize that my text tends to be a bit more verbose than is > >> > strictly needed, so please feel free to edit it down. > >> > >> We propose the following change: > >> > >> OLD: > >> > >> The DTLS handshake requires the client and server to prove that they > >> can use certain keying material. In the RPK mode, the client proves > >> with the DTLS handshake that it can use the RPK bound to the token > >> and the server shows that it can use a certain RPK. The access token > >> must be presented to the resource server. For the RPK mode, the > >> access token needs to be uploaded to the resource server before the > >> handshake is initiated, as described in Section 5.8.1 of the ACE > >> framework {{I-D.ietf-ace-oauth-authz}}. > >> > >> NEW: > >> > >> The ACE framework requires that client and server mutually > >> authenticate each other before any application data is exchanged. > >> DTLS enables mutual authentication if both client and server prove > >> their ability to use certain keying material in the DTLS handshake. > >> The authorization server assists in this process on the server side > >> by incorporating keying material (or information about keying > >> material) into the access token, which is considered a "proof of > >> possession" token. > >> > >> In the RPK mode, the client proves that it can use the RPK bound to > >> the token and the server shows that it can use a certain RPK (as > >> indicated by the authorization server to the client). > >> > >> The resource server needs access to the token in order to complete > >> this exchange. For the RPK mode, the client must upload the access > >> token to the resource server before initiating the handshake, as > >> described in Section 5.8.1 of the ACE framework > >> {{I-D.ietf-ace-oauth-authz}}. > > > > This looks good. > > > >> > Section 2 > >> > > >> > The CoAP-DTLS profile for ACE specifies the transfer of > >> > authentication information and, if necessary, authorization > >> > information between the client (C) and the resource server (RS) > >> > during setup of a DTLS session for CoAP messaging. It also specifies > >> > how C can use CoAP over DTLS to retrieve an access token from the > >> > authorization server (AS) for a protected resource hosted on the > >> > resource server. > >> > > >> > I suggest reiterating that "As specified in Section 6.7 of > >> > [I-D.ietf-ace-oauth-authz], use of DTLS for one or both of these > >> > interactions is completely independent". > >> > >> done > >> > >> > To determine the AS in charge of a resource hosted at the RS, C MAY > >> > send an initial Unauthorized Resource Request message to the RS. The > >> > > >> > This is part of the core framework, so the "MAY" may be overkill. > >> > (Lowercase "can" would do just fine.) > >> > >> done > >> > >> > Once the client knows the authorization server's address, it can send > >> > an access token request to the token endpoint at the AS as specified > >> > > >> > Hmm. There's some level of "the client needs to have already been > >> > configured that that AS is a valid AS" verification that's done here, > >> > but I'm not sure if that's too much detail to include at this stage > >> > (since we're really just summarizing the framework here). > >> > >> Yes, there has been a discussion on this. The issue with this three > >> corner model is that the client needs a pretty tight relationship with > >> the AS, meaning that it must be able to recognize an AS depicted in the > >> AS Request Creation Hints as trustworthy. > >> > >> > in [I-D.ietf-ace-oauth-authz]. As the access token request as well > >> > as the response may contain confidential data, the communication > >> > between the client and the authorization server MUST be > >> > > >> > (This "MUST" is already a requirement from the core framework, so we > >> > don't necessarily need to repeat it as normative language.) > >> > >> Okay, changed to lower case. > >> > >> > confidentiality-protected and ensure authenticity. C may have been > >> > registered at the AS via the OAuth 2.0 client registration mechanism > >> > as outlined in Section 5.3 of [I-D.ietf-ace-oauth-authz]. > >> > > >> > Section 5.3 of oauth-authz says that registration is "out of scope"; is > >> > this still the right reference? > >> > >> It is the correct reference but unfortunately, Section 5.3 of the > >> framework document just says that "Authentication of the client is > >> mandatory". The issue here is that the framework as well as OAuth > >> requires a prior registration of the client. Otherwise, the AS would not > >> be able to authorize the client in the three corner model. Not including > >> the reference would mean to repeat the requirement of client > >> registration here. > > > > Okay. > > > >> > [I-D.ietf-ace-oauth-authz]. In case the client uses a symmetric > >> > proof-of-possession key in the DTLS handshake, the procedure as above > >> > MAY be used, or alternatively, the access token MAY instead be > >> > transferred in the DTLS ClientKeyExchange message (see > >> > Section 3.3.1). > >> > > >> > (This is not DTLS 1.3-compatible.) > >> > >> Agreed. This would need a change if we decided to add-in support for > >> DTLS 1.3. > >> > >> > Section 3 > >> > > >> > secured. Depending on the used CoAP security mode (see also > >> > Section 9 of [RFC7252], the Client-to-AS request, AS-to-Client > >> > response and DTLS session establishment carry slightly different > >> > information. [...] > >> > > >> > At this point in the document it's pretty unclear what "Client-to-AS > >> > request", "AS-to-Client response", and "DTLS session establishment" are > >> > and how they relate to each other. > >> > >> The "Client-to-AS request" and "AS-to-Client response" are introduced by > >> the ACE framework document. Maybe an explicit reference helps to avoid > >> confusion. > >> > >> OLD: > >> > >> Depending on the used CoAP security mode (see also Section 9 of > >> {{RFC7252}}, the Client-to-AS request, AS-to-Client response and DTLS > >> session establishment carry slightly different > >> information. {{rpk-mode}} addresses the use of raw public keys while > >> {{psk-mode}} defines how pre-shared keys are used in this profile. > >> > >> NEW: > >> > >> Depending on the used CoAP security mode (see also Section 9 of > >> {{RFC7252}}, the Client-to-AS request, AS-to-Client response (see > >> Section 5.6 of {{I-D.ietf-ace-oauth-authz}}) and DTLS session > >> establishment carry slightly different information. {{rpk-mode}} > > > > Thanks! > > > >> > Also, it seems like the behavior in Section 3.2 and 3.3 are relating to > >> > the mode used for the client/RS interactions, which relates to the > >> > client/AS interactions only in the form of how PoP information is bound > >> > to/with the token. > >> > >> I am not sure if there is anything else to say about the client/AS > >> interactions that is not covered by the framework. > >> > >> > Section 3.1 > >> > > >> > establish a secure communication channel. C MUST securely have > >> > obtained keying material to communicate with AS. Furthermore, C MUST > >> > verify that AS is authorized to provide access tokens (including > >> > authorization information) about RS to C. Also, AS MUST securely > >> > have obtained keying material for C, and obtained authorization rules > >> > approved by the resource owner (RO) concerning C and RS that relate > >> > to this keying material. [...] > >> > > >> > The way this is written right now, we're going to get lots of questions > >> > from reviewers about "how does this happen?" and for more details about > >> > it. We are effectively assuming that this stuff is all provisioned > >> > already as part of the device configuration or during enrollment, we > >> > should say something about these being requirements on device > >> > provisioning, not on the operation of the ACE protocol. > >> > >> The following new text has been added for clarification: > >> > >> NEW: > >> > >> This profile assumes that the keying material to secure this > >> communication channel has securely been obtained either by manual > >> configuration or in an automated provisioning process. > > > > Thanks! > > > >> > between C and AS is bootstrapped is not part of this document. C and > >> > AS MUST ensure the confidentiality, integrity and authenticity of all > >> > exchanged messages. > >> > > >> > I think this is also restating requirements from the core framework, and > >> > may not need normative language in this manner. > >> > >> done > >> > >> > Section 3.2 > >> > > >> > I know that the section heading says "RawPublicKey Mode" already, but > >> > I'd recommend adding a sentence in the preface that repeats that "When > >> > the client and RS use RawPublicKey authentication, the procedure is as > >> > follows"; we might get complaints otherwise that we are saying that the > >> > client MUST do things that are not universal requirements. > >> > (Section 3.3 does already have something like this for the symmetric-key > >> > case.) > >> > >> done > >> > >> > previously made known to the authorization server. To prove that the > >> > client is in possession of this key, C MUST use the same keying > >> > material that it uses to secure the communication with AS, e.g., the > >> > DTLS session. > >> > > >> > This seems in conflict with the core framework's requirement that the > >> > client/AS profile and client/RS profile are severable. > >> > >> This profile explicitly specifies the communication flow between C and > >> AS on one side and between C and RS on the other. As both legs are part > >> of this profile, there is no combination of profiles involved. In that > >> regard, there is no such assumption as indicated in Section 6.7 of the > >> framework. > >> > >> *) https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-33#section-6.7 > >> > >> We could weaken the security here by removing the "To prove"-statement. > >> However, it is advisable not to do this because by using the keying > >> material in the C/AS communication, C shows that it is actually in > >> possession of the respective private key. This would raise the bar for > >> the client to retrieve access tokens in the name of other clients. > >> > >> The preferred alternative would be replace MUST with SHOULD: > >> > >> OLD: > >> > >> previously made known to the authorization server. To prove that the > >> client is in possession of this key, C MUST use the same keying > >> material that it uses to secure the communication with AS, e.g., the > >> DTLS session. > >> > >> NEW: > >> > >> previously made known to the authorization server. To prove that the > >> client is in possession of this key, C SHOULD use the same keying > >> material that it uses to secure the communication with AS, e.g., the > >> DTLS session. > > > > That seems like it's going in the right direction, but I'm not sure it's > > the precise change we want. Basically, we need to keep the requirement > > that the client prove possession of the key, and we want the recommended > > way to be to use it for DTLS with the AS, but we can't require that the > > client use DTLS to talk to the AS, because we "MUST NOT depend on the > > assumption that the profile is used for all the different types of > > interactions". So perhaps > > > > NEWNEW: > > > > % previously made known to the authorization server. It is RECOMMENDED that > > % C use DTLS with the same keying material to secure the communication with > > % AS, proving possession of the key as part of the token request, but other > > % mechanisms for proving possession of the key may be defined in the > > % future. > > Done. > > >> > >> > AS MUST check if the client that it communicates with is associated > >> > with the RPK in the cnf object before issuing an access token to it. > >> > > >> > Earlier in the section we noted a requirement to prove possession of the > >> > key by using it in DTLS; why is there a separate "association" > >> > requirement? > >> > >> This is the same rationale as above. The AS needs some way to decide > >> which authorization rules apply to the requesting client. There was a > >> discussion on the mailing list that the client may use a different RPK > >> in the communication with AS than it uses in the communication with the > >> resource server. AS then must ensure two things: First, that the > >> authorization decision coded into the access token applies to the RPK > >> provided by C. Second, that the access token is transferred to the same > >> C. > >> > >> The following text has been added to the Security Considerations to > >> explain the problems that arise from using different RPKs for the C/AS > >> and C/RS communication: > >> > >> NEW: > >> > >> The authorization server must ascertain that the keying material > >> for the client that it provides to the resource server actually is > >> associated with this client. Malicious clients may hand over > >> access tokens containing their own access permissions to other > >> entities. This problem cannot be completely > >> eliminated. Nevertheless, in RPK mode it should not be possible > >> for clients to request access tokens for arbitrary public keys, > >> since that would allow the client to relay tokens without the need > >> to share its own credentials with others. The authorization server > > > > I think this sentence could probably be wordsmithed some more, though I > > don't have a concrete proposal at the moment. It does seem like we might > > want to discuss this scenario more in terms of "identity misbinding" than > > "relay tokens", though. (We had a SAAG talk at IETF 104 about misbinding > > attacks on device pairing, which is not quite the same, but shares some of > > the concepts.) > > Okay. This is the only comment I did not yet address in the text. We > might want to keep this in mind for -11. Looking at it again, perhaps: % eliminated. Nevertheless, in RPK mode it should not be possible % for clients to request access tokens for arbitrary public keys: if the % client can cause the AS to issue a token for a public key without % proving possession of the corresponding private key, this allows for % identity misbinding attacks where the issued token is usable by an % entity other than the intended one. [...] > >> therefore should at some point validate that the client can > >> actually use the private key corresponding to the client's public > >> key. > > > > Why is this only "should", vs. (e.g.) "needs to"? > > I am perfectly happy with the stronger "needs to" and changed the text > accordingly. > > > > >> > >> > also, nit: "The AS". > >> > >> done > >> > >> > which case it does not have to be sent. The response also contains > >> > an access token and an "rs_cnf" parameter containing information > >> > about the public key that is used by the resource server. AS MUST > >> > > >> > nit(?): is the "rs_cnf" parameter always mandatory? (Or only when > >> > DTLS-RPK is used for client-RS interactions?) > >> > >> Done as follows: > >> > >> OLD: > >> > >> The response also contains an access token and an "rs_cnf" > >> parameter containing information about the public key that is used > >> by the resource server. AS MUST ascertain that the RPK specified > >> in "rs_cnf" belongs to the resource server that C wants to > >> communicate with. > >> > >> NEW: > >> > >> The response also contains an access token with information about > >> the public key that is used by the resource server. The > > > > This sounds like "the information[...]" is part of the access token; maybe > > "along with"? > > What is meant here is that the information is contained in the access > token. The misleading part is that the AT contains information about the > client's RPK that the resource server uses to recognize the client in > the subsequent communication. > > I have changed this sentence to: > > NEW: > > The response also contains an access token with information for the > resource server about the client's public key. That should help a lot; thanks! > > >> authorization server MUST return in its response the parameter > >> "rs_cnf" unless it is certain that the client already knows the > >> public key of the resource server. The authorization server MUST > >> ascertain that the RPK specified in "rs_cnf" belongs to the resource > >> server that the client wants to communicate with. > >> > >> > nit: "The AS" again (and throughought, to a large extent). > >> > >> [Okay, we will change these for I-D submission.] > >> > >> > server that C wants to communicate with. AS MUST protect the > >> > integrity of the token. If the access token contains confidential > >> > data, AS MUST also protect the confidentiality of the access token. > >> > > >> > This requirement ("protect the integrity of the token") feels a little > >> > underspecified, as it doesn't say protection over what workflow or who > >> > will verify the integrity (the RS). > >> > >> done, by adding > >> > >> NEW: > >> > >> to ensure that the resource server can detect unauthorized changes. > >> > >> > C MUST ascertain that the access token response belongs to a certain > >> > previously sent access token request, as the request may specify the > >> > resource server with which C wants to communicate. > >> > > >> > nit: I recomment rewording "belongs to", perhaps as "corresponds to". > >> > DTLS can provide this guarantee when configured to do so, though it is > >> > not a guaranteed property from DTLS. > >> > >> Changed to: > >> > >> OLD: > >> > >> C MUST ascertain that the access token response corresponds to a > >> certain previously sent access token request,... > >> > >> NEW: > >> > >> the client MUST check if the access token response is bound to a > >> certain previously sent access token request, > >> > >> > We'll probably get some grief about the "access_token" contents in the > >> > example not being valid CBOR, due to the parenthetical comment. We > >> > could probably put a note in the preface that the value is truncated for > >> > readability. Also, nit: "the client's" with article and apostrophe. > >> > >> Okay. For now, I have put in a disclaimer into the description of the > >> two examples where this occurs. > > > > Thanks! > > > >> > Section 3.2.1 > >> > > >> > Before the client initiates the DTLS handshake with the resource > >> > server, C MUST send a "POST" request containing the new access token > >> > to the authz-info resource hosted by the resource server. After the > >> > client > >> > > >> > nit: we don't require single-use tokens, so "new" is probably overkill; > >> > just "its access token" should suffice. > >> > nit: formatting issue with spurious line break here. > >> > >> done > >> > >> > server. To use the RawPublicKey mode, the client MUST specify the > >> > public key that AS defined in the "cnf" field of the access token > >> > response in the SubjectPublicKeyInfo structure in the DTLS handshake > >> > as specified in [RFC7250]. > >> > > >> > IIRC the access token response does not have to include a "cnf" field > >> > (e.g., if the AS accepts the req_cnf from the request), so "defined in > >> > the field of the response" doesn't seem like quite the right wording. > >> > >> Done: > >> > >> OLD: > >> > >> To use the RawPublicKey mode, the client MUST specify the public > >> key that AS defined in the `cnf` field of the access token response > >> in the SubjectPublicKeyInfo structure in the DTLS handshake as > >> specified in {{RFC7250}}. > >> > >> NEW: > >> > >> The client MUST use its correct public key in the DTLS > >> handshake. If the authorization server has specified a `cnf` field > >> in the access token response, the client MUST use this > >> key. Otherwise, the client MUST use the public key that it > >> specified in the `req_cnf` of the access token request. The client > >> MUST specify this public key in the SubjectPublicKeyInfo structure > >> of the DTLS handshake as described in [RFC7250]. > >> > >> > An implementation that supports the RPK mode of this profile MUST at > >> > least support the ciphersuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 > >> > > >> > I understand that making the full-width-tag ciphersuite MTI would > >> > exclude some devices, though it feels like some recommendation to use > >> > the full-length tag when possible would be appropriate. That said, I do > >> > see that RFC 7252 makes no such remark, and thus consistency would have > >> > us not say anything either. > >> > >> We have now included more text on the tag length in the Security > >> Considerations, see below. > > > > Thanks; I think that text strikes a good balance. > > > >> > [RFC7251] with the ed25519 curve (cf. [RFC8032], [RFC8422]). > >> > > >> > Just to be clear: ed25519 is an ECDSA algorithm; the corresponding ECDHE > >> > operation is called x25519, and both algorithms make use of the > >> > elliptical curve known as curve25519. Since we are using both ECDHE and > >> > ECDSA, it's probably simplest to just refer to "curve25519", though > >> > mentioning both ed25519 and x25519 would also work. > >> > >> This has been a WG decision at some point but the authors agree that > >> curve25519 is the best to go for and propose the following change which > >> also gets rid of the ugly note in favor of more coherent text: > >> > >> OLD: > >> > >> An implementation that supports the RPK mode of this profile MUST > >> at least support the ciphersuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 > >> [RFC7251] with the ed25519 curve (cf. [RFC8032], [RFC8422]). > >> > >> NEW: > >> > >> To be consistent with {{RFC7252}} which allows for shortened MAC > >> tags in constrained environments, an implementation that supports > >> the RPK mode of this profile MUST at least support the ciphersuite > >> TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_CCM\_8 {{RFC7251}}. As discussed > >> in {{RFC7748}}, new ECC curves have been defined recently that are > >> considered superior to the so-called NIST curves. This specification > >> therefore mandates implementation support for curve25519 > >> (cf. {{RFC8032}}, {{RFC8422}}) as this curve said to be efficient > >> and less dangerous regarding implementation errors than the > >> secp256r1 curve mandated in {{RFC7252}}. > >> > >> > RS MUST check if the access token is still valid, if RS is the > >> > intended destination, i.e., the audience, of the token, and if the > >> > token was issued by an authorized AS. The access token is > >> > > >> > nit: "i.e., the audience" is in effect a parenthetical, so using commas > >> > to offset it inside a comma-separated list is potentially confusing; I'd > >> > suggest using actual parentheses instead of commas around it. > >> > >> done > >> > >> > reference to this key. If the authorization server has no certain > >> > knowledge that the Client's key is already known to the resource > >> > server, the Client's public key MUST be included in the access > >> > token's "cnf" parameter. If CBOR web tokens [RFC8392] are used as > >> > recommended in [I-D.ietf-ace-oauth-authz], keys MUST be encoded as > >> > specified in [I-D.ietf-ace-cwt-proof-of-possession]. RS MUST use the > >> > > >> > Is talking about """the access token's "cnf" parameter" consistent with > >> > allowing the use of non-CWT (non-JWT) token formats? > >> > >> This has been addressed by adding the following paragraph to the > >> introduction: > >> > >> NEW: > >> > >> As recommended in Section 5.8 of [I-D.ietf-ace-oauth-authz], this > >> specification uses CBOR web tokens to convey claims within an > >> access token issued by the server. While other formats could be > >> used as well, those are out of scope for this document. > > > > I think that will work; thanks. > > > >> > keying material in the handshake that AS specified in the rs_cnf > >> > parameter in the access token. Thus, the handshake only finishes if > >> > C and RS are able to use their respective keying material. > >> > > >> > I suggest being explicit about "the DTLS handshake with the client", > >> > perhaps as "MUST use in the DLTS handshake with the client the keying > >> > material that the AS specified in the rs_cnf parameter in the access > >> > token". > >> > >> Done, see next comment. > >> > >> > The same caveat about "parameter in the access token" > >> > applies here, though I guess there is an additional complication for > >> > "rs_cnf" in that it's an token response parameter but I don't remember > >> > that we say a huge amount about it also being included in the token > >> > itself -- the token response is directed to the client but the token is > >> > directed to the RS. > >> > >> As we have found, the mailing list discussion concluded that the access > >> token does not contain an rs_cnf claim at all. This occurrence most > >> likely was an artefact. This now has been changed as follows: > >> > >> OLD: > >> > >> RS MUST use the keying material in the handshake that AS specified > >> in the rs_cnf parameter in the access token. Thus, the handshake > >> only finishes if C and RS are able to use their respective keying > >> material. > >> > >> NEW: > >> > >> The resource server MUST use its own raw public key in the DTLS > >> handshake with the client. If the resource server has several raw > >> public keys, it must already know which key it is supposed to use > >> with this client. How this is achieved is not part of this profile. > >> > >> > Section 3.3 > >> > > >> > token. AS MUST check if the identifier refers to a symmetric key > >> > that was previously generated by AS as a shared secret for the > >> > communication between this client and the resource server. > >> > > >> > "What does the AS do if this check fails?" > >> > >> The following text has been added to avoid additional roundtrips for the > >> client: > >> > >> NEW: > >> > >> If no such symmetric key was found, the AS MUST generate a new > >> symmetric key that is returned in its response to the client. > > > > :) > > > >> > The authorization server MUST determine the authorization rules for > >> > the C it communicates with as defined by RO and generate the access > >> > > >> > nit: it's surprising to see "authorization server" spelled out in the > >> > same sentence as "C" and "RO" (which, incidentally, we don't seem to use > >> > in abbreviation form anywhere other than where we define it). > >> > >> There has been some discussion about the short forms. We will > >> harmonize this before submitting the next I-D version. > > > > Okay, thanks. > > > >> > wants to communicate with. Also, AS MUST protect the integrity of > >> > the access token. If the token contains confidential data such as > >> > the symmetric key, the confidentiality of the token MUST also be > >> > protected. Depending on the requested token type and algorithm in > >> > > >> > (same comment about "protect the integrity" or "protect" as for the RPK > >> > case.) > >> > >> Done, by adding: > >> > >> NEW: > >> > >> to ensure that the resource server can detect unauthorized changes. > >> > >> > that is to be used between C and the resource server. The access > >> > token MUST be bound to the same symmetric key by means of the cnf > >> > claim. > >> > > >> > Now we call it a "claim" rather than a "token parameter", but this again > >> > seems to be implicitly assuming CWT/JWT for tokens. > >> > >> We distinguish between the (semantic) information conveyed by an access > >> token of the syntactic description of data objects. To make this more > >> explicit, we now have added some text in the Terminology section that > >> refers to the same usage of the term 'claim' as in the framework > >> document. > > > > Thank you! > > > >> > (Also, this "MUST" seems like something that the framework should > >> > guarantee and not a new requirement that the DTLS profile imposes.) > >> > >> As this as been a bit misleading as well, it has been rephrased as > >> follows: > >> > >> OLD: > >> > >> The access token MUST be bound to the same symmetric key by means > >> of the cnf claim. > >> > >> NEW: > >> > >> To convey the same secret to the resource server, the > >> authorization server either includes it directly in the access > >> token by means of the `cnf` claim or it provides sufficient > >> information to enable the resource server to derive the key from > >> the access token using key derivation. > >> > >> > Figure 5: Example Access Token Request, symmetric PoP-key > >> > > >> > Maybe we could include "(implicit)" in the caption, since symmetric PoP > >> > key is the default. > >> > >> done > >> > >> > An example access token response is illustrated in Figure 6. In this > >> > > >> > Is it accurate to say "A corresponding example access token response"? > >> > It's nice to the reader if we can tie the examples together like that. > >> > >> done > >> > >> > Is the "Max-Age" usage in Figure 6 typical? (Also, similar comment > >> > about having the parenthetical comment in the example body vs. preface.) > >> > >> New text was added as follows to clarify that inconsistencies with > >> cached responses should be avoided. For a more realistic example, the > >> value of Max-Age in the examples has been decreased to be sufficiently > >> below expires_in: > >> > >> NEW: > >> > >> Caching proxies process the Max-Age option in the CoAP response > >> which has a default value of 60 seconds (Section 5.6.1 of > >> [RFC7252]). The authorization server SHOULD adjust the Max-Age > >> option such that it does not exceed the `expires_in` parameter to > >> avoid stale responses. > >> > >> > token_type : pop, > >> > > >> > Didn't we switch this to being capitalized as "PoP"? > >> > >> done > >> > >> > "COSE_Encrypt0" structure. The AS MUST use the keying material > >> > shared with the RS to encrypt the token. > >> > > >> > nit: I suggest s/shared with/it shares with/ > >> > >> done > >> > >> > We should probably say something about why the kid in Figure 7 is > >> > different from the one in Figure 6. > >> > >> As it seems more clear if both examples use the same kid, this now has > >> been harmonized. > >> > >> > 4.00 Bad Request > >> > Content-Format: application/ace+cbor > >> > Payload: > >> > { > >> > error : invalid_request > >> > } > >> > > >> > Figure 8: Example Access Token Response With Reject > >> > > >> > RFC 6749's description of "invalid_request" seems to imply that it's > >> > mostly about malformed requests, as opposed to the AS deciding that the > >> > client is not authorized for any access to the requested resource (which > >> > is maybe what's implied by the previous paragraph). This is not > >> > necessarily a problem, but perhaps we could make the text and example > >> > more consistent. > >> > >> This example is actually about malformed requests (4.00). We now have > >> added text to clarify this. > > > > Ah, looks good :) > > > >> > The method for how the resource server determines the symmetric key > >> > from an access token containing only a key identifier is application > >> > specific, the remainder of this section provides one example. > >> > > >> > nit: hyphenate "application-specific", and this is a comma splice. > >> > >> done > >> > >> > resource server. This key needs to be securely stored and processed > >> > in the same way as the key used to protect the communication between > >> > AS and RS. > >> > > >> > nit: is this better as "processed" or "protected"? > >> > >> "processed" because this part is about the handling not the > >> characteristics of the data. > >> > >> > The fields in the context information "COSE_KDF_Context" > >> > (Section 11.2 of [RFC8152]) have the following values: > >> > > >> > o AlgorithmID = "ACE-CoAP-DTLS-key-derivation" > >> > > >> > RFC 8152 says that these AlgorithmID values come from the COSE > >> > Algorithms registry, which this does not (unless we register it there, > >> > which we don't currently). Also, since the output is used directly for > >> > DTLS PSK, I don't think the "key-derivation" portion is needed. > >> > > >> > o PartyUInfo = PartyVInfo = ( null, null, null ) > >> > > >> > (8152 seems to prefer "nil" over "null".) > >> > > >> > o keyDataLength needs to be defined by the application > >> > > >> > o protected MUST be a zero length bstr > >> > > >> > o other is a zero length bstr > >> > > >> > (These three are all members of the "SuppPubInfo" field, which is not > >> > very clear from how we include them in the same list as top-level > >> > fields.) > >> > >> The example now has updated and rephrased according to HKDF usage. > > > > The formatting/discussion looks good, but I'll need to cross-check the data > > structures once the new revision is uploaded. I do like the presentation with HKDF and the structured input to it. However, I think we may have over-corrected w.r.t. key-id uniqueness: In order to generate a new symmetric key to be used by client and resource server, the authorization server generates a new key identifier which MUST be unique among all key identifiers used by the authorization server. The authorization server then uses the key I think this requirement for uniqueness global to the AS may be too strong; couldn't key identifiers be reused for different RSes? Having the kid be part of the input to HKDF keyed by a unique AS/RS shared key also helps a great deal to avoid accidental key collisions. To ensure uniqueness of the derived shared secret, the authorization server SHOULD generate a sufficiently random kid value and include the claims "iat" and either "exp" or "exi" in the access token. I don't think I understand the motivation for all these statements (and in fact that they may not be entirely correct). It is permitted to use the 'info' parameter to HKDF for domain separation, so even having the unique kid mentioned above is enough to ensure a unique derived shared secret (and this holds even if the kid uniqueness requirement is weakendt to be per-RS and not per-AS). Including "iat", "exp", and/or "exi" also helps to ensure uniqueness and should be recommended, but the interrelationships are not stated well here. Perhaps: % Use of a unique (per RS) "kid" and the use of a unique per-AS/RS key % derivation IKM as specified above will ensure that the derived key is % not shared across multiple clients. However, to additionally provide % variation in the derived key across different tokens used by the same % client, it is additionally RECOMMENDED to include the "iat" claim and % either the "exp" or "exi" claims in the access token. > >> > Section 3.3.1 > >> > > >> > When a client receives an access token response from an authorization > >> > server, C MUST ascertain that the access token response belongs to a > >> > certain previously sent access token request, as the request may > >> > specify the resource server with which C wants to communicate. > >> > > >> > (Same bit about "belongs to".) > >> > >> done > >> > >> > If a resource server receives a ClientKeyExchange message that > >> > contains a "psk_identity" with a length greater zero, it uses the > >> > contents as index for its key store (i.e., treat the contents as key > >> > > >> > (This is not DTLS 1.3-compatible.) > >> > >> See side discussion on DTLS versions. > >> > >> > nits: "greater than", "as an index", "as a key identifier" > >> > >> done > >> > >> > identifier). The resource server MUST check if it has one or more > >> > access tokens that are associated with the specified key. > >> > > >> > I don't understand this sentence -- isn't the access token the precise > >> > contents of the "psk_identity" field, so that there would be a key > >> > associated with the access token, not the other way around? > >> > >> Now clarified that the psk_identity must contain the opaque access > >> token: > >> > >> OLD: > >> > >> Alternatively, the client MAY provide the most recent access > >> token in the `psk_identity` field of the ClientKeyExchange > >> message. To do so, the client MUST treat the contents of the > >> `access_token` field from the AS-to-Client response as opaque data > >> and not perform any re-coding. > >> > >> Note: > >> As stated in Section 4.2 of [RFC7925], the PSK identity should be > >> treated as binary data in the Internet of Things space and not > >> assumed to have a human-readable form of any sort. > >> > >> NEW: > >> > >> As an alternative to the access token upload, the client can > >> provide the most recent access token in the `psk_identity` field of > >> the ClientKeyExchange message. To do so, the client MUST treat the > >> contents of the `access_token` field from the AS-to-Client response > >> as opaque data as specified in Section 4.2 of [RFC7925] and not > >> perform any re-coding. This allows the resource server to retrieve > >> the shared secret directly from the `cnf` claim of the access > >> token. > >> > >> > If no key with a matching identifier is found, the resource server > >> > MAY process the contents of the "psk_identity" field as access token > >> > > >> > Similarly here, the causality feels reversed. > >> > >> Hopefully, this has been sufficiently clarified by the previous > >> comment. Moreover, the following change is proposed to emphasize the > >> aforementioned behavior of RS. The access token now must always be > >> parsed but may contain a kid for an already known key: > > > > I think I confused myself with the previous diff, but your description here > > and the text in the editor's copy seem to make sense, so I'm willing to say > > that I got confused earlier and move on. > > > >> OLD: > >> > >> If a resource server receives a ClientKeyExchange message that > >> contains a `psk_identity` with a length greater than zero, it uses > >> the contents as an index for its key store[...] > >> > >> [...] session setup is terminated with an `illegal_parameter` DTLS > >> alert message. > >> > >> NEW: > >> > >> If a resource server receives a ClientKeyExchange message that > >> contains a `psk_identity` with a length greater than zero, it MUST > >> process the contents of the `psk_identity` field as access token > >> that is stored with the authorization information endpoint, before > >> continuing the DTLS handshake. If the contents of the > >> `psk_identity` do not yield a valid access token for the requesting > >> client, the resource server aborts the DTLS handshake with an > >> `illegal_parameter` alert. > >> > >> > continuing the DTLS handshake. If the contents of the "psk_identity" > >> > do not yield a valid access token for the requesting client, the DTLS > >> > session setup is terminated with an "illegal_parameter" DTLS alert > >> > message. > >> > > >> > I think "the RS aborts the DTLS handshake with an 'illegal_parameter' alert" > >> > would be more conventional phrasing. > >> > >> done > >> > >> > Note2: According to [RFC7252], CoAP implementations MUST support the > >> > ciphersuite TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]. A client is > >> > therefore expected to offer at least this ciphersuite to the > >> > resource server. > >> > > >> > Do we want to say anything about the (EC)DHE variants? Short-lived access > >> > tokens with the AS generating new symmetric keys can provide similar > >> > forward-secrecy properties to using DHE, but there is in general a trend > >> > in the IETF towards defaulting to providing forward secrecy in key > >> > exchanges. > >> > >> Yes, this makes a lot of sense. We have added the following text to > >> the Security Considerations to give advice: > >> > >> NEW: > >> > >> The PSK mode of this profile offers a distribution mechanism to > >> convey authorization tokens together with a shared secret to a > >> client and a server. As this specification aims at constrained > >> devices and uses CoAP [RFC7252] as transfer protocol, at least the > >> ciphersuite TLS\_PSK\_WITH\_AES\_128\_CCM\_8 {{RFC6655}} should be > >> supported. The access tokens and the corresponding shared secrets > >> generated by the authorization server are expected to be > >> sufficiently short-lived to provide similar forward-secrecy > >> properties to using ephemeral Diffie-Hellman (DHE) key exchange > >> mechanisms. For longer-lived access tokens, DHE ciphersuites should > >> be used. > > > > Nicely said! > > > >> > When RS receives an access token, RS MUST check if the access token > >> > is still valid, if RS is the intended destination, i.e., the audience > >> > of the token, and if the token was issued by an authorized AS. This > >> > > >> > As above, "i.e., the audience of the token" would probably be better > >> > when offset in parentheses than by commas. > >> > >> done > >> > >> > While the client can retrieve the shared secret from the contents of > >> > the "cnf" parameter in the AS-to-Client response, the resource server > >> > uses the information contained in the "cnf" claim of the access token > >> > to determine the actual secret when no explicit "kid" was provided in > >> > the "psk_identity" field. If key derivation is used, the RS uses the > >> > "COSE_KDF_Context" information as described above. > >> > > >> > "psk_identity" is a field in ClientKeyExchange, and we say that its > >> > contents are the raw access token for our usage. It does not have a > >> > direct COSE structure for this talk of "kid" to make much sense without > >> > further explanation. > >> > >> Yes, this is misleading. We propose the following to clarify the > >> processing of access tokens (independent whether this has been uploaded > >> or carried in the psk_identity) on the RS: > >> > >> OLD: > >> > >> While the client can retrieve the shared secret from the contents > >> of the `cnf` parameter in the AS-to-Client response, the resource > >> server uses the information contained in the `cnf` claim of the > >> access token to determine the actual secret when no explicit `kid` > >> was provided in the `psk_identity` field. If key derivation is > >> used, the RS uses the `COSE_KDF_Context` information as described > >> above. > >> > >> NEW: > >> > >> While the client can retrieve the shared secret from the contents > >> of the `cnf` parameter in the AS-to-Client response, the resource > >> server uses the information contained in the `cnf` claim of the > >> access token to determine the actual secret. To retrieve the `cnf` > >> claim and determine the shared secret for the session between the > >> client and the resource server, the resource server first has to > >> decrypt the access token if it is enclosed in a `COSE_Encrypt0` > >> structure and then parse the access token. The parsed access > >> token then is associated with the `kid` for the contained shared > >> secret, if any. If key derivation is used, the resource server > >> calculates the shared secret from the `COSE_KDF_Context` > >> information as described above. > >> > >> > Section 3.4 > >> > > >> > We may get some requests for a more explicit definition of what the > >> > "authorization information" tied to a client is. > >> > > >> > Once a DTLS channel has been established as described in Section 3.2 > >> > and Section 3.3, respectively, the client is authorized to access > >> > > >> > nit: I think "or" is more appropriate to join the sections listed, as > >> > only one is applicable to a given connection. > >> > >> done > >> > >> > With the successful establishment of the DTLS channel, C and RS have > >> > proven that they can use their respective keying material. An access > >> > token that is bound to the client's keying material is associated > >> > with the channel. Any request that the resource server receives on > >> > this channel MUST be checked against these authorization rules. RS > >> > > >> > nit: I'd s/these/the following/ > >> > >> done > >> > >> > MUST check for every request if the access token is still valid. > >> > Incoming CoAP requests that are not authorized with respect to any > >> > access token that is associated with the client MUST be rejected by > >> > the resource server with 4.01 response as described in Section 5.1.1 > >> > of [I-D.ietf-ace-oauth-authz]. > >> > > >> > "any access token" implies there might be more than one, though I seem > >> > to recall discussion of updated tokens overwriting any previous one, so > >> > that only one token per client is active at any given time. What did we > >> > end up settling on? > >> > >> done > >> > >> OLD: > >> > >> Any request that the resource server receives on this channel MUST > >> be checked against these authorization rules. RS MUST check for > >> every request if the access token is still valid. Incoming CoAP > >> requests that are not authorized with respect to any access token > >> that is associated with the client MUST be rejected by the resource > >> server with 4.01 response as described in Section 5.1.1 of > >> [I-D.ietf-ace-oauth-authz]. > >> > >> NEW: > >> > >> According to section 5.8.1 of [I-D.ietf-ace-oauth-authz], there > >> should be only one access token for each client. New access tokens > >> issued by the authorization server are supposed to replace > >> previously issued access tokens for the respective client. The > >> resource server therefore must have a common understanding with > >> the authorization server how access tokens are ordered. > >> > >> Any request that the resource server receives on a DTLS channel > >> that is tied to an access token via its keying material MUST be > >> checked against the authorization rules that can be determined > >> with the access token. The resource server MUST check for every > >> request if the access token is still valid. Incoming CoAP requests > >> that are not authorized with respect to any access token that is > >> associated with the client MUST be rejected by the resource server > >> with 4.01 response. The response MAY include AS Request Creation > >> Hints as described in Section 5.1.1 of [I-D.ietf-ace-oauth-authz]. > > > > I think this is good; it repeats the hints from the core framework that > > getting things right with multiple active tokens is hard, but doesn't > > strictly forbid it. > > > >> > Also, the referenced framework Section 5.1.1 does not actually mandate > >> > the 4.01 response code. > >> > >> Fixed in the proposed text for the previous comment: We now require the > >> 4.01 and do not imply that this is required by section 5.1.1 of the > >> framework document which is silent on the proper response codes. > >> > >> > The resource server SHOULD treat an incoming CoAP request as > >> > authorized if the following holds: > >> > > >> > We could say more about this "SHOULD" (or change the way we discuss it) > >> > -- is it the minimum baseline of checks and additional checks may be > >> > applied, or do some of them not apply in some cases, or ...? > >> > >> These are the minimum checks that the RS needs to do. The following > >> proposal should make this clearer: > >> > >> OLD: > >> > >> The resource server SHOULD treat an incoming CoAP request as > >> authorized if the following holds: > >> > >> NEW: > >> > >> The resource server MUST only accept an incoming CoAP request as > >> authorized if the following holds: > > > > That's good. I didn't think very hard about whether adding a brief note > > after the list along the lines of "additional checks may be applied > > according to local policy" would add value; it may well go without saying. > > > >> > Incoming CoAP requests received on a secure DTLS channel that are not > >> > thus authorized MUST be rejected according to Section 5.8.2 of > >> > [I-D.ietf-ace-oauth-authz] > >> > > >> > We may also get some questions asking about what the difference is > >> > between the "not authorized with respect to any access token" in the > >> > previous quoted snippet" and "not thus authorized" in this quoted > >> > snippet. > >> > >> We hope that the previous change should have fixed this as well. > > > > That seems likely :) > > > >> > The client cannot always know a priori if an Authorized Resource > >> > Request will succeed. It MUST check the validity of its keying > >> > material before sending a request or processing a response. If the > >> > > >> > What does "check the validity of its keying material" mean? > >> > >> The following change should make this more clear as the only thing that > >> the client can do is to check if the keying material is still valid: > >> > >> OLD: > >> > >> The client cannot always know a priori if an Authorized Resource > >> Request will succeed. It MUST check the validity of its keying > >> material before sending a request or processing a response. > >> > >> NEW: > >> > >> The client MUST ascertain that its keying material is still valid > >> before sending a request or processing a response. > >> > >> > >> > client repeatedly gets error responses containing AS Creation Hints > >> > (cf. Section 5.1.2 of [I-D.ietf-ace-oauth-authz] as response to its > >> > requests, it SHOULD request a new access token from the authorization > >> > server in order to continue communication with the resource server. > >> > > >> > Why should this only be done in the case of *repeatedly* getting such > >> > error responses; I thought the idea of the AS Request Creation Hints was > >> > to take immediate effect. > >> > >> Correct. The intention was to deal with the race condition for the > >> upload mechanism. But as this affects different communication channels, > >> it is safe to just remove the word "repeatedly": > >> > >> OLD: > >> > >> client repeatedly gets error responses containing AS Creation Hints > >> > >> NEW: > >> > >> client gets an error response containing AS Request Creation Hints > >> > >> > (Also, nit: s/AS Creation Hints/AS Request Creation Hints/.) > >> > >> done > >> > >> > Section 4 > >> > > >> > The client can update the authorization information stored at the > >> > resource server at any time without changing an established DTLS > >> > session. To do so, the Client requests a new access token from the > >> > authorization server for the intended action on the respective > >> > resource and uploads this access token to the authz-info resource on > >> > the resource server. > >> > > >> > I suggest adding another sentence similar to "Because ACE tokens are > >> > proof-of-possession tokens, the updated authorization information only > >> > takes immediate effect if such proof has already been provided, e.g., if > >> > the PoP key associated with the new token is the same as the one > >> > currently in use." This is further detailed in the following > >> > paragraphs, but not stated concretely as a key principle. > >> > >> The term "ACE tokens" may be a bit misleading. In this profile, we > >> always use PoP tokens. Our proposal is to move the note from the end > >> upwards: > >> > >> OLD: > >> > >> The client can update... > >> > >> NEW: > >> > >> Resource servers must only use a new access token to update the > >> authorization information for a DTLS session if the keying > >> material that is bound to the token is the same that was used in > >> the DTLS handshake. By associating the access tokens with the > >> identifier of an existing DTLS session, the authorization > >> information can be updated without changing the cryptographic keys > >> for the DTLS communication between the client and the resource > >> server, i.e. an existing session can be used with updated > >> permissions. > > > > This looks like it will work; I can handle the lack of my preferred > > phrasing about the "proof has already been provided" :) > > > >> The client can therefore update... > >> > >> > Section 5 > >> > > >> > DTLS sessions that have been established in accordance with this > >> > profile are always tied to a specific access token. As this token > >> > > >> > Doesn't the dynamic authorization update mechanism allow that token to > >> > be swapped out during the lifetime of the connection? > >> > Also, as a terminology point, I think "DTLS association" is more > >> > appropriate than "DTLS session" for what we describe, since the token is > >> > is tied to the client and consulted at the start of the handshake, as > >> > opposed to being a property of the DTLS session and carried across > >> > resumptions. > >> > >> We propose the following text as a clarification. This also takes > >> into account the "session" vs. "association" part which looks a bit > >> weird. If we come to the conclusion that this is a better term, we > >> would have to revise the rest of the document accordingly: > >> > >> OLD: > >> > >> DTLS sessions that have been established in accordance with this > >> profile are always tied to a specific access token. As this token > >> may become invalid at any time (e.g. because it has expired), the > >> session may become useless at some point. A resource server > >> therefore MUST terminate existing DTLS sessions after the access > >> token for this session has been deleted. > >> > >> NEW: > >> > >> The resource server MUST delete access tokens that are no longer > >> valid. DTLS associations that have been setup in accordance with > >> this profile are always tied to specific tokens (which may be > >> exchanged with a dynamic update as described in Section 4). As > >> tokens may become invalid at any time (e.g. because they have > >> expired), the association may become useless at some point. A > >> resource server therefore MUST terminate existing DTLS association > >> after the last access token associated with this association has > >> expired. > > > > This looks good (modulo the nit: comma after "e.g."). > > Fixed, thanks! > > >> > may become invalid at any time (e.g. because it has expired), the > >> > session may become useless at some point. A resource server > >> > therefore MUST terminate existing DTLS sessions after the access > >> > token for this session has been deleted. > >> > > >> > I assume that using "been deleted" vs. "has expired" is a deliberate > >> > choice? If we don't say anything else about when to delete tokens, it > >> > doesn't post much of a requirement, though. > >> > >> Good point. This is missing in Section 3.4. We now have added an > >> explicit requirement to remove expired (or otherwise invalid) access > >> tokens: > >> > >> OLD: > >> > >> The resource server MUST check for every request if the access > >> token is still valid. > >> > >> NEW: > >> > >> The resource server MUST check for every request if the access > >> token is still valid. If the token has expired, the resource > >> server MUST remove it. > > > > Ah, thanks. > > > >> > Section 6 > >> > > >> > endpoint. The use of CoAP and DTLS for this communication is > >> > RECOMMENDED in this profile, other protocols (such as HTTP and TLS or > >> > CoAP and OSCORE) MAY be used instead. > >> > > >> > nit: comma splice > >> > >> done > >> > >> > Also, we could potentially refer to the OSCORE profile document here > >> > (informatively). > >> > >> done > >> > >> > If other means of securing the communication with the AS are used, > >> > the security protocol MUST fulfill the communication security > >> > requirements in Section 6.2 of [I-D.ietf-ace-oauth-authz]. > >> > > >> > I suggest phrasing more like "the communication security requirements > >> > from Section 6.2 of [I-D.ietf-ace-oauth-authz] remain applicable", since > >> > there's no need to add another MUST to the ones already in the framework > >> > document. > >> > >> Done, although "remain applicable" seems a bit weak. > >> > >> > Section 7 > >> > > >> > I have a few suggestions for potential additions to this section as well > >> > as comments on the existing contents. > >> > > >> > We might consider adding a brief note about the use of 8-byte > >> > authentication tags in DTLS ciphers and how that affects the risk > >> > profile. > >> > >> Done. New text has been added as follows. > >> > >> NEW: > >> > >> As this specification targets at constrained environments, message > >> payloads exchanged between the client and the resource server are > >> expected to be small and rare. CoAP {{RFC7252}} mandates the > >> implementation of cipher suites with abbreviated, 8-byte tags for > >> message integrity protection. For consistency, this profile requires > >> implementation of the same cipher suites. For application scenarios > >> where the cost of full-width authentication tags is low compared to > >> the overall amount of data being transmitted, the use of cipher > >> suites with 16-byte integrity protection tags is preferred. > >> > >> > The use of "live" authorization upgrades on an existing DTLS connection > >> > by posting a new token to the authz-info endpoint does not provide much > >> > guarantee about the order in which operations occur (and thus which > >> > authorization info is used to process a given client request), > >> > especially in the face of an attacker that can delay and reorder > >> > packets. This does not necessarily mean that we should not bother to > >> > define that mechanism, but we should point out that there is only a weak > >> > ordering property provided, note that other mechanisms should be used > >> > when strict serialization is important, and caution that when the > >> > later-issued token contains a reduction in authorization from the > >> > initial token, it is impossible to guarantee that the reduction in > >> > authorization will take effect prior to the expiration of the original > >> > token. > >> > >> Exactly! To address this, the following text has been added to the > >> Security Considerations: > >> > >> NEW: > >> > >> Even when a single access token per client is used, an attacker > >> could compromise the dynamic update mechanism for existing DTLS > >> connections by delaying or reordering packets destined for the > >> authz-info endpoint. Thus, the order in which operations occur at > >> the resource server (and thus which authorization info is used to > >> process a given client request) cannot be guaranteed. Especially > >> in the presence of later-issued access tokens that reduce the > >> client's permissions from the initial access token, it is > >> impossible to guarantee that the reduction in authorization will > >> take effect prior to the expiration of the original token. > >> > >> > We rely heavily on the AS to accurately provide binding of raw key > >> > material to authorization information and endpoint identinty; I think > >> > this is a stronger reliance than just that implied by the core > >> > architecture, and so might merit a mention here. (This relates to all > >> > the checks about "MUST check that [client/...] is associated with > >> > [RPK/PSK]" that appear throughout the document.) > >> > >> We are not sure if this is specific to this profile. For any profile > >> within the ACE framework, the AS must know C and RS and must know their > >> keys. In this profile, we just describe what the AS needs to do to > >> address these requirements. > > > > Okay. > > > >> > I'd also suggest reiterating all the places where we rely on out-of-band > >> > configuration, as there's always a risk of such configuration becoming > >> > stale (or getting attacked directly). > >> > >> Most parts of the document already now do this. We have added an > >> additional remark in Section 3.1 to ensure that the client checks that > >> the authorization information about the AS is still valid. > >> We have also added a new subsection to the Security Considerations that > >> describes the configuration and authorization information that must > >> be provided to the authorization server, the resource server, and the > >> client outside of the ACE DTLS profile. > >> > >> NEW: > >> > >> 7.1 Out-of-Band Configuration > >> > >> To communicate securely, the authorization server, the client and > >> the resource server require certain information that must be > >> exchanged outside the protocol flow described in this > >> document. The authorization server must have obtained > >> authorization information concerning the client and the resource > >> server that is approved by the resource owner as well as > >> corresponding keying material. The resource server must have > >> received authorization information approved by the resource owner > >> concerning its authorization managers and the respective keying > > > > (Do we use the phrase "authorization manager" elsewhere?) > > > >> material. The client must have obtained authorization information > >> concerning the authorization server approved by its owner as well > >> as the corresponding keying material. Also, the client's owner > >> must have approved of the client's communication with the resource > >> server. The client and the authorization server must have obtained > >> a common understanding how this resource server is identified to > >> ensure that the client obtains access token and keying material > >> for the correct resource server. If the client is provided with a > >> raw public key for the resource server, it must be ascertained to > >> which resource server (which identifier and authorization > >> information) the key is associated. All authorization information > >> and keying material must be kept up to date. > >> > >> > I'd consider reiterating that when the KDF scheme is in use between RS > >> > and AS, that kid uniqueness is paramount, as using the same kid for > >> > multiple clients and the same RS would have potentially disasterous > >> > consequences in that case. > >> > >> Not sure if this is specific to the key generation through KDF, as the > >> kid is typically used to find the access token that was uploaded to the > >> auth-info endpoint? > > > > I think it is specific to key generation through KDF, but let me try to > > walk through it. > > > > Up in Section 3.3 we talk about a case where the AS and RS are assumed to > > share a key derivation key that's used to derive symmetric keys for the RS > > to share with the client. The KDF input is the IKM and the 'info' (since > > 'salt' is empty), and the IKM is just that same "key derivation key". So > > the only input to HKDF that changes for different clients (and the same RS) > > is the 'info'. The 'info', in turn contains a string constant 'type' plus > > the 'kid' and (presumably fixed) output length. If I'm reading this > > correctly, the 'kid' is the only HKDF input that varies between clients, so > > if the 'kid' was reused for different clients, the AS and RS would derive > > the same symmetric key for those distinct client/RS pairs. Furthermore, > > since the AS returns the actual symmetric key to the client in the token > > response, that means that the symmetric key is shared by *three* parties > > (vs. just client and RS, ignoring in the count the AS which knows > > everything). I guess technically this is not the scenario forbidden by the > > core framework (which is to have the same symmetric key used at multiple > > RSes, but it still is bad hygeine and would let one client impersonate the > > other. > > > > In cases not using the KDF, the 'kid' is just a hint to finding the actual > > key, and the actual key is assumed to be constructed uniquely by the AS > > each time. > > Thank you, this is absolutely true. I have now changed the input for the > key derivation mechanism in the sense of what originally has been > specified in draft-gerdes-ace-dcaf-authorize, i.e., including the access > token as input to the KDF. This enables the authorization server to > include a certain amount of unifying attributes in the info parameter, > esp. with a randomly generated kid and the iat claim. I would have loved > to have a claim type for carrying a nonce in the access token… Hmm, we say that "access_token is the decrypted access_token as transferred from the AS to the RS", but it's supposed to be a CBOR map; is this intended to just be the claims set from the CWT? If so, we should say that. > >> > Similarly (though this is inherent to symmetric PoP and may not actually > >> > need reiterating), when we use symmetric PSKs for PoP, they lose almost > >> > all value if any given PSK is known to more than one client or RS. (The > >> > secdir review on the framework has us putting in MUST-level requirements > >> > to not share further than that, so it seems pretty reasonable to not > >> > duplicate that warning here.) > >> > >> Okay. This was one of things that we deemed obvious… > >> > >> > This document specifies a profile for the Authentication and > >> > Authorization for Constrained Environments (ACE) framework > >> > [I-D.ietf-ace-oauth-authz]. As it follows this framework's general > >> > approach, the general security considerations from section 6 also > >> > apply to this profile. > >> > > >> > (The HTMLized link will only do the right thing if you use the redundant > >> > "section 6 of [I-D.ietf-ace-oauth-authz]".) > >> > >> done > > > > Though I guess we're on v3 XML now (yay! very pretty!), which hopefully > > does not have the same artificial limitations. > > > >> > The use of multiple access tokens for a single client increases the > >> > strain on the resource server as it must consider every access token > >> > and calculate the actual permissions of the client. Also, tokens may > >> > contradict each other which may lead the server to enforce wrong > >> > permissions. If one of the access tokens expires earlier than > >> > others, the resulting permissions may offer insufficient protection. > >> > Developers SHOULD avoid using multiple access tokens for a client. > >> > > >> > I think I touched on this above; did we want to make a stronger > >> > statement about "only one active token per client"? > >> > >> At the time this was written, the framework document was pretty unclear > >> about this. Now, it would be possible to have multiple access tokens for > >> a client if you knew how to merge the authorization rules. We have > >> changed the update mechanism to clearly state that a new token replaces > >> the old one. The question is if we still need this paragraph. > > > > I think the discussion is still valid and the only thing I'm not sure about > > is whether the last sentence is needed. > > As there is no guidance so far on how permission sets in access tokens > are to be combined properly it seems to be wise at least to advise > against. I agree that's the right advice to give; what is less clear to me is whether this document needs to be the place to give that advice (vs. the framework doing so). But I don't have a strong stance on this at the moment, and am happy to move forward with the text as-is if you want. > >> > Section 8 > >> > > >> > information as possible in an unencrypted response. When a DTLS > >> > session between the client and the resource server already exists, > >> > more detailed information MAY be included with an error response to > >> > provide the client with sufficient information to react on that > >> > particular error. > >> > > >> > I'd suggest adding a caveat like "an authenticated client" or > >> > "a known client", since DTLS itself does not guarantee that the client > >> > is not an attacker. > >> > >> done > >> > >> > Section 9 > >> > > >> > Profile ID: 1 > >> > > >> > I think this has to be merely a "suggested value", as IANA will control > >> > the actual allocations, in the absence of a reservation of this value in > >> > the framework document. > >> > >> done > >> > >> > Section 10.1 > >> > > >> > We don't currently reference RFC 7925 in any way that would require it > >> > to be a normative reference. We probably should, though -- somehow pull > >> > in that we require/recommend conformance with that profile of DTLS. > >> > >> We are not sure if there is anything special about RFC 7925 that we > >> explicitly want to point out. However, as we have the requirement of > >> treating the access token in the psk_identity as opaque binary data, we > >> have moved the reference RFC 7925 into the normative section. > > > > Okay, thanks. > > > >> > Section 10.2 > >> > > >> > I think RFCs 7250, 7251, and 8422 need to be normative. > >> > >> done > > Actually, I had to revert this for the informational RFC 7251 as the > idnits tool did not allow the downref from normative. idnits is just a tool to raise potential issues that a human can look at and think about; in this case, idnits is wrong: 7251 is listed at https://datatracker.ietf.org/doc/downref/ and is perfectly fine to use as a normative reference. Thanks for the updates, Ben From nobody Thu May 28 13:41:54 2020 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF33E3A0D75; Thu, 28 May 2020 13:41:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <159069851291.7031.7009323921343905594@ietfa.amsl.com> Date: Thu, 28 May 2020 13:41:52 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-mqtt-tls-profile-05.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 20:41:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : MQTT-TLS profile of ACE Authors : Cigdem Sengul Anthony Kirby Paul Fremantle Filename : draft-ietf-ace-mqtt-tls-profile-05.txt Pages : 29 Date : 2020-05-28 Abstract: This document specifies a profile for the ACE (Authentication and Authorization for Constrained Environments) framework to enable authorization in an MQTT-based publish-subscribe messaging system. Proof-of-possession keys, bound to OAuth2.0 access tokens, are used to authenticate and authorize MQTT Clients. The protocol relies on TLS for confidentiality and MQTT server (broker) authentication. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-mqtt-tls-profile-05 https://datatracker.ietf.org/doc/html/draft-ietf-ace-mqtt-tls-profile-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-mqtt-tls-profile-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 28 14:00:57 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E57B73A0EE5 for ; Thu, 28 May 2020 14:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJ-L5f99sUBf for ; Thu, 28 May 2020 14:00:47 -0700 (PDT) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (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 5C3633A0EB2 for ; Thu, 28 May 2020 14:00:46 -0700 (PDT) Received: by mail-vs1-xe31.google.com with SMTP id l15so251452vsr.3 for ; Thu, 28 May 2020 14:00:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=LtFm1o03okkoSCan2aJLsf0d9QfO6qdkjAqbFPAiKCg=; b=k61yXw2VmNxlJkVhmtaiWp5gljvdEjt+q6ropRq6wcmZfeHJRmvEk4wQ3UD70dT3I5 xtyFunLOcBlZOepBn4REKNVc9rnBPmSujw0LJ/3pkHd0J4nj2Cc0Tt9Yap8bicQys1Fr Cx43swhzrZZggEK9kmvPjo3KWqvIz7l9PWM3olPh2HtDcM/fLNqg+agk4fClP48kvZV0 eFv2ThjQeMWCrC6HTt772jZRjlloJ4NYFSt476EiRBFzOw5XcxOVd8K0Ju0MOYS8DlSp wiPqy3NDs7nQn3Kxp5LgaUlrBJROtX3eT+mXTFvuBsYdntoYWvSav24VNJ9xxqooKM0s xu+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=LtFm1o03okkoSCan2aJLsf0d9QfO6qdkjAqbFPAiKCg=; b=tmA9vBqBSEngph8sBxmm0WQNYkXyUnUG/AZOsrfrGI6Ik/8eNfNy9ZwHEK8YawFFZC TvCCBtWLRU0O+2R0mb+77MyAf+hngDnMQhEbegSfTKiiFCDjnp+CA4miVSnCxYpUWt1r gurS7GfiKu843Dj4ISqUNyO/xh1qEiGysBmdZgqMNQ1O/ywLMtBUqGOeGedPWYY/k+sC a03ZepMPtl4iGRPd97uAJ0vX6gk0eP2XN8YAAXcFfq77q6UPxVUlF6gcakOKjiHhKU/O QsEvTv5NPBDVOSz39Rb4jaxy1m9eR+U++bG3iijh1ITCgbrB3tt59WXbRMLlmop7lT31 DhhA== X-Gm-Message-State: AOAM533nogkHhXfR5MD5MhSTL3JxR5nceetNbHtxN6Mi0nb4NA4TRE63 QhlzfmK8DMz1JQNGxeapFfGgDR4lXZXpJDfd8hvpwAtb2QY= X-Google-Smtp-Source: ABdhPJxQciQ3nfb2eRvws6EIKAFKcK6TIwcfFezcNZCDjjijjMeWYRtbTT+n+HsftldyqWHtzhWpDE1VBs3haOCbeCs= X-Received: by 2002:a67:fa50:: with SMTP id j16mr930067vsq.144.1590699643621; Thu, 28 May 2020 14:00:43 -0700 (PDT) MIME-Version: 1.0 References: <159069851291.7031.7009323921343905594@ietfa.amsl.com> In-Reply-To: <159069851291.7031.7009323921343905594@ietfa.amsl.com> From: Cigdem Sengul Date: Thu, 28 May 2020 22:00:33 +0100 Message-ID: To: Ace Wg Content-Type: multipart/alternative; boundary="00000000000033d48105a6bb9f76" Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-mqtt-tls-profile-05.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 28 May 2020 21:00:56 -0000 --00000000000033d48105a6bb9f76 Content-Type: text/plain; charset="UTF-8" Dear Ace, I've submitted a v5 of the MQTT profile making the following updates as discussed in the April interim (the changes should be able to close all the remaining 6 issues in the github repo). After Jim and Carsten's e-mails, I've been thinking also how to add support for AIF in the draft. List of changes: * Clarified that MQTT v5.0 Brokers may implement username/password option for transporting the ACE token only for MQTT v.3.1.1 clients. This option is not recommended for MQTT v.5.0 clients. * Changed Clean Session requirement both for MQTT v.5.0 and v.3.1.1. The Broker SHOULD NOT, instead of MUST NOT, continue sessions. Clarified expected behaviour if session continuation is supported. Added to the Security Considerations the potential misuse of session continuation. * Added that client re-authentication is accepted only for the challenge/response PoP. * Also important for misuse of re-authentication messages, clarified that the Broker should not accept any other packets from Client after CONNECT and before sending CONNACK. Other including some minor changes: * Added Ed25519 as mandatory to implement * Fixed the Authentication Data to include token length for the Challenge/Response PoP. * Added that Authorisation Server Discovery is triggered if a token is invalid and not only missing. * Did some reorganisation in Section 2 so that "Unauthorised Request: Authorisation Server Discovery" is presented under Section 2.6 as part of the broker's response to the client. *Fixed Figure 2 to remove the "empty" word from the CONNECT format. Thanks, --Cigdem On Thu, May 28, 2020 at 9:42 PM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Authentication and Authorization for > Constrained Environments WG of the IETF. > > Title : MQTT-TLS profile of ACE > Authors : Cigdem Sengul > Anthony Kirby > Paul Fremantle > Filename : draft-ietf-ace-mqtt-tls-profile-05.txt > Pages : 29 > Date : 2020-05-28 > > Abstract: > This document specifies a profile for the ACE (Authentication and > Authorization for Constrained Environments) framework to enable > authorization in an MQTT-based publish-subscribe messaging system. > Proof-of-possession keys, bound to OAuth2.0 access tokens, are used > to authenticate and authorize MQTT Clients. The protocol relies on > TLS for confidentiality and MQTT server (broker) authentication. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ace-mqtt-tls-profile-05 > https://datatracker.ietf.org/doc/html/draft-ietf-ace-mqtt-tls-profile-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-mqtt-tls-profile-05 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --00000000000033d48105a6bb9f76 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Ace,=C2=A0

I've submitted a v5= of the MQTT profile making the following updates as discussed in the April= interim (the changes should be able to close all the remaining 6 issues in= the github repo). After Jim and Carsten's e-mails, I've been think= ing also how to add support=C2=A0for AIF in the draft.=C2=A0

=
List of changes:
* Clarified that MQTT v5.0 Brokers ma= y implement username/password option for transporting the ACE token only fo= r MQTT v.3.1.1 clients. This option is not recommended for MQTT v.5.0 clien= ts.=C2=A0=C2=A0
* Changed Clean Session requirement both for MQTT= v.5.0 and v.3.1.1. The Broker SHOULD NOT, instead of MUST NOT, continue se= ssions.=C2=A0
=C2=A0 =C2=A0Clarified expected behaviour if session con= tinuation is supported. Added to the Security Considerations the potential = misuse of session continuation.=C2=A0=C2=A0
*=C2=A0=20 Added that client re-authentication is accepted only for the challenge/resp= onse PoP. =C2=A0=C2=A0
=C2=A0* Also important for misuse of re-authenticati= on messages, clarified that the Broker should not accept any other packets = from Client after CONNECT and before sending CONNACK.=C2=A0=C2=A0
<= br>
Other including some minor changes:
* Added Ed25519 as mandatory to implement
*=C2=A0 Fixed the Authentication Data to include token length for the Challenge/Res= ponse PoP.
*=C2=A0 Added that Authorisation Server Discovery is triggered if a token is invali= d and not only missing. =C2=A0=C2=A0
* Did some reorganisation in Section 2 so that &quo= t;Unauthorised Request: Authorisation Server Discovery" =C2=A0is prese= nted under Section 2.6 as part of the broker's response to the client.<= br>=C2=A0 *Fixed Figure 2 to remove the "empty" word from the CON= NECT format.

Thanks,
--Cigdem=C2=A0
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0

On Thu, May 2= 8, 2020 at 9:42 PM <internet= -drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Authentication and Authorization for Const= rained Environments WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= MQTT-TLS profile of ACE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Cigd= em Sengul
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Anthony Kirby
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Paul Fremantle
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-ace-mqtt-tls-profile-05.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 29
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2020-05-28

Abstract:
=C2=A0 =C2=A0This document specifies a profile for the ACE (Authentication = and
=C2=A0 =C2=A0Authorization for Constrained Environments) framework to enabl= e
=C2=A0 =C2=A0authorization in an MQTT-based publish-subscribe messaging sys= tem.
=C2=A0 =C2=A0Proof-of-possession keys, bound to OAuth2.0 access tokens, are= used
=C2=A0 =C2=A0to authenticate and authorize MQTT Clients.=C2=A0 The protocol= relies on
=C2=A0 =C2=A0TLS for confidentiality and MQTT server (broker) authenticatio= n.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dr= aft-ietf-ace-mqtt-tls-profile/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf= -ace-mqtt-tls-profile-05
https://datatracker.ietf.org= /doc/html/draft-ietf-ace-mqtt-tls-profile-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?u= rl2=3Ddraft-ietf-ace-mqtt-tls-profile-05


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
--00000000000033d48105a6bb9f76-- From nobody Sat May 30 15:36:12 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C34AD3A0B35 for ; Sat, 30 May 2020 15:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 eC9hLue2eWhe for ; Sat, 30 May 2020 15:36:06 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 9D56F3A0B34 for ; Sat, 30 May 2020 15:36:06 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 04UMa2LL013733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sat, 30 May 2020 18:36:04 -0400 Date: Sat, 30 May 2020 15:36:02 -0700 From: Benjamin Kaduk To: ace@ietf.org Message-ID: <20200530223602.GF58497@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: [Ace] "default value" for authz-info endpoint X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 30 May 2020 22:36:11 -0000 Hi all, I was prompted by the discussion at the interim to look more closely at what we say about the "default name" for endpoint URIs, e.g., the authz-info endpoint. The last paragraph of https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-33#section-5.8.1 says: The default name of this endpoint in an url-path is '/authz-info', however implementations are not required to use this name and can define their own instead. I've gotten advice from some URI experts that this doesn't give an easy/discoverable path (pun intended) to using a non-default value, which is problematic from the perspective of BCP 190 (and we should expect to get discussed at IESG evaluation time). This sort of issue goes away if we allocate a well-known URI for authz-info from https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml and have that be the default. In particular, that wouldn't actually stop any deployments from using /authz-info, but it does mean they'd have to knowingly "opt in" to doing so. What do people think? Thanks, Ben