From nobody Sat Feb 1 03:01:24 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 441C2120026; Sat, 1 Feb 2020 03:01:23 -0800 (PST) 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.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <158055488317.11743.17493600560023993363@ietfa.amsl.com> Date: Sat, 01 Feb 2020 03:01:23 -0800 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-oauth-params-12.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: Sat, 01 Feb 2020 11:01: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 : Additional OAuth Parameters for Authorization in Constrained Environments (ACE) Author : Ludwig Seitz Filename : draft-ietf-ace-oauth-params-12.txt Pages : 11 Date : 2020-02-01 Abstract: This specification defines new parameters and encodings for the OAuth 2.0 token and introspection endpoints when used with the framework for authentication and authorization for constrained environments (ACE). These are used to express the proof-of-possession key the client wishes to use, the proof-of-possession key that the Authorization Server has selected, and the key the Resource Server uses to authenticate to the client. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-params/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-oauth-params-12 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-params-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-params-12 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 Sat Feb 1 03:06: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 D23961200EB for ; Sat, 1 Feb 2020 03:06:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPV-iNgBZd0r for ; Sat, 1 Feb 2020 03:06:23 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 A05D11200E6 for ; Sat, 1 Feb 2020 03:06:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1580555179; bh=cB8VhyZVn4D34q8Q5yJ8SwthPe0YRHYB8Q+61NGOtpo=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=ZAjt7j24oo+gERIgBaEf5PxQ769Zjv3lc9hk7k3yq60T1EU4UBCKzyIIRdbi1R5HO CsRXwSd7RhWVYkAdfoId5QOPnl+w5QtrM6ghAqPSZ0nB5sjuvhI17lgph8EhXD6Hjn ZMxBjQGyKo1L6wZIscqqHvAmFPtMaYlwAkGfoTsU= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.220] ([84.217.44.37]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N1wq3-1jhrXO0QlV-012JbU for ; Sat, 01 Feb 2020 12:06:19 +0100 To: ace@ietf.org References: <158055488317.11743.17493600560023993363@ietfa.amsl.com> From: Ludwig Seitz Message-ID: Date: Sat, 1 Feb 2020 12:06:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <158055488317.11743.17493600560023993363@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:LwCScB4qSA268Y10SKlua3sVQSMa7i8tCYjkfinEJ2V9X9hm6Nh +9GM18POVad9WS9j6okLPIf8m1ZbT5JFpxrvxJGlb9/JitHYOg/aBoUOT8O3N/fyJwvFKLD 6vJnw4kjz565gRYkz7U1kKd5aD6VrNIBSxcuXn5GOFBPS5qUkwqtIKPDI+eVbW+z89y9p9T 4pRzokKvrR8QLBPGcuZFg== X-UI-Out-Filterresults: notjunk:1;V03:K0:A8LRqQDVK7w=:iXd0XmhjA3MOJQWuDbVMAb WGdn7onBx5G5gjOx7Z+lx0OMW6WlGvLA3kGQWJAMRyk+vaiWe4GxqPy11uyrzrf9GvFipLTNa GCOobdCDkGQwxoHgn0UkiExxj6gxkgQSp71bKyPq4yxBBY3femF81JXrSv0043HueG9W/hrTT PgOAmixeqyWt+DQ2Y3k7uYQJgQSkk7aD9ITZdglQTsaLICXycrPRO524KjUcTEg3lh96MKTmn iLSGoZUaqZyTK6AWEYUv74/4lA6j4Cn798G4zy/FErPVEbTKDenqWimBev/19roetiJc6Lggt uTz1AFetjaVnBeLwFcEFMxx/famRnYBIo8p4hqa+2iG+g6Vzx7y9a081fEx1bt9VtCvZo9VI1 ReWr222tfbivUyM4eppJnoK3iQ8XPnh+qm02hl8Lm4Z6emacvyY0X51/OyClVx5YJ0QeluzUC Iu0Vl79juCvavmBtTa8Ah8NFGXjLalkYjb7Tir6d7DbobjHuGPZjxRN3I7f7geGjx3jFgBrCt uver52K5CM8T9unkOPmdpnxqmGbm08tJhrUdlss4+UFWX9l6CMAy+QKolnccMC/vSs2ZTCkM8 TNn+70dhglbUu/DeLgr5HsZ0ABSpiVL3qQX4sABPbLxNtDHoaJFWnIM3FyD2+qDKEemLyxlZm I4LhI8EtPSSvriHHvw9nK80OK4jRMwyBJBgl3U1ZlHJk3DZ5KAOQWW1mfJTiI924cvh15KXxj le3dn858mY+J+nMmsL/QvEdoh729Sw1y7E/TP4opiyxvaHbhdbd2nvNl3koxDNO6TMDY/khA6 7GKQVrHQpyEMOZs1ISnHsmrBni3HezxJLxnFNFuaFoqHX45Ur3vaNFcZiz3Q9nOe0pCBOaMbK 57im3bJ83RGSsZL92O1BKeiQ0gq34KL2phm0CHW7hOqT1FAYq3YERXpUJe5VFokRVZjDHHcCc 49DPOMFtLWMQIbUZ5dmGnJ4gHuXeSBxynTSqhXydEk2CIozmc79CdRzn76jcQSNeVgKlk6J2r QJYJwT/bLLYw5g7gqEoe37UTnqJ9ofwwkb9Vbh799RUZ2+RJbiMCt5KpP5mdP4+c8OhfyIKzs ozjJ/1M+cyYaL54ZrSARQxBQuV2HaBjGG+NFfjSusaKGF0pj4ZUL6mR9fqHbwwoJ+Gxn9G558 C7729S0ZKJQ+ln+nGH7U2BCFvzLKm8ySK80oTMUUzslJ7pTuz/kgdyZWDIvE2XWFHmZx0iL2N NRkZr3GJ+EohTeCUX Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-oauth-params-12.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: Sat, 01 Feb 2020 11:06:25 -0000 Hello ACE, this update (together with an upcoming update of draft-ietf-ace-oauth-authz) fixes the issues raised by Brian Campbell. Please review the new section 7. (Requirements when using asymmetric keys) to see if you agree with the reasoning proposed therein. Regards, Ludwig On 2020-02-01 12:01, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. > This draft is a work item of the Authentication and Authorization for Co= nstrained Environments WG of the IETF. > > Title : Additional OAuth Parameters for Authorization= in Constrained Environments (ACE) > Author : Ludwig Seitz > Filename : draft-ietf-ace-oauth-params-12.txt > Pages : 11 > Date : 2020-02-01 > > Abstract: > This specification defines new parameters and encodings for the OAut= h > 2.0 token and introspection endpoints when used with the framework > for authentication and authorization for constrained environments > (ACE). These are used to express the proof-of-possession key the > client wishes to use, the proof-of-possession key that the > Authorization Server has selected, and the key the Resource Server > uses to authenticate to the client. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-params/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ace-oauth-params-12 > https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-params-12 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-oauth-params-12 > > > Please note that it may take a couple of minutes from the time of submis= sion > 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 Sat Feb 1 03:41:38 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 68D4012010E; Sat, 1 Feb 2020 03:41:36 -0800 (PST) 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.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <158055729638.11792.5791734503373593664@ietfa.amsl.com> Date: Sat, 01 Feb 2020 03:41:36 -0800 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-oauth-authz-32.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: Sat, 01 Feb 2020 11:41:36 -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 : Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) Authors : Ludwig Seitz Goeran Selander Erik Wahlstroem Samuel Erdtman Hannes Tschofenig Filename : draft-ietf-ace-oauth-authz-32.txt Pages : 87 Date : 2020-02-01 Abstract: This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE- OAuth. The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-32 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-32 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-32 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 Sat Feb 1 03:44:22 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 A85D512010E for ; Sat, 1 Feb 2020 03:44:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 vrFMFxt1Y-GX for ; Sat, 1 Feb 2020 03:44:17 -0800 (PST) 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 8B4CE12010C for ; Sat, 1 Feb 2020 03:44:17 -0800 (PST) Received: from mailhub1.air.saab.se ([136.163.213.4]) by weald2.air.saab.se (8.14.4/8.14.4) with ESMTP id 011BiFll031798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 1 Feb 2020 12:44:15 +0100 Received: from corpappl16254.corp.saab.se (corpappl16254.corp.saab.se [10.12.13.174]) by mailhub1.air.saab.se (8.13.8/8.13.8) with ESMTP id 011Bi2TO005658 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sat, 1 Feb 2020 12:44:02 +0100 Received: from corpappl16593.corp.saab.se (10.12.12.125) by corpappl16254.corp.saab.se (10.12.13.174) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Sat, 1 Feb 2020 12:44:02 +0100 Received: from corpappl16593.corp.saab.se ([fe80::b4c9:ca69:a80d:fa3]) by corpappl16593.corp.saab.se ([fe80::b4c9:ca69:a80d:fa3%7]) with mapi id 15.01.1847.003; Sat, 1 Feb 2020 12:44:02 +0100 From: Seitz Ludwig To: "ace@ietf.org" Thread-Topic: New Version Notification for draft-ietf-ace-oauth-authz-32.txt Thread-Index: AQHV2PSb4wo4JqTxRUy13+L+xhoqMKgGN2dA Date: Sat, 1 Feb 2020 11:44:02 +0000 Message-ID: <4d30342ceec14ed5969a2d9056b329fd@combitech.se> References: <158055729656.11792.17155843199056353940.idtracker@ietfa.amsl.com> In-Reply-To: <158055729656.11792.17155843199056353940.idtracker@ietfa.amsl.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: 011Bi2TO005658 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: 1581162242.62115@J62eDygqgpm54Jpn+r0+yQ X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (weald2.air.saab.se [136.163.212.4]); Sat, 01 Feb 2020 12:44:15 +0100 (CET) Archived-At: Subject: [Ace] FW: New Version Notification for draft-ietf-ace-oauth-authz-32.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: Sat, 01 Feb 2020 11:44:21 -0000 SGVsbG8gQUNFLA0KDQpUaGlzIHVwZGF0ZSBmaXhlcyBpc3N1ZXMgcmFpc2VkIGJ5IHRoZSBJQU5B IGRlc2lnbmF0ZWQgZXhwZXJ0IGZvciBtZWRpYSB0eXBlIHJlZ2lzdHJhdGlvbnMuDQoNCk5vdGUg dGhhdCBjb250cmFyeSB0byBteSBwcmV2aW91cyBleHBlY3RhdGlvbiwgdGhlIHJzX2NuZiBpc3N1 ZSBmcm9tIGRyYWZ0LWlldGYtYWNlLW9hdXRoLXBhcmFtcyBkaWQgbm90IHNwaWxsIG92ZXIgdG8g dGhpcyBkb2N1bWVudCwgc28gbm8gY2hhbmdlcyByZWxhdGVkIHRvIHRoYXQgaXNzdWUgYXJlIGlu Y2x1ZGVkIGluIHRoaXMgdXBkYXRlLg0KDQovTHVkd2lnDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgPGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZz4gDQpTZW50OiBkZW4gMSBmZWJydWFyaSAyMDIwIDEyOjQyDQpUbzogSGFubmVzIFRz Y2hvZmVuaWcgPGhhbm5lcy50c2Nob2ZlbmlnQGFybS5jb20+OyBHb2VyYW4gU2VsYW5kZXIgPGdv cmFuLnNlbGFuZGVyQGVyaWNzc29uLmNvbT47IFNhbXVlbCBFcmR0bWFuIDxlcmR0bWFuQHNwb3Rp ZnkuY29tPjsgU2VpdHogTHVkd2lnIDxsdWR3aWcuc2VpdHpAY29tYml0ZWNoLnNlPjsgRXJpayBX YWhsc3Ryb2VtIDxlcmlrQHdhaGxzdHJvbXN0ZWtuaXNrYS5zZT4NClN1YmplY3Q6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1hY2Utb2F1dGgtYXV0aHotMzIudHh0DQoN Cg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtYWNlLW9hdXRoLWF1dGh6LTMyLnR4 dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEx1ZHdpZyBTZWl0eiBhbmQgcG9z dGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1pZXRmLWFjZS1vYXV0 aC1hdXRoeg0KUmV2aXNpb246CTMyDQpUaXRsZToJCUF1dGhlbnRpY2F0aW9uIGFuZCBBdXRob3Jp emF0aW9uIGZvciBDb25zdHJhaW5lZCBFbnZpcm9ubWVudHMgKEFDRSkgdXNpbmcgdGhlIE9BdXRo IDIuMCBGcmFtZXdvcmsgKEFDRS1PQXV0aCkNCkRvY3VtZW50IGRhdGU6CTIwMjAtMDItMDENCkdy b3VwOgkJYWNlDQpQYWdlczoJCTg3DQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtYWNlLW9hdXRoLWF1dGh6LTMyLnR4dA0KU3Rh dHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt YWNlLW9hdXRoLWF1dGh6Lw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLWFjZS1vYXV0aC1hdXRoei0zMg0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1hY2Utb2F1dGgtYXV0 aHoNCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh ZnQtaWV0Zi1hY2Utb2F1dGgtYXV0aHotMzINCg0KQWJzdHJhY3Q6DQogICBUaGlzIHNwZWNpZmlj YXRpb24gZGVmaW5lcyBhIGZyYW1ld29yayBmb3IgYXV0aGVudGljYXRpb24gYW5kDQogICBhdXRo b3JpemF0aW9uIGluIEludGVybmV0IG9mIFRoaW5ncyAoSW9UKSBlbnZpcm9ubWVudHMgY2FsbGVk IEFDRS0NCiAgIE9BdXRoLiAgVGhlIGZyYW1ld29yayBpcyBiYXNlZCBvbiBhIHNldCBvZiBidWls ZGluZyBibG9ja3MgaW5jbHVkaW5nDQogICBPQXV0aCAyLjAgYW5kIHRoZSBDb25zdHJhaW5lZCBB cHBsaWNhdGlvbiBQcm90b2NvbCAoQ29BUCksIHRodXMNCiAgIHRyYW5zZm9ybWluZyBhIHdlbGwt a25vd24gYW5kIHdpZGVseSB1c2VkIGF1dGhvcml6YXRpb24gc29sdXRpb24gaW50bw0KICAgYSBm b3JtIHN1aXRhYmxlIGZvciBJb1QgZGV2aWNlcy4gIEV4aXN0aW5nIHNwZWNpZmljYXRpb25zIGFy ZSB1c2VkDQogICB3aGVyZSBwb3NzaWJsZSwgYnV0IGV4dGVuc2lvbnMgYXJlIGFkZGVkIGFuZCBw cm9maWxlcyBhcmUgZGVmaW5lZCB0bw0KICAgYmV0dGVyIHNlcnZlIHRoZSBJb1QgdXNlIGNhc2Vz Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBt YXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1 bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xz LmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Sun Feb 2 14:52:53 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 27D7D1200D6; Sun, 2 Feb 2020 14:52:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 2iAHgj5fK-OT; Sun, 2 Feb 2020 14:52:49 -0800 (PST) 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 04A6D1200E7; Sun, 2 Feb 2020 14:52:48 -0800 (PST) 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 012MqeVK017722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 2 Feb 2020 17:52:43 -0500 Date: Sun, 2 Feb 2020 14:52:40 -0800 From: Benjamin Kaduk To: Jim Schaad Cc: "'Francesca Palombini'" , draft-ietf-ace-oscore-profile@ietf.org, "'Ace Wg'" Message-ID: <20200202225240.GL91553@kduck.mit.edu> References: <20200107163851.GV57294@kduck.mit.edu> <4086FADE-7993-47F6-9292-FDD7FC5457B4@ericsson.com> <011401d5d7df$6845a050$38d0e0f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <011401d5d7df$6845a050$38d0e0f0$@augustcellars.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-oscore-profile-08 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, 02 Feb 2020 22:52:51 -0000 On Thu, Jan 30, 2020 at 06:37:37PM -0800, Jim Schaad wrote: > > > -----Original Message----- > From: Ace On Behalf Of Francesca Palombini > Sent: Wednesday, January 29, 2020 6:43 AM > To: Benjamin Kaduk ; draft-ietf-ace-oscore-profile@ietf.org; Ace Wg > Subject: Re: [Ace] AD review of draft-ietf-ace-oscore-profile-08 > > Hi Ben, > > Thank you so much for this very thorough and in-depth review! > > I have started a PR (https://github.com/ace-wg/ace-oscore-profile/pull/25 ) where I plan to include all the review comments. I have started with the editorial fixes, which I have collected in one issue: https://github.com/ace-wg/ace-oscore-profile/issues/24 > > The details of answers and additional questions for clarification are inline, I also noted with "OK" the points where I agree with your suggestion and don't see any problem implementing in the PR. I will keep the numbering consistent in the mail thread and in the github to make sure everything is covered. > > Additionally, you made a number of points I'd like to get wg opinion on: > > * The mechanism of letting the RS pick the identifier of the client is not worth the additional complexity. So I propose we revert that, and go back to AS MUST pick the clientId, the clientId MUST be included in the token. This will only add some considerations about the scenario has several-AS-per-RS, in which case these AS need to be synchronized on clientIds they give out. (6., 21., 61., 65.) > > [JLS] For better or worse, this is not the only consideration. The above statement presumes that only the AS is going to be assigning the client identifiers. If the RS uses a different method of doing authentication as well, such as LAKE, then there is a chance for collisions at that point as well. > > * Recommendation about length of nonces N1 and N2 to use. The wg agreed on 64 bits, now Ben suggests to use 128 bits nonces. Reminder: these nonces are appended to the input salt to create the Master Salt, to run the HKDF and derive the keys. Also consider that OSCORE appendix B2 has a similar setting and does some considerations about that, mentioning that "typically nonces of at least 8 bytes will be used". > > [JLS] I am agnostic on this, but I think that generally 64-bits from each side is sufficient. This does add an additional 8 bytes of message size when sending the token to the server. That worries me slightly. > I agree that 64 bits from each endpoint may well be sufficient, but it requires some analysis and thought to verify that, whereas 128 bits is "obviously enough". So, I'd like to know what level of analysis has already been done (vs. just inference from, e.g., OSCORE). -Ben From nobody Sun Feb 2 20:06: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 9130012088D; Sun, 2 Feb 2020 20:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, 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 ssxb2vrARbFG; Sun, 2 Feb 2020 20:06:10 -0800 (PST) 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 865A612082B; Sun, 2 Feb 2020 20:06:09 -0800 (PST) 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 013460MB028823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 2 Feb 2020 23:06:03 -0500 Date: Sun, 2 Feb 2020 20:06:00 -0800 From: Benjamin Kaduk To: Francesca Palombini Cc: "draft-ietf-ace-oscore-profile@ietf.org" , Ace Wg Message-ID: <20200203040600.GM91553@kduck.mit.edu> References: <20200107163851.GV57294@kduck.mit.edu> <4086FADE-7993-47F6-9292-FDD7FC5457B4@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4086FADE-7993-47F6-9292-FDD7FC5457B4@ericsson.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-oscore-profile-08 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, 03 Feb 2020 04:06:15 -0000 On Wed, Jan 29, 2020 at 02:42:34PM +0000, Francesca Palombini wrote: > Hi Ben, > > Thank you so much for this very thorough and in-depth review! > > I have started a PR (https://github.com/ace-wg/ace-oscore-profile/pull/25 ) where I plan to include all the review comments. I have started with the editorial fixes, which I have collected in one issue: https://github.com/ace-wg/ace-oscore-profile/issues/24 > > The details of answers and additional questions for clarification are inline, I also noted with "OK" the points where I agree with your suggestion and don't see any problem implementing in the PR. I will keep the numbering consistent in the mail thread and in the github to make sure everything is covered. > > Additionally, you made a number of points I'd like to get wg opinion on: > > * The mechanism of letting the RS pick the identifier of the client is not worth the additional complexity. So I propose we revert that, and go back to AS MUST pick the clientId, the clientId MUST be included in the token. This will only add some considerations about the scenario has several-AS-per-RS, in which case these AS need to be synchronized on clientIds they give out. (6., 21., 61., 65.) > * Recommendation about length of nonces N1 and N2 to use. The wg agreed on 64 bits, now Ben suggests to use 128 bits nonces. Reminder: these nonces are appended to the input salt to create the Master Salt, to run the HKDF and derive the keys. Also consider that OSCORE appendix B2 has a similar setting and does some considerations about that, mentioning that "typically nonces of at least 8 bytes will be used". > * Define and register 2 new ACE parameters to transport the nonces used in the exchange, instead of using "cnonce". (see point 3., 53.) > * Define the nonces as bstr so that length value is encoded. (7.) > https://tools.ietf.org/html/rfc8613#page-72 > * Editorial: point 75. > > Thanks again! > Francesca > > On 07/01/2020, 17:40, "Ace on behalf of Benjamin Kaduk" wrote: > > Hi all, > > Some high-level points before the section-by-section commentary: > > 1. I'm a little confused by the registry we are creating in Section 9.2. > While it's clear that we need something to specify the CBOR map key > labels to encode the structure for transit, it's not clear that we need > easy extensibility vs. a fixed table. A registry implies expectations > of future additions, but draft-ietf-core-object-security did not feel a > need to make a registry for future extensions; what has changed in the > past few months that makes extensibility needed now? Why is this > document the right place to create the registry as opposed to that one? > > FP: Why extensibility now: an example is the Group OSCORE profile, which extends this registry with fields that the OSCORE profile does not need, related to countersignatures (see https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore-04#page-22 ). The difference between OSCORE (RFC8613) and this doc is that in OSCORE the security context is never sent on the wire, it is assumed to be pre-established, while here we needed to define a structure to send. Yes, we could avoid defining the registry and define all the fields (we can think of right now), including those for ace-key-groupcomm-oscore as a fixed table, but we thought this would be better, also considering that the OSCORE security context could get extended in a future version of OSCORE. I would suggest that we have some discussion about how "stock OSCORE" treats the security context as a logical entity local to each endpoint, but since we need to serialize it, the registry is required for extensibility. We will probably still get questions from other IESG members about the relationship between this registry and the core OSCORE spec, but we can explain as needed. > 2. We are in some sense defining a new substructure within "kid" values (a > CBOR-encoded array of one or two elements) for usage by things using > this profile. That's probably not problematic, as the "kid" can be an > arbitrary bstr and its interpretation is up to the recipient -- any > recipient that implements this profile will know to handle the > substructure, but it does feel a little unusual and perhaps worth an > early note. (IIUC, we also need to be careful about actually providing > the bstr framing in our examples.) > > FP: Ok, I will add an early note and also make sure the array is wrapped in a bstr. Do you have any opinion on where best to add this note? Kid appears first in 3.1, should we have it in the introductory section 3.? Or were you thinking even before? I think we may have to put something in Section 2, noting that OSCORE needs to have identifiers for both parties, but these identifiers are only unique within the scope of a given ID context, and that in order to have a protocol element to convey both the client ID and the ID context, this profiles uses a substructure within the "kid" bstr. > 3. I'm concerned about the usage of "cnonce" to carry both N1 and N2, > neither of which correspond to the "cnonce" behavior in the core > framework; I think we should pick a different parameter name for the > differeng semantic usage. Specifically, the core-framework "cnonce" is > a tool to give RSes some modicum of replay protection -- it verifies > that the client's authorization in the token is "fresh", since the token > includes the random nonce generated by the RS and conveyd to the AS via > the client. This document uses a parameter named "cnonce" in two ways: > (1) to convey the client-generated nonce N1 to the RS in the authz-info > request; this is giving the client contributory behavior to the > ephemeral randomness input to the Security Context computation but does > not provide any sort of replay-protection in and of itself > (2) to convey the RS-generated nonce N2 back to the client in the > authz-info response; this does serve as replay protection in some sense, > but in that it serves to cause repeated posting of the same token (as > might occur in a replay attack) to generate a different OSCORE context > (due to the RSes contributory nature) so that the resulting key material > will be unique for a given association, as opposed to detecting and > blocking replay outright. I think all three uses should have distinct > parameter names, based on my current understanding. > > FP: Yes, your understanding is right. I don't see any problem at all with defining new parameters names for the nonces, the reason we used "cnonce" is that this exact point was brought up in the wg and everybody seemed to agree on no need to define a new one, despite the semantics of "cnonce". The authors did not have a strong opinion. It's true that, at the moment, there's no ambiguity of interpretation once the context in which the message is received is known. But it feels awkward and constrains future extensions to alias the semantics in this way, and it's not obvious that codepoints are so scarce that we need to have such a confusing interpretation of the field across messages. > 4. We mention several times about getting protection from AEAD nonce/key > reuse, but to some extent leave it to the reader to figure out how that > works. Specifically, the only guidance we give on nonce selection is > for our N1 and N2 that go into the Master Salt; we don't say how varying > the Master Salt like that will cause the generated keys and (common) IVs > to differ across runs, thus by construction preventing the collision of > (key, nonce) pairs. (Implementation carelessness that just reuses > key+nonce for a given Security Context is still possible, of course.) > > FP: Would it be sufficient to add a sentence in Section 2 saying that by construction if Master Salt is different that will generate different keys and common IVs (+ reference to OSCORE)? For example in this paragraph: > > In fact, by using random nonces as part > of the Master Salt, the request to the authz-info endpoint posting > the same token results in a different Security Context, since Master > Secret, Sender ID and Recipient ID are the same but Master Salt is > different. That sounds like a good plan, yes. > 5. In a related vein, we do not get into full detail about the > cryptographic role played by N1 and N2, so as to make the reader > confident that our 64-bit recommendation does provide full > Internet-grade security (as opposed to a weakened "IoT" variant). I'm > not specifically concerned, but we may get some reviewers asking for > more detail. > > FP: would it be sufficient to add text along the lines of what you describe in point 3 above? Hmm, I'm not entirely sure how related they are. What I had in mind here is more along the lines of the analysis that I asked about in response to Jim (downthread). > 6. I am, however, concerned about the exposure to an RFC 3552-style > attacker for unprotected authz-info responses. There are two main > aspects I'm concerned about: identifier selection and nonce selection. > Letting the server override the client's idea of its own identity (even > when the AS has given the client an identifier!) seems to increase the > risk of a client being tricked into impersonating a different client, > and the stated justification (letting the RS preserve uniqueness) > doesn't seem to hold up in our one-AS-per-RS stated scope, where the AS > can equally well do so. Based on what I know right now, it doesn't feel > like we're at the right point on the cost/benefit curve. For the nonce > selection, this comes into play due to the lack of injectivity for the > mapping of initial AS-generated salt, N1, and N2 into the Master Salt. > Specifically, if a client chooses an N1 that's a prefix of some other N1 > that was used, then the attacker can send an "N2" that contains the tail > end of that other N1 plus the actual N2 picked by the server in that > other exchange, causing a full nonce collision and having the > AS-generated portion be the only difference in Master Salt between > security contexts. Using a length prefix for the fields being > concatenated provides injectivity and thwarts this type of attack. > > FP: Concerning identifier selection: after a number of points raised (here and in following points), I do believe that the mechanism of letting the RS pick the identifier of the client is not worth the additional complexity. So I propose we revert that, and go back to AS MUST pick the clientId, the clientId MUST be included in the token. This will only add some considerations about the scenario has several-AS-per-RS, in which case these AS need to be synchronized on clientIds they give out. Okay. I think ASes need to be synchronized in other ways already (right?), so that's not a substantial additional burden. > About nonce selection: we will define N1 and N2 as CBOR bstr, so that the length prefix will be included. Nice and elegant :) > 7. There are a few places where I'm not entirely sure how the protocol flow > works for the case where the RS is (re)assigning the clientId; I've > tried to note them in the section-by-section comments. > > FP: Yes, I agree, we missed some of those. As mentioned, I think it could be solved, but the additional complexity is probably not worth it. > > On to the section-by-section notes: > > Section 1 > > 8. I'd suggest noting that this is a symmetric-crypto-based scheme in some > manner (e.g., that the AS is assigning a shared symmetric key used as the > OSCORE master secret), and/or that asymmetric PoP semantics are not possible > with this mechanism (or OSCORE in general). > > FP: OK > > 9. I'd also suggest noting that proof of possession is not done by a dedicated > protocol element, but rather occurs implicitly based on knowledge of the > OSCORE Security Context. (This is essentially analogous to Kerberos, but a > reference is not strictly needed.) We do have a good treatment in > toplevel Section 4, but it might be worth saying earlier. > > FP: OK > > Section 2 > > 10. [I-D.ietf-ace-oauth-authz]. The access token request and response > MUST be confidentiality-protected and ensure authenticity. This > profile RECOMMENDS the use of OSCORE between client and AS, but TLS > or DTLS MAY be used additionally or instead. > > Since the client/AS and client/RS profile are supposed to be completely > severable, I don't think we should use "MAY" here; perhaps "but other > protocols (such as TLS or DTLS) can be used as well". > > FP: OK > > 11. Once the client has retrieved the access token, it generates a nonce > N1 and posts both the token and N1 to the RS using the authz-info > endpoint and mechanisms specified in section 5.8 of > [I-D.ietf-ace-oauth-authz] and Content-Format = application/ace+cbor. > > Do we want to say explicitly that there is no cryptographic protection > applied for this POST to authz-info? > > FP: OK (will add a note) > > 12. which contains a nonce N2 in a CBOR map. Moreover, the server > concatenates N1 with N2 and appends the result to the Master Salt in > the Security Context (see section 3 of > [I-D.ietf-core-object-security]). The RS then derives the complete > Security Context associated with the received token from it plus the > parameters received in the AS, following section 3.2 of > [I-D.ietf-core-object-security]. > > This passage feels strange to me, probably because it seems to use "Master > Salt" to both the portion with and without N1+N2, and also because it does > not introduce "the Master Salt" as a term or some other object that deserves > the definite article. Would it be equivalent to say "Moreover, the server > concatenates the input salt, N1, and N2 to obtain the Master Salt of the > OSCORE Security Context (see section 3 of [I-D.ietf-core-object-security]" > instead? (Though the details may yet change based on later comments...) > Is "from it" the resulting Master Salt? > There seems to be a word or two missing in "the parameters received in > the AS". (Presumably these parameters are contained in the token?) > > FP: OK. Yes,that would be equivalent. Yes, "From it" referred to the Master Salt (the input salt concatenated with N1 and N2). Yes, it's missing "received in the access token from the AS". > > 13. After receiving the nonce N2, the client concatenates it with N1 and > appends the result to the Master Salt in its Security Context (see > section 3 of [I-D.ietf-core-object-security]). The client then > derives the complete Security Context from the nonces plus the > parameters received from the AS. > > Similarly, IIUC we should be able to word this so that the "Master Salt" is > unique (and includes the nonces), as opposed to having it apparently refer to > both the pre- and post-nonce-includion strings. > Are these "parameters" received from the AS in the token response? > > FP: OK. Yes, they are. > > 14. Finally, the client sends a request protected with OSCORE to the RS. > If the request verifies, then this Security Context is stored in the > server, and used in the response, and in further communications with > the client, until token expiration. This Security Context is > discarded if the same token is re-used to successfully derive a new > Security Context. > > The conditional on storing the Security Context only if the request > verifies reads oddly to me, as the RS seems to have needed to store some > amount of security context information for the period betweeen receiving > the token and receiving the authenticated request, as a prerequisite to > being able to verify the request. > Also, is this security context discarded if a new token from the same > client is successfully used? > > FP: "Storing" is probably not clear enough, the point is that only after the request passes verification the server marks this security context as "valid" for this client. I'd love suggestions on how to make this clearer. Yes, the security context is discarded if a new token (or a valid old one) is successfully used. Is anything missing here? W.r.t. the wording, would it work to do something like s/then this Security Context is stored in the server/the server stores the complete Security Context state that is ready for use in protecting messages/? On the discarding old security contexts point, I don't think it's necessarily required to mention the new-token case here (as it's semantically different), but as an editorial matter if it flows more smoothly to talk about "context is discarded when a token (whether the same or different) is used to derive a new Security Context for that client" then we get coverage of both cases "for free". > 15. The use of random nonces during the exchange prevents the reuse of > AEAD nonces and keys with different messages, in case of re- > derivation of the Security Context both for Clients and Resource > Servers from an old non-expired access token, e.g. in case of re-boot > of either the client or RS. In fact, by using random nonces as part > > This sentence is pretty long and a little hard to parse. I'd suggest > something more like: > > % The use of random nonces during the exchange prevents the reuse of > % an AEAD nonces/key pair for two different messages. This situation > % might occur when client and RS derive a new Security Context from an > % existing (non-expired) access token, as might occur when either party > % has just rebooted. [...] > > FP: OK > > I'd also consider s/In fact/Instead/ since we are contrasting the > previously described hypothetical (bad) scenario with what actually > happens. > > FP: OK > > 16. of the Master Salt, the request to the authz-info endpoint posting > the same token results in a different Security Context, since Master > Secret, Sender ID and Recipient ID are the same but Master Salt is > different. Therefore, the main requirement for the nonces is that > > nit: [more usage of "Master Salt" for pre- and post-nonce forms] > I'd also suggest to s/since/since even though the/ (and the s/but/the/ > needed to fix up the end of the sentence). > > FP: OK (reformulation already fixed in PR) > > I also want to check my understanding: this "different Security Context" is > still going to use the same identifiers for the endpoints, and will just have > different keys/IVs/etc? This would tie in to the (later) recommendation to > have such a new Security Context completely replace the old one, since > otherwise we'd have to resort to trial decryption to determine which > Security Context to use for processing a given message. > > FP: Yes, it would use the same identifiers. Typically, the old security context would get discarded when the new one is validated. Applications could still decide to keep more than one context, and in that case yes, they'd have to rely on trial decryption, but that is not the goal of this document. Okay, thanks for confirming. > 17. they have a good amount of randomness. If random nonces were not > used, a node re-using a non-expired old token would be susceptible to > on-path attackers provoking the creation of OSCORE messages using old > AEAD keys and nonces. > > I guess the focus on "good amount of randomness" is trying to emphasize > that we merely need to avoid a single node accidentally producing the > same value, as opposed to a stricter property of unguessability by an > on-path attacker? Or is unguessability also needed when the attacker > can delay traffic? > > FP: Yes, that is correct (about the single node). We do not think unguessability is needed. Do you think it should? I don't know of a reason why unguessability would be needed. > Section 3 > > 18. Section 3.2 of [I-D.ietf-core-object-security] defines how to derive > a Security Context based on a shared master secret and a set of other > parameters, established between client and server, which the client > receives from the AS in this exchange. The proof-of-possession key > > We say that the client gets the OSCORE parameters from the AS in the > token response; where do we say how the RS gets the OSCORE parameters > from the AS? > > FP: Do you mean this sentence from section 4. > > The > client generates a nonce N1 and posts it together with the token that > includes the materials provisioned by the AS to the RS. > > And if not, what are we missing? This may just have been a matter of "I didn't get to that part of the document when I wrote the question". That said, it probably doesn't hurt to say "the materials (e.g., OSCORE parameters) provisioned by the AS to the RS" in the Section-4 passage. > Section 3.1 > > 19. The client MUST send this POST request to the token endpoint over a > secure channel that guarantees authentication, message integrity and > confidentiality (see Section 5). > > (The framework already requires this, so we may not need the "MUST" > keyword again, though I'm not proposing to remove all mention of the > need for these properties.) > > FP: OK, will remove normative MUST etc for the requirements coming from the framework. Thanks. This is an aspect where opinions differ, but I generally fall into the camp that says the risk of introducing conflicting requirements is stronger than the desire to reinforce the requirement with normative language multiple times. > 20. An example of such a request, in CBOR diagnostic notation without the > tag and value abbreviations is reported in Figure 2 > > nit: only the payload is using CBOR diagnostic notation; the headers are > using CoAP notation. > > FP: Done in PR. > > 21. If the client wants to update its access rights without changing an > existing OSCORE Security Context, it MUST include in its POST request > to the token endpoint a req_cnf object. The req_cnf MUST include a > kid field carrying a CBOR array object containing the client's > identifier (assigned in section Section 3.2) and optionally the > context identifier (if assigned in section Section 3.2). The CBOR > > I'm not sure the best way to write a clear description that includes the > "bstr" framing for "kid". > > FP: OK, it is missing here that the CBOR array is wrapped in a bstr. I did miss that the kid is a CBOR bstr and not a byte string. > > Also, nit: the "assigned" language in the parentheticals feels weird to > me, here. > > FP: Why? the use of "assigned" was to highlight that that's the value the AS has set and communicated to the Client. How can we make it clearer? I think it's because "assigned in Section 3.2" sounds like this spec is making the assignment, but all that's actually in Section 3.2 is the procedure/potential for making that assignment. So "assigned as discussed in" would read more naturally to me. > What's the workflow when the RS has overridden the AS's idea of the > clientId? Does the client have to remember the original AS-assigned > clientId and use it here instead of the RS-assigned one? > > FP: Good point, which we did not expand on. Yes, to make this mechanism work (RS can pick an identifier for the client + AS has already assigned one) the client would have to remember the original AS-assigned clientID and use that. Or we should define a mechanism for the client to communicate the RS-assigned clientId to the AS. This would be necessary also in case the AS did not assign the clientId at all. After thinking this through I think this complication makes this RS overwriting the clientId mechanism not worth having. No argument from here :) > > 22. These identifiers can be used by the AS to determine the shared > secret to construct the proof-of-possession token and therefore MUST > identify a symmetric key that was previously generated by the AS as a > shared secret for the communication between the client and the RS. > > nit: I suggest s/shared secret to construct/shared secret bound to/ > > FP: Done in PR. > > Also, I think the AS will need to use some of the other token request > parameters (e.g., req_aud) in order to determine the client and RS for > which it needs to retrieve the shared PoP key. We might want to mention > that as well. > > FP: I am not sure that would be needed, in principle. If the client sends them, then yes, they could be used (and I can add text clarifying that), but if it doesn't, those identifiers should be enough. I think I had in mind a case where the AS assigns the same client ID and context ID to more than one (client, server) pairs (but of course with different servers). The AS can choose to not do so, but I don't remember anything that prevents it; in such cases the AS would need to know at least which client (and maybe which server, if the client is duplicated in the (client, server) pairs) is making the reuqest. This could be done by the key used to authenticate to the AS, the requested audience (server), etc., but I think there are scenarios allowed by the spec where just "req_cnf" is not enough. > 23. The AS MUST verify that the received value identifies a proof-of- > possession key and token that have previously been issued to the > requesting client. If that is not the case, the Client-to-AS request > > nit: It's not clear that we need it to identify a specific token, just a > key. (And in fact for multiple successive access-rights updates, there > will be more than one previous token.) > > FP: Done in PR. Unrelated, but why would the AS keep more than one previous token? It would be weird for the AS to keep more than one (but is, IIRC, allowed). >From a rhetorical sense, though, I think even tokens already deleted by the RS would still qualify as "previous token"s absent further clarifying language. > The "kid" "req_cnf" member in Figure 4's example does not include the > bstr wrapper that draft-ietf-ace-cwt-proof-of-possession suggests is > required. > > FP: correct, kid is missing the bstr wrapper, but req_cnf should be correct, as it should be a map (https://tools.ietf.org/html/draft-ietf-ace-oauth-params-11#section-3.1 defines it having the same structure of "cnf" from draft-ietf-ace-cwt-proof-of-possession, which in section 3.4 defines it as a CBOR map). Right; I was just identifying that "kid" is a member of the "req_cnf" map. Sorry for the confusion. > Section 3.2 > > 24. Moreover, the AS MUST provision the following data: > > It's frequently the case in IETF documents that "provision" is a > euphimism for "out-of-band configuration", so if we mean "include in the > token response" it's probably better to say that directly. > > FP: OK, Done in PR. > > 25. Additionally, the AS MAY provision the following data, in the same > response. > > When the AS does not do so, how are these parameters determined? > > FP: Context ID can be omitted and not used in OSCORE. AEAD alg, HKDF alg, salt and replay window can be omitted and then the default value would be used in OSCORE. That should be clear from section 4.3, specifically the sentence: > " In > case these parameters are omitted, the default values are used as > described in section 3.2 of [I-D.ietf-core-object-security]. " > Anything else we need to add? No, this looks fine (and thanks for explaining). > 26. The OSCORE_Security_Context is a CBOR map object, defined in > Section 3.2.1. The master secret MUST be communicated as the 'ms' > field in the OSCORE_Security_Context in the 'cnf' parameter of the > access token response as defined in Section 3.2 of > [I-D.ietf-ace-oauth-params]. The AEAD algorithm MAY be included as > > nit: s/in the OSCORE_Security_Context/in the OSCORE_Security_Context > field/, I think? > > FP: Done in PR. Yes it is. > > 27. the 'alg' parameter in the OSCORE_Security_Context; the HKDF > algorithm MAY be included as the 'hkdf' parameter of the > OSCORE_Security_Context, a salt MAY be included as the 'salt' > parameter of the OSCORE_Security_Context, and the replay window type > and size MAY be included as the 'rpl' of the OSCORE_Security_Context, > as defined in Section 3.2.1. > > I think we want to reword all of these, as I understand what we're doing > to be defining the parameters in which these values are conveyed, if > they are conveyed at all. Just saying " MAY be conveyed in " has > the connotation that might alternatively be conveyed in some other > that is not mentioned. The relevant MAY for our purposes is the one > above the list -- "the AS MAY provision the following data". > > FP: OK. I will remove all the normative MAY and replace them with may. Would that be sufficient? Now that you reminded me about the defaults and Section 4.3, yes :) > 28. The same parameters MUST be included as metadata of the access token. > This profile RECOMMENDS the use of CBOR web token (CWT) as specified > in [RFC8392]. If the token is a CWT, the same > OSCORE_Security_Context structure defined above MUST be placed in the > 'cnf' claim of this token. > > nit: "metadata of the access token" sounds like it's trying to be a term > of art, but it is not presently used as such. s/metadata/attributes/ > would, IIUC, be more in keeping with OAuth 2.0 tradition. > > FP: rephrased into "part of the access token" in PR, is that ok? Yes, that works. > not-nit: the second sentence seems redundant with the second sentence of > the previous paragraph. > > FP: I do agree there is some redundancy. The previous sentence’s MUST referred to the master secret and how it MUST be transported (‘ms’ field of ‘OSCORE_Security_Context’ in ‘cnf’), this sentence is about OSCORE_Security_Context in ‘cnf’. I suggest removing the first MUST, as that will be compliant with point 27, removing the normative MAYs. I think that's okay, assuming I understand correctly ("master secret must be communicated as the 'ms' field"). > 29. The AS MUST also assign an identifier to the RS (serverId), MAY > assign an identifier to the client (clientId), and MAY assign an > identifier to the context (contextId). These identifiers are then > used as Sender ID, Recipient ID and ID Context in the OSCORE context > as described in section 3.1 of [I-D.ietf-core-object-security]. The > couple (client identifier, context identifier) MUST be unique in the > set of all clients on a single RS. Moreover, when assigned, > serverId, clientId and contextId MUST be included in the > OSCORE_Security_Context, as defined in Section 3.2.1. > > [Any time we're assigning identities we have to say something about the > privacy properties thereof, or a bunch of reviewers will complain.] > > FP: OK. What about adding privacy considerations pointing to the privacy considerations in OSCORE? I feel that should cover it. Yes, that looks like it will do just fine. > Is the Recipient ID expected to be stable/persistent for a given RS as seen > by all clients? > > FP: Not necessarily. > > nit: "all clients on a single RS" reads oddly to me; maybe s/on/of/? > > FP: Done in PR. s/on/for > > nit: I'd suggest to replace "couple" with "tuple" or "pair". > > FP: Done in PR: "pair". > > nit: serverId is always assigned by the AS, so the "when assigned" > doesn't quite bind properly, grammar-wise. While the clientId is > "always assigned" by the time of the Master Secret derivation, this is > just discussing the AS token response, so we can't necessarily assume > it's assigned here, at least with the current protocol spec. > > FP: Done in PR. I believe this is a formulation problem. Yes the serverId is always assigned, so it would always be included in the OSCORE_Security_Context. The point of this sentence was: whenever the AS assigns a value for the identifier, it also sets the corresponding field to that value in the OSCORE_Security_Context. I reformulated: The pair (client identifier, context identifier) MUST be unique in the set of all clients for a single RS. Moreover, clientId, serverId and (when assigned) contextId MUST be included in the OSCORE_Security_Context, as defined in ... This would be consistent with removing the option of clientId not being included in the OSCORE_Security_Context. Yes, thanks! > OSCORE requires a Sender ID and Recipient ID, but we only have it as > optional for the AS to assign the clientId -- what does OSCORE use as > the Sender/Recipient ID when the AS does not assign a clientId? > > FP: That was the case where the RS MUST assign a clientId, see section 4.2: > “Moreover, if the OSCORE_Security_Context in the token did not > contain a 'clientId' parameter, the RS MUST generate an identifier, > unique in the set of all its existing client identifiers, and send it > in a 'clientId' parameter in the CBOR map as a CBOR bstr.“ > But if we agree on removing this mechanism, this becomes outdated. > > When certain fields are optional, we typically have to ask whether it's > possible for the two parties to disagree about whether the field is > present. IIUC, the OSCORE context derivation procedure includes enough > information to prevent that possibility, but it would be good if someone > would confirm that. > > FP: That is correct, a number of fields have default values when non present. Hkdf, alg, salt, contextId, rpl. On the other hand, ms, clientId and serverId need to be set. Hmm, so there is not a great mechanism to distinguish "absent" from "present with default value", but the practical consequences of such an attack seem quite limited. > 30. We assume in this document that a resource is associated to one > single AS, which makes it possible to assume unique identifiers for > each client requesting a particular resource to a RS. If this is not > > I feel like this might be more clear if we can frame it in terms of the > AS enforcing the uniqueness of client identifiers (or, if you will, that > we delegate the enforcement thereof to the AS...) > > FP: OK > > 31. the case, collisions of identifiers may appear in the RS, in which > case the RS needs to have a mechanism in place to disambiguate > identifiers or mitigate their effect. > > nit: s/appear in/occur at/ > > FP: Done in PR. > > nit: s/mitigate their effect/mitigate the effect of the collisions/ > > FP: Done in PR. > > 32. Note that in Section 4.3 C sets the Sender ID of its Security Context > to the clientId value received and the Recipient ID to the serverId > value, and RS does the opposite. > > (The way this is written implicitly assumes that both clientId and > serverId are received from the AS.) > > FP: That's right. I would keep as is if we agree on removing the RS-assigns-identifier mechanism. > > 33. Figure 5 shows an example of such an AS response, in CBOR diagnostic > notation without the tag and value abbreviations. > > I'd suggest s/such an AS response/an AS token response/ > > FP: OK > > 34. "access_token" : h'a5037674656d7053656e73 ...' > (remainder of access token omitted for brevity)', > > In addition to the invalid-CBOR-diagnostic-notation-syntax comment, we > also have unbalanced quotes. > > FP: Right, but this is not valid CBOR diagnostic notation syntax anyway, do you have a better idea? I do not think it would be useful to have the full token here. Will remove the unbalanced quote. This is probably manageable, though we do often see people put a disclaimer before the example that are truncated for readability; some other ADs may have other suggestions, too. > 35. "profile" : "coap_oscore", > "expires_in" : "3600", > "cnf" : { > "OSCORE_Security_Context" : { > "alg" : "AES-CCM-16-64-128", > "clientId" : b64'qA', > "serverId" : b64'Qg', > > Any reason to prefer b64'qA' over h'a8' which is shorter? > > FP: No, this is a leftover of some previous example. Will remove b64 encodings. > > 36. If the client has requested an update to its access rights using the > same OSCORE Security Context, which is valid and authorized, the AS > MUST omit the 'cnf' parameter in the response, and MUST carry the > client identifier and optionally the context identifier in the 'kid' > field in the 'cnf' parameter of the token, with the same structure > > I think we should be careful about referring to this as "optionally the > context identifier" -- the choice for whether there is a context > identifier is made once (at initial issuance), and subsequent usage > depends on whether one has been allocated or not. It's not like the AS > can decide at runtime "I gave you a context identifier for your original > security context, but I don't feel like giving it to you again" -- the > derived keys won't match up and it won't be reusable as the same > security context. > > FP: Right, this again is a formulation problem. The optionality comes from if it has ever been assigned/allocated/set for that security context. What about reformulating into: > , and MUST carry the > client identifier and the context identifier (if it was set and included in the initial access token response byt the AS) in the 'kid' > field in the 'cnf' parameter of the token, with the same structure That sounds good. > Also, I'm not sure this is fully defined for the case when the RS > overrides the AS's clientId assignment, as the kid array in the token > needs to be the value the RS will know, but the kid in req_cnf needs to > be the one the AS knows, and we don't really define a mechanism for the > AS to be able to do translation from one to the other. > > FP: Right… this is getting complicated. If the client and the RS both kept track of AS-assigned and RS-assigned clientId, that could still work. Or if there was a mechanism for the client to communicate to the AS: “this is the RS-assigned kid, this is the AS-assigned kid, please talk to me as the former”. As mentioned, I think this is getting too complicated and propose removing this mechanism altogether. > > 37. defined in Figure 3. These identifiers need to be provisioned, in > order for the RS to identify the previously generated Security > Context. > > nits: there's only one (not "these") identifier in the token, and > nothing in the token response; and a similar remark about "provisioned" > as was made above. > > FP: Here it referred to both clientId and contextId (from the previous sentence), which are carried in the kid field, so I think “these” should be ok. Please correct me if I am wrong. Ok about provisioned, done in PR. There's only the one ('kid') field in the token, but I think you're correct here. Sorry for the mixup! > 38. Figure 9 shows an example CWT, containing the necessary OSCORE > parameters in the 'cnf' claim for update of access rights, in CBOR > diagnostic notation without tag and value abbreviations. > > { > "aud" : "tempSensorInLivingRoom", > "iat" : "1360189224", > "exp" : "1360289224", > "scope" : "temperature_h", > "cnf" : { > "kid" : b64'qA' > > I don't think this "kid" is a valid CBOR bstr wrapping the one- or > two-element array. > > FP: OK > > Section 3.2.1 > > 39. [I-D.ietf-core-object-security]). The OSCORE_Security_Context object > can either be encoded as JSON object or as CBOR map. In both cases, > > nits "a JSON object", "a CBOR map". > > FP: Done in PR. > > 40. defined below. All parameters are optional. Table 1 provides a > summary of the OSCORE_Security_Context parameters defined in this > section. > > They're optional to appear in the OSCORE_Security_Context object that's > included in a "cnf" value, but not necessarily optional for OSCORE to be > usable. What do we do for OSCORE when any given parameter is not > present in this structure? (Also, doesn't the AS always have to provide > things like 'ms' and 'serverId'?) > > FP: This is just the structure definition, which is aimed to be more general than just for this spec. For example, this could be reused to send only a part of these parameters, for example if only the salt + identifiers need to be updated. Yes, that is correct, not all parameters are optional when used in this profile, as mentioned in a previous point. ms, serverId are not optional. In an OSCORE Security Context: master secret, sender Id and recipient Id are not optional. Section 4.3 describes what happens if any of the parameters is not present: Maybe the text relating to my high-level point (1) could try to indicate that the structure definition is also trying to be more general than just this profile, as otherwise it's not entirely clear to me. (But if the wording is too awkward, we can probably think of something else.) > “If any of the expected parameters is missing (e.g. any of the > mandatory parameters from the AS, or the 'clientId', either received > from the AS or in the 2.01 (Created) response from the RS), the > client MUST stop the exchange, and MUST NOT derive the Security > Context. The client MAY restart the exchange, to get the correct > security material.” > > 41. | hkdf | 4 | bstr / int | COSE | OSCORE HKDF | > | | | | Algorithm | value | > | | | | Values | | > | | | | (HMAC-based) | | > > Should be tstr, not bstr, right? > > FP: Yes, OK. > > Also, why do we need the string form of either hkdf or alg? More > possibilities makes the decoder more complicated and increases the > attack surface. > > FP: because a COSE algorithm can be registered as a string (see https://tools.ietf.org/html/rfc8152#section-16.4 “Value”). Ah, I missed that; sorry. > 42. | rpl | 8 | bstr / int | | OSCORE Replay | > | | | | | Window Type | > | | | | | and Size | > > Should just be bstr (not int), right? > > FP: Yes. OK. > > 43. hkdf: This parameter identifies the OSCORE HKDF Algorithm. For more > information about this field, see section 3.1 of > [I-D.ietf-core-object-security]. The values used MUST be > registered in the IANA "COSE Algorithms" registry and MUST be > HMAC-based HKDF algorithms. The value can either be the integer > > It's a little unfortunate that we basically are relying on "I know it > when I see it" for determining which algorithms are HKDF algorithms. > > FP: Agreed, but we don’t really have another way to say this. If you or COSE experts (Jim) have any idea please let us know. I think we inherited this from JOSE :-/ > Also, "HKDF" expands to "HMAC-based Extract-and-Expand Key Derivation > Function", i.e., is definitionally HMAC-based. So this should be > reworded to reflect the actual intent. > > FP: Right, that is because COSE also defines HKDF using AES-MAC, see Table 12 of RFC8152, so we needed to specify that only HMAC-based can be used. Oof, rather unfortunate IMO that the terminology was overloaded by RFC 8152. > 44. alg: This parameter identifies the OSCORE AEAD Algorithm. For more > information about this field, see section 3.1 of > [I-D.ietf-core-object-security] The values used MUST be registered > in the IANA "COSE Algorithms" registry and MUST be AEAD > algorithms. The value can either be the integer or the text > > Similarly, this seems to be "I know it when I see it". > > FP: Yes. > > 45. contextId: This parameter identifies the security context as a byte > string. This identifier is used as OSCORE ID Context. For more > information about this field, see section 3.1 of > [I-D.ietf-core-object-security]. In JSON, the "contextID" value > is a Base64 encoded byte string. In CBOR, the "contextID" type is > bstr, and has label 7. > > Do we need to forbid present-but-empty contextIds in order to avoid > cryptographic collision with absent-contextId? > > FP: The field being present but empty (i.e. value is the empty byte string) is not the same as absent, in OSCORE. So we do not need to forbid that. Cool. > 46. rpl: This parameter is used to carry the OSCORE value, encoded as a > bstr. This parameter identifies the OSCORE Replay Window Size and > Type value, which is a byte string. For more information about > this field, see section 3.1 of [I-D.ietf-core-object-security]. > In JSON, the "rpl" value is a Base64 encoded byte string. In > CBOR, the "rpl" type is bstr, and has label 8. > > I tried to follow the reference, but I couldn't really find a > description of the encoding for this as a byte string (especially > noteworthy since we claim that it represents both size and type). > (Relatedly, I'm not sure why it's allowed to be either bstr or int.) > > FP: Right, this is an old reference, where we actually gave a default encoding for rpl, I believe. Now this is entirely up to the application. I would keep this as bstr and specify that it is any format wrapped in a bstr. "Up to the application" meaning known by prior agreement among all three of C, AS, and RS? > Also I need to fix a couple of mistakes: “OSCORE value” is wrong; “Replay Window” and not "Size and Type". Also, I think we need to define a new IANA registry for rpl with 0 as default, so that applications can define their format. I'm not entirely sure I understand that the registry is for (i.e., what you propose). > Section 4 > > 47. Can we get some CDDL or similar for both C-to-RS and RS-to-C (in the > respective subsections)? > > FP: I am not sure what you’d like to see in CDDL in this subsection, could you expand? I am not sure what the body of the POST and response thereto are formatted as. Maybe CDDL is not quite right, if we only want to provide an example with a particular content-format but allow many formats. > 48. I'd naively expect a section titled "Client-RS Communication" to include > some discussion of normal protected OSCORE request/response pairs once > the security context is fully established, but this initial section > basically only talks about the authz-info interaction and disclaims that > the subsections will cover anything else. > > FP: Ok, will add some introductory text about the OSCORE security context being used of future OSCORE protected communication. Thanks! > 49. The following subsections describe the details of the POST request > and response to the authz-info endpoint between client and RS. The > client generates a nonce N1 and posts it together with the token that > includes the materials provisioned by the AS to the RS. The RS then > derives a nonce N2 and use Section 3.2 of > > nits: "provisioned" again, and the RS is going to be generating a nonce > from scratch, not deriving one from ... anything else, really. > > FP: Done in PR. > > 50. [I-D.ietf-core-object-security] to derive a security context based on > a shared master secret and the two nonces, established between client > and server. > > (The shared master secret is part of what the AS provisions^Wgives to > the RS, right?) > > FP: Yes, correct. Actually here it is also the clientId, serverId and contextId (if any) that are used for deriving the OSCORE context. > > 51. Note that the proof-of-possession required to bind the access token > to the client is implicitly performed by generating the shared OSCORE > Security Context using the pop-key as master secret, for both client > and RS. An attacker using a stolen token will not be able to > generate a valid OSCORE context and thus not be able to prove > possession of the pop-key. > > It may be worth saying something roughly equating "proof of possesion > performed by the RS" and "the RS authenticating itself to the client", > since there is not an external action for server authentication. > Also, ISTR getting some pushback on a different document that talked > about an attacker with a "stolen token", as something that can steal a > token from the client's local storage might also steal the associated > key. I forget if we ended up changing to some other phrasing or not, > though :( > > FP: Ok, will rephrase to “the RS authenticating itself” instead of “pop performed by the RS”. Also, what about using eavesdrop here instead? Eavesdrop may be too limited, as I think it's also in scope for the attack when an RS receives (whether legitimately or by deception) the token in question as the target of a CoAP request. > Section 4.1 > > 52. The client MUST generate a nonce N1 very unlikely to have been > previously used with the same input keying material. This profile > RECOMMENDS to use a 64-bit long random number as nonce. The client > > Why 64 instead of 128? I know that 128 is enough without having to > think about it; for 64 we have to be clear about what role the nonce is > serving. > > FP: We brought this up in the wg and everybody seemed to be ok with 64. We can go up to 128 if you think it’s better. Also consider that OSCORE appendix B2 has a similar setting and does some considerations about that, mentioning that "typically nonces of at least 8 bytes will be used". Maybe add a reference? > https://tools.ietf.org/html/rfc8613#page-72 I brought it up as one of the points the wg should agree on. > > 53. Note that the use of the payload and the Content-Format is different > from what described in section 5.8.1 of [I-D.ietf-ace-oauth-authz], > which only transports the token without any CBOR wrapping. In this > profile, the client MUST wrap the token and N1 in a CBOR map. The > client MUST use the Content-Format "application/ace+cbor" defined in > section 8.14 of [I-D.ietf-ace-oauth-authz]. The client MUST include > the access token using the correct CBOR label (e.g., "cwt" for CWT, > "jwt" for JWT) and N1 using the 'cnonce' parameter defined in section > 5.1.2 of [I-D.ietf-ace-oauth-authz]. > > That's not what the 'cnonce' parameter is for -- 'cnonce' is protecting > the RS against replay, but N1 is protecting the client. I think we need > to use a different name (and maybe define some integer map label > values?) for this authz-info POST body. > > FP: As mentioned, this was raised as an open point and ok by the wg (and particularly Ludwig and Jim). > > 54. The access token MUST be encrypted, since it is transferred from the > client to the RS over an unprotected channel. > > This is probably worth stating in Section 3.2 as well, where we discuss > the AS-to-C token response in more detail. > > FP: OK. > > 55. Note that a client may be required to re-POST the access token, since > an RS may delete a stored access token, due to lack of memory. > > I'd suggest using the phrase "at any time" and noting that the client > will detect this by receiving an AS Request Creation Hints message since > the RS treated the request as an Unauthorized Resource Request, perhaps: > > % Note that a client may be required to re-POST the access token in > % order to complete a request, since an RS may delete a stored access > % token at any time, for example due to all storage space being > % consumed. This situation is detected by the client when it receives > % an AS Request Creation Hints response. > > FP: OK. > > 56. Payload: > { > "access_token": h'a5037674656d7053656e73 ...' > (remainder of access token omitted for brevity)', > "cnonce": h'018a278f7faab55a' > } > > This does not appear to be using either a "cwt" label or "jwt" label, as > the second paragraph of the section would have us using. > > FP: OK. Will use "cwt". > > Section 4.2 > > 57. token. If the token is valid, the RS MUST respond to the POST > request with 2.01 (Created). If the token is valid but is associated > > We probably don't need to repeat the normative requirements from > the core framework with normative keywords again. > > FP: OK. > > 58. to claims that the RS cannot process (e.g., an unknown scope), or if > any of the expected parameters in the OSCORE_Security_Context is > > Hmm, "associated to claims that the RS cannot process" sounds like we're > telling the RS to abort if the token includes any unrecognized claims, > which IIUC is at odds with the OAuth 2.0 philosophy of ignoring > unrecognized parameters. (Hopefully someone will correct me if I'm > misremembering that.) > > FP: This paragraph is meant to mirror what specified in 5.8.1.1 of ace-oauth-authz: > If the claims cannot be obtained the RS MUST discard the token > and, in case of an interaction via the authz-info endpoint, return > an error message with a response code equivalent to the CoAP code > 4.00 (Bad Request). > Next, the RS MUST verify claims, if present, contained in the access > token. Errors are returned when claim checks fail, in the order of > priority of this list: Ah, maybe the ace framework diverges from oauth here and I misremembered. But is this behavior limited to "any of the four standard claims that have a value that cannot be processed" or does it also include "there was an unrecognized claim"? > 59. missing (e.g. any of the mandatory parameters from the AS), or if any > > nit: comma after "e.g.". > > FP: Done in PR > > 60. Additionally, the RS MUST generate a nonce N2 very unlikely to have > been previously used with the same input keying material, and send it > within the 2.01 (Created) response. The payload of the 2.01 > (Created) response MUST be a CBOR map containing the 'cnonce' > parameter defined in section 5.1.2 of [I-D.ietf-ace-oauth-authz], set > to N2. This profile RECOMMENDS to use a 64-bit long random number as > nonce. Moreover, if the OSCORE_Security_Context in the token did not > > As above, we need to use a different name than 'cnonce', as it's > performing a different role (this time, contributing entropy to the > master secret). (Also, if we change our recommendation about nonce > length above we should do so here as well, of course.) > > FP: OK, pending wg agreement, and OK. > > 61. contain a 'clientId' parameter, the RS MUST generate an identifier, > unique in the set of all its existing client identifiers, and send it > in a 'clientId' parameter in the CBOR map as a CBOR bstr. The RS MAY > generate and send a 'ClientId' identifier even though the > OSCORE_Security_Context contained such a parameter, in order to > guarantee the uniqueness of the client identifier. The RS MUST use > > I'm not sure I understand the case where the AS wouldn't be able to > guarantee uniqueness of ClientId, and wonder if we could simplify by > always having the AS make ID assignment. Is there some more > background/usage scenarios here that I'm missing? > > FP: No that's it. The case I was trying to cover is having several AS cover the same resource at the same RS. Then we would have to have them synchronized for uniqueness of ClientId. But yes. Agree on removing this mechanism. > > 62. When receiving an updated access token with updated authorization > information from the client (see section Section 3.1), it is > RECOMMENDED that the RS overwrites the previous token, that is only > the latest authorization information in the token received by the RS > is valid. This simplifies for the RS to keep track of authorization > information for a given client. > > [this same recommendation is already in the core framework] > > FP: OK, will remove normative text and reference framework. > > Section 4.3 > > 63. the 'clientId' in the CBOR map in the payload of the response. Then, > the client MUST set the Master Salt of the Security Context created > to communicate with the RS to the concatenation of salt, N1, and N2, > in this order: Master Salt = salt | N1 | N2, where | denotes byte > string concatenation, and where salt was received from the AS in > Section 3.2. The client MUST set the Master Secret and Recipient ID > > I think it's general best practice to use an injective mapping of the inputs > to the Master Salt value (i.e., length-prefixes for the various fields, since > there are no reserved octet values). > > FP: OK, using CBOR encoded bstr (or b64 if JSON is used) should fix that. > > 64. from the parameters received from the AS in Section 3.2. The client > MUST set the AEAD Algorithm, ID Context, HKDF, and Replay Window from > the parameters received from the AS in Section 3.2, if present. In > case these parameters are omitted, the default values are used as > described in section 3.2 of [I-D.ietf-core-object-security]. The > > Ah, okay; I'd asked about default values earlier. That said, if stock OSCORE > ever changes the defaults we'd have to come up with a compatibility story for > communication between old/new nodes. > > FP: Yes. Maybe adding a version number to this context structure? I think this is a good idea. It's hard to argue that a version number would be a bad idea, so that seems reasonable. > 65. client MUST set the Sender ID from the 'clientId in the 2.01 > (Created) response, if present; otherwise, the client MUST set the > Sender ID from the parameters received from the AS in Section 3.2. > > [As written, this has the clientId from the RS take precedence over the one > from the AS when both are present. I understand that the claimed > justification is for the RS to be able to enforce clientId uniqueness, but it > still feels risky, since the value from the RS is unauthenticated.] > > FP: Let's remove this mechanism. > > 66. If any of the expected parameters is missing (e.g. any of the > mandatory parameters from the AS, or the 'clientId', either received > from the AS or in the 2.01 (Created) response from the RS), the > client MUST stop the exchange, and MUST NOT derive the Security > Context. The client MAY restart the exchange, to get the correct > security material. > > I think this means "restart at the AS" but it's probably worth being very > explicit about it. > > FP: Yes, OK will clarify. > > Also, is there anything to be said about rate-limiting/backoff for persistent > missing parameters? > > FP: OK, will add a sentence about that. > > 67. After sending the 2.01 (Created) response, the RS MUST set the Master > Salt of the Security Context created to communicate with the client > to the concatenation of salt, N1, and N2, in this order: Master Salt > = salt | N1 | N2, where | denotes byte string concatenation, and > > [It might be worth breaking this computation off into a standalone piece of > text that applies to both C and RS, including the edits for injectivity.] > > FP: OK > > 68. where salt was received from the AS in Section 4.2. The RS MUST set > the Master Secret, Sender ID and Recipient ID from the parameters, > received from the client in the access token in Section 4.1 after > > nit: I'd place the emphasis more on "in the access token" or even "from the > AS" rather than "from the client" -- the RS/AS preestablished relationship is > what authenticates these values. > > FP: Done in PR: "from the AS forwarded by the client". > > 69. validation of the token as specified in Section 4.2. The RS MUST set > > Does Section 4.2 really say much about validation other than "RS MUST verify > the validity of the token"? > > FP: well, that and points to 5.8.1 of ace-oauth-authz. I pointed to the framework not to duplicate the reference, but we can do that if you think it’s best. I think I was just wondering if we should skip the Section-4.2 indirection and refer directly to the framework. What's in place now is okay, though. > 70. [I-D.ietf-core-object-security]. After that, the RS MUST derive the > complete Security Context following section 3.2.1 of > [I-D.ietf-core-object-security], and MUST associate this Security > Context with the authorization information from the access token. > > side note: it's sometimes useful as a rhetorical device to have a discussion > of the abstract data model the RS uses -- in this case, that it maintains a > collection of Security Contexts with associated authorization information, > for all the clients that it's currently communicating with, and that the > authorization information is policy that's used as input to processing > requests from those clients. Otherwise, this text about "MUST associate" can > be a bit vague to the reader. > > FP: OK, will add this clarification in this section. > > 71. The RS then uses this Security Context to verify the request and send > responses to C using OSCORE. If OSCORE verification fails, error > > (nit?) what is "the request"? I don't think we've talked about a specific > OSCORE request yet, so this would probably be better if talking about generic > incoming requests from a given client. > > FP: Done in PR: "verify requests and sends responses". > > 72. responses are used, as specified in section 8 of > [I-D.ietf-core-object-security]. Additionally, if OSCORE > verification succeeds, the verification of access rights is performed > as described in section Section 4.4. The RS MUST NOT use the > Security Context after the related token has expired, and MUST > respond with a unprotected 4.01 (Unauthorized) error message. > > nit: I suggest "MUST respond with an unprotected [...] error message to > requests received that correspond to a security context with an expired > token" to tie it back to which requests are affected. > > FP: Done in PR. > > 73. If the exchange was an update of access rights, i.e. a new Security > > nit: comma after "i.e.". > > FP: Done in PR. > > 74. Context was derived from a client that already had a Security Context > in place, the is RECOMMENDED to delete the old Security Context after > OSCORE verification and verification of access rights succeed. The > RS MUST delete the Security Context if it deletes the access token > associated to it. > > I'm not sure I understand what the workflow is, here -- I assume that the > deletion of the old security context occurs after a successful update via > the authz-info endpoint (as opposed to some particular OSCORE-protected > request), but I don't know what "verification of access rights" could be > performed at that time. Aren't access rights mostly tied to a specific > operation, or is this just supposed to be a more generic audience/scope > check? > > FP: The RS deletes the old token and the old security context only after successfully processing a request from the client, using the new token and security context. That includes OSCORE verification and also access rights verification, like any normal request. Is that not clear? How to make it clearer? It sounds like it's just my misreading: "OSCORE verification" clearly implies an OSCORE request (i.e., not the authz-info endpoint). > Section 4.4 > > 75. The RS MUST follow the procedures defined in section 5.8.2 of > [I-D.ietf-ace-oauth-authz]: if an RS receives an OSCORE-protected > request from a client, then the RS processes it according to > [I-D.ietf-core-object-security]. If OSCORE verification succeeds, > and the target resource requires authorization, the RS retrieves the > > nit(?): is it appropriate to say "requires additional authorization" (over > the implicit authorization given to any authenticated client)? I'm not sure > if that would be confusing or not. > > FP: I would think this is more confusing than clarifying because we don’t talk about implicit authorization in this document. We can make this change if other people agree that this formulation is better. Understood; leaving it as-is is okay. > 76. authorization information from the access token associated to the > Security Context. The RS then MUST verify that the authorization > information covers the resource and the action requested. > > In the vein of my previous note about an abstract data model, we may not want > to be overly prescriptive about "retrieves [...] from the access token". > Per-request introspection is allowed, as is caching the authorization > information in a non-token local datastore. > > FP: Ok, I understand but I am not sure how to implement this comment. “Retrieve” may be misinterpreted, but in my mind it can mean both by looking up caching info as well as introspecting. How to make this clearer? Would s/from/using/ work? > I'd also consider rephrasing to "MUST verify that the resource and action > requested are authorized", since "covers" is perhaps a little vague. > > FP: OK > > 77. The response code MUST be 4.01 (Unauthorized) in case the client has > not used the Security Context associated with the access token, or if > RS has no valid access token for the client. If RS has an access > > The causality here seems a bit weird; how would the RS know what token was > intended just from an OSCORE request that's using a random or different > security context? > > FP: The RS needs to keep this association between Security Context and token. This first section covers the case where the client is using a sec ctx not associated to any token or where that sec ctx was not used before (so the full OSCORE setup did not go through). Different (“valid”) security context associated to a token is covered in the next section. Is there anything I am missing here? I think I'm just complaining about the wording: if a request comes in using some other (wrong) security context, how does the RS know what the relevant "the access token" is for that request? > 78. token for the client but not for the resource that was requested, RS > MUST reject the request with a 4.03 (Forbidden). If RS has an access > > I'd suggest rephrasing this to be in terms of authorization rather than > "token for X", perhaps as "if the RS has an access token for the client but > no actions are authorized on the target resource" > > FP: OK > > 79. token for the client but it does not cover the action that was > requested on the resource, RS MUST reject the request with a 4.05 > (Method Not Allowed). > > Similarly, perhaps "but the requested action is not authorized". > > FP: OK > > Also, don't both of these descriptions have high overlap with Section 5.8.2 > of the core framework? Is it necessary to reiterate those behavior > specifications? > > FP: Yes, this whole second paragraph re-iterates that section. We can remove it, the only thing left will be to specify that “performed proof-of-possession” = “having an OSCORE security context established” > > Section 5 > > 80. Thank you for clearly stating that the OSCORE security contexts between RS/AS > and C/AS must be established independently of any of the mechanisms defined > in this document, and that the protocols used for the C/RS, C/AS, and RS/AS > steps can be selected independently. > > FP: Good that it's clear. > > 81. Furthermore the requesting entity and the AS communicate using OSCORE > ([I-D.ietf-core-object-security]) through the introspection endpoint > as specified in section 5.7 of [I-D.ietf-ace-oauth-authz] and through > the token endpoint as specified in section 5.6 of > [I-D.ietf-ace-oauth-authz]. > > I'm not entirely sure what this sentence is trying to say -- it comes across > a little bit as saying that when this document is in use, the indicated > interactions also use OSCORE, but that of course can't be what's actually > intended. Perhaps just saying that the behavior of the introspection > endpoing is specified in section 5.7 of [framework] and that of the token > endpoint is specified in section 5.6 of [framework] would suffice?'' > > FP: No, this sentence wanted to add to the previous (“if OSCORE is used”), and just point to the framework’s section for the specific behaviours. Will rephrase. > > Section 6 > > 82. o the client receives a number of 4.01 Unauthorized responses to > OSCORE requests using the same security context. The exact number > needs to be specified by the application. > > Is this a global counter or does it get reset by a successful OSCORE > response? > > FP: I would say this gets reset by a successful OSCORE response. But probably the application would have to define that as well. Do we need to add any text about this? Probably not, since this is a pretty typical class of behavior. If it was a global counter that never got reset that would be noteworthy. > 83. o the client receives a new nonce in the 2.01 (Created) response > (see Section 4.2) to a POST request to the authz-info endpoint, > when re-posting a non-expired token associated to the existing > context. > > Why is "non-expired" specifically relevant? > > FP: because if it’s expired the RS will not accept that token. This was just for clarification. > What about adding a parenthesis “(non-expired)”? Sure! > 84. The RS MUST discard the current security context associated with a > client when: > > o Sequence Number space ends. > > o Access token associated with the context expires. > > nit: we should make the grammar of the list elements parallel to the client's > list, so "the Sequence Number space ends." and "the access token associated > with the context expires". > > FP: Done in PR. > > Section 7 > > 85. We talk about both nonces as needing to be "very unlikely to have been > previously used", and it might be worth trying to quantify that (e.g., > "chance of inadvertent collision less than 2^-32"). > > FP: This is hard to quantify in a general case. But we can add some text about avoiding inadvertent collisions. > > 86. As alluded to in my high-level point, we should have more discussion of > the consequences of the authz-info exchange being completely > unprotected. > > FP: Let's discuss that in the point above. > > 87. a secure binding between the request and the response(s). Thus the > basic OSCORE protocol is not intended for use in point-to-multipoint > communication (e.g. multicast, publish-subscribe). Implementers of > > nit: comma after "e.g.". > > FP: Done in PR. > > 88. provoke re-use. If that is not guaranteed, nodes are still > susceptible to re-using AEAD nonces and keys, in case the Security > Context is lost, and on-path attacker replay messages. > > This text is talking about AEAD nonces, but the nonces (and 64-bit > recommendation) previously discussed are the nonces used in the Master Salt > (and thus Master Secret) calculation; we don't really talk about AEAD nonces > specifically anywhere in the document, other than to point out the risk of > (nonce, key) reuse. IIUC, vulnerable nodes would need to reuse both the > N1 or N2 values defined in this spec as well as the OSCORE partial IV in > order to collide the AEAD (nonce, key) pair (noting that both key and common > IV are influenced by the Master Salt). That said, if the N1 generation is > flawed it seems quite plausible that PIV generation is similarly flawed, so > we are right to document the concern. > Also, the grammar here is a little bit weird, so perhaps a rewording to: > > % provoke re-use. If that is not guaranteed, nodes are > % susceptible to re-use of AEAD (nonces, keys) pairs, especially since an on-path > % attacker can cause the client to use an arbitrary nonce for Security > % Context establishment. Even partial loss of Security Context information > % can allow an on-path attacker to replay messages. > > though I'm not entirely sure I understand which replay scenarios you had in > mind. > > FP: I think the last sentence in your rewording is partially changing the intent of the paragraph. Partial loss does not allow attacker to replay messages; what was meant by that is that, if the context is lost (think reboot without use of persistent memory, where partial IV could reset to previously used IVs, and node’s nonce resets to previously used nonce) and at the same time the attacker replays an old message (so second nonce is previously used too), that creates the problem. I would just remove the last sentence of your reworded paragraph and would be fine with that. Ah, right, so it's more like "Reuse of AEAD nonces and keys is also possible by replay of client-to-server messages when state is lost." (IIUC the replay attack and the "on-path attacker forces a nonce" case are attacking different protocol actors.) > 89. This profiles recommends that the RS maintains a single access token > > nit: "This profile" singular. > > FP: Done in PR. > > 90. Also, tokens may contradict each other which may lead the server to > enforce wrong permissions. If one of the access tokens expires > > Could you give me an example of the contradiction scenarios? I see the > "common" case as being roughly "Token T1 gives access to the set X of > resources and token T2 gives access to a partially disjoint set Y of > resources", but I don't know that such a scenario would be considered a > "conflict". To get a conflict I'd expect more like "token T1 indicates that > access to X is to be denied, but token T2 indicates that access to X is to be > allowed" with some sort of explicit negative ACL, but I don't think OAuth > really has a concept of negative ACL. > > FP: No, I meant what you describe as the common case. The contradiction coming from the fact that one token would give access to a set X of resource that the other token would not give access to. A server implementation might check only one token, which could lead to wrong permissions. Do we need to say anything else here? How would "if tokens indicate different or disjoint permissions from each other" work? > Section 8 > > 91. There might be a few more privacy considerations worth mentioning: > > - the token is sent in the clear to the authz-info endpoint, so if a single > token is used with multiple audiences or RSes, a client that uses the same > token from multiple locations can be tracked/correlated by the access > token's value. > > FP: OK > > - the nonces exchanged in the authz-info exchange are also sent in the clear, > so using random nonces is best for privacy (as opposed to, e.g., a counter, > that might leak some information). > > FP: OK > > - the identifiers clientId/serverId that are created/assigned for this > protocol have some privacy considerations; they overlap a lot with the core > OSCORE considerations in terms of the potential privacy consequences but > there might be a little more to say about guidelines for how the > identifiers are generated. If I'm reading OSCORE correctly, for the uses > specified in this document only the clientId will actually go on the wire? > > FP: that’s right, unless client and server swap roles, in which case also serverId (acting as client) could go on the wire. I thought OSCORE should have this covered. What additional details are missing here? >From memory the main new part is that the AS (a third party) is assigning the identifiers and has information that could (whether by malice or incompetence) aid in tracking the client/server. > - similarly, there may be considerations for the ID context values. > > FP: same, referencing OSCORE should cover it, no? Most likely. > Section 9.1 > > 92. o Profile Description: Profile for using OSCORE to secure > communication between constrained nodes using the Authentication > and Authorization for Constrained Environments framework. > > This is the registry for ACE profiles; "using the Authentication and > Authorization for Constrained Envirornments framework" feels redundant. > There's also perhaps something to say about defining "coap_oscore" for all > three interaction flows even though the procedures for two of the three are > essentially just "out of the scope of this specification", though having > *some* identifier for "use OSCORE" is probably still useful. > > FP: Ok, we can remove the last part. About the interaction flows between nodes, I am not sure what you mean, as by following definition https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-31#section-5.6.4.3 it is not mandatory for a profile to specify C-AS and RS-AS, those flows can be out of scope. Am I missing something? It's not mandatory, though given that we talk about profiles not being able to assume that the same profile is used for any/all of C/RS, C/AS, and RS/AS, I guess I assumed that we use the profile identifier to talk about the last two cases as well as the first one. Maybe I'm wrong to assume that! Regardless, I think the question here is whether we want to have people use the "coap_oscore" string to indicate that C/AS and/or RS/AS use OSCORE, or if that information is not expected to be encoded in any protocol element; if the latter, then there's nothing to change. > Section 9.2 > > 93. name The JSON name requested (e.g., "ms"). Because a core goal of > this specification is for the resulting representations to be > compact, it is RECOMMENDED that the name be short. This name is > case sensitive. Names may not match other registered names in a > case-insensitive manner unless the Designated Experts state that > there is a compelling reason to allow an exception. The name is > > nit: I'd suggest s/state/determine/ > > FP: Done in PR > > 94. CBOR label The value to be used to identify this algorithm. Key map > labels MUST be unique. The label can be a positive integer, a > > nit: s/Key map/Map key/ > > FP: Done in PR > > 95. negative integer or a string. Integer values between 0 and 255 > and strings of length 1 are designated as Standards Track Document > required. Integer values from 256 to 65535 and strings of length > 2 are designated as Specification Required. Integer values of > greater than 65535 and strings of length greater than 2 are > designated as expert review. Integer values less than -65536 are > marked as private use. > > So use of negative integers from -65535 to -1 and positive integers greater > than or equal to 65536 is not defined? > > FP: OK Right we missed it. We will fix it. > > I'd also consider listing [I-D.ietf-core-object-security] as an > additional reference for the initial entries, since that specifies the > actual semantics of the fields in question. > > FP: OK > > Section 9.3 > > 96. "OSCORE_Security_Context" feels like a somewhat long name in light of the > previous commentary about shorter names being preferred. :) > > FP: Typically this whole name should not be sent when CBOR is used (so in constrained environments). But we’ll shorten it, what about "Sec_Ctx"? There's no need to shorten it just on my account; as you note, it's generally going to be the CBOR tag that's used. > 97. o Confirmation Method Description: OSCORE_Security_Context carrying > the OSCORE Security Context parameters > > I'd suggest rewording the description to "parameters for using OSCORE > per-message security with implicit key confirmation" > > FP: Ok, still would like to keep OSCORE_Security_Context (or whatever the structure will be called) somewhere in the description. > > Section 9.4 > > 98. > > [same suggested rewording] > > FP: OK > > Section 9.5 > > 99. Thank you for indicating in which direction the various considerations should > sway the experts' decisions, as opposed to just what the experts should > consider. :) > > FP: good. > > 100. The IANA registry established in this document is defined as expert > review. This section gives some general guidelines for what the > > nit: I suggest "defined to use the Expert Review registration policy". > > FP: Done in PR > > 101 The zones tagged as private use are intended for testing purposes > and closed environments, code points in other ranges should not be > assigned for testing. > > nit: comma splice > > FP: TIL comme splices. Done in PR. > > 102. o Specifications are required for the standards track range of point > assignment. Specifications should exist for specification > required ranges, but early assignment before a specification is > available is considered to be permissible. Specifications are > > side note: this is a little awkward, as RFC 7120 formally does not allow > "early allocations" for the "Expert Review" policy, so there is not a formal > procedure in place to review and expire early allocations that end up not > being needed. It might be worth something to chat with the IANA table about > in Vancouver. > > FP: Sure, we will check with IANA. We got inspired by (read shamelessly stole from) COSE here. > > Section 10.2 > > 103. We might get some sticklers asking for the terminology references to be made > normative, but I'm not concerned about it one way or the other for now. > > FP: OK, will keep in mind. > > Appendix A > > 104. Thank you for assembling this in list form for me. > Do we expect to keep this content in the final RFC? If we do, we should > resynchronize to the current list in Appendix C of the framework :) > > FP: Definitely should resynchronize. Yes I’d like this content to stay. > > 105. o how/if the authz-info endpoint is protected: Security protocol > above > > I thought authz-info was fully unprotected, per Section 4.1's "The authz-info > endpoint is not protected, nor are the responses from this resource." > > FP: OK, will fix. Thanks for working through all the comments! -Ben From nobody Mon Feb 3 02:16: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 22E051200F7 for ; Mon, 3 Feb 2020 02:16:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.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 EL82cMR7rIAs for ; Mon, 3 Feb 2020 02:15:57 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150075.outbound.protection.outlook.com [40.107.15.75]) (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 8387712002E for ; Mon, 3 Feb 2020 02:15:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jMWgHAEeAY7EetqNmy0JjFL5hY4KBYfL1nruXTYp9tHi1HIGLuBJbVSKPMggSjisdqg+yVAJefnpFk6tPiZGGxyNYI0OIfkOn8ts0rDzcJ9anx3zfhW4vqxIcmcHHVEoGDlyAC43WOACZ5K2veYcc0Axr8WlABwVoZW4PlXWwiveQwezp7xH79oCO0H8K/DEzIK9LLpll9qcH/jtvP8HdnSKRUhU78OIIMl1EtJRDZDDEdcF9o+yxwsg6iBkJFbOvX1Q95ZbU+jCgmYfJ3KuE7iFCd3aDv/ht/Vlem1eUuaDl9NKh41s6gvSGSNtAl+/8w9Y6oqvK1MmfdbUMFegyg== 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=JuYfFtE1vQzBraRqFeoGgfM4dhXKDgkbJWi/Y+eHgq8=; b=eRnQxs+8uQeKxvoV8kxbMnc3Y0CY4yegPL787mRZ2BAlTX27VmefsQCr+EPueyEd7/7kIVC3sBTk3UHUpb1jcDGMjGsEidpcCSDYyyc6QmFTvoMGU623R0ppd7xWI5+XFA2iT6KzmKS+YFLuEXcFVSOlNsKaXxG0MTgd/DXxvy3R1I1l0iPUzbvCu1h/2DcXCdfOCEW3Gx04kPpd7kk1+chPs33YDsrvH67INXj0m/jwdE9vd0jTzC9ElL03CdoV55aL1FU0VR4HBEPlH5Z2Wh/crrODxoFn176YUBeLN7sGMGZ9nPFO4/nEJAM18NXjDtmmBvnGS+GWQRbHAEN8xw== 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=RISEcloud.onmicrosoft.com; s=selector1-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JuYfFtE1vQzBraRqFeoGgfM4dhXKDgkbJWi/Y+eHgq8=; b=sP1cHFLTuJ02f+vk36FzPTkVnu8F16HAwd4743hDaTt0veLivxgRlkA1uyiDwrJ7sx1Z4LqyMrfVqT3fCSQ6eHMBfYVuItRj622a2mvr6hnm8SKWxT2RyHTqzDgtlr8zFGlW6ZFfsNu6wv8HssziV32QASJ4KiFOON+p8Grdm4Q= Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (10.165.195.159) by VI1P189MB0399.EURP189.PROD.OUTLOOK.COM (10.165.189.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.30; Mon, 3 Feb 2020 10:15:55 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::80e4:7dc7:7d4e:c9cb]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::80e4:7dc7:7d4e:c9cb%4]) with mapi id 15.20.2686.031; Mon, 3 Feb 2020 10:15:55 +0000 Received: from [10.8.0.25] (213.232.87.96) by AM3PR07CA0080.eurprd07.prod.outlook.com (2603:10a6:207:6::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.11 via Frontend Transport; Mon, 3 Feb 2020 10:15:55 +0000 From: Marco Tiloca To: Ace Wg Thread-Topic: [ace] key-groupcomm-oscore - Key material from the Group Manager Thread-Index: AQHV2nrrC3d3Bzv100aTigGyl9Q3pQ== Date: Mon, 3 Feb 2020 10:15:55 +0000 Message-ID: <1342d583-32f9-3d22-a1eb-13d68d485aaf@ri.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-clientproxiedby: AM3PR07CA0080.eurprd07.prod.outlook.com (2603:10a6:207:6::14) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) authentication-results: spf=none (sender IP is ) smtp.mailfrom=marco.tiloca@ri.se; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [213.232.87.96] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9f34b37b-6a32-4b89-2d35-08d7a8920e25 x-ms-traffictypediagnostic: VI1P189MB0399: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0302D4F392 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39850400004)(396003)(366004)(376002)(136003)(346002)(189003)(199004)(5660300002)(26005)(16576012)(16526019)(316002)(86362001)(186003)(6486002)(8936002)(81156014)(8676002)(81166006)(956004)(966005)(66946007)(2616005)(2906002)(66574012)(31696002)(36756003)(66616009)(478600001)(66476007)(66446008)(64756008)(66556008)(71200400001)(6916009)(44832011)(52116002)(31686004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P189MB0399; H:VI1P189MB0398.EURP189.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ri.se does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: iXzD3YP8751hPjLfQQ9TQOSO3hSUss3T9ZUIT/tzsenDzs52PgdTHDTSnboXLUR6Xf46CR0sgIi7ZeVvNfNX40gjLOp2R25lrecpXiOPQ8veDc9VlTetgqXuqTi+jWAVRnHf6mPk/OSzRKJCAFilaYECWBzzUFImg0rqTfcz9e7eqeXJ3PwZI0Zc8q5yMSlOlRkf1BKyUE5HZfHXDiMz2aBF8Ae1z41/ZtlfiQ7o04tzsfbXPIHHF2eol9XBenq4nu4pa8aRkW8P1LB7iqSxUzLpppfhcGhgXoCFT+TNlMsA+XmLYBHeO31VZEMMJoA2zzWFskh7NPmn3pIxH87yvWsHV2fjui27FVu49seRc3lzuOEQ/IHIa99hEYQ/UT+sA5ofUGoMb0fPtxQduTWbMgTE7KfMDdS+TzxPp9Oa2ty84G19yUHLFWz/YWHNf+4kC14CGEfczL1/T6sYvnldTmH3+EOm62ODNjCKvlFBm6CqPg+Hy+/1ZL7pGLZ494tTWRP6pg5ZbmLTOVX3EAPeRw== x-ms-exchange-antispam-messagedata: 0i12fRZw8sJp7xBPhV+IbtoAk9pm92L4jbCPJRIQ6Z7UJL+r9QSSGOtdfMuUCXICerubJesWzKpAYtMXhX4O2LPwI+Q2g0O3IJb5SAarwgFiYp5dZzLA5OyBQLkbaV1nchEijGtjRe1NZf4qDoSHmg== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="XJ2Uot0hsuOvleASOv7TzB6HQDpmdt3mf" MIME-Version: 1.0 X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 9f34b37b-6a32-4b89-2d35-08d7a8920e25 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2020 10:15:55.3143 (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: hpWR9ghx9e4G50SPzQ5C/OEgG+HV0u5xZ1TvBm/jXNGIWK9gPYd619cCvs1aJhSBQVEBUaaSiCut9VM/G8Odyg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0399 Archived-At: Subject: [Ace] [ace] key-groupcomm-oscore - Key material from the Group Manager 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, 03 Feb 2020 10:16:00 -0000 --XJ2Uot0hsuOvleASOv7TzB6HQDpmdt3mf Content-Type: multipart/mixed; boundary="EeNf4nfSQ1W2XvwBt1Xuwos3VTAPflL0K" --EeNf4nfSQ1W2XvwBt1Xuwos3VTAPflL0K Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hello ACE, Here I elaborate more on the open point #3 that I raised during the interim meeting on Friday, 31st of January --- see slide 5 at [1]. According to the API defined in ace-key-groupcomm , a group member can issue the following two requests to the Group Manager: (A) GET to /group-oscore/GROUPNAME This is intended to retrieve the latest group key material, i.e. what is pertinent to all group members as related to the group [2]. (B) GET to /group-oscore/GROUPNAME/NODENAME This is intended to retrieve the latest group key material - as in (A) - , plus the latest individual key material for the requesting node. In this profile, the individual key material is the Sender ID that that node uses in the group [3]. As I mentioned at the interim, now both (A) and (B) practically return the same thing. In fact: 1) Both (A) and (B) return the parameters 'gkty', 'key' and 'num'. 2) Both in (A) and (B), the 'key' parameter includes 'clientId', which specifies the Sender ID of the requesting node, just implicitly reusing the detailed description of the 'key' content in [4]. That is, (A) currently goes beyond what is actually intended by the general interface of ace-key-groupcomm , i.e. it returns more information than intended. A fix can simply be clarifying the specific content of 'key' in [2], i.e. explicitly saying to not include 'clientId' in the 'key' parameter for responses from the GET in (A). Thoughts? Thanks, /Marco [1] https://datatracker.ietf.org/meeting/interim-2020-ace-02/materials/slides= -interim-2020-ace-02-sessa-draft-ietf-ace-key-groupcomm-oscore [2] https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore-04#sectio= n-6.1 [3] https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore-04#sectio= n-6.2 [4] https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore-04#sectio= n-4.4 --=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 --EeNf4nfSQ1W2XvwBt1Xuwos3VTAPflL0K-- --XJ2Uot0hsuOvleASOv7TzB6HQDpmdt3mf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl438tUACgkQ7iZktA5Y 2kOZuggAhQwEUZI3E4YbbRuv8/C0BnJYAN0+pDZhNOWDBlngTM20wLZ41Bbur26c eEy6QwXL2/7dnNKdMMKHNsvdaDr92t12h5cfGIaSkxk7OBXbJk0xab1P01VHieMv cCbeMErxfsRuOxXjTAG+yGZjd4OSz0nne/Zrg6snohf64aPZRwEeI3ZEfGzT4sTU VblXAyZogJjJk6RiW5FcumtWxcNBrAPj1S595Gc7TOBxZAUYPQOZXDVuBjuSj3LP sqfZqEQDPVKY1AI1f3esCvCISqMqLetc4jOKVZH2DmYYu2aJibiVFiDNsZm6xuBj R1OC16pbGSWfuHaXAKknrHFhJ6p5JA== =codE -----END PGP SIGNATURE----- --XJ2Uot0hsuOvleASOv7TzB6HQDpmdt3mf-- From nobody Mon Feb 3 09:28: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 CD28B1200B2; Sat, 1 Feb 2020 02:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdnzElbeakw7; Sat, 1 Feb 2020 02:20:51 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 A9EBD12003E; Sat, 1 Feb 2020 02:20:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1580552405; bh=+98nkYhsM8Mr4Rl88bRrvtEGeOSdwlbUv/dZn9zeTtk=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=ac2IwGDTbjq/SxOEqkZTwsTwVaXVZv34VtzbqBA6x4DCYf5816gtS9fjX83C4rLnW DBO5LRU8Z4DavfNKQJwaTbibTghR7EM92qBdS3CzqkQCUMsKF3xk2lFG1FDJxMqsKs 5l77ExekOsCaNmbBBCCQeza5TxJwNuEsYhorDulY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.220] ([84.217.44.37]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MCKFk-1ipcgh1HOM-009Lzb; Sat, 01 Feb 2020 11:20:05 +0100 To: Brian Campbell , Seitz Ludwig Cc: Roman Danyliw , "oauth-ext-review@ietf.org" , Daniel Migault , jwt-reg-review@ietf.org, Jim Schaad , Benjamin Kaduk , "ace@ietf.org" , "drafts-lastcall@iana.org" References: <9c32d171-9a4a-ba71-c989-92a177d9e989@gmx.de> <77781da882414f4aae98ae2443691933@combitech.se> <582bfd3fbdee4cc592b92857c955721b@combitech.se> From: Ludwig Seitz Message-ID: Date: Sat, 1 Feb 2020 11:19:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:98plQ3KHndAmhMho4cyvFCidvdNNzvmGBTmagVCAt/8BIq9Reot fdmQRB13HQohugWMTM1+vZvyA1AjTXSgcMlaI/yhKAKqGsSlNdfkkje3JK6P88U+kccp9nU o2O+t/AGnb8fKmnDYZBhDhxgxKT/07dHXlcDQsrpP9UlbbgSFRUkpKeTCqnCV1CmTWs8nuu U5/DgMS3PeQlJb7swFT6A== X-UI-Out-Filterresults: notjunk:1;V03:K0:lbUaxRfFmfk=:18lNccsdZj3Fwr3n7l57iM hXu5aWRW9bei4NvhCkBaOCVk3x1SpTBsTf7SvxZlP07RrIKIIweQq4yPrqjfCYw4xxUZWIoFb kO7AxnMWNhCopi0cQEHG2Svcdeq6N/6/1Zj3aOie85NhbYNKHv2Z3jAxp8iME6lpsXmzhn9jU DouokzmPW5uYcfZPiN+eIxdpt9T6CKGkd2rEceHptCaH/W59ZXT/zPLi9VtGdP465V1j6ogrB b4llrr0hrBnk0XqhWZ9EQCZhyrxeUVL6dmX4gHg1NjJeI7csVerHNraJCdm5bIuOG3LdQo+aI 0nY5DrrMO43BlvSLiZ3VnbR2NPH3C7hBsIft1sUJDRi5es4l905HsC658bBcn+xP6qe8DCJeB /dEWmeOo7MhHabAbLRJXW12J5KrjFxOuuaHDWWsWLPmvQ8RI2bOwOLQx6sDapbRWYJykXlZ1V Ol7rNsnWVfeozwG473Gsz8FSsmuDhpgrgKBF85aSuN6AgRLUxpE5SoRjdTtSz0WoE+Hbq1FNV foFJzZhhLUsvk5x56PhYNbvj8NiVq7mcazw1McWIpws1eDCMpJq/meIs9ydEURJ0WOx7X8mMp oae6jd4pmdhn3gb5O0gWPbLGOWXpHw8gc7adp1iF7N/Fx5DO3bZDwktuzEg8DHTbgJfdRZ0g2 LGd6YkPZAyBSd/cGAkeXpYqZCBRdXonPYBpEZddXQ45nhOnLvNg9rY8kih/FGx/o+ttlGnwli fSsFRNtmT79lR1S8UFUMbsFSa6GGnJgwIlEskERhQFTsJSci6+Sq8mk6VSfJxv/nC3PUOzlW5 iQLQWLjfZbiN2VMsHS1OLMbGiqvXeysf59GqBLyRPfdJKhpYuTtw8TJ8dqfZYb0cmFnbzswie 8s9HiSUlSzSyCmx/aKTpyjmwGRu/YytdIh4GbxDBH1kyBqWJX0dmGR9KfEpVWp/6hwHrgHUw8 CH0+7jd+48jAu7ptHGk09itNlQd4lCdVyc3ceZEZ0BFiu6MtQdmQkaEuNL7VJpt8cgk/6ns7m rPItm3KhzH95dqw6zAxUkieZAVoUvWDkNi1+PB8FJyB9BCi6K5TKzX9myalxzCF6hZ0ZbG5Hv jgG5RFT+wiP0Vw9+maZf0plMIGQJwlGH6jzHwMFt2Uha0QRnK05qVf1fBoI+GOeU+4HDWtmku 47AAq2nL3pemF6r31bZq2qtRf4Dff5WuDlgwm+mYstDP2FYH/M91ugm0sfdJ/1GJVyhkcfdlU KEOsXVHeehKDO4YpG Archived-At: X-Mailman-Approved-At: Mon, 03 Feb 2020 09:28:10 -0800 Subject: Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params 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, 01 Feb 2020 10:20:52 -0000 On 2020-01-23 22:31, Brian Campbell wrote: > Apologies, I forgot to reply-all at some earlier point and dropped the > mailing lists and other cc's off the thread. Added back now. > > And also apologies because I think I need to recuse myself from the DE > responsibility on the JWT registry request here. I've spent more time > than I'd like to admit or really have to spare on it and am still > struggling to understand. > > I appreciate you pointing out the authz-info endpoint in ACE but I still > don't follow how "rs_cnf" in an access token would really work in > practice. The client sends the token to the RS's authz-info endpoint on > an insecure connection or one that has the server auth with potentially > different key and the RS stores the access token for later use. Then on > resource access the RS looks up the access token (with respect to the > cnf key in it) based on the key the client used in establishing a new > mutually authentication connection to the RS. For the RS to choose a key > for server it will use during the handshake (and as far as I know the > server key is the first in the authn process of the handshake) based on > the "rs_cnf" in the access token, it needs to remember and associate > that client and the access token with something else (IP address?) that > will be available during the handshake. It doesn't fit together for me > in a way that seems likely to work or be interoperable but, like I said, > I'm really struggling to understand. > > Hello Brian, thank you for your efforts in reviewing the IANA registrations. As for your struggling to understand, we should have struggled more, since there was indeed a flaw in the reasoning behind the rs_cnf claim (and introspection parameter). As a result of that we will remove both the rs_cnf claim and the introspection parameter, keeping only the rs_cnf token endpoint parameter, which I believe still makes sense. Background: When introducing the rs_cnf claim, we had mistakenly assumed that the RS could associate the token with the ongoing (D)TLS handshake at the time the server certificate message is to be created, this is not the case and the rs_cnf claim is therefore useless (same goes for the rs_cnf introspection parameter). Instead I will require that a RS MUST NOT hold more than one asymmetric key pair based on the same algorithm, used for authentication. Thus the (D)TLS algorithm negotiation in the handshake should resolve the issue of which key to use for the RS. Updates of both draft-ietf-ace-oauth-params and draft-ietf-ace-oauth-authz coming soon. /Ludwig From nobody Tue Feb 4 15:30: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 E0132120144 for ; Tue, 4 Feb 2020 14:11:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=pingidentity.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 JQXIBF39ykHS for ; Tue, 4 Feb 2020 14:11:46 -0800 (PST) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36A7812003F for ; Tue, 4 Feb 2020 14:11:46 -0800 (PST) Received: by mail-lj1-x229.google.com with SMTP id y6so310570lji.0 for ; Tue, 04 Feb 2020 14:11:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JwvSUkEMbZvggNIJsoUpuCiOrRYiKmx3sYeGDaATt1w=; b=Fv+zoITne3MQGLc5x4JrDdLL08hYaA0juabrVcG/esoi4MEAkyM1l3lgOn9eVVFa15 UctTMJqZHYRo5N/pNUvQF5wBuElLKIQ297mKNC5QENI1xNjfHwR7QCHw0sWlPZ4yJ/jc hOAj6qZB+1p4Vd6sjIbB5HjFUNjnKlog7JUnJiLgnpBRvpEWfSB6Ri3nDSXBwRcAok9A hLWtWX5TvvHjcCPDp/k5+A5DgUIesQHoSnp/ORjF0IzCsOwoewgv0qvuzlbcV2jtRAr+ ll6jhSW/YGhA5xyxPse8g9vS0PH3WjXPVVI/PEwTr3dtkTubPj09XwRM2TzHBXes74kU vyOA== 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:cc; bh=JwvSUkEMbZvggNIJsoUpuCiOrRYiKmx3sYeGDaATt1w=; b=JrXIJg4eE82ui2AlwrvLfYES4bVWisypgz3Y8UIJhENH6UIVva6Mo+ckl/QsJmphZn ZdSDy3Se0sXxwKJKMdf5uDluwwFUhrWg61OHvPBUkN9xm3yeSv/7LV0U6s1l8t47gr1Q 8N+JUdJYr15rZe4/xew7hTGovF/sUF01DZYHZA7yeIk3OkLqkVAJ1bpOkrqK0a0F6VhE kk0WahCgLS/FUla0jpFOspsfcvUnCzDHFaXr9t9ePVP/4D1qP7Uqu2by3bA8nVaunW5w NqOxxuDAk3sPv08n07Zd5s73x1rQz1ewAXtH47SHoJopkntP1qd3ZJbYZPEm33HACcGp 0cow== X-Gm-Message-State: APjAAAWmxw/1EEKo+SjKTsQ+7ueQ3D9R4qd9gBx4ow5opBEKwjS/Xc3c 4YS+kR3XjtFSyvTckkgHJ3lvdfGbDTHN8rpc3pDVPUEPEdE3qyympoDpGQPqx9ZsYmQ1wUcS+j7 /dU+b7gq+PrxcLDZ1 X-Google-Smtp-Source: APXvYqyZ0Ixe1gfT97p19mldWc2T3m1+dzkQI56yuYE4bXhrL5tLeoKZbecpYYGBqHHCE5XpCvhEqj1aYPAWeuLp9+U= X-Received: by 2002:a2e:7009:: with SMTP id l9mr18355663ljc.96.1580854304435; Tue, 04 Feb 2020 14:11:44 -0800 (PST) MIME-Version: 1.0 References: <9c32d171-9a4a-ba71-c989-92a177d9e989@gmx.de> <77781da882414f4aae98ae2443691933@combitech.se> <582bfd3fbdee4cc592b92857c955721b@combitech.se> In-Reply-To: From: Brian Campbell Date: Tue, 4 Feb 2020 15:11:18 -0700 Message-ID: To: Ludwig Seitz Cc: Seitz Ludwig , Roman Danyliw , "oauth-ext-review@ietf.org" , Daniel Migault , jwt-reg-review@ietf.org, Jim Schaad , Benjamin Kaduk , "ace@ietf.org" , "drafts-lastcall@iana.org" Content-Type: multipart/alternative; boundary="000000000000420a8f059dc75364" Archived-At: X-Mailman-Approved-At: Tue, 04 Feb 2020 15:30:05 -0800 Subject: Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params 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, 04 Feb 2020 22:11:49 -0000 --000000000000420a8f059dc75364 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Ludwig, That does alleviate the concerns/confusion I had regarding the rs_cnf claim. On Sat, Feb 1, 2020 at 3:20 AM Ludwig Seitz wrote: > On 2020-01-23 22:31, Brian Campbell wrote: > > Apologies, I forgot to reply-all at some earlier point and dropped the > > mailing lists and other cc's off the thread. Added back now. > > > > And also apologies because I think I need to recuse myself from the DE > > responsibility on the JWT registry request here. I've spent more time > > than I'd like to admit or really have to spare on it and am still > > struggling to understand. > > > > I appreciate you pointing out the authz-info endpoint in ACE but I stil= l > > don't follow how "rs_cnf" in an access token would really work in > > practice. The client sends the token to the RS's authz-info endpoint on > > an insecure connection or one that has the server auth with potentially > > different key and the RS stores the access token for later use. Then on > > resource access the RS looks up the access token (with respect to the > > cnf key in it) based on the key the client used in establishing a new > > mutually authentication connection to the RS. For the RS to choose a ke= y > > for server it will use during the handshake (and as far as I know the > > server key is the first in the authn process of the handshake) based on > > the "rs_cnf" in the access token, it needs to remember and associate > > that client and the access token with something else (IP address?) that > > will be available during the handshake. It doesn't fit together for me > > in a way that seems likely to work or be interoperable but, like I said= , > > I'm really struggling to understand. > > > > > > Hello Brian, > > thank you for your efforts in reviewing the IANA registrations. > As for your struggling to understand, we should have struggled more, > since there was indeed a flaw in the reasoning behind the rs_cnf claim > (and introspection parameter). As a result of that we will remove both > the rs_cnf claim and the introspection parameter, keeping only the > rs_cnf token endpoint parameter, which I believe still makes sense. > > Background: When introducing the rs_cnf claim, we had mistakenly assumed > that the RS could associate the token with the ongoing (D)TLS handshake > at the time the server certificate message is to be created, this is not > the case and the rs_cnf claim is therefore useless (same goes for the > rs_cnf introspection parameter). Instead I will require that a RS MUST > NOT hold more than one asymmetric key pair based on the same algorithm, > used for authentication. Thus the (D)TLS algorithm negotiation in the > handshake should resolve the issue of which key to use for the RS. > > Updates of both draft-ietf-ace-oauth-params and > draft-ietf-ace-oauth-authz coming soon. > > > /Ludwig > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000420a8f059dc75364 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Ludwig,

That doe= s alleviate the concerns/confusion I had regarding the rs_cnf claim.=C2=A0 =

On Sat, Feb 1, 2020 at 3:20 AM Ludwig Seitz <ludwig_seitz@gmx.de> wrote:
On 2020-01-23 22:31, Brian Campbel= l wrote:
> Apologies, I forgot to reply-all at some earlier point and dropped the=
> mailing lists and other cc's off the thread. Added back now.
>
> And also apologies because I think I need to recuse myself from the DE=
> responsibility on the JWT registry request here. I've spent more t= ime
> than I'd like to admit or really have to spare on it and am still<= br> > struggling to understand.
>
> I appreciate you pointing out the authz-info endpoint in ACE but I sti= ll
> don't follow how "rs_cnf" in an access token would reall= y work in
> practice. The client sends the token to the RS's authz-info endpoi= nt on
> an insecure connection or one that has the server auth with potentiall= y
> different key and the RS stores the access token for later use. Then o= n
> resource access the RS looks up the access token (with respect to the<= br> > cnf key in it) based on the key the client used in establishing a new<= br> > mutually authentication connection to the RS. For the RS to choose a k= ey
> for server it will use during the handshake (and as far as I know the<= br> > server key is the first in the authn process of the handshake) based o= n
> the "rs_cnf" in the access token, it needs to remember and a= ssociate
> that client and the access token with something else (IP address?) tha= t
> will be available during the handshake. It doesn't fit together fo= r me
> in a way that seems likely to work or be interoperable but, like I sai= d,
> I'm really struggling to understand.
>
>

Hello Brian,

thank you for your efforts in reviewing the IANA registrations.
As for your struggling to understand, we should have struggled more,
since there was indeed a flaw in the reasoning behind the rs_cnf claim
(and introspection parameter). As a result of that we will remove both
the rs_cnf claim and the introspection parameter, keeping only the
rs_cnf token endpoint parameter, which I believe still makes sense.

Background: When introducing the rs_cnf claim, we had mistakenly assumed that the RS could associate the token with the ongoing (D)TLS handshake
at the time the server certificate message is to be created, this is not the case and the rs_cnf claim is therefore useless (same goes for the
rs_cnf introspection parameter).=C2=A0 Instead I will require that a RS MUS= T
NOT hold more than one asymmetric key pair based on the same algorithm,
used for authentication.=C2=A0 Thus the (D)TLS algorithm negotiation in the=
handshake should resolve the issue of which key to use for the RS.

Updates of both draft-ietf-ace-oauth-params and
draft-ietf-ace-oauth-authz coming soon.


/Ludwig

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000420a8f059dc75364-- From nobody Thu Feb 6 09:51:18 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 0BE22120851 for ; Thu, 6 Feb 2020 09:51:15 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 4UhCFnPCf4NQ for ; Thu, 6 Feb 2020 09:51:10 -0800 (PST) Received: from sjmda10.webex.com (sjmda10.webex.com [64.68.124.127]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56154120843 for ; Thu, 6 Feb 2020 09:51:10 -0800 (PST) Received: from rva2rmd102.webex.com (sjc02-wxpd-lb03-v140.webex.com [10.252.16.111]) by sjmda10.webex.com (Postfix) with ESMTP id 0F61230744B3 for ; Thu, 6 Feb 2020 17:51:10 +0000 (GMT) Received: from rva2rmd102.webex.com (localhost [127.0.0.1]) by rva2rmd102.webex.com (Postfix) with ESMTP id B38AF10526CD for ; Thu, 6 Feb 2020 17:51:09 +0000 (GMT) Date: Thu, 6 Feb 2020 17:51:09 +0000 (GMT) From: ACE Working Group Reply-To: ace-chairs@ietf.org To: ace@ietf.org Message-ID: <1020534943.5238481581011469732.JavaMail.nobody@rva2rmd102.webex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1047688_650537669.1581011469732" X-Priority: 3 Importance: normal X-WBX-INFO: X-WBX-SID=456680, X-WBX-CID=152360891817405798, X-WBX-TID=4u71yv42czyvmrthom92lsejkizi6lcgl0ds0avk9gabanoew632hs8g, X-WBX-RID=537fd16889cf45a28f284585df639099, X-WBX-SVC:Meeting Center, X-WBX-TT:Meeting Invitation, Date:Thu Feb 06 17:51:09 GMT 2020 reminder-39.11.0-2724 Archived-At: Subject: [Ace] Webex meeting invitation: ACE interim meeting 2 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, 06 Feb 2020 17:51:15 -0000 ------=_Part_1047688_650537669.1581011469732 Content-Type: multipart/Alternative; boundary="----=_Part_1047689_1350382790.1581011469732" ------=_Part_1047689_1350382790.1581011469732 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhpLCBhY2VAaWV0Zi5vcmcsCgpBQ0UgV29ya2luZyBHcm91cCBpbnZpdGVzIHlvdSB0byBqb2lu IHRoaXMgV2ViZXggbWVldGluZy4KCgpBQ0UgaW50ZXJpbSBtZWV0aW5nIDIKRnJpZGF5LCBGZWJy dWFyeSAyOCwgMjAyMAo4OjAwIGFtICB8ICAoVVRDLTA1OjAwKSBFYXN0ZXJuIFRpbWUgKFVTICYg Q2FuYWRhKSAgfCAgMSBocgpNZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiA2NDkgNjk3IDk3 NSAKTWVldGluZyBwYXNzd29yZDogNjNQYWpNQUEKCgoKV2hlbiBpdCdzIHRpbWUsIGpvaW4gdGhl IG1lZXRpbmcuCmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW0xZTk2YWMz NDUzODVmZjQwNmZjYzA2MmE0MzgyY2ZlNgoKQWRkIHRvIENhbGVuZGFyCmh0dHBzOi8vaWV0Zi53 ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW01YjZkZDBkOTQyNGZiMDVmNmY0ZGZkYjc2ODhiYzBk Zg0KDQoKCg0KSk9JTiBCWSBQSE9ORQ0KMS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJl ciAoVVMvQ2FuYWRhKQpUYXAgaGVyZSB0byBjYWxsIChtb2JpbGUgcGhvbmVzIG9ubHksIGhvc3Rz IG5vdCBzdXBwb3J0ZWQpOiB0ZWw6JTJCMS02NTAtNDc5LTMyMDgsLCowMSo2NDk2OTc5NzUlMjMl MjMqMDEqCg0KDQoKSk9JTiBGUk9NIEEgVklERU8gU1lTVEVNIE9SIEFQUExJQ0FUSU9OCkRpYWwg c2lwOjY0OTY5Nzk3NUBpZXRmLndlYmV4LmNvbQpZb3UgY2FuIGFsc28gZGlhbCAxNzMuMjQzLjIu NjggYW5kIGVudGVyIHlvdXIgbWVldGluZyBudW1iZXIuCgoKSm9pbiB1c2luZyBNaWNyb3NvZnQg THluYyBvciBNaWNyb3NvZnQgU2t5cGUgZm9yIEJ1c2luZXNzCkRpYWwgc2lwOjY0OTY5Nzk3NS5p ZXRmQGx5bmMud2ViZXguY29tCgoKQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz8KaHR0cHM6Ly9jb2xs YWJvcmF0aW9uaGVscC5jaXNjby5jb20vYXJ0aWNsZS9XQlgwMDAwMjkwNTUKCgpJTVBPUlRBTlQg Tk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViZXggc2VydmljZSBhbGxvd3MgYXVkaW8g YW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29y ZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2lu aW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29y ZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5 b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uCg== ------=_Part_1047689_1350382790.1581011469732 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PHN0eWxlIHR5cGU9InRleHQvY3NzIj4KKiB7CiAgICBwYWRkaW5nOiAwOyAgICBtYXJnaW46IDA7 fQp0YWJsZSB7Cglib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyB3aWR0aCA9MTAwJTsJYm9yZGVy OiAwOwlib3JkZXItc3BhY2luZzogMDt9Cgp0ciB7CglsaW5lLWhlaWdodDogMThweDt9CgphLCB0 ZCB7Cglmb250LXNpemU6IDE0cHg7CWZvbnQtZmFtaWx5OiBBcmlhbDsJY29sb3I6ICMzMzM7CXdv cmQtd3JhcDogYnJlYWstd29yZDsJd29yZC1icmVhazogbm9ybWFsOwlwYWRkaW5nOiAwO30KCi50 aXRsZSB7Cglmb250LXNpemU6IDI4cHg7fQoKLmltYWdlIHsKCXdpZHRoOiBhdXRvOwltYXgtd2lk dGg6IGF1dG87fQoKLmZvb3RlciB7Cgl3aWR0aDogNjA0cHg7fQoKLm1haW4gewoKfUBtZWRpYSBz Y3JlZW4gYW5kIChtYXgtZGV2aWNlLXdpZHRoOiA4MDBweCkgewoJLnRpdGxlIHsKCQlmb250LXNp emU6IDIycHggIWltcG9ydGFudDsJfQoJLmltYWdlIHsKCQl3aWR0aDogYXV0byAhaW1wb3J0YW50 OwkJbWF4LXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CX0KCS5mb290ZXIgewoJCXdpZHRoOiAxMDAl ICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6IDYwNHB4ICFpbXBvcnRhbnQKCX0KCS5tYWluIHsKCQl3 aWR0aDogMTAwJSAhaW1wb3J0YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1wb3J0YW50Cgl9Cn0K PC9zdHlsZT4KCjx0YWJsZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0icGFkZGluZzogMDsgbWFy Z2luOiAwOyBib3JkZXI6IDA7IHdpZHRoOiAxMDAlOyIgYWxpZ249ImxlZnQiPgoJPHRyIHN0eWxl PSJoZWlnaHQ6IDI4cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+Cgk8dHI+CgkJPHRkIGFsaWduPSJs ZWZ0IiBzdHlsZT0icGFkZGluZzogMCAyMHB4OyBtYXJnaW46IDAiPgoJCQk8IS0tPHRhYmxlIGJn Y29sb3I9IiNGRkZGRkYiIHN0eWxlPSJib3JkZXI6IDBweDsgd2lkdGg6IDEwMCU7IHBhZGRpbmct bGVmdDogNTBweDsgcGFkZGluZy1yaWdodDogNTBweDsiIGFsaWduPSJsZWZ0IiBjbGFzcz0ibWFp biI+CgkJCQk8dHI+CgkJCQkJPHRkIGFsaWduPSJjZW50ZXIiIHZhbGlnbj0idG9wIiA+Jm5ic3A7 CQkJCQk8L3RkPgoJCQkJPC90cj4KCQkJPC90YWJsZT4tLT4KCgo8dGFibGU+CiAgICAgICA8dHI+ CiAgICAgICAgICAgPHRkIHN0eWxlPSJoZWlnaHQ6IDIycHg7Y29sb3I6ICMwMDAwMDA7Zm9udC1m YW1pbHk6IEFyaWFsOwlmb250LXNpemU6IDE2cHg7Zm9udC13ZWlnaHQ6IGJvbGQ7bGluZS1oZWln aHQ6IDIycHg7Ij4KICAgICAgICAgICAgICAgIEFDRSBXb3JraW5nIEdyb3VwIGludml0ZXMgeW91 IHRvIGpvaW4gdGhpcyBXZWJleCBtZWV0aW5nLgogICAgICAgICAgICAgICAgCSAgICAgICAgICAg PC90ZD4KICAgICAgPC90cj4KPC90YWJsZT4KCgo8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdo dDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxl PgoKICAgIDx0YWJsZSBzdHlsZT0id2lkdGg6YXV0bzsgd2lkdGg6YXV0byFpbXBvcnRhbnQ7Ij4K ICAgICAgICA8dHI+CiAgICAgICAgICAgIDx0ZCBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsOyBj b2xvcjogIzAwMDAwMDsgZm9udC1zaXplOiAxNnB4OyBsaW5lLWhlaWdodDogMjJweDsiPgogICAg ICAgICAgICAgICAgTWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogNjQ5IDY5NyA5NzUKICAg ICAgICAgICAgPC90ZD4KICAgICAgICA8L3RyPgogICAgPC90YWJsZT4KICAgIDx0YWJsZSBzdHls ZT0id2lkdGg6YXV0bzsgd2lkdGg6YXV0byFpbXBvcnRhbnQiPgogICAgICAgIDx0ciA+CiAgICAg ICAgICAgIDx0ZCBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogIzAwMDAwMDsgZm9u dC1zaXplOiAxNnB4OyBsaW5lLWhlaWdodDogMjJweDsiPk1lZXRpbmcgcGFzc3dvcmQ6IDYzUGFq TUFBPC90ZD4KICAgICAgICA8L3RyPgogICAgPC90YWJsZT4KICAgICAgICAKPHRhYmxlPjx0ciBz dHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8 L3RkPjwvdHI+PC90YWJsZT4KCiAgICA8dGFibGUgIHdpZHRoPSIxMDAlIj4KICAgICAgICA8dHIg c3R5bGU9Im1hcmdpbjowcHg7Y29sb3I6ICM2NjY2NjY7Zm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQt c2l6ZTogMTRweDtsaW5lLWhlaWdodDogMjJweDsiPgogICAgICAgICAgICA8dGQgc3R5bGU9Im1h cmdpbjowcHg7Y29sb3I6ICM2NjY2NjY7Zm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTRw eDtsaW5lLWhlaWdodDogMjJweDsiPkZyaWRheSwgRmVicnVhcnkgMjgsIDIwMjAKICAgICAgICAg ICAgPC90ZD4KICAgICAgICA8L3RyPgogICAgICAgIDx0ciBzdHlsZT0ibWFyZ2luOjBweDtjb2xv cjogIzY2NjY2Njtmb250LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0 OiAyMnB4OyI+CiAgICAgICAgICAgIDx0ZCBzdHlsZT0ibWFyZ2luOjBweDtjb2xvcjogIzY2NjY2 Njtmb250LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0OiAyMnB4OyI+ ODowMCBhbSZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDsoVVRDLTA1OjAwKSBFYXN0ZXJuIFRpbWUg KFVTICYgQ2FuYWRhKSZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDsxIGhyCiAgICAgICAgICAgIDwv dGQ+CiAgICAgICAgPC90cj4KICAgIDwvdGFibGU+CgogPEZPTlQgc2l6ZT0iMiIgQ09MT1I9IiNG RjAwMDAiIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7Ij48L0ZPTlQ+CgogICAgCgoJCQk8dGFi bGUgc3R5bGU9InBhZGRpbmctYm90dG9tOiA0cHg7Zm9udC1mYW1pbHk6IEFyaWFsOyI+PHRyIHN0 eWxlPSJsaW5lLWhlaWdodDogMjBweCI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90 ZD48L3RyPjwvdGFibGU+CgkJCTx0YWJsZSBzdHlsZT0nd2lkdGg6YXV0bzt3aWR0aDphdXRvIWlt cG9ydGFudDsnPjx0cj48dGQgc3R5bGU9J3dpZHRoOmF1dG8haW1wb3J0YW50OyAnPjx0YWJsZSBi b3JkZXI9JzAnIGNlbGxwYWRkaW5nPScwJyBjZWxsc3BhY2luZz0nMCcgc3R5bGU9J3dpZHRoOmF1 dG87d2lkdGg6YXV0byFpbXBvcnRhbnQ7IGJhY2tncm91bmQtY29sb3I6IzQzQTk0MjsgYm9yZGVy OjBweCBzb2xpZCAjNDNBOTQyOyBib3JkZXItcmFkaXVzOjIwcHg7IG1pbi13aWR0aDoxNjBweCFp bXBvcnRhbnQ7Jz48dGJvZHk+PHRyPjx0ZCBhbGlnbj0nY2VudGVyJyBzdHlsZT0ncGFkZGluZzox MHB4IDM2cHg7Zm9udC1mYW1pbHk6IEFyaWFsOyc+PGEgaHJlZj0naHR0cHM6Ly9pZXRmLndlYmV4 LmNvbS9pZXRmL2oucGhwP01USUQ9bTFlOTZhYzM0NTM4NWZmNDA2ZmNjMDYyYTQzODJjZmU2JyBz dHlsZT0nY29sb3I6I0ZGRkZGRjsgZm9udC1zaXplOjIwcHg7IHRleHQtZGVjb3JhdGlvbjpub25l Oyc+Sm9pbiBtZWV0aW5nPC9hPjwvdGQ+PC90cj48L3Rib2R5PjwvdGFibGU+PC90ZD48L3RyPjwv dGFibGU+CgkJCTx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiA0OHB4Ij48dGQgc3R5bGU9 ImhlaWdodDo0OHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCgoJPHRhYmxlPjx0Ym9keT48 dHI+PHRkIHN0eWxlPSJjb2xvcjogIzAwMDAwMDtmb250LWZhbWlseTogQXJpYWw7IGZvbnQtc2l6 ZTogMTJweDsgZm9udC13ZWlnaHQ6IGJvbGQ7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+PGI+Sm9pbiBi eSBwaG9uZTwvYj48L3RkPjwvdHI+PHRyPjx0ZCBzdHlsZT0iY29sb3I6ICM5OTk5OTk7Zm9udC1m YW1pbHk6IEFyaWFsOyBmb250LXNpemU6IDEycHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+VGFwIHRv IGNhbGwgaW4gZnJvbSBhIG1vYmlsZSBkZXZpY2UgKGF0dGVuZGVlcyBvbmx5KTwvdGQ+PC90cj48 dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZCBzdHlsZT0iY29sb3I6ICMzMzMzMzM7Zm9udC1mYW1p bHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTRweDtsaW5lLWhlaWdodDogMjRweDsiPjxhIGhyZWY9J3Rl bDolMkIxLTY1MC00NzktMzIwOCwsKjAxKjY0OTY5Nzk3NSUyMyUyMyowMSonIHN0eWxlPSdjb2xv cjojMDBBRkY5OyAgdGV4dC1kZWNvcmF0aW9uOm5vbmU7IGZvbnQtZmFtaWx5OiBBcmlhbDtmb250 LXNpemU6IDE0cHg7bGluZS1oZWlnaHQ6IDI0cHg7Jz4xLTY1MC00NzktMzIwODwvYT4mbmJzcDs8 c3BhbiBzdHlsZT0iY29sb3I6ICMzMzMzMzM7Ij5DYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5h ZGEpPC9zcGFuPjwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZCBzdHlsZT0iZm9u dC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTRweDtsaW5lLWhlaWdodDogMjRweDsiPjwvdGQ+ PC90cj48L3Rib2R5PjwvdGFibGU+PHRhYmxlIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0i MCI+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjhweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjI4cHgi PiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoJPHRhYmxlPjx0cj48dGQgIHN0eWxlPSJjb2xvcjog IzAwMDAwMDsgZm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTJweDsgZm9udC13ZWlnaHQ6 IGJvbGQ7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+PGI+Sm9pbiBmcm9tIGEgdmlkZW8gc3lzdGVtIG9y IGFwcGxpY2F0aW9uPC9iPjwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZCBzdHls ZT0iY29sb3I6ICMzMzMzMzM7IGZvbnQtZmFtaWx5OiBBcmlhbDsgZm9udC1zaXplOiAxNHB4OyBs aW5lLWhlaWdodDogMjRweDsiPkRpYWwgPGEgaHJlZj0iIHNpcDo2NDk2OTc5NzVAaWV0Zi53ZWJl eC5jb20iICAgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2NvbG9yOiMwMEFGRjkiPjY0OTY5 Nzk3NUBpZXRmLndlYmV4LmNvbTwvYT48L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48 dGQgc3R5bGU9ImNvbG9yOiAjMzMzMzMzOyBmb250LWZhbWlseTogQXJpYWw7IGZvbnQtc2l6ZTog MTRweDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij5Zb3UgY2FuIGFsc28gZGlhbCAxNzMuMjQzLjIuNjgg YW5kIGVudGVyIHlvdXIgbWVldGluZyBudW1iZXIuPC90ZD48L3RyPjwvdGFibGU+PHRhYmxlPjx0 ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJz cDs8L3RkPjwvdHI+PC90YWJsZT4KICAgIDx0YWJsZSBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNp bmc9IjAiPjx0cj48dGQgIHN0eWxlPSJjb2xvcjogIzAwMDAwMDsgZm9udC1mYW1pbHk6IEFyaWFs O2ZvbnQtc2l6ZTogMTJweDsgZm9udC13ZWlnaHQ6IGJvbGQ7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+ PGI+Sm9pbiB1c2luZyBNaWNyb3NvZnQgTHluYyBvciBNaWNyb3NvZnQgU2t5cGUgZm9yIEJ1c2lu ZXNzPC9iPjwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZCBzdHlsZT0iY29sb3I6 ICMzMzMzMzM7IGZvbnQtZmFtaWx5OiBBcmlhbDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdo dDogMjRweDsiPkRpYWwgPGEgaHJlZj0iIHNpcDo2NDk2OTc5NzUuaWV0ZkBseW5jLndlYmV4LmNv bSIgICBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Y29sb3I6IzAwQUZGOSI+NjQ5Njk3OTc1 LmlldGZAbHluYy53ZWJleC5jb208L2E+PC90ZD48L3RyPjwvdGFibGU+CgoJCQk8dGFibGUgc3R5 bGU9IndpZHRoOiAxMDAlOyIgYWxpZ249ImxlZnQiIGNsYXNzPSJtYWluIj4KICAgICAgICAgICAg ICAgIDx0ciBzdHlsZT0iaGVpZ2h0OiA3MnB4Ij48dGQ+Jm5ic3A7PC90ZD48L3RyPgoJCQkJPHRy PgoJCQkJCTx0ZCBzdHlsZT0iaGVpZ2h0OiAyNHB4OyBjb2xvcjogIzAwMDAwMDsgZm9udC1mYW1p bHk6QXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij5OZWVkIGhlbHA/ IEdvIHRvIDxhIGhyZWY9Imh0dHA6Ly9oZWxwLndlYmV4LmNvbSIgc3R5bGU9ImNvbG9yOiMwNDlG RDk7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+aHR0cDovL2hlbHAud2ViZXguY29tPC9hPgoJCQkJ CTwvdGQ+CgkJCQk8L3RyPgogICAgICAgICAgICAgICAgPHRyIHN0eWxlPSJoZWlnaHQ6IDQ0cHgi Pjx0ZD4mbmJzcDs8L3RkPjwvdHI+CgkJCTwvdGFibGU+CgkJPC90ZD4KCTwvdHI+CjwvdGFibGU+ Cg== ------=_Part_1047689_1350382790.1581011469732 Content-Type: text/calendar;method=REQUEST;charset=utf-8; Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkFtZXJpY2EvTmV3X1lvcmsNClRaVVJMOmh0dHA6Ly90enVybC5vcmcvem9u ZWluZm8tb3V0bG9vay9BbWVyaWNhL05ld19Zb3JrDQpYLUxJQy1MT0NBVElPTjpBbWVyaWNhL05l d19Zb3JrDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOi0wNTAwDQpUWk9GRlNFVFRPOi0w NDAwDQpUWk5BTUU6RURUDQpEVFNUQVJUOjE5NzAwMzA4VDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFS TFk7QllNT05USD0zO0JZREFZPTJTVQ0KRU5EOkRBWUxJR0hUDQpCRUdJTjpTVEFOREFSRA0KVFpP RkZTRVRGUk9NOi0wNDAwDQpUWk9GRlNFVFRPOi0wNTAwDQpUWk5BTUU6RVNUDQpEVFNUQVJUOjE5 NzAxMTAxVDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFSTFk7QllNT05USD0xMTtCWURBWT0xU1UNCkVO RDpTVEFOREFSRA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpEVFNUQU1QOjIwMjAwMjA2 VDE3NTEwOVoNCkFUVEVOREVFO0NOPSJhY2VAaWV0Zi5vcmciO1JPTEU9UkVRLVBBUlRJQ0lQQU5U O1JTVlA9VFJVRTpNQUlMVE86YWNlQGlldGYub3JnDQpPUkdBTklaRVI7Q049IkFDRSBXb3JraW5n IEdyb3VwIjpNQUlMVE86YWNlLWNoYWlyc0BpZXRmLm9yZw0KRFRTVEFSVDtUWklEPUFtZXJpY2Ev TmV3X1lvcms6MjAyMDAyMjhUMDgwMDAwDQpEVEVORDtUWklEPUFtZXJpY2EvTmV3X1lvcms6MjAy MDAyMjhUMDkwMDAwDQpMT0NBVElPTjpodHRwczovL2lldGYud2ViZXguY29tL2lldGYNClRSQU5T UDpPUEFRVUUNClNFUVVFTkNFOjE1ODEwMTE0NjkNClVJRDo0YTFmNGJiNC05ZTE2LTQ4ZDktYjMw MC1jNjA1ZjdiNzQ1OWQNCkRFU0NSSVBUSU9OOlxuXG5cblxuSk9JTiBXRUJFWCBNRUVUSU5HXG5o dHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tMWU5NmFjMzQ1Mzg1ZmY0MDZm Y2MwNjJhNDM4MmNmZTZcbk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDY0OSA2OTcgOTc1 XG5cblxuTWVldGluZyBwYXNzd29yZDogNjNQYWpNQUFcblxuXG5cbkpPSU4gQlkgUEhPTkVcbjEt NjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSlcblRhcCBoZXJlIHRv IGNhbGwgKG1vYmlsZSBwaG9uZXMgb25seSwgaG9zdHMgbm90IHN1cHBvcnRlZCk6IHRlbDolMkIx LTY1MC00NzktMzIwOCwsKjAxKjY0OTY5Nzk3NSUyMyUyMyowMSpcblxuXG5cbkpPSU4gRlJPTSBB IFZJREVPIFNZU1RFTSBPUiBBUFBMSUNBVElPTlxuRGlhbCBzaXA6NjQ5Njk3OTc1QGlldGYud2Vi ZXguY29tXG5Zb3UgY2FuIGFsc28gZGlhbCAxNzMuMjQzLjIuNjggYW5kIGVudGVyIHlvdXIgbWVl dGluZyBudW1iZXIuXG5cblxuSm9pbiB1c2luZyBNaWNyb3NvZnQgTHluYyBvciBNaWNyb3NvZnQg U2t5cGUgZm9yIEJ1c2luZXNzXG5EaWFsIHNpcDo2NDk2OTc5NzUuaWV0ZkBseW5jLndlYmV4LmNv bVxuXG5cblxuQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz9cbmh0dHBzOi8vY29sbGFib3JhdGlvbmhl bHAuY2lzY28uY29tL2FydGljbGUvV0JYMDAwMDI5MDU1XG5cblxuSU1QT1JUQU5UIE5PVElDRTog UGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYmV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhl ciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hp Y2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlz IHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJ ZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25j ZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLlxuDQpYLUFMVC1E RVNDO0ZNVFRZUEU9dGV4dC9odG1sOjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+XG4qIHtcbiAgICBw YWRkaW5nOiAwOyAgICBtYXJnaW46IDA7fVxudGFibGUge1xuCWJvcmRlci1jb2xsYXBzZTogc2Vw YXJhdGU7IHdpZHRoID0xMDAlOwlib3JkZXI6IDA7CWJvcmRlci1zcGFjaW5nOiAwO31cblxudHIg e1xuCWxpbmUtaGVpZ2h0OiAxOHB4O31cblxuYSwgdGQge1xuCWZvbnQtc2l6ZTogMTRweDsJZm9u dC1mYW1pbHk6IEFyaWFsOwljb2xvcjogIzMzMzsJd29yZC13cmFwOiBicmVhay13b3JkOwl3b3Jk LWJyZWFrOiBub3JtYWw7CXBhZGRpbmc6IDA7fVxuXG4udGl0bGUge1xuCWZvbnQtc2l6ZTogMjhw eDt9XG5cbi5pbWFnZSB7XG4Jd2lkdGg6IGF1dG87CW1heC13aWR0aDogYXV0bzt9XG5cbi5mb290 ZXIge1xuCXdpZHRoOiA2MDRweDt9XG5cbi5tYWluIHtcblxufUBtZWRpYSBzY3JlZW4gYW5kICht YXgtZGV2aWNlLXdpZHRoOiA4MDBweCkge1xuCS50aXRsZSB7XG4JCWZvbnQtc2l6ZTogMjJweCAh aW1wb3J0YW50Owl9XG4JLmltYWdlIHtcbgkJd2lkdGg6IGF1dG8gIWltcG9ydGFudDsJCW1heC13 aWR0aDogMTAwJSAhaW1wb3J0YW50Owl9XG4JLmZvb3RlciB7XG4JCXdpZHRoOiAxMDAlICFpbXBv cnRhbnQ7CQltYXgtd2lkdGg6IDYwNHB4ICFpbXBvcnRhbnRcbgl9XG4JLm1haW4ge1xuCQl3aWR0 aDogMTAwJSAhaW1wb3J0YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1wb3J0YW50XG4JfVxufVxu PC9zdHlsZT5cblxuPHRhYmxlIGJnY29sb3I9IiNGRkZGRkYiIHN0eWxlPSJwYWRkaW5nOiAwOyBt YXJnaW46IDA7IGJvcmRlcjogMDsgd2lkdGg6IDEwMCU7IiBhbGlnbj0ibGVmdCI+XG4JPHRyIHN0 eWxlPSJoZWlnaHQ6IDI4cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JPHRyPlxuCQk8dGQgYWxp Z249ImxlZnQiIHN0eWxlPSJwYWRkaW5nOiAwIDIwcHg7IG1hcmdpbjogMCI+XG4JCQk8IS0tPHRh YmxlIGJnY29sb3I9IiNGRkZGRkYiIHN0eWxlPSJib3JkZXI6IDBweDsgd2lkdGg6IDEwMCU7IHBh ZGRpbmctbGVmdDogNTBweDsgcGFkZGluZy1yaWdodDogNTBweDsiIGFsaWduPSJsZWZ0IiBjbGFz cz0ibWFpbiI+XG4JCQkJPHRyPlxuCQkJCQk8dGQgYWxpZ249ImNlbnRlciIgdmFsaWduPSJ0b3Ai ID4mbmJzcDsJCQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJCTwvdGFibGU+LS0+XG5cblxuXG5cblxu CQkJPHRhYmxlPlxuCQkJCTx0cj5cbgkJCQkJPHRkPlxuCQkJCQkJPEZPTlQgU0laRT0iNCIgQ09M T1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5XaGVuIGl0J3MgdGltZSwgam9pbiB0aGUgV2ViZXgg bWVldGluZyBoZXJlLjwvRk9OVD5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJCTx0ciBzdHls ZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3Rk PjwvdHI+XG4JCQkJPHRyPlxuCQkJCQk8dGQ+XG4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0i IzY2NjY2NiIgRkFDRT0iYXJpYWwiPk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDY0OSA2 OTcgOTc1PC9GT05UPlxuCQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4JCQk8L3RhYmxlPlxuCQkJXG4J CQk8dGFibGU+PHRyPjx0ZD48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJp YWwiPk1lZXRpbmcgcGFzc3dvcmQ6PC9GT05UPjwvdGQ+PHRkPjxGT05UIFNJWkU9IjIiICBDT0xP Uj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjYzUGFqTUFBPC9GT05UPjwvdGQ+PC90cj48L3RhYmxl PlxuXG4gICAgICAgIDx0YWJsZT5cbiAgICAgICAgCTx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIw cHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+XG4JCQk8dHI+XG4J CQkJPHRkIHN0eWxlPSJ3aWR0aDphdXRvIWltcG9ydGFudDsgIj5cbgkJCQkJPHRhYmxlIGJvcmRl cj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIiBzdHlsZT0id2lkdGg6YXV0bzt3 aWR0aDphdXRvIWltcG9ydGFudDtiYWNrZ3JvdW5kLWNvbG9yOiM0M0E5NDI7IGJvcmRlcjowcHgg c29saWQgIzQzQTk0MjsgYm9yZGVyLXJhZGl1czoyNXB4OyBtaW4td2lkdGg6MTYwcHghaW1wb3J0 YW50OyI+XG4JCQkJCQk8dHI+XG4JCQkJCQkJPHRkIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJwYWRk aW5nOjEwcHggMzZweDsiPjxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBo cD9NVElEPW0xZTk2YWMzNDUzODVmZjQwNmZjYzA2MmE0MzgyY2ZlNiIgc3R5bGU9ImNvbG9yOiNG RkZGRkY7IGZvbnQtc2l6ZToyMHB4OyB0ZXh0LWRlY29yYXRpb246bm9uZTsiPkpvaW4gbWVldGlu ZzwvYT48L3RkPlxuCQkJCQkJPC90cj5cbgkJCQkJPC90YWJsZT5cbgkJCQk8L3RkPlxuCQkJPC90 cj5cbgkJPC90YWJsZT5cblxuIDxGT05UIHNpemU9IjIiIENPTE9SPSIjRkYwMDAwIiBzdHlsZT0i Zm9udC1mYW1pbHk6IEFyaWFsOyI+PC9GT05UPlxuPEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwi PiZuYnNwOzxCUj4mbmJzcDs8QlI+PC9GT05UPlxuXG4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjQi IEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpFPSIzIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwi PkpvaW4gYnkgcGhvbmU8L0ZPTlQ+ICZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2 NjY2NjYiIEZBQ0U9ImFyaWFsIj48Yj48YSBocmVmPSd0ZWw6JTJCMS02NTAtNDc5LTMyMDgsLCow MSo2NDk2OTc5NzUlMjMlMjMqMDEqJyBzdHlsZT0nY29sb3I6IzAwQUZGOTsgIHRleHQtZGVjb3Jh dGlvbjpub25lOyBmb250LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0 OiAyNHB4Oyc+MS02NTAtNDc5LTMyMDg8L2E+PC9iPiBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9D YW5hZGEpPC9GT05UPiAmbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBG QUNFPSJhcmlhbCI+PC9GT05UPiZuYnNwOyA8QlI+PEJSPjxCUj5cblxuPHRhYmxlPjx0ciBzdHls ZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3Rk PjwvdHI+PC90YWJsZT5cblxuPEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9 IjMiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBmcm9tIGEgdmlkZW8gc3lzdGVt IG9yIGFwcGxpY2F0aW9uPC9GT05UPjxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIg RkFDRT0iYXJpYWwiPkRpYWw8L0ZPTlQ+IDxhIGhyZWY9InNpcDo2NDk2OTc5NzVAaWV0Zi53ZWJl eC5jb20iPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJhcmlhbCI+NjQ5Njk3 OTc1QGlldGYud2ViZXguY29tPC9GT05UPjwvYT4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENP TE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+WW91IGNhbiBhbHNvIGRpYWwgMTczLjI0My4yLjY4 IGFuZCBlbnRlciB5b3VyIG1lZXRpbmcgbnVtYmVyLjwvRk9OVD4gJm5ic3A7IDxCUj48L0ZPTlQ+ Jm5ic3A7IDxCUj5cblxuPHRhYmxlIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCI+PHRy Pjx0ZCAgc3R5bGU9ImNvbG9yOiAjMDAwMDAwOyBmb250LWZhbWlseTogQXJpYWw7Zm9udC1zaXpl OiAxMnB4OyBmb250LXdlaWdodDogYm9sZDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij48Yj5Kb2luIHVz aW5nIE1pY3Jvc29mdCBMeW5jIG9yIE1pY3Jvc29mdCBTa3lwZSBmb3IgQnVzaW5lc3M8L2I+PC90 ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkIHN0eWxlPSJjb2xvcjogIzMzMzMzMzsg Zm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6IDE0cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+ RGlhbCA8YSBocmVmPSIgc2lwOjY0OTY5Nzk3NS5pZXRmQGx5bmMud2ViZXguY29tIiAgIHN0eWxl PSJ0ZXh0LWRlY29yYXRpb246bm9uZTtjb2xvcjojMDBBRkY5Ij42NDk2OTc5NzUuaWV0ZkBseW5j LndlYmV4LmNvbTwvYT48L3RkPjwvdHI+PC90YWJsZT5cblxuCQkJPHRhYmxlIHN0eWxlPSJ3aWR0 aDogMTAwJTsiIGFsaWduPSJsZWZ0IiBjbGFzcz0ibWFpbiI+XG4gICAgICAgICAgICAgICAgPHRy IHN0eWxlPSJoZWlnaHQ6IDcycHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JCQkJPHRyPlxuCQkJ CQk8dGQgc3R5bGU9ImhlaWdodDogMjRweDsgY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFtaWx5OkFy aWFsOyBmb250LXNpemU6IDE0cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+TmVlZCBoZWxwPyBHbyB0 byA8YSBocmVmPSJodHRwOi8vaGVscC53ZWJleC5jb20iIHN0eWxlPSJjb2xvcjojMDQ5RkQ5OyB0 ZXh0LWRlY29yYXRpb246bm9uZTsiPmh0dHA6Ly9oZWxwLndlYmV4LmNvbTwvYT5cbgkJCQkJPC90 ZD5cbgkJCQk8L3RyPlxuICAgICAgICAgICAgICAgIDx0ciBzdHlsZT0iaGVpZ2h0OiA0NHB4Ij48 dGQ+Jm5ic3A7PC90ZD48L3RyPlxuCQkJPC90YWJsZT5cbgkJPC90ZD5cbgk8L3RyPlxuPC90YWJs ZT5cbg0KU1VNTUFSWTpBQ0UgaW50ZXJpbSBtZWV0aW5nIDINClBSSU9SSVRZOjUNCkNMQVNTOlBV QkxJQw0KQkVHSU46VkFMQVJNDQpUUklHR0VSOi1QVDVNDQpBQ1RJT046RElTUExBWQ0KREVTQ1JJ UFRJT046UmVtaW5kZXINCkVORDpWQUxBUk0NCkVORDpWRVZFTlQNCkVORDpWQ0FMRU5EQVINCg== ------=_Part_1047689_1350382790.1581011469732-- ------=_Part_1047688_650537669.1581011469732 Content-Type: application/octet-stream; name="Webex_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Webex_Meeting.ics" QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkFtZXJpY2EvTmV3X1lvcmsNClRaVVJMOmh0dHA6Ly90enVybC5vcmcvem9u ZWluZm8tb3V0bG9vay9BbWVyaWNhL05ld19Zb3JrDQpYLUxJQy1MT0NBVElPTjpBbWVyaWNhL05l d19Zb3JrDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOi0wNTAwDQpUWk9GRlNFVFRPOi0w NDAwDQpUWk5BTUU6RURUDQpEVFNUQVJUOjE5NzAwMzA4VDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFS TFk7QllNT05USD0zO0JZREFZPTJTVQ0KRU5EOkRBWUxJR0hUDQpCRUdJTjpTVEFOREFSRA0KVFpP RkZTRVRGUk9NOi0wNDAwDQpUWk9GRlNFVFRPOi0wNTAwDQpUWk5BTUU6RVNUDQpEVFNUQVJUOjE5 NzAxMTAxVDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFSTFk7QllNT05USD0xMTtCWURBWT0xU1UNCkVO RDpTVEFOREFSRA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpEVFNUQU1QOjIwMjAwMjA2 VDE3NTEwOVoNCkFUVEVOREVFO0NOPSJhY2VAaWV0Zi5vcmciO1JPTEU9UkVRLVBBUlRJQ0lQQU5U O1JTVlA9VFJVRTpNQUlMVE86YWNlQGlldGYub3JnDQpPUkdBTklaRVI7Q049IkFDRSBXb3JraW5n IEdyb3VwIjpNQUlMVE86YWNlLWNoYWlyc0BpZXRmLm9yZw0KRFRTVEFSVDtUWklEPUFtZXJpY2Ev TmV3X1lvcms6MjAyMDAyMjhUMDgwMDAwDQpEVEVORDtUWklEPUFtZXJpY2EvTmV3X1lvcms6MjAy MDAyMjhUMDkwMDAwDQpMT0NBVElPTjpodHRwczovL2lldGYud2ViZXguY29tL2lldGYNClRSQU5T UDpPUEFRVUUNClNFUVVFTkNFOjE1ODEwMTE0NjkNClVJRDo0YTFmNGJiNC05ZTE2LTQ4ZDktYjMw MC1jNjA1ZjdiNzQ1OWQNCkRFU0NSSVBUSU9OOlxuXG5cblxuSk9JTiBXRUJFWCBNRUVUSU5HXG5o dHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tMWU5NmFjMzQ1Mzg1ZmY0MDZm Y2MwNjJhNDM4MmNmZTZcbk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDY0OSA2OTcgOTc1 XG5cblxuTWVldGluZyBwYXNzd29yZDogNjNQYWpNQUFcblxuXG5cbkpPSU4gQlkgUEhPTkVcbjEt NjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSlcblRhcCBoZXJlIHRv IGNhbGwgKG1vYmlsZSBwaG9uZXMgb25seSwgaG9zdHMgbm90IHN1cHBvcnRlZCk6IHRlbDolMkIx LTY1MC00NzktMzIwOCwsKjAxKjY0OTY5Nzk3NSUyMyUyMyowMSpcblxuXG5cbkpPSU4gRlJPTSBB IFZJREVPIFNZU1RFTSBPUiBBUFBMSUNBVElPTlxuRGlhbCBzaXA6NjQ5Njk3OTc1QGlldGYud2Vi ZXguY29tXG5Zb3UgY2FuIGFsc28gZGlhbCAxNzMuMjQzLjIuNjggYW5kIGVudGVyIHlvdXIgbWVl dGluZyBudW1iZXIuXG5cblxuSm9pbiB1c2luZyBNaWNyb3NvZnQgTHluYyBvciBNaWNyb3NvZnQg U2t5cGUgZm9yIEJ1c2luZXNzXG5EaWFsIHNpcDo2NDk2OTc5NzUuaWV0ZkBseW5jLndlYmV4LmNv bVxuXG5cblxuQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz9cbmh0dHBzOi8vY29sbGFib3JhdGlvbmhl bHAuY2lzY28uY29tL2FydGljbGUvV0JYMDAwMDI5MDU1XG5cblxuSU1QT1JUQU5UIE5PVElDRTog UGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYmV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhl ciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hp Y2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlz IHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJ ZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25j ZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLlxuDQpYLUFMVC1E RVNDO0ZNVFRZUEU9dGV4dC9odG1sOjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+XG4qIHtcbiAgICBw YWRkaW5nOiAwOyAgICBtYXJnaW46IDA7fVxudGFibGUge1xuCWJvcmRlci1jb2xsYXBzZTogc2Vw YXJhdGU7IHdpZHRoID0xMDAlOwlib3JkZXI6IDA7CWJvcmRlci1zcGFjaW5nOiAwO31cblxudHIg e1xuCWxpbmUtaGVpZ2h0OiAxOHB4O31cblxuYSwgdGQge1xuCWZvbnQtc2l6ZTogMTRweDsJZm9u dC1mYW1pbHk6IEFyaWFsOwljb2xvcjogIzMzMzsJd29yZC13cmFwOiBicmVhay13b3JkOwl3b3Jk LWJyZWFrOiBub3JtYWw7CXBhZGRpbmc6IDA7fVxuXG4udGl0bGUge1xuCWZvbnQtc2l6ZTogMjhw eDt9XG5cbi5pbWFnZSB7XG4Jd2lkdGg6IGF1dG87CW1heC13aWR0aDogYXV0bzt9XG5cbi5mb290 ZXIge1xuCXdpZHRoOiA2MDRweDt9XG5cbi5tYWluIHtcblxufUBtZWRpYSBzY3JlZW4gYW5kICht YXgtZGV2aWNlLXdpZHRoOiA4MDBweCkge1xuCS50aXRsZSB7XG4JCWZvbnQtc2l6ZTogMjJweCAh aW1wb3J0YW50Owl9XG4JLmltYWdlIHtcbgkJd2lkdGg6IGF1dG8gIWltcG9ydGFudDsJCW1heC13 aWR0aDogMTAwJSAhaW1wb3J0YW50Owl9XG4JLmZvb3RlciB7XG4JCXdpZHRoOiAxMDAlICFpbXBv cnRhbnQ7CQltYXgtd2lkdGg6IDYwNHB4ICFpbXBvcnRhbnRcbgl9XG4JLm1haW4ge1xuCQl3aWR0 aDogMTAwJSAhaW1wb3J0YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1wb3J0YW50XG4JfVxufVxu PC9zdHlsZT5cblxuPHRhYmxlIGJnY29sb3I9IiNGRkZGRkYiIHN0eWxlPSJwYWRkaW5nOiAwOyBt YXJnaW46IDA7IGJvcmRlcjogMDsgd2lkdGg6IDEwMCU7IiBhbGlnbj0ibGVmdCI+XG4JPHRyIHN0 eWxlPSJoZWlnaHQ6IDI4cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JPHRyPlxuCQk8dGQgYWxp Z249ImxlZnQiIHN0eWxlPSJwYWRkaW5nOiAwIDIwcHg7IG1hcmdpbjogMCI+XG4JCQk8IS0tPHRh YmxlIGJnY29sb3I9IiNGRkZGRkYiIHN0eWxlPSJib3JkZXI6IDBweDsgd2lkdGg6IDEwMCU7IHBh ZGRpbmctbGVmdDogNTBweDsgcGFkZGluZy1yaWdodDogNTBweDsiIGFsaWduPSJsZWZ0IiBjbGFz cz0ibWFpbiI+XG4JCQkJPHRyPlxuCQkJCQk8dGQgYWxpZ249ImNlbnRlciIgdmFsaWduPSJ0b3Ai ID4mbmJzcDsJCQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJCTwvdGFibGU+LS0+XG5cblxuXG5cblxu CQkJPHRhYmxlPlxuCQkJCTx0cj5cbgkJCQkJPHRkPlxuCQkJCQkJPEZPTlQgU0laRT0iNCIgQ09M T1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5XaGVuIGl0J3MgdGltZSwgam9pbiB0aGUgV2ViZXgg bWVldGluZyBoZXJlLjwvRk9OVD5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJCTx0ciBzdHls ZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3Rk PjwvdHI+XG4JCQkJPHRyPlxuCQkJCQk8dGQ+XG4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0i IzY2NjY2NiIgRkFDRT0iYXJpYWwiPk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDY0OSA2 OTcgOTc1PC9GT05UPlxuCQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4JCQk8L3RhYmxlPlxuCQkJXG4J CQk8dGFibGU+PHRyPjx0ZD48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJp YWwiPk1lZXRpbmcgcGFzc3dvcmQ6PC9GT05UPjwvdGQ+PHRkPjxGT05UIFNJWkU9IjIiICBDT0xP Uj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjYzUGFqTUFBPC9GT05UPjwvdGQ+PC90cj48L3RhYmxl PlxuXG4gICAgICAgIDx0YWJsZT5cbiAgICAgICAgCTx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIw cHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+XG4JCQk8dHI+XG4J CQkJPHRkIHN0eWxlPSJ3aWR0aDphdXRvIWltcG9ydGFudDsgIj5cbgkJCQkJPHRhYmxlIGJvcmRl cj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIiBzdHlsZT0id2lkdGg6YXV0bzt3 aWR0aDphdXRvIWltcG9ydGFudDtiYWNrZ3JvdW5kLWNvbG9yOiM0M0E5NDI7IGJvcmRlcjowcHgg c29saWQgIzQzQTk0MjsgYm9yZGVyLXJhZGl1czoyNXB4OyBtaW4td2lkdGg6MTYwcHghaW1wb3J0 YW50OyI+XG4JCQkJCQk8dHI+XG4JCQkJCQkJPHRkIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJwYWRk aW5nOjEwcHggMzZweDsiPjxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBo cD9NVElEPW0xZTk2YWMzNDUzODVmZjQwNmZjYzA2MmE0MzgyY2ZlNiIgc3R5bGU9ImNvbG9yOiNG RkZGRkY7IGZvbnQtc2l6ZToyMHB4OyB0ZXh0LWRlY29yYXRpb246bm9uZTsiPkpvaW4gbWVldGlu ZzwvYT48L3RkPlxuCQkJCQkJPC90cj5cbgkJCQkJPC90YWJsZT5cbgkJCQk8L3RkPlxuCQkJPC90 cj5cbgkJPC90YWJsZT5cblxuIDxGT05UIHNpemU9IjIiIENPTE9SPSIjRkYwMDAwIiBzdHlsZT0i Zm9udC1mYW1pbHk6IEFyaWFsOyI+PC9GT05UPlxuPEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwi PiZuYnNwOzxCUj4mbmJzcDs8QlI+PC9GT05UPlxuXG4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjQi IEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpFPSIzIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwi PkpvaW4gYnkgcGhvbmU8L0ZPTlQ+ICZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2 NjY2NjYiIEZBQ0U9ImFyaWFsIj48Yj48YSBocmVmPSd0ZWw6JTJCMS02NTAtNDc5LTMyMDgsLCow MSo2NDk2OTc5NzUlMjMlMjMqMDEqJyBzdHlsZT0nY29sb3I6IzAwQUZGOTsgIHRleHQtZGVjb3Jh dGlvbjpub25lOyBmb250LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0 OiAyNHB4Oyc+MS02NTAtNDc5LTMyMDg8L2E+PC9iPiBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9D YW5hZGEpPC9GT05UPiAmbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBG QUNFPSJhcmlhbCI+PC9GT05UPiZuYnNwOyA8QlI+PEJSPjxCUj5cblxuPHRhYmxlPjx0ciBzdHls ZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3Rk PjwvdHI+PC90YWJsZT5cblxuPEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9 IjMiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBmcm9tIGEgdmlkZW8gc3lzdGVt IG9yIGFwcGxpY2F0aW9uPC9GT05UPjxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIg RkFDRT0iYXJpYWwiPkRpYWw8L0ZPTlQ+IDxhIGhyZWY9InNpcDo2NDk2OTc5NzVAaWV0Zi53ZWJl eC5jb20iPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJhcmlhbCI+NjQ5Njk3 OTc1QGlldGYud2ViZXguY29tPC9GT05UPjwvYT4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENP TE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+WW91IGNhbiBhbHNvIGRpYWwgMTczLjI0My4yLjY4 IGFuZCBlbnRlciB5b3VyIG1lZXRpbmcgbnVtYmVyLjwvRk9OVD4gJm5ic3A7IDxCUj48L0ZPTlQ+ Jm5ic3A7IDxCUj5cblxuPHRhYmxlIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCI+PHRy Pjx0ZCAgc3R5bGU9ImNvbG9yOiAjMDAwMDAwOyBmb250LWZhbWlseTogQXJpYWw7Zm9udC1zaXpl OiAxMnB4OyBmb250LXdlaWdodDogYm9sZDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij48Yj5Kb2luIHVz aW5nIE1pY3Jvc29mdCBMeW5jIG9yIE1pY3Jvc29mdCBTa3lwZSBmb3IgQnVzaW5lc3M8L2I+PC90 ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkIHN0eWxlPSJjb2xvcjogIzMzMzMzMzsg Zm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6IDE0cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+ RGlhbCA8YSBocmVmPSIgc2lwOjY0OTY5Nzk3NS5pZXRmQGx5bmMud2ViZXguY29tIiAgIHN0eWxl PSJ0ZXh0LWRlY29yYXRpb246bm9uZTtjb2xvcjojMDBBRkY5Ij42NDk2OTc5NzUuaWV0ZkBseW5j LndlYmV4LmNvbTwvYT48L3RkPjwvdHI+PC90YWJsZT5cblxuCQkJPHRhYmxlIHN0eWxlPSJ3aWR0 aDogMTAwJTsiIGFsaWduPSJsZWZ0IiBjbGFzcz0ibWFpbiI+XG4gICAgICAgICAgICAgICAgPHRy IHN0eWxlPSJoZWlnaHQ6IDcycHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JCQkJPHRyPlxuCQkJ CQk8dGQgc3R5bGU9ImhlaWdodDogMjRweDsgY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFtaWx5OkFy aWFsOyBmb250LXNpemU6IDE0cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+TmVlZCBoZWxwPyBHbyB0 byA8YSBocmVmPSJodHRwOi8vaGVscC53ZWJleC5jb20iIHN0eWxlPSJjb2xvcjojMDQ5RkQ5OyB0 ZXh0LWRlY29yYXRpb246bm9uZTsiPmh0dHA6Ly9oZWxwLndlYmV4LmNvbTwvYT5cbgkJCQkJPC90 ZD5cbgkJCQk8L3RyPlxuICAgICAgICAgICAgICAgIDx0ciBzdHlsZT0iaGVpZ2h0OiA0NHB4Ij48 dGQ+Jm5ic3A7PC90ZD48L3RyPlxuCQkJPC90YWJsZT5cbgkJPC90ZD5cbgk8L3RyPlxuPC90YWJs ZT5cbg0KU1VNTUFSWTpBQ0UgaW50ZXJpbSBtZWV0aW5nIDINClBSSU9SSVRZOjUNCkNMQVNTOlBV QkxJQw0KQkVHSU46VkFMQVJNDQpUUklHR0VSOi1QVDVNDQpBQ1RJT046RElTUExBWQ0KREVTQ1JJ UFRJT046UmVtaW5kZXINCkVORDpWQUxBUk0NCkVORDpWRVZFTlQNCkVORDpWQ0FMRU5EQVINCg== ------=_Part_1047688_650537669.1581011469732-- From nobody Thu Feb 6 11:39:00 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 6EB9212009E; Thu, 6 Feb 2020 11:38:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158101793429.5356.6070906221823723521@ietfa.amsl.com> Date: Thu, 06 Feb 2020 11:38:54 -0800 Archived-At: Subject: [Ace] Authentication and Authorization for Constrained Environments (ace) WG Virtual Meeting: 2020-02-28 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, 06 Feb 2020 19:38:55 -0000 The Authentication and Authorization for Constrained Environments (ace) Working Group will hold a virtual interim meeting on 2020-02-28 from 08:00 to 09:00 America/New_York. Agenda: * chairs slides * status / progress of the current drafts * draft-ietf-ace-pusub * .... A more detailed agenda will be provided Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m6d4d2bbc3dece1e868ab501cc801b271 From nobody Thu Feb 6 12:26:34 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 1C8D11200F1 for ; Thu, 6 Feb 2020 12:26:32 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 tkr9TnFREhAA for ; Thu, 6 Feb 2020 12:26:29 -0800 (PST) Received: from sjmda11.webex.com (sjmda11.webex.com [64.68.124.128]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65050120128 for ; Thu, 6 Feb 2020 12:26:29 -0800 (PST) Received: from rva2rmd101.webex.com (sjc02-wxpd-lb03-v140.webex.com [10.252.16.111]) by sjmda11.webex.com (Postfix) with ESMTP id 405713072E64 for ; Thu, 6 Feb 2020 20:26:28 +0000 (GMT) Received: from rva2rmd101.webex.com (localhost [127.0.0.1]) by rva2rmd101.webex.com (Postfix) with ESMTP id E5E07101C804 for ; Thu, 6 Feb 2020 20:26:27 +0000 (GMT) Date: Thu, 6 Feb 2020 20:26:27 +0000 (GMT) From: ACE Working Group Reply-To: ace-chairs@ietf.org To: ace@ietf.org Message-ID: <1531544372.8098981581020787940.JavaMail.nobody@rva2rmd101.webex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1619756_43786354.1581020787940" X-Priority: 3 Importance: normal X-WBX-INFO: X-WBX-SID=456680, X-WBX-CID=152360891817405798, X-WBX-TID=2mius0gszqounkcoouik43u21rqixo82cdu56h3tf4x211x7t58r4z07, X-WBX-RID=18bb0722764e40cf81ac478c02261462, X-WBX-SVC:Web Components, X-WBX-TT:Meeting Cancelled, Date:Thu Feb 06 20:26:27 GMT 2020 reminder-39.11.0-2724 Archived-At: Subject: [Ace] Canceled Webex meeting: ACE interim meeting 2 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, 06 Feb 2020 20:26:32 -0000 ------=_Part_1619756_43786354.1581020787940 Content-Type: multipart/Alternative; boundary="----=_Part_1619757_1301839173.1581020787940" ------=_Part_1619757_1301839173.1581020787940 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhpLCBhY2VAaWV0Zi5vcmcsCgpBQ0UgV29ya2luZyBHcm91cCBjYW5jZWxlZCB0aGlzIFdlYmV4 IG1lZXRpbmcuCgoKQUNFIGludGVyaW0gbWVldGluZyAyCkZyaWRheSwgRmVicnVhcnkgMjgsIDIw MjAKODowMCBhbSAgfCAgKFVUQy0wNTowMCkgRWFzdGVybiBUaW1lIChVUyAmIENhbmFkYSkgIHwg IDEgaHIKCgpUbyByZW1vdmUgdGhlIG1lZXRpbmcgZnJvbSB5b3VyIGNhbGVuZGFyLCBvcGVuIHRo ZSBhdHRhY2hlZCAuaWNzIGZpbGUuIElmIHRoZSBhdHRhY2htZW50IGlzCiBtaXNzaW5nLCBkb3du bG9hZCB0aGUgLmljcyBmaWxlIGhlcmU6Cmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBo cD9NVElEPW02YWU3MWQzOWUyYjdiNzkyMTNmNTlkMjM3MmViOTFhYw0KDQoKCgo= ------=_Part_1619757_1301839173.1581020787940 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9VVRGLTgiPjxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50PSJ3aWR0aD1kZXZpY2Utd2lk dGgsIGluaXRpYWwtc2NhbGU9MSI+PGJvZHk+PHN0eWxlIHR5cGU9InRleHQvY3NzIj4KKiB7CiAg ICBwYWRkaW5nOiAwOyAgICBtYXJnaW46IDA7fQp0YWJsZSB7Cglib3JkZXItY29sbGFwc2U6IHNl cGFyYXRlOyB3aWR0aCA9MTAwJTsJYm9yZGVyOiAwOwlib3JkZXItc3BhY2luZzogMDt9Cgp0ciB7 CglsaW5lLWhlaWdodDogMThweDt9CgphLCB0ZCB7Cglmb250LXNpemU6IDE0cHg7CWZvbnQtZmFt aWx5OiBBcmlhbDsJY29sb3I6ICMzMzM7CXdvcmQtd3JhcDogYnJlYWstd29yZDsJd29yZC1icmVh azogbm9ybWFsOwlwYWRkaW5nOiAwO30KCi50aXRsZSB7Cglmb250LXNpemU6IDI4cHg7fQoKLmlt YWdlIHsKCXdpZHRoOiBhdXRvOwltYXgtd2lkdGg6IGF1dG87fQoKLmZvb3RlciB7Cgl3aWR0aDog NjA0cHg7fQoKLm1haW4gewoKfUBtZWRpYSBzY3JlZW4gYW5kIChtYXgtZGV2aWNlLXdpZHRoOiA4 MDBweCkgewoJLnRpdGxlIHsKCQlmb250LXNpemU6IDIycHggIWltcG9ydGFudDsJfQoJLmltYWdl IHsKCQl3aWR0aDogYXV0byAhaW1wb3J0YW50OwkJbWF4LXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7 CX0KCS5mb290ZXIgewoJCXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6IDYwNHB4 ICFpbXBvcnRhbnQKCX0KCS5tYWluIHsKCQl3aWR0aDogMTAwJSAhaW1wb3J0YW50OwkJbWF4LXdp ZHRoOiA2MDRweCAhaW1wb3J0YW50Cgl9Cn0KPC9zdHlsZT4KCjx0YWJsZSBiZ2NvbG9yPSIjRkZG RkZGIiBzdHlsZT0icGFkZGluZzogMDsgbWFyZ2luOiAwOyBib3JkZXI6IDA7IHdpZHRoOiAxMDAl OyIgYWxpZ249ImxlZnQiPgoJPHRyIHN0eWxlPSJoZWlnaHQ6IDI4cHgiPjx0ZD4mbmJzcDs8L3Rk PjwvdHI+Cgk8dHI+CgkJPHRkIGFsaWduPSJsZWZ0IiBzdHlsZT0icGFkZGluZzogMCAyMHB4OyBt YXJnaW46IDAiPgoJCQk8IS0tPHRhYmxlIGJnY29sb3I9IiNGRkZGRkYiIHN0eWxlPSJib3JkZXI6 IDBweDsgd2lkdGg6IDEwMCU7IHBhZGRpbmctbGVmdDogNTBweDsgcGFkZGluZy1yaWdodDogNTBw eDsiIGFsaWduPSJsZWZ0IiBjbGFzcz0ibWFpbiI+CgkJCQk8dHI+CgkJCQkJPHRkIGFsaWduPSJj ZW50ZXIiIHZhbGlnbj0idG9wIiA+Jm5ic3A7CQkJCQk8L3RkPgoJCQkJPC90cj4KCQkJPC90YWJs ZT4tLT4KCgo8dGFibGU+CiAgICAgICA8dHI+CiAgICAgICAgICAgPHRkPgogICAgICAgICAgIAkJ PHA+CiAgICAgICAgICAgCQkJPGZvbnQgc3R5bGU9ImZvbnQtc2l6ZTogMTZweDtmb250LWZhbWls eTogQXJpYWw7Y29sb3I6IzAwMDAwMDtmb250LXdlaWdodDogYm9sZDtsaW5lLWhlaWdodDogMjJw eDsiPgogICAgICAgICAgICAgICAgCQlBQ0UgV29ya2luZyBHcm91cCBjYW5jZWxlZCB0aGlzIFdl YmV4IG1lZXRpbmcuCiAgICAgICAgICAgICAgIAkJPC9mb250PgogICAgICAgICAgIDwvdGQ+CiAg ICAgIDwvdHI+CjwvdGFibGU+CgkJIDwhLS08dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDog MjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoK LS0+CgkJCSAgPHRhYmxlPgoJCQkgIAk8dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRk IHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPgogICAgICAgICAgICAgICAgPHRy IHN0eWxlPSJtYXJnaW46MHB4Ij4KICAgICAgICAgICAgICAgICAgIDx0ZCBzdHlsZT0iaGVpZ2h0 OiAyNHB4OyAgY29sb3I6ICMwMDAwMDA7CWZvbnQtZmFtaWx5OiBBcmlhbDsJZm9udC1zaXplOiAx NnB4OwlsaW5lLWhlaWdodDogMjRweDsiPkZyaWRheSwgRmVicnVhcnkgMjgsIDIwMjAKICAgICAg ICAgICAgICAgICAgIDwvdGQ+CiAgICAgICAgICAgICAgICA8L3RyPgogICAgICAgICAgICAgICAg PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij4KICAgICAgICAgICAgICAgICAgIDx0ZCBzdHlsZT0iaGVp Z2h0OiAyNHB4OyAgY29sb3I6ICMwMDAwMDA7CWZvbnQtZmFtaWx5OiBBcmlhbDsJZm9udC1zaXpl OiAxNnB4OwlsaW5lLWhlaWdodDogMjRweDsiPjg6MDAgYW0mbmJzcDsmbmJzcDt8Jm5ic3A7Jm5i c3A7KFVUQy0wNTowMCkgRWFzdGVybiBUaW1lIChVUyAmIENhbmFkYSkmbmJzcDsmbmJzcDt8Jm5i c3A7Jm5ic3A7MSBocgogICAgICAgICAgICAgICAgICAgPC90ZD4KICAgICAgICAgICAgICAgIDwv dHI+CiAgICAgICAgICAgICA8L3RhYmxlPgoKCQkJPHRhYmxlIHN0eWxlPSJ3aWR0aDogMTAwJTsi IGFsaWduPSJsZWZ0IiBjbGFzcz0ibWFpbiI+CiAgICAgICAgICAgICAgICA8dHIgc3R5bGU9Imhl aWdodDogNzJweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj4KCQkJCTx0cj4KCQkJCQk8dGQgc3R5bGU9 ImhlaWdodDogMjRweDsgY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFtaWx5OkFyaWFsOyBmb250LXNp emU6IDE0cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+TmVlZCBoZWxwPyBHbyB0byA8YSBocmVmPSJo dHRwOi8vaGVscC53ZWJleC5jb20iIHN0eWxlPSJjb2xvcjojMDQ5RkQ5OyB0ZXh0LWRlY29yYXRp b246bm9uZTsiPmh0dHA6Ly9oZWxwLndlYmV4LmNvbTwvYT4KCQkJCQk8L3RkPgoJCQkJPC90cj4K ICAgICAgICAgICAgICAgIDx0ciBzdHlsZT0iaGVpZ2h0OiA0NHB4Ij48dGQ+Jm5ic3A7PC90ZD48 L3RyPgoJCQk8L3RhYmxlPgoJCTwvdGQ+Cgk8L3RyPgo8L3RhYmxlPgo8L2JvZHk+ ------=_Part_1619757_1301839173.1581020787940 Content-Type: text/calendar;method=CANCEL;charset=utf-8; Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6Q0FOQ0VMDQpCRUdJTjpWVElN RVpPTkUNClRaSUQ6QW1lcmljYS9OZXdfWW9yaw0KVFpVUkw6aHR0cDovL3R6dXJsLm9yZy96b25l aW5mby1vdXRsb29rL0FtZXJpY2EvTmV3X1lvcmsNClgtTElDLUxPQ0FUSU9OOkFtZXJpY2EvTmV3 X1lvcmsNCkJFR0lOOkRBWUxJR0hUDQpUWk9GRlNFVEZST006LTA1MDANClRaT0ZGU0VUVE86LTA0 MDANClRaTkFNRTpFRFQNCkRUU1RBUlQ6MTk3MDAzMDhUMDIwMDAwDQpSUlVMRTpGUkVRPVlFQVJM WTtCWU1PTlRIPTM7QllEQVk9MlNVDQpFTkQ6REFZTElHSFQNCkJFR0lOOlNUQU5EQVJEDQpUWk9G RlNFVEZST006LTA0MDANClRaT0ZGU0VUVE86LTA1MDANClRaTkFNRTpFU1QNCkRUU1RBUlQ6MTk3 MDExMDFUMDIwMDAwDQpSUlVMRTpGUkVRPVlFQVJMWTtCWU1PTlRIPTExO0JZREFZPTFTVQ0KRU5E OlNUQU5EQVJEDQpFTkQ6VlRJTUVaT05FDQpCRUdJTjpWRVZFTlQNCkRUU1RBTVA6MjAyMDAyMDZU MjAyNjI3Wg0KQVRURU5ERUU7Q049ImFjZUBpZXRmLm9yZyI7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7 UlNWUD1UUlVFOk1BSUxUTzphY2VAaWV0Zi5vcmcNCk9SR0FOSVpFUjtDTj0iQUNFIFdvcmtpbmcg R3JvdXAiOk1BSUxUTzphY2UtY2hhaXJzQGlldGYub3JnDQpEVFNUQVJUO1RaSUQ9QW1lcmljYS9O ZXdfWW9yazoyMDIwMDIyOFQwODAwMDANCkRURU5EO1RaSUQ9QW1lcmljYS9OZXdfWW9yazoyMDIw MDIyOFQwOTAwMDANCkxPQ0FUSU9OOmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zg0KVFJBTlNQ Ok9QQVFVRQ0KU0VRVUVOQ0U6MTU4MTAyMDc4Nw0KVUlEOjRhMWY0YmI0LTllMTYtNDhkOS1iMzAw LWM2MDVmN2I3NDU5ZA0KREVTQ1JJUFRJT046XG5cblRoaXMgV2ViZXggbWVldGluZyBoYXMgYmVl biBjYW5jZWxlZC5cblxuVG9waWM6IEFDRSBpbnRlcmltIG1lZXRpbmcgMlxuRGF0ZTogRnJpZGF5 LCBGZWJydWFyeSAyOCwgMjAyMFxuVGltZTogODowMCBhbSwgKFVUQy0wNTowMCkgRWFzdGVybiBU aW1lIChVUyAmIENhbmFkYSlcbg0KU1VNTUFSWTpBQ0UgaW50ZXJpbSBtZWV0aW5nIDINClBSSU9S SVRZOjUNCkNMQVNTOlBVQkxJQw0KU1RBVFVTOkNBTkNFTExFRA0KRU5EOlZFVkVOVA0KRU5EOlZD QUxFTkRBUg0K ------=_Part_1619757_1301839173.1581020787940-- ------=_Part_1619756_43786354.1581020787940 Content-Type: application/octet-stream; name="Webex_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Webex_Meeting.ics" QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6Q0FOQ0VMDQpCRUdJTjpWVElN RVpPTkUNClRaSUQ6QW1lcmljYS9OZXdfWW9yaw0KVFpVUkw6aHR0cDovL3R6dXJsLm9yZy96b25l aW5mby1vdXRsb29rL0FtZXJpY2EvTmV3X1lvcmsNClgtTElDLUxPQ0FUSU9OOkFtZXJpY2EvTmV3 X1lvcmsNCkJFR0lOOkRBWUxJR0hUDQpUWk9GRlNFVEZST006LTA1MDANClRaT0ZGU0VUVE86LTA0 MDANClRaTkFNRTpFRFQNCkRUU1RBUlQ6MTk3MDAzMDhUMDIwMDAwDQpSUlVMRTpGUkVRPVlFQVJM WTtCWU1PTlRIPTM7QllEQVk9MlNVDQpFTkQ6REFZTElHSFQNCkJFR0lOOlNUQU5EQVJEDQpUWk9G RlNFVEZST006LTA0MDANClRaT0ZGU0VUVE86LTA1MDANClRaTkFNRTpFU1QNCkRUU1RBUlQ6MTk3 MDExMDFUMDIwMDAwDQpSUlVMRTpGUkVRPVlFQVJMWTtCWU1PTlRIPTExO0JZREFZPTFTVQ0KRU5E OlNUQU5EQVJEDQpFTkQ6VlRJTUVaT05FDQpCRUdJTjpWRVZFTlQNCkRUU1RBTVA6MjAyMDAyMDZU MjAyNjI3Wg0KQVRURU5ERUU7Q049ImFjZUBpZXRmLm9yZyI7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7 UlNWUD1UUlVFOk1BSUxUTzphY2VAaWV0Zi5vcmcNCk9SR0FOSVpFUjtDTj0iQUNFIFdvcmtpbmcg R3JvdXAiOk1BSUxUTzphY2UtY2hhaXJzQGlldGYub3JnDQpEVFNUQVJUO1RaSUQ9QW1lcmljYS9O ZXdfWW9yazoyMDIwMDIyOFQwODAwMDANCkRURU5EO1RaSUQ9QW1lcmljYS9OZXdfWW9yazoyMDIw MDIyOFQwOTAwMDANCkxPQ0FUSU9OOmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zg0KVFJBTlNQ Ok9QQVFVRQ0KU0VRVUVOQ0U6MTU4MTAyMDc4Nw0KVUlEOjRhMWY0YmI0LTllMTYtNDhkOS1iMzAw LWM2MDVmN2I3NDU5ZA0KREVTQ1JJUFRJT046XG5cblRoaXMgV2ViZXggbWVldGluZyBoYXMgYmVl biBjYW5jZWxlZC5cblxuVG9waWM6IEFDRSBpbnRlcmltIG1lZXRpbmcgMlxuRGF0ZTogRnJpZGF5 LCBGZWJydWFyeSAyOCwgMjAyMFxuVGltZTogODowMCBhbSwgKFVUQy0wNTowMCkgRWFzdGVybiBU aW1lIChVUyAmIENhbmFkYSlcbg0KU1VNTUFSWTpBQ0UgaW50ZXJpbSBtZWV0aW5nIDINClBSSU9S SVRZOjUNCkNMQVNTOlBVQkxJQw0KU1RBVFVTOkNBTkNFTExFRA0KRU5EOlZFVkVOVA0KRU5EOlZD QUxFTkRBUg0K ------=_Part_1619756_43786354.1581020787940-- From nobody Thu Feb 6 23:48:01 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 638541200E7; Thu, 6 Feb 2020 23:48:00 -0800 (PST) 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.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <158106168033.15994.18114903994287433315@ietfa.amsl.com> Date: Thu, 06 Feb 2020 23:48:00 -0800 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-oauth-authz-33.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: Fri, 07 Feb 2020 07:48:00 -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 : Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) Authors : Ludwig Seitz Goeran Selander Erik Wahlstroem Samuel Erdtman Hannes Tschofenig Filename : draft-ietf-ace-oauth-authz-33.txt Pages : 87 Date : 2020-02-06 Abstract: This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE- OAuth. The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-33 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-33 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-33 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 6 23:50:41 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 3C7CE1200F5 for ; Thu, 6 Feb 2020 23:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 zElqOHfvIXlo for ; Thu, 6 Feb 2020 23:50:35 -0800 (PST) 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 56B2812003E for ; Thu, 6 Feb 2020 23:50:35 -0800 (PST) Received: from mailhub1.air.saab.se ([136.163.213.4]) by weald.air.saab.se (8.14.4/8.14.4) with ESMTP id 0177oXTf002109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 7 Feb 2020 08:50:33 +0100 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 0177oJAh023151 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 7 Feb 2020 08:50:19 +0100 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; Fri, 7 Feb 2020 08:50:19 +0100 Received: from corpappl16593.corp.saab.se ([fe80::b4c9:ca69:a80d:fa3]) by corpappl16593.corp.saab.se ([fe80::b4c9:ca69:a80d:fa3%7]) with mapi id 15.01.1847.003; Fri, 7 Feb 2020 08:50:19 +0100 From: Seitz Ludwig To: "ace@ietf.org" Thread-Topic: New Version Notification for draft-ietf-ace-oauth-authz-33.txt Thread-Index: AQHV3Yr4X6vD5OmjcEGvbggqweoJqKgPWxpA Date: Fri, 7 Feb 2020 07:50:19 +0000 Message-ID: References: <158106168059.15994.7180104820081617667.idtracker@ietfa.amsl.com> In-Reply-To: <158106168059.15994.7180104820081617667.idtracker@ietfa.amsl.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="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: 0177oJAh023151 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: 1581666619.73821@3Z7r4lzGnawz/7rKRIELVQ X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (weald.air.saab.se [136.163.212.3]); Fri, 07 Feb 2020 08:50:33 +0100 (CET) Archived-At: Subject: [Ace] FW: New Version Notification for draft-ietf-ace-oauth-authz-33.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: Fri, 07 Feb 2020 07:50:39 -0000 SGVsbG8gQUNFLA0KDQpUaGlzIHVwZGF0ZSBmaXhlcyB0aGUgcmVtYWluaW5nIElBTkEgcmV2aWV3 LCBjb25jZXJuaW5nIHRoZSBPQXV0aCBpbnRyb3NwZWN0aW9uIHBhcmFtZXRlcnMuDQooYW5kIG9y ZGVycyB0aGUgcmVnaXN0cmF0aW9ucyBvZiBhIGZldyBvdGhlciBzZWN0aW9ucyBhbHBoYWJldGlj YWxseSkuDQovTHVkd2lnDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmcgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gDQpTZW50OiBk ZW4gNyBmZWJydWFyaSAyMDIwIDA4OjQ4DQpUbzogSGFubmVzIFRzY2hvZmVuaWcgPGhhbm5lcy50 c2Nob2ZlbmlnQGFybS5jb20+OyBHb2VyYW4gU2VsYW5kZXIgPGdvcmFuLnNlbGFuZGVyQGVyaWNz c29uLmNvbT47IFNhbXVlbCBFcmR0bWFuIDxlcmR0bWFuQHNwb3RpZnkuY29tPjsgU2VpdHogTHVk d2lnIDxsdWR3aWcuc2VpdHpAY29tYml0ZWNoLnNlPjsgRXJpayBXYWhsc3Ryb2VtIDxlcmlrQHdh aGxzdHJvbXN0ZWtuaXNrYS5zZT4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtaWV0Zi1hY2Utb2F1dGgtYXV0aHotMzMudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LWlldGYtYWNlLW9hdXRoLWF1dGh6LTMzLnR4dCBoYXMgYmVlbiBzdWNjZXNz ZnVsbHkgc3VibWl0dGVkIGJ5IEx1ZHdpZyBTZWl0eiBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJl cG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1pZXRmLWFjZS1vYXV0aC1hdXRoeg0KUmV2aXNpb246 CTMzDQpUaXRsZToJCUF1dGhlbnRpY2F0aW9uIGFuZCBBdXRob3JpemF0aW9uIGZvciBDb25zdHJh aW5lZCBFbnZpcm9ubWVudHMgKEFDRSkgdXNpbmcgdGhlIE9BdXRoIDIuMCBGcmFtZXdvcmsgKEFD RS1PQXV0aCkNCkRvY3VtZW50IGRhdGU6CTIwMjAtMDItMDcNCkdyb3VwOgkJYWNlDQpQYWdlczoJ CTg3DQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWlldGYtYWNlLW9hdXRoLWF1dGh6LTMzLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtYWNlLW9hdXRoLWF1dGh6Lw0K SHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFj ZS1vYXV0aC1hdXRoei0zMw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1hY2Utb2F1dGgtYXV0aHoNCkRpZmY6ICAgICAgICAg ICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1hY2Utb2F1dGgt YXV0aHotMzMNCg0KQWJzdHJhY3Q6DQogICBUaGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyBhIGZy YW1ld29yayBmb3IgYXV0aGVudGljYXRpb24gYW5kDQogICBhdXRob3JpemF0aW9uIGluIEludGVy bmV0IG9mIFRoaW5ncyAoSW9UKSBlbnZpcm9ubWVudHMgY2FsbGVkIEFDRS0NCiAgIE9BdXRoLiAg VGhlIGZyYW1ld29yayBpcyBiYXNlZCBvbiBhIHNldCBvZiBidWlsZGluZyBibG9ja3MgaW5jbHVk aW5nDQogICBPQXV0aCAyLjAgYW5kIHRoZSBDb25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90b2Nv bCAoQ29BUCksIHRodXMNCiAgIHRyYW5zZm9ybWluZyBhIHdlbGwta25vd24gYW5kIHdpZGVseSB1 c2VkIGF1dGhvcml6YXRpb24gc29sdXRpb24gaW50bw0KICAgYSBmb3JtIHN1aXRhYmxlIGZvciBJ b1QgZGV2aWNlcy4gIEV4aXN0aW5nIHNwZWNpZmljYXRpb25zIGFyZSB1c2VkDQogICB3aGVyZSBw b3NzaWJsZSwgYnV0IGV4dGVuc2lvbnMgYXJlIGFkZGVkIGFuZCBwcm9maWxlcyBhcmUgZGVmaW5l ZCB0bw0KICAgYmV0dGVyIHNlcnZlIHRoZSBJb1QgdXNlIGNhc2VzLg0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUg SUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Mon Feb 10 08:08: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 6DE8B120232 for ; Mon, 10 Feb 2020 06:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 dXHpUPHZaaFz for ; Mon, 10 Feb 2020 06:54:44 -0800 (PST) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2085.outbound.protection.outlook.com [40.107.93.85]) (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 1795A120227 for ; Mon, 10 Feb 2020 06:54:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZpSN7nsmJA069lCOpjicugbml03AZLHAk7RhfecBBpdibfPOrGO9lnKRVzwV24sweE7k+w8ruqJp1i/GzQZDMvCwWgkshd5BGzqfXwDbiAGZ3DVX+ZrBHLjt8EPnp2j4P7H+xoVwAoLJ9Wo3hsKhUMUbTEW+8KFbis6+omtpacMP3buqbve/inkNTZn5FsYBH30gxLKVLPnxG83ZagkCI+2FrOjaGDdHaZ+hG2BLjdDbsz89C6lsDIHhwFD2pL5gxV8PoW/L+EihNg/DYGFec5V3QBkXsJyM1CbV/FfkXhcoBV4jvR0w9ylA5jdRWvGi0R+IK00SaL2iYjblhXnuMA== 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=9PFqVQHtbbVM9Rl4zvpVQ17nvaR1PG8hKU9fR6y7MHU=; b=mWcHMk83DMBVF9DCAO4D0FkJrdSFYIRtoy4JBSf6Q5hrICWkWQaUh5NFV0tgN1azFzd3BdaGOswNx6V4+fdSG/xQqH8A+fUxpsFrQst+HwuFTSX5Q4cdSeUzcJ/+kN8tOBa3dri2oRcv1jVemkj2k1PM7XFE+UeGgZRxpIYkOPpVVQRW8c+X4ioPLBY90aQ6oDjikni+gGOQgQz5w0iQp5dNmDhYxhoK9LhFh+toUqVi55Hvx5Ms8KXWpXYnNi/sPGxwBN86xBEeqRa9NlzUqCPsMY9ohpBNIidwiE11M40qLhwkJt1CxZQ/+fgIgY5hQOs2Q/WHxNot+LAPJ5ByHA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=webex.com; dkim=pass header.d=webex.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=9PFqVQHtbbVM9Rl4zvpVQ17nvaR1PG8hKU9fR6y7MHU=; b=CO1BUZCFzHYrTwyOU9jqmdcxB5tnd+B5GmvdD2LoaXxPY+EG5rDNRvdbHD9y/vgHqT256miMSaz15f5M/VXoIhe2kQXkUVeHDNrqHv7liq02udtQxRYtazEbVbQJ2+1FwyrkuJe+UKp6JiDgfNK8i7d76eA7IMArczfdNqfxJBQ= Received: from SN6PR15MB2302.namprd15.prod.outlook.com (52.132.124.11) by SN6PR15MB2383.namprd15.prod.outlook.com (52.135.66.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.25; Mon, 10 Feb 2020 14:54:41 +0000 Received: from SN6PR15MB2302.namprd15.prod.outlook.com ([fe80::e89a:1a1e:d6b5:d9f9]) by SN6PR15MB2302.namprd15.prod.outlook.com ([fe80::e89a:1a1e:d6b5:d9f9%4]) with mapi id 15.20.2707.028; Mon, 10 Feb 2020 14:54:41 +0000 From: Cisco Webex To: "ace@ietf.org" Thread-Topic: Webex meeting scheduled: ACE interim meeting 2 Thread-Index: AQHV4A6Xs6zStosEMEqjmw4En6XtQQ== Sender: Daniel Migault Date: Mon, 10 Feb 2020 14:54: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: spf=none (sender IP is ) smtp.mailfrom=daniel.migault@ericsson.com; x-ms-exchange-messagesentrepresentingtype: 2 x-ms-exchange-meetingforward-message: Forward x-ms-exchange-calendar-series-instance-id: BAAAAIIA4AB0xbcQGoLgCAAAAAAAAAAAAAAAAAAAAAAAAAAAMQAAAHZDYWwtVWlkAQAAADJmYjdlYmVlLTg1YmQtNDdmNC1hZTNiLTc5YTliZGU3M2E5NQA= x-originating-ip: [96.22.11.129] x-ms-office365-filtering-correlation-id: 668dc09f-ca5a-4a85-3cae-08d7ae392870 x-ms-traffictypediagnostic: SN6PR15MB2383:MeetingMessage x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1332; x-forefront-prvs: 03094A4065 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(346002)(376002)(39850400004)(136003)(199004)(189003)(6916009)(33656002)(53546011)(6506007)(9686003)(478600001)(186003)(64756008)(66616009)(66946007)(66476007)(76116006)(19627405001)(66556008)(66446008)(52536014)(26005)(16799955002)(71200400001)(5660300002)(42882007)(2940100002)(966005)(7846003)(7696005)(55016002)(45080400002)(8676002)(316002)(4744005)(8936002)(81166006)(81156014)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN6PR15MB2383; H:SN6PR15MB2302.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 2 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PtiYYzb5ZVbfrFSR6LCGdCdJqSrs4B1clp0E6eQi72s2inhekN0v9rkyLGAJLwIuUJj9ylGSI8LsXRU5jLv8TtKB3mgYMXGqPJ+CjR4+ZP2S9VhOJuijeSGf31ri6Fc5CzZtQmxssvXwr2wWZMKU1rIZLO+BOvx/Ezj6VKGHaPyW8z50FlT39i9JFHic0/MCXkWsJzbqc68HK+1uyLl9kEYRDBCYGuag62Kz3xfP/tfo2hm7bmnKyH3t7pQEu9OhSjpFj80dewRh5csevbw3LtiNlH1JP6n4BNGI1ieqJ5aMiGFu5Xd3yqMCqDP+JvDSAomj30iK78wGBB5rj3DEGSezzfWS3FcgVMEztlwZKmD5zcXkcexMPZdZYwx4RFKlfn/dGFBHQSoUOyv/Ouj8iNrkczoYDZrRsIYTZf5T+atFFyvFq5aNbxOsLW/C+RL7tbe56i2a5tlAsTiB0E77f1hYLiKEdZfOYqKsLCVQ8S09iy9VUlbzXdkh6ha7mdi4lW4HCvpt+s3FIvNRbevrHQ== x-ms-exchange-antispam-messagedata: uYKevzTWMLA2wNfiuC+zArvkaLZs9yJCPih8qW+fcHa75kcDvkdMrKdXDQOR7klqdwd1ePUAQcEjifJUdv0y4hFB8iXu5/5r+urmAz3Y6Fo570DdrC8JzeUx0Dr2M+sslJ+nkXHNzY7XTe1HH7ibSw== x-ms-exchange-transport-forked: True Content-Type: multipart/mixed; boundary="_005_SN6PR15MB2302EC00488D5CA70FB70ED8E3190SN6PR15MB2302namp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 668dc09f-ca5a-4a85-3cae-08d7ae392870 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2020 14:54:40.9338 (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: yFrzxwINDHYkn08ByGuzLS79lYi79x8f4oRPfktCIUk+MotsKI8E6GLXeZIJ8h0Qne9vPcDoGs3vAC3j3qnJHPDzIWZNDaDXqN/mDCGYymA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR15MB2383 Archived-At: Subject: [Ace] FW: Webex meeting scheduled: ACE interim meeting 2 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, 10 Feb 2020 14:54:46 -0000 --_005_SN6PR15MB2302EC00488D5CA70FB70ED8E3190SN6PR15MB2302namp_ Content-Type: multipart/alternative; boundary="_000_SN6PR15MB2302EC00488D5CA70FB70ED8E3190SN6PR15MB2302namp_" --_000_SN6PR15MB2302EC00488D5CA70FB70ED8E3190SN6PR15MB2302namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -----Original Appointment----- From: Cisco Webex > Sent: Monday, February 10, 2020 7:36 AM To: Cisco Webex; ACE Working Group Subject: Webex meeting scheduled: ACE interim meeting 2 When: Tuesday, February 25, 2020 11:00 AM-12:30 PM America/New_York. Where: https://ietf.webex.com/ietf You are the host for this Webex meeting. When it's time, start your Webex meeting here. Meeting number (access code): 642 878 288 Meeting password: 73km5Jkz Host key: 791367 Tuesday, February 25, 2020 11:00 am | (UTC-05:00) Eastern Time (US & Canada) | 1 hr 30 mins Start meeting Join by phone Tap to call in from a mobile device (attendees only) 1-650-479-3208 Call-in toll= number (US/Canada) Join from a video system or application Dial 642878288@ietf.webex.com<%20sip:642878288@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 642878288.ietf@lync.webex.com<%20sip:642878288.ietf@lync.webex.com> Need help? Go to http://help.webex.com --_000_SN6PR15MB2302EC00488D5CA70FB70ED8E3190SN6PR15MB2302namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

 

-----Original Appointment-----
From: Cisco Webex <messenger@webex.com>
Sent: Monday, February 10, 2020 7:36 AM
To: Cisco Webex; ACE Working Group
Subject: Webex meeting scheduled: ACE interim meeting 2
When: Tuesday, February 25, 2020 11:00 AM-12:30 PM America/New_York.=
Where: https://ietf.webex.com/ietf<= o:p>

 

 

You are the host for this Webex meeting.

 

When it's time, start your Webex meeting here.

 

 

Meeting number (access code): 642 878 288

 

Meeting password: 73km5Jkz

 

Host key: 791367

 

 

Tuesday, February 25, 2020

11:00 am  |  (UTC-05:00) Eastern Time (US = & Canada)  |  1 hr 30 mins

 

 

 

Start meeting

 

 

 

Join by phone

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

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

 

 

 

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

Dial 642878288@ietf.webex.com=

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 642878288.ietf@lync.webe= x.com

 

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

 

 

--_000_SN6PR15MB2302EC00488D5CA70FB70ED8E3190SN6PR15MB2302namp_ Content-Type: text/calendar; charset="utf-8"; method=REQUEST Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpNRVRIT0Q6UkVRVUVTVA0KUFJPRElEOk1pY3Jvc29mdCBFeGNoYW5n ZSBTZXJ2ZXIgMjAxMA0KVkVSU0lPTjoyLjANCkJFR0lOOlZUSU1FWk9ORQ0KVFpJRDpFYXN0ZXJu IFN0YW5kYXJkIFRpbWUNCkJFR0lOOlNUQU5EQVJEDQpEVFNUQVJUOjE2MDEwMTAxVDAyMDAwMA0K VFpPRkZTRVRGUk9NOi0wNDAwDQpUWk9GRlNFVFRPOi0wNTAwDQpSUlVMRTpGUkVRPVlFQVJMWTtJ TlRFUlZBTD0xO0JZREFZPTFTVTtCWU1PTlRIPTExDQpFTkQ6U1RBTkRBUkQNCkJFR0lOOkRBWUxJ R0hUDQpEVFNUQVJUOjE2MDEwMTAxVDAyMDAwMA0KVFpPRkZTRVRGUk9NOi0wNTAwDQpUWk9GRlNF VFRPOi0wNDAwDQpSUlVMRTpGUkVRPVlFQVJMWTtJTlRFUlZBTD0xO0JZREFZPTJTVTtCWU1PTlRI PTMNCkVORDpEQVlMSUdIVA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpPUkdBTklaRVI7 Q049Q2lzY28gV2ViZXg7U0VOVC1CWT0ibWFpbHRvOmRhbmllbC5taWdhdWx0QGVyaWNzc29uLmNv bSI6bWFpbHRvOg0KIG1lc3NlbmdlckB3ZWJleC5jb20NCkFUVEVOREVFO1JPTEU9UkVRLVBBUlRJ Q0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPUZBTFNFO0NOPWFjZUBpZXRmLg0KIG9y ZzptYWlsdG86YWNlQGlldGYub3JnDQpBVFRBQ0g6Q0lEOkU4ODIyQjcxOUZCQTkwNDVCQjI4OTZC NDkyRDI0M0E3QG5hbXByZDE1LnByb2Qub3V0bG9vay5jb20NCkRFU0NSSVBUSU9OO0xBTkdVQUdF PWVuLVVTOlxuXG4tLS0tLU9yaWdpbmFsIEFwcG9pbnRtZW50LS0tLS1cbkZyb206IENpc2NvIA0K IFdlYmV4IDxtZXNzZW5nZXJAd2ViZXguY29tPG1haWx0bzptZXNzZW5nZXJAd2ViZXguY29tPj5c blNlbnQ6IE1vbmRheVwsIEZlDQogYnJ1YXJ5IDEwXCwgMjAyMCA3OjM2IEFNXG5UbzogQ2lzY28g V2ViZXhcOyBBQ0UgV29ya2luZyBHcm91cFxuU3ViamVjdDogV2UNCiBiZXggbWVldGluZyBzY2hl ZHVsZWQ6IEFDRSBpbnRlcmltIG1lZXRpbmcgMlxuV2hlbjogVHVlc2RheVwsIEZlYnJ1YXJ5IDI1 XA0KICwgMjAyMCAxMTowMCBBTS0xMjozMCBQTSBBbWVyaWNhL05ld19Zb3JrLlxuV2hlcmU6IGh0 dHBzOi8vaWV0Zi53ZWJleC5jb20vDQogaWV0ZlxuXG5cblxuWW91IGFyZSB0aGUgaG9zdCBmb3Ig dGhpcyBXZWJleCBtZWV0aW5nLlxuXG5cbldoZW4gaXQncyB0aW1lXCwNCiAgc3RhcnQgeW91ciBX ZWJleCBtZWV0aW5nIGhlcmUuXG5cblxuTWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogNjQy IDg3OA0KICAyODhcblxuTWVldGluZyBwYXNzd29yZDogNzNrbTVKa3pcblxuSG9zdCBrZXk6IDc5 MTM2N1xuXG5cblR1ZXNkYXlcLCBGZWJyDQogdWFyeSAyNVwsIDIwMjBcbjExOjAwIGFtICB8ICAo VVRDLTA1OjAwKSBFYXN0ZXJuIFRpbWUgKFVTICYgQ2FuYWRhKSAgfCAgMSANCiBociAzMCBtaW5z XG5cblxuXG5TdGFydCBtZWV0aW5nPGh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9N VElEPW1lZg0KIDNlZjNhMjJlOTZjMDYwZDM3ODJmZGQzODg2NGYyND5cblxuXG5cbkpvaW4gYnkg cGhvbmVcblRhcCB0byBjYWxsIGluIGZyb20gDQogYSBtb2JpbGUgZGV2aWNlIChhdHRlbmRlZXMg b25seSlcbjEtNjUwLTQ3OS0zMjA4PHRlbDolMkIxLTY1MC00NzktMzIwOFwsXCwNCiAqMDEqNjQy ODc4Mjg4JTIzJTIzKjAxKj4gQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKVxuXG5cblxu Sm9pbiBmcm9tIA0KIGEgdmlkZW8gc3lzdGVtIG9yIGFwcGxpY2F0aW9uXG5EaWFsIDY0Mjg3ODI4 OEBpZXRmLndlYmV4LmNvbTwlMjBzaXA6NjQyODc4DQogMjg4QGlldGYud2ViZXguY29tPlxuWW91 IGNhbiBhbHNvIGRpYWwgMTczLjI0My4yLjY4IGFuZCBlbnRlciB5b3VyIG1lZXRpbmcNCiAgbnVt YmVyLlxuXG5cblxuSm9pbiB1c2luZyBNaWNyb3NvZnQgTHluYyBvciBNaWNyb3NvZnQgU2t5cGUg Zm9yIEJ1c2luZXNzXA0KIG5EaWFsIDY0Mjg3ODI4OC5pZXRmQGx5bmMud2ViZXguY29tPCUyMHNp cDo2NDI4NzgyODguaWV0ZkBseW5jLndlYmV4LmNvbT5cDQogblxuTmVlZCBoZWxwPyBHbyB0byBo dHRwOi8vaGVscC53ZWJleC5jb21cblxuXG4NClVJRDoyZmI3ZWJlZS04NWJkLTQ3ZjQtYWUzYi03 OWE5YmRlNzNhOTUNClNVTU1BUlk7TEFOR1VBR0U9ZW4tVVM6Rlc6IFdlYmV4IG1lZXRpbmcgc2No ZWR1bGVkOiBBQ0UgaW50ZXJpbSBtZWV0aW5nIDINCkRUU1RBUlQ7VFpJRD1FYXN0ZXJuIFN0YW5k YXJkIFRpbWU6MjAyMDAyMjVUMTEwMDAwDQpEVEVORDtUWklEPUVhc3Rlcm4gU3RhbmRhcmQgVGlt ZToyMDIwMDIyNVQxMjMwMDANCkNMQVNTOlBVQkxJQw0KUFJJT1JJVFk6NQ0KRFRTVEFNUDoyMDIw MDIxMFQxMjM1MTVaDQpUUkFOU1A6T1BBUVVFDQpTVEFUVVM6Q09ORklSTUVEDQpTRVFVRU5DRTox NTgxMzM4MTE1DQpMT0NBVElPTjtMQU5HVUFHRT1lbi1VUzpodHRwczovL2lldGYud2ViZXguY29t L2lldGYNClgtTUlDUk9TT0ZULUNETy1BUFBULVNFUVVFTkNFOjE1ODEzMzgxMTUNClgtTUlDUk9T T0ZULUNETy1PV05FUkFQUFRJRDowDQpYLU1JQ1JPU09GVC1DRE8tQlVTWVNUQVRVUzpURU5UQVRJ VkUNClgtTUlDUk9TT0ZULUNETy1JTlRFTkRFRFNUQVRVUzpCVVNZDQpYLU1JQ1JPU09GVC1DRE8t QUxMREFZRVZFTlQ6RkFMU0UNClgtTUlDUk9TT0ZULUNETy1JTVBPUlRBTkNFOjENClgtTUlDUk9T T0ZULUNETy1JTlNUVFlQRTowDQpYLU1JQ1JPU09GVC1ET05PVEZPUldBUkRNRUVUSU5HOkZBTFNF DQpYLU1JQ1JPU09GVC1ESVNBTExPVy1DT1VOVEVSOkZBTFNFDQpYLU1JQ1JPU09GVC1MT0NBVElP TlM6W3siRGlzcGxheU5hbWUiOiJodHRwczovL2lldGYud2ViZXguY29tL2lldGYiXCwiTG9jYXQN CiBpb25Bbm5vdGF0aW9uIjoiIlwsIkxvY2F0aW9uVXJpIjoiIlwsIkxvY2F0aW9uU3RyZWV0Ijoi IlwsIkxvY2F0aW9uQ2l0eSI6Ig0KICJcLCJMb2NhdGlvblN0YXRlIjoiIlwsIkxvY2F0aW9uQ291 bnRyeSI6IiJcLCJMb2NhdGlvblBvc3RhbENvZGUiOiIiXCwiTG9jDQogYXRpb25GdWxsQWRkcmVz cyI6IiJ9XQ0KQkVHSU46VkFMQVJNDQpERVNDUklQVElPTjpSRU1JTkRFUg0KVFJJR0dFUjtSRUxB VEVEPVNUQVJUOi1QVDVNDQpBQ1RJT046RElTUExBWQ0KRU5EOlZBTEFSTQ0KRU5EOlZFVkVOVA0K RU5EOlZDQUxFTkRBUg0K --_000_SN6PR15MB2302EC00488D5CA70FB70ED8E3190SN6PR15MB2302namp_-- --_005_SN6PR15MB2302EC00488D5CA70FB70ED8E3190SN6PR15MB2302namp_ Content-Type: application/octet-stream; name="Webex_Meeting.ics" Content-Description: Webex_Meeting.ics Content-Disposition: attachment; filename="Webex_Meeting.ics"; size=6739; creation-date="Mon, 10 Feb 2020 12:35:35 GMT"; modification-date="Mon, 10 Feb 2020 12:35:35 GMT" Content-ID: Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkFtZXJpY2EvTmV3X1lvcmsNClRaVVJMOmh0dHA6Ly90enVybC5vcmcvem9u ZWluZm8tb3V0bG9vay9BbWVyaWNhL05ld19Zb3JrDQpYLUxJQy1MT0NBVElPTjpBbWVyaWNhL05l d19Zb3JrDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOi0wNTAwDQpUWk9GRlNFVFRPOi0w NDAwDQpUWk5BTUU6RURUDQpEVFNUQVJUOjE5NzAwMzA4VDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFS TFk7QllNT05USD0zO0JZREFZPTJTVQ0KRU5EOkRBWUxJR0hUDQpCRUdJTjpTVEFOREFSRA0KVFpP RkZTRVRGUk9NOi0wNDAwDQpUWk9GRlNFVFRPOi0wNTAwDQpUWk5BTUU6RVNUDQpEVFNUQVJUOjE5 NzAxMTAxVDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFSTFk7QllNT05USD0xMTtCWURBWT0xU1UNCkVO RDpTVEFOREFSRA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpEVFNUQU1QOjIwMjAwMjEw VDEyMzUxNVoNCkFUVEVOREVFO0NOPSJBQ0UgV29ya2luZyBHcm91cCI7Uk9MRT1SRVEtUEFSVElD SVBBTlQ7UlNWUD1GQUxTRTpNQUlMVE86YWNlLWNoYWlyc0BpZXRmLm9yZw0KT1JHQU5JWkVSO0NO PSJDaXNjbyBXZWJleCI6TUFJTFRPOm1lc3NlbmdlckB3ZWJleC5jb20NCkRUU1RBUlQ7VFpJRD1B bWVyaWNhL05ld19Zb3JrOjIwMjAwMjI1VDExMDAwMA0KRFRFTkQ7VFpJRD1BbWVyaWNhL05ld19Z b3JrOjIwMjAwMjI1VDEyMzAwMA0KTE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRm DQpUUkFOU1A6T1BBUVVFDQpTRVFVRU5DRToxNTgxMzM4MTE1DQpVSUQ6MmZiN2ViZWUtODViZC00 N2Y0LWFlM2ItNzlhOWJkZTczYTk1DQpERVNDUklQVElPTjpcblxuSk9JTiBXRUJFWCBNRUVUSU5H XG5odHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tZWYzZWYzYTIyZTk2YzA2 MGQzNzgyZmRkMzg4NjRmMjRcbk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDY0MiA4Nzgg Mjg4XG5cbkhvc3Qga2V5OiA3OTEzNjdcblxuTWVldGluZyBwYXNzd29yZDogNzNrbTVKa3pcblxu XG5cbkpPSU4gQlkgUEhPTkVcbjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVT L0NhbmFkYSlcblRhcCBoZXJlIHRvIGNhbGwgKG1vYmlsZSBwaG9uZXMgb25seSwgaG9zdHMgbm90 IHN1cHBvcnRlZCk6IHRlbDolMkIxLTY1MC00NzktMzIwOCwsKjAxKjY0Mjg3ODI4OCUyMyUyMyow MSpcblxuXG5cbkpPSU4gRlJPTSBBIFZJREVPIFNZU1RFTSBPUiBBUFBMSUNBVElPTlxuRGlhbCBz aXA6NjQyODc4Mjg4QGlldGYud2ViZXguY29tXG5Zb3UgY2FuIGFsc28gZGlhbCAxNzMuMjQzLjIu NjggYW5kIGVudGVyIHlvdXIgbWVldGluZyBudW1iZXIuXG5cblxuSm9pbiB1c2luZyBNaWNyb3Nv ZnQgTHluYyBvciBNaWNyb3NvZnQgU2t5cGUgZm9yIEJ1c2luZXNzXG5EaWFsIHNpcDo2NDI4Nzgy ODguaWV0ZkBseW5jLndlYmV4LmNvbVxuXG5cblxuQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz8gQ29u dGFjdCBzdXBwb3J0IGhlcmU6XG5odHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWNcblxuXG5J TVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViZXggc2VydmljZSBhbGxv d3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRv IGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVy LiBZb3Ugc2hvdWxkIGluZm9ybSBhbGwgbWVldGluZyBhdHRlbmRlZXMgcHJpb3IgdG8gcmVjb3Jk aW5nIGlmIHlvdSBpbnRlbmQgdG8gcmVjb3JkIHRoZSBtZWV0aW5nLlxuDQpYLUFMVC1ERVNDO0ZN VFRZUEU9dGV4dC9odG1sOjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+XG4qIHtcbiAgICBwYWRkaW5n OiAwOyAgICBtYXJnaW46IDA7fVxudGFibGUge1xuCWJvcmRlci1jb2xsYXBzZTogc2VwYXJhdGU7 IHdpZHRoID0xMDAlOwlib3JkZXI6IDA7CWJvcmRlci1zcGFjaW5nOiAwO31cblxudHIge1xuCWxp bmUtaGVpZ2h0OiAxOHB4O31cblxuYSwgdGQge1xuCWZvbnQtc2l6ZTogMTRweDsJZm9udC1mYW1p bHk6IEFyaWFsOwljb2xvcjogIzMzMzsJd29yZC13cmFwOiBicmVhay13b3JkOwl3b3JkLWJyZWFr OiBub3JtYWw7CXBhZGRpbmc6IDA7fVxuXG4udGl0bGUge1xuCWZvbnQtc2l6ZTogMjhweDt9XG5c bi5pbWFnZSB7XG4Jd2lkdGg6IGF1dG87CW1heC13aWR0aDogYXV0bzt9XG5cbi5mb290ZXIge1xu CXdpZHRoOiA2MDRweDt9XG5cbi5tYWluIHtcblxufUBtZWRpYSBzY3JlZW4gYW5kIChtYXgtZGV2 aWNlLXdpZHRoOiA4MDBweCkge1xuCS50aXRsZSB7XG4JCWZvbnQtc2l6ZTogMjJweCAhaW1wb3J0 YW50Owl9XG4JLmltYWdlIHtcbgkJd2lkdGg6IGF1dG8gIWltcG9ydGFudDsJCW1heC13aWR0aDog MTAwJSAhaW1wb3J0YW50Owl9XG4JLmZvb3RlciB7XG4JCXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7 CQltYXgtd2lkdGg6IDYwNHB4ICFpbXBvcnRhbnRcbgl9XG4JLm1haW4ge1xuCQl3aWR0aDogMTAw JSAhaW1wb3J0YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1wb3J0YW50XG4JfVxufVxuPC9zdHls ZT5cblxuPHRhYmxlIGJnY29sb3I9IiNGRkZGRkYiIHN0eWxlPSJwYWRkaW5nOiAwOyBtYXJnaW46 IDA7IGJvcmRlcjogMDsgd2lkdGg6IDEwMCU7IiBhbGlnbj0ibGVmdCI+XG4JPHRyIHN0eWxlPSJo ZWlnaHQ6IDI4cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JPHRyPlxuCQk8dGQgYWxpZ249Imxl ZnQiIHN0eWxlPSJwYWRkaW5nOiAwIDIwcHg7IG1hcmdpbjogMCI+XG4JCQk8IS0tPHRhYmxlIGJn Y29sb3I9IiNGRkZGRkYiIHN0eWxlPSJib3JkZXI6IDBweDsgd2lkdGg6IDEwMCU7IHBhZGRpbmct bGVmdDogNTBweDsgcGFkZGluZy1yaWdodDogNTBweDsiIGFsaWduPSJsZWZ0IiBjbGFzcz0ibWFp biI+XG4JCQkJPHRyPlxuCQkJCQk8dGQgYWxpZ249ImNlbnRlciIgdmFsaWduPSJ0b3AiID4mbmJz cDsJCQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJCTwvdGFibGU+LS0+XG5cblxuXG4JCQk8dGFibGU+ XG4JCQkJPHRyPlxuCQkJCQk8dGQ+XG4JCQkJCQk8Rk9OVCBTSVpFPSI0IiBDT0xPUj0iIzY2NjY2 NiIgRkFDRT0iYXJpYWwiPldoZW4gaXQncyB0aW1lLCBqb2luIHRoZSBXZWJleCBtZWV0aW5nIGhl cmUuPC9GT05UPlxuCQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4JCQkJPHRyIHN0eWxlPSJsaW5lLWhl aWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj5cbgkJ CQk8dHI+XG4JCQkJCTx0ZD5cbgkJCQkJCTxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBG QUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogNjQyIDg3OCAyODg8L0ZP TlQ+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJCTwvdGFibGU+XG4JCQk8dGFibGU+XG4JCQkJ PHRyPlxuCQkJCQk8dGQ+XG4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFD RT0iYXJpYWwiPkhvc3Qga2V5OiA3OTEzNjc8L0ZPTlQ+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5c bgkJCTwvdGFibGU+XG4JCQk8dGFibGU+PHRyPjx0ZD48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2 NjY2NiIgRkFDRT0iYXJpYWwiPk1lZXRpbmcgcGFzc3dvcmQ6PC9GT05UPjwvdGQ+PHRkPjxGT05U IFNJWkU9IjIiICBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjcza201Smt6PC9GT05UPjwv dGQ+PC90cj48L3RhYmxlPlxuXG4gICAgICAgIDx0YWJsZT5cbiAgICAgICAgCTx0ciBzdHlsZT0i bGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwv dHI+XG4JCQk8dHI+XG4JCQkJPHRkIHN0eWxlPSJ3aWR0aDphdXRvIWltcG9ydGFudDsgIj5cbgkJ CQkJPHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIiBzdHls ZT0id2lkdGg6YXV0bzt3aWR0aDphdXRvIWltcG9ydGFudDtiYWNrZ3JvdW5kLWNvbG9yOiM0M0E5 NDI7IGJvcmRlcjowcHggc29saWQgIzQzQTk0MjsgYm9yZGVyLXJhZGl1czoyNXB4OyBtaW4td2lk dGg6MTYwcHghaW1wb3J0YW50OyI+XG4JCQkJCQk8dHI+XG4JCQkJCQkJPHRkIGFsaWduPSJjZW50 ZXIiIHN0eWxlPSJwYWRkaW5nOjEwcHggMzZweDsiPjxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJl eC5jb20vaWV0Zi9qLnBocD9NVElEPW1lZjNlZjNhMjJlOTZjMDYwZDM3ODJmZGQzODg2NGYyNCIg c3R5bGU9ImNvbG9yOiNGRkZGRkY7IGZvbnQtc2l6ZToyMHB4OyB0ZXh0LWRlY29yYXRpb246bm9u ZTsiPkpvaW4gbWVldGluZzwvYT48L3RkPlxuCQkJCQkJPC90cj5cbgkJCQkJPC90YWJsZT5cbgkJ CQk8L3RkPlxuCQkJPC90cj5cbgkJPC90YWJsZT5cblxuIDxGT05UIHNpemU9IjIiIENPTE9SPSIj RkYwMDAwIiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsOyI+PC9GT05UPlxuPEZPTlQgU0laRT0i MSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4mbmJzcDs8QlI+PC9GT05UPlxuXG4mbmJzcDsgPEJS PjxGT05UIFNJWkU9IjQiIEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpFPSIzIiBDT0xPUj0iIzY2NjY2 NiIgRkFDRT0iYXJpYWwiPkpvaW4gYnkgcGhvbmU8L0ZPTlQ+ICZuYnNwOyA8QlI+PEZPTlQgU0la RT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48Yj48YSBocmVmPSd0ZWw6JTJCMS02 NTAtNDc5LTMyMDgsLCowMSo2NDI4NzgyODglMjMlMjMqMDEqJyBzdHlsZT0nY29sb3I6IzAwQUZG OTsgIHRleHQtZGVjb3JhdGlvbjpub25lOyBmb250LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAx NHB4O2xpbmUtaGVpZ2h0OiAyNHB4Oyc+MS02NTAtNDc5LTMyMDg8L2E+PC9iPiBDYWxsLWluIHRv bGwgbnVtYmVyIChVUy9DYW5hZGEpPC9GT05UPiAmbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENP TE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+PC9GT05UPiZuYnNwOyA8QlI+PEJSPjxCUj5cblxu PHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoy MHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT5cblxuPEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJ QUwiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBmcm9t IGEgdmlkZW8gc3lzdGVtIG9yIGFwcGxpY2F0aW9uPC9GT05UPjxCUj48Rk9OVCBTSVpFPSIyIiBD T0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkRpYWw8L0ZPTlQ+IDxhIGhyZWY9InNpcDo2NDI4 NzgyODhAaWV0Zi53ZWJleC5jb20iPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjMDBBRkY5IiBGQUNF PSJhcmlhbCI+NjQyODc4Mjg4QGlldGYud2ViZXguY29tPC9GT05UPjwvYT4mbmJzcDsgPEJSPjxG T05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+WW91IGNhbiBhbHNvIGRp YWwgMTczLjI0My4yLjY4IGFuZCBlbnRlciB5b3VyIG1lZXRpbmcgbnVtYmVyLjwvRk9OVD4gJm5i c3A7IDxCUj48L0ZPTlQ+Jm5ic3A7IDxCUj5cblxuPHRhYmxlIGNlbGxwYWRkaW5nPSIwIiBjZWxs c3BhY2luZz0iMCI+PHRyPjx0ZCAgc3R5bGU9ImNvbG9yOiAjMDAwMDAwOyBmb250LWZhbWlseTog QXJpYWw7Zm9udC1zaXplOiAxMnB4OyBmb250LXdlaWdodDogYm9sZDsgbGluZS1oZWlnaHQ6IDI0 cHg7Ij48Yj5Kb2luIHVzaW5nIE1pY3Jvc29mdCBMeW5jIG9yIE1pY3Jvc29mdCBTa3lwZSBmb3Ig QnVzaW5lc3M8L2I+PC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkIHN0eWxlPSJj b2xvcjogIzMzMzMzMzsgZm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6IDE0cHg7IGxpbmUt aGVpZ2h0OiAyNHB4OyI+RGlhbCA8YSBocmVmPSIgc2lwOjY0Mjg3ODI4OC5pZXRmQGx5bmMud2Vi ZXguY29tIiAgIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtjb2xvcjojMDBBRkY5Ij42NDI4 NzgyODguaWV0ZkBseW5jLndlYmV4LmNvbTwvYT48L3RkPjwvdHI+PC90YWJsZT5cblxuCQkJPHRh YmxlIHN0eWxlPSJ3aWR0aDogMTAwJTsiIGFsaWduPSJsZWZ0IiBjbGFzcz0ibWFpbiI+XG4gICAg ICAgICAgICAgICAgPHRyIHN0eWxlPSJoZWlnaHQ6IDcycHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+ XG4JCQkJPHRyPlxuCQkJCQk8dGQgc3R5bGU9ImhlaWdodDogMjRweDsgY29sb3I6ICMwMDAwMDA7 IGZvbnQtZmFtaWx5OkFyaWFsOyBmb250LXNpemU6IDE0cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+ TmVlZCBoZWxwPyBHbyB0byA8YSBocmVmPSJodHRwOi8vaGVscC53ZWJleC5jb20iIHN0eWxlPSJj b2xvcjojMDQ5RkQ5OyB0ZXh0LWRlY29yYXRpb246bm9uZTsiPmh0dHA6Ly9oZWxwLndlYmV4LmNv bTwvYT5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuICAgICAgICAgICAgICAgIDx0ciBzdHlsZT0i aGVpZ2h0OiA0NHB4Ij48dGQ+Jm5ic3A7PC90ZD48L3RyPlxuCQkJPC90YWJsZT5cbgkJPC90ZD5c bgk8L3RyPlxuPC90YWJsZT5cbg0KU1VNTUFSWTpBQ0UgaW50ZXJpbSBtZWV0aW5nIDINClBSSU9S SVRZOjUNCkNMQVNTOlBVQkxJQw0KQkVHSU46VkFMQVJNDQpUUklHR0VSOi1QVDVNDQpBQ1RJT046 RElTUExBWQ0KREVTQ1JJUFRJT046UmVtaW5kZXINCkVORDpWQUxBUk0NCkVORDpWRVZFTlQNCkVO RDpWQ0FMRU5EQVINCg== --_005_SN6PR15MB2302EC00488D5CA70FB70ED8E3190SN6PR15MB2302namp_-- From nobody Mon Feb 10 08:15:30 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 D915912086B; Mon, 10 Feb 2020 08:15:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158135131063.4044.4493273886343043950@ietfa.amsl.com> Date: Mon, 10 Feb 2020 08:15:10 -0800 Archived-At: Subject: [Ace] Authentication and Authorization for Constrained Environments (ace) WG Virtual Meeting: 2020-02-25 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, 10 Feb 2020 16:15:17 -0000 The Authentication and Authorization for Constrained Environments (ace) Working Group will hold a virtual interim meeting on 2020-02-25 from 11:00 to 12:30 America/New_York. Agenda: (No agenda submitted) Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=mef47d467abc73c0a86252d04c0fe24a2 From nobody Mon Feb 10 11:22:37 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 B5345120838 for ; Mon, 10 Feb 2020 11:22:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 u1JJda6-c3Lg for ; Mon, 10 Feb 2020 11:22:34 -0800 (PST) Received: from mail-vk1-xa2b.google.com (mail-vk1-xa2b.google.com [IPv6:2607:f8b0:4864:20::a2b]) (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 D71D5120832 for ; Mon, 10 Feb 2020 11:22:33 -0800 (PST) Received: by mail-vk1-xa2b.google.com with SMTP id o187so2104986vka.2 for ; Mon, 10 Feb 2020 11:22:33 -0800 (PST) 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=ZKPWKbO4cQ5xmYJ3j/FlNBQicjM/8I3lGaxunuiW/2I=; b=EENJLXbw4FUg1MohvYG6L8OmyxJg+GoE1oMD8V7e/ouppRpXTVinfrvBt9sTJBgRjy NwSdnliGmh8wQTcvjXPbhHG3nMUlN8iCtnTB/UOGPXQaozJH5z4BWUHPEt3O1Zbv/til G8omckDhcQW67HmpZkm49o8d6psHfO5O12x7gso04n8fKlRjTMZukXrHGkmXUH89T2Oc TuUDdQ12ethXoCI9Q5r4ZNNVxK4WBzWL0betgZUoFWrXWpLUHcxRvtew1FOGWo2nm3O8 hD4mbLaNY/NLy7Fs19IudDU1jDWyagPnCo9CyA/Q1UtZsfx5PnQ7loLAMhKbS4FfgkHL ryZg== 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=ZKPWKbO4cQ5xmYJ3j/FlNBQicjM/8I3lGaxunuiW/2I=; b=Dqw584obe4gYB/Uepp5pYJ5VNrbAVUID0jJtb4HrAQLGaXtq8rAaiVWAys56hKR6yo BGjHYlArQmexHI1M019dRUbVmtP4v5VpZ6ruXFp7W6LQgQL8ct+kwKE6reB1YZ/tJQUz e2qN3y4sWL5qHfbBkRBstWCOGv0vyubIFJ3wZFVhkfXI5GAQWftXwa0v+BGqupwcb74t NyfdPYnO8QR32V05P4IpIcP6qERtUUZzInR6a7PhJ+fbncfiKiZeh2plp27yufOk8CgO +hGkJPFYZ806YhpE5UEDaNmY84uWOzfPpRNNfZDN99D0R+fRNCdLOZVyQygNk06RTr8/ O8ew== X-Gm-Message-State: APjAAAWaqyTQUhLoPdfQgcO9AwrxcphHI+halTXJL2MGvMIcyTH+TKNK P4cMTl0Zk6bOcug0If+7m/r/TpfFhrSomk7KnGJ3B1Vl X-Google-Smtp-Source: APXvYqyrnzniVRfanP+23vqHvhponA4rCB858D4HR6P24bfp0/9RhXu/9m4qFLz8cYulv78poBgwbRX9RzYRVLmxuO4= X-Received: by 2002:a1f:3ac9:: with SMTP id h192mr1561531vka.55.1581362550460; Mon, 10 Feb 2020 11:22:30 -0800 (PST) MIME-Version: 1.0 References: <1097333699.127611581338115971.JavaMail.nobody@rva2rmd101.webex.com> In-Reply-To: <1097333699.127611581338115971.JavaMail.nobody@rva2rmd101.webex.com> From: Daniel Migault Date: Mon, 10 Feb 2020 14:22:18 -0500 Message-ID: To: Ace Wg Content-Type: multipart/mixed; boundary="0000000000001c9c52059e3da9d5" Archived-At: Subject: [Ace] Fwd: Webex meeting invitation: ACE interim meeting 2 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, 10 Feb 2020 19:22:37 -0000 --0000000000001c9c52059e3da9d5 Content-Type: multipart/alternative; boundary="0000000000001c9c4e059e3da9d3" --0000000000001c9c4e059e3da9d3 Content-Type: text/plain; charset="UTF-8" Please find the time slot for the ACE interim meeting 2. If there is an topic you would like to discuss to discuss please provide them to the list so we can set the agenda. * Yours, Daniel ---------- Forwarded message --------- From: ACE Working Group Date: Mon, Feb 10, 2020 at 7:35 AM Subject: Webex meeting invitation: ACE interim meeting 2 To: ACE Working Group invites you to join this Webex meeting. Meeting number (access code): 642 878 288 Meeting password: 73km5Jkz Tuesday, February 25, 2020 11:00 am | (UTC-05:00) Eastern Time (US & Canada) | 1 hr 30 mins Join meeting *Join by phone* Tap to call in from a mobile device (attendees only) 1-650-479-3208 <%2B1-650-479-3208,,*01*642878288%23%23*01*> Call-in toll number (US/Canada) *Join from a video system or application* Dial 642878288@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 642878288.ietf@lync.webex.com Need help? Go to http://help.webex.com -- Daniel Migault Ericsson --0000000000001c9c4e059e3da9d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Please find the time slot for the ACE interim meeting 2. I= f there is an topic you would like to discuss to discuss please provide the= m to the list so we can set the agenda.=C2=A0
*=C2=A0
Yours,= =C2=A0
Daniel

---------- Forwarded message ---------
From: <= strong class=3D"gmail_sendername" dir=3D"auto">ACE Working Group <= span dir=3D"auto"><messenger@webe= x.com>
Date: Mon, Feb 10, 2020 at 7:35 AM
Subject: Webe= x meeting invitation: ACE interim meeting 2
To: <mglt.ietf@gmail.com>


=C2=A0
=09
ACE Working Group invites you to join this Webex meeting.
=C2= =A0
Meeting number (access code): 642 878 288
Meeting password: 73km5Jkz
=20
=C2= =A0
Tuesday, February 25, 2020
11:00 am=C2=A0=C2=A0|=C2=A0=C2=A0(UTC-05:00) East= ern Time (US & Canada)=C2=A0=C2=A0|=C2=A0=C2=A01 hr 30 mins
=20
=C2=A0
Join meeting
= =C2=A0
Tap to call in from a mobile device (attendees only)
Join by phone
1-650-479-3208=C2=A0Call-in toll number (US/Canada)
= =
=C2=A0
Join from a video system or appli= cation
Dial 642878288@ietf.webex.com
You can also dial 173.243.2.68 and enter your meeting nu= mber.
=C2=A0
Join using Microsoft Lync or Microsoft Skype for Business
Dial 642878288.ietf@lync.webex.com
=C2=A0
Need help? Go to http://help.webe= x.com
=C2=A0


--
Dani= el Migault
Ericsson
--0000000000001c9c4e059e3da9d3-- --0000000000001c9c52059e3da9d5 Content-Type: application/ics; name="invite.ics" Content-Disposition: attachment; filename="invite.ics" Content-Transfer-Encoding: base64 Content-ID: <1702f27fe1c475802341> X-Attachment-Id: 1702f27fe1c475802341 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkFtZXJpY2EvTmV3X1lvcmsNClRaVVJMOmh0dHA6Ly90enVybC5vcmcvem9u ZWluZm8tb3V0bG9vay9BbWVyaWNhL05ld19Zb3JrDQpYLUxJQy1MT0NBVElPTjpBbWVyaWNhL05l d19Zb3JrDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOi0wNTAwDQpUWk9GRlNFVFRPOi0w NDAwDQpUWk5BTUU6RURUDQpEVFNUQVJUOjE5NzAwMzA4VDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFS TFk7QllNT05USD0zO0JZREFZPTJTVQ0KRU5EOkRBWUxJR0hUDQpCRUdJTjpTVEFOREFSRA0KVFpP RkZTRVRGUk9NOi0wNDAwDQpUWk9GRlNFVFRPOi0wNTAwDQpUWk5BTUU6RVNUDQpEVFNUQVJUOjE5 NzAxMTAxVDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFSTFk7QllNT05USD0xMTtCWURBWT0xU1UNCkVO RDpTVEFOREFSRA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpEVFNUQU1QOjIwMjAwMjEw VDEyMzUxNVoNCkFUVEVOREVFO0NOPSJtZ2x0LmlldGZAZ21haWwuY29tIjtST0xFPVJFUS1QQVJU SUNJUEFOVDtSU1ZQPVRSVUU6TUFJTFRPOm1nbHQuaWV0ZkBnbWFpbC5jb20NCk9SR0FOSVpFUjtD Tj0iQUNFIFdvcmtpbmcgR3JvdXAiOk1BSUxUTzphY2UtY2hhaXJzQGlldGYub3JnDQpEVFNUQVJU O1RaSUQ9QW1lcmljYS9OZXdfWW9yazoyMDIwMDIyNVQxMTAwMDANCkRURU5EO1RaSUQ9QW1lcmlj YS9OZXdfWW9yazoyMDIwMDIyNVQxMjMwMDANCkxPQ0FUSU9OOmh0dHBzOi8vaWV0Zi53ZWJleC5j b20vaWV0Zg0KVFJBTlNQOk9QQVFVRQ0KU0VRVUVOQ0U6MTU4MTMzODExNQ0KVUlEOjJmYjdlYmVl LTg1YmQtNDdmNC1hZTNiLTc5YTliZGU3M2E5NQ0KREVTQ1JJUFRJT046XG5cblxuXG5KT0lOIFdF QkVYIE1FRVRJTkdcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW1lZjQ3 ZDQ2N2FiYzczYzBhODYyNTJkMDRjMGZlMjRhMlxuTWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2Rl KTogNjQyIDg3OCAyODhcblxuXG5NZWV0aW5nIHBhc3N3b3JkOiA3M2ttNUprelxuXG5cblxuSk9J TiBCWSBQSE9ORVxuMS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRh KVxuVGFwIGhlcmUgdG8gY2FsbCAobW9iaWxlIHBob25lcyBvbmx5LCBob3N0cyBub3Qgc3VwcG9y dGVkKTogdGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwqMDEqNjQyODc4Mjg4JTIzJTIzKjAxKlxuXG5c blxuSk9JTiBGUk9NIEEgVklERU8gU1lTVEVNIE9SIEFQUExJQ0FUSU9OXG5EaWFsIHNpcDo2NDI4 NzgyODhAaWV0Zi53ZWJleC5jb21cbllvdSBjYW4gYWxzbyBkaWFsIDE3My4yNDMuMi42OCBhbmQg ZW50ZXIgeW91ciBtZWV0aW5nIG51bWJlci5cblxuXG5Kb2luIHVzaW5nIE1pY3Jvc29mdCBMeW5j IG9yIE1pY3Jvc29mdCBTa3lwZSBmb3IgQnVzaW5lc3NcbkRpYWwgc2lwOjY0Mjg3ODI4OC5pZXRm QGx5bmMud2ViZXguY29tXG5cblxuXG5DYW4ndCBqb2luIHRoZSBtZWV0aW5nP1xuaHR0cHM6Ly9j b2xsYWJvcmF0aW9uaGVscC5jaXNjby5jb20vYXJ0aWNsZS9XQlgwMDAwMjkwNTVcblxuXG5JTVBP UlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViZXggc2VydmljZSBhbGxvd3Mg YXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJl IHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBC eSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNo IHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlz Y3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Np b24uXG4NClgtQUxULURFU0M7Rk1UVFlQRT10ZXh0L2h0bWw6PHN0eWxlIHR5cGU9InRleHQvY3Nz Ij5cbioge1xuICAgIHBhZGRpbmc6IDA7ICAgIG1hcmdpbjogMDt9XG50YWJsZSB7XG4JYm9yZGVy LWNvbGxhcHNlOiBzZXBhcmF0ZTsgd2lkdGggPTEwMCU7CWJvcmRlcjogMDsJYm9yZGVyLXNwYWNp bmc6IDA7fVxuXG50ciB7XG4JbGluZS1oZWlnaHQ6IDE4cHg7fVxuXG5hLCB0ZCB7XG4JZm9udC1z aXplOiAxNHB4Owlmb250LWZhbWlseTogQXJpYWw7CWNvbG9yOiAjMzMzOwl3b3JkLXdyYXA6IGJy ZWFrLXdvcmQ7CXdvcmQtYnJlYWs6IG5vcm1hbDsJcGFkZGluZzogMDt9XG5cbi50aXRsZSB7XG4J Zm9udC1zaXplOiAyOHB4O31cblxuLmltYWdlIHtcbgl3aWR0aDogYXV0bzsJbWF4LXdpZHRoOiBh dXRvO31cblxuLmZvb3RlciB7XG4Jd2lkdGg6IDYwNHB4O31cblxuLm1haW4ge1xuXG59QG1lZGlh IHNjcmVlbiBhbmQgKG1heC1kZXZpY2Utd2lkdGg6IDgwMHB4KSB7XG4JLnRpdGxlIHtcbgkJZm9u dC1zaXplOiAyMnB4ICFpbXBvcnRhbnQ7CX1cbgkuaW1hZ2Uge1xuCQl3aWR0aDogYXV0byAhaW1w b3J0YW50OwkJbWF4LXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CX1cbgkuZm9vdGVyIHtcbgkJd2lk dGg6IDEwMCUgIWltcG9ydGFudDsJCW1heC13aWR0aDogNjA0cHggIWltcG9ydGFudFxuCX1cbgku bWFpbiB7XG4JCXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6IDYwNHB4ICFpbXBv cnRhbnRcbgl9XG59XG48L3N0eWxlPlxuXG48dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIgc3R5bGU9 InBhZGRpbmc6IDA7IG1hcmdpbjogMDsgYm9yZGVyOiAwOyB3aWR0aDogMTAwJTsiIGFsaWduPSJs ZWZ0Ij5cbgk8dHIgc3R5bGU9ImhlaWdodDogMjhweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj5cbgk8 dHI+XG4JCTx0ZCBhbGlnbj0ibGVmdCIgc3R5bGU9InBhZGRpbmc6IDAgMjBweDsgbWFyZ2luOiAw Ij5cbgkJCTwhLS08dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIgc3R5bGU9ImJvcmRlcjogMHB4OyB3 aWR0aDogMTAwJTsgcGFkZGluZy1sZWZ0OiA1MHB4OyBwYWRkaW5nLXJpZ2h0OiA1MHB4OyIgYWxp Z249ImxlZnQiIGNsYXNzPSJtYWluIj5cbgkJCQk8dHI+XG4JCQkJCTx0ZCBhbGlnbj0iY2VudGVy IiB2YWxpZ249InRvcCIgPiZuYnNwOwkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJPC90YWJsZT4t LT5cblxuXG5cblxuXG4JCQk8dGFibGU+XG4JCQkJPHRyPlxuCQkJCQk8dGQ+XG4JCQkJCQk8Rk9O VCBTSVpFPSI0IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPldoZW4gaXQncyB0aW1lLCBq b2luIHRoZSBXZWJleCBtZWV0aW5nIGhlcmUuPC9GT05UPlxuCQkJCQk8L3RkPlxuCQkJCTwvdHI+ XG4JCQkJPHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIw cHgiPiZuYnNwOzwvdGQ+PC90cj5cbgkJCQk8dHI+XG4JCQkJCTx0ZD5cbgkJCQkJCTxGT05UIFNJ WkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXIgKGFjY2Vz cyBjb2RlKTogNjQyIDg3OCAyODg8L0ZPTlQ+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJCTwv dGFibGU+XG4JCQlcbgkJCTx0YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2 NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQg U0laRT0iMiIgIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+NzNrbTVKa3o8L0ZPTlQ+PC90 ZD48L3RyPjwvdGFibGU+XG5cbiAgICAgICAgPHRhYmxlPlxuICAgICAgICAJPHRyIHN0eWxlPSJs aW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90 cj5cbgkJCTx0cj5cbgkJCQk8dGQgc3R5bGU9IndpZHRoOmF1dG8haW1wb3J0YW50OyAiPlxuCQkJ CQk8dGFibGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiIHN0eWxl PSJ3aWR0aDphdXRvO3dpZHRoOmF1dG8haW1wb3J0YW50O2JhY2tncm91bmQtY29sb3I6IzQzQTk0 MjsgYm9yZGVyOjBweCBzb2xpZCAjNDNBOTQyOyBib3JkZXItcmFkaXVzOjI1cHg7IG1pbi13aWR0 aDoxNjBweCFpbXBvcnRhbnQ7Ij5cbgkJCQkJCTx0cj5cbgkJCQkJCQk8dGQgYWxpZ249ImNlbnRl ciIgc3R5bGU9InBhZGRpbmc6MTBweCAzNnB4OyI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4 LmNvbS9pZXRmL2oucGhwP01USUQ9bWVmNDdkNDY3YWJjNzNjMGE4NjI1MmQwNGMwZmUyNGEyIiBz dHlsZT0iY29sb3I6I0ZGRkZGRjsgZm9udC1zaXplOjIwcHg7IHRleHQtZGVjb3JhdGlvbjpub25l OyI+Sm9pbiBtZWV0aW5nPC9hPjwvdGQ+XG4JCQkJCQk8L3RyPlxuCQkJCQk8L3RhYmxlPlxuCQkJ CTwvdGQ+XG4JCQk8L3RyPlxuCQk8L3RhYmxlPlxuXG4gPEZPTlQgc2l6ZT0iMiIgQ09MT1I9IiNG RjAwMDAiIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7Ij48L0ZPTlQ+XG48Rk9OVCBTSVpFPSIx IiBGQUNFPSJBUklBTCI+Jm5ic3A7PEJSPiZuYnNwOzxCUj48L0ZPTlQ+XG5cbiZuYnNwOyA8QlI+ PEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2 IiBGQUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwvRk9OVD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpF PSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxiPjxhIGhyZWY9J3RlbDolMkIxLTY1 MC00NzktMzIwOCwsKjAxKjY0Mjg3ODI4OCUyMyUyMyowMSonIHN0eWxlPSdjb2xvcjojMDBBRkY5 OyAgdGV4dC1kZWNvcmF0aW9uOm5vbmU7IGZvbnQtZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDE0 cHg7bGluZS1oZWlnaHQ6IDI0cHg7Jz4xLTY1MC00NzktMzIwODwvYT48L2I+IENhbGwtaW4gdG9s bCBudW1iZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+ICZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09M T1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48L0ZPTlQ+Jm5ic3A7IDxCUj48QlI+PEJSPlxuXG48 dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIw cHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPlxuXG48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklB TCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGZyb20g YSB2aWRlbyBzeXN0ZW0gb3IgYXBwbGljYXRpb248L0ZPTlQ+PEJSPjxGT05UIFNJWkU9IjIiIENP TE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+RGlhbDwvRk9OVD4gPGEgaHJlZj0ic2lwOjY0Mjg3 ODI4OEBpZXRmLndlYmV4LmNvbSI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9 ImFyaWFsIj42NDI4NzgyODhAaWV0Zi53ZWJleC5jb208L0ZPTlQ+PC9hPiZuYnNwOyA8QlI+PEZP TlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Zb3UgY2FuIGFsc28gZGlh bCAxNzMuMjQzLjIuNjggYW5kIGVudGVyIHlvdXIgbWVldGluZyBudW1iZXIuPC9GT05UPiAmbmJz cDsgPEJSPjwvRk9OVD4mbmJzcDsgPEJSPlxuXG48dGFibGUgY2VsbHBhZGRpbmc9IjAiIGNlbGxz cGFjaW5nPSIwIj48dHI+PHRkICBzdHlsZT0iY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFtaWx5OiBB cmlhbDtmb250LXNpemU6IDEycHg7IGZvbnQtd2VpZ2h0OiBib2xkOyBsaW5lLWhlaWdodDogMjRw eDsiPjxiPkpvaW4gdXNpbmcgTWljcm9zb2Z0IEx5bmMgb3IgTWljcm9zb2Z0IFNreXBlIGZvciBC dXNpbmVzczwvYj48L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQgc3R5bGU9ImNv bG9yOiAjMzMzMzMzOyBmb250LWZhbWlseTogQXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1o ZWlnaHQ6IDI0cHg7Ij5EaWFsIDxhIGhyZWY9IiBzaXA6NjQyODc4Mjg4LmlldGZAbHluYy53ZWJl eC5jb20iICAgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2NvbG9yOiMwMEFGRjkiPjY0Mjg3 ODI4OC5pZXRmQGx5bmMud2ViZXguY29tPC9hPjwvdGQ+PC90cj48L3RhYmxlPlxuXG4JCQk8dGFi bGUgc3R5bGU9IndpZHRoOiAxMDAlOyIgYWxpZ249ImxlZnQiIGNsYXNzPSJtYWluIj5cbiAgICAg ICAgICAgICAgICA8dHIgc3R5bGU9ImhlaWdodDogNzJweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj5c bgkJCQk8dHI+XG4JCQkJCTx0ZCBzdHlsZT0iaGVpZ2h0OiAyNHB4OyBjb2xvcjogIzAwMDAwMDsg Zm9udC1mYW1pbHk6QXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij5O ZWVkIGhlbHA/IEdvIHRvIDxhIGhyZWY9Imh0dHA6Ly9oZWxwLndlYmV4LmNvbSIgc3R5bGU9ImNv bG9yOiMwNDlGRDk7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+aHR0cDovL2hlbHAud2ViZXguY29t PC9hPlxuCQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4gICAgICAgICAgICAgICAgPHRyIHN0eWxlPSJo ZWlnaHQ6IDQ0cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JCQk8L3RhYmxlPlxuCQk8L3RkPlxu CTwvdHI+XG48L3RhYmxlPlxuDQpTVU1NQVJZOkFDRSBpbnRlcmltIG1lZXRpbmcgMg0KUFJJT1JJ VFk6NQ0KQ0xBU1M6UFVCTElDDQpCRUdJTjpWQUxBUk0NClRSSUdHRVI6LVBUNU0NCkFDVElPTjpE SVNQTEFZDQpERVNDUklQVElPTjpSZW1pbmRlcg0KRU5EOlZBTEFSTQ0KRU5EOlZFVkVOVA0KRU5E OlZDQUxFTkRBUg0K --0000000000001c9c52059e3da9d5 Content-Type: application/ics; name="Webex_Meeting.ics" Content-Disposition: attachment; filename="Webex_Meeting.ics" Content-Transfer-Encoding: base64 Content-ID: <1702f27fe1cc1ce7aee2> X-Attachment-Id: 1702f27fe1cc1ce7aee2 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkFtZXJpY2EvTmV3X1lvcmsNClRaVVJMOmh0dHA6Ly90enVybC5vcmcvem9u ZWluZm8tb3V0bG9vay9BbWVyaWNhL05ld19Zb3JrDQpYLUxJQy1MT0NBVElPTjpBbWVyaWNhL05l d19Zb3JrDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOi0wNTAwDQpUWk9GRlNFVFRPOi0w NDAwDQpUWk5BTUU6RURUDQpEVFNUQVJUOjE5NzAwMzA4VDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFS TFk7QllNT05USD0zO0JZREFZPTJTVQ0KRU5EOkRBWUxJR0hUDQpCRUdJTjpTVEFOREFSRA0KVFpP RkZTRVRGUk9NOi0wNDAwDQpUWk9GRlNFVFRPOi0wNTAwDQpUWk5BTUU6RVNUDQpEVFNUQVJUOjE5 NzAxMTAxVDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFSTFk7QllNT05USD0xMTtCWURBWT0xU1UNCkVO RDpTVEFOREFSRA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpEVFNUQU1QOjIwMjAwMjEw VDEyMzUxNVoNCkFUVEVOREVFO0NOPSJtZ2x0LmlldGZAZ21haWwuY29tIjtST0xFPVJFUS1QQVJU SUNJUEFOVDtSU1ZQPVRSVUU6TUFJTFRPOm1nbHQuaWV0ZkBnbWFpbC5jb20NCk9SR0FOSVpFUjtD Tj0iQUNFIFdvcmtpbmcgR3JvdXAiOk1BSUxUTzphY2UtY2hhaXJzQGlldGYub3JnDQpEVFNUQVJU O1RaSUQ9QW1lcmljYS9OZXdfWW9yazoyMDIwMDIyNVQxMTAwMDANCkRURU5EO1RaSUQ9QW1lcmlj YS9OZXdfWW9yazoyMDIwMDIyNVQxMjMwMDANCkxPQ0FUSU9OOmh0dHBzOi8vaWV0Zi53ZWJleC5j b20vaWV0Zg0KVFJBTlNQOk9QQVFVRQ0KU0VRVUVOQ0U6MTU4MTMzODExNQ0KVUlEOjJmYjdlYmVl LTg1YmQtNDdmNC1hZTNiLTc5YTliZGU3M2E5NQ0KREVTQ1JJUFRJT046XG5cblxuXG5KT0lOIFdF QkVYIE1FRVRJTkdcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW1lZjQ3 ZDQ2N2FiYzczYzBhODYyNTJkMDRjMGZlMjRhMlxuTWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2Rl KTogNjQyIDg3OCAyODhcblxuXG5NZWV0aW5nIHBhc3N3b3JkOiA3M2ttNUprelxuXG5cblxuSk9J TiBCWSBQSE9ORVxuMS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRh KVxuVGFwIGhlcmUgdG8gY2FsbCAobW9iaWxlIHBob25lcyBvbmx5LCBob3N0cyBub3Qgc3VwcG9y dGVkKTogdGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwqMDEqNjQyODc4Mjg4JTIzJTIzKjAxKlxuXG5c blxuSk9JTiBGUk9NIEEgVklERU8gU1lTVEVNIE9SIEFQUExJQ0FUSU9OXG5EaWFsIHNpcDo2NDI4 NzgyODhAaWV0Zi53ZWJleC5jb21cbllvdSBjYW4gYWxzbyBkaWFsIDE3My4yNDMuMi42OCBhbmQg ZW50ZXIgeW91ciBtZWV0aW5nIG51bWJlci5cblxuXG5Kb2luIHVzaW5nIE1pY3Jvc29mdCBMeW5j IG9yIE1pY3Jvc29mdCBTa3lwZSBmb3IgQnVzaW5lc3NcbkRpYWwgc2lwOjY0Mjg3ODI4OC5pZXRm QGx5bmMud2ViZXguY29tXG5cblxuXG5DYW4ndCBqb2luIHRoZSBtZWV0aW5nP1xuaHR0cHM6Ly9j b2xsYWJvcmF0aW9uaGVscC5jaXNjby5jb20vYXJ0aWNsZS9XQlgwMDAwMjkwNTVcblxuXG5JTVBP UlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViZXggc2VydmljZSBhbGxvd3Mg YXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJl IHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBC eSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNo IHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlz Y3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Np b24uXG4NClgtQUxULURFU0M7Rk1UVFlQRT10ZXh0L2h0bWw6PHN0eWxlIHR5cGU9InRleHQvY3Nz Ij5cbioge1xuICAgIHBhZGRpbmc6IDA7ICAgIG1hcmdpbjogMDt9XG50YWJsZSB7XG4JYm9yZGVy LWNvbGxhcHNlOiBzZXBhcmF0ZTsgd2lkdGggPTEwMCU7CWJvcmRlcjogMDsJYm9yZGVyLXNwYWNp bmc6IDA7fVxuXG50ciB7XG4JbGluZS1oZWlnaHQ6IDE4cHg7fVxuXG5hLCB0ZCB7XG4JZm9udC1z aXplOiAxNHB4Owlmb250LWZhbWlseTogQXJpYWw7CWNvbG9yOiAjMzMzOwl3b3JkLXdyYXA6IGJy ZWFrLXdvcmQ7CXdvcmQtYnJlYWs6IG5vcm1hbDsJcGFkZGluZzogMDt9XG5cbi50aXRsZSB7XG4J Zm9udC1zaXplOiAyOHB4O31cblxuLmltYWdlIHtcbgl3aWR0aDogYXV0bzsJbWF4LXdpZHRoOiBh dXRvO31cblxuLmZvb3RlciB7XG4Jd2lkdGg6IDYwNHB4O31cblxuLm1haW4ge1xuXG59QG1lZGlh IHNjcmVlbiBhbmQgKG1heC1kZXZpY2Utd2lkdGg6IDgwMHB4KSB7XG4JLnRpdGxlIHtcbgkJZm9u dC1zaXplOiAyMnB4ICFpbXBvcnRhbnQ7CX1cbgkuaW1hZ2Uge1xuCQl3aWR0aDogYXV0byAhaW1w b3J0YW50OwkJbWF4LXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CX1cbgkuZm9vdGVyIHtcbgkJd2lk dGg6IDEwMCUgIWltcG9ydGFudDsJCW1heC13aWR0aDogNjA0cHggIWltcG9ydGFudFxuCX1cbgku bWFpbiB7XG4JCXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6IDYwNHB4ICFpbXBv cnRhbnRcbgl9XG59XG48L3N0eWxlPlxuXG48dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIgc3R5bGU9 InBhZGRpbmc6IDA7IG1hcmdpbjogMDsgYm9yZGVyOiAwOyB3aWR0aDogMTAwJTsiIGFsaWduPSJs ZWZ0Ij5cbgk8dHIgc3R5bGU9ImhlaWdodDogMjhweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj5cbgk8 dHI+XG4JCTx0ZCBhbGlnbj0ibGVmdCIgc3R5bGU9InBhZGRpbmc6IDAgMjBweDsgbWFyZ2luOiAw Ij5cbgkJCTwhLS08dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIgc3R5bGU9ImJvcmRlcjogMHB4OyB3 aWR0aDogMTAwJTsgcGFkZGluZy1sZWZ0OiA1MHB4OyBwYWRkaW5nLXJpZ2h0OiA1MHB4OyIgYWxp Z249ImxlZnQiIGNsYXNzPSJtYWluIj5cbgkJCQk8dHI+XG4JCQkJCTx0ZCBhbGlnbj0iY2VudGVy IiB2YWxpZ249InRvcCIgPiZuYnNwOwkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJPC90YWJsZT4t LT5cblxuXG5cblxuXG4JCQk8dGFibGU+XG4JCQkJPHRyPlxuCQkJCQk8dGQ+XG4JCQkJCQk8Rk9O VCBTSVpFPSI0IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPldoZW4gaXQncyB0aW1lLCBq b2luIHRoZSBXZWJleCBtZWV0aW5nIGhlcmUuPC9GT05UPlxuCQkJCQk8L3RkPlxuCQkJCTwvdHI+ XG4JCQkJPHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIw cHgiPiZuYnNwOzwvdGQ+PC90cj5cbgkJCQk8dHI+XG4JCQkJCTx0ZD5cbgkJCQkJCTxGT05UIFNJ WkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXIgKGFjY2Vz cyBjb2RlKTogNjQyIDg3OCAyODg8L0ZPTlQ+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJCTwv dGFibGU+XG4JCQlcbgkJCTx0YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2 NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQg U0laRT0iMiIgIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+NzNrbTVKa3o8L0ZPTlQ+PC90 ZD48L3RyPjwvdGFibGU+XG5cbiAgICAgICAgPHRhYmxlPlxuICAgICAgICAJPHRyIHN0eWxlPSJs aW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90 cj5cbgkJCTx0cj5cbgkJCQk8dGQgc3R5bGU9IndpZHRoOmF1dG8haW1wb3J0YW50OyAiPlxuCQkJ CQk8dGFibGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiIHN0eWxl PSJ3aWR0aDphdXRvO3dpZHRoOmF1dG8haW1wb3J0YW50O2JhY2tncm91bmQtY29sb3I6IzQzQTk0 MjsgYm9yZGVyOjBweCBzb2xpZCAjNDNBOTQyOyBib3JkZXItcmFkaXVzOjI1cHg7IG1pbi13aWR0 aDoxNjBweCFpbXBvcnRhbnQ7Ij5cbgkJCQkJCTx0cj5cbgkJCQkJCQk8dGQgYWxpZ249ImNlbnRl ciIgc3R5bGU9InBhZGRpbmc6MTBweCAzNnB4OyI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4 LmNvbS9pZXRmL2oucGhwP01USUQ9bWVmNDdkNDY3YWJjNzNjMGE4NjI1MmQwNGMwZmUyNGEyIiBz dHlsZT0iY29sb3I6I0ZGRkZGRjsgZm9udC1zaXplOjIwcHg7IHRleHQtZGVjb3JhdGlvbjpub25l OyI+Sm9pbiBtZWV0aW5nPC9hPjwvdGQ+XG4JCQkJCQk8L3RyPlxuCQkJCQk8L3RhYmxlPlxuCQkJ CTwvdGQ+XG4JCQk8L3RyPlxuCQk8L3RhYmxlPlxuXG4gPEZPTlQgc2l6ZT0iMiIgQ09MT1I9IiNG RjAwMDAiIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7Ij48L0ZPTlQ+XG48Rk9OVCBTSVpFPSIx IiBGQUNFPSJBUklBTCI+Jm5ic3A7PEJSPiZuYnNwOzxCUj48L0ZPTlQ+XG5cbiZuYnNwOyA8QlI+ PEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2 IiBGQUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwvRk9OVD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpF PSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxiPjxhIGhyZWY9J3RlbDolMkIxLTY1 MC00NzktMzIwOCwsKjAxKjY0Mjg3ODI4OCUyMyUyMyowMSonIHN0eWxlPSdjb2xvcjojMDBBRkY5 OyAgdGV4dC1kZWNvcmF0aW9uOm5vbmU7IGZvbnQtZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDE0 cHg7bGluZS1oZWlnaHQ6IDI0cHg7Jz4xLTY1MC00NzktMzIwODwvYT48L2I+IENhbGwtaW4gdG9s bCBudW1iZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+ICZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09M T1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48L0ZPTlQ+Jm5ic3A7IDxCUj48QlI+PEJSPlxuXG48 dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIw cHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPlxuXG48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklB TCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGZyb20g YSB2aWRlbyBzeXN0ZW0gb3IgYXBwbGljYXRpb248L0ZPTlQ+PEJSPjxGT05UIFNJWkU9IjIiIENP TE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+RGlhbDwvRk9OVD4gPGEgaHJlZj0ic2lwOjY0Mjg3 ODI4OEBpZXRmLndlYmV4LmNvbSI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9 ImFyaWFsIj42NDI4NzgyODhAaWV0Zi53ZWJleC5jb208L0ZPTlQ+PC9hPiZuYnNwOyA8QlI+PEZP TlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Zb3UgY2FuIGFsc28gZGlh bCAxNzMuMjQzLjIuNjggYW5kIGVudGVyIHlvdXIgbWVldGluZyBudW1iZXIuPC9GT05UPiAmbmJz cDsgPEJSPjwvRk9OVD4mbmJzcDsgPEJSPlxuXG48dGFibGUgY2VsbHBhZGRpbmc9IjAiIGNlbGxz cGFjaW5nPSIwIj48dHI+PHRkICBzdHlsZT0iY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFtaWx5OiBB cmlhbDtmb250LXNpemU6IDEycHg7IGZvbnQtd2VpZ2h0OiBib2xkOyBsaW5lLWhlaWdodDogMjRw eDsiPjxiPkpvaW4gdXNpbmcgTWljcm9zb2Z0IEx5bmMgb3IgTWljcm9zb2Z0IFNreXBlIGZvciBC dXNpbmVzczwvYj48L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQgc3R5bGU9ImNv bG9yOiAjMzMzMzMzOyBmb250LWZhbWlseTogQXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1o ZWlnaHQ6IDI0cHg7Ij5EaWFsIDxhIGhyZWY9IiBzaXA6NjQyODc4Mjg4LmlldGZAbHluYy53ZWJl eC5jb20iICAgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2NvbG9yOiMwMEFGRjkiPjY0Mjg3 ODI4OC5pZXRmQGx5bmMud2ViZXguY29tPC9hPjwvdGQ+PC90cj48L3RhYmxlPlxuXG4JCQk8dGFi bGUgc3R5bGU9IndpZHRoOiAxMDAlOyIgYWxpZ249ImxlZnQiIGNsYXNzPSJtYWluIj5cbiAgICAg ICAgICAgICAgICA8dHIgc3R5bGU9ImhlaWdodDogNzJweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj5c bgkJCQk8dHI+XG4JCQkJCTx0ZCBzdHlsZT0iaGVpZ2h0OiAyNHB4OyBjb2xvcjogIzAwMDAwMDsg Zm9udC1mYW1pbHk6QXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij5O ZWVkIGhlbHA/IEdvIHRvIDxhIGhyZWY9Imh0dHA6Ly9oZWxwLndlYmV4LmNvbSIgc3R5bGU9ImNv bG9yOiMwNDlGRDk7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+aHR0cDovL2hlbHAud2ViZXguY29t PC9hPlxuCQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4gICAgICAgICAgICAgICAgPHRyIHN0eWxlPSJo ZWlnaHQ6IDQ0cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JCQk8L3RhYmxlPlxuCQk8L3RkPlxu CTwvdHI+XG48L3RhYmxlPlxuDQpTVU1NQVJZOkFDRSBpbnRlcmltIG1lZXRpbmcgMg0KUFJJT1JJ VFk6NQ0KQ0xBU1M6UFVCTElDDQpCRUdJTjpWQUxBUk0NClRSSUdHRVI6LVBUNU0NCkFDVElPTjpE SVNQTEFZDQpERVNDUklQVElPTjpSZW1pbmRlcg0KRU5EOlZBTEFSTQ0KRU5EOlZFVkVOVA0KRU5E OlZDQUxFTkRBUg0K --0000000000001c9c52059e3da9d5-- From nobody Fri Feb 14 05:59: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 20681120074 for ; Fri, 14 Feb 2020 05:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 rVXpUdNGt1Ef for ; Fri, 14 Feb 2020 05:59:22 -0800 (PST) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 0BC50120041 for ; Fri, 14 Feb 2020 05:59:22 -0800 (PST) Received: by mail-vs1-xe2f.google.com with SMTP id x18so6277903vsq.4 for ; Fri, 14 Feb 2020 05:59:21 -0800 (PST) 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=bo8VE9LF1aROHdtJBFBjKBjL10UeWzJ4cPLr8A9Ac0w=; b=UtbuBFAMxkSjgH4lGDBiRqoHEjcssAV32Baovf4qI94BuhsNllCFRfeoS/ZNjltUI7 Bt9pS/Q++neQijlyn638fnvjzA2O6qjOwA3V05NNBwULRX4p6Q7T/mLTXOeh4zz2HEwS LYVZ5Ljui6IZjJOeIhQBHcuD6oXYLu5TxiM8tPo7Nq4AnS/QFjJc0dYZDitaAE5Ebp+r 7S2opaY5+/dMJw4PbsSBfSaWOeh1J4baP+CB1tT3G3J0t8Cd82Dr1Yihctb3Yffl4S15 XUaCM88WBvJCjJMeC8ER/tzuElCni40dHydwy18QIA2bj1G0eqrXQXgMj0UuoTanMxMk v6Sw== 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=bo8VE9LF1aROHdtJBFBjKBjL10UeWzJ4cPLr8A9Ac0w=; b=EgqDr61jtpYnzhrgdPo2YXtj7GMw1Jl6EZVpMxg3RWsX5NUpuT4jw8ZbynUtqgZd05 0S+JftVPWUN3v4zOET8dWqtdg5+/AXPsJwo5jxenRk8X75lqGWpgNWC2Zt1c/FKzgUev m6/1INquuSTishPaY5iipaMRrumGIDf8f0mdVqCWINDNeodx0wdsQBcRXFC8k2N9NvgS gS4S9rZu33pSoAFCsDqt9EahS6fB5FH/JKAkJQJa8wuRlJA7wYQMKte5kUAOCemvBd31 zXUp0rmUeFSJE3hGS3BT52oef7wU/wSHr3HyQLQ4pdptiHeQwy+o1Q55fglbcRZ+C1tI 19cQ== X-Gm-Message-State: APjAAAU8DV/Ztkai/8J4UMaDQkxnxnTlwyDLFtJtkYl6jOqnSL+2tpjv 75PdJlY//BPaxF47Q15hHn8Mnhc8M68BdG24iL5KEUzeWYqQlyoN X-Google-Smtp-Source: APXvYqwxOwWxssPjcbcOK+7E4F07fIflU9yVnCSflLsqoKdPq3mrDkP5NsWVZfoUtGVupXdvILZUHpVDJ1z5H5IkeoA= X-Received: by 2002:a05:6102:72b:: with SMTP id u11mr1530129vsg.69.1581688759327; Fri, 14 Feb 2020 05:59:19 -0800 (PST) MIME-Version: 1.0 References: <1097333699.127611581338115971.JavaMail.nobody@rva2rmd101.webex.com> In-Reply-To: From: Daniel Migault Date: Fri, 14 Feb 2020 08:59:08 -0500 Message-ID: To: Ace Wg Content-Type: multipart/alternative; boundary="000000000000a51dbe059e899ca0" Archived-At: Subject: Re: [Ace] Webex meeting invitation: ACE interim meeting 2 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: Fri, 14 Feb 2020 13:59:28 -0000 --000000000000a51dbe059e899ca0 Content-Type: text/plain; charset="UTF-8" Hi, The current draft agenda is available here: https://datatracker.ietf.org/meeting/interim-2020-ace-04/session/ace If you would like to present and you are not yet on the agenda, please let us know. There are still slots available. Presenters, please upload your presentations: https://datatracker.ietf.org/meeting/interim-2020-ace-04/session/ace Yours, Jim and Daniel ACE -- DRAFT AGENDA for Virtual Interim Meeting Tuesday, February 25, 2020 11:00 am | (UTC-05:00) Eastern Time (US & Canada) | 1 hr 30 mins MEETING INFO: * https://datatracker.ietf.org/meeting/interim-2020-ace-04/session/ace WEB CONFERENCE: https://ietf.webex.com/ietf/j.php?MTID=mef47d467abc73c0a86252d04c0fe24a2 PRESENT: AGENDA: 1. Note Well. https://www.ietf.org/about/note-well/ 2. Status update: * [draft-ietf-ace-key-groupcomm]( https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/) * [draft-ietf-ace-key-groupcomm-oscore]( https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm-oscore/) * [draft-ietf-ace-mqtt-tls-profile]( https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/) 3. [draft-ietf-ace-oscore-profile]( https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-profile/) updates: * https://github.com/ace-wg/ace-oscore-profile/pull/25 * https://github.com/ace-wg/ace-oscore-profile/issues/26 4. [draft-ietf-ace-pubsub-profile]( https://datatracker.ietf.org/doc/draft-ietf-ace-pubsub-profile/) On Mon, Feb 10, 2020 at 2:22 PM Daniel Migault wrote: > Please find the time slot for the ACE interim meeting 2. If there is an > topic you would like to discuss to discuss please provide them to the list > so we can set the agenda. > * > Yours, > Daniel > > ---------- Forwarded message --------- > From: ACE Working Group > Date: Mon, Feb 10, 2020 at 7:35 AM > Subject: Webex meeting invitation: ACE interim meeting 2 > To: > > > > ACE Working Group invites you to join this Webex meeting. > > Meeting number (access code): 642 878 288 > Meeting password: 73km5Jkz > > Tuesday, February 25, 2020 > 11:00 am | (UTC-05:00) Eastern Time (US & Canada) | 1 hr 30 mins > > Join meeting > > > *Join by phone* > Tap to call in from a mobile device (attendees only) > 1-650-479-3208 <%2B1-650-479-3208,,*01*642878288%23%23*01*> Call-in toll > number (US/Canada) > > *Join from a video system or application* > Dial 642878288@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 642878288.ietf@lync.webex.com > > Need help? Go to http://help.webex.com > > > > -- > Daniel Migault > Ericsson > -- Daniel Migault Ericsson --000000000000a51dbe059e899ca0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

The current draft agenda is availab= le here:

If you would=C2=A0lik= e to present and you are not yet on the agenda, please let us know. There a= re still slots available.

Presenters, please uploa= d your presentations:

Yours,=C2=A0
Jim and Daniel

ACE -- DRAFT AGENDA for Virtual= Interim Meeting
Tuesday, February 25, 2020 11:00 am =C2=A0| =C2=A0(UTC-= 05:00) Eastern Time (US & Canada) =C2=A0| =C2=A01 hr 30 mins

MEE= TING INFO:
* https://datatracker.ietf.org/meeting/interim-2020-ace= -04/session/ace


WEB CONFERENCE:
https://ietf.= webex.com/ietf/j.php?MTID=3Dmef47d467abc73c0a86252d04c0fe24a2

PRESENT:

AGENDA:
1. Note Well. =C2=A0https://www.ietf.org/about/note-well/
2. Sta= tus update:
* [draft-ietf-ace-key-groupcomm](https://datatracker.ietf.or= g/doc/draft-ietf-ace-key-groupcomm/)
* [draft-ietf-ace-key-groupcomm= -oscore](https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupco= mm-oscore/)
* [draft-ietf-ace-mqtt-tls-profile](https://datatrack= er.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/)
3. [draft-ietf-ace= -oscore-profile](https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-pr= ofile/)
updates:
* https://github.com/ace-wg/ace-oscore-profile/pull/25=
* ht= tps://github.com/ace-wg/ace-oscore-profile/issues/26
4. [draft-ietf-= ace-pubsub-profile](https://datatracker.ietf.org/doc/draft-ietf-ace-pubsub= -profile/)
=C2=A0
=C2=A0
=C2=A0

<= /div>
O= n Mon, Feb 10, 2020 at 2:22 PM Daniel Migault <mglt.ietf@gmail.com> wrote:
Please find the time slot= for the ACE interim meeting 2. If there is an topic you would like to disc= uss to discuss please provide them to the list so we can set the agenda.=C2= =A0
*=C2=A0
Yours,=C2=A0
Daniel

---------- Forwar= ded message ---------
From: ACE Working Group <messenger@webex.com>
D= ate: Mon, Feb 10, 2020 at 7:35 AM
Subject: Webex meeting invitation: ACE= interim meeting 2
To: <mglt.ietf@gmail.com>


=C2=A0
=09
ACE Working Group invites you to join this Webex meeting.
=C2= =A0
Meeting number (access code): 642 878 288
Meeting password: 73km5Jkz
=20
=C2= =A0
Tuesday, February 25, 2020
11:00 am=C2=A0=C2=A0|=C2=A0=C2=A0(UTC-05= :00) Eastern Time (US & Canada)=C2=A0=C2=A0|=C2=A0=C2=A01 hr 30 mins
=20
=C2=A0
Join meeting
= =C2=A0
=
Join by phone
Tap to call in from a mobile device (attendees only)
1-650-479-32= 08=C2=A0Call-in toll number (US/Can= ada)
=C2=A0
=
Join from a video system or ap= plication
Dial 642878288@ietf.webex.com
You can also dial 173.243.2.68 and e= nter your meeting number.
=C2=A0
= =
Join using Microsoft Lync or Microsoft Skype for Business
Dial 642878288.ietf@lync.webex.com
=C2=A0
Need help? Go to http:/= /help.webex.com
=C2=A0


--
Daniel Migault
Ericsson


--
Daniel Migault
Ericsson
--000000000000a51dbe059e899ca0-- From nobody Mon Feb 17 18:27: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 C8A591201E4 for ; Mon, 17 Feb 2020 00:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancynl.onmicrosoft.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 DQLask1waKZ4 for ; Mon, 17 Feb 2020 00:15:31 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03on0706.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe09::706]) (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 A1CE8120100 for ; Mon, 17 Feb 2020 00:15:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W0gasizcyb9aWWbo8Yl3IbDq+jWwPQ9spI7cb+T3pcn8NbbO5h6uZKUBpBG+wiCvDdfZQ1gHQIvoIn1MwFG/EWKa44hVDVaqDPspxuMkO57oeAmet7XpT3B7uGU4Yf2nQgkWsr25IsC/lHt/YHppv3I5xdHgoapvMGr9S4z82HqfAAdM6+DmZd1amfJy+o1wkyyHgyPsx6+PxeMLntgyxJR5frN6NUvuT5kglj+f6q0V5r7jVjXXumT1VJZAl+3VmVGhs0X2p13FkoRcuIB4EQbV/zR73PvxtcCv2f5LF92dJQpzELPwbSxY8OpSq6YrptATm3xH9rDJdfHrwkBRFw== 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=k3EvHq/NOfN6/x4VqmHWxeLNRgg0uWVAOQVZnFMrfoI=; b=EXENK4qBNSCX97Fn+EUJKLtS48DcG0HTtvdZEHW8/cbOOru6z+lar8i7LXgYc5xyYFc3a5yVeT7eDnXJvFLAHN1hlkSV7qW1+qg1nFJg9kBNSktWPwLBFDbq8ARjgvGqB4oaj7UlBSlOCX7sf96E9zu3Z+X8+y5MiB+jeXkodgkNHYNi9uSE/uxYiOJeKxkCmVfPHx9xB8B7Q3xW+xMCIXW3iuQwDgPiztd9G1HU07brfM7kqavCqZ6v/COivJcfPtL7X957GithtC6s6fqQcnaHLoTvq3NeHwbT6uj6b3qe9xm/aelCgp7RVGPRd2ewpFRH8TCz0nl10C8Bzss9GA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancynl.onmicrosoft.com; s=selector2-iotconsultancynl-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=k3EvHq/NOfN6/x4VqmHWxeLNRgg0uWVAOQVZnFMrfoI=; b=GuqgE3X4wbFcG14+PD/kqDkUrqFISC5amhLg2bdfdwTZ66OoAf78xn1sGqPpme3WrfHUqNoylN2nFFPok7GcPRk7K92OyaU3XWeBfdPFyo902/G+Aa1O2hQ/rLz/rbJqO+PsjFZMSHjrmxegzsb1V8lsY+P4m4mL+PhrvnYco6s= Received: from AM5P190MB0275.EURP190.PROD.OUTLOOK.COM (10.161.62.28) by AM5P190MB0420.EURP190.PROD.OUTLOOK.COM (10.161.92.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.25; Mon, 17 Feb 2020 08:15:24 +0000 Received: from AM5P190MB0275.EURP190.PROD.OUTLOOK.COM ([fe80::287f:e6f2:a17:a59f]) by AM5P190MB0275.EURP190.PROD.OUTLOOK.COM ([fe80::287f:e6f2:a17:a59f%7]) with mapi id 15.20.2729.032; Mon, 17 Feb 2020 08:15:24 +0000 From: Esko Dijk To: "Panos Kampanakis (pkampana)" , "ace@ietf.org" Thread-Topic: [Ace] I-D Action: draft-ietf-ace-coap-est-18.txt Thread-Index: AQHVxLs5a84UpdRvE0O3c4mcfUR7gKfd8DaAgEFZfBA= Date: Mon, 17 Feb 2020 08:15:24 +0000 Message-ID: References: <157833360921.8003.6238594444996424752@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=esko.dijk@iotconsultancy.nl; x-originating-ip: [2001:1c02:3103:6d00:a978:3cbd:1e0a:ed5b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d37ae892-bc51-49b8-b26d-08d7b3818a16 x-ms-traffictypediagnostic: AM5P190MB0420: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0316567485 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(39830400003)(396003)(346002)(376002)(199004)(189003)(2906002)(86362001)(66556008)(64756008)(66446008)(9686003)(76116006)(66476007)(66946007)(71200400001)(5660300002)(55016002)(44832011)(66574012)(966005)(81166006)(81156014)(186003)(508600001)(33656002)(6506007)(52536014)(8676002)(8936002)(110136005)(316002)(7696005)(53546011); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5P190MB0420; H:AM5P190MB0275.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: iotconsultancy.nl does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: P+lerzMoJQSg/M8k8TJU9RowAxo6bEPqNsHC8sa6x+/3q3LfIiJeo721ZbBwrO+zCA13vK2UXQ3Vdw6YtN4JgcfhW00JNsJjghEBW7LPZUBzMq+em6GS7tdxiy8u1bu0QVKTMYh6L+tNWYQVnqRrZVat0n6yo/gs9VVaeMz/oX9i/CIMesN7mpvGVMag6NHYYuDYW4gZ7yyh5HAqwUS3b8xL3kkVB/PZb0aLUwD6x7CBZkkR2EvMpVIJ1KErPLh2WgrZnpVaBWyVnyVzaUYOO+3EQ9wXkz7bQrfu834Sknu33CbDmFBLM9C1XYdrgTEyEcBcPZXaWp5rT19F+wTRRb/NvUJItDx5t1vMm3ZdFKLOw1Z2AtCY3IttbhsMbUhbBy5sZv97KaBBuVgKd47AhjdBtE3gP+6jHE/9VGlaz1PSkkbcX3j00IaMmcrrhn2qrxSmlRJTwD72WUq9BFiSrPcyHpN06GiyLwODi9flcKlDTEw8sYmfRYrkXRlqlr6wIbHKOB9JPnGApriXIDR7dA== x-ms-exchange-antispam-messagedata: 1naqP525j57Kr2tsbgQgzDrZfXf+2qjxT2YGqlVkyo3/TDs7oir9WO//MdExQZzlkzuQ1xU7wQkbRUULNVKySl+tyr1JDP0hLgqtGic4yTWY5oePcJoyIHrZAWSCF7N08ST4Ovbpx2nNyhxZk2y4wZnhLgYn0uliRIDdlD54m0gk+VPZoeRY8QgCBzrSzXBmZWzlA4l12I6QOXIGj+bxcw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: iotconsultancy.nl X-MS-Exchange-CrossTenant-Network-Message-Id: d37ae892-bc51-49b8-b26d-08d7b3818a16 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Feb 2020 08:15:24.3411 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: nNmPC5SPdhAvl1Ho6Wh+ylBPcMD4gaR7YLnFeRI9XQoxwlRs5eiNIyY6p09rOmkNOhth0bt8mw4L/6+idhdD2n6o6lQF2UTu3wRd511rDVQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5P190MB0420 Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-coap-est-18.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, 17 Feb 2020 08:15:34 -0000 SGVsbG8gUGFub3MsDQoNCkkgbm90aWNlZCBvbmUgc2VudGVuY2UgaW4gQXBwZW5kaXggQSB0aGF0 IHNlZW1zIGluY29uc2lzdGVudCB3aXRoIHRoZSByZXN0IG9mIHRoZSBJLUQsIG9yIGF0IGxlYXN0 IGdpdmVzIGFuIGluY29tcGxldGUgdmlldyA6DQoNCiAgIElmIHRoZSBjbGllbnQgaGFkIHJlcXVl c3RlZCBDb250ZW50LQ0KICAgRm9ybWF0IFRCRDI4NyAoYXBwbGljYXRpb24vcGtpeC1jZXJ0KSBi eSBxdWVyeWluZyAvZXN0L3NrYywgdGhlDQogICBzZXJ2ZXIgd291bGQgcmVzcG9uZCB3aXRoIGEg c2luZ2xlIERFUiBiaW5hcnkgY2VydGlmaWNhdGUgaW4gdGhlDQogICBtdWx0aXBhcnQtY29yZSBj b250YWluZXIuDQoNClRoZSBjbGllbnQgaGVyZSBjb3VsZCBhbHNvIGhhdmUgUE9TVGVkIHRvIHJl c291cmNlIC9lc3Qvc2VuIHdpdGggQWNjZXB0OlRCRDI4NyBvcHRpb24sIGluZGljYXRpbmcgaXQg aXMgcmVxdWVzdGluZyBUQkQyODcgZm9yIHNpbXBsZSBlbnJvbGxtZW50LCBhbmQgdGhlIHNlcnZl ciB3b3VsZCByZXNwb25kIHdpdGggYSBzaW5nbGUgREVSIGJpbmFyeSBjZXJ0aWZpY2F0ZSAoYXBw bGljYXRpb24vcGtpeC1jZXJ0KS4gU28gdGhlIGN1cnJlbnQgdGV4dCBtaWdodCBzdWdnZXN0IHRo YXQgUE9TVGluZyB0byAvZXN0L3NrYyBpcyB0aGUgb25seSB3YXkgdG8gcmVxdWVzdCBUQkQyODcg Zm9ybWF0LCB3aGljaCBpcyBub3QgdGhlIGNhc2Ugc2luY2UgL2VzdC9zZW4gYWxzbyBtYXkgc3Vw cG9ydCBpdCB0b28uDQoNCkJlc3QgcmVnYXJkcw0KRXNrbw0KDQoNCklvVGNvbnN1bHRhbmN5Lm5s ICB8ICBFbWFpbC9Ta3lwZTogZXNrby5kaWprQGlvdGNvbnN1bHRhbmN5Lm5sIA0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQWNlIDxhY2UtYm91bmNlc0BpZXRmLm9yZz4gT24g QmVoYWxmIE9mIFBhbm9zIEthbXBhbmFraXMgKHBrYW1wYW5hKQ0KU2VudDogTW9uZGF5LCBKYW51 YXJ5IDYsIDIwMjAgMTk6MTINClRvOiBhY2VAaWV0Zi5vcmc7IGktZC1hbm5vdW5jZUBpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFtBY2VdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtYWNlLWNvYXAtZXN0 LTE4LnR4dA0KDQpIZWxsbywNCg0KVGhpcyBpdGVyYXRpb24gYWRkcmVzc2VzIGFsbCBJRVNHIHJl dmlld3MuIE1vcmUgZGV0YWlscyBvbiB0aGUgZmVlZGJhY2sgYW5kDQpob3cgd2UgYWRkcmVzc2Vk IGl0IGFyZSBpbiB0aGUgZ2l0IGlzc3VlcyBoZXJlIA0KDQpSZ3MsDQpQYW5vcw0KDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBY2UgPGFjZS1ib3VuY2VzQGlldGYub3JnPiBP biBCZWhhbGYgT2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQpTZW50OiBNb25kYXksIEphbnVh cnkgMDYsIDIwMjAgMTowMCBQTQ0KVG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0KQ2M6IGFjZUBp ZXRmLm9yZw0KU3ViamVjdDogW0FjZV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1hY2UtY29hcC1l c3QtMTgudHh0DQoNCg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhl IG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQpkaXJlY3Rvcmllcy4NClRoaXMgZHJhZnQgaXMgYSB3 b3JrIGl0ZW0gb2YgdGhlIEF1dGhlbnRpY2F0aW9uIGFuZCBBdXRob3JpemF0aW9uIGZvcg0KQ29u c3RyYWluZWQgRW52aXJvbm1lbnRzIFdHIG9mIHRoZSBJRVRGLg0KDQogICAgICAgIFRpdGxlICAg ICAgICAgICA6IEVTVCBvdmVyIHNlY3VyZSBDb0FQIChFU1QtY29hcHMpDQogICAgICAgIEF1dGhv cnMgICAgICAgICA6IFBldGVyIHZhbiBkZXIgU3Rvaw0KICAgICAgICAgICAgICAgICAgICAgICAg ICBQYW5vcyBLYW1wYW5ha2lzDQogICAgICAgICAgICAgICAgICAgICAgICAgIE1pY2hhZWwgQy4g UmljaGFyZHNvbg0KICAgICAgICAgICAgICAgICAgICAgICAgICBTaGFoaWQgUmF6YQ0KCUZpbGVu YW1lICAgICAgICA6IGRyYWZ0LWlldGYtYWNlLWNvYXAtZXN0LTE4LnR4dA0KCVBhZ2VzICAgICAg ICAgICA6IDUxDQoJRGF0ZSAgICAgICAgICAgIDogMjAyMC0wMS0wNg0KDQpBYnN0cmFjdDoNCiAg IEVucm9sbG1lbnQgb3ZlciBTZWN1cmUgVHJhbnNwb3J0IChFU1QpIGlzIHVzZWQgYXMgYSBjZXJ0 aWZpY2F0ZQ0KICAgcHJvdmlzaW9uaW5nIHByb3RvY29sIG92ZXIgSFRUUFMuICBMb3ctcmVzb3Vy Y2UgZGV2aWNlcyBvZnRlbiB1c2UgdGhlDQogICBsaWdodHdlaWdodCBDb25zdHJhaW5lZCBBcHBs aWNhdGlvbiBQcm90b2NvbCAoQ29BUCkgZm9yIG1lc3NhZ2UNCiAgIGV4Y2hhbmdlcy4gIFRoaXMg ZG9jdW1lbnQgZGVmaW5lcyBob3cgdG8gdHJhbnNwb3J0IEVTVCBwYXlsb2FkcyBvdmVyDQogICBz ZWN1cmUgQ29BUCAoRVNULWNvYXBzKSwgd2hpY2ggYWxsb3dzIGNvbnN0cmFpbmVkIGRldmljZXMg dG8gdXNlDQogICBleGlzdGluZyBFU1QgZnVuY3Rpb25hbGl0eSBmb3IgcHJvdmlzaW9uaW5nIGNl cnRpZmljYXRlcy4NCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhp cyBkcmFmdCBpczoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt YWNlLWNvYXAtZXN0Lw0KDQpUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFi bGUgYXQ6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hY2UtY29hcC1l c3QtMTgNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1h Y2UtY29hcC1lc3QtMTgNCg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZh aWxhYmxlIGF0Og0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYt YWNlLWNvYXAtZXN0LTE4DQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBs ZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxp emVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0K SW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0K ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkFjZSBtYWlsaW5nIGxpc3QNCkFjZUBpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UNCg== From nobody Mon Feb 17 18:39: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 673C4120854; Mon, 17 Feb 2020 07:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 1An5BC8N6CGd; Mon, 17 Feb 2020 07:55:33 -0800 (PST) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2085.outbound.protection.outlook.com [40.107.20.85]) (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 69D82120086; Mon, 17 Feb 2020 07:55:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gjY2PhpqaFdVDcdyvOxvTshr1R3y6voCj1a5CQQGBWBbEXG9/aPuW5IA5vdgovjQwHK7ayWMK+mXaaaVNgj2wEM8eceCMehN91DvKsMGtkqw4Dp9SnFkiP/Cr/V/T9f0CZM64ggyksb9rljwO2p971P6JTgDVbSeAlXk+yjQyho5C8pzTiJGKUQ9/9FhDFL93CgJKKCTH+GJloW9I2rR+htk/8AigEYaAL8nhPgALLg/8FNbRsj+Cz+GsQ/g0VGHuSdWWtZl4seZ6ZgSPdHJ38lkUh41aqHMy2DaJqcwx6zboTSBWwrT1dZOxUVrumbbpymy03Q1VRRdWEiTwc9lgg== 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=bZgop6+7RVwtiYQDkXR5e3XdL3x6ah3HCUXAP6LZ55g=; b=ggoYPjNeSjj3l58Rgx1JLx8zbygkNaa36xJNX42xTP1E/F1XOAFA/OTf6IyubLDp9iM/DFu9dUTewyNIo4vzrzx2ZoR1W1UWlbUqCJo9GWyPqHPCMeOBTFSt2CgJG3bekF6IeBkRzulHuHi142x8pgZFzs/lhdQPQEPvkGrppT9SJvyEsbz0yyLc26JDX7Le8nzAZ66M34pmDJsuNH/3JMjijnBh2GI1OGmAVqrDCj82W+gbxspVjwznC/yhgPhxcssHNpQ/jeaafqLdvuqsxD/kHhIInzE2mbZXx8BcGCHKckfExE5jOlMFtYGf8xBTDA3GiXBK0A9DuhYEB01m5w== 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=bZgop6+7RVwtiYQDkXR5e3XdL3x6ah3HCUXAP6LZ55g=; b=Oot8JeIM27rfTKK/AwjBT1IwHaRo8j37pacTzivHElzAtuKGYVXUPmLfl1YZsqyekKLc76W7RSB5LKkJdPlEYc2fu1l5mLwy+/Wi1ERrXUmEqjordpU7TI3x/ujylKp6DxU9ZFbLaJgvkhUPdP77vIGfbXbVrs6YRjpFHGoVdqI= Received: from AM6PR07MB4053.eurprd07.prod.outlook.com (52.134.117.139) by AM6PR07MB4727.eurprd07.prod.outlook.com (20.177.38.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.18; Mon, 17 Feb 2020 15:55:29 +0000 Received: from AM6PR07MB4053.eurprd07.prod.outlook.com ([fe80::7537:e135:422d:c5a7]) by AM6PR07MB4053.eurprd07.prod.outlook.com ([fe80::7537:e135:422d:c5a7%5]) with mapi id 15.20.2750.016; Mon, 17 Feb 2020 15:55:29 +0000 From: Francesca Palombini To: Benjamin Kaduk , Ace Wg CC: "draft-ietf-ace-oscore-profile@ietf.org" Thread-Topic: [Ace] AD review of draft-ietf-ace-oscore-profile-08 Thread-Index: AQHVxXkvf17L6O/aSkulV21bFzeHXqgB6oAAgAcZCgCAFtegAA== Date: Mon, 17 Feb 2020 15:55:29 +0000 Message-ID: <8B7C0C63-3F8D-478A-907C-E424649FC6C5@ericsson.com> References: <20200107163851.GV57294@kduck.mit.edu> <4086FADE-7993-47F6-9292-FDD7FC5457B4@ericsson.com> <20200203040600.GM91553@kduck.mit.edu> In-Reply-To: <20200203040600.GM91553@kduck.mit.edu> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [192.176.1.84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3a22998b-24f0-438e-3a5b-08d7b3c1d000 x-ms-traffictypediagnostic: AM6PR07MB4727: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0316567485 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(346002)(39860400002)(366004)(376002)(189003)(199004)(30864003)(5660300002)(8936002)(36756003)(33656002)(26005)(2906002)(91956017)(76116006)(66946007)(66476007)(81166006)(6512007)(64756008)(110136005)(8676002)(966005)(316002)(44832011)(66446008)(86362001)(81156014)(4326008)(71200400001)(186003)(6486002)(6506007)(2616005)(66556008)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB4727; H:AM6PR07MB4053.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sxWNWhFgoHaOWHcNT8o5IfoggtQ0tfPOomVXGxAbZ8buYylowW/KzmcWq4yusDZiQAVxwtUUX3WMxL4pFoddgZdnuunuwGjyNOvqCJkMSWq6sF04EYJhe6HQWDAxctPC4jOEzVnVVknQWICsmpXhlg0Vm5KY5QBjA/82RqMPUh8EEppsNnX7R8gzQUVxaQxcOpxNTvYGvLk/cg+oO2vJAcjqrw+LDEIWZyRl4OwWKLvbzm+WLiGBfG+ADtWJIgTsams4TYvEW91QlKNmBq4zEyNj6Yq3RAvJElnFuOQaL1wvtnppaDAylf/q4LEtjV37DUNFcVWyrDBzaLOcy4ljkCaORwC6KUM1EbHP5nORyFhyiCMxaKD75P4ShwPrLXV5M04s3PsRmHuKMQN29TM8Xv1DX3Zz7x8gOtMVPoYcBFDuQgPbRPXO+1jJ9yhL0DyvQZNVfA4KXxoyKafefKMFMB23fN1ScgZ6bSDQmoQNEgzxBqGJgOUE7h//ONSb0fiBWkOaWCI2gR06TtEHJkSQ2A== x-ms-exchange-antispam-messagedata: I35pOLB9Ai/WDCtF8ajwj6v5asx+aflwmAVMwH5Wj3x7xucNxBpxZ1DBZKWBzv0DovoYVkCGnydHPjx8/7GMUe21ZKgAYpLjEcIVY9mmpGZcqnZLg4IyfwW224lBg8mfVYzR5edxHpTGv867ekN2KQ== 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: 3a22998b-24f0-438e-3a5b-08d7b3c1d000 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Feb 2020 15:55:29.4091 (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: 3EvB6qdss29l11a0vW0e8MHB9VSoaSqNDn2fQmDy7qvuomJAEM7De5Lc1EuGhisOOurIxwrbJ+yw1WEoZo1Dqjl/I0uShtNO7oXgeGEDd2QCKCprDbD2ds0r6qytHUbd X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB4727 Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-oscore-profile-08 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, 17 Feb 2020 15:55:38 -0000 SGkgQmVuLA0KDQpJIGFtIG5vdyBkb25lIHdpdGggdXBkYXRpbmcgdGhlIGRyYWZ0IGZvbGxvd2lu ZyBtb3N0IG9mIHlvdXIgcmV2aWV3IGNvbW1lbnRzLiBPdXQgb2YgdGhlIDEwNSwgSSBoYXZlIGlt cGxlbWVudGVkIDg4IGluIHRoZSBkcmFmdCwgd2hpbGUgdGhvc2UgbGVmdCBuZWVkIGFncmVlbWVu dCBpbiB0aGUgd2cgYXMgcHJldmlvdXNseSBtZW50aW9uZWQsIG9yIHJlcXVpcmUgeW91ciBPSyAo c2VlIGlubGluZSkuDQoNCllvdSBjYW4gc2VlIHRoZSByZXN1bHQgb2YgdGhlIHVwZGF0ZSBpbiB0 aGUgUFIgaGVyZTogaHR0cHM6Ly9naXRodWIuY29tL2FjZS13Zy9hY2Utb3Njb3JlLXByb2ZpbGUv cHVsbC8yNSAgSWYgeW91IGdpdmUgbWUgdGhlIGdvLWFoZWFkLCBJIHdpbGwgbWVyZ2UgdGhpcyBQ UiBhbmQgc3VibWl0IGEgbmV3IHZlcnNpb24sIGFuZCB0aGVuIHdlIGNhbiBjb250aW51ZSB3b3Jr aW5nIG9uIHRoZSBvcGVuIGlzc3Vlcy4NCg0KVGhlc2Ugb3BlbiBpc3N1ZXMgYXJlOg0KDQoqIFRo ZSBtZWNoYW5pc20gb2YgbGV0dGluZyB0aGUgUlMgcGljayB0aGUgaWRlbnRpZmllciBvZiB0aGUg Y2xpZW50IGlzIG5vdCB3b3J0aCB0aGUgYWRkaXRpb25hbCBjb21wbGV4aXR5Lg0KCTYsIDcsIDMy LCA2MSwgNjUsDQoqIFJlY29tbWVuZGF0aW9uIGFib3V0IGxlbmd0aCBvZiBub25jZXMgTjEgYW5k IE4yIHRvIHVzZS4NCgk1LCA1Mg0KKiBEZWZpbmUgYW5kIHJlZ2lzdGVyIDIgbmV3IEFDRSBwYXJh bWV0ZXJzIHRvIHRyYW5zcG9ydCB0aGUgbm9uY2VzIHVzZWQgaW4gdGhlIGV4Y2hhbmdlLCBpbnN0 ZWFkIG9mIHVzaW5nICJjbm9uY2UiLg0KCTMsICA1MywgNjANCiogQ2hlY2sgd2l0aCBJQU5BDQoJ MTAyDQoNCkkgaG9wZSB0byBkaXNjdXNzIHRoZXNlIGluIHRoZSBtYWlsaW5nIGxpc3QgKGNvbnRp bnVpbmcgb24gdGhlIHNlcGFyYXRlIHRocmVhZCksIGFuZCBhdCB0aGUgaW50ZXJpbS4gDQoNCkkg d2lsbCBjdXQgYW5kIHBhc3RlIHRoZSByZXN0ICg0NiAsIDQ3LCAgNTggLCA2NyAsIDkyICsgYSBj b3VwbGUgb2YgbW9yZSkgd2hpY2ggSSBoYXZlIGFuc3dlcmVkIGJlbG93LCB3aGF0ZXZlciBpcyBu b3QgcmVwb3J0ZWQgYmVsb3cgSSBmb3VuZCBubyBpc3N1ZSBpbiBkb2luZyB0aGUgbW9kaWZpY2F0 aW9ucyB5b3Ugc3VnZ2VzdGVkLCBvciBpcyBjb3ZlcmVkIGJ5IHRoZSBvcGVuIHBvaW50cyBJIG1l bnRpb25lZC4gUGxlYXNlIGRvIGJyaW5nIGFueSBvZiB0aG9zZSBJIGRvIG5vdCB0b3VjaCBvbiB1 cCBhZ2FpbiBpZiB5b3UgZmVlbCB0aGV5IHdlcmUgbm90IHNvbHZlZCBpbiB0aGUgUFIuDQoNClRo YW5rcyBhZ2FpbiBmb3IgeW91ciBleHRlbnNpdmUgcmV2aWV3IQ0KRnJhbmNlc2NhDQoNCu+7v09u IDAzLzAyLzIwMjAsIDA1OjA2LCAiQmVuamFtaW4gS2FkdWsiIDxrYWR1a0BtaXQuZWR1PiB3cm90 ZToNCiAgICA+IDI5LiAgICAgICBUaGUgQVMgTVVTVCBhbHNvIGFzc2lnbiBhbiBpZGVudGlmaWVy IHRvIHRoZSBSUyAoc2VydmVySWQpLCBNQVkNCiAgICA+ICAgICAgICBhc3NpZ24gYW4gaWRlbnRp ZmllciB0byB0aGUgY2xpZW50IChjbGllbnRJZCksIGFuZCBNQVkgYXNzaWduIGFuDQogICAgPiAg ICAgICAgaWRlbnRpZmllciB0byB0aGUgY29udGV4dCAoY29udGV4dElkKS4gIFRoZXNlIGlkZW50 aWZpZXJzIGFyZSB0aGVuDQogICAgPiAgICAgICAgdXNlZCBhcyBTZW5kZXIgSUQsIFJlY2lwaWVu dCBJRCBhbmQgSUQgQ29udGV4dCBpbiB0aGUgT1NDT1JFIGNvbnRleHQNCiAgICA+ICAgICAgICBh cyBkZXNjcmliZWQgaW4gc2VjdGlvbiAzLjEgb2YgW0ktRC5pZXRmLWNvcmUtb2JqZWN0LXNlY3Vy aXR5XS4gIFRoZQ0KICAgID4gICAgICAgIGNvdXBsZSAoY2xpZW50IGlkZW50aWZpZXIsIGNvbnRl eHQgaWRlbnRpZmllcikgTVVTVCBiZSB1bmlxdWUgaW4gdGhlDQogICAgPiAgICAgICAgc2V0IG9m IGFsbCBjbGllbnRzIG9uIGEgc2luZ2xlIFJTLiAgTW9yZW92ZXIsIHdoZW4gYXNzaWduZWQsDQog ICAgPiAgICAgICAgc2VydmVySWQsIGNsaWVudElkIGFuZCBjb250ZXh0SWQgTVVTVCBiZSBpbmNs dWRlZCBpbiB0aGUNCiAgICA+ICAgICAgICBPU0NPUkVfU2VjdXJpdHlfQ29udGV4dCwgYXMgZGVm aW5lZCBpbiBTZWN0aW9uIDMuMi4xLg0KICAgID4gICAgIA0KICAgID4gICAgIFdoZW4gY2VydGFp biBmaWVsZHMgYXJlIG9wdGlvbmFsLCB3ZSB0eXBpY2FsbHkgaGF2ZSB0byBhc2sgd2hldGhlciBp dCdzDQogICAgPiAgICAgcG9zc2libGUgZm9yIHRoZSB0d28gcGFydGllcyB0byBkaXNhZ3JlZSBh Ym91dCB3aGV0aGVyIHRoZSBmaWVsZCBpcw0KICAgID4gICAgIHByZXNlbnQuICBJSVVDLCB0aGUg T1NDT1JFIGNvbnRleHQgZGVyaXZhdGlvbiBwcm9jZWR1cmUgaW5jbHVkZXMgZW5vdWdoDQogICAg PiAgICAgaW5mb3JtYXRpb24gdG8gcHJldmVudCB0aGF0IHBvc3NpYmlsaXR5LCBidXQgaXQgd291 bGQgYmUgZ29vZCBpZiBzb21lb25lDQogICAgPiAgICAgd291bGQgY29uZmlybSB0aGF0Lg0KICAg ID4gDQogICAgPiBGUDogVGhhdCBpcyBjb3JyZWN0LCBhIG51bWJlciBvZiBmaWVsZHMgaGF2ZSBk ZWZhdWx0IHZhbHVlcyB3aGVuIG5vbiBwcmVzZW50LiBIa2RmLCBhbGcsIHNhbHQsIGNvbnRleHRJ ZCwgcnBsLiBPbiB0aGUgb3RoZXIgaGFuZCwgbXMsIGNsaWVudElkIGFuZCBzZXJ2ZXJJZCBuZWVk IHRvIGJlIHNldC4NCiAgICANCiAgICBIbW0sIHNvIHRoZXJlIGlzIG5vdCBhIGdyZWF0IG1lY2hh bmlzbSB0byBkaXN0aW5ndWlzaCAiYWJzZW50IiBmcm9tDQogICAgInByZXNlbnQgd2l0aCBkZWZh dWx0IHZhbHVlIiwgYnV0IHRoZSBwcmFjdGljYWwgY29uc2VxdWVuY2VzIG9mIHN1Y2ggYW4NCiAg ICBhdHRhY2sgc2VlbSBxdWl0ZSBsaW1pdGVkLg0KDQpGUDogVGhhdCBpcyByaWdodC4gSSBkaWQg bm90IGFkZCBhbnkgdGV4dCBhYm91dCB0aGlzLCBhcyB0aGlzIGlzIG1vcmUgT1NDT1JFIGltcGxp Y2F0aW9uLg0KICAgIA0KICAgID4gICAgIA0KICAgID4gMzQuICAgICAgICAgICAgICJhY2Nlc3Nf dG9rZW4iIDogaCdhNTAzNzY3NDY1NmQ3MDUzNjU2ZTczIC4uLicNCiAgICA+ICAgICAgICAgICAg ICAgKHJlbWFpbmRlciBvZiBhY2Nlc3MgdG9rZW4gb21pdHRlZCBmb3IgYnJldml0eSknLA0KICAg ID4gICAgIA0KICAgID4gICAgIEluIGFkZGl0aW9uIHRvIHRoZSBpbnZhbGlkLUNCT1ItZGlhZ25v c3RpYy1ub3RhdGlvbi1zeW50YXggY29tbWVudCwgd2UNCiAgICA+ICAgICBhbHNvIGhhdmUgdW5i YWxhbmNlZCBxdW90ZXMuDQogICAgPiANCiAgICA+IEZQOiBSaWdodCwgYnV0IHRoaXMgaXMgbm90 IHZhbGlkIENCT1IgZGlhZ25vc3RpYyBub3RhdGlvbiBzeW50YXggYW55d2F5LCBkbyB5b3UgaGF2 ZSBhIGJldHRlciBpZGVhPyBJIGRvIG5vdCB0aGluayBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gaGF2 ZSB0aGUgZnVsbCB0b2tlbiBoZXJlLiBXaWxsIHJlbW92ZSB0aGUgdW5iYWxhbmNlZCBxdW90ZS4N CiAgICANCiAgICBUaGlzIGlzIHByb2JhYmx5IG1hbmFnZWFibGUsIHRob3VnaCB3ZSBkbyBvZnRl biBzZWUgcGVvcGxlIHB1dCBhIGRpc2NsYWltZXINCiAgICBiZWZvcmUgdGhlIGV4YW1wbGUgdGhh dCA8Y2VydGFpbiBmaWVsZHM+IGFyZSB0cnVuY2F0ZWQgZm9yIHJlYWRhYmlsaXR5Ow0KICAgIHNv bWUgb3RoZXIgQURzIG1heSBoYXZlIG90aGVyIHN1Z2dlc3Rpb25zLCB0b28uDQoNCkZQOiBUaGFu a3MgZm9yIHRoZSBpbnB1dCB0ZXh0IDopIE5vdyBhZGRlZC4NCg0KICAgIC4uLg0KDQogICAgPiA0 My4gICAgICAgaGtkZjogIFRoaXMgcGFyYW1ldGVyIGlkZW50aWZpZXMgdGhlIE9TQ09SRSBIS0RG IEFsZ29yaXRobS4gIEZvciBtb3JlDQogICAgPiAgICAgICAgICAgaW5mb3JtYXRpb24gYWJvdXQg dGhpcyBmaWVsZCwgc2VlIHNlY3Rpb24gMy4xIG9mDQogICAgPiAgICAgICAgICAgW0ktRC5pZXRm LWNvcmUtb2JqZWN0LXNlY3VyaXR5XS4gIFRoZSB2YWx1ZXMgdXNlZCBNVVNUIGJlDQogICAgPiAg ICAgICAgICAgcmVnaXN0ZXJlZCBpbiB0aGUgSUFOQSAiQ09TRSBBbGdvcml0aG1zIiByZWdpc3Ry eSBhbmQgTVVTVCBiZQ0KICAgID4gICAgICAgICAgIEhNQUMtYmFzZWQgSEtERiBhbGdvcml0aG1z LiAgVGhlIHZhbHVlIGNhbiBlaXRoZXIgYmUgdGhlIGludGVnZXINCiAgICA+ICAgICANCiAgICA+ ICAgICBJdCdzIGEgbGl0dGxlIHVuZm9ydHVuYXRlIHRoYXQgd2UgYmFzaWNhbGx5IGFyZSByZWx5 aW5nIG9uICJJIGtub3cgaXQNCiAgICA+ICAgICB3aGVuIEkgc2VlIGl0IiBmb3IgZGV0ZXJtaW5p bmcgd2hpY2ggYWxnb3JpdGhtcyBhcmUgSEtERiBhbGdvcml0aG1zLg0KICAgID4gDQogICAgPiBG UDogQWdyZWVkLCBidXQgd2UgZG9u4oCZdCByZWFsbHkgaGF2ZSBhbm90aGVyIHdheSB0byBzYXkg dGhpcy4gSWYgeW91IG9yIENPU0UgZXhwZXJ0cyAoSmltKSBoYXZlIGFueSBpZGVhIHBsZWFzZSBs ZXQgdXMga25vdy4gICAgDQogICAgDQogICAgSSB0aGluayB3ZSBpbmhlcml0ZWQgdGhpcyBmcm9t IEpPU0UgOi0vDQoNCkZQOiBUaGF0IHdvdWxkIG1ha2Ugc2Vuc2UuIEkgaGF2ZSBub3QgZG9uZSBh bnkgbW9kaWZpY2F0aW9ucyBoZXJlLCBzdGlsbCB3YWl0aW5nIGZvciBtb3JlIGlucHV0IGlmIGFu eS4NCiAgICANCiAgICA+ICAgICBBbHNvLCAiSEtERiIgZXhwYW5kcyB0byAiSE1BQy1iYXNlZCBF eHRyYWN0LWFuZC1FeHBhbmQgS2V5IERlcml2YXRpb24NCiAgICA+ICAgICBGdW5jdGlvbiIsIGku ZS4sIGlzIGRlZmluaXRpb25hbGx5IEhNQUMtYmFzZWQuICBTbyB0aGlzIHNob3VsZCBiZQ0KICAg ID4gICAgIHJld29yZGVkIHRvIHJlZmxlY3QgdGhlIGFjdHVhbCBpbnRlbnQuDQogICAgPiANCiAg ICA+IEZQOiBSaWdodCwgdGhhdCBpcyBiZWNhdXNlIENPU0UgYWxzbyBkZWZpbmVzIEhLREYgdXNp bmcgQUVTLU1BQywgc2VlIFRhYmxlIDEyIG9mIFJGQzgxNTIsIHNvIHdlIG5lZWRlZCB0byBzcGVj aWZ5IHRoYXQgb25seSBITUFDLWJhc2VkIGNhbiBiZSB1c2VkLg0KICAgIA0KICAgIE9vZiwgcmF0 aGVyIHVuZm9ydHVuYXRlIElNTyB0aGF0IHRoZSB0ZXJtaW5vbG9neSB3YXMgb3ZlcmxvYWRlZCBi eSBSRkMNCiAgICA4MTUyLg0KDQpGUDogQWdyZWVkLiBBZ2FpbiBubyBtb2RpZmljYXRpb25zIGZv bGxvd2luZyB0aGlzIHBvaW50IChvciB0aGUgYW5hbG9nb3VzIDQ0LiBBYm91dCBBRUFEIGFsZyku DQogICAgDQogICAgPiA0Ni4gICAgICAgcnBsOiAgVGhpcyBwYXJhbWV0ZXIgaXMgdXNlZCB0byBj YXJyeSB0aGUgT1NDT1JFIHZhbHVlLCBlbmNvZGVkIGFzIGENCiAgICA+ICAgICAgICAgICBic3Ry LiAgVGhpcyBwYXJhbWV0ZXIgaWRlbnRpZmllcyB0aGUgT1NDT1JFIFJlcGxheSBXaW5kb3cgU2l6 ZSBhbmQNCiAgICA+ICAgICAgICAgICBUeXBlIHZhbHVlLCB3aGljaCBpcyBhIGJ5dGUgc3RyaW5n LiAgRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQNCiAgICA+ICAgICAgICAgICB0aGlzIGZpZWxk LCBzZWUgc2VjdGlvbiAzLjEgb2YgW0ktRC5pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5XS4NCiAg ICA+ICAgICAgICAgICBJbiBKU09OLCB0aGUgInJwbCIgdmFsdWUgaXMgYSBCYXNlNjQgZW5jb2Rl ZCBieXRlIHN0cmluZy4gIEluDQogICAgPiAgICAgICAgICAgQ0JPUiwgdGhlICJycGwiIHR5cGUg aXMgYnN0ciwgYW5kIGhhcyBsYWJlbCA4Lg0KICAgID4gICAgIA0KICAgID4gICAgIEkgdHJpZWQg dG8gZm9sbG93IHRoZSByZWZlcmVuY2UsIGJ1dCBJIGNvdWxkbid0IHJlYWxseSBmaW5kIGENCiAg ICA+ICAgICBkZXNjcmlwdGlvbiBvZiB0aGUgZW5jb2RpbmcgZm9yIHRoaXMgYXMgYSBieXRlIHN0 cmluZyAoZXNwZWNpYWxseQ0KICAgID4gICAgIG5vdGV3b3J0aHkgc2luY2Ugd2UgY2xhaW0gdGhh dCBpdCByZXByZXNlbnRzIGJvdGggc2l6ZSBhbmQgdHlwZSkuDQogICAgPiAgICAgKFJlbGF0ZWRs eSwgSSdtIG5vdCBzdXJlIHdoeSBpdCdzIGFsbG93ZWQgdG8gYmUgZWl0aGVyIGJzdHIgb3IgaW50 LikNCiAgICA+ICAgICANCiAgICA+IEZQOiBSaWdodCwgdGhpcyBpcyBhbiBvbGQgcmVmZXJlbmNl LCB3aGVyZSB3ZSBhY3R1YWxseSBnYXZlIGEgZGVmYXVsdCBlbmNvZGluZyBmb3IgcnBsLCBJIGJl bGlldmUuIE5vdyB0aGlzIGlzIGVudGlyZWx5IHVwIHRvIHRoZSBhcHBsaWNhdGlvbi4gSSB3b3Vs ZCBrZWVwIHRoaXMgYXMgYnN0ciBhbmQgc3BlY2lmeSB0aGF0IGl0IGlzIGFueSBmb3JtYXQgd3Jh cHBlZCBpbiBhIGJzdHIuDQogICAgDQogICAgIlVwIHRvIHRoZSBhcHBsaWNhdGlvbiIgbWVhbmlu ZyBrbm93biBieSBwcmlvciBhZ3JlZW1lbnQgYW1vbmcgYWxsIHRocmVlIG9mDQogICAgQywgQVMs IGFuZCBSUz8NCiAgICANCkZQOiBUaGVyZSBpcyBubyBuZWVkIGZvciB0aGUgMyBub2RlcyB0byBi ZSBpbiBhZ3JlZW1lbnQgb24gdGhlIHJlcGxheSB3aW5kb3cgb24gdGhlIFJTLiBBZnRlciB0aGlu a2luZyBhIGJpdCBtb3JlIGFib3V0IHRoaXMsIEkgdGhpbmsgSSdkIGxpa2UgdG8gcmVtb3ZlIHRo aXMgcGFyYW1ldGVyIGNvbXBsZXRlbHkgZnJvbSB0aGlzIG9iamVjdC4gVGhlIGlkZWEgaGVyZSB3 YXMgdGhhdCB0aGUgQVMgaXMgYWJsZSB0byB0ZWxsIHRoZSBSUyB3aGF0IHR5cGUgYW5kIHNpemUg b2YgcmVwbGF5IHdpbmRvdyB0byB1c2UsIGJ1dCBJIGRvIG5vdCBzZWUgYSByZWFzb24gd2h5IHRo ZSBBUyBzaG91bGQgc2VuZCB0aGlzIGluZm8gdG8gdGhlIFJTLiBXaW5kb3cgdHlwZSBhbmQgc2l6 ZSBpcyBpbXBsZW1lbnRhdGlvbiByZWxhdGVkLCBhbmQgZWFjaCBSUyBub2RlIGNhbiBoYXZlIGl0 cyBvd24uIA0KDQogICAgPiBBbHNvIEkgbmVlZCB0byBmaXggYSBjb3VwbGUgb2YgbWlzdGFrZXM6 IOKAnE9TQ09SRSB2YWx1ZeKAnSBpcyB3cm9uZzsg4oCcUmVwbGF5IFdpbmRvd+KAnSBhbmQgbm90 ICJTaXplIGFuZCBUeXBlIi4gQWxzbywgSSB0aGluayB3ZSBuZWVkIHRvIGRlZmluZSBhIG5ldyBJ QU5BIHJlZ2lzdHJ5IGZvciBycGwgd2l0aCAwIGFzIGRlZmF1bHQsIHNvIHRoYXQgYXBwbGljYXRp b25zIGNhbiBkZWZpbmUgdGhlaXIgZm9ybWF0Lg0KICAgIA0KICAgIEknbSBub3QgZW50aXJlbHkg c3VyZSBJIHVuZGVyc3RhbmQgdGhhdCB0aGUgcmVnaXN0cnkgaXMgZm9yIChpLmUuLCB3aGF0IHlv dQ0KICAgIHByb3Bvc2UpLg0KDQpGUDogZGlzcmVnYXJkIHRoYXQuIEkgd2FzIHRoaW5raW5nIHdl IG1pZ2h0IHdhbnQgdG8gaGF2ZSBhIHJlZ2lzdHJ5IGZvciBkaWZmZXJlbnQgdHlwZXMgb2YgcmVw bGF5IHdpbmRvd3MsIGJ1dCBjb25zaWRlcmluZyB0aGUgY29tbWVudCBhYm92ZSBJIGRvIG5vdCB0 aGluayBpdCdzIG5lZWRlZCBhbnltb3JlLg0KICAgIA0KICAgID4gICAgIFNlY3Rpb24gNA0KICAg ID4gICAgIA0KICAgID4gNDcuICAgIENhbiB3ZSBnZXQgc29tZSBDRERMIG9yIHNpbWlsYXIgZm9y IGJvdGggQy10by1SUyBhbmQgUlMtdG8tQyAoaW4gdGhlDQogICAgPiAgICAgcmVzcGVjdGl2ZSBz dWJzZWN0aW9ucyk/DQogICAgPiAgICAgDQogICAgPiBGUDogSSBhbSBub3Qgc3VyZSB3aGF0IHlv deKAmWQgbGlrZSB0byBzZWUgaW4gQ0RETCBpbiB0aGlzIHN1YnNlY3Rpb24sIGNvdWxkIHlvdSBl eHBhbmQ/DQogICAgDQogICAgSSBhbSBub3Qgc3VyZSB3aGF0IHRoZSBib2R5IG9mIHRoZSBQT1NU IGFuZCByZXNwb25zZSB0aGVyZXRvIGFyZSBmb3JtYXR0ZWQNCiAgICBhcy4gIE1heWJlIENEREwg aXMgbm90IHF1aXRlIHJpZ2h0LCBpZiB3ZSBvbmx5IHdhbnQgdG8gcHJvdmlkZSBhbiBleGFtcGxl DQogICAgd2l0aCBhIHBhcnRpY3VsYXIgY29udGVudC1mb3JtYXQgYnV0IGFsbG93IG1hbnkgZm9y bWF0cy4NCiAgICANCkZQOiBJIHRoaW5rIHRoaXMgc2hvdWxkIGJlIGNvdmVyZWQgaW4gdGhlIGV4 YW1wbGVzIG9mIHRob3NlIDIgbWVzc2FnZXMsIHNlZSBmaWd1cmVzIDExIGFuZCAxMi4gQW55dGhp bmcgZWxzZSBuZWVkZWQ/DQoNCiAgICA+IDUxLiAgICAgICBOb3RlIHRoYXQgdGhlIHByb29mLW9m LXBvc3Nlc3Npb24gcmVxdWlyZWQgdG8gYmluZCB0aGUgYWNjZXNzIHRva2VuDQogICAgPiAgICAg ICAgdG8gdGhlIGNsaWVudCBpcyBpbXBsaWNpdGx5IHBlcmZvcm1lZCBieSBnZW5lcmF0aW5nIHRo ZSBzaGFyZWQgT1NDT1JFDQogICAgPiAgICAgICAgU2VjdXJpdHkgQ29udGV4dCB1c2luZyB0aGUg cG9wLWtleSBhcyBtYXN0ZXIgc2VjcmV0LCBmb3IgYm90aCBjbGllbnQNCiAgICA+ICAgICAgICBh bmQgUlMuICBBbiBhdHRhY2tlciB1c2luZyBhIHN0b2xlbiB0b2tlbiB3aWxsIG5vdCBiZSBhYmxl IHRvDQogICAgPiAgICAgICAgZ2VuZXJhdGUgYSB2YWxpZCBPU0NPUkUgY29udGV4dCBhbmQgdGh1 cyBub3QgYmUgYWJsZSB0byBwcm92ZQ0KICAgID4gICAgICAgIHBvc3Nlc3Npb24gb2YgdGhlIHBv cC1rZXkuDQogICAgPiAgICAgDQogICAgPiAgICAgSXQgbWF5IGJlIHdvcnRoIHNheWluZyBzb21l dGhpbmcgcm91Z2hseSBlcXVhdGluZyAicHJvb2Ygb2YgcG9zc2VzaW9uDQogICAgPiAgICAgcGVy Zm9ybWVkIGJ5IHRoZSBSUyIgYW5kICJ0aGUgUlMgYXV0aGVudGljYXRpbmcgaXRzZWxmIHRvIHRo ZSBjbGllbnQiLA0KICAgID4gICAgIHNpbmNlIHRoZXJlIGlzIG5vdCBhbiBleHRlcm5hbCBhY3Rp b24gZm9yIHNlcnZlciBhdXRoZW50aWNhdGlvbi4NCiAgICA+ICAgICBBbHNvLCBJU1RSIGdldHRp bmcgc29tZSBwdXNoYmFjayBvbiBhIGRpZmZlcmVudCBkb2N1bWVudCB0aGF0IHRhbGtlZA0KICAg ID4gICAgIGFib3V0IGFuIGF0dGFja2VyIHdpdGggYSAic3RvbGVuIHRva2VuIiwgYXMgc29tZXRo aW5nIHRoYXQgY2FuIHN0ZWFsIGENCiAgICA+ICAgICB0b2tlbiBmcm9tIHRoZSBjbGllbnQncyBs b2NhbCBzdG9yYWdlIG1pZ2h0IGFsc28gc3RlYWwgdGhlIGFzc29jaWF0ZWQNCiAgICA+ICAgICBr ZXkuICBJIGZvcmdldCBpZiB3ZSBlbmRlZCB1cCBjaGFuZ2luZyB0byBzb21lIG90aGVyIHBocmFz aW5nIG9yIG5vdCwNCiAgICA+ICAgICB0aG91Z2ggOigNCiAgICA+IA0KICAgID4gRlA6IE9rLCB3 aWxsIHJlcGhyYXNlIHRvIOKAnHRoZSBSUyBhdXRoZW50aWNhdGluZyBpdHNlbGbigJ0gaW5zdGVh ZCBvZiDigJxwb3AgcGVyZm9ybWVkIGJ5IHRoZSBSU+KAnS4gQWxzbywgd2hhdCBhYm91dCB1c2lu ZyBlYXZlc2Ryb3AgaGVyZSBpbnN0ZWFkPw0KICAgIA0KICAgIEVhdmVzZHJvcCBtYXkgYmUgdG9v IGxpbWl0ZWQsIGFzIEkgdGhpbmsgaXQncyBhbHNvIGluIHNjb3BlIGZvciB0aGUgYXR0YWNrDQog ICAgd2hlbiBhbiBSUyByZWNlaXZlcyAod2hldGhlciBsZWdpdGltYXRlbHkgb3IgYnkgZGVjZXB0 aW9uKSB0aGUgdG9rZW4gaW4NCiAgICBxdWVzdGlvbiBhcyB0aGUgdGFyZ2V0IG9mIGEgQ29BUCBy ZXF1ZXN0Lg0KDQpGUDogT2ssIGRpZCBub3QgdXNlIHRoZSB0ZXJtIGVhdmVzZHJvcC4NCiAgICAN CiAgICA+IDU4LiAgICAgICB0byBjbGFpbXMgdGhhdCB0aGUgUlMgY2Fubm90IHByb2Nlc3MgKGUu Zy4sIGFuIHVua25vd24gc2NvcGUpLCBvciBpZg0KICAgID4gICAgICAgIGFueSBvZiB0aGUgZXhw ZWN0ZWQgcGFyYW1ldGVycyBpbiB0aGUgT1NDT1JFX1NlY3VyaXR5X0NvbnRleHQgaXMNCiAgICA+ ICAgICANCiAgICA+ICAgICBIbW0sICJhc3NvY2lhdGVkIHRvIGNsYWltcyB0aGF0IHRoZSBSUyBj YW5ub3QgcHJvY2VzcyIgc291bmRzIGxpa2Ugd2UncmUNCiAgICA+ICAgICB0ZWxsaW5nIHRoZSBS UyB0byBhYm9ydCBpZiB0aGUgdG9rZW4gaW5jbHVkZXMgYW55IHVucmVjb2duaXplZCBjbGFpbXMs DQogICAgPiAgICAgd2hpY2ggSUlVQyBpcyBhdCBvZGRzIHdpdGggdGhlIE9BdXRoIDIuMCBwaGls b3NvcGh5IG9mIGlnbm9yaW5nDQogICAgPiAgICAgdW5yZWNvZ25pemVkIHBhcmFtZXRlcnMuICAo SG9wZWZ1bGx5IHNvbWVvbmUgd2lsbCBjb3JyZWN0IG1lIGlmIEknbQ0KICAgID4gICAgIG1pc3Jl bWVtYmVyaW5nIHRoYXQuKQ0KICAgID4gDQogICAgPiBGUDogVGhpcyBwYXJhZ3JhcGggaXMgbWVh bnQgdG8gbWlycm9yIHdoYXQgc3BlY2lmaWVkIGluIDUuOC4xLjEgb2YgYWNlLW9hdXRoLWF1dGh6 Og0KICAgID4gSWYgdGhlIGNsYWltcyBjYW5ub3QgYmUgb2J0YWluZWQgdGhlIFJTIE1VU1QgZGlz Y2FyZCB0aGUgdG9rZW4NCiAgICA+ICAgICAgIGFuZCwgaW4gY2FzZSBvZiBhbiBpbnRlcmFjdGlv biB2aWEgdGhlIGF1dGh6LWluZm8gZW5kcG9pbnQsIHJldHVybg0KICAgID4gICAgICAgYW4gZXJy b3IgbWVzc2FnZSB3aXRoIGEgcmVzcG9uc2UgY29kZSBlcXVpdmFsZW50IHRvIHRoZSBDb0FQIGNv ZGUNCiAgICA+ICAgICAgIDQuMDAgKEJhZCBSZXF1ZXN0KS4NCiAgICA+IE5leHQsIHRoZSBSUyBN VVNUIHZlcmlmeSBjbGFpbXMsIGlmIHByZXNlbnQsIGNvbnRhaW5lZCBpbiB0aGUgYWNjZXNzDQog ICAgPiAgICB0b2tlbi4gIEVycm9ycyBhcmUgcmV0dXJuZWQgd2hlbiBjbGFpbSBjaGVja3MgZmFp bCwgaW4gdGhlIG9yZGVyIG9mDQogICAgPiAgICBwcmlvcml0eSBvZiB0aGlzIGxpc3Q6DQogICAg DQogICAgQWgsIG1heWJlIHRoZSBhY2UgZnJhbWV3b3JrIGRpdmVyZ2VzIGZyb20gb2F1dGggaGVy ZSBhbmQgSSBtaXNyZW1lbWJlcmVkLg0KICAgIEJ1dCBpcyB0aGlzIGJlaGF2aW9yIGxpbWl0ZWQg dG8gImFueSBvZiB0aGUgZm91ciBzdGFuZGFyZCBjbGFpbXMgdGhhdCBoYXZlDQogICAgYSB2YWx1 ZSB0aGF0IGNhbm5vdCBiZSBwcm9jZXNzZWQiIG9yIGRvZXMgaXQgYWxzbyBpbmNsdWRlICJ0aGVy ZSB3YXMgYW4NCiAgICB1bnJlY29nbml6ZWQgY2xhaW0iPw0KDQpGUDogWWVzLCBJIGNoZWNrZWQg d2l0aCBMdWR3aWcgd2hvIGNvbmZpcm1lZCB0aGF0IHRoZSBmcmFtZXdvcmsgZGl2ZXJnZXMgZnJv bSBvYXV0aCBhbmQgdGhhdCBpdCdzIGZvciBhbnkgdW5yZWNvZ25pemVkIGNsYWltcy4gU28gSSBk aWQgbm90IGRvIGFueSBtb2RpZmljYXRpb25zIGhlcmUuDQoNCiAgICA+IDY3LiAgICAgICBBZnRl ciBzZW5kaW5nIHRoZSAyLjAxIChDcmVhdGVkKSByZXNwb25zZSwgdGhlIFJTIE1VU1Qgc2V0IHRo ZSBNYXN0ZXINCiAgICA+ICAgICAgICBTYWx0IG9mIHRoZSBTZWN1cml0eSBDb250ZXh0IGNyZWF0 ZWQgdG8gY29tbXVuaWNhdGUgd2l0aCB0aGUgY2xpZW50DQogICAgPiAgICAgICAgdG8gdGhlIGNv bmNhdGVuYXRpb24gb2Ygc2FsdCwgTjEsIGFuZCBOMiwgaW4gdGhpcyBvcmRlcjogTWFzdGVyIFNh bHQNCiAgICA+ICAgICAgICA9IHNhbHQgfCBOMSB8IE4yLCB3aGVyZSB8IGRlbm90ZXMgYnl0ZSBz dHJpbmcgY29uY2F0ZW5hdGlvbiwgYW5kDQogICAgPiAgICAgDQogICAgPiAgICAgW0l0IG1pZ2h0 IGJlIHdvcnRoIGJyZWFraW5nIHRoaXMgY29tcHV0YXRpb24gb2ZmIGludG8gYSBzdGFuZGFsb25l IHBpZWNlIG9mDQogICAgPiAgICAgdGV4dCB0aGF0IGFwcGxpZXMgdG8gYm90aCBDIGFuZCBSUywg aW5jbHVkaW5nIHRoZSBlZGl0cyBmb3IgaW5qZWN0aXZpdHkuXQ0KICAgID4gICAgIA0KICAgID4g RlA6IE9LDQoNCkZQOiBJIHRyaWVkIHRvIGRvIHRoaXMsIGJ1dCBkaWQgbm90IG1hbmFnZSB0byBp bXBsZW1lbnQgdGhlIGNoYW5nZSBpbiBhIHNhdGlzZmFjdG9yeSB3YXkgdGhhdCB3b3VsZCBpbXBy b3ZlIHJlYWRhYmlsaXR5LCBzbyBJIGdhdmUgdXAuIFRoZSByZWFzb24gaXMgdGhhdCB0aGUgdGV4 dCB0aGF0IGlzIGFjdHVhbGx5IHRoZSBzYW1lIGlzIG9ubHkgIk1hc3RlciBTYWx0IGlzIHRoZSBj b25jYXRlbmF0aW9uIG9mIC4uLiIsIHdoaWxlIHRoZSBzdXJyb3VuZGluZyB0ZXh0IGlzIHZlcnkg bXVjaCBub2RlLXNwZWNpZmljLiBBbHNvLCB0aGUgdGV4dCBpcyB3cml0dGVuIGluIGEgd2F5IHRv IHNlcXVlbnRpYWxseSBleHBsYWluIGNsaWVudCBhbmQgUlMgcHJvY2Vzc2luZy4gTW92aW5nIHRo aXMgdGV4dCBhcm91bmQgd291bGQgbWFrZSB0aGUgcmVhZGVyIGp1bXAgZnJvbSBhIHNlY3Rpb24g dG8gYW5vdGhlci4gSWYgeW91IGhhdmUgc3VnZ2VzdGlvbnMgb24gYSBiZXR0ZXIgd2F5IHRvIHN0 cnVjdHVyZSB0aGlzIHRleHQsIEknbGwgdGFrZSB0aGVtLiANCg0KICAgID4gNzYuICAgICAgIGF1 dGhvcml6YXRpb24gaW5mb3JtYXRpb24gZnJvbSB0aGUgYWNjZXNzIHRva2VuIGFzc29jaWF0ZWQg dG8gdGhlDQogICAgPiAgICAgICAgU2VjdXJpdHkgQ29udGV4dC4gIFRoZSBSUyB0aGVuIE1VU1Qg dmVyaWZ5IHRoYXQgdGhlIGF1dGhvcml6YXRpb24NCiAgICA+ICAgICAgICBpbmZvcm1hdGlvbiBj b3ZlcnMgdGhlIHJlc291cmNlIGFuZCB0aGUgYWN0aW9uIHJlcXVlc3RlZC4NCiAgICA+ICAgICAN CiAgICA+ICAgICBJbiB0aGUgdmVpbiBvZiBteSBwcmV2aW91cyBub3RlIGFib3V0IGFuIGFic3Ry YWN0IGRhdGEgbW9kZWwsIHdlIG1heSBub3Qgd2FudA0KICAgID4gICAgIHRvIGJlIG92ZXJseSBw cmVzY3JpcHRpdmUgYWJvdXQgInJldHJpZXZlcyBbLi4uXSBmcm9tIHRoZSBhY2Nlc3MgdG9rZW4i Lg0KICAgID4gICAgIFBlci1yZXF1ZXN0IGludHJvc3BlY3Rpb24gaXMgYWxsb3dlZCwgYXMgaXMg Y2FjaGluZyB0aGUgYXV0aG9yaXphdGlvbg0KICAgID4gICAgIGluZm9ybWF0aW9uIGluIGEgbm9u LXRva2VuIGxvY2FsIGRhdGFzdG9yZS4NCiAgICA+IA0KICAgID4gRlA6IE9rLCBJIHVuZGVyc3Rh bmQgYnV0IEkgYW0gbm90IHN1cmUgaG93IHRvIGltcGxlbWVudCB0aGlzIGNvbW1lbnQuIOKAnFJl dHJpZXZl4oCdIG1heSBiZSBtaXNpbnRlcnByZXRlZCwgYnV0IGluIG15IG1pbmQgaXQgY2FuIG1l YW4gYm90aCBieSBsb29raW5nIHVwIGNhY2hpbmcgaW5mbyBhcyB3ZWxsIGFzIGludHJvc3BlY3Rp bmcuIEhvdyB0byBtYWtlIHRoaXMgY2xlYXJlcj8NCiAgICANCiAgICBXb3VsZCBzL2Zyb20vdXNp bmcvIHdvcms/DQoNCkZQOiBZZXMhIFRoYW5rcy4NCiAgICANCiAgICA+ICAgICANCiAgICA+IDky LiAgICAgICBvICBQcm9maWxlIERlc2NyaXB0aW9uOiBQcm9maWxlIGZvciB1c2luZyBPU0NPUkUg dG8gc2VjdXJlDQogICAgPiAgICAgICAgICAgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIGNvbnN0cmFp bmVkIG5vZGVzIHVzaW5nIHRoZSBBdXRoZW50aWNhdGlvbg0KICAgID4gICAgICAgICAgIGFuZCBB dXRob3JpemF0aW9uIGZvciBDb25zdHJhaW5lZCBFbnZpcm9ubWVudHMgZnJhbWV3b3JrLg0KICAg ID4gICAgIA0KICAgID4gICAgIFRoaXMgaXMgdGhlIHJlZ2lzdHJ5IGZvciBBQ0UgcHJvZmlsZXM7 ICJ1c2luZyB0aGUgQXV0aGVudGljYXRpb24gYW5kDQogICAgPiAgICAgQXV0aG9yaXphdGlvbiBm b3IgQ29uc3RyYWluZWQgRW52aXJvcm5tZW50cyBmcmFtZXdvcmsiIGZlZWxzIHJlZHVuZGFudC4N CiAgICA+ICAgICBUaGVyZSdzIGFsc28gcGVyaGFwcyBzb21ldGhpbmcgdG8gc2F5IGFib3V0IGRl ZmluaW5nICJjb2FwX29zY29yZSIgZm9yIGFsbA0KICAgID4gICAgIHRocmVlIGludGVyYWN0aW9u IGZsb3dzIGV2ZW4gdGhvdWdoIHRoZSBwcm9jZWR1cmVzIGZvciB0d28gb2YgdGhlIHRocmVlIGFy ZQ0KICAgID4gICAgIGVzc2VudGlhbGx5IGp1c3QgIm91dCBvZiB0aGUgc2NvcGUgb2YgdGhpcyBz cGVjaWZpY2F0aW9uIiwgdGhvdWdoIGhhdmluZw0KICAgID4gICAgICpzb21lKiBpZGVudGlmaWVy IGZvciAidXNlIE9TQ09SRSIgaXMgcHJvYmFibHkgc3RpbGwgdXNlZnVsLg0KICAgID4gICAgIA0K ICAgID4gRlA6IE9rLCB3ZSBjYW4gcmVtb3ZlIHRoZSBsYXN0IHBhcnQuIEFib3V0IHRoZSBpbnRl cmFjdGlvbiBmbG93cyBiZXR3ZWVuIG5vZGVzLCBJIGFtIG5vdCBzdXJlIHdoYXQgeW91IG1lYW4s IGFzIGJ5IGZvbGxvd2luZyBkZWZpbml0aW9uIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWFjZS1vYXV0aC1hdXRoei0zMSNzZWN0aW9uLTUuNi40LjMgaXQgaXMgbm90IG1h bmRhdG9yeSBmb3IgYSBwcm9maWxlIHRvIHNwZWNpZnkgQy1BUyBhbmQgUlMtQVMsIHRob3NlIGZs b3dzIGNhbiBiZSBvdXQgb2Ygc2NvcGUuIEFtIEkgbWlzc2luZyBzb21ldGhpbmc/DQogICAgDQog ICAgSXQncyBub3QgbWFuZGF0b3J5LCB0aG91Z2ggZ2l2ZW4gdGhhdCB3ZSB0YWxrIGFib3V0IHBy b2ZpbGVzIG5vdCBiZWluZyBhYmxlDQogICAgdG8gYXNzdW1lIHRoYXQgdGhlIHNhbWUgcHJvZmls ZSBpcyB1c2VkIGZvciBhbnkvYWxsIG9mIEMvUlMsIEMvQVMsIGFuZA0KICAgIFJTL0FTLCBJIGd1 ZXNzIEkgYXNzdW1lZCB0aGF0IHdlIHVzZSB0aGUgcHJvZmlsZSBpZGVudGlmaWVyIHRvIHRhbGsg YWJvdXQNCiAgICB0aGUgbGFzdCB0d28gY2FzZXMgYXMgd2VsbCBhcyB0aGUgZmlyc3Qgb25lLiAg TWF5YmUgSSdtIHdyb25nIHRvIGFzc3VtZQ0KICAgIHRoYXQhDQoNCkZQOiBGcm9tIG15IHVuZGVy c3RhbmRpbmcsIHRoYXQncyBub3QgdGhlIGNhc2UsIGFzIEkgc2FpZCBhYm92ZS4gTWF5YmUgc29t ZW9uZSBlbHNlIGNhbiBjb25maXJtLg0KICAgIA0KICAgIFJlZ2FyZGxlc3MsIEkgdGhpbmsgdGhl IHF1ZXN0aW9uIGhlcmUgaXMgd2hldGhlciB3ZSB3YW50IHRvIGhhdmUgcGVvcGxlIHVzZQ0KICAg IHRoZSAiY29hcF9vc2NvcmUiIHN0cmluZyB0byBpbmRpY2F0ZSB0aGF0IEMvQVMgYW5kL29yIFJT L0FTIHVzZSBPU0NPUkUsIG9yDQogICAgaWYgdGhhdCBpbmZvcm1hdGlvbiBpcyBub3QgZXhwZWN0 ZWQgdG8gYmUgZW5jb2RlZCBpbiBhbnkgcHJvdG9jb2wgZWxlbWVudDsNCiAgICBpZiB0aGUgbGF0 dGVyLCB0aGVuIHRoZXJlJ3Mgbm90aGluZyB0byBjaGFuZ2UuDQoNCkZQOiBBcyBvZiBub3csIHRo YXQgaW5mb3JtYXRpb24gaXMgbm90IGV4cGVjdGVkIHRvIGJlIGVuY29kZWQgaW4gYW55IHByb3Rv Y29sIGVsZW1lbnQsIGFzIGZhciBhcyBJIHVuZGVyc3RhbmQuIEFnYWluLCBpZiBhbnlib2R5IGNh biBjb25maXJtL3Nob3V0IGlmIHdyb25nLCBwbGVhc2UgZG8uDQogICAgDQogICAgPiA5Ni4gICAg Ik9TQ09SRV9TZWN1cml0eV9Db250ZXh0IiBmZWVscyBsaWtlIGEgc29tZXdoYXQgbG9uZyBuYW1l IGluIGxpZ2h0IG9mIHRoZQ0KICAgID4gICAgIHByZXZpb3VzIGNvbW1lbnRhcnkgYWJvdXQgc2hv cnRlciBuYW1lcyBiZWluZyBwcmVmZXJyZWQuIDopDQogICAgPiAgICAgDQogICAgPiBGUDogVHlw aWNhbGx5IHRoaXMgd2hvbGUgbmFtZSBzaG91bGQgbm90IGJlIHNlbnQgd2hlbiBDQk9SIGlzIHVz ZWQgKHNvIGluIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cykuIEJ1dCB3ZeKAmWxsIHNob3J0ZW4g aXQsIHdoYXQgYWJvdXQgIlNlY19DdHgiPw0KICAgIA0KICAgIFRoZXJlJ3Mgbm8gbmVlZCB0byBz aG9ydGVuIGl0IGp1c3Qgb24gbXkgYWNjb3VudDsgYXMgeW91IG5vdGUsIGl0J3MNCiAgICBnZW5l cmFsbHkgZ29pbmcgdG8gYmUgdGhlIENCT1IgdGFnIHRoYXQncyB1c2VkLg0KDQpGUDogSSBlbmRl ZCB1cCBzaG9ydGVuaW5nIHRoZSBuYW1lIG9mIHRoZSBDV1QgcGFyYW1ldGVyIHRvICJvc2MiIChz YW1lIGFzIEpXVCksIGV2ZW4gdGhvdWdoIHRoZSBDQk9SIGxhYmVsIHdvdWxkIGJlIHVzZWQgaW5z dGVhZCwgYnV0IGtlcHQgdGhlICJPU0NPUkVfU2VjdXJpdHlfQ29udGV4dCIgYXMgdGhlIG5hbWUg Zm9yIHRoZSBDQk9SIG1hcC4gSSB0aGluayBpdCdzIGJldHRlciB0byBzZXBhcmF0ZSBiZXR3ZWVu IHRoZSBDQk9SIG9iamVjdCBhbmQgdGhlIENXVCBmaWVsZCdzIG5hbWUuDQogICAgDQogICAgDQoN Cg== From nobody Mon Feb 17 18:40: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 DF068120879 for ; Mon, 17 Feb 2020 08:46:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=lBPLPoko; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=oXV9Agcz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7c1HAcuKxuCf for ; Mon, 17 Feb 2020 08:46:47 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD27E120841 for ; Mon, 17 Feb 2020 08:46:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9888; q=dns/txt; s=iport; t=1581958006; x=1583167606; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=/I6zprueXZasAOOVmkXHvblYslkVE9wpQvkuln0c/mw=; b=lBPLPokoGwxRTasEeEtQ3MBrJPkBIFXUd2c0LRVMT9VrT46gMonQTr0z ckIJgPg4Yt9X5ve/cqTPGhgvrdoxShAIgLWW6DjOBKVm+Obh3H/YBjDXV dAgSzpmAGlD6V5CbU6e6vGFL2R9nq4Q5OQ2JHfLwm4Xofz5BE9kvsnrV4 M=; X-Files: smime.p7s : 4024 IronPort-PHdr: =?us-ascii?q?9a23=3A/0T3qhVKhjHqpOUF0wbKLitgZonV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSA9yJ8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtankiH81HTFZj9lmwMFNeH4D1YFiB6nA=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C/EACwwkpe/5pdJa1mHgEMNxeDHFA?= =?us-ascii?q?FbCstIAQLKoQUg0YDinpOghGYEYFCgRADVAIHAQEBCQMBARgLCgIEAQGEQAJ?= =?us-ascii?q?MBYEzJDgTAgMNAQEFAQEBAgEFBG2FNwyFZgEBAQEDAQEQER0BASwMCwQCAQg?= =?us-ascii?q?RBAEBKwICAiULHQgCBAESCAYUgwWBfU0DHw8BAgyhQgKBOYhidYEygn8BAQW?= =?us-ascii?q?BLwEDAg5BgysYggUHCYE4gVODTQyGeBqBQT+BEUeCTD6CZAEBAgEBGIEUARI?= =?us-ascii?q?BCRqDDjKCLI1WG4JshnGYNAqCOoNtgjs7ao8igkl7hxuQO45piHCSQQIEAgQ?= =?us-ascii?q?FAg4BAQWBaSJnWw4IcBUaIYJsCUcYDZIQhHAkhT90gSmLRYIyAQE?= X-IronPort-AV: E=Sophos;i="5.70,453,1574121600"; d="p7s'?scan'208";a="430965978" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Feb 2020 16:46:46 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 01HGkjfU008070 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 17 Feb 2020 16:46:45 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 17 Feb 2020 10:46:45 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 17 Feb 2020 11:46:44 -0500 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 17 Feb 2020 11:46:44 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EMZIgxH+KsC0Dk2FzPL6kyQISSh85WWdI7IF0Gf0mbhPgxA6iQKCYpgAZ3lIC2qLeus7RdAHhSTv+uQUCv9yzAvOFXA1bVlNUoDPEKjUG8RmOW+WE0gXVkyRjUfuH08ftmSIuOGaAVv08BtK4N3yPLv+QOPgOvr6dbTkrm1FmhWmA/8FlJR8/iO3XEJeHZjQwrD4CBU6EqXEHEVHTlWTvpIB7pPXWOLnhrq7LBv0qGIWT30CAqTlcfbXzlTZ2WXOXa4USFRGy1tNGApx9iqSl5PlsrBWKLFN1PeQu0RrDiC4KJyNP7in3Pi7R50GQ1yh3SzjRAvay0+CCIjiPn70qQ== 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=PTccrAnY+gP8V/CfXhbHgtDZ/zoRDoac2OzFr+qq0rQ=; b=Wy6YN83tfIuVz1vZyqBFbWdjmIf2F4ewgvs0bqD6owHVOrHwCcuX28W0xSgXCQb/+4IvwBW4d3p5vP2NwRKFvJbDb/Q24KZPQwmS1sJDftk/fU+A4ALeHl7T39ompcd+WRgTTATW3pWAjin7uv/Nsje6g/RZQrpom2wRCGG9eGvCasORxh1itfrdqat0Y8EwlWhadA89dphdPVbB2y7tuNIyUBvFG//sMI0rCXTPJHdjyDX+qXwgonpCmVskPs7sjIjYlGyk62xqlASKizl6BdRbPVg3PPJG/yM1HBpzs93PehY47t2X/zFhJYD3S4dnvr0Lo29F7ci/Nra5/budlQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PTccrAnY+gP8V/CfXhbHgtDZ/zoRDoac2OzFr+qq0rQ=; b=oXV9Agczzcx+M4IG8PCPBrFzyswhxKj3a9QPIigupQiL9PAXpote+oZ6iR8Z2/z8VZbOpELQpTZvksPumMA1qBqFVYRZtA73d97dEzvDL8OwZops0QrYKiBQxoc+4Wwf4N813Y0Wk8jDgYwFMoFm+jD64lhdPw4EqjL6SGNJnj8= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2657.namprd11.prod.outlook.com (52.135.244.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.25; Mon, 17 Feb 2020 16:46:43 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::2d8b:4fd5:9d28:a1c7]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::2d8b:4fd5:9d28:a1c7%6]) with mapi id 15.20.2729.032; Mon, 17 Feb 2020 16:46:43 +0000 From: "Panos Kampanakis (pkampana)" To: Esko Dijk , "ace@ietf.org" Thread-Topic: [Ace] I-D Action: draft-ietf-ace-coap-est-18.txt Thread-Index: AQHVxLtE07rr0EyB+EKjyAxbFxjZSqfd7nmAgEFc3wCAAIsqoA== Date: Mon, 17 Feb 2020 16:46:42 +0000 Message-ID: References: <157833360921.8003.6238594444996424752@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1008::31f] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 922ec58f-e6c6-4580-2a65-08d7b3c8f7f6 x-ms-traffictypediagnostic: BN7PR11MB2657: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0316567485 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(39860400002)(376002)(136003)(346002)(189003)(199004)(53546011)(81166006)(33656002)(8676002)(81156014)(86362001)(5660300002)(186003)(7696005)(110136005)(8936002)(2906002)(66476007)(71200400001)(66556008)(966005)(478600001)(66574012)(9686003)(316002)(52536014)(66616009)(66446008)(64756008)(66946007)(55016002)(76116006)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2657; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: frP+5wzSGW8L0Pml9A52dHJZbLdRU5vYPvU98o4qhwirLq5/sg+aWRV2jV52THf5Pwm8XWQmAV1PSVOBU9OPakSR0Dy4Ue1w9PLwEtBmuvo2R0/6DjZMZhWulWzz7aM7ue9SiWM+deyrPWBy5NsecXg5JBK66D9RUcKQmR7WRiNsBWTYNEJNGCKhPNZVjTiJ7edqocjTT53+jJ+lqlos29XYoWReJ5QmTXopVRm4LSsCF6bctGHKCavCvE30oXIkm6QChHCQJZtepBe6Tj2Rov3Q+EpFnzDNbqf3KVqgU0XLgMQfM4bHsyVPZHMWUhGDvijC5g3NFk78dFB9cbw2gx9824AEUM2vCzAW0GY5grzMjPkcb74VGiqNmPCj4FzdqVh0YF/15TntE4oAzoJf3RUojDedOPMe3uJ8Ey7MkRVkhYtnsJJ58NEs/zmxHgQCkN9Hta1MxKx6FxtbFJJ0sLGfyLNhQBvcwTM4BeGRSkCZROB5cJPQapdSv2nGRl8f5uu4C6YAL7EHkTJfca9CSw== x-ms-exchange-antispam-messagedata: d4vk2SLdvqi0kDSIgzYN2EPzOfFrk6wEho09dzUZvXQ/QcNrdp75hUTaNSeE0qpHl9h1WUZA+tJU9s9SMDuD4KiGOALOK67BoPTiyQKRed+3kSGpHabv13DIuQrWxoR1nKbfvg88qkcSHTWdmJOE37GkODvUamgNSm6f4Wh0rxk= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0038_01D5E587.EB069340" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 922ec58f-e6c6-4580-2a65-08d7b3c8f7f6 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Feb 2020 16:46:42.8961 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 3c1HGvfUiW6oh9rFV4I3tgaeyWbTlt0CsFrCXjUAqgMbGDH4+toYtGCzM6n4YWCZLKs7eMHhLQrrc6T6KhhBCQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2657 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-coap-est-18.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, 17 Feb 2020 16:46:51 -0000 ------=_NextPart_000_0038_01D5E587.EB069340 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Thank you for this Esko. Hmm, point taken. I consider this a minor change and we will incorporate it in the AUTH48 phase. I am planning to rephrase to "[...] If the client had requested Content- Format TBD287 (application/pkix-cert), the server would respond with a single DER binary certificate. That certificate would be in a multipart-core container specifically in the case of a response to /est/skc query." Let us know if you have any objections. Rgs, Panos -----Original Message----- From: Esko Dijk Sent: Monday, February 17, 2020 3:15 AM To: Panos Kampanakis (pkampana) ; ace@ietf.org Subject: RE: [Ace] I-D Action: draft-ietf-ace-coap-est-18.txt Hello Panos, I noticed one sentence in Appendix A that seems inconsistent with the rest of the I-D, or at least gives an incomplete view : If the client had requested Content- Format TBD287 (application/pkix-cert) by querying /est/skc, the server would respond with a single DER binary certificate in the multipart-core container. The client here could also have POSTed to resource /est/sen with Accept:TBD287 option, indicating it is requesting TBD287 for simple enrollment, and the server would respond with a single DER binary certificate (application/pkix-cert). So the current text might suggest that POSTing to /est/skc is the only way to request TBD287 format, which is not the case since /est/sen also may support it too. Best regards Esko IoTconsultancy.nl | Email/Skype: esko.dijk@iotconsultancy.nl -----Original Message----- From: Ace On Behalf Of Panos Kampanakis (pkampana) Sent: Monday, January 6, 2020 19:12 To: ace@ietf.org; i-d-announce@ietf.org Subject: Re: [Ace] I-D Action: draft-ietf-ace-coap-est-18.txt Hello, This iteration addresses all IESG reviews. More details on the feedback and how we addressed it are in the git issues here Rgs, Panos -----Original Message----- From: Ace On Behalf Of internet-drafts@ietf.org Sent: Monday, January 06, 2020 1:00 PM To: i-d-announce@ietf.org Cc: ace@ietf.org Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-18.txt 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 : EST over secure CoAP (EST-coaps) Authors : Peter van der Stok Panos Kampanakis Michael C. Richardson Shahid Raza Filename : draft-ietf-ace-coap-est-18.txt Pages : 51 Date : 2020-01-06 Abstract: Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-coap-est-18 https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-est-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-18 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 ------=_NextPart_000_0038_01D5E587.EB069340 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDGkw ggNDMIICK6ADAgECAhBf+HsoK1TcjUKjFbVoya3/MA0GCSqGSIb3DQEBBQUAMDUxFjAUBgNVBAoT DUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNpc2NvIFJvb3QgQ0EgMjA0ODAeFw0wNDA1MTQyMDE3 MTJaFw0yOTA1MTQyMDI1NDJaMDUxFjAUBgNVBAoTDUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNp c2NvIFJvb3QgQ0EgMjA0ODCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBALCauaunrwp3 p+JxtrRmYpR4iEfGYlWEQDK/wKsupRxx1rxue6iqum7SFYhIRZ2i/IPQzLmM4CZocEp43yEXnvRh BckVyM8W2jVhiZRDqISoMZh4m7lObyxTEmzNHa0rJLsxxCv/g0Rvtj0kdwnqvyqoH2pW9iAPEVSX gXWnJc5ZaoJl77fq5+KNdYtu8t1Ppl5inM8QCmTQTm3OK8xb9WClJ0eNafR/zhtw3nAbINZuzaYB qDwS0qk/oGteu44gi3qR47Vo7qDnxAF0qFMLK0qaD2USDoJNjmP97+ubGttTphNgr8J918dsFyXU c/tHZFCBgJRM4b+uSxzfku0uBd8CAQOjUTBPMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/ MB0GA1UdDgQWBBQn88gVHm6aAgkWrSugiWBf2nsvqjAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG 9w0BAQUFAAOCAQEAnZ2EhKNBqXx3DLdTyk5EUGLvVHzTdRcc6ODGSEu2/kw6GYFWsFbuGZZiqlqj ZMH2TlQzxnf+xRy65V0lyvXwk5qDES7my/h0Rf7nBbir59/LS+E3hNq5i5dwHvDii9ew2A6dsWnW KpF7qUlPfuaOldiDJzzVaEkO1J32LuunvuswpKwfRPyVqzMG+31gCt60imOwnKnypLlTAYfQaKQn f6v/6frJQDiIZ7Q5xoRvV8lT27qO7sBDsvgJg27/Zs8+7xezWBglCTRe48vWFLbs8pJvdOQvgSrV kpHg4Jc8MmgFhUvR91fiUh2TGlSfBXDASnFgHkMLYB7+o86BGeELNTCCBG4wggNWoAMCAQICCmEQ gG0AAAAAAA4wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UE AxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTE0MDQwNDIwMjQxOFoXDTI5MDUxNDIwMjU0MlowLDEO MAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxveWVlIENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyt9+FkxTFfsjVs3GuWUKBJXl3kxFZ4wMxwbgqx9tXzcqe+fto62A fxHI84Lr7p9Q2cm/PaEvuzwRBzXvuKXZUU7ZsPdToJSALCySZa0Qb6GGa19ACpmlUEQakE3P5kz7 RgaNSOMH1+GtY9fV6CcAFb9uB7JDu2UGL332WV2bEsUsfb3rRLBS4cL8Hu2dWfcdk6erMaZCQjkn 04FixlQsJozbPRTQqI4V6iikG/69rDyeTdbVTK+My/9LnwVsD3GBMiRh7RmrvupxtGiMu8j05Is/ d1OifhWecwvjV3Reg9Lok8bMNJEMAped1weTdVS0X4MsAheosJBld9lS5O4idwIDAQABo4IBhzCC AYMwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFJ+VNrSOXdVLwwrBpymTQ1EG/YlRMBkGCSsG AQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB8G A1UdIwQYMBaAFCfzyBUebpoCCRatK6CJYF/aey+qMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly93 d3cuY2lzY28uY29tL3NlY3VyaXR5L3BraS9jcmwvY3JjYTIwNDguY3JsMFAGCCsGAQUFBwEBBEQw QjBABggrBgEFBQcwAoY0aHR0cDovL3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL2NlcnRzL2Ny Y2EyMDQ4LmNlcjBcBgNVHSAEVTBTMFEGCisGAQQBCRUBFQAwQzBBBggrBgEFBQcCARY1aHR0cDov L3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL3BvbGljaWVzL2luZGV4Lmh0bWwwDQYJKoZIhvcN AQEFBQADggEBAD5OviMaRgKNXmvbigI0C2Ob5QE8Jl2McLIk62Be7IqEZC4bWRWjZxrhFuP94E19 RJojKNLttveiH+dEze1t6oYhVCisbGG8+8hlUARAiiqL/J9uGJ71xT6loqkcAK5xphe7STJLSlgT k0w26fcvDeiA6zhdVHnKhVKkpOJWd9MNByFOnCQyDOK+pcNxLU6IN9TwL1ZoRkdFa11QiCX3Oimk 8YhBrVN+VzGGKtbgZ4fYU6uBo3V3vtshyDpHtGkn1e7f9/TWcY26etFzL33dzaZ4lChlw4l3XkLq 6AfCEDF5djpBdiCRjwpBUIIbCSmyESBvA+sL4j8i1vo/uEartrAwggSsMIIDlKADAgECAgoBhhEi QTzquitVMA0GCSqGSIb3DQEBCwUAMCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBF bXBsb3llZSBDQTAeFw0xOTEyMjAxOTQ5MDJaFw0yMTEyMTkxOTU5MDJaMIGfMSQwIgYDVQQDExtQ YW5vcyBLYW1wYW5ha2lzIChwa2FtcGFuYSkxFDASBgNVBAsTC0Npc2NvIFVzZXJzMRIwEAYDVQQL EwlFbXBsb3llZXMxEzARBgoJkiaJk/IsZAEZEwNjb20xFTATBgoJkiaJk/IsZAEZEwVjaXNjbzEh MB8GCSqGSIb3DQEJAQwScGthbXBhbmFAY2lzY28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAmIHTLIzoAnuMUiHMx8V+PF9JpAcB7zrNHOY1Vj1R1Vx7ty7m9yo9G991T2n7zHo4 UzF6tnB9NxzQOKCY54oqP5KjVGYOPPo+qZ+2rx1GABzdKUF4LwUUKOTf9uXAtvsvIRUc5J/csShT jcUIvtVmiAzWXWRfMYShjBYBVtx/h8fDqAqfFAzd6HG0TcdsN/BRb9k6QEW1afHjPKlRUaDRELyj nFGJZd2OsUJ7/aKMdFmQFd2CAJYzsuwLYjeqJsuGNzBc/k6mzQPf6FW17nz17G41KReU0UdZf2yZ jvimkwCQ/yW8SVTOcGBP+Zk+Lq5EYEGQMu1qtNK/97bXMc5kuwIDAQABo4IBWjCCAVYwDgYDVR0P AQH/BAQDAgTwMAwGA1UdEwEB/wQCMAAwegYIKwYBBQUHAQEEbjBsMDwGCCsGAQUFBzAChjBodHRw Oi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY2VjYS5jZXIwLAYIKwYBBQUHMAGG IGh0dHA6Ly9wa2ljdnMuY2lzY28uY29tL3BraS9vY3NwMB8GA1UdIwQYMBaAFJ+VNrSOXdVLwwrB pymTQ1EG/YlRMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jaXNjb2NlcnRzLmNpc2NvLmNvbS9m aWxlL2NlY2EuY3JsMB0GA1UdEQQWMBSBEnBrYW1wYW5hQGNpc2NvLmNvbTAdBgNVHQ4EFgQUjrl7 6Mrrdw3ZYFiTpZBdtrUm5P4wHwYDVR0lBBgwFgYKKwYBBAGCNwoDDAYIKwYBBQUHAwQwDQYJKoZI hvcNAQELBQADggEBAMhR6xCTygu68lppjWebXTXYznix5961hcmwiJRkPtUIGQ5JQwXyCwq/Juuq yc5ebeq9cQEO5iqyxik/UAQ35BlmKb7SNLi75RtFE/AIZrRsEjTUoO2EtCMQOEMcenWa2XE8fEID BkwzreKeaOchCbDd4L9PvKFht6nDDFtb6VZdWs4ort+J3iFeilVf3oI5MSVi+qroWaFLnLYTQGTn qEjWANfKw3RRBAMdoPCZ+N4eftAk1TWVS08nOsPoKWXtIqX6y0ZPs/EZjBSk57v1TPLpYhEqYGXI oGJlIvzIAfYNoUg8yP8toG5T7x+7hRz0MMUGWcCDsS9PMFxH6SnrUSMxggMNMIIDCQIBATA6MCwx DjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTAN BglghkgBZQMEAgEFAKCCAaQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMjAwMjE3MTY0NjQwWjAvBgkqhkiG9w0BCQQxIgQgupa0wNqcTl8ts/G00KI/IarCaO6TSy5m wf7xAo+xzjUwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lz Y28gRW1wbG95ZWUgQ0ECCgGGESJBPOq6K1UwSwYLKoZIhvcNAQkQAgsxPKA6MCwxDjAMBgNVBAoT BUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTCBoAYJKoZIhvcN AQkPMYGSMIGPMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUD BAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDALBglghkgBZQMEAgEwCwYJKoZIhvcN AQEKMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEggEA jleMYRr9qfeRNwhgCInl/cD4EOxoTe7EZBw/V38cIPhdaZmTVDTtmriVAAD7AgYsTb9l6RA0FUm7 vzBPmYjf/mdru8cB6fr3vilG3fPmJRRMUQsZExeYMd/gdJf+9wMNGh1n6RUtUpjkhLXkSDAt8MI3 vrv+k98n6zlW4dzGKkwByJQ0UwsCxiijuNc9ZDNG79pwgc1PiENJEmJh9wvfKiED+tPIXWTdXV1h Pp52uASdTcQ4q6MdTusjsGKbXYF8f0vuJgx/cbXLffYLn+zORh+nF+BCGxTaGXMhx0LdV9Q7XB2B 1otc8Vjx9PAC1pfTVjBRsr9R29YtjlF4Z6jj5QAAAAAAAA== ------=_NextPart_000_0038_01D5E587.EB069340-- From nobody Mon Feb 17 18:41:09 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 DF9FB12088D for ; Mon, 17 Feb 2020 08:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancynl.onmicrosoft.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 E38gDBxQ7yyK for ; Mon, 17 Feb 2020 08:49:20 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on0727.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0d::727]) (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 7F4BF12088A for ; Mon, 17 Feb 2020 08:49:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=O3QbuzdbqZtb9jQjcBT2CtRRTqKb9W/EPiBgip5W+d4Q2slUuN1dgdhDB7d5ouXS2i0WG2CYf5XTI6mqMTQ3aH/O3o5Eo8aK45QVZzKV6bzazFDauJPCLalx+3oru9zzyYcPWj49FfALThtmV25o48QC4JMhMSh3UdPASeh1uuKpLZdOFa50xIEkxZ23WETh0jvn3Qpd3R6hASkl/z2hQzjUzp6LOblA9YLWPVFd455X2aP5ekfwa6eFivmKzoZVdP3GS2QDI7Js9tFwM72F3DgsE548F6NkucKtsf/eYwat6A4m3LEnRrgPcuSEBlj0bXyCVlSthOq5XmM4wKj1hQ== 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=e0ZSVs23mUPxR54SIc708JD/KPYI0fjDpVE4S6Sx3/M=; b=ESFkbgFbs5/9kiRhDqvqMRVsDBJ4tYvBaZTC2GQEsVjRLMSjUsJBhO4LubWOY8bMr1Ab9mavokNPHaC1mkSJjihlabLQnakSfoLdIYX2Cq6XxBtXJaPxJIoE8taE1sNLUMCZ8uqCV9/ala5y8GKn7XD0MErhV3WVeqWr1mmDkJQImQ8bPrm6RxPQlYvwabVH3FWFmMxuqtLYxzp1YAtDGpf+olxaZuPdULZipLtgEkHCvPZ9R32stLUJgKIrOo+F3UAWqJor3fNna9U6W1S4ynJ9e8n+M9bnX4hh/ItoWjd0cIfkfmauXwSD+A9GhAgB1qEl568iqq2Ic/y3/hQIcQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancynl.onmicrosoft.com; s=selector2-iotconsultancynl-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=e0ZSVs23mUPxR54SIc708JD/KPYI0fjDpVE4S6Sx3/M=; b=hUC4BEVzdynwH9OUVQElBF1eii5gjti+o0BY0fXoQkmjtQSqLrI+4efu5XdKnZjDtPDfFV+KiankXsCnevyxCY1iNYAFEPhaVBxrfWDGAUPkncYVVm97zQgOTSaV9m1bp1WbGyVNGTEdvPNe1qY5IEi4G7WhHfbaWB211mZyCQ4= Received: from AM5P190MB0275.EURP190.PROD.OUTLOOK.COM (10.161.62.28) by AM5P190MB0386.EURP190.PROD.OUTLOOK.COM (10.161.66.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.25; Mon, 17 Feb 2020 16:49:13 +0000 Received: from AM5P190MB0275.EURP190.PROD.OUTLOOK.COM ([fe80::287f:e6f2:a17:a59f]) by AM5P190MB0275.EURP190.PROD.OUTLOOK.COM ([fe80::287f:e6f2:a17:a59f%7]) with mapi id 15.20.2729.032; Mon, 17 Feb 2020 16:49:13 +0000 From: Esko Dijk To: "Panos Kampanakis (pkampana)" , "ace@ietf.org" Thread-Topic: [Ace] I-D Action: draft-ietf-ace-coap-est-18.txt Thread-Index: AQHVxLs5a84UpdRvE0O3c4mcfUR7gKfd8DaAgEFZfBCAAJCBAIAAAIGA Date: Mon, 17 Feb 2020 16:49:13 +0000 Message-ID: References: <157833360921.8003.6238594444996424752@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=esko.dijk@iotconsultancy.nl; x-originating-ip: [2001:1c02:3103:6d00:7824:73b4:cb71:9a42] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 959bfdbc-577a-4e0a-ffe0-08d7b3c9519b x-ms-traffictypediagnostic: AM5P190MB0386: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0316567485 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39830400003)(346002)(366004)(396003)(136003)(376002)(189003)(199004)(7696005)(5660300002)(86362001)(81156014)(8676002)(81166006)(6506007)(66574012)(110136005)(66556008)(53546011)(64756008)(66476007)(76116006)(8936002)(44832011)(66946007)(186003)(66446008)(52536014)(55016002)(9686003)(2906002)(33656002)(71200400001)(966005)(508600001)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5P190MB0386; H:AM5P190MB0275.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: iotconsultancy.nl does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: kYHTWaJADIu6tNMyiWEsajXD/0oO8G8OYR+qEHxyRLmlt9cXW1ajQZoWItjANCNQscoc06jw4S5ZmzYeTQ1ao4XP/zm6vDa3Pi1Hi0duOoyIP/nzvQuNTwFjwdFvZawHMZ2SKqtmqYR+s02pPVqEJvFdtCHyLSnVbwYnZVUDZL7KIv+MTtKO6VldXK9WYgxNcQy9rxedS3MWWSFdO0SHuHs2oqQcUyeOXAgHFZ1EvwU+eiQj/lgRNdBllwC0lvwgY7qZgqsHFGaxYNlAIo8NkrMAf2WBQkY2cbBUJGR1ms17GVchXEyPvZV0wDLMI1rqlMc2rGVTBpbKypfqiLIxmMAwX7b5nZdyqxSmBhxx+lyECebXWLVqPEqB3qPB5aQMuwcMiiUCaBRvg9TwzW7ukxystJ5h39OiLfsbQvndQIdqXmi0hMRDjMIYgHQnJfq63Lun2ZY6sEjUBa8uBFtgYSS9AAAfU5u35Y5CWdIq2nfay4jHK87GvqxxUBv7VuuuBPDe3t6sM1ozd73MwuhOdg== x-ms-exchange-antispam-messagedata: jKNTey3Pr9dObOZUPnEncHtDNMmRIcffDmbDIYD3QlRBYRxTfvI6SGCsnnKZz3yE7C1pVFDDU0g/LAHx+4ky2PmLp+iTKeKiDquZf7r6MY0HFEar2Ag7BIpIciG7nkJwubiUUAxorj/RA937I/FHcPJGx1X0eKxA0zO4QubPtIaRsala12tW7+ScVF8ICxDU9eBFz7GUSza8UvbOzpTmkw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: iotconsultancy.nl X-MS-Exchange-CrossTenant-Network-Message-Id: 959bfdbc-577a-4e0a-ffe0-08d7b3c9519b X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Feb 2020 16:49:13.3781 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: fp6jvqV5nEFsIZ9iJ4iSLgWp1LN/710intqjjceGHXGAnT8uMAgaAoXlRpyh5apuIKIopgyZnIzvJpJlSRTCOpVWwdrRJAdqqJo51/cRru4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5P190MB0386 Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-coap-est-18.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, 17 Feb 2020 16:49:27 -0000 VGhhbmtzLCB0aGUgcHJvcG9zZWQgdGV4dCBpcyBmaW5lISBBZ3JlZSBpdCBpcyBhIG1pbm9yIGl0 ZW0uDQoNCkVza28NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFBhbm9zIEth bXBhbmFraXMgKHBrYW1wYW5hKSA8cGthbXBhbmFAY2lzY28uY29tPiANClNlbnQ6IE1vbmRheSwg RmVicnVhcnkgMTcsIDIwMjAgMTc6NDcNClRvOiBFc2tvIERpamsgPGVza28uZGlqa0Bpb3Rjb25z dWx0YW5jeS5ubD47IGFjZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtBY2VdIEktRCBBY3Rpb246 IGRyYWZ0LWlldGYtYWNlLWNvYXAtZXN0LTE4LnR4dA0KDQpUaGFuayB5b3UgZm9yIHRoaXMgRXNr by4gSG1tLCBwb2ludCB0YWtlbi4NCg0KSSBjb25zaWRlciB0aGlzIGEgbWlub3IgY2hhbmdlIGFu ZCB3ZSB3aWxsIGluY29ycG9yYXRlIGl0IGluIHRoZSBBVVRINDggcGhhc2UuIA0KSSBhbSBwbGFu bmluZyB0byByZXBocmFzZSB0bw0KICAgIlsuLi5dIElmIHRoZSBjbGllbnQgaGFkIHJlcXVlc3Rl ZCBDb250ZW50LQ0KICAgRm9ybWF0IFRCRDI4NyAoYXBwbGljYXRpb24vcGtpeC1jZXJ0KSwgdGhl DQogICBzZXJ2ZXIgd291bGQgcmVzcG9uZCB3aXRoIGEgc2luZ2xlIERFUiBiaW5hcnkgY2VydGlm aWNhdGUuDQogICBUaGF0IGNlcnRpZmljYXRlIHdvdWxkIGJlIGluIGEgbXVsdGlwYXJ0LWNvcmUg Y29udGFpbmVyIHNwZWNpZmljYWxseQ0KICAgaW4gdGhlIGNhc2Ugb2YgYSByZXNwb25zZSB0byAv ZXN0L3NrYyBxdWVyeS4iDQoNCkxldCB1cyBrbm93IGlmIHlvdSBoYXZlIGFueSBvYmplY3Rpb25z Lg0KDQpSZ3MsDQpQYW5vcw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRXNr byBEaWprIDxlc2tvLmRpamtAaW90Y29uc3VsdGFuY3kubmw+DQpTZW50OiBNb25kYXksIEZlYnJ1 YXJ5IDE3LCAyMDIwIDM6MTUgQU0NClRvOiBQYW5vcyBLYW1wYW5ha2lzIChwa2FtcGFuYSkgPHBr YW1wYW5hQGNpc2NvLmNvbT47IGFjZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtBY2VdIEktRCBB Y3Rpb246IGRyYWZ0LWlldGYtYWNlLWNvYXAtZXN0LTE4LnR4dA0KDQpIZWxsbyBQYW5vcywNCg0K SSBub3RpY2VkIG9uZSBzZW50ZW5jZSBpbiBBcHBlbmRpeCBBIHRoYXQgc2VlbXMgaW5jb25zaXN0 ZW50IHdpdGggdGhlIHJlc3Qgb2YgDQp0aGUgSS1ELCBvciBhdCBsZWFzdCBnaXZlcyBhbiBpbmNv bXBsZXRlIHZpZXcgOg0KDQogICBJZiB0aGUgY2xpZW50IGhhZCByZXF1ZXN0ZWQgQ29udGVudC0N CiAgIEZvcm1hdCBUQkQyODcgKGFwcGxpY2F0aW9uL3BraXgtY2VydCkgYnkgcXVlcnlpbmcgL2Vz dC9za2MsIHRoZQ0KICAgc2VydmVyIHdvdWxkIHJlc3BvbmQgd2l0aCBhIHNpbmdsZSBERVIgYmlu YXJ5IGNlcnRpZmljYXRlIGluIHRoZQ0KICAgbXVsdGlwYXJ0LWNvcmUgY29udGFpbmVyLg0KDQpU aGUgY2xpZW50IGhlcmUgY291bGQgYWxzbyBoYXZlIFBPU1RlZCB0byByZXNvdXJjZSAvZXN0L3Nl biB3aXRoIEFjY2VwdDpUQkQyODcgDQpvcHRpb24sIGluZGljYXRpbmcgaXQgaXMgcmVxdWVzdGlu ZyBUQkQyODcgZm9yIHNpbXBsZSBlbnJvbGxtZW50LCBhbmQgdGhlIA0Kc2VydmVyIHdvdWxkIHJl c3BvbmQgd2l0aCBhIHNpbmdsZSBERVIgYmluYXJ5IGNlcnRpZmljYXRlIA0KKGFwcGxpY2F0aW9u L3BraXgtY2VydCkuIFNvIHRoZSBjdXJyZW50IHRleHQgbWlnaHQgc3VnZ2VzdCB0aGF0IFBPU1Rp bmcgdG8gDQovZXN0L3NrYyBpcyB0aGUgb25seSB3YXkgdG8gcmVxdWVzdCBUQkQyODcgZm9ybWF0 LCB3aGljaCBpcyBub3QgdGhlIGNhc2Ugc2luY2UgDQovZXN0L3NlbiBhbHNvIG1heSBzdXBwb3J0 IGl0IHRvby4NCg0KQmVzdCByZWdhcmRzDQpFc2tvDQoNCg0KSW9UY29uc3VsdGFuY3kubmwgIHwg IEVtYWlsL1NreXBlOiBlc2tvLmRpamtAaW90Y29uc3VsdGFuY3kubmwNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IEFjZSA8YWNlLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFs ZiBPZiBQYW5vcyBLYW1wYW5ha2lzIChwa2FtcGFuYSkNClNlbnQ6IE1vbmRheSwgSmFudWFyeSA2 LCAyMDIwIDE5OjEyDQpUbzogYWNlQGlldGYub3JnOyBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbQWNlXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWFjZS1jb2FwLWVzdC0xOC50 eHQNCg0KSGVsbG8sDQoNClRoaXMgaXRlcmF0aW9uIGFkZHJlc3NlcyBhbGwgSUVTRyByZXZpZXdz LiBNb3JlIGRldGFpbHMgb24gdGhlIGZlZWRiYWNrIGFuZCANCmhvdyB3ZSBhZGRyZXNzZWQgaXQg YXJlIGluIHRoZSBnaXQgaXNzdWVzIGhlcmUNCg0KUmdzLA0KUGFub3MNCg0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQWNlIDxhY2UtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVo YWxmIE9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KU2VudDogTW9uZGF5LCBKYW51YXJ5IDA2 LCAyMDIwIDE6MDAgUE0NClRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCkNjOiBhY2VAaWV0Zi5v cmcNClN1YmplY3Q6IFtBY2VdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtYWNlLWNvYXAtZXN0LTE4 LnR4dA0KDQoNCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1s aW5lIEludGVybmV0LURyYWZ0cyANCmRpcmVjdG9yaWVzLg0KVGhpcyBkcmFmdCBpcyBhIHdvcmsg aXRlbSBvZiB0aGUgQXV0aGVudGljYXRpb24gYW5kIEF1dGhvcml6YXRpb24gZm9yIA0KQ29uc3Ry YWluZWQgRW52aXJvbm1lbnRzIFdHIG9mIHRoZSBJRVRGLg0KDQogICAgICAgIFRpdGxlICAgICAg ICAgICA6IEVTVCBvdmVyIHNlY3VyZSBDb0FQIChFU1QtY29hcHMpDQogICAgICAgIEF1dGhvcnMg ICAgICAgICA6IFBldGVyIHZhbiBkZXIgU3Rvaw0KICAgICAgICAgICAgICAgICAgICAgICAgICBQ YW5vcyBLYW1wYW5ha2lzDQogICAgICAgICAgICAgICAgICAgICAgICAgIE1pY2hhZWwgQy4gUmlj aGFyZHNvbg0KICAgICAgICAgICAgICAgICAgICAgICAgICBTaGFoaWQgUmF6YQ0KCUZpbGVuYW1l ICAgICAgICA6IGRyYWZ0LWlldGYtYWNlLWNvYXAtZXN0LTE4LnR4dA0KCVBhZ2VzICAgICAgICAg ICA6IDUxDQoJRGF0ZSAgICAgICAgICAgIDogMjAyMC0wMS0wNg0KDQpBYnN0cmFjdDoNCiAgIEVu cm9sbG1lbnQgb3ZlciBTZWN1cmUgVHJhbnNwb3J0IChFU1QpIGlzIHVzZWQgYXMgYSBjZXJ0aWZp Y2F0ZQ0KICAgcHJvdmlzaW9uaW5nIHByb3RvY29sIG92ZXIgSFRUUFMuICBMb3ctcmVzb3VyY2Ug ZGV2aWNlcyBvZnRlbiB1c2UgdGhlDQogICBsaWdodHdlaWdodCBDb25zdHJhaW5lZCBBcHBsaWNh dGlvbiBQcm90b2NvbCAoQ29BUCkgZm9yIG1lc3NhZ2UNCiAgIGV4Y2hhbmdlcy4gIFRoaXMgZG9j dW1lbnQgZGVmaW5lcyBob3cgdG8gdHJhbnNwb3J0IEVTVCBwYXlsb2FkcyBvdmVyDQogICBzZWN1 cmUgQ29BUCAoRVNULWNvYXBzKSwgd2hpY2ggYWxsb3dzIGNvbnN0cmFpbmVkIGRldmljZXMgdG8g dXNlDQogICBleGlzdGluZyBFU1QgZnVuY3Rpb25hbGl0eSBmb3IgcHJvdmlzaW9uaW5nIGNlcnRp ZmljYXRlcy4NCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBk cmFmdCBpczoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtYWNl LWNvYXAtZXN0Lw0KDQpUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUg YXQ6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hY2UtY29hcC1lc3Qt MTgNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1hY2Ut Y29hcC1lc3QtMTgNCg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxh YmxlIGF0Og0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtYWNl LWNvYXAtZXN0LTE4DQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiANCnVudGlsIHRoZSBodG1saXpl ZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNCklu dGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCmZ0 cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpBY2UgbWFpbGluZyBsaXN0DQpBY2VAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQo= From nobody Tue Feb 18 15:12:52 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 CF43B120838; Tue, 18 Feb 2020 14:44:21 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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=microsoft.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 qeSIUjdnWhkF; Tue, 18 Feb 2020 14:44:18 -0800 (PST) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640110.outbound.protection.outlook.com [40.107.64.110]) (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 6279D120145; Tue, 18 Feb 2020 14:44:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aTVxXbbgfWvVMhSZzD7Bn4jZ21qqOOCHkeZnmu3erQ4t989bkTqErmiDklpmFYpBsl4PNURW7p4GYPRneSuP2ZWAipr683xK25SMaA3ySAM91zI7HQFYJ+cn1nVPA6CZXjVenvbGs7YE0RkxCR3QdpQxKS5ipV6Pg/8YOOpJl2Alwk9Oh6aCO1e/8EYxsXWj2kpQpVVM8lNtHiD6yIG5pKOKdiKIh3Qoe3hGXYRY+FNBHLsfnYWmKntrhl+0RJVoItH9jvWn+dKDsZLmC+nvQcvgga78HlP8CbpdQeS1SMpsvfgEugNWP3R3B7Azz3d6p2PkdMvcGEyFyYYXtE+ABw== 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=2v3tb6lmP6pgVutjdI0En4qUBLVgEuwpdqxFux3UmDA=; b=ZANmOhCPI5/Ul+AAENrESFIX30eEEwTzLhG4k0C2syWMo6ENv+hVp3t4zvnOqQvF0W6DkO3q+0BqdVq1AcDWzJXO0cHT9OLX1Qq011istB+Ucr0Wo1JDA3dglKOHYiOgAdpF1AyCvn7Rl9hmN2j7tUSnAdAM268o4sOryFgNUfklWJljx7wBeWWLjlMuaHNLkzxMwi696RERars3q4vJR9zc7bfhDp+JmYXzVDqMt7JHDiZ//jRrluyZzdqniLGaK5G5Xm9tLKiAF/iSGdtQ29OoC0B1HZuKASfFUIinstJt7YXw1fG2cR5yTs6jS9KWvgds84XcWorUmUPi8fGkdg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2v3tb6lmP6pgVutjdI0En4qUBLVgEuwpdqxFux3UmDA=; b=GoWjLPUOlBAukdylem2MYe146tHl83mdilgppFfjC4WV/XlaiFQKXfUR747s6c5N0uEkloMCAo0/vhM5n2qqqBQNBd4pXvpSgD0fpL/+sYkwVfvCFwKAwe+KAsMZs0u92i32kA20hdczZlbKiUCqMFynaxxA0aKS/p+oMOT+W9U= Received: from BY5PR00MB0676.namprd00.prod.outlook.com (52.135.55.15) by BY5PR00MB0676.namprd00.prod.outlook.com (52.135.55.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2777.0; Tue, 18 Feb 2020 22:44:16 +0000 Received: from BY5PR00MB0676.namprd00.prod.outlook.com ([fe80::a0dd:da8c:7433:3c6f]) by BY5PR00MB0676.namprd00.prod.outlook.com ([fe80::a0dd:da8c:7433:3c6f%4]) with mapi id 15.20.2777.000; Tue, 18 Feb 2020 22:44:16 +0000 From: Mike Jones To: "drafts-lastcall@iana.org" CC: "rdd@cert.org" , "daniel.migault@ericsson.com" , "jwt-reg-review@ietf.org" , "ietf@augustcellars.com" , "ludwig_seitz@gmx.de" , "kaduk@mit.edu" , "ludwig.seitz@combitech.se" , "ace@ietf.org" , "bcampbell@pingidentity.com" Thread-Topic: [EXTERNAL] [Jwt-reg-review] [IANA #1160802] Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params Thread-Index: AQHV0tkCDgs7+DsPqEKR1jljL3oJ+aghtCHw Date: Tue, 18 Feb 2020 22:44:16 +0000 Message-ID: References: <9c32d171-9a4a-ba71-c989-92a177d9e989@gmx.de> <77781da882414f4aae98ae2443691933@combitech.se> <582bfd3fbdee4cc592b92857c955721b@combitech.se> <20200124014548.GE90660@kduck.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=584f1b2c-fc79-452a-af46-000038a5859a; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-02-18T22:44:01Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:b:b9d9:4560:3dd5:6cec] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: a23766b0-b406-420e-3bce-08d7b4c41568 x-ms-traffictypediagnostic: BY5PR00MB0676: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-forefront-prvs: 031763BCAF x-forefront-antispam-report: SFV:NSPM; SFS:(10001)(10019020)(4636009)(366004)(199004)(189003)(186003)(81156014)(81166006)(8676002)(6916009)(71200400001)(7696005)(86362001)(54906003)(10290500003)(966005)(498600001)(9686003)(66946007)(76116006)(66556008)(66446008)(66476007)(64756008)(53546011)(15974865002)(5660300002)(52536014)(6506007)(55016002)(7416002)(33656002)(8936002)(8990500004)(2906002)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:BY5PR00MB0676; H:BY5PR00MB0676.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zdeWGTW7ldzaOqnGAs+45Ag0mPuIwr/WfHsqDJc8S9NDARKfffPXIINbzuvt5yBvivzTx6y7ArLtBGLA0QSuOUKlZkzK54ceqQOiZ7b6JTcdtDzUpjS1KYyDChRBBidDa4hvqV99rXNsHBUrtU9ma81smYndIoBASmJZyEcPKJSEPA/xqKGv35yGtA1Z/hxiRhQbuZ63pNmnENXTnMgHaW+1ymJAqqdFo+KMJgo7j26gAbrTCn5wTfdelVEJE7zIcDB8d8//I2rRF9MuTnYbYV5VX7I8zhzwVCaRGGlOw09U21wr+BSfSdgJV+Qapmh7VnvJLfOdns/ulw1IuGa7oJdD118zKs4HhrBoQl7EIPSUFJZfVaxWp/07HKnwiisZfG7wJMEZsNXeew/+uTrm/hxfB/brVb/+UFbC1dIJ7/MSFon8nFDOBzlGrvMjRM+dn9sI1B+iOLqGvhWH6yHQ/JFFhoZjZrbQJ/MFTJ4QXx1Hmz3IzAmy7npwwthUACH23YAci6anVtuBmjja6NNAoUcJydXFAYgrNm7layFTfvLfm/U8swdAxhcyo1B0A9f8XnqhjZkZX/fnyAODIoertQ== x-ms-exchange-antispam-messagedata: BIEUo/fbOxCdC7KhY2MJrltPpVpdLgJxD80FNaUvplJbzeYgIjBylFYfcxyzi38nPDUsYt+0HI46obalRPZwags9pzapbfxfrcoC6c71DGIR2e8jQZ26Gx+MbS8BoBUlkvNaLYAGupPtU/TxGQLk+CB5fRit3J/2P91BRPsA98Av/LE+fFDnCsrvywe/enaCh0fFAKuZFFO0Gng6Zw0sxQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: a23766b0-b406-420e-3bce-08d7b4c41568 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2020 22:44:16.0493 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: uFOMQlx3YmGRBvQf6OOmjICB6eC39aL2YUFGbmyVqDfSEfiF6CB7POm5Ul4jX0tS+k3VHgoy+kAC7RNPGQtaPg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR00MB0676 Archived-At: X-Mailman-Approved-At: Tue, 18 Feb 2020 15:12:51 -0800 Subject: Re: [Ace] [EXTERNAL] [Jwt-reg-review] [IANA #1160802] Re: Requested review for IANA registration in draft-ietf-ace-oauth-params 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, 18 Feb 2020 22:44:22 -0000 SSBhbSBPSyB3aXRoIHRoZXNlIEpXVCBjbGFpbSByZWdpc3RyYXRpb25zLg0KDQoJCQkJLS0gTWlr ZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSnd0LXJlZy1yZXZpZXcgPGp3 dC1yZWctcmV2aWV3LWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBTYWJyaW5hIFRhbmFt YWwgdmlhIFJUDQpTZW50OiBGcmlkYXksIEphbnVhcnkgMjQsIDIwMjAgODo1OSBBTQ0KQ2M6IHJk ZEBjZXJ0Lm9yZzsgZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24uY29tOyBqd3QtcmVnLXJldmlld0Bp ZXRmLm9yZzsgaWV0ZkBhdWd1c3RjZWxsYXJzLmNvbTsgbHVkd2lnX3NlaXR6QGdteC5kZTsga2Fk dWtAbWl0LmVkdTsgbHVkd2lnLnNlaXR6QGNvbWJpdGVjaC5zZTsgYWNlQGlldGYub3JnOyBiY2Ft cGJlbGxAcGluZ2lkZW50aXR5LmNvbQ0KU3ViamVjdDogW0VYVEVSTkFMXSBbSnd0LXJlZy1yZXZp ZXddIFtJQU5BICMxMTYwODAyXSBSZTogW0FjZV0gUmVxdWVzdGVkIHJldmlldyBmb3IgSUFOQSBy ZWdpc3RyYXRpb24gaW4gZHJhZnQtaWV0Zi1hY2Utb2F1dGgtcGFyYW1zDQoNCkhpIEJlbiwgDQoN ClNpbmNlIHRoZXJlIGFyZSBtdWx0aXBsZSBleHBlcnRzIGZvciB0aGlzIHJlZ2lzdHJ5LCB3ZSBj YW4gYXNrIHRoZSBvdGhlcnMgdG8gcmV2aWV3IHRoZSByZWdpc3RyYXRpb24uIA0KDQpUaGFua3Ms DQoNClNhYnJpbmEgVGFuYW1hbA0KU2VuaW9yIElBTkEgU2VydmljZXMgU3BlY2lhbGlzdA0KDQpP biBGcmkgSmFuIDI0IDAxOjQ2OjQ3IDIwMjAsIGthZHVrQG1pdC5lZHUgd3JvdGU6DQo+IFRoYW5r cyBmb3IgcHV0dGluZyB0aGUgZWZmb3J0IGluLCBCcmlhbi4NCj4gDQo+IElBTkEsIGRvIHlvdSBu ZWVkIHRvIGFzc2lnbiBhIG5ldyBleHBlcnQgdG8gcmV2aWV3aSB0aGUgSldUIENsYWltcyANCj4g cmVnaXN0cmF0aW9uIHJlcXVlc3QgZnJvbSB0aGlzIGRvY3VtZW50LCBvciBhcmUgdGhlIGV4cGVy dHMgZXhwZWN0ZWQgDQo+IHRvIGJlIHNlbGYtb3JnYW5pemluZyBoZXJlPw0KPiANCj4gVGhhbmtz LA0KPiANCj4gQmVuDQo+IA0KPiBPbiBUaHUsIEphbiAyMywgMjAyMCBhdCAwMjozMToyMFBNIC0w NzAwLCBCcmlhbiBDYW1wYmVsbCB3cm90ZToNCj4gPiBBcG9sb2dpZXMsIEkgZm9yZ290IHRvIHJl cGx5LWFsbCBhdCBzb21lIGVhcmxpZXIgcG9pbnQgYW5kIGRyb3BwZWQgDQo+ID4gdGhlIG1haWxp bmcgbGlzdHMgYW5kIG90aGVyIGNjJ3Mgb2ZmIHRoZSB0aHJlYWQuIEFkZGVkIGJhY2sgbm93Lg0K PiA+DQo+ID4gQW5kIGFsc28gYXBvbG9naWVzIGJlY2F1c2UgSSB0aGluayBJIG5lZWQgdG8gcmVj dXNlIG15c2VsZiBmcm9tIHRoZSANCj4gPiBERSByZXNwb25zaWJpbGl0eSBvbiB0aGUgSldUIHJl Z2lzdHJ5IHJlcXVlc3QgaGVyZS4gSSd2ZSBzcGVudCBtb3JlIA0KPiA+IHRpbWUgdGhhbiBJJ2Qg bGlrZSB0byBhZG1pdCBvciByZWFsbHkgaGF2ZSB0byBzcGFyZSBvbiBpdCBhbmQgYW0gDQo+ID4g c3RpbGwgc3RydWdnbGluZyB0byB1bmRlcnN0YW5kLg0KPiA+DQo+ID4gSSBhcHByZWNpYXRlIHlv dSBwb2ludGluZyBvdXQgdGhlIGF1dGh6LWluZm8gZW5kcG9pbnQgaW4gQUNFIGJ1dCBJIA0KPiA+ IHN0aWxsIGRvbid0IGZvbGxvdyBob3cgInJzX2NuZiIgaW4gYW4gYWNjZXNzIHRva2VuIHdvdWxk IHJlYWxseSB3b3JrIA0KPiA+IGluIHByYWN0aWNlLg0KPiA+IFRoZSBjbGllbnQgc2VuZHMgdGhl IHRva2VuIHRvIHRoZSBSUydzIGF1dGh6LWluZm8gZW5kcG9pbnQgb24gYW4gDQo+ID4gaW5zZWN1 cmUgY29ubmVjdGlvbiBvciBvbmUgdGhhdCBoYXMgdGhlIHNlcnZlciBhdXRoIHdpdGggcG90ZW50 aWFsbHkgDQo+ID4gZGlmZmVyZW50IGtleSBhbmQgdGhlIFJTIHN0b3JlcyB0aGUgYWNjZXNzIHRv a2VuIGZvciBsYXRlciB1c2UuIFRoZW4gDQo+ID4gb24gcmVzb3VyY2UgYWNjZXNzIHRoZSBSUyBs b29rcyB1cCB0aGUgYWNjZXNzIHRva2VuICh3aXRoIHJlc3BlY3QgdG8gDQo+ID4gdGhlIGNuZiBr ZXkgaW4gaXQpIGJhc2VkIG9uIHRoZSBrZXkgdGhlIGNsaWVudCB1c2VkIGluIGVzdGFibGlzaGlu ZyANCj4gPiBhIG5ldyBtdXR1YWxseSBhdXRoZW50aWNhdGlvbiBjb25uZWN0aW9uIHRvIHRoZSBS Uy4gRm9yIHRoZSBSUyB0byANCj4gPiBjaG9vc2UgYSBrZXkgZm9yIHNlcnZlciBpdCB3aWxsIHVz ZSBkdXJpbmcgdGhlIGhhbmRzaGFrZSAoYW5kIGFzIGZhciANCj4gPiBhcyBJIGtub3cgdGhlIHNl cnZlciBrZXkgaXMgdGhlIGZpcnN0IGluIHRoZSBhdXRobiBwcm9jZXNzIG9mIHRoZSANCj4gPiBo YW5kc2hha2UpIGJhc2VkIG9uIHRoZSAicnNfY25mIiBpbiB0aGUgYWNjZXNzIHRva2VuLCBpdCBu ZWVkcyB0byANCj4gPiByZW1lbWJlciBhbmQgYXNzb2NpYXRlIHRoYXQgY2xpZW50IGFuZCB0aGUg YWNjZXNzIHRva2VuIHdpdGggDQo+ID4gc29tZXRoaW5nIGVsc2UgKElQIGFkZHJlc3M/KSB0aGF0 IHdpbGwgYmUgYXZhaWxhYmxlIGR1cmluZyB0aGUgDQo+ID4gaGFuZHNoYWtlLiBJdCBkb2Vzbid0 IGZpdCB0b2dldGhlciBmb3IgbWUgaW4gYSB3YXkgdGhhdCBzZWVtcyBsaWtlbHkgDQo+ID4gdG8g d29yayBvciBiZSBpbnRlcm9wZXJhYmxlIGJ1dCwgbGlrZSBJIHNhaWQsIEknbSByZWFsbHkgc3Ry dWdnbGluZyANCj4gPiB0byB1bmRlcnN0YW5kLg0KPiA+DQo+ID4gT24gVGh1LCBKYW4gMTYsIDIw MjAgYXQgMTI6NTQgQU0gU2VpdHogTHVkd2lnIA0KPiA+IDxsdWR3aWcuc2VpdHpAY29tYml0ZWNo LnNlPg0KPiA+IHdyb3RlOg0KPiA+DQo+ID4gPiBIaSBCcmlhbiwNCj4gPiA+DQo+ID4gPg0KPiA+ ID4NCj4gPiA+IENvbW1lbnRzIGlubGluZS4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+IC9M dWR3aWcNCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+ICpGcm9tOiogQnJpYW4gQ2FtcGJlbGwg PGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPg0KPiA+ID4gKlNlbnQ6KiBkZW4gMTMgamFudWFy aSAyMDIwIDIxOjIyDQo+ID4gPiAqVG86KiBTZWl0eiBMdWR3aWcgPGx1ZHdpZy5zZWl0ekBjb21i aXRlY2guc2U+DQo+ID4gPiAqU3ViamVjdDoqIFJlOiBbQWNlXSBSZXF1ZXN0ZWQgcmV2aWV3IGZv ciBJQU5BIHJlZ2lzdHJhdGlvbiBpbiANCj4gPiA+IGRyYWZ0LWlldGYtYWNlLW9hdXRoLXBhcmFt cw0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gVGhhbmtzIGZvciB0aGUgcmVzcG9uc2UgYW5k IHVwZGF0ZXMgTHVkd2lnLA0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gUGxlYXNlIGJlYXIg d2l0aCBtZSB3aGlsZSBJIHRyeSB0byB3cmFwIG15IGhlYWQgYXJvdW5kIHNvbWUgdGhpbmdzLg0K PiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gVGhlIEpXVCByZWdpc3RyYXRpb24gcmVxdWVzdCBm b3IgdGhlICJyc19jbmYiIGNsYWltIHBvaW50cyB0byBTZWMNCj4gPiA+IDMuMw0KPiA+ID4gPGh0 dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUz QSUyRiUyDQo+ID4gPiBGdG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtaWV0Zi1hY2Utb2F1 dGgtcGFyYW1zLSZhbXA7ZGF0YT0wMiUNCj4gPiA+IDdDMDElN0NNaWNoYWVsLkpvbmVzJTQwbWlj cm9zb2Z0LmNvbSU3Q2RiYmQ2NWNkZTQwOTQ1NDA5MzJiMDhkN2EwZg0KPiA+ID4gMDIyMGYlN0M3 MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MTU0ODI1NTUwNjkx DQo+ID4gPiA1NDcmYW1wO3NkYXRhPWdpaWN0V2YlMkJwelhXRUJIMkhCQzF2eUhZcjY4T2hmTzl6 UEszV3EweCUyRlFjJTNEJmENCj4gPiA+IG1wO3Jlc2VydmVkPTANCj4gPiA+IDA4I3NlY3Rpb24t My4zPg0KPiA+ID4gc2F5aW5nIGl0IGlzICJhIGhpbnQgW2luIHRoZSBhY2Nlc3MgdG9rZW5dIHRv IHRoZSBSUyBhYm91dCB3aGljaCANCj4gPiA+IGtleSBpdCBzaG91bGQgdXNlIHRvIGF1dGhlbnRp Y2F0ZSB0b3dhcmRzIHRoZSBjbGllbnQiLiAgQnV0IA0KPiA+ID4gZG9lc24ndCB0aGUgY2xpZW50 IGhhdmUgdG8gZ28gdGhyb3VnaCB0aGUgRFRMUy9UTFMgaGFuZHNoYWtlIHdpdGggDQo+ID4gPiB0 aGUgUlMgKHdoaWNoIGlzIHByZXN1bWFibHkgd2hlbiBpdCBhdXRoZW50aWNhdGVzIHRvIHRoZSBj bGllbnQpIA0KPiA+ID4gYmVmb3JlIGl0IHByZXNlbnRzIHRoZSBhY2Nlc3MgdG9rZW4/DQo+ID4g PiBJJ20gbm90IHNlZWluZyBob3cgdGhpcyB3b3VsZCB3b3JrIGFzIHNlZW1zIHRoZSBSUyB3b24n dCBzZWUgdGhlIA0KPiA+ID4gaGludCB1bnRpbCBhZnRlciBpdCBuZWVkcyBpdC4NCj4gPiA+DQo+ ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gW0xTXSBOb3QgaW4gdGhlIEFDRSBmbG93 LiBXZSB1c2UgdGhlIGFjY2VzcyB0b2tlbiB0byBlc3RhYmxpc2ggDQo+ID4gPiBrZXlzIGF0IHRo ZSBSUyBib3RoIGZvciB0aGUgY2xpZW50IGFuZCB0aGUgUlMuIFdlIGhhdmUgdGhlcmVmb3JlIA0K PiA+ID4gZGVmaW5lZCBhIG5ldyBBQ0UtT0F1dGggZW5kcG9pbnQgKGF1dGh6LWluZm8pIGF0IHRo ZSBSUy4gVGhlIA0KPiA+ID4gY2xpZW50IGNhbiBQT1NUIGFjY2VzcyB0b2tlbnMgdG8gdGhpcyBl bmRwb2ludCB3aXRob3V0IHByaW9yIA0KPiA+ID4gYXV0aGVudGljYXRpb24uDQo+ID4gPg0KPiA+ ID4gQXQgdGhhdCBwb2ludCwgdGhlIFJTIG9ubHkgdmFsaWRhdGVzIHRoZSBzaWduYXR1cmUvTUFD IGJ5IHRoZSBBUy4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+IExhdGVyIGF0IHRoZSB0aW1l IG9mIGFjY2VzcywgdGhlIGNvcnJlc3BvbmRpbmcgdG9rZW4gaXMgbGlua2VkIHRvIA0KPiA+ID4g dGhlIGFjY2VzcyByZXF1ZXN0IHZpYSB0aGUgcG9wLW1lY2hhbmlzbSBhbmQgdGhlIGNsaWVudC9h Y2Nlc3MgDQo+ID4gPiBzcGVjaWZpYyBwYXJ0cyBhcmUgdmFsaWRhdGVkIChlLmcuIHNjb3BlLCBz dWJqZWN0KS4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+IEhvcGUgdGhhdCBjbGFyaWZpZXMg dGhpbmdzIGEgYml0Lg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gT24gU2F0LCBKYW4gMTEs IDIwMjAgYXQgODozMCBBTSBTZWl0eiBMdWR3aWcgDQo+ID4gPiA8bHVkd2lnLnNlaXR6QGNvbWJp dGVjaC5zZT4NCj4gPiA+IHdyb3RlOg0KPiA+ID4NCj4gPiA+IEhlbGxvIGFnYWluIEJyaWFuLA0K PiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gVGhhbmsgeW91IGZvciByZXZpZXdpbmcgdGhpcyEg SW5kZWVkIHRoZSBoYW5kbGluZyBvZiBKV1QvSlNPTiANCj4gPiA+IGludGVyYWN0aW9ucyB3YXMg aGFuZGxlZCBzbG9wcGlseSBoZXJlLiBJIHdpbGwgc29vbiBpc3N1ZSBhIGRyYWZ0IA0KPiA+ID4g dXBkYXRlIHRoYXQgc3BlY2lmaWVzIHRoYXQgdGhlIEpTT04tYmFzZWQgaW50ZXJhY3Rpb25zIHNo b3VsZCB1c2UgDQo+ID4gPiB0aGUgc3ludGF4IGZyb20gUkZDNzgwMCB3aGlsZSB0aGUgQ0JPUi1i YXNlZCBvbmVzIHNob3VsZCB1c2UgDQo+ID4gPiBJRC5pZXRmLWFjZS1jd3QtcHJvb2Ytb2YtcG9z c2Vzc2lvbi4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+IFRoaXMgY29ycmVjdGlvbiBnb2Vz IGZvciBhbGwgdGhlIHVzZSBvZiDigJxjbmbigJ0sIOKAnHJlcV9jbmbigJ0gYW5kIA0KPiA+ID4g 4oCccnNfY25m4oCdLg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gUmVnYXJkcywNCj4gPiA+ DQo+ID4gPg0KPiA+ID4NCj4gPiA+IEx1ZHdpZw0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4g KkZyb206KiBBY2UgPGFjZS1ib3VuY2VzQGlldGYub3JnPiAqT24gQmVoYWxmIE9mICpCcmlhbiBD YW1wYmVsbA0KPiA+ID4gKlNlbnQ6KiBkZW4gMTAgamFudWFyaSAyMDIwIDIyOjEyDQo+ID4gPiAq VG86KiBMdWR3aWcgU2VpdHogPGx1ZHdpZ19zZWl0ekBnbXguZGU+DQo+ID4gPiAqQ2M6KiBSb21h biBEYW55bGl3IDxyZGRAY2VydC5vcmc+OyBqd3QtcmVnLXJldmlld0BpZXRmLm9yZzsgSmltIA0K PiA+ID4gU2NoYWFkIDwgaWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT47IFRoZSBJRVNHIDxpZXNnQGll dGYub3JnPjsgDQo+ID4gPiBhY2VAaWV0Zi5vcmc7IGRyYWZ0cy1sYXN0Y2FsbEBpYW5hLm9yZzsg QmVuamFtaW4gS2FkdWsgDQo+ID4gPiA8a2FkdWtAbWl0LmVkdT4NCj4gPiA+ICpTdWJqZWN0Oiog UmU6IFtBY2VdIFJlcXVlc3RlZCByZXZpZXcgZm9yIElBTkEgcmVnaXN0cmF0aW9uIGluIA0KPiA+ ID4gZHJhZnQtaWV0Zi1hY2Utb2F1dGgtcGFyYW1zDQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4g PiBUaGF0ICAicnNfY25mIiBjbGFpbSByZWdpc3RyYXRpb24gcmVxdWVzdCBpbiA5LjEgcG9pbnRz IHRvIDMuMyANCj4gPiA+IHdoaWNoIHNheXMgaXQgaGFzICd0aGUgc2FtZSBzeW50YXggYW5kIHNl bWFudGljcyBhcyBkZWZpbmVkIGluIGZvciANCj4gPiA+IHRoZSAicnNfY25mIg0KPiA+ID4gcGFy YW1ldGVyJywgd2hpY2ggSSB0aGluayBpcyBpbiA0LjEuIEFuZCA0LjEgc2F5cyB0aGF0IHRoZSAi cnNfY25mIg0KPiA+ID4gdmFsdWVzDQo+ID4gPiAnZm9sbG93IHRoZSBzeW50YXggb2YgdGhlICJj bmYiIGNsYWltIGZyb20gc2VjdGlvbiAzLjEgb2YgDQo+ID4gPiBbSS1ELmlldGYtYWNlLWN3dC1w cm9vZi1vZi1wb3NzZXNzaW9uXS4nIFNpbWlsYXIgdG8gb3RoZXIgY29tbWVudHMgDQo+ID4gPiBJ J3ZlIG1hZGUgdG9kYXksIEkgZG9uJ3QgZm9sbG93IHdoYXQgdGhhdCB3b3VsZCBtZWFuIGZvciB0 aGUgdmFsdWUgDQo+ID4gPiBvZiB0aGUgY2xhaW0gd2hlbiBpdCdzIGEgSldULiBBbmQgdGhhdCBz ZWVtcyBsaWtlIHNvbWV0aGluZyB0aGF0J3MgDQo+ID4gPiBpbXBvcnRhbnQgdG8gdW5kZXJzdGFu ZCBmb3IgdGhlIHB1cnBvc2Ugb2YgYSBKV1QgY2xhaW1zIHJlZ2lzdHJ5IA0KPiA+ID4gcmVxdWVz dC4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gT24gU2F0LCBEZWMg MjEsIDIwMTkgYXQgNDoxMSBBTSBMdWR3aWcgU2VpdHogPGx1ZHdpZ19zZWl0ekBnbXguZGU+DQo+ ID4gPiB3cm90ZToNCj4gPiA+DQo+ID4gPiBIZWxsbyBKV1QgcmVnaXN0cnkgcmV2aWV3ZXJzLA0K PiA+ID4NCj4gPiA+IHRoZSBJRVNHLWRlc2lnbmF0ZWQgZXhwZXJ0cyBmb3IgdGhlIEpXVCBjbGFp bXMgcmVnaXN0cnkgaGF2ZSBhc2tlZCANCj4gPiA+IG1lIHRvIHNlbmQgYSByZXZpZXcgcmVxdWVz dCB0byB5b3UgYWJvdXQgdGhlICJyc19jbmYiIGNsYWltIA0KPiA+ID4gcmVnaXN0ZXJlZA0KPiA+ ID4gaGVyZToNCj4gPiA+DQo+ID4gPiBodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9u Lm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkYNCj4gPiA+IHRvb2xzLmlldGYub3JnJTJG aHRtbCUyRmRyYWZ0LWlldGYtYWNlLW9hdXRoLXBhcmFtcy0wNyUyM3NlY3Rpb24tJg0KPiA+ID4g YW1wO2RhdGE9MDIlN0MwMSU3Q01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdDZGJiZDY1 Y2RlNDA5NDU0DQo+ID4gPiAwOTMyYjA4ZDdhMGYwMjIwZiU3QzcyZjk4OGJmODZmMTQxYWY5MWFi MmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzcNCj4gPiA+IDE1NDgyNTU1MDcwMTQ5MyZhbXA7c2Rh dGE9ZyUyQkNmRGNiT3JDVXNQN3B0UiUyRjJkdWpiV2tmWXlNaUZucVFiUA0KPiA+ID4gbzEyMmNS cyUzRCZhbXA7cmVzZXJ2ZWQ9MA0KPiA+ID4gOS4xDQo+ID4gPg0KPiA+ID4gVGhhbmsgeW91IGlu IGFkdmFuY2UgZm9yIHlvdSByZXZpZXcgY29tbWVudHMuDQo+ID4gPg0KPiA+ID4gUmVnYXJkcywN Cj4gPiA+DQo+ID4gPiBMdWR3aWcNCj4gPiA+DQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gQWNlIG1haWxpbmcgbGlzdA0KPiA+ID4g QWNlQGlldGYub3JnDQo+ID4gPiBodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91 dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkYNCj4gPiA+IHd3dy5pZXRmLm9yZyUyRm1haWxt YW4lMkZsaXN0aW5mbyUyRmFjZSZhbXA7ZGF0YT0wMiU3QzAxJTdDTWljaGFlbA0KPiA+ID4gLkpv bmVzJTQwbWljcm9zb2Z0LmNvbSU3Q2RiYmQ2NWNkZTQwOTQ1NDA5MzJiMDhkN2EwZjAyMjBmJTdD NzJmOTg4DQo+ID4gPiBiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MTU0 ODI1NTUwNzAxNDkzJmFtcDtzZGF0YT0NCj4gPiA+IDZLeDRyZ1BXUmJuZVl2RU5JQ0hudldNMVEw VGxDdkZmZURVMTZyZSUyRk9iNCUzRCZhbXA7cmVzZXJ2ZWQ9MA0KPiA+ID4NCj4gPiA+DQo+ID4g PiAqQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRl bnRpYWwgYW5kIA0KPiA+ID4gcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9m IHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuDQo+ID4gPiBBbnkNCj4gPiA+IHJldmlldywgdXNl LCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgDQo+ID4g PiBwcm9oaWJpdGVkLi4NCj4gPiA+IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNh dGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSANCj4gPiA+IHRoZSBzZW5kZXIgaW1tZWRpYXRl bHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSANCj4gPiA+IGZpbGUg YXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuKg0KPiA+ID4NCj4gPiA+ DQo+ID4gPiAqQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBj b25maWRlbnRpYWwgYW5kIA0KPiA+ID4gcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUg dXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuDQo+ID4gPiBBbnkNCj4gPiA+IHJldmll dywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkg DQo+ID4gPiBwcm9oaWJpdGVkLg0KPiA+ID4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21t dW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IA0KPiA+ID4gdGhlIHNlbmRlciBpbW1l ZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IA0KPiA+ID4g ZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS4qDQo+ID4gPg0K PiA+DQo+ID4gLS0NCj4gPiBfQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkg Y29udGFpbiBjb25maWRlbnRpYWwgYW5kIA0KPiA+IHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRo ZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiANCj4gPiBBbnkgcmV2aWV3 LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSAN Cj4gPiBwcm9oaWJpdGVkLsKgIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlv biBpbiBlcnJvciwgDQo+ID4gcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5 IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSANCj4gPiBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2ht ZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS5fDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpKd3QtcmVnLXJldmlldyBtYWlsaW5nIGxp c3QNCkp3dC1yZWctcmV2aWV3QGlldGYub3JnDQpodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90 ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWls bWFuJTJGbGlzdGluZm8lMkZqd3QtcmVnLXJldmlldyZhbXA7ZGF0YT0wMiU3QzAxJTdDTWljaGFl bC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN0NkYmJkNjVjZGU0MDk0NTQwOTMyYjA4ZDdhMGYwMjIw ZiU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzcxNTQ4MjU1 NTA3MDE0OTMmYW1wO3NkYXRhPVBFMGU3ZSUyRk5nMVZUdTBSNCUyQkFZazl3TiUyRlc0SWxNSGN4 a3F3dVBWOFA3MWclM0QmYW1wO3Jlc2VydmVkPTANCg== From nobody Fri Feb 21 04:37:25 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 E5F0C1200C4 for ; Fri, 21 Feb 2020 04:37:23 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 UY17Q1LGBkEW for ; Fri, 21 Feb 2020 04:37:21 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80088.outbound.protection.outlook.com [40.107.8.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 16215120033 for ; Fri, 21 Feb 2020 04:37:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W8hO8f/WutKzsBZho75Fgk/FwR+FHl3D9h+61ohjE3P8CTETdXK6uItQCJV3MeKqmcQnewpBKRELdeGmdPg2TMe2+bMoq0Urt+b88cvLd23oYwYJGIw/6eXkD8HlHxz0jzKcpBfJBiHZKjbNNIDXz3KI63quj8T+5ITeRzvMO3SVeOek8Z5jLh0isLSqiRSQCI2jYgONVJkwjna7LmSckoV37OVH6graWsBD55UGJNfsOhPgzFVAtT2GPBZ7wSsFMa56eVEIFDrkNcARx3G0eiTXbP32/6HIosAKOAGNXUwqxnkmJjZDDjqJlizLfE7h22s0FxUZwghfUtbrcMx44A== 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=HIeVnjX8DWPU4mkYK5nOIE38zAnpLrviRj9gPY54Zms=; b=FmRjNPmis0QTDjdLzMX6X17wUEDgGZf6p0odvFKr5AODN5ZGdqeG13Uve7cVptVfdfBIpXKEK0gSce2y1O4gVk4TDyD4nZ6S4CUdQ2uTeFoRpu41HnfbzmysuSxtJFBo5UhmBCbRpRETm2aQHVUZh+K37G2T9Hs3bM/bg7n9D4g287/4b2gYkQilL/v6rhZiIkkHZ0fGt1cmjc/llEfUcPssCKpNz+h2ZZoxCizD4nb3fbkd5bzHOHl0l10S17NEFrOgYpClaDGM84rVpxQhhKpike1AhwRJVllMKI3AteKsUPgDkIc4lojG0LqWtvteVHiMWytr+Bpy4eXHn8j5Mw== 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=HIeVnjX8DWPU4mkYK5nOIE38zAnpLrviRj9gPY54Zms=; b=PX3epyUMNBuiQgUQ970EV8R/T2BuEgcZehF2pheafOILnkOz3Own11DXgsDpePvQnf4sa1X7u+rfGafTDkTMEUESp5TaLbWOJCFOMpN0SnU2aWoOKmjo0QGGuEbmQ4Of/gyEWxXtEmPX3x0WdDPOWx21VMviKdbrNpbsH5pq2MY= Received: from AM6PR07MB4053.eurprd07.prod.outlook.com (52.134.117.139) by AM6PR07MB3927.eurprd07.prod.outlook.com (52.134.119.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.9; Fri, 21 Feb 2020 12:37:18 +0000 Received: from AM6PR07MB4053.eurprd07.prod.outlook.com ([fe80::7537:e135:422d:c5a7]) by AM6PR07MB4053.eurprd07.prod.outlook.com ([fe80::7537:e135:422d:c5a7%5]) with mapi id 15.20.2750.016; Fri, 21 Feb 2020 12:37:18 +0000 From: Francesca Palombini To: Seitz Ludwig , Mike Jones , Jim Schaad CC: Ace Wg Thread-Topic: Access token question Thread-Index: AQHV6LOn1YxpaJAAlEyTLIgejF6mBg== Date: Fri, 21 Feb 2020 12:37:18 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [192.176.1.84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9ad7a87c-01d9-4b8b-7bf9-08d7b6caca3c x-ms-traffictypediagnostic: AM6PR07MB3927: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0320B28BE1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(136003)(366004)(396003)(376002)(39860400002)(189003)(199004)(33656002)(5660300002)(6512007)(86362001)(478600001)(6486002)(91956017)(3480700007)(64756008)(66446008)(66476007)(7116003)(76116006)(66946007)(66556008)(4326008)(4744005)(186003)(71200400001)(81156014)(2616005)(8676002)(26005)(81166006)(2906002)(316002)(6506007)(8936002)(110136005)(44832011)(36756003)(9326002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB3927; H:AM6PR07MB4053.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xQUD3/fxpoQjsjMr8YWkUUPS5424n1Od8fAMlrPjKToF2tdDPGhMPJ43lKMW5naf/DGPYe/srPkd87z+h2ZPrmJpW8K7BBAlBBg4cZ4paKszg1WAY3dRMsYTZIyHgduZh0u7+W86JEI8QmX2XbCF0HLHgzPTJZnJ4C+L68vQEyWgCSH9KlVFIEkhMBnj9GXjTZHRPQUgi221aQFiTF8vr4FqK8VO0gz/xSEcWACvbO7iSWQCUvL3bSKZSJxC2ckWpgNwnmXEcXPBpUXpj3hftXLhRPvMMuNUM/RwUJQW8jftVjMdJg7bdgXvf9viTrnAQRW/9ugtb10rraIiZxlgrW2EczSQ/vbx3QMUuiaTZC9miUoicyQ0kRNBUYXTDtqjgh4xT4pMcxeaKtbf+LLfkQh2PxcIHZvsdC5LgM5Hv5bojraGjYoPEAE7TibfeDyy x-ms-exchange-antispam-messagedata: hze897wia2X2qCL/OKLDH39GUpBXKa5tEoaYzEukzD040QkvEESIrZgb0jLpXPWxveYGLHTMaQf1vtsliThvOnQD/8xrBNg//tbodFKPU51t7qz7H6HQPbe4XTP5po5O8TRpCVH3Y0Ef40Wv1wK6xw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_C233BD01B46E458AA9B0E1FB03E82C67ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9ad7a87c-01d9-4b8b-7bf9-08d7b6caca3c X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2020 12:37:18.8095 (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: P1XILVNZ2zlhaHt/hhPMc3oHcFmSCAjcO2UzbuQ5TlbEtuQVwym4jLV/zysgWVLRmELW22IdHqaRj8Pz7F8vQheRWeQwawkz8RbJouyXWS5OCzgfGGEzg0Dh6NW1+gQu X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB3927 Archived-At: Subject: [Ace] Access token question 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: Fri, 21 Feb 2020 12:37:24 -0000 --_000_C233BD01B46E458AA9B0E1FB03E82C67ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClF1aWNrIHF1ZXN0aW9uIHJlZ2FyZGluZyBhY2Nlc3MgdG9rZW4gYW5kIHNjb3BlLg0K SSBrbm93IHRoYXQg4oCcc2NvcGXigJ0gc2VtYW50aWNzIGlzIGxlZnQgdG8gdGhlIGFwcGxpY2F0 aW9uIHRvIGRlZmluZSwgYnV0IGluIGdlbmVyYWwgSSB3b3VsZCBleHBlY3QgdG8gaW5jbHVkZSB0 aGVyZSBzb21lIGluZm9ybWF0aW9uIGFib3V0IHJlc291cmNlIGFuZCBtZXRob2Qvb3BlcmF0aW9u cyBhbGxvd2VkIG9uIHRoYXQgcmVzb3VyY2UuIFBsZWFzZSBjb3JyZWN0IG1lIGlmIGFueSBvZiB0 aGlzIGlzIG5vdCBleGFjdC4NCg0KSXQgd2FzIG15IHVuZGVyc3RhbmRpbmcgdGhhdCDigJxzY29w ZeKAnSAob3IgbW9yZSBwcmVjaXNlbHkgdGhlIOKAnHNjb3Bl4oCdIHZhbHVlKSBkZWZpbmVkIGZv ciB0aGUgQ2xpZW50LUFTIHJlcXVlc3QgYW5kIHJlc3BvbnNlIHNob3VsZCBiZSBpbmNsdWRlZCBp biB0aGUgYWNjZXNzIHRva2VuIGFzIHdlbGwuIENoZWNraW5nIGluIENXVCwgdGhlcmUgaXMgbm8g c3VjaCDigJxzY29wZeKAnSBjbGFpbSBkZWZpbmVkLiDigJxhdWTigJ0gY2xhaW0gaXMgaW5kZWVk IGRlZmluZWQgZm9yIHRoZSBDV1QsIGJ1dCB0aGF0IHNob3VsZCBjb3JyZXNwb25kIHRvIOKAnGF1 ZOKAnSBwYXJhbWV0ZXIgaW4gdGhlIEFDRSByZXF1ZXN0L3Jlc3BvbnNlLiBTbyB3aGVyZSBkbyBJ IHB1dCB0aGUgZXhhY3QgcmVzb3VyY2UgYW5kIG9wZXJhdGlvbnMgaW4gdGhlIGFjY2VzcyB0b2tl bj8NCg0KV2hhdCBhbSBJIG1pc3Npbmc/DQoNCkZyYW5jZXNjYQ0K --_000_C233BD01B46E458AA9B0E1FB03E82C67ericssoncom_ 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 b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCnNwYW4uRW1haWxT dHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIu MHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iIzA1NjNDMSIgdmxp bms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SGksPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iU1YiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UXVpY2sgcXVl c3Rpb24gcmVnYXJkaW5nIGFjY2VzcyB0b2tlbiBhbmQgc2NvcGUuDQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+SSBrbm93IHRoYXQg4oCcc2NvcGXigJ0gc2VtYW50aWNzIGlzIGxlZnQgdG8gdGhlIGFwcGxp Y2F0aW9uIHRvIGRlZmluZSwgYnV0IGluIGdlbmVyYWwgSSB3b3VsZCBleHBlY3QgdG8gaW5jbHVk ZSB0aGVyZSBzb21lIGluZm9ybWF0aW9uIGFib3V0IHJlc291cmNlIGFuZCBtZXRob2Qvb3BlcmF0 aW9ucyBhbGxvd2VkIG9uIHRoYXQgcmVzb3VyY2UuIFBsZWFzZSBjb3JyZWN0DQogbWUgaWYgYW55 IG9mIHRoaXMgaXMgbm90IGV4YWN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+SXQgd2FzIG15IHVuZGVyc3RhbmRpbmcgdGhhdCDigJxzY29wZeKAnSAob3IgbW9y ZSBwcmVjaXNlbHkgdGhlIOKAnHNjb3Bl4oCdIHZhbHVlKSBkZWZpbmVkIGZvciB0aGUgQ2xpZW50 LUFTIHJlcXVlc3QgYW5kIHJlc3BvbnNlIHNob3VsZCBiZSBpbmNsdWRlZCBpbiB0aGUgYWNjZXNz IHRva2VuIGFzIHdlbGwuIENoZWNraW5nIGluIENXVCwgdGhlcmUgaXMgbm8gc3VjaCDigJxzY29w ZeKAnQ0KIGNsYWltIGRlZmluZWQuIOKAnGF1ZOKAnSBjbGFpbSBpcyBpbmRlZWQgZGVmaW5lZCBm b3IgdGhlIENXVCwgYnV0IHRoYXQgc2hvdWxkIGNvcnJlc3BvbmQgdG8g4oCcYXVk4oCdIHBhcmFt ZXRlciBpbiB0aGUgQUNFIHJlcXVlc3QvcmVzcG9uc2UuIFNvIHdoZXJlIGRvIEkgcHV0IHRoZSBl eGFjdCByZXNvdXJjZSBhbmQgb3BlcmF0aW9ucyBpbiB0aGUgYWNjZXNzIHRva2VuPzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+V2hhdCBhbSBJIG1pc3Npbmc/PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPjxicj4NCkZyYW5jZXNjYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_C233BD01B46E458AA9B0E1FB03E82C67ericssoncom_-- From nobody Fri Feb 21 09:15: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 E149F1200CC for ; Fri, 21 Feb 2020 09:15:24 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 iARUuUHRBBmk for ; Fri, 21 Feb 2020 09:15:22 -0800 (PST) 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 15622120020 for ; Fri, 21 Feb 2020 09:15:22 -0800 (PST) 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; Fri, 21 Feb 2020 09:15:15 -0800 From: Jim Schaad To: 'Francesca Palombini' , 'Seitz Ludwig' , 'Mike Jones' CC: 'Ace Wg' References: In-Reply-To: Date: Fri, 21 Feb 2020 09:15:13 -0800 Message-ID: <00da01d5e8da$7ce45130$76acf390$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DB_01D5E897.6EC1AD70" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQE2kOYab9UqhopwEMpdnLZbx5Q6WqlkkxmA Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] Access token question 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: Fri, 21 Feb 2020 17:15:25 -0000 ------=_NextPart_000_00DB_01D5E897.6EC1AD70 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable You are missing something =20 https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-33#section-8.13 =20 defined here =20 From: Francesca Palombini =20 Sent: Friday, February 21, 2020 4:37 AM To: Seitz Ludwig ; Mike Jones = ; Jim Schaad Cc: Ace Wg Subject: Access token question =20 Hi, =20 Quick question regarding access token and scope.=20 I know that =E2=80=9Cscope=E2=80=9D semantics is left to the application = to define, but in general I would expect to include there some = information about resource and method/operations allowed on that = resource. Please correct me if any of this is not exact. =20 It was my understanding that =E2=80=9Cscope=E2=80=9D (or more precisely = the =E2=80=9Cscope=E2=80=9D value) defined for the Client-AS request and = response should be included in the access token as well. Checking in = CWT, there is no such =E2=80=9Cscope=E2=80=9D claim defined. = =E2=80=9Caud=E2=80=9D claim is indeed defined for the CWT, but that = should correspond to =E2=80=9Caud=E2=80=9D parameter in the ACE = request/response. So where do I put the exact resource and operations in = the access token? =20 What am I missing? Francesca ------=_NextPart_000_00DB_01D5E897.6EC1AD70 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

You are missing = something

 

https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-33#section-= 8.13

 

defined = here

 

From: Francesca Palombini = <francesca.palombini@ericsson.com>
Sent: Friday, = February 21, 2020 4:37 AM
To: Seitz Ludwig = <ludwig.seitz@combitech.se>; Mike Jones = <Michael.Jones@microsoft.com>; Jim Schaad = <ietf@augustcellars.com>
Cc: Ace Wg = <ace@ietf.org>
Subject: Access token = question

 

Hi,

 

Quick = question regarding access token and scope.

I know = that =E2=80=9Cscope=E2=80=9D semantics is left to the application to = define, but in general I would expect to include there some information = about resource and method/operations allowed on that resource. Please = correct me if any of this is not exact.

 

It was = my understanding that =E2=80=9Cscope=E2=80=9D (or more precisely the = =E2=80=9Cscope=E2=80=9D value) defined for the Client-AS request and = response should be included in the access token as well. Checking in = CWT, there is no such =E2=80=9Cscope=E2=80=9D claim defined. = =E2=80=9Caud=E2=80=9D claim is indeed defined for the CWT, but that = should correspond to =E2=80=9Caud=E2=80=9D parameter in the ACE = request/response. So where do I put the exact resource and operations in = the access token?

 

What am = I missing?


Francesca

------=_NextPart_000_00DB_01D5E897.6EC1AD70-- From nobody Fri Feb 21 10:45:34 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 548A7120026 for ; Fri, 21 Feb 2020 10:45:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=microsoft.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 3n2vEBWISEgh for ; Fri, 21 Feb 2020 10:45:29 -0800 (PST) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650115.outbound.protection.outlook.com [40.107.65.115]) (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 0B459120013 for ; Fri, 21 Feb 2020 10:45:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JAMIjeKX42iKOZOYiix+EMFhjD+IV5KZQMZxWTWcQ9v1kgS392Upo+h1sGrAV8/xT7tkxE21rKlpEYhJes4he6fasRVxJVuzhwAd+MD07aUToTnSaytmX47MgJ3NKSV77n7uekVzKaeE4GbzewO8RG4aJuYtrz5HbE8+cNKMC+Ic/o/xo2XwiO/G8UjH69upNc3S2XYfDxBKsC5FBxPqaScX/jCoAQNBUc6w10kXQ99nznSmjClyXkrZVELX46s9llAKXjBeXz4KpFlCT/cFOwNICeIYAM05QIS/H9POq8XtqOLKDrtOis0rBxbjyl6STmDhI2AqzQuRBbyu7YqILQ== 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=lrHIvZ9XUHwVt4owKHMY4KWPClgtoBZcskthyXCv5V8=; b=Q5xQMjVR/n03zK14ARHqWugOpk0UMWMtVPU/e1Jfv6pTLFQnunfssKAErjPyRW9Q4AZNMelRHAAh8R1sV8Iic8ACv/LuntX8eb/2VGvdsilwjJo7DV0tE2BJEzg+QIf7xJ49Jc8chKl+M3+o8uZk5cggeWloIxGl2IirW2hVpNZ9iEiIPHtRGNx5MmT1PIOUY9rh/978++7Z/dpUayVHeW6ICycbJdPpq2w9+rsyDiK9VExK9hN9nxbXbq977KkAilbv32QeXDj+lkbCTa/FkUF4ksSL0/6MdnIKP9k/1fpX0VvkyxxAfVjLjrqT0gr35+76CtAEuVO01rzZu//Ttw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lrHIvZ9XUHwVt4owKHMY4KWPClgtoBZcskthyXCv5V8=; b=UrZ5z/zEN0nNvEwus/LcWFodVsmmS9AO39glPJO9xxKj4M4t/7gLOnM3g1lEnU8cSlDdFDiV9IP6ExctLdUFdj+D+wTI2haWaO0qzfDqhCajz3qGQ7hbxZsq5Bznot3m/c1pGGyRB93NjsQoy8L3WCSBvXZeESNe7wiQkfHSvOE= Received: from DM6PR00MB0682.namprd00.prod.outlook.com (2603:10b6:5:213::24) by DM6PR00MB0749.namprd00.prod.outlook.com (2603:10b6:5:1b6::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2792.0; Fri, 21 Feb 2020 18:45:26 +0000 Received: from DM6PR00MB0682.namprd00.prod.outlook.com ([fe80::8d19:b89:22f5:f7ab]) by DM6PR00MB0682.namprd00.prod.outlook.com ([fe80::8d19:b89:22f5:f7ab%6]) with mapi id 15.20.2796.000; Fri, 21 Feb 2020 18:45:26 +0000 From: Mike Jones To: Jim Schaad , 'Francesca Palombini' , 'Seitz Ludwig' CC: 'Ace Wg' Thread-Topic: [EXTERNAL] RE: Access token question Thread-Index: AQHV6LOn1YxpaJAAlEyTLIgejF6mBqgl442AgAAZCUA= Date: Fri, 21 Feb 2020 18:45:26 +0000 Message-ID: References: <00da01d5e8da$7ce45130$76acf390$@augustcellars.com> In-Reply-To: <00da01d5e8da$7ce45130$76acf390$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=a0896083-77dd-4ee6-b1d0-000079222655; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-02-21T18:44:49Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:b:c99d:f725:258e:3463] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: eded986a-57a2-41b9-7680-08d7b6fe3779 x-ms-traffictypediagnostic: DM6PR00MB0749: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0320B28BE1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(366004)(396003)(346002)(39860400002)(136003)(376002)(199004)(189003)(66556008)(4326008)(66476007)(64756008)(186003)(6506007)(81156014)(53546011)(66946007)(76116006)(81166006)(478600001)(8676002)(71200400001)(66446008)(10290500003)(316002)(8936002)(9686003)(110136005)(33656002)(8990500004)(5660300002)(55016002)(966005)(86362001)(7696005)(52536014)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR00MB0749; H:DM6PR00MB0682.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: kOAxmQDc05xrJL/R3mFzBUV5wDI+3AZ29PaDbEzNQJeKYvAPVBI+FpsT5bTmqH5v/XxMeli8ZfDJkDioPp1yg2W8eOKmEADGUj5fxTb1Uzgz/2M7Ll9jGAxOqAdd4oumQprL6Ln5wVA7Cl2PygEg+WxDoQHf76ywr8+c7neaCi81cptStBeBeo7jw+jvgGD2ego2Gt2iGyt6f9vQl7gz96naCHjTWAUm/nSecol1ponchlVWCgPyXneOummvVs1/tEZA0mq2ObCLy3DPQLbqwj0iVMH1DfRN5j18Y9M+tCkkV3sONJYEi4/N2s0htq1yKR+56OdQOvocX3OYqddoTqKI/P0b80CVN6qUyBDCQDvMDU+hRtTtt4B8dNSnXuS7xDgIJ1ST3/crPeDrovvAQ/lwe22chxnJzHWQ4DgUpiOagb4fvNl0aWUrXVOz48CKrXCmAjQ4+MeuddD+UhPfEqaVfmnNb0P6rji0xXz4jqM/fbtU6EDjst8t1gxXzlS3KFYvNAAywUSliU/aEZ9AAA== x-ms-exchange-antispam-messagedata: IM1tceIkTMnLZ4GT3poMNcHYav1+HJQoh3j5L9Xt/J7dbSXewXG0bsDYh73D7RFAM9EFvXcHITjpiRxI2FukmGSLcF0hCvknGK23GYt7Y6xdJjRgbHzmwTIl1mNDK7ISb3Be+OMYkypAraAATEUTWYY4vwH9JMibVMLf6BDS11rojK/cq3M2RWxqQ5qfxbN8/hfOwwqc7mk6HG+FPnEnMA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB068296640E3FC5A119328C10F5120DM6PR00MB0682namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: eded986a-57a2-41b9-7680-08d7b6fe3779 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2020 18:45:26.3276 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: JC/fCTD+UyiBB8kmyGi2YjHryIZ5x1e35ZtIKnroySscKkWl392HlqZZKpKMtMhox72m4IDAZMo36plvHTAm+A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0749 Archived-At: Subject: Re: [Ace] [EXTERNAL] RE: Access token question 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: Fri, 21 Feb 2020 18:45:33 -0000 --_000_DM6PR00MB068296640E3FC5A119328C10F5120DM6PR00MB0682namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5kIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4NjkzI3NlY3Rpb24tNy40LCB3aGlj aCByZWdpc3RlcnMg4oCcc2NvcGXigJ0gYXQgaHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVu dHMvand0L2p3dC54aHRtbC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogSmltIFNjaGFhZCA8 aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4NClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMjEsIDIwMjAg OToxNSBBTQ0KVG86ICdGcmFuY2VzY2EgUGFsb21iaW5pJyA8ZnJhbmNlc2NhLnBhbG9tYmluaUBl cmljc3Nvbi5jb20+OyAnU2VpdHogTHVkd2lnJyA8bHVkd2lnLnNlaXR6QGNvbWJpdGVjaC5zZT47 IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4NCkNjOiAnQWNlIFdnJyA8 YWNlQGlldGYub3JnPg0KU3ViamVjdDogW0VYVEVSTkFMXSBSRTogQWNjZXNzIHRva2VuIHF1ZXN0 aW9uDQoNCllvdSBhcmUgbWlzc2luZyBzb21ldGhpbmcNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtYWNlLW9hdXRoLWF1dGh6LTMzI3NlY3Rpb24tOC4xMzxodHRwczov L25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYl MkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZkcmFmdC1pZXRmLWFjZS1vYXV0aC1hdXRoei0zMyUy M3NlY3Rpb24tOC4xMyZkYXRhPTAyJTdDMDElN0NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNv bSU3QzQxZTI2YmJjZGI3YzRmOTAyZDc5MDhkN2I2ZjFhODYwJTdDNzJmOTg4YmY4NmYxNDFhZjkx YWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzE3OTAyMTM0MDQ3ODg2NCZzZGF0YT1iTW96cUky QllxTUFBVmlXTElJS3pKQnZRRmEzMGVxS1ZIdHFVaUMzYkg4JTNEJnJlc2VydmVkPTA+DQoNCmRl ZmluZWQgaGVyZQ0KDQpGcm9tOiBGcmFuY2VzY2EgUGFsb21iaW5pIDxmcmFuY2VzY2EucGFsb21i aW5pQGVyaWNzc29uLmNvbTxtYWlsdG86ZnJhbmNlc2NhLnBhbG9tYmluaUBlcmljc3Nvbi5jb20+ Pg0KU2VudDogRnJpZGF5LCBGZWJydWFyeSAyMSwgMjAyMCA0OjM3IEFNDQpUbzogU2VpdHogTHVk d2lnIDxsdWR3aWcuc2VpdHpAY29tYml0ZWNoLnNlPG1haWx0bzpsdWR3aWcuc2VpdHpAY29tYml0 ZWNoLnNlPj47IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86 TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj47IEppbSBTY2hhYWQgPGlldGZAYXVndXN0Y2Vs bGFycy5jb208bWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb20+Pg0KQ2M6IEFjZSBXZyA8YWNl QGlldGYub3JnPG1haWx0bzphY2VAaWV0Zi5vcmc+Pg0KU3ViamVjdDogQWNjZXNzIHRva2VuIHF1 ZXN0aW9uDQoNCkhpLA0KDQpRdWljayBxdWVzdGlvbiByZWdhcmRpbmcgYWNjZXNzIHRva2VuIGFu ZCBzY29wZS4NCkkga25vdyB0aGF0IOKAnHNjb3Bl4oCdIHNlbWFudGljcyBpcyBsZWZ0IHRvIHRo ZSBhcHBsaWNhdGlvbiB0byBkZWZpbmUsIGJ1dCBpbiBnZW5lcmFsIEkgd291bGQgZXhwZWN0IHRv IGluY2x1ZGUgdGhlcmUgc29tZSBpbmZvcm1hdGlvbiBhYm91dCByZXNvdXJjZSBhbmQgbWV0aG9k L29wZXJhdGlvbnMgYWxsb3dlZCBvbiB0aGF0IHJlc291cmNlLiBQbGVhc2UgY29ycmVjdCBtZSBp ZiBhbnkgb2YgdGhpcyBpcyBub3QgZXhhY3QuDQoNCkl0IHdhcyBteSB1bmRlcnN0YW5kaW5nIHRo YXQg4oCcc2NvcGXigJ0gKG9yIG1vcmUgcHJlY2lzZWx5IHRoZSDigJxzY29wZeKAnSB2YWx1ZSkg ZGVmaW5lZCBmb3IgdGhlIENsaWVudC1BUyByZXF1ZXN0IGFuZCByZXNwb25zZSBzaG91bGQgYmUg aW5jbHVkZWQgaW4gdGhlIGFjY2VzcyB0b2tlbiBhcyB3ZWxsLiBDaGVja2luZyBpbiBDV1QsIHRo ZXJlIGlzIG5vIHN1Y2gg4oCcc2NvcGXigJ0gY2xhaW0gZGVmaW5lZC4g4oCcYXVk4oCdIGNsYWlt IGlzIGluZGVlZCBkZWZpbmVkIGZvciB0aGUgQ1dULCBidXQgdGhhdCBzaG91bGQgY29ycmVzcG9u ZCB0byDigJxhdWTigJ0gcGFyYW1ldGVyIGluIHRoZSBBQ0UgcmVxdWVzdC9yZXNwb25zZS4gU28g d2hlcmUgZG8gSSBwdXQgdGhlIGV4YWN0IHJlc291cmNlIGFuZCBvcGVyYXRpb25zIGluIHRoZSBh Y2Nlc3MgdG9rZW4/DQoNCldoYXQgYW0gSSBtaXNzaW5nPw0KDQpGcmFuY2VzY2ENCg== --_000_DM6PR00MB068296640E3FC5A119328C10F5120DM6PR00MB0682namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIwNjAiPkFuZCA8YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODY5MyNzZWN0aW9uLTcuNCI+DQpodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjODY5MyNzZWN0aW9uLTcuNDwvYT4sIHdoaWNoIHJlZ2lzdGVycyDi gJxzY29wZeKAnSBhdCA8YSBocmVmPSJodHRwczovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9q d3Qvand0LnhodG1sIj4NCmh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2p3dC9qd3Qu eGh0bWw8L2E+LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiBKaW0gU2NoYWFkICZsdDtp ZXRmQGF1Z3VzdGNlbGxhcnMuY29tJmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgRmVi cnVhcnkgMjEsIDIwMjAgOToxNSBBTTxicj4NCjxiPlRvOjwvYj4gJ0ZyYW5jZXNjYSBQYWxvbWJp bmknICZsdDtmcmFuY2VzY2EucGFsb21iaW5pQGVyaWNzc29uLmNvbSZndDs7ICdTZWl0eiBMdWR3 aWcnICZsdDtsdWR3aWcuc2VpdHpAY29tYml0ZWNoLnNlJmd0OzsgTWlrZSBKb25lcyAmbHQ7TWlj aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gJ0FjZSBXZycgJmx0 O2FjZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0VYVEVSTkFMXSBSRTogQWNj ZXNzIHRva2VuIHF1ZXN0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPllvdSBhcmUgbWlzc2luZyBz b21ldGhpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxhIGhy ZWY9Imh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1o dHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LWlldGYtYWNlLW9hdXRo LWF1dGh6LTMzJTIzc2VjdGlvbi04LjEzJmFtcDtkYXRhPTAyJTdDMDElN0NNaWNoYWVsLkpvbmVz JTQwbWljcm9zb2Z0LmNvbSU3QzQxZTI2YmJjZGI3YzRmOTAyZDc5MDhkN2I2ZjFhODYwJTdDNzJm OTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzE3OTAyMTM0MDQ3ODg2 NCZhbXA7c2RhdGE9Yk1venFJMkJZcU1BQVZpV0xJSUt6SkJ2UUZhMzBlcUtWSHRxVWlDM2JIOCUz RCZhbXA7cmVzZXJ2ZWQ9MCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt YWNlLW9hdXRoLWF1dGh6LTMzI3NlY3Rpb24tOC4xMzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPmRlZmluZWQgaGVyZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+IEZyYW5jZXNj YSBQYWxvbWJpbmkgJmx0OzxhIGhyZWY9Im1haWx0bzpmcmFuY2VzY2EucGFsb21iaW5pQGVyaWNz c29uLmNvbSI+ZnJhbmNlc2NhLnBhbG9tYmluaUBlcmljc3Nvbi5jb208L2E+Jmd0Ow0KPGJyPg0K PGI+U2VudDo8L2I+IEZyaWRheSwgRmVicnVhcnkgMjEsIDIwMjAgNDozNyBBTTxicj4NCjxiPlRv OjwvYj4gU2VpdHogTHVkd2lnICZsdDs8YSBocmVmPSJtYWlsdG86bHVkd2lnLnNlaXR6QGNvbWJp dGVjaC5zZSI+bHVkd2lnLnNlaXR6QGNvbWJpdGVjaC5zZTwvYT4mZ3Q7OyBNaWtlIEpvbmVzICZs dDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIj5NaWNoYWVsLkpv bmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OzsgSmltIFNjaGFhZCAmbHQ7PGEgaHJlZj0ibWFpbHRv OmlldGZAYXVndXN0Y2VsbGFycy5jb20iPmlldGZAYXVndXN0Y2VsbGFycy5jb208L2E+Jmd0Ozxi cj4NCjxiPkNjOjwvYj4gQWNlIFdnICZsdDs8YSBocmVmPSJtYWlsdG86YWNlQGlldGYub3JnIj5h Y2VAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBBY2Nlc3MgdG9rZW4gcXVl c3Rpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhpLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5RdWljayBx dWVzdGlvbiByZWdhcmRpbmcgYWNjZXNzIHRva2VuIGFuZCBzY29wZS4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+SSBrbm93IHRoYXQg4oCcc2NvcGXigJ0gc2VtYW50aWNzIGlzIGxl ZnQgdG8gdGhlIGFwcGxpY2F0aW9uIHRvIGRlZmluZSwgYnV0IGluIGdlbmVyYWwgSSB3b3VsZCBl eHBlY3QgdG8gaW5jbHVkZSB0aGVyZSBzb21lIGluZm9ybWF0aW9uIGFib3V0IHJlc291cmNlIGFu ZCBtZXRob2Qvb3BlcmF0aW9ucyBhbGxvd2VkIG9uIHRoYXQgcmVzb3VyY2UuDQogUGxlYXNlIGNv cnJlY3QgbWUgaWYgYW55IG9mIHRoaXMgaXMgbm90IGV4YWN0LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JdCB3YXMg bXkgdW5kZXJzdGFuZGluZyB0aGF0IOKAnHNjb3Bl4oCdIChvciBtb3JlIHByZWNpc2VseSB0aGUg 4oCcc2NvcGXigJ0gdmFsdWUpIGRlZmluZWQgZm9yIHRoZSBDbGllbnQtQVMgcmVxdWVzdCBhbmQg cmVzcG9uc2Ugc2hvdWxkIGJlIGluY2x1ZGVkIGluIHRoZSBhY2Nlc3MgdG9rZW4gYXMgd2VsbC4g Q2hlY2tpbmcgaW4gQ1dULCB0aGVyZQ0KIGlzIG5vIHN1Y2gg4oCcc2NvcGXigJ0gY2xhaW0gZGVm aW5lZC4g4oCcYXVk4oCdIGNsYWltIGlzIGluZGVlZCBkZWZpbmVkIGZvciB0aGUgQ1dULCBidXQg dGhhdCBzaG91bGQgY29ycmVzcG9uZCB0byDigJxhdWTigJ0gcGFyYW1ldGVyIGluIHRoZSBBQ0Ug cmVxdWVzdC9yZXNwb25zZS4gU28gd2hlcmUgZG8gSSBwdXQgdGhlIGV4YWN0IHJlc291cmNlIGFu ZCBvcGVyYXRpb25zIGluIHRoZSBhY2Nlc3MgdG9rZW4/PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPldoYXQgYW0gSSBt aXNzaW5nPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PGJyPg0KRnJhbmNlc2NhPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DM6PR00MB068296640E3FC5A119328C10F5120DM6PR00MB0682namp_-- From nobody Fri Feb 21 22:21: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 7907E120125; Fri, 21 Feb 2020 22:21:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 jrVerdp7WFPq; Fri, 21 Feb 2020 22:21:23 -0800 (PST) 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 5128F12006D; Fri, 21 Feb 2020 22:21:23 -0800 (PST) Received: from [172.16.42.113] (p548DC4D8.dip0.t-ipconnect.de [84.141.196.216]) (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 48PdWP672dz183C; Sat, 22 Feb 2020 07:21:21 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 604045281.409403-48d283213530afe9b09ae2a1c8a06238 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Sat, 22 Feb 2020 07:21:21 +0100 Message-Id: To: ace@ietf.org, Core , cose@ietf.org, cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: [Ace] Constrained Node/Network Cluster @ IETF107: DRAFT AGENDA 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, 22 Feb 2020 06:21:27 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF107. Remember that there is still quite some potential for changes. Conflicts that meet the eye: ROLL vs. COSE/TEEP, LPWAN vs. RATS, and LAKE vs. RATS, WPACK vs. ACE. The latter two might be a bigger problem, while the first two are displaying the inevitable split between security vs. other IoT issues, as is MODEL-T vs. CORE and TXAUTH vs. T2TRG. All times are in PDT =3D=3D UTC - 7 hours. Note that North America is = on DST already during the IETF, while Europe will only go there on March 29, so we are in the three-week period of DST confusion (where the US is one hour closer to the EU than the rest of the year). (Pure UTC times at https://datatracker.ietf.org/meeting/agenda-utc are useful for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten FRIDAY, March 20, 2020 0900-1800 T2TRG/W3C WoT Workshop = https://github.com/t2trg/2020-03-vancouver SATURDAY, March 21, 2020 0830-2200 IETF Hackathon - Plaza Ballroom SUNDAY, March 22, 2020 0830-1600 IETF Hackathon - Plaza Ballroom 1700-1900 Welcome Reception - Regency A/B/C/D 1800-2000 Hot RFC Lightning Talks -- Plaza B/C MONDAY, March 23, 2020 1000-1200 Morning Session I Regency D ART dispatch Dispatch WG - Joint with ARTAREA Regency C INT 6man IPv6 Maintenance WG Plaza B/C IRTF pearg Privacy Enhancements and Assessments = Research Group Regency E SEC *** suit Software Updates for Internet of Things = WG 1330-1530 Afternoon Session I Regency C INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Regency D IRTF irtfopen IRTF Open Meeting Georgia A SEC mls Messaging Layer Security WG Georgia B SEC oauth Web Authorization Protocol WG Plaza A SEC *** rats Remote ATtestation ProcedureS WG 1550-1750 Afternoon Session II Regency F ART webtrans WebTransport WG Regency C IRTF maprg Measurement and Analysis for Protocols Regency E OPS anima Autonomic Networking Integrated Model = and Approach WG Plaza A RTG raw Reliable and Available Wireless WG Plaza B/C SEC secdispatch Security Dispatch WG 1810-1910 Afternoon Session III Georgia A RTG *** roll Routing Over Low power and Lossy = networks WG Georgia B SEC *** cose CBOR Object Signing and Encryption WG Plaza B/C SEC tls Transport Layer Security WG Regency C TSV tsvarea Transport Area Open Meeting TUESDAY, March 24, 2020 1000-1200 Morning Session I Georgia A INT add Adaptive DNS Discovery WG Regency D IRTF*** dinrg Decentralized Internet Infrastructure Regency F SEC acme Automated Certificate Management = Environment WG Regency E SEC *** teep Trusted Execution Environment = Provisioning WG Plaza B/C TSV quic QUIC WG 1330-1530 Afternoon Session I Regency C INT masque Multiplexed Application Substrate over = QUIC Encryption BOF Regency D IRTF coinrg Computing in the Network Research Group Georgia B RTG *** roll Routing Over Low power and Lossy = networks WG Georgia A SEC emu EAP Method Update WG Plaza A SEC *** teep Trusted Execution Environment = Provisioning WG 1550-1720 Afternoon Session II Regency F ART *** core Constrained RESTful Environments WG Plaza A IRTF qirg Quantum Internet Proposed Research Group Georgia B SEC oauth Web Authorization Protocol WG Regency C TSV tsvwg Transport Area Working Group WG 1740-1840 Afternoon Session III Plaza B/C INT 6man IPv6 Maintenance WG Georgia A RTG babel Babel routing protocol WG Regency D RTG detnet Deterministic Networking WG Regency E RTG rift Routing In Fat Trees WG Regency C TSV quic QUIC WG WEDNESDAY, March 25, 2020 0830-0945 Side Meetings / Open Time Regency C tdd Technology Deep Dive 1000-1200 Morning Session I Regency F IRTF*** t2trg Thing-to-Thing Georgia B RTG bier Bit Indexed Explicit Replication WG Regency D SEC txauth Transactional Authorization and = Delegation BOF Regency C TSV quic QUIC WG 1330-1500 Afternoon Session I Regency C ART wpack Web Packaging BOF Regency E IRTF panrg Path Aware Networking RG Georgia A SEC *** ace Authentication and Authorization for = Constrained Environments WG 1520-1650 Afternoon Session II Georgia A model-t Internet Threat Model Plaza A ART *** core Constrained RESTful Environments WG Plaza B/C RTG rtgarea Routing Area Open Meeting 1710-1940 IETF Plenary - Regency C/D/E/F THURSDAY, March 26, 2020 1000-1200 Morning Session I Georgia A ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Georgia B INT dnssd Extensions for Scalable DNS Service = Discovery WG - Joint with HOMENET Georgia B INT homenet Home Networking WG - Joint with DNSSD Regency E IRTF icnrg Information-Centric Networking Regency C SEC privacypass privacy-pass BOF Plaza B/C TSV tsvwg Transport Area Working Group WG 1330-1530 Afternoon Session I Regency F OPS v6ops IPv6 Operations WG Regency D SEC saag Security Area Open Meeting Georgia B TSV taps Transport Services WG 1550-1720 Afternoon Session II Regency C ART httpbis HTTP WG Regency F INT intarea Internet Area Working Group WG Regency E IRTF cfrg Crypto Forum Plaza B/C RTG detnet Deterministic Networking WG 1740-1840 Afternoon Session III Regency E ART uta Using TLS in Applications WG Georgia B INT *** drip Drone Remote ID Protocol WG Regency D OPS anima Autonomic Networking Integrated Model = and Approach WG FRIDAY, March 27, 2020 1000-1200 Morning Session I Plaza B/C INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Regency C SEC tls Transport Layer Security WG 1220-1350 Morning Session II Regency D ART httpbis HTTP WG Regency C IRTF coinrg Computing in the Network Research Group Regency F SEC *** lake Lightweight Authenticated Key Exchange = WG Georgia A SEC *** rats Remote ATtestation ProcedureS WG From nobody Sun Feb 23 23:55: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 1E5E03A07E2 for ; Sun, 23 Feb 2020 23:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, 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 1_vzbJLf6DBN for ; Sun, 23 Feb 2020 23:55:03 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04on0620.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0c::620]) (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 D265C3A07E1 for ; Sun, 23 Feb 2020 23:55:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ef68UxkSYTZx3jh2cqGcuHsza+9+hsnRVWCRofWcDx1XYRIdTsetKWNTHKw3scS/78DCZKahIvwRu1LDKz1BS1WXrfXYyCjSI/chOkaJIfudSav8N4XbrlNfzL5/wkrra22vLVQx7yVcX4rvh68D/9aFOofaJQKqU5zBSRDpct5iMwtNtmQ+ecjMIzCeX1UYqyJNh5b7J0whfSHuNtXZpLcmI46h+mJBFwyMZjqRiUnzRClVOTen23uYFUqn4G8lvjC2jiCabHcl2LvQCi4WoBG8RrwRavp7y1RaLkEfQfnuC5xi7pO24qYv4qFUTdWNVM+ujryqoi1VdON9CcikkQ== 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=vi2DK0s9JTIfIe1Rv/3iTlW6yEjLwLmSh7eGXzKp4+8=; b=VjC1324PJoOYda0bogcU90UwNKilHK7OMnEIC6P7snF3gjGI/IpXcXkPxSYNqiVriCA0H7zYBfSJy9lXj3W7Tf5aW+ikPoCn15NjNy6zB8ztjXwQrpEF54wv606twBWnXbXlj2bS6yG+AhFdUhWNq2RuGhwMz7eSeOMIo5WTndmwLBGlGCenV6QxQwt2NqniYN61kcBJie2GvQR/PB42N6n1w33GG+t0dmyYTgT+dVfKhx/r3vdMrkhBM8sisFFuOcHPjKNznc84Wnos4wqG+wkccMs9NWRJ2ng7Nbohykya1KGOh4Y1Xcx8+w2FjI8wKj8BzP+U6kEYOtQeSwcKeg== 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=vi2DK0s9JTIfIe1Rv/3iTlW6yEjLwLmSh7eGXzKp4+8=; b=Tb2HzHfkrSAfdE8o7YcH6tZWeva51x8v7NI8+PbztoepRnuXhKBmcmOTUyQT5ZzzYy72k8ELZI0Zl2bL7Cyr2H2rRjAQSqCgMj84zIcejChkYob/CQTCTovykRsvjjGBd+BLeIQI8rFv/zaNh1FgQeaG7qFGqXejc1aEwxPknIw= Received: from AM6PR07MB4053.eurprd07.prod.outlook.com (52.134.117.139) by AM6PR07MB4053.eurprd07.prod.outlook.com (52.134.117.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.9; Mon, 24 Feb 2020 07:54:59 +0000 Received: from AM6PR07MB4053.eurprd07.prod.outlook.com ([fe80::7537:e135:422d:c5a7]) by AM6PR07MB4053.eurprd07.prod.outlook.com ([fe80::7537:e135:422d:c5a7%5]) with mapi id 15.20.2772.012; Mon, 24 Feb 2020 07:54:59 +0000 From: Francesca Palombini To: Mike Jones , Jim Schaad , 'Seitz Ludwig' CC: 'Ace Wg' Thread-Topic: [EXTERNAL] RE: Access token question Thread-Index: AQHV6LOn1YxpaJAAlEyTLIgejF6mBqgl442AgAAZCUCABBIygA== Date: Mon, 24 Feb 2020 07:54:59 +0000 Message-ID: References: <00da01d5e8da$7ce45130$76acf390$@augustcellars.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=a0896083-77dd-4ee6-b1d0-000079222655; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-02-21T18:44:49Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1a203d6a-9f4d-41ca-839d-08d7b8fed906 x-ms-traffictypediagnostic: AM6PR07MB4053: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 032334F434 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(346002)(39860400002)(396003)(376002)(199004)(189003)(33656002)(86362001)(53546011)(91956017)(26005)(76116006)(45080400002)(71200400001)(6486002)(66946007)(36756003)(2616005)(478600001)(44832011)(966005)(81166006)(186003)(5660300002)(8676002)(66476007)(6512007)(316002)(6506007)(66446008)(64756008)(110136005)(81156014)(2906002)(4326008)(66556008)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB4053; H:AM6PR07MB4053.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZmsGaHYYUTVizd1s17M0QUDVKXLYGXa/e/81fHlOYmz8G53WlbkQiwGvBw3mpbKHXYOGVxieWwc1SNiSojCE8MTF5aLW3k4ew0iDqX6H7ABechLRBUrFs6pDNgfUhz1Vz2PvxGXVBqVhSRTZuVI3u/V+Gn+33WOOGo6wgfBv2MafLVfctlFSNDAVXVPEXdIMipxij8YyKfSWmZEXjZkRYiAOHufeMDFNfrFa3Bugcjdp3e7UKmwj0vx4PGcnsXQnnONcx85MpgwKcZBpM5gHLmKEZM5UwUffnW4pUuUW1nUnEL9utSmhQhHFzbRz7oPdyCZ/BiPwQ+0FS9kZJbsBo3VhmslGqjMXd5m/y+6XVNSg/UfGuMi6iXpqQ24Sto43EJFYzA1hw5Hy3lN8QvFGYjikApp5qKzjDkuj4HEoygKVqK1wjAO8f2r88FsQiAbQmA7amkoyELQazYLgARqgpWrB+HqbLwZiqQFkmlM6fjrsAveHgxJePgdNb5oAPweHjKRqtAL12b68O+L3RjMekg== x-ms-exchange-antispam-messagedata: ecsVw+hMw+u/f7dCg+h5KHFHyw25g3k9Vmz1SJ6rtdH/StonB445lq1PLpywb3K1A7hf3712XnQSuB0Co0/HjfwMp4v6Mxk4hVGjMOHxQDuNNlPjrECoaPpd9FJJXYp/qzJRqvv4ylVrS4CJgJsmZA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_D7ED6308E621476E8C4A17B10F5E7356ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1a203d6a-9f4d-41ca-839d-08d7b8fed906 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2020 07:54:59.6672 (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: pkB4WeiTaVMKkiVlw3OteRa6NpfkhBIQ/GPUlXf42Q1Y3Gl0lPRP4NWTIHM8fPEKH1yHJVfcFDUx7GHt2V1IsOSAjSlBcwYc4h94ZjsiiXIPw+/YUIqgE/t+/PocWP5U X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB4053 Archived-At: Subject: Re: [Ace] [EXTERNAL] RE: Access token question 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, 24 Feb 2020 07:55:05 -0000 --_000_D7ED6308E621476E8C4A17B10F5E7356ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGFsbCEgU2VjdGlvbiA4LjEzIG9mIHRoZSBmcmFtZXdvcmsgaXMgZXhhY3RseSB3aGF0 IEkgd2FzIGxvb2tpbmcgZm9yLCBJIGRvbuKAmXQga25vdyBob3cgSSBkaWQgbm90IHNlZSBpdC4g QSBiaXQgc3VycHJpc2VkIHRoZXJlIGlzIG5vIHRleHQgcmVmZXJlbmNpbmcgaXQgaW4gdGhlIGZy YW1ld29yayBpdHNlbGYuDQoNCkFsc28sIGFib3V0IHRoZSDigJxzY29wZeKAnSBjbGFpbSByZWdp c3RyYXRpb246IHRoZSBjbGFpbSBkZXNjcmlwdGlvbiBhbmQgdGhlIHNwZWNpZmljYXRpb24gZG9j dW1lbnQgZ2l2ZSAyIGRpZmZlcmVudCBwb2ludGVycy4gVGhlIGNsYWltIGRlc2NyaXB0aW9uIHJl ZiBwb2ludHMgdG8gdGhlIGRlc2NyaXB0aW9uIGZvciBKV1QgKEpTT04gc3RyaW5nIGV0YyksIEkg dGhpbmsgdGhpcyBzaG91bGQgYmUgYWRhcHRlZCB0byB1c2luZyBDQk9SICh3cml0aW5nIGEgc2Vj dGlvbiBpbiB0aGUgQUNFIGZyYW1ld29yaywgd2hpY2ggY291bGQgdGhlbiByZWZlcmVuY2UgYm90 aCBwb2ludGVycykuIEFsc28gbWlub3IsIEkgd291bGQgYWRkIHRoZSBwcmVjaXNlIHNlY3Rpb24g b2YgNjc0OSB3ZSBzaG91bGQgbG9vayBhdCwgd2hpY2ggSSBhc3N1bWUgaXMgMy4zLg0KDQpGcmFu Y2VzY2ENCg0KRnJvbTogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPg0K RGF0ZTogRnJpZGF5LCAyMSBGZWJydWFyeSAyMDIwIGF0IDE5OjQ1DQpUbzogSmltIFNjaGFhZCA8 aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4sIEZyYW5jZXNjYSBQYWxvbWJpbmkgPGZyYW5jZXNjYS5w YWxvbWJpbmlAZXJpY3Nzb24uY29tPiwgJ1NlaXR6IEx1ZHdpZycgPGx1ZHdpZy5zZWl0ekBjb21i aXRlY2guc2U+DQpDYzogQWNlIFdnIDxhY2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW0VYVEVS TkFMXSBSRTogQWNjZXNzIHRva2VuIHF1ZXN0aW9uDQoNCkFuZCBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjODY5MyNzZWN0aW9uLTcuNCwgd2hpY2ggcmVnaXN0ZXJzIOKAnHNjb3Bl4oCd IGF0IGh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2p3dC9qd3QueGh0bWwuDQoNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAtLSBNaWtlDQoNCkZyb206IEppbSBTY2hhYWQgPGlldGZAYXVndXN0Y2VsbGFycy5jb20+ DQpTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDIxLCAyMDIwIDk6MTUgQU0NClRvOiAnRnJhbmNlc2Nh IFBhbG9tYmluaScgPGZyYW5jZXNjYS5wYWxvbWJpbmlAZXJpY3Nzb24uY29tPjsgJ1NlaXR6IEx1 ZHdpZycgPGx1ZHdpZy5zZWl0ekBjb21iaXRlY2guc2U+OyBNaWtlIEpvbmVzIDxNaWNoYWVsLkpv bmVzQG1pY3Jvc29mdC5jb20+DQpDYzogJ0FjZSBXZycgPGFjZUBpZXRmLm9yZz4NClN1YmplY3Q6 IFtFWFRFUk5BTF0gUkU6IEFjY2VzcyB0b2tlbiBxdWVzdGlvbg0KDQpZb3UgYXJlIG1pc3Npbmcg c29tZXRoaW5nDQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFjZS1v YXV0aC1hdXRoei0zMyNzZWN0aW9uLTguMTM8aHR0cHM6Ly9wcm90ZWN0Mi5maXJlZXllLmNvbS92 MS91cmw/az03MjAwMmQ3ZC0yZWQ0MjZkNi03MjAwNmRlNi04NjRiMGQxMzZiODctNDAwZjA4MmE4 MTgyMjhkZiZxPTEmZT1hNWQ3NmMxMC0zNTdlLTQ4MzQtOWU4Yy01Njk5NmE3NTcyNjgmdT1odHRw cyUzQSUyRiUyRm5hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tJTJGJTNGdXJs JTNEaHR0cHMlMjUzQSUyNTJGJTI1MkZ0b29scy5pZXRmLm9yZyUyNTJGaHRtbCUyNTJGZHJhZnQt aWV0Zi1hY2Utb2F1dGgtYXV0aHotMzMlMjUyM3NlY3Rpb24tOC4xMyUyNmRhdGElM0QwMiUyNTdD MDElMjU3Q01pY2hhZWwuSm9uZXMlMjU0MG1pY3Jvc29mdC5jb20lMjU3QzQxZTI2YmJjZGI3YzRm OTAyZDc5MDhkN2I2ZjFhODYwJTI1N0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyUy NTdDMSUyNTdDMCUyNTdDNjM3MTc5MDIxMzQwNDc4ODY0JTI2c2RhdGElM0RiTW96cUkyQllxTUFB VmlXTElJS3pKQnZRRmEzMGVxS1ZIdHFVaUMzYkg4JTI1M0QlMjZyZXNlcnZlZCUzRDA+DQoNCmRl ZmluZWQgaGVyZQ0KDQpGcm9tOiBGcmFuY2VzY2EgUGFsb21iaW5pIDxmcmFuY2VzY2EucGFsb21i aW5pQGVyaWNzc29uLmNvbTxtYWlsdG86ZnJhbmNlc2NhLnBhbG9tYmluaUBlcmljc3Nvbi5jb20+ Pg0KU2VudDogRnJpZGF5LCBGZWJydWFyeSAyMSwgMjAyMCA0OjM3IEFNDQpUbzogU2VpdHogTHVk d2lnIDxsdWR3aWcuc2VpdHpAY29tYml0ZWNoLnNlPG1haWx0bzpsdWR3aWcuc2VpdHpAY29tYml0 ZWNoLnNlPj47IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86 TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj47IEppbSBTY2hhYWQgPGlldGZAYXVndXN0Y2Vs bGFycy5jb208bWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb20+Pg0KQ2M6IEFjZSBXZyA8YWNl QGlldGYub3JnPG1haWx0bzphY2VAaWV0Zi5vcmc+Pg0KU3ViamVjdDogQWNjZXNzIHRva2VuIHF1 ZXN0aW9uDQoNCkhpLA0KDQpRdWljayBxdWVzdGlvbiByZWdhcmRpbmcgYWNjZXNzIHRva2VuIGFu ZCBzY29wZS4NCkkga25vdyB0aGF0IOKAnHNjb3Bl4oCdIHNlbWFudGljcyBpcyBsZWZ0IHRvIHRo ZSBhcHBsaWNhdGlvbiB0byBkZWZpbmUsIGJ1dCBpbiBnZW5lcmFsIEkgd291bGQgZXhwZWN0IHRv IGluY2x1ZGUgdGhlcmUgc29tZSBpbmZvcm1hdGlvbiBhYm91dCByZXNvdXJjZSBhbmQgbWV0aG9k L29wZXJhdGlvbnMgYWxsb3dlZCBvbiB0aGF0IHJlc291cmNlLiBQbGVhc2UgY29ycmVjdCBtZSBp ZiBhbnkgb2YgdGhpcyBpcyBub3QgZXhhY3QuDQoNCkl0IHdhcyBteSB1bmRlcnN0YW5kaW5nIHRo YXQg4oCcc2NvcGXigJ0gKG9yIG1vcmUgcHJlY2lzZWx5IHRoZSDigJxzY29wZeKAnSB2YWx1ZSkg ZGVmaW5lZCBmb3IgdGhlIENsaWVudC1BUyByZXF1ZXN0IGFuZCByZXNwb25zZSBzaG91bGQgYmUg aW5jbHVkZWQgaW4gdGhlIGFjY2VzcyB0b2tlbiBhcyB3ZWxsLiBDaGVja2luZyBpbiBDV1QsIHRo ZXJlIGlzIG5vIHN1Y2gg4oCcc2NvcGXigJ0gY2xhaW0gZGVmaW5lZC4g4oCcYXVk4oCdIGNsYWlt IGlzIGluZGVlZCBkZWZpbmVkIGZvciB0aGUgQ1dULCBidXQgdGhhdCBzaG91bGQgY29ycmVzcG9u ZCB0byDigJxhdWTigJ0gcGFyYW1ldGVyIGluIHRoZSBBQ0UgcmVxdWVzdC9yZXNwb25zZS4gU28g d2hlcmUgZG8gSSBwdXQgdGhlIGV4YWN0IHJlc291cmNlIGFuZCBvcGVyYXRpb25zIGluIHRoZSBh Y2Nlc3MgdG9rZW4/DQoNCldoYXQgYW0gSSBtaXNzaW5nPw0KDQpGcmFuY2VzY2ENCg== --_000_D7ED6308E621476E8C4A17B10F5E7356ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <624FE7ED6D8BA14394BDABFC2C3F1798@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t R0IiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFua3MgYWxsISBTZWN0aW9uIDguMTMgb2Yg dGhlIGZyYW1ld29yayBpcyBleGFjdGx5IHdoYXQgSSB3YXMgbG9va2luZyBmb3IsIEkgZG9u4oCZ dCBrbm93IGhvdyBJIGRpZCBub3Qgc2VlIGl0LiBBIGJpdCBzdXJwcmlzZWQgdGhlcmUgaXMgbm8g dGV4dCByZWZlcmVuY2luZyBpdCBpbiB0aGUgZnJhbWV3b3JrIGl0c2VsZi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkFsc28sIGFib3V0IHRoZSDigJxzY29wZeKAnSBj bGFpbSByZWdpc3RyYXRpb246IHRoZSBjbGFpbSBkZXNjcmlwdGlvbiBhbmQgdGhlIHNwZWNpZmlj YXRpb24gZG9jdW1lbnQgZ2l2ZSAyIGRpZmZlcmVudCBwb2ludGVycy4gVGhlIGNsYWltIGRlc2Ny aXB0aW9uIHJlZiBwb2ludHMgdG8gdGhlIGRlc2NyaXB0aW9uIGZvcg0KIEpXVCAoSlNPTiBzdHJp bmcgZXRjKSwgSSB0aGluayB0aGlzIHNob3VsZCBiZSBhZGFwdGVkIHRvIHVzaW5nIENCT1IgKHdy aXRpbmcgYSBzZWN0aW9uIGluIHRoZSBBQ0UgZnJhbWV3b3JrLCB3aGljaCBjb3VsZCB0aGVuIHJl ZmVyZW5jZSBib3RoIHBvaW50ZXJzKS4gQWxzbyBtaW5vciwgSSB3b3VsZCBhZGQgdGhlIHByZWNp c2Ugc2VjdGlvbiBvZiA2NzQ5IHdlIHNob3VsZCBsb29rIGF0LCB3aGljaCBJIGFzc3VtZSBpcyAz LjMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5GcmFuY2VzY2E8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+TWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXksIDIxIEZlYnJ1YXJ5IDIwMjAgYXQg MTk6NDU8YnI+DQo8Yj5UbzogPC9iPkppbSBTY2hhYWQgJmx0O2lldGZAYXVndXN0Y2VsbGFycy5j b20mZ3Q7LCBGcmFuY2VzY2EgUGFsb21iaW5pICZsdDtmcmFuY2VzY2EucGFsb21iaW5pQGVyaWNz c29uLmNvbSZndDssICdTZWl0eiBMdWR3aWcnICZsdDtsdWR3aWcuc2VpdHpAY29tYml0ZWNoLnNl Jmd0Ozxicj4NCjxiPkNjOiA8L2I+QWNlIFdnICZsdDthY2VAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+ U3ViamVjdDogPC9iPlJFOiBbRVhURVJOQUxdIFJFOiBBY2Nlc3MgdG9rZW4gcXVlc3Rpb248bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtjb2xvcjojMDAyMDYwIj5BbmQgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzg2OTMjc2VjdGlvbi03LjQiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm Yzg2OTMjc2VjdGlvbi03LjQ8L2E+LCB3aGljaCByZWdpc3RlcnMg4oCcc2NvcGXigJ0gYXQgPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvand0L2p3dC54aHRtbCI+DQpo dHRwczovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9qd3Qvand0LnhodG1sPC9hPi48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjoj MDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij4gSmltIFNjaGFhZCAmbHQ7aWV0ZkBhdWd1c3RjZWxsYXJz LmNvbSZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEZlYnJ1YXJ5IDIxLCAyMDIwIDk6 MTUgQU08YnI+DQo8Yj5Ubzo8L2I+ICdGcmFuY2VzY2EgUGFsb21iaW5pJyAmbHQ7ZnJhbmNlc2Nh LnBhbG9tYmluaUBlcmljc3Nvbi5jb20mZ3Q7OyAnU2VpdHogTHVkd2lnJyAmbHQ7bHVkd2lnLnNl aXR6QGNvbWJpdGVjaC5zZSZndDs7IE1pa2UgSm9uZXMgJmx0O01pY2hhZWwuSm9uZXNAbWljcm9z b2Z0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+ICdBY2UgV2cnICZsdDthY2VAaWV0Zi5vcmcmZ3Q7 PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtFWFRFUk5BTF0gUkU6IEFjY2VzcyB0b2tlbiBxdWVzdGlv bjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Zb3UgYXJlIG1pc3Npbmcgc29tZXRoaW5nPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48YSBocmVmPSJodHRwczovL3Byb3Rl Y3QyLmZpcmVleWUuY29tL3YxL3VybD9rPTcyMDAyZDdkLTJlZDQyNmQ2LTcyMDA2ZGU2LTg2NGIw ZDEzNmI4Ny00MDBmMDgyYTgxODIyOGRmJmFtcDtxPTEmYW1wO2U9YTVkNzZjMTAtMzU3ZS00ODM0 LTllOGMtNTY5OTZhNzU3MjY4JmFtcDt1PWh0dHBzJTNBJTJGJTJGbmFtMDYuc2FmZWxpbmtzLnBy b3RlY3Rpb24ub3V0bG9vay5jb20lMkYlM0Z1cmwlM0RodHRwcyUyNTNBJTI1MkYlMjUyRnRvb2xz LmlldGYub3JnJTI1MkZodG1sJTI1MkZkcmFmdC1pZXRmLWFjZS1vYXV0aC1hdXRoei0zMyUyNTIz c2VjdGlvbi04LjEzJTI2ZGF0YSUzRDAyJTI1N0MwMSUyNTdDTWljaGFlbC5Kb25lcyUyNTQwbWlj cm9zb2Z0LmNvbSUyNTdDNDFlMjZiYmNkYjdjNGY5MDJkNzkwOGQ3YjZmMWE4NjAlMjU3QzcyZjk4 OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTI1N0MxJTI1N0MwJTI1N0M2MzcxNzkwMjEzNDA0 Nzg4NjQlMjZzZGF0YSUzRGJNb3pxSTJCWXFNQUFWaVdMSUlLekpCdlFGYTMwZXFLVkh0cVVpQzNi SDglMjUzRCUyNnJlc2VydmVkJTNEMCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtYWNlLW9hdXRoLWF1dGh6LTMzI3NlY3Rpb24tOC4xMzwvYT48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPmRlZmluZWQgaGVyZTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+IEZy YW5jZXNjYSBQYWxvbWJpbmkgJmx0OzxhIGhyZWY9Im1haWx0bzpmcmFuY2VzY2EucGFsb21iaW5p QGVyaWNzc29uLmNvbSI+ZnJhbmNlc2NhLnBhbG9tYmluaUBlcmljc3Nvbi5jb208L2E+Jmd0Ow0K PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgRmVicnVhcnkgMjEsIDIwMjAgNDozNyBBTTxicj4N CjxiPlRvOjwvYj4gU2VpdHogTHVkd2lnICZsdDs8YSBocmVmPSJtYWlsdG86bHVkd2lnLnNlaXR6 QGNvbWJpdGVjaC5zZSI+bHVkd2lnLnNlaXR6QGNvbWJpdGVjaC5zZTwvYT4mZ3Q7OyBNaWtlIEpv bmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIj5NaWNo YWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OzsgSmltIFNjaGFhZCAmbHQ7PGEgaHJlZj0i bWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb20iPmlldGZAYXVndXN0Y2VsbGFycy5jb208L2E+ Jmd0Ozxicj4NCjxiPkNjOjwvYj4gQWNlIFdnICZsdDs8YSBocmVmPSJtYWlsdG86YWNlQGlldGYu b3JnIj5hY2VAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBBY2Nlc3MgdG9r ZW4gcXVlc3Rpb248L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhpLDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlF1aWNrIHF1ZXN0aW9u IHJlZ2FyZGluZyBhY2Nlc3MgdG9rZW4gYW5kIHNjb3BlLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkkg a25vdyB0aGF0IOKAnHNjb3Bl4oCdIHNlbWFudGljcyBpcyBsZWZ0IHRvIHRoZSBhcHBsaWNhdGlv biB0byBkZWZpbmUsIGJ1dCBpbiBnZW5lcmFsIEkgd291bGQgZXhwZWN0IHRvIGluY2x1ZGUgdGhl cmUgc29tZSBpbmZvcm1hdGlvbiBhYm91dCByZXNvdXJjZSBhbmQgbWV0aG9kL29wZXJhdGlvbnMg YWxsb3dlZCBvbiB0aGF0IHJlc291cmNlLiBQbGVhc2UgY29ycmVjdA0KIG1lIGlmIGFueSBvZiB0 aGlzIGlzIG5vdCBleGFjdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPkl0IHdhcyBteSB1bmRlcnN0YW5kaW5nIHRoYXQg4oCcc2NvcGXigJ0gKG9yIG1vcmUgcHJl Y2lzZWx5IHRoZSDigJxzY29wZeKAnSB2YWx1ZSkgZGVmaW5lZCBmb3IgdGhlIENsaWVudC1BUyBy ZXF1ZXN0IGFuZCByZXNwb25zZSBzaG91bGQgYmUgaW5jbHVkZWQgaW4gdGhlIGFjY2VzcyB0b2tl biBhcyB3ZWxsLiBDaGVja2luZyBpbiBDV1QsIHRoZXJlIGlzIG5vIHN1Y2gg4oCcc2NvcGXigJ0N CiBjbGFpbSBkZWZpbmVkLiDigJxhdWTigJ0gY2xhaW0gaXMgaW5kZWVkIGRlZmluZWQgZm9yIHRo ZSBDV1QsIGJ1dCB0aGF0IHNob3VsZCBjb3JyZXNwb25kIHRvIOKAnGF1ZOKAnSBwYXJhbWV0ZXIg aW4gdGhlIEFDRSByZXF1ZXN0L3Jlc3BvbnNlLiBTbyB3aGVyZSBkbyBJIHB1dCB0aGUgZXhhY3Qg cmVzb3VyY2UgYW5kIG9wZXJhdGlvbnMgaW4gdGhlIGFjY2VzcyB0b2tlbj88L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPldoYXQgYW0gSSBtaXNzaW5nPzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij48YnI+DQpGcmFuY2VzY2E8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D7ED6308E621476E8C4A17B10F5E7356ericssoncom_-- From nobody Mon Feb 24 09:04:50 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 AF9943A0986 for ; Mon, 24 Feb 2020 09:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 61FWRlXsQsT4 for ; Mon, 24 Feb 2020 09:04:44 -0800 (PST) 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 6EF273A0DC0 for ; Mon, 24 Feb 2020 09:04:43 -0800 (PST) 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, 24 Feb 2020 09:04:05 -0800 From: Jim Schaad To: 'Francesca Palombini' , 'Mike Jones' , 'Seitz Ludwig' CC: 'Ace Wg' References: <00da01d5e8da$7ce45130$76acf390$@augustcellars.com> In-Reply-To: Date: Mon, 24 Feb 2020 09:04:02 -0800 Message-ID: <01a201d5eb34$6c2d42f0$4487c8d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A3_01D5EAF1.5E0CE920" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQE2kOYab9UqhopwEMpdnLZbx5Q6WgHomLlhAczfMxUBakNrZalARC7A Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] [EXTERNAL] RE: Access token question 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, 24 Feb 2020 17:04:48 -0000 ------=_NextPart_000_01A3_01D5EAF1.5E0CE920 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I have found that I had to put a scope encoding format into my database = for each audience definition. Just saying that the scope is CBOR is not = going to be sufficient, just like saying that it is a text string is not = enough. =20 For the text string side you have: * It is a text string * It is a text string with space separated values * It is a text string with space separated values and each value has an = underscore which separates operation and resource (MQTT) =20 On the binary side you have: * The proposal from Carsten that has not get adopted anywhere yet. * The group communication format (roughly based on the above format) =20 There is a question about how all of the binary values are going to work = if you do a JSON encoded request rather than a CBOR encoded request. At = the moment, I am assuming that the binary value is encoded (in CBOR) and = then base64url encoded and placed in the JSON. I am not sure if people = are going to want to define this as being native JSON instead depending = on how the fields of the binary format are encoded. =20 Given all of this, I don=E2=80=99t know if adding something to the = framework is going to be generally useful or not. So much of what a = scope looks like is going to be application dependent. With any luck we = are going to be able to get a good set of scope definitions at some = point in the near future and can produce a survey document. I am not = holding my breath on this yet. =20 Jim =20 =20 From: Francesca Palombini =20 Sent: Sunday, February 23, 2020 11:55 PM To: Mike Jones ; Jim Schaad = ; 'Seitz Ludwig' Cc: 'Ace Wg' Subject: Re: [EXTERNAL] RE: Access token question =20 Thanks all! Section 8.13 of the framework is exactly what I was looking = for, I don=E2=80=99t know how I did not see it. A bit surprised there is = no text referencing it in the framework itself. =20 Also, about the =E2=80=9Cscope=E2=80=9D claim registration: the claim = description and the specification document give 2 different pointers. = The claim description ref points to the description for JWT (JSON string = etc), I think this should be adapted to using CBOR (writing a section in = the ACE framework, which could then reference both pointers). Also = minor, I would add the precise section of 6749 we should look at, which = I assume is 3.3. =20 Francesca =20 From: Mike Jones > Date: Friday, 21 February 2020 at 19:45 To: Jim Schaad = >, Francesca Palombini , 'Seitz = Ludwig' > Cc: Ace Wg > Subject: RE: [EXTERNAL] RE: Access token question =20 And https://tools.ietf.org/html/rfc8693#section-7.4, which registers = =E2=80=9Cscope=E2=80=9D at = https://www.iana.org/assignments/jwt/jwt.xhtml. =20 -- Mike =20 From: Jim Schaad = >=20 Sent: Friday, February 21, 2020 9:15 AM To: 'Francesca Palombini' >; 'Seitz Ludwig' = >; Mike = Jones = > Cc: 'Ace Wg' > Subject: [EXTERNAL] RE: Access token question =20 You are missing something =20 https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-33#section-8.13 =20 defined here =20 From: Francesca Palombini >=20 Sent: Friday, February 21, 2020 4:37 AM To: Seitz Ludwig >; Mike Jones = >; Jim = Schaad > Cc: Ace Wg > Subject: Access token question =20 Hi, =20 Quick question regarding access token and scope.=20 I know that =E2=80=9Cscope=E2=80=9D semantics is left to the application = to define, but in general I would expect to include there some = information about resource and method/operations allowed on that = resource. Please correct me if any of this is not exact. =20 It was my understanding that =E2=80=9Cscope=E2=80=9D (or more precisely = the =E2=80=9Cscope=E2=80=9D value) defined for the Client-AS request and = response should be included in the access token as well. Checking in = CWT, there is no such =E2=80=9Cscope=E2=80=9D claim defined. = =E2=80=9Caud=E2=80=9D claim is indeed defined for the CWT, but that = should correspond to =E2=80=9Caud=E2=80=9D parameter in the ACE = request/response. So where do I put the exact resource and operations in = the access token? =20 What am I missing? Francesca ------=_NextPart_000_01A3_01D5EAF1.5E0CE920 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I have found that I = had to put a scope encoding format into my database for each audience = definition.=C2=A0 Just saying that the scope is CBOR is not going to be = sufficient, just like saying that it is a text string is not = enough.

 

For the text string = side you have:

  • It is a text string
  • It is a text string with space = separated values
  • It is a text string with space separated = values and each value has an underscore which separates operation and = resource (MQTT)

 

On the binary side = you have:

  • The proposal from Carsten that has not get = adopted anywhere yet.
  • The group communication format (roughly based = on the above format)

 

There is a question = about how all of the binary values are going to work if you do a JSON = encoded request rather than a CBOR encoded request.=C2=A0 At the moment, = I am assuming that the binary value is encoded (in CBOR) and then = base64url encoded and placed in the JSON.=C2=A0 I am not sure if people = are going to want to define this as being native JSON instead depending = on how the fields of the binary format are = encoded.

 

Given all of this, I = don=E2=80=99t know if adding something to the framework is going to be = generally useful or not.=C2=A0 So much of what a scope looks like is = going to be application dependent.=C2=A0 With any luck we are going to = be able to get a good set of scope definitions at some point in the near = future and can produce a survey document.=C2=A0 I am not holding my = breath on this yet.

 

Jim

 

 

From: Francesca Palombini = <francesca.palombini@ericsson.com>
Sent: Sunday, = February 23, 2020 11:55 PM
To: Mike Jones = <Michael.Jones@microsoft.com>; Jim Schaad = <ietf@augustcellars.com>; 'Seitz Ludwig' = <ludwig.seitz@combitech.se>
Cc: 'Ace Wg' = <ace@ietf.org>
Subject: Re: [EXTERNAL] RE: Access token = question

 

Thanks all! Section 8.13 of the = framework is exactly what I was looking for, I don=E2=80=99t know how I = did not see it. A bit surprised there is no text referencing it in the = framework itself.

 

Also, = about the =E2=80=9Cscope=E2=80=9D claim registration: the claim = description and the specification document give 2 different pointers. = The claim description ref points to the description for JWT (JSON string = etc), I think this should be adapted to using CBOR (writing a section in = the ACE framework, which could then reference both pointers). Also = minor, I would add the precise section of 6749 we should look at, which = I assume is 3.3.

 

Francesca

 

From: Mike Jones <Michael.Jones@microsoft.com>
Date: Friday, 21 February 2020 at 19:45
To: = Jim Schaad <ietf@augustcellars.com>, = Francesca Palombini <francesca.palombini@eric= sson.com>, 'Seitz Ludwig' <ludwig.seitz@combitech.se&g= t;
Cc: Ace Wg <ace@ietf.org>
Subject: RE: = [EXTERNAL] RE: Access token question

 

And https://tools.ie= tf.org/html/rfc8693#section-7.4, which registers = =E2=80=9Cscope=E2=80=9D at https://www.iana.= org/assignments/jwt/jwt.xhtml.

 

     &n= bsp;           &nb= sp;           &nbs= p;            = ;            =           -- = Mike

 

From: Jim Schaad <ietf@augustcellars.com> =
Sent: Friday, February 21, 2020 9:15 AM
To: = 'Francesca Palombini' <francesca.palombini@eric= sson.com>; 'Seitz Ludwig' <ludwig.seitz@combitech.se&g= t;; Mike Jones <Michael.Jones@microsoft.com>
Cc: 'Ace Wg' <ace@ietf.org>
Subject: = [EXTERNAL] RE: Access token question

 

You are = missing something

 

https://tools.ietf= .org/html/draft-ietf-ace-oauth-authz-33#section-8.13

 

defined here

 

From: Francesca Palombini <francesca.palombini@eric= sson.com>
Sent: Friday, February 21, 2020 4:37 = AM
To: Seitz Ludwig <ludwig.seitz@combitech.se&g= t;; Mike Jones <Michael.Jones@microsoft.com>; Jim Schaad <ietf@augustcellars.com>
= Cc: Ace Wg <ace@ietf.org>
Subject: = Access token question

 

Hi,

 

Quick question regarding access = token and scope.

I know = that =E2=80=9Cscope=E2=80=9D semantics is left to the application to = define, but in general I would expect to include there some information = about resource and method/operations allowed on that resource. Please = correct me if any of this is not exact.

 

It was my understanding that = =E2=80=9Cscope=E2=80=9D (or more precisely the =E2=80=9Cscope=E2=80=9D = value) defined for the Client-AS request and response should be included = in the access token as well. Checking in CWT, there is no such = =E2=80=9Cscope=E2=80=9D claim defined. =E2=80=9Caud=E2=80=9D claim is = indeed defined for the CWT, but that should correspond to = =E2=80=9Caud=E2=80=9D parameter in the ACE request/response. So where do = I put the exact resource and operations in the access token?

 

What am I missing?


Francesca

------=_NextPart_000_01A3_01D5EAF1.5E0CE920-- From nobody Mon Feb 24 10:02: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 1E3393A1040; Mon, 24 Feb 2020 10:02:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ldam6sK2sTO1; Mon, 24 Feb 2020 10:02:38 -0800 (PST) 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 AF5403A1034; Mon, 24 Feb 2020 10:02:35 -0800 (PST) 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, 24 Feb 2020 10:02:19 -0800 From: Jim Schaad To: CC: 'Ace Wg' Date: Mon, 24 Feb 2020 10:02:17 -0800 Message-ID: <01b501d5eb3c$8e7d9e60$ab78db20$@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: AdXrOKpmWNataaOcRlGMfJexQnZTiA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Ace] Scope question 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, 24 Feb 2020 18:02:40 -0000 I was starting to code up the encoding of scope and wanted to clarify what the encoding is. The text appears to say that the encoding is: scope = [ groupId: tstr, ?[* role : any ]] I was expecting this to be more along the lines of scope = [ + scope_item ] scopeItem = [ groupId: tstr, ?[* role : any ]] This would allow for more than one group to be identified in a single token which I think is important given some of the statements about only having a single token for a client. This does not solve the resource server having multiple audiences but that is fine. I am unsure if it makes sense to allow for the array to be removed for scope in the second example in the event that only one group is specified. One byte saved at the expense of more code. Jim From nobody Mon Feb 24 12:14: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 7CD983A1250 for ; Mon, 24 Feb 2020 12:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 TX54za4Hjvwr for ; Mon, 24 Feb 2020 12:14:53 -0800 (PST) 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 CF7BB3A0EB8 for ; Mon, 24 Feb 2020 12:14:52 -0800 (PST) Received: from client-0217.vpn.uni-bremen.de (client-0217.vpn.uni-bremen.de [134.102.107.217]) (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 48RCwC0ggkz10sF; Mon, 24 Feb 2020 21:14:51 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Carsten Bormann In-Reply-To: <01a201d5eb34$6c2d42f0$4487c8d0$@augustcellars.com> Date: Mon, 24 Feb 2020 21:14:50 +0100 Cc: Francesca Palombini , Mike Jones , Seitz Ludwig , Ace Wg X-Mao-Original-Outgoing-Id: 604268090.447413-05a4db474518ccd0d05232b5a83c8fdc Content-Transfer-Encoding: quoted-printable Message-Id: <57654FD4-108A-4305-A3CE-946E6A7DED01@tzi.org> References: <00da01d5e8da$7ce45130$76acf390$@augustcellars.com> <01a201d5eb34$6c2d42f0$4487c8d0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Ace] [EXTERNAL] RE: Access token question 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, 24 Feb 2020 20:14:56 -0000 On 2020-02-24, at 18:04, Jim Schaad wrote: >=20 > =E2=80=A2 The proposal from Carsten that has not get adopted = anywhere yet. Well, not adopted in the literal sense, but it has been used as a = blueprint both in research works and in standardization. The main question that is holding this back from being a more complete = solution is how to represent authorization that is dependent on request = parameters (in particular, in bodies, both FETCH and POST/PATCH). Maybe that is too hard to do in a generic way, and AIF should focus on = providing a placeholder for profile specific information about request = body handling. (I have taken the opportunity to resubmit AIF with updated references:=20= https://datatracker.ietf.org/doc/draft-bormann-core-ace-aif/ .) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Feb 24 14:13: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 15B623A1453; Mon, 24 Feb 2020 14:13:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=risecloud.onmicrosoft.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 qV71e4n0FxWS; Mon, 24 Feb 2020 14:13:53 -0800 (PST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on20610.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e1b::610]) (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 DEC793A1450; Mon, 24 Feb 2020 14:13:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AQXJG17CmPJ17qWbrehYZskqXV4EIUeQj5fdMQCZBRH62wByKic4HLwFauARYnGQFEZEE6qRlLIjAMbGIosqUcHGdHwiQJfL9OOQc76etaW9g6GmT116uvnQ9NI4j15c8ZsVU4KfSFJ+k2nwcTSdVusYKcbTmmLnU+1lmCZdqRzgWk0Jsw5WqYM4gfENJczFwvRc/4vxVaIBVcYoqEWMFxecYb8gclie4hxAckv8swn9IG0Ir5mXOiAVf/vKWJmdoWpg52yLLMt+81YREzVAdzFdEGwpLBFb0DjjQk/Ow78Wsk521kirYcBu9T0zWI8zeNUKr2t8cjmb7XW3jAN0fQ== 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=sKmDLs9CCkirJ/UufHPP2B21i5iDZKFIbcMdbauKE7g=; b=cwXVhnLFx8D4RkZM4TY1YfeyD8RseYgJfMU41rDB/eR5WWJz3Ux51n5rPyMmtXaC2FxWTDGAlhCD1cfxuSmRArgpWL0fFvTR819+srIazpMQt2ktHop1m8KgQSV3YybsjQumFLCiwqwVrZz4RHFb3t8zJUoUpIE8Aw7ejZ1CCQZU2dNiF1CcnqHgaReKzvqK1WvVrDay8hGTF3W2PC6Sf2/GlQh5ldh5PDPP3Z4oLQRUINREqvqCBWQTyJq5YX+8z8cUKN514Lov3dawJttH034FAelX/zF5s6//ZkzvqShO2+pOeTlOHZsf3SCj30ecn2eKzEK2B2shtjRiQt/6aQ== 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=RISEcloud.onmicrosoft.com; s=selector1-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sKmDLs9CCkirJ/UufHPP2B21i5iDZKFIbcMdbauKE7g=; b=K9PQIGqbX3BaqW8hKeocJ1T3wyZEIXO7pmuwOyMP6YDFJxm9de4kl2A7kkjw/Km+eVoBUWCDMa3SCRpi/O/B6EZ5HzPmjwHGJjBrgJkpG3t6mZCw9ehiNlGr3QAgk+Yt7azCI4f72tZrwLkokTYPlJzSL5jV6BR8AT1ylFV8n8g= Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (10.165.195.159) by VI1P189MB0463.EURP189.PROD.OUTLOOK.COM (10.165.195.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.21; Mon, 24 Feb 2020 22:13:49 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::80e4:7dc7:7d4e:c9cb]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::80e4:7dc7:7d4e:c9cb%4]) with mapi id 15.20.2750.021; Mon, 24 Feb 2020 22:13:49 +0000 Received: from [10.8.2.31] (178.239.173.196) by AM3PR05CA0093.eurprd05.prod.outlook.com (2603:10a6:207:1::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.18 via Frontend Transport; Mon, 24 Feb 2020 22:13:48 +0000 From: Marco Tiloca To: Jim Schaad , "draft-ietf-ace-key-groupcomm-oscore@ietf.org" CC: 'Ace Wg' Thread-Topic: Scope question Thread-Index: AdXrOKpmWNataaOcRlGMfJexQnZTiAAJwHAA Date: Mon, 24 Feb 2020 22:13:49 +0000 Message-ID: References: <01b501d5eb3c$8e7d9e60$ab78db20$@augustcellars.com> In-Reply-To: <01b501d5eb3c$8e7d9e60$ab78db20$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-clientproxiedby: AM3PR05CA0093.eurprd05.prod.outlook.com (2603:10a6:207:1::19) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) authentication-results: spf=none (sender IP is ) smtp.mailfrom=marco.tiloca@ri.se; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [178.239.173.196] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 08dfddab-2bc9-4120-9872-08d7b976d2cb x-ms-traffictypediagnostic: VI1P189MB0463: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 032334F434 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(396003)(39860400002)(376002)(366004)(189003)(199004)(52116002)(4326008)(31686004)(53546011)(31696002)(86362001)(66476007)(16526019)(66616009)(186003)(6486002)(26005)(66946007)(66556008)(64756008)(66446008)(3480700007)(7116003)(44832011)(5660300002)(478600001)(966005)(8936002)(8676002)(81166006)(81156014)(2906002)(956004)(316002)(110136005)(16576012)(66574012)(36756003)(2616005)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P189MB0463; H:VI1P189MB0398.EURP189.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ri.se does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: e/YkeK++QMO9scP9On8TBZ2Etm/rWdDihwoVq7Z+tR6Sic5GdkTWRrCM0aUuG6flacq7ei6nSb5HrZD4ZFC+0wW/dhKYuD4Dnv2IZ4HRukM9ZFBzC/qSvLR9e8+CJHfdXWYGIECcXZqVNiv95H0ZBpHFz4AjM+dCfSCU2aHPdzHXZ9vHWute/5AvKVoNy1YzT4z6fk/NFbPpxQDXFwB8GP6A1hnLZWM0Fr8NqwwrKAPiHkT1pK43/RC1AkRpvOSkZCWmEZk6FYr7jJOvhU2bDqQpBogqF1Rtiwn+Z+im6E/QDFw3q6ClmlHug6TA9PoZvAwFG62JOqndEqGAS0oIRIm1D+gBRy8/+eebPKa6jYjKfBe0FmI53YN4atu/v5HX41DLD+Gz1CR/ju1exUDwAdFdDcy0fogUn8WgNE8Lrj6MhbGOfO2qcCopQKR+WmbIVTUYEpKsOOCfYAEj66zXa8qEJ6uXg1XtjOvhqXEtJhCVWjvhujNd/+m4+hLy05fuFQmnHv3UkkB2U+apveXKNQ== x-ms-exchange-antispam-messagedata: 8lPE8sK9t/iJiTZ4Tlsc/fIz+iwf8wgDSNVWuRnjmL9zcXemBskosAfLVXN/OswqBQuYKsGmuIs9StQyQYbpKYwtkPB8nMNW+YKN2p+/1/UO5uLUqzhSi9GToJDuxiD3ORjGFe3DCPwEJ0UDAgk1Kw== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RfZFbjllJeZC52RjyLEXoiaaHTKRUhbHZ" MIME-Version: 1.0 X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 08dfddab-2bc9-4120-9872-08d7b976d2cb X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2020 22:13:49.1351 (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: GCyjprpabj7U1UK0riEIGqLGseqlsC/anJ1cEB6IimCGDhtFvI7Su9DMWoBo7VQ0CC6rBZtNTQyTnU1oUdfkEQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0463 Archived-At: Subject: Re: [Ace] Scope question 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, 24 Feb 2020 22:13:56 -0000 --RfZFbjllJeZC52RjyLEXoiaaHTKRUhbHZ Content-Type: multipart/mixed; boundary="t4zAuvwFqKAypV7ZsG1QQyXha4AbrxNPf" --t4zAuvwFqKAypV7ZsG1QQyXha4AbrxNPf Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Jim, On 2020-02-24 19:02, Jim Schaad wrote: > I was starting to code up the encoding of scope and wanted to clarify w= hat > the encoding is. > > The text appears to say that the encoding is: > > scope =3D [ groupId: tstr, ?[* role : any ]] > > I was expecting this to be more along the lines of > > scope =3D [ + scope_item ] > scopeItem =3D [ groupId: tstr, ?[* role : any ]] =20 > > This would allow for more than one group to be identified in a single t= oken > which I think is important given some of the statements about only havi= ng a > single token for a client. This does not solve the resource server hav= ing > multiple audiences but that is fine. =3D=3D>MT At the January interim, we mentioned a multi group/topic scope as next step. The format you suggest above is essentially the one we also had in mind. This should be firstly defined in the ace-key-groupcomm document. This should be just fine for the Token request/response and the Access Token itself. Then I am thinking of what happens next. In a general case, in each of the specified groups a different signature algorithm (etc.) is used. Then, in the 2.01 response from /authz-info , we would have 'sign_info' also as an array of arrays and 'pub_key_enc' as an array (unless the very same configuration applies for each scopeItem above). Same goes for 'rsnonce' becoming an array. The order of such arrays' elements is the same as for the scopeItems in the 'scope' claim. <=3D=3D > > I am unsure if it makes sense to allow for the array to be removed for = scope > in the second example in the event that only one group is specified. O= ne > byte saved at the expense of more code. =3D=3D>MT I think it makes sense to avoid that byte, and essentially revert to the original scope format when only one group is specified. <=3D=3D Best, /Marco > > Jim > > --=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 --t4zAuvwFqKAypV7ZsG1QQyXha4AbrxNPf-- --RfZFbjllJeZC52RjyLEXoiaaHTKRUhbHZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl5USpYACgkQ7iZktA5Y 2kMcRAf+NWdTQaT7jiPyh45FTu87vKpkam29GNW8Vau3fj1SESZ2Ld8RRb166Oem OBvjkNrapBC+bU3C9XtVvohnSe76o21pZ6DwqbaTjdZMeS/qnAAzhr5psgYgXoko +4BoYeNTn7Vear2jXYNO3J2ntwsCH0HxfDzuU7zsKuFwpfvWS0lbPPyWTe78O10s z0+ApWsKY8Ff+Qf92j3kvI8WohOx0WXIBs/yeiT4/eZoW5JE01Wfpzh6ZyFNduHr FPRoKnfaLpiyQA8YvMOG8OZr/8BgtjjvlTcIcx8EU0UzyEOSHDINiADruo2nUapp VMlyPOKCNHaZmTeBjPvIk+ig7XU2Yw== =ohm0 -----END PGP SIGNATURE----- --RfZFbjllJeZC52RjyLEXoiaaHTKRUhbHZ-- From nobody Mon Feb 24 21:17: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 9E1683A09DE; Mon, 24 Feb 2020 21:17:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 C0ZtEc7vY4Jx; Mon, 24 Feb 2020 21:17:32 -0800 (PST) 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 81C503A09B1; Mon, 24 Feb 2020 21:17:31 -0800 (PST) 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, 24 Feb 2020 21:17:21 -0800 From: Jim Schaad To: 'Marco Tiloca' , CC: 'Ace Wg' References: <01b501d5eb3c$8e7d9e60$ab78db20$@augustcellars.com> In-Reply-To: Date: Mon, 24 Feb 2020 21:17:18 -0800 Message-ID: <01f301d5eb9a$db047110$910d5330$@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: AQJLn6qW+CeKP8sCHW2O8QWjx2MEkwHcNwUYpzETjrA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] Scope question 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, 25 Feb 2020 05:17:34 -0000 -----Original Message----- From: Marco Tiloca =20 Sent: Monday, February 24, 2020 2:14 PM To: Jim Schaad ; = draft-ietf-ace-key-groupcomm-oscore@ietf.org Cc: 'Ace Wg' Subject: Re: Scope question Hi Jim, On 2020-02-24 19:02, Jim Schaad wrote: > I was starting to code up the encoding of scope and wanted to clarify=20 > what the encoding is. > > The text appears to say that the encoding is: > > scope =3D [ groupId: tstr, ?[* role : any ]] > > I was expecting this to be more along the lines of > > scope =3D [ + scope_item ] > scopeItem =3D [ groupId: tstr, ?[* role : any ]] > > This would allow for more than one group to be identified in a single=20 > token which I think is important given some of the statements about=20 > only having a single token for a client. This does not solve the=20 > resource server having multiple audiences but that is fine. =3D=3D>MT At the January interim, we mentioned a multi group/topic scope as next = step. The format you suggest above is essentially the one we also had in = mind. This should be firstly defined in the ace-key-groupcomm document. This should be just fine for the Token request/response and the Access = Token itself. Then I am thinking of what happens next. In a general = case, in each of the specified groups a different signature algorithm (etc.) is used. Then, in the 2.01 response from /authz-info , we would have 'sign_info' also as an array of arrays and 'pub_key_enc' as an array (unless the = very same configuration applies for each scopeItem above). Same goes for = 'rsnonce' becoming an array. The order of such arrays' elements is the = same as for the scopeItems in the 'scope' claim. <=3D=3D [JLS] I am having some problems with thinking that this is a good idea. = The only reason to have different signing keys is to keep the different = signature keys isolated in terms of correlation. If this is the case = then adding a situation where we are going to share this information = with a specific entity seems to be a bad idea. I would think that if = the signing keys are going to be separate then that should be true all = of the back as far as possible. This would mean that, if possible, that = even the AS should not know that the different signing keys are = associated with the same entity. Jim > > I am unsure if it makes sense to allow for the array to be removed for = > scope in the second example in the event that only one group is=20 > specified. One byte saved at the expense of more code. =3D=3D>MT I think it makes sense to avoid that byte, and essentially revert to the = original scope format when only one group is specified. <=3D=3D Best, /Marco > > Jim > > -- 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 From nobody Mon Feb 24 21:34: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 DA9893A0A34; Mon, 24 Feb 2020 21:34:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 cEDR_c45fGqu; Mon, 24 Feb 2020 21:34:11 -0800 (PST) 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 86CC03A0A33; Mon, 24 Feb 2020 21:34:08 -0800 (PST) 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 01P5Y1QY013319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 Feb 2020 00:34:03 -0500 Date: Mon, 24 Feb 2020 21:34:00 -0800 From: Benjamin Kaduk To: Francesca Palombini Cc: Ace Wg , "draft-ietf-ace-oscore-profile@ietf.org" Message-ID: <20200225053400.GF5814@kduck.mit.edu> References: <20200107163851.GV57294@kduck.mit.edu> <4086FADE-7993-47F6-9292-FDD7FC5457B4@ericsson.com> <20200203040600.GM91553@kduck.mit.edu> <8B7C0C63-3F8D-478A-907C-E424649FC6C5@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8B7C0C63-3F8D-478A-907C-E424649FC6C5@ericsson.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-oscore-profile-08 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, 25 Feb 2020 05:34:14 -0000 Hi Francesca, Sorry to cut this so close to the wire...I was on vacation and came back to a sizeable inbox. On Mon, Feb 17, 2020 at 03:55:29PM +0000, Francesca Palombini wrote: > Hi Ben, > > I am now done with updating the draft following most of your review comments. Out of the 105, I have implemented 88 in the draft, while those left need agreement in the wg as previously mentioned, or require your OK (see inline). > > You can see the result of the update in the PR here: https://github.com/ace-wg/ace-oscore-profile/pull/25 If you give me the go-ahead, I will merge this PR and submit a new version, and then we can continue working on the open issues. I will have to download the changes locally to view them, as the in-browser viewer does not do well with the long lines. > These open issues are: > > * The mechanism of letting the RS pick the identifier of the client is not worth the additional complexity. > 6, 7, 32, 61, 65, > * Recommendation about length of nonces N1 and N2 to use. > 5, 52 > * Define and register 2 new ACE parameters to transport the nonces used in the exchange, instead of using "cnonce". > 3, 53, 60 > * Check with IANA > 102 > > I hope to discuss these in the mailing list (continuing on the separate thread), and at the interim. > > I will cut and paste the rest (46 , 47, 58 , 67 , 92 + a couple of more) which I have answered below, whatever is not reported below I found no issue in doing the modifications you suggested, or is covered by the open points I mentioned. Please do bring any of those I do not touch on up again if you feel they were not solved in the PR. > > Thanks again for your extensive review! > Francesca > > On 03/02/2020, 05:06, "Benjamin Kaduk" wrote: > > 29. The AS MUST also assign an identifier to the RS (serverId), MAY > > assign an identifier to the client (clientId), and MAY assign an > > identifier to the context (contextId). These identifiers are then > > used as Sender ID, Recipient ID and ID Context in the OSCORE context > > as described in section 3.1 of [I-D.ietf-core-object-security]. The > > couple (client identifier, context identifier) MUST be unique in the > > set of all clients on a single RS. Moreover, when assigned, > > serverId, clientId and contextId MUST be included in the > > OSCORE_Security_Context, as defined in Section 3.2.1. > > > > When certain fields are optional, we typically have to ask whether it's > > possible for the two parties to disagree about whether the field is > > present. IIUC, the OSCORE context derivation procedure includes enough > > information to prevent that possibility, but it would be good if someone > > would confirm that. > > > > FP: That is correct, a number of fields have default values when non present. Hkdf, alg, salt, contextId, rpl. On the other hand, ms, clientId and serverId need to be set. > > Hmm, so there is not a great mechanism to distinguish "absent" from > "present with default value", but the practical consequences of such an > attack seem quite limited. > > FP: That is right. I did not add any text about this, as this is more OSCORE implication. That's okay. > > > > 34. "access_token" : h'a5037674656d7053656e73 ...' > > (remainder of access token omitted for brevity)', > > > > In addition to the invalid-CBOR-diagnostic-notation-syntax comment, we > > also have unbalanced quotes. > > > > FP: Right, but this is not valid CBOR diagnostic notation syntax anyway, do you have a better idea? I do not think it would be useful to have the full token here. Will remove the unbalanced quote. > > This is probably manageable, though we do often see people put a disclaimer > before the example that are truncated for readability; > some other ADs may have other suggestions, too. > > FP: Thanks for the input text :) Now added. > > ... > > > 43. hkdf: This parameter identifies the OSCORE HKDF Algorithm. For more > > information about this field, see section 3.1 of > > [I-D.ietf-core-object-security]. The values used MUST be > > registered in the IANA "COSE Algorithms" registry and MUST be > > HMAC-based HKDF algorithms. The value can either be the integer > > > > It's a little unfortunate that we basically are relying on "I know it > > when I see it" for determining which algorithms are HKDF algorithms. > > > > FP: Agreed, but we don’t really have another way to say this. If you or COSE experts (Jim) have any idea please let us know. > > I think we inherited this from JOSE :-/ > > FP: That would make sense. I have not done any modifications here, still waiting for more input if any. I don't know of any modifications that would help. > > Also, "HKDF" expands to "HMAC-based Extract-and-Expand Key Derivation > > Function", i.e., is definitionally HMAC-based. So this should be > > reworded to reflect the actual intent. > > > > FP: Right, that is because COSE also defines HKDF using AES-MAC, see Table 12 of RFC8152, so we needed to specify that only HMAC-based can be used. > > Oof, rather unfortunate IMO that the terminology was overloaded by RFC > 8152. > > FP: Agreed. Again no modifications following this point (or the analogous 44. About AEAD alg). Okay. > > 46. rpl: This parameter is used to carry the OSCORE value, encoded as a > > bstr. This parameter identifies the OSCORE Replay Window Size and > > Type value, which is a byte string. For more information about > > this field, see section 3.1 of [I-D.ietf-core-object-security]. > > In JSON, the "rpl" value is a Base64 encoded byte string. In > > CBOR, the "rpl" type is bstr, and has label 8. > > > > I tried to follow the reference, but I couldn't really find a > > description of the encoding for this as a byte string (especially > > noteworthy since we claim that it represents both size and type). > > (Relatedly, I'm not sure why it's allowed to be either bstr or int.) > > > > FP: Right, this is an old reference, where we actually gave a default encoding for rpl, I believe. Now this is entirely up to the application. I would keep this as bstr and specify that it is any format wrapped in a bstr. > > "Up to the application" meaning known by prior agreement among all three of > C, AS, and RS? > > FP: There is no need for the 3 nodes to be in agreement on the replay window on the RS. After thinking a bit more about this, I think I'd like to remove this parameter completely from this object. The idea here was that the AS is able to tell the RS what type and size of replay window to use, but I do not see a reason why the AS should send this info to the RS. Window type and size is implementation related, and each RS node can have its own. It's not even just the AS sending this to the RS, though, right? This section is for the token response from AS to C, and the OSCORE_Security_Context object is for cleartext information that the AS gives to the C alongside the token. (It might also be represented in the token as well, but this is where the text in question occurs.) I may be forgetting something, but the replay windows sounds like it could just be entirely local to the RS (and not something the client needs to know the implementation of), so removing this parameter seems to make sense. (And after all, we have a registry now for the OSCORE_Security_Context contents, so we could allocate the codepoint later if needed.) > > Also I need to fix a couple of mistakes: “OSCORE value” is wrong; “Replay Window” and not "Size and Type". Also, I think we need to define a new IANA registry for rpl with 0 as default, so that applications can define their format. > > I'm not entirely sure I understand that the registry is for (i.e., what you > propose). > > FP: disregard that. I was thinking we might want to have a registry for different types of replay windows, but considering the comment above I do not think it's needed anymore. > > > Section 4 > > > > 47. Can we get some CDDL or similar for both C-to-RS and RS-to-C (in the > > respective subsections)? > > > > FP: I am not sure what you’d like to see in CDDL in this subsection, could you expand? > > I am not sure what the body of the POST and response thereto are formatted > as. Maybe CDDL is not quite right, if we only want to provide an example > with a particular content-format but allow many formats. > > FP: I think this should be covered in the examples of those 2 messages, see figures 11 and 12. Anything else needed? I would prefer to have something that looks more like a formal syntax than just relying on examples, though I don't insist upon it for now. (Some other ADs might, though.) > > 51. Note that the proof-of-possession required to bind the access token > > to the client is implicitly performed by generating the shared OSCORE > > Security Context using the pop-key as master secret, for both client > > and RS. An attacker using a stolen token will not be able to > > generate a valid OSCORE context and thus not be able to prove > > possession of the pop-key. > > > > It may be worth saying something roughly equating "proof of possesion > > performed by the RS" and "the RS authenticating itself to the client", > > since there is not an external action for server authentication. > > Also, ISTR getting some pushback on a different document that talked > > about an attacker with a "stolen token", as something that can steal a > > token from the client's local storage might also steal the associated > > key. I forget if we ended up changing to some other phrasing or not, > > though :( > > > > FP: Ok, will rephrase to “the RS authenticating itself” instead of “pop performed by the RS”. Also, what about using eavesdrop here instead? > > Eavesdrop may be too limited, as I think it's also in scope for the attack > when an RS receives (whether legitimately or by deception) the token in > question as the target of a CoAP request. > > FP: Ok, did not use the term eavesdrop. > > > 58. to claims that the RS cannot process (e.g., an unknown scope), or if > > any of the expected parameters in the OSCORE_Security_Context is > > > > Hmm, "associated to claims that the RS cannot process" sounds like we're > > telling the RS to abort if the token includes any unrecognized claims, > > which IIUC is at odds with the OAuth 2.0 philosophy of ignoring > > unrecognized parameters. (Hopefully someone will correct me if I'm > > misremembering that.) > > > > FP: This paragraph is meant to mirror what specified in 5.8.1.1 of ace-oauth-authz: > > If the claims cannot be obtained the RS MUST discard the token > > and, in case of an interaction via the authz-info endpoint, return > > an error message with a response code equivalent to the CoAP code > > 4.00 (Bad Request). > > Next, the RS MUST verify claims, if present, contained in the access > > token. Errors are returned when claim checks fail, in the order of > > priority of this list: > > Ah, maybe the ace framework diverges from oauth here and I misremembered. > But is this behavior limited to "any of the four standard claims that have > a value that cannot be processed" or does it also include "there was an > unrecognized claim"? > > FP: Yes, I checked with Ludwig who confirmed that the framework diverges from oauth and that it's for any unrecognized claims. So I did not do any modifications here. Okay, thanks for confirming and sorry for misremebmering. > > 67. After sending the 2.01 (Created) response, the RS MUST set the Master > > Salt of the Security Context created to communicate with the client > > to the concatenation of salt, N1, and N2, in this order: Master Salt > > = salt | N1 | N2, where | denotes byte string concatenation, and > > > > [It might be worth breaking this computation off into a standalone piece of > > text that applies to both C and RS, including the edits for injectivity.] > > > > FP: OK > > FP: I tried to do this, but did not manage to implement the change in a satisfactory way that would improve readability, so I gave up. The reason is that the text that is actually the same is only "Master Salt is the concatenation of ...", while the surrounding text is very much node-specific. Also, the text is written in a way to sequentially explain client and RS processing. Moving this text around would make the reader jump from a section to another. If you have suggestions on a better way to structure this text, I'll take them. Thank you for trying; I don't think we need to go to great lengths to make this refactoring happen. > > 76. authorization information from the access token associated to the > > Security Context. The RS then MUST verify that the authorization > > information covers the resource and the action requested. > > > > In the vein of my previous note about an abstract data model, we may not want > > to be overly prescriptive about "retrieves [...] from the access token". > > Per-request introspection is allowed, as is caching the authorization > > information in a non-token local datastore. > > > > FP: Ok, I understand but I am not sure how to implement this comment. “Retrieve” may be misinterpreted, but in my mind it can mean both by looking up caching info as well as introspecting. How to make this clearer? > > Would s/from/using/ work? > > FP: Yes! Thanks. > > > > > 92. o Profile Description: Profile for using OSCORE to secure > > communication between constrained nodes using the Authentication > > and Authorization for Constrained Environments framework. > > > > This is the registry for ACE profiles; "using the Authentication and > > Authorization for Constrained Envirornments framework" feels redundant. > > There's also perhaps something to say about defining "coap_oscore" for all > > three interaction flows even though the procedures for two of the three are > > essentially just "out of the scope of this specification", though having > > *some* identifier for "use OSCORE" is probably still useful. > > > > FP: Ok, we can remove the last part. About the interaction flows between nodes, I am not sure what you mean, as by following definition https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-31#section-5.6.4.3 it is not mandatory for a profile to specify C-AS and RS-AS, those flows can be out of scope. Am I missing something? > > It's not mandatory, though given that we talk about profiles not being able > to assume that the same profile is used for any/all of C/RS, C/AS, and > RS/AS, I guess I assumed that we use the profile identifier to talk about > the last two cases as well as the first one. Maybe I'm wrong to assume > that! > > FP: From my understanding, that's not the case, as I said above. Maybe someone else can confirm. > > Regardless, I think the question here is whether we want to have people use > the "coap_oscore" string to indicate that C/AS and/or RS/AS use OSCORE, or > if that information is not expected to be encoded in any protocol element; > if the latter, then there's nothing to change. > > FP: As of now, that information is not expected to be encoded in any protocol element, as far as I understand. Again, if anybody can confirm/shout if wrong, please do. Okay. I would be happy to hear from the WG if there are other known uses like this. > > 96. "OSCORE_Security_Context" feels like a somewhat long name in light of the > > previous commentary about shorter names being preferred. :) > > > > FP: Typically this whole name should not be sent when CBOR is used (so in constrained environments). But we’ll shorten it, what about "Sec_Ctx"? > > There's no need to shorten it just on my account; as you note, it's > generally going to be the CBOR tag that's used. > > FP: I ended up shortening the name of the CWT parameter to "osc" (same as JWT), even though the CBOR label would be used instead, but kept the "OSCORE_Security_Context" as the name for the CBOR map. I think it's better to separate between the CBOR object and the CWT field's name. That seems likely to be a good idea; I'll try to remember to look for it when I'm reading the diff. Thanks! -Ben From nobody Tue Feb 25 02:01:24 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 102753A07EA for ; Tue, 25 Feb 2020 02:01:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=woUc7aVo; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=woUc7aVo Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-D2oZrl4-Wj for ; Tue, 25 Feb 2020 02:01:20 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02on0602.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe07::602]) (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 434A33A07E9 for ; Tue, 25 Feb 2020 02:01:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9VIbGHStO1V5IvfuR26Em7KiNBBEYP0ry5eKgsGcUnc=; b=woUc7aVobEqANYCNDFlgf1cjdLt294h9hh4/xPRI4we1j7dUgvH3Tsk9jF/rlGoX8MudcfQM518NKxi9mxnJOmUAR2nJPZk2Tidcji1kTcwG1EimdI7wqCnmhDVD7Qs9k7g/vVOsmVYBP36Vx3CZTw/d7Tjy4bCg/fjwRWGNS/o= Received: from VI1PR08CA0141.eurprd08.prod.outlook.com (2603:10a6:800:d5::19) by VI1PR08MB5453.eurprd08.prod.outlook.com (2603:10a6:803:132::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.21; Tue, 25 Feb 2020 10:01:14 +0000 Received: from AM5EUR03FT041.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e08::201) by VI1PR08CA0141.outlook.office365.com (2603:10a6:800:d5::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.18 via Frontend Transport; Tue, 25 Feb 2020 10:01:14 +0000 Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT041.mail.protection.outlook.com (10.152.17.186) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.17 via Frontend Transport; Tue, 25 Feb 2020 10:01:12 +0000 Received: ("Tessian outbound efdea641ed36:v42"); Tue, 25 Feb 2020 10:01:12 +0000 X-CR-MTA-TID: 64aa7808 Received: from d4f07dee5564.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id CE7DF423-48A1-4815-805C-F80A4980877A.1; Tue, 25 Feb 2020 10:01:07 +0000 Received: from EUR05-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id d4f07dee5564.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 25 Feb 2020 10:01:07 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=b1HB/7SVlobJmOxscECrwo0Qc2KW6L2JlgxVwo2A3/O/xlXz3AtpV0lK+o5UsqsJ9UaATQSwO6ssZhG1U5lWAaFX1/P6/5pQPucA1NuilgCwrtDYsjj+v3OdoC/+3wQlLnkOVOc8Vy2u9qE24bPF8tSlPj8IX7QY5oehkcs0KFSwZtNjk9umVnSkyzmYY5DbasmmktxP8ndFbj5pBChrtL0NJmYPvEz4RVoiam+T2CQ60gbRs/7m1sLLsXrkBhKfVibItQdl7tab3OxW94qjeh6uFTif+yybiIC8iIeUp/tO35Sdwt71ZEy4oqayjcG8bi0k0U1AhxLoC9mVBmB9DA== 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=9VIbGHStO1V5IvfuR26Em7KiNBBEYP0ry5eKgsGcUnc=; b=B5ERP+xJi6RYR12BxHdlr19ZnYOMqGz3B41/KvY0XsAddBZS/nwy6arX68OB5qP9ZXss1AX3EHHDRQzGMx5YtxSeicf4ISxjEohBvNAcHCmsKyXTkGzeKmq2pfptRi71CI3DlI2r2/Il2/m4mvyXmQD/0OoSnl2J54ll0tHb81ARlRPilg2MNXTPNAsiYOpISfkK9qTczSLWFMy2ya9ghMWBf6SIH+Oa9aaRXJ++qMoOwQChQlfXXnVWPvPQQCdOxY2KP0djn5jYanYpPDrWDzAOXEBME1OIYGruvcy4w7aG/DBP6MFiiH+Gmpo23Q8rMQw8lzfxLttv31EVzs2vFg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9VIbGHStO1V5IvfuR26Em7KiNBBEYP0ry5eKgsGcUnc=; b=woUc7aVobEqANYCNDFlgf1cjdLt294h9hh4/xPRI4we1j7dUgvH3Tsk9jF/rlGoX8MudcfQM518NKxi9mxnJOmUAR2nJPZk2Tidcji1kTcwG1EimdI7wqCnmhDVD7Qs9k7g/vVOsmVYBP36Vx3CZTw/d7Tjy4bCg/fjwRWGNS/o= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (20.178.23.205) by AM0PR08MB4371.eurprd08.prod.outlook.com (20.179.34.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.21; Tue, 25 Feb 2020 10:01:06 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::2159:870b:25df:e612]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::2159:870b:25df:e612%5]) with mapi id 15.20.2750.021; Tue, 25 Feb 2020 10:01:06 +0000 From: Hannes Tschofenig To: "ace@ietf.org" Thread-Topic: draft-ietf-ace-mqtt-tls-profile-03 Thread-Index: AdXrwPKVlOWry/rCSraJ6rVcwUtPZQ== Date: Tue, 25 Feb 2020 10:01:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 5ef7cd5e-e814-43da-866e-ac80f25d1d99.0 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [156.67.195.207] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 2695259d-100a-43e9-31b6-08d7b9d9a531 X-MS-TrafficTypeDiagnostic: AM0PR08MB4371:|VI1PR08MB5453: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:5516;OLM:9508; x-forefront-prvs: 0324C2C0E2 X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(346002)(366004)(136003)(376002)(39860400002)(396003)(189003)(199004)(8676002)(6916009)(9686003)(316002)(55016002)(186003)(6506007)(5660300002)(26005)(8936002)(71200400001)(64756008)(81156014)(66446008)(76116006)(4744005)(52536014)(2906002)(66946007)(478600001)(33656002)(7696005)(86362001)(81166006)(66476007)(66556008); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR08MB4371; H:AM0PR08MB3716.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 48ebBdhRmaZQenEb1nQPzT2dIcxUUOvXJSxY5tcHQPrXyphyShHqH5o0bCApJip2whJ454NSEKFvLABO/EmkmJU3/WENk7LA/zeiSPHmc7o2lVY7MDoGOSsTn6sQla5ZfoRP1ludUj0qq1kpXtGKaVuk/3yAem0HCm+vkId0zoWZuiuEodCJgmy/iAPqFyFIao14Nhu/+iD5RCHo8v/eLHnoHyzyBJOXhz5XRIqGHdVRi5teeIq5Zj8Wz51iM1QDS91PykbElYExBVVPowyK+G0SBoaMgdce3pCR2mHcQNr8Uf2saduvE96EjC1SFnfLZkwI3pqHbdW/cmtUiLPx/NGrehYF4VKNXmNgW/NWDJ1pg9Jq5K74Z6zXWztnDf8GE7zFjAKjvHC2ofzvcdliF/DXKQfEcIecoGOn84o7XxqLdtGHsn2ErxJBhL4UB1ss x-ms-exchange-antispam-messagedata: HhBnEL/qv3AojzRYboODYGwfAEnyUT05h/K6YpJczB3wQDa8rHLC3LWCFfCTQMnw1h10QNuLRGEiAy9eA8tJNVwJfNF3u1ybVuYNnwquZDNBvULJe2tjvA0cGlFZqX2d8uIQUmsR/nmZB9EMGJz29w== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4371 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT041.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; IPV:CAL; SCL:-1; CTRY:IE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(396003)(376002)(136003)(39860400002)(346002)(189003)(199004)(6506007)(9686003)(36906005)(33656002)(186003)(26005)(316002)(55016002)(70206006)(356004)(4744005)(5660300002)(52536014)(81156014)(86362001)(6916009)(7696005)(2906002)(81166006)(8676002)(8936002)(70586007)(26826003)(478600001)(336012); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR08MB5453; H:64aa7808-outbound-1.mta.getcheckrecipient.com; FPR:; SPF:Pass; LANG:en; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; MX:1; A:1; X-MS-Office365-Filtering-Correlation-Id-Prvs: bba51566-ea5b-4c89-cbc9-08d7b9d9a184 X-Forefront-PRVS: 0324C2C0E2 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 3Ri1QPgmxC4L2ZtYWXakffHG+O8uOXbYCB0kQ442LwRP9WUtIKsa4ZF+zpRp7ZNcqdzouyYUQv33PmljP3R/2ez3cl1o0V9Orn/pKzNafal8RUlPrOiOx5+fgvuL6zqkG1kb70X0W3T9FxhXPklgACaxStWp49Qe4C3mEiqaeE/uV3eUDE75iQHL4gAKzDoza8cn6vZSfo9bnpGUrXHZeqJICjyiby26v/Wm4XQuvUuCJ4nRUC+2+M9fJcRO5N4i8ApX0c48l39YwLPECb1cFQ5cjLMMkVdkLbgtkfsjSF4c8Optd+Y3YyRudpFF22Fstviz4sXpuuCETbWTG2se64YAWFc5Jrx/8EndF2yHhXedXyaxESCtJ7GCuHuC7vbtLBDHuW+4TgAVMzQBfqIREUiLCWSRzky0wknUVd+neNfyEPOr1P1enXETW7r33GSe X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Feb 2020 10:01:12.6140 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2695259d-100a-43e9-31b6-08d7b9d9a531 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB5453 Archived-At: Subject: [Ace] draft-ietf-ace-mqtt-tls-profile-03 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, 25 Feb 2020 10:01:22 -0000 Hi Cigdem, Hi Anthony, Hi Paul, Why are you using the term MQTT broker? My understanding of the MQTT spec i= s that there are only clients and servers - nothing more. Is a MQTT v3.1.1 client able to talk to a MQTT v5 server? Would a MQTT v3.1= .1 client talk to a MQTT v5 client via a server that supports both v3.1.1 a= nd v5? Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Tue Feb 25 02:56:53 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 E83C63A0965; Tue, 25 Feb 2020 02:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, 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 keKZ0cFgdtqU; Tue, 25 Feb 2020 02:56:48 -0800 (PST) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on20609.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e1a::609]) (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 74B0C3A0964; Tue, 25 Feb 2020 02:56:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kBHxP4obbtOuRE4D10nFeOdlCjaA1AnI+qKnx8qhZMGq9m6AOKYZXNjWNjbXF8oRXC5rCjdJ3fOWq2pGEq9qpNjeSA4qOF2v/3lazg/pS4EekgoFHHg5GenWuXylZEmlB30QHhBTsX1U3kN6AWAdLF701oql2nPHdSUwLWv02mYdLZq7aLmdeChMZdS9LZBRQnkCOtcacucp6/Z9YApngYUzhGv9azK6cD3H6lu5RbSeHACSVq/i3ZzhtS3LtZo31OGn3JzO2Ryqu5qkyY3F20HiRlsTukNRvqm1E1s91OYfJExSsVLIuX3JrVBVnahcDOCcsWyFlcalkjVaoCLeJw== 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=jnOng9hvSm3u4opKVGR/Uf3q396sfgKjoz47x7UqXT8=; b=gpeTu+fWo3BIHUFbfJsQPeWjwFdAotvsqX5LWT6yRE/sZq4vPiR+kI9Pveegi6hJuWZj4PtaNiiAKlVr/g+zfqWJP/CkN8U15WhYTy/S2vRLtZfEzGeItNQbULe2fS/2eMdfnTCrV6zKnTYsGpiJjHSvrF6P3uGci4MuizzDdk2DpukWlyhj2PdKzcJd7/EfNhm9maUnrRhzQQVyLEHVWclPlYTQErXiF1V4YQzjOEr39PYt4vp3472z3JwWC1nPuAnM6QsL+3Oh6md4S7/CXr3WEe7qj0SjGany2TWH4cIm3ABDL8Cj90/wYbmKJYmhGMDgoDVhhGSvgqVgfuZwow== 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=jnOng9hvSm3u4opKVGR/Uf3q396sfgKjoz47x7UqXT8=; b=f0yx7AKY1QiaTujTE+djLroO6al6wuxt3ENFjpYax/dIIzDH3cpI0TLRvvMOCAXzTpMjuVHJ1WKMHNeLQB8SZqTuiiS+uOkv6aZue0yub+ro3zHGIzYEfRsqp9Dm/mGUbGTqYtS9RYW2Vg3RSuPlVhe+b+2I9YcA+29pS/GnssE= Received: from AM6PR07MB4053.eurprd07.prod.outlook.com (52.134.117.139) by AM6PR07MB4119.eurprd07.prod.outlook.com (52.134.114.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.10; Tue, 25 Feb 2020 10:56:43 +0000 Received: from AM6PR07MB4053.eurprd07.prod.outlook.com ([fe80::7537:e135:422d:c5a7]) by AM6PR07MB4053.eurprd07.prod.outlook.com ([fe80::7537:e135:422d:c5a7%5]) with mapi id 15.20.2772.012; Tue, 25 Feb 2020 10:56:43 +0000 From: Francesca Palombini To: Benjamin Kaduk CC: Ace Wg , "draft-ietf-ace-oscore-profile@ietf.org" Thread-Topic: [Ace] AD review of draft-ietf-ace-oscore-profile-08 Thread-Index: AQHVxXkvf17L6O/aSkulV21bFzeHXqgB6oAAgAcZCgCAFtegAIAL1EAAgABq7QA= Date: Tue, 25 Feb 2020 10:56:43 +0000 Message-ID: References: <20200107163851.GV57294@kduck.mit.edu> <4086FADE-7993-47F6-9292-FDD7FC5457B4@ericsson.com> <20200203040600.GM91553@kduck.mit.edu> <8B7C0C63-3F8D-478A-907C-E424649FC6C5@ericsson.com> <20200225053400.GF5814@kduck.mit.edu> In-Reply-To: <20200225053400.GF5814@kduck.mit.edu> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4f65c858-2cde-4494-cec9-08d7b9e16655 x-ms-traffictypediagnostic: AM6PR07MB4119: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0324C2C0E2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(346002)(376002)(396003)(136003)(39860400002)(189003)(199004)(2906002)(30864003)(478600001)(76116006)(316002)(91956017)(66556008)(33656002)(54906003)(66574012)(6916009)(6486002)(64756008)(66476007)(44832011)(6512007)(966005)(186003)(53546011)(2616005)(8676002)(66946007)(81166006)(81156014)(36756003)(86362001)(71200400001)(26005)(4326008)(6506007)(8936002)(5660300002)(66446008); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB4119; H:AM6PR07MB4053.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 9Cm3WUQlYIwP7yM4TBQNwTtDpnSf0uYbgvXFYkbuKwOhmh1TQ9IpG4zGnzLvooL6xjdxE/e4/mHQ+EE1iN3zwHczmo6+6eWjzIl5DycrE9h0txT2IspSLpOizQDYtDLco6z+YXCAjsC6A0ION9THgdFId/HoGdZhz+dvdHISNqFA1exFd1Y246Zd7H6MPbzRGrceDQxe4ICZ97cFZ1YbMchpyGQ5Z0VIrOw4yUTtpjKpkHCnOxVh413EanOMm1upb7lD6BzRTI4IrMceJsWBjLygMbmPZf2Vs8Q/zTkA5AyQORZOlzz/v8tkQG1FNAD7XvIikLjRxDXOoKZVgbSkNfF422AmVZ0gFgCOariKAGo3ETkDB87E1Ux08QPZAeR14toHpGb7M7qvHNejmh7CQsceM19s8jthNtq/8hXepZX8+YU9/BzzsbYjVyKGhAVOJUxZVtSRALDOK7I/O3EaShhL0n5wFy0mf6whszzuYRWNa5Kf1RnLH/Uno6Sp1nOO03/1VzAdevvdpkmIreA1VA== x-ms-exchange-antispam-messagedata: iiB1Rvo5ia1N9NhD97kEl+sU+z7ix5xTAtZZSOhVFocGSUDOZc9+lII25QMyp44KB8MWcI//bXDfaAYSZTOoW9QuDqjiuxlHEl+BhgDnPZOp1OsuFK89P6PahIhKAi8kl42rQrhabWNg5KjLgwMfsg== 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: 4f65c858-2cde-4494-cec9-08d7b9e16655 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2020 10:56:43.1274 (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: bOavVJr0K5EM8DcFmZTjH7CaWE9gmoYpfd4k4uaqtz7KP9aH9SAlQuOt4MEWI4RO+K9g6uaX0HNpD+Sjek9pDQM57OuWJY3GMpU+R3CepWyq/SEy3y0A6wB5C73wzKSu X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB4119 Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-oscore-profile-08 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, 25 Feb 2020 10:56:51 -0000 SGkgQmVuLA0KDQpObyB3b3JyaWVzLCBJIHRvb2sgZW5vdWdoIHRpbWUgYW5zd2VyaW5nIHlvdXIg cmV2aWV3LCBvbiB0aGUgY29udHJhcnkgdGhhbmsgeW91IGZvciBtYWtpbmcgaXQgYmVmb3JlIHRo ZSBpbnRlcmltIQ0KSSBzYXcgeW91IGFscmVhZHkgcmV2aWV3ZWQgdGhlIFBSLCBvdGhlcndpc2Ug eW91IGNhbiBzZWUgdGhlIGRpZmYgd2l0aCB0aGUgbGF0ZXN0IHN1Ym1pc3Npb24gbW9yZSBlYXNp bHkgaGVyZTogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDE9aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLWFjZS1vc2NvcmUtcHJvZmlsZS50eHQmdXJsMj1odHRw czovL2FjZS13Zy5naXRodWIuaW8vYWNlLW9zY29yZS1wcm9maWxlL3YtMDkvZHJhZnQtaWV0Zi1h Y2Utb3Njb3JlLXByb2ZpbGUudHh0IA0KSSBoYXZlIHJlcGxpZWQgdG8geW91ciBsYXRlc3QgUFIg Y29tbWVudHMsIHdhaXRpbmcgZm9yIGZpbmFsIE9LIGZvciBtZXJnaW5nIGl0LiBBbHNvIGFuc3dl cmluZyBpbmxpbmUgdG8geW91ciBvcGVuIGNvbW1lbnRzIGJlbG93LCBwcmVmYWNlZCB3aXRoIFtG UF0sIEkgdGhpbmsgd2UgYWdyZWUgb24gYWxsIG5vdy4NCg0KDQogVGhhbmtzIGEgbG90IQ0KRnJh bmNlc2NhDQoNCg0K77u/T24gMjUvMDIvMjAyMCwgMDY6MzQsICJCZW5qYW1pbiBLYWR1ayIgPGth ZHVrQG1pdC5lZHU+IHdyb3RlOg0KDQogICAgSGkgRnJhbmNlc2NhLA0KICAgIA0KICAgIFNvcnJ5 IHRvIGN1dCB0aGlzIHNvIGNsb3NlIHRvIHRoZSB3aXJlLi4uSSB3YXMgb24gdmFjYXRpb24gYW5k IGNhbWUgYmFjayB0bw0KICAgIGEgc2l6ZWFibGUgaW5ib3guDQogICAgDQogICAgT24gTW9uLCBG ZWIgMTcsIDIwMjAgYXQgMDM6NTU6MjlQTSArMDAwMCwgRnJhbmNlc2NhIFBhbG9tYmluaSB3cm90 ZToNCiAgICA+IEhpIEJlbiwNCiAgICA+IA0KICAgID4gSSBhbSBub3cgZG9uZSB3aXRoIHVwZGF0 aW5nIHRoZSBkcmFmdCBmb2xsb3dpbmcgbW9zdCBvZiB5b3VyIHJldmlldyBjb21tZW50cy4gT3V0 IG9mIHRoZSAxMDUsIEkgaGF2ZSBpbXBsZW1lbnRlZCA4OCBpbiB0aGUgZHJhZnQsIHdoaWxlIHRo b3NlIGxlZnQgbmVlZCBhZ3JlZW1lbnQgaW4gdGhlIHdnIGFzIHByZXZpb3VzbHkgbWVudGlvbmVk LCBvciByZXF1aXJlIHlvdXIgT0sgKHNlZSBpbmxpbmUpLg0KICAgID4gDQogICAgPiBZb3UgY2Fu IHNlZSB0aGUgcmVzdWx0IG9mIHRoZSB1cGRhdGUgaW4gdGhlIFBSIGhlcmU6IGh0dHBzOi8vZ2l0 aHViLmNvbS9hY2Utd2cvYWNlLW9zY29yZS1wcm9maWxlL3B1bGwvMjUgSWYgeW91IGdpdmUgbWUg dGhlIGdvLWFoZWFkLCBJIHdpbGwgbWVyZ2UgdGhpcyBQUiBhbmQgc3VibWl0IGEgbmV3IHZlcnNp b24sIGFuZCB0aGVuIHdlIGNhbiBjb250aW51ZSB3b3JraW5nIG9uIHRoZSBvcGVuIGlzc3Vlcy4N CiAgICANCiAgICBJIHdpbGwgaGF2ZSB0byBkb3dubG9hZCB0aGUgY2hhbmdlcyBsb2NhbGx5IHRv IHZpZXcgdGhlbSwgYXMgdGhlIGluLWJyb3dzZXINCiAgICB2aWV3ZXIgZG9lcyBub3QgZG8gd2Vs bCB3aXRoIHRoZSBsb25nIGxpbmVzLg0KDQpbRlBdIFNvcnJ5IGFib3V0IHRoYXQsIHNob3VsZCBo YXZlIHNwbGl0IHRoZSBsaW5lcyBiZXR0ZXIuDQogICAgDQogICAgPiBUaGVzZSBvcGVuIGlzc3Vl cyBhcmU6DQogICAgPiANCiAgICA+ICogVGhlIG1lY2hhbmlzbSBvZiBsZXR0aW5nIHRoZSBSUyBw aWNrIHRoZSBpZGVudGlmaWVyIG9mIHRoZSBjbGllbnQgaXMgbm90IHdvcnRoIHRoZSBhZGRpdGlv bmFsIGNvbXBsZXhpdHkuDQogICAgPiAJNiwgNywgMzIsIDYxLCA2NSwNCiAgICA+ICogUmVjb21t ZW5kYXRpb24gYWJvdXQgbGVuZ3RoIG9mIG5vbmNlcyBOMSBhbmQgTjIgdG8gdXNlLg0KICAgID4g CTUsIDUyDQogICAgPiAqIERlZmluZSBhbmQgcmVnaXN0ZXIgMiBuZXcgQUNFIHBhcmFtZXRlcnMg dG8gdHJhbnNwb3J0IHRoZSBub25jZXMgdXNlZCBpbiB0aGUgZXhjaGFuZ2UsIGluc3RlYWQgb2Yg dXNpbmcgImNub25jZSIuDQogICAgPiAJMywgIDUzLCA2MA0KICAgID4gKiBDaGVjayB3aXRoIElB TkENCiAgICA+IAkxMDINCiAgICA+IA0KICAgID4gSSBob3BlIHRvIGRpc2N1c3MgdGhlc2UgaW4g dGhlIG1haWxpbmcgbGlzdCAoY29udGludWluZyBvbiB0aGUgc2VwYXJhdGUgdGhyZWFkKSwgYW5k IGF0IHRoZSBpbnRlcmltLiANCiAgICA+IA0KICAgID4gSSB3aWxsIGN1dCBhbmQgcGFzdGUgdGhl IHJlc3QgKDQ2ICwgNDcsICA1OCAsIDY3ICwgOTIgKyBhIGNvdXBsZSBvZiBtb3JlKSB3aGljaCBJ IGhhdmUgYW5zd2VyZWQgYmVsb3csIHdoYXRldmVyIGlzIG5vdCByZXBvcnRlZCBiZWxvdyBJIGZv dW5kIG5vIGlzc3VlIGluIGRvaW5nIHRoZSBtb2RpZmljYXRpb25zIHlvdSBzdWdnZXN0ZWQsIG9y IGlzIGNvdmVyZWQgYnkgdGhlIG9wZW4gcG9pbnRzIEkgbWVudGlvbmVkLiBQbGVhc2UgZG8gYnJp bmcgYW55IG9mIHRob3NlIEkgZG8gbm90IHRvdWNoIG9uIHVwIGFnYWluIGlmIHlvdSBmZWVsIHRo ZXkgd2VyZSBub3Qgc29sdmVkIGluIHRoZSBQUi4NCiAgICA+IA0KICAgID4gVGhhbmtzIGFnYWlu IGZvciB5b3VyIGV4dGVuc2l2ZSByZXZpZXchDQogICAgPiBGcmFuY2VzY2ENCiAgICA+IA0KICAg ID4gT24gMDMvMDIvMjAyMCwgMDU6MDYsICJCZW5qYW1pbiBLYWR1ayIgPGthZHVrQG1pdC5lZHU+ IHdyb3RlOg0KICAgID4gICAgID4gMjkuICAgICAgIFRoZSBBUyBNVVNUIGFsc28gYXNzaWduIGFu IGlkZW50aWZpZXIgdG8gdGhlIFJTIChzZXJ2ZXJJZCksIE1BWQ0KICAgID4gICAgID4gICAgICAg IGFzc2lnbiBhbiBpZGVudGlmaWVyIHRvIHRoZSBjbGllbnQgKGNsaWVudElkKSwgYW5kIE1BWSBh c3NpZ24gYW4NCiAgICA+ICAgICA+ICAgICAgICBpZGVudGlmaWVyIHRvIHRoZSBjb250ZXh0IChj b250ZXh0SWQpLiAgVGhlc2UgaWRlbnRpZmllcnMgYXJlIHRoZW4NCiAgICA+ICAgICA+ICAgICAg ICB1c2VkIGFzIFNlbmRlciBJRCwgUmVjaXBpZW50IElEIGFuZCBJRCBDb250ZXh0IGluIHRoZSBP U0NPUkUgY29udGV4dA0KICAgID4gICAgID4gICAgICAgIGFzIGRlc2NyaWJlZCBpbiBzZWN0aW9u IDMuMSBvZiBbSS1ELmlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHldLiAgVGhlDQogICAgPiAgICAg PiAgICAgICAgY291cGxlIChjbGllbnQgaWRlbnRpZmllciwgY29udGV4dCBpZGVudGlmaWVyKSBN VVNUIGJlIHVuaXF1ZSBpbiB0aGUNCiAgICA+ICAgICA+ICAgICAgICBzZXQgb2YgYWxsIGNsaWVu dHMgb24gYSBzaW5nbGUgUlMuICBNb3Jlb3Zlciwgd2hlbiBhc3NpZ25lZCwNCiAgICA+ICAgICA+ ICAgICAgICBzZXJ2ZXJJZCwgY2xpZW50SWQgYW5kIGNvbnRleHRJZCBNVVNUIGJlIGluY2x1ZGVk IGluIHRoZQ0KICAgID4gICAgID4gICAgICAgIE9TQ09SRV9TZWN1cml0eV9Db250ZXh0LCBhcyBk ZWZpbmVkIGluIFNlY3Rpb24gMy4yLjEuDQogICAgPiAgICAgPiAgICAgDQogICAgPiAgICAgPiAg ICAgV2hlbiBjZXJ0YWluIGZpZWxkcyBhcmUgb3B0aW9uYWwsIHdlIHR5cGljYWxseSBoYXZlIHRv IGFzayB3aGV0aGVyIGl0J3MNCiAgICA+ICAgICA+ICAgICBwb3NzaWJsZSBmb3IgdGhlIHR3byBw YXJ0aWVzIHRvIGRpc2FncmVlIGFib3V0IHdoZXRoZXIgdGhlIGZpZWxkIGlzDQogICAgPiAgICAg PiAgICAgcHJlc2VudC4gIElJVUMsIHRoZSBPU0NPUkUgY29udGV4dCBkZXJpdmF0aW9uIHByb2Nl ZHVyZSBpbmNsdWRlcyBlbm91Z2gNCiAgICA+ICAgICA+ICAgICBpbmZvcm1hdGlvbiB0byBwcmV2 ZW50IHRoYXQgcG9zc2liaWxpdHksIGJ1dCBpdCB3b3VsZCBiZSBnb29kIGlmIHNvbWVvbmUNCiAg ICA+ICAgICA+ICAgICB3b3VsZCBjb25maXJtIHRoYXQuDQogICAgPiAgICAgPiANCiAgICA+ICAg ICA+IEZQOiBUaGF0IGlzIGNvcnJlY3QsIGEgbnVtYmVyIG9mIGZpZWxkcyBoYXZlIGRlZmF1bHQg dmFsdWVzIHdoZW4gbm9uIHByZXNlbnQuIEhrZGYsIGFsZywgc2FsdCwgY29udGV4dElkLCBycGwu IE9uIHRoZSBvdGhlciBoYW5kLCBtcywgY2xpZW50SWQgYW5kIHNlcnZlcklkIG5lZWQgdG8gYmUg c2V0Lg0KICAgID4gICAgIA0KICAgID4gICAgIEhtbSwgc28gdGhlcmUgaXMgbm90IGEgZ3JlYXQg bWVjaGFuaXNtIHRvIGRpc3Rpbmd1aXNoICJhYnNlbnQiIGZyb20NCiAgICA+ICAgICAicHJlc2Vu dCB3aXRoIGRlZmF1bHQgdmFsdWUiLCBidXQgdGhlIHByYWN0aWNhbCBjb25zZXF1ZW5jZXMgb2Yg c3VjaCBhbg0KICAgID4gICAgIGF0dGFjayBzZWVtIHF1aXRlIGxpbWl0ZWQuDQogICAgPiANCiAg ICA+IEZQOiBUaGF0IGlzIHJpZ2h0LiBJIGRpZCBub3QgYWRkIGFueSB0ZXh0IGFib3V0IHRoaXMs IGFzIHRoaXMgaXMgbW9yZSBPU0NPUkUgaW1wbGljYXRpb24uDQogICAgDQogICAgVGhhdCdzIG9r YXkuDQogICAgDQogICAgPiAgICAgPiAgICAgDQogICAgPiAgICAgPiAzNC4gICAgICAgICAgICAg ImFjY2Vzc190b2tlbiIgOiBoJ2E1MDM3Njc0NjU2ZDcwNTM2NTZlNzMgLi4uJw0KICAgID4gICAg ID4gICAgICAgICAgICAgICAocmVtYWluZGVyIG9mIGFjY2VzcyB0b2tlbiBvbWl0dGVkIGZvciBi cmV2aXR5KScsDQogICAgPiAgICAgPiAgICAgDQogICAgPiAgICAgPiAgICAgSW4gYWRkaXRpb24g dG8gdGhlIGludmFsaWQtQ0JPUi1kaWFnbm9zdGljLW5vdGF0aW9uLXN5bnRheCBjb21tZW50LCB3 ZQ0KICAgID4gICAgID4gICAgIGFsc28gaGF2ZSB1bmJhbGFuY2VkIHF1b3Rlcy4NCiAgICA+ICAg ICA+IA0KICAgID4gICAgID4gRlA6IFJpZ2h0LCBidXQgdGhpcyBpcyBub3QgdmFsaWQgQ0JPUiBk aWFnbm9zdGljIG5vdGF0aW9uIHN5bnRheCBhbnl3YXksIGRvIHlvdSBoYXZlIGEgYmV0dGVyIGlk ZWE/IEkgZG8gbm90IHRoaW5rIGl0IHdvdWxkIGJlIHVzZWZ1bCB0byBoYXZlIHRoZSBmdWxsIHRv a2VuIGhlcmUuIFdpbGwgcmVtb3ZlIHRoZSB1bmJhbGFuY2VkIHF1b3RlLg0KICAgID4gICAgIA0K ICAgID4gICAgIFRoaXMgaXMgcHJvYmFibHkgbWFuYWdlYWJsZSwgdGhvdWdoIHdlIGRvIG9mdGVu IHNlZSBwZW9wbGUgcHV0IGEgZGlzY2xhaW1lcg0KICAgID4gICAgIGJlZm9yZSB0aGUgZXhhbXBs ZSB0aGF0IDxjZXJ0YWluIGZpZWxkcz4gYXJlIHRydW5jYXRlZCBmb3IgcmVhZGFiaWxpdHk7DQog ICAgPiAgICAgc29tZSBvdGhlciBBRHMgbWF5IGhhdmUgb3RoZXIgc3VnZ2VzdGlvbnMsIHRvby4N CiAgICA+IA0KICAgID4gRlA6IFRoYW5rcyBmb3IgdGhlIGlucHV0IHRleHQgOikgTm93IGFkZGVk Lg0KICAgID4gDQogICAgPiAgICAgLi4uDQogICAgPiANCiAgICA+ICAgICA+IDQzLiAgICAgICBo a2RmOiAgVGhpcyBwYXJhbWV0ZXIgaWRlbnRpZmllcyB0aGUgT1NDT1JFIEhLREYgQWxnb3JpdGht LiAgRm9yIG1vcmUNCiAgICA+ICAgICA+ICAgICAgICAgICBpbmZvcm1hdGlvbiBhYm91dCB0aGlz IGZpZWxkLCBzZWUgc2VjdGlvbiAzLjEgb2YNCiAgICA+ICAgICA+ICAgICAgICAgICBbSS1ELmll dGYtY29yZS1vYmplY3Qtc2VjdXJpdHldLiAgVGhlIHZhbHVlcyB1c2VkIE1VU1QgYmUNCiAgICA+ ICAgICA+ICAgICAgICAgICByZWdpc3RlcmVkIGluIHRoZSBJQU5BICJDT1NFIEFsZ29yaXRobXMi IHJlZ2lzdHJ5IGFuZCBNVVNUIGJlDQogICAgPiAgICAgPiAgICAgICAgICAgSE1BQy1iYXNlZCBI S0RGIGFsZ29yaXRobXMuICBUaGUgdmFsdWUgY2FuIGVpdGhlciBiZSB0aGUgaW50ZWdlcg0KICAg ID4gICAgID4gICAgIA0KICAgID4gICAgID4gICAgIEl0J3MgYSBsaXR0bGUgdW5mb3J0dW5hdGUg dGhhdCB3ZSBiYXNpY2FsbHkgYXJlIHJlbHlpbmcgb24gIkkga25vdyBpdA0KICAgID4gICAgID4g ICAgIHdoZW4gSSBzZWUgaXQiIGZvciBkZXRlcm1pbmluZyB3aGljaCBhbGdvcml0aG1zIGFyZSBI S0RGIGFsZ29yaXRobXMuDQogICAgPiAgICAgPiANCiAgICA+ICAgICA+IEZQOiBBZ3JlZWQsIGJ1 dCB3ZSBkb27igJl0IHJlYWxseSBoYXZlIGFub3RoZXIgd2F5IHRvIHNheSB0aGlzLiBJZiB5b3Ug b3IgQ09TRSBleHBlcnRzIChKaW0pIGhhdmUgYW55IGlkZWEgcGxlYXNlIGxldCB1cyBrbm93LiAg ICANCiAgICA+ICAgICANCiAgICA+ICAgICBJIHRoaW5rIHdlIGluaGVyaXRlZCB0aGlzIGZyb20g Sk9TRSA6LS8NCiAgICA+IA0KICAgID4gRlA6IFRoYXQgd291bGQgbWFrZSBzZW5zZS4gSSBoYXZl IG5vdCBkb25lIGFueSBtb2RpZmljYXRpb25zIGhlcmUsIHN0aWxsIHdhaXRpbmcgZm9yIG1vcmUg aW5wdXQgaWYgYW55Lg0KICAgIA0KICAgIEkgZG9uJ3Qga25vdyBvZiBhbnkgbW9kaWZpY2F0aW9u cyB0aGF0IHdvdWxkIGhlbHAuDQogICAgDQogICAgPiAgICAgPiAgICAgQWxzbywgIkhLREYiIGV4 cGFuZHMgdG8gIkhNQUMtYmFzZWQgRXh0cmFjdC1hbmQtRXhwYW5kIEtleSBEZXJpdmF0aW9uDQog ICAgPiAgICAgPiAgICAgRnVuY3Rpb24iLCBpLmUuLCBpcyBkZWZpbml0aW9uYWxseSBITUFDLWJh c2VkLiAgU28gdGhpcyBzaG91bGQgYmUNCiAgICA+ICAgICA+ICAgICByZXdvcmRlZCB0byByZWZs ZWN0IHRoZSBhY3R1YWwgaW50ZW50Lg0KICAgID4gICAgID4gDQogICAgPiAgICAgPiBGUDogUmln aHQsIHRoYXQgaXMgYmVjYXVzZSBDT1NFIGFsc28gZGVmaW5lcyBIS0RGIHVzaW5nIEFFUy1NQUMs IHNlZSBUYWJsZSAxMiBvZiBSRkM4MTUyLCBzbyB3ZSBuZWVkZWQgdG8gc3BlY2lmeSB0aGF0IG9u bHkgSE1BQy1iYXNlZCBjYW4gYmUgdXNlZC4NCiAgICA+ICAgICANCiAgICA+ICAgICBPb2YsIHJh dGhlciB1bmZvcnR1bmF0ZSBJTU8gdGhhdCB0aGUgdGVybWlub2xvZ3kgd2FzIG92ZXJsb2FkZWQg YnkgUkZDDQogICAgPiAgICAgODE1Mi4NCiAgICA+IA0KICAgID4gRlA6IEFncmVlZC4gQWdhaW4g bm8gbW9kaWZpY2F0aW9ucyBmb2xsb3dpbmcgdGhpcyBwb2ludCAob3IgdGhlIGFuYWxvZ291cyA0 NC4gQWJvdXQgQUVBRCBhbGcpLg0KICAgIA0KICAgIE9rYXkuDQogICAgDQogICAgPiAgICAgPiA0 Ni4gICAgICAgcnBsOiAgVGhpcyBwYXJhbWV0ZXIgaXMgdXNlZCB0byBjYXJyeSB0aGUgT1NDT1JF IHZhbHVlLCBlbmNvZGVkIGFzIGENCiAgICA+ICAgICA+ICAgICAgICAgICBic3RyLiAgVGhpcyBw YXJhbWV0ZXIgaWRlbnRpZmllcyB0aGUgT1NDT1JFIFJlcGxheSBXaW5kb3cgU2l6ZSBhbmQNCiAg ICA+ICAgICA+ICAgICAgICAgICBUeXBlIHZhbHVlLCB3aGljaCBpcyBhIGJ5dGUgc3RyaW5nLiAg Rm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQNCiAgICA+ICAgICA+ICAgICAgICAgICB0aGlzIGZp ZWxkLCBzZWUgc2VjdGlvbiAzLjEgb2YgW0ktRC5pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5XS4N CiAgICA+ICAgICA+ICAgICAgICAgICBJbiBKU09OLCB0aGUgInJwbCIgdmFsdWUgaXMgYSBCYXNl NjQgZW5jb2RlZCBieXRlIHN0cmluZy4gIEluDQogICAgPiAgICAgPiAgICAgICAgICAgQ0JPUiwg dGhlICJycGwiIHR5cGUgaXMgYnN0ciwgYW5kIGhhcyBsYWJlbCA4Lg0KICAgID4gICAgID4gICAg IA0KICAgID4gICAgID4gICAgIEkgdHJpZWQgdG8gZm9sbG93IHRoZSByZWZlcmVuY2UsIGJ1dCBJ IGNvdWxkbid0IHJlYWxseSBmaW5kIGENCiAgICA+ICAgICA+ICAgICBkZXNjcmlwdGlvbiBvZiB0 aGUgZW5jb2RpbmcgZm9yIHRoaXMgYXMgYSBieXRlIHN0cmluZyAoZXNwZWNpYWxseQ0KICAgID4g ICAgID4gICAgIG5vdGV3b3J0aHkgc2luY2Ugd2UgY2xhaW0gdGhhdCBpdCByZXByZXNlbnRzIGJv dGggc2l6ZSBhbmQgdHlwZSkuDQogICAgPiAgICAgPiAgICAgKFJlbGF0ZWRseSwgSSdtIG5vdCBz dXJlIHdoeSBpdCdzIGFsbG93ZWQgdG8gYmUgZWl0aGVyIGJzdHIgb3IgaW50LikNCiAgICA+ICAg ICA+ICAgICANCiAgICA+ICAgICA+IEZQOiBSaWdodCwgdGhpcyBpcyBhbiBvbGQgcmVmZXJlbmNl LCB3aGVyZSB3ZSBhY3R1YWxseSBnYXZlIGEgZGVmYXVsdCBlbmNvZGluZyBmb3IgcnBsLCBJIGJl bGlldmUuIE5vdyB0aGlzIGlzIGVudGlyZWx5IHVwIHRvIHRoZSBhcHBsaWNhdGlvbi4gSSB3b3Vs ZCBrZWVwIHRoaXMgYXMgYnN0ciBhbmQgc3BlY2lmeSB0aGF0IGl0IGlzIGFueSBmb3JtYXQgd3Jh cHBlZCBpbiBhIGJzdHIuDQogICAgPiAgICAgDQogICAgPiAgICAgIlVwIHRvIHRoZSBhcHBsaWNh dGlvbiIgbWVhbmluZyBrbm93biBieSBwcmlvciBhZ3JlZW1lbnQgYW1vbmcgYWxsIHRocmVlIG9m DQogICAgPiAgICAgQywgQVMsIGFuZCBSUz8NCiAgICA+ICAgICANCiAgICA+IEZQOiBUaGVyZSBp cyBubyBuZWVkIGZvciB0aGUgMyBub2RlcyB0byBiZSBpbiBhZ3JlZW1lbnQgb24gdGhlIHJlcGxh eSB3aW5kb3cgb24gdGhlIFJTLiBBZnRlciB0aGlua2luZyBhIGJpdCBtb3JlIGFib3V0IHRoaXMs IEkgdGhpbmsgSSdkIGxpa2UgdG8gcmVtb3ZlIHRoaXMgcGFyYW1ldGVyIGNvbXBsZXRlbHkgZnJv bSB0aGlzIG9iamVjdC4gVGhlIGlkZWEgaGVyZSB3YXMgdGhhdCB0aGUgQVMgaXMgYWJsZSB0byB0 ZWxsIHRoZSBSUyB3aGF0IHR5cGUgYW5kIHNpemUgb2YgcmVwbGF5IHdpbmRvdyB0byB1c2UsIGJ1 dCBJIGRvIG5vdCBzZWUgYSByZWFzb24gd2h5IHRoZSBBUyBzaG91bGQgc2VuZCB0aGlzIGluZm8g dG8gdGhlIFJTLiBXaW5kb3cgdHlwZSBhbmQgc2l6ZSBpcyBpbXBsZW1lbnRhdGlvbiByZWxhdGVk LCBhbmQgZWFjaCBSUyBub2RlIGNhbiBoYXZlIGl0cyBvd24uIA0KICAgIA0KICAgIEl0J3Mgbm90 IGV2ZW4ganVzdCB0aGUgQVMgc2VuZGluZyB0aGlzIHRvIHRoZSBSUywgdGhvdWdoLCByaWdodD8g IFRoaXMNCiAgICBzZWN0aW9uIGlzIGZvciB0aGUgdG9rZW4gcmVzcG9uc2UgZnJvbSBBUyB0byBD LCBhbmQgdGhlDQogICAgT1NDT1JFX1NlY3VyaXR5X0NvbnRleHQgb2JqZWN0IGlzIGZvciBjbGVh cnRleHQgaW5mb3JtYXRpb24gdGhhdCB0aGUgQVMNCiAgICBnaXZlcyB0byB0aGUgQyBhbG9uZ3Np ZGUgdGhlIHRva2VuLiAgKEl0IG1pZ2h0IGFsc28gYmUgcmVwcmVzZW50ZWQgaW4gdGhlDQogICAg dG9rZW4gYXMgd2VsbCwgYnV0IHRoaXMgaXMgd2hlcmUgdGhlIHRleHQgaW4gcXVlc3Rpb24gb2Nj dXJzLikgIEkgbWF5IGJlDQogICAgZm9yZ2V0dGluZyBzb21ldGhpbmcsIGJ1dCB0aGUgcmVwbGF5 IHdpbmRvd3Mgc291bmRzIGxpa2UgaXQgY291bGQganVzdCBiZQ0KICAgIGVudGlyZWx5IGxvY2Fs IHRvIHRoZSBSUyAoYW5kIG5vdCBzb21ldGhpbmcgdGhlIGNsaWVudCBuZWVkcyB0byBrbm93IHRo ZQ0KICAgIGltcGxlbWVudGF0aW9uIG9mKSwgc28gcmVtb3ZpbmcgdGhpcyBwYXJhbWV0ZXIgc2Vl bXMgdG8gbWFrZSBzZW5zZS4gIChBbmQNCiAgICBhZnRlciBhbGwsIHdlIGhhdmUgYSByZWdpc3Ry eSBub3cgZm9yIHRoZSBPU0NPUkVfU2VjdXJpdHlfQ29udGV4dCBjb250ZW50cywNCiAgICBzbyB3 ZSBjb3VsZCBhbGxvY2F0ZSB0aGUgY29kZXBvaW50IGxhdGVyIGlmIG5lZWRlZC4pDQoNCltGUF0g WWVzLCBpdCBpcyBwYXJ0IG9mIHRoZSBhY2Nlc3MgdG9rZW4gYXMgd2VsbCwgd2hpY2ggaXMgd2h5 IEkgdGFsayBhYm91dCBBUyB0byBSUy4gWWVzLCB0aGUgY2xpZW50IHdvdWxkIG5vdCBjYXJlIGFi b3V0IHRoaXMgcGFyYW1ldGVyIGF0IGFsbC4gSSB3ZW50IGFoZWFkIGFuZCByZW1vdmVkIGl0Lg0K ICAgIA0KICAgID4gICAgID4gQWxzbyBJIG5lZWQgdG8gZml4IGEgY291cGxlIG9mIG1pc3Rha2Vz OiDigJxPU0NPUkUgdmFsdWXigJ0gaXMgd3Jvbmc7IOKAnFJlcGxheSBXaW5kb3figJ0gYW5kIG5v dCAiU2l6ZSBhbmQgVHlwZSIuIEFsc28sIEkgdGhpbmsgd2UgbmVlZCB0byBkZWZpbmUgYSBuZXcg SUFOQSByZWdpc3RyeSBmb3IgcnBsIHdpdGggMCBhcyBkZWZhdWx0LCBzbyB0aGF0IGFwcGxpY2F0 aW9ucyBjYW4gZGVmaW5lIHRoZWlyIGZvcm1hdC4NCiAgICA+ICAgICANCiAgICA+ICAgICBJJ20g bm90IGVudGlyZWx5IHN1cmUgSSB1bmRlcnN0YW5kIHRoYXQgdGhlIHJlZ2lzdHJ5IGlzIGZvciAo aS5lLiwgd2hhdCB5b3UNCiAgICA+ICAgICBwcm9wb3NlKS4NCiAgICA+IA0KICAgID4gRlA6IGRp c3JlZ2FyZCB0aGF0LiBJIHdhcyB0aGlua2luZyB3ZSBtaWdodCB3YW50IHRvIGhhdmUgYSByZWdp c3RyeSBmb3IgZGlmZmVyZW50IHR5cGVzIG9mIHJlcGxheSB3aW5kb3dzLCBidXQgY29uc2lkZXJp bmcgdGhlIGNvbW1lbnQgYWJvdmUgSSBkbyBub3QgdGhpbmsgaXQncyBuZWVkZWQgYW55bW9yZS4N CiAgICA+ICAgICANCiAgICA+ICAgICA+ICAgICBTZWN0aW9uIDQNCiAgICA+ICAgICA+ICAgICAN CiAgICA+ICAgICA+IDQ3LiAgICBDYW4gd2UgZ2V0IHNvbWUgQ0RETCBvciBzaW1pbGFyIGZvciBi b3RoIEMtdG8tUlMgYW5kIFJTLXRvLUMgKGluIHRoZQ0KICAgID4gICAgID4gICAgIHJlc3BlY3Rp dmUgc3Vic2VjdGlvbnMpPw0KICAgID4gICAgID4gICAgIA0KICAgID4gICAgID4gRlA6IEkgYW0g bm90IHN1cmUgd2hhdCB5b3XigJlkIGxpa2UgdG8gc2VlIGluIENEREwgaW4gdGhpcyBzdWJzZWN0 aW9uLCBjb3VsZCB5b3UgZXhwYW5kPw0KICAgID4gICAgIA0KICAgID4gICAgIEkgYW0gbm90IHN1 cmUgd2hhdCB0aGUgYm9keSBvZiB0aGUgUE9TVCBhbmQgcmVzcG9uc2UgdGhlcmV0byBhcmUgZm9y bWF0dGVkDQogICAgPiAgICAgYXMuICBNYXliZSBDRERMIGlzIG5vdCBxdWl0ZSByaWdodCwgaWYg d2Ugb25seSB3YW50IHRvIHByb3ZpZGUgYW4gZXhhbXBsZQ0KICAgID4gICAgIHdpdGggYSBwYXJ0 aWN1bGFyIGNvbnRlbnQtZm9ybWF0IGJ1dCBhbGxvdyBtYW55IGZvcm1hdHMuDQogICAgPiAgICAg DQogICAgPiBGUDogSSB0aGluayB0aGlzIHNob3VsZCBiZSBjb3ZlcmVkIGluIHRoZSBleGFtcGxl cyBvZiB0aG9zZSAyIG1lc3NhZ2VzLCBzZWUgZmlndXJlcyAxMSBhbmQgMTIuIEFueXRoaW5nIGVs c2UgbmVlZGVkPw0KICAgIA0KICAgIEkgd291bGQgcHJlZmVyIHRvIGhhdmUgc29tZXRoaW5nIHRo YXQgbG9va3MgbW9yZSBsaWtlIGEgZm9ybWFsIHN5bnRheCB0aGFuDQogICAganVzdCByZWx5aW5n IG9uIGV4YW1wbGVzLCB0aG91Z2ggSSBkb24ndCBpbnNpc3QgdXBvbiBpdCBmb3Igbm93LiAgKFNv bWUNCiAgICBvdGhlciBBRHMgbWlnaHQsIHRob3VnaC4pDQoNCltGUF0gT2ssIEknbGwga2VlcCBp dCBpbiBtaW5kLg0KICAgIA0KICAgID4gICAgID4gNTEuICAgICAgIE5vdGUgdGhhdCB0aGUgcHJv b2Ytb2YtcG9zc2Vzc2lvbiByZXF1aXJlZCB0byBiaW5kIHRoZSBhY2Nlc3MgdG9rZW4NCiAgICA+ ICAgICA+ICAgICAgICB0byB0aGUgY2xpZW50IGlzIGltcGxpY2l0bHkgcGVyZm9ybWVkIGJ5IGdl bmVyYXRpbmcgdGhlIHNoYXJlZCBPU0NPUkUNCiAgICA+ICAgICA+ICAgICAgICBTZWN1cml0eSBD b250ZXh0IHVzaW5nIHRoZSBwb3Ata2V5IGFzIG1hc3RlciBzZWNyZXQsIGZvciBib3RoIGNsaWVu dA0KICAgID4gICAgID4gICAgICAgIGFuZCBSUy4gIEFuIGF0dGFja2VyIHVzaW5nIGEgc3RvbGVu IHRva2VuIHdpbGwgbm90IGJlIGFibGUgdG8NCiAgICA+ICAgICA+ICAgICAgICBnZW5lcmF0ZSBh IHZhbGlkIE9TQ09SRSBjb250ZXh0IGFuZCB0aHVzIG5vdCBiZSBhYmxlIHRvIHByb3ZlDQogICAg PiAgICAgPiAgICAgICAgcG9zc2Vzc2lvbiBvZiB0aGUgcG9wLWtleS4NCiAgICA+ICAgICA+ICAg ICANCiAgICA+ICAgICA+ICAgICBJdCBtYXkgYmUgd29ydGggc2F5aW5nIHNvbWV0aGluZyByb3Vn aGx5IGVxdWF0aW5nICJwcm9vZiBvZiBwb3NzZXNpb24NCiAgICA+ICAgICA+ICAgICBwZXJmb3Jt ZWQgYnkgdGhlIFJTIiBhbmQgInRoZSBSUyBhdXRoZW50aWNhdGluZyBpdHNlbGYgdG8gdGhlIGNs aWVudCIsDQogICAgPiAgICAgPiAgICAgc2luY2UgdGhlcmUgaXMgbm90IGFuIGV4dGVybmFsIGFj dGlvbiBmb3Igc2VydmVyIGF1dGhlbnRpY2F0aW9uLg0KICAgID4gICAgID4gICAgIEFsc28sIElT VFIgZ2V0dGluZyBzb21lIHB1c2hiYWNrIG9uIGEgZGlmZmVyZW50IGRvY3VtZW50IHRoYXQgdGFs a2VkDQogICAgPiAgICAgPiAgICAgYWJvdXQgYW4gYXR0YWNrZXIgd2l0aCBhICJzdG9sZW4gdG9r ZW4iLCBhcyBzb21ldGhpbmcgdGhhdCBjYW4gc3RlYWwgYQ0KICAgID4gICAgID4gICAgIHRva2Vu IGZyb20gdGhlIGNsaWVudCdzIGxvY2FsIHN0b3JhZ2UgbWlnaHQgYWxzbyBzdGVhbCB0aGUgYXNz b2NpYXRlZA0KICAgID4gICAgID4gICAgIGtleS4gIEkgZm9yZ2V0IGlmIHdlIGVuZGVkIHVwIGNo YW5naW5nIHRvIHNvbWUgb3RoZXIgcGhyYXNpbmcgb3Igbm90LA0KICAgID4gICAgID4gICAgIHRo b3VnaCA6KA0KICAgID4gICAgID4gDQogICAgPiAgICAgPiBGUDogT2ssIHdpbGwgcmVwaHJhc2Ug dG8g4oCcdGhlIFJTIGF1dGhlbnRpY2F0aW5nIGl0c2VsZuKAnSBpbnN0ZWFkIG9mIOKAnHBvcCBw ZXJmb3JtZWQgYnkgdGhlIFJT4oCdLiBBbHNvLCB3aGF0IGFib3V0IHVzaW5nIGVhdmVzZHJvcCBo ZXJlIGluc3RlYWQ/DQogICAgPiAgICAgDQogICAgPiAgICAgRWF2ZXNkcm9wIG1heSBiZSB0b28g bGltaXRlZCwgYXMgSSB0aGluayBpdCdzIGFsc28gaW4gc2NvcGUgZm9yIHRoZSBhdHRhY2sNCiAg ICA+ICAgICB3aGVuIGFuIFJTIHJlY2VpdmVzICh3aGV0aGVyIGxlZ2l0aW1hdGVseSBvciBieSBk ZWNlcHRpb24pIHRoZSB0b2tlbiBpbg0KICAgID4gICAgIHF1ZXN0aW9uIGFzIHRoZSB0YXJnZXQg b2YgYSBDb0FQIHJlcXVlc3QuDQogICAgPiANCiAgICA+IEZQOiBPaywgZGlkIG5vdCB1c2UgdGhl IHRlcm0gZWF2ZXNkcm9wLg0KICAgID4gICAgIA0KICAgID4gICAgID4gNTguICAgICAgIHRvIGNs YWltcyB0aGF0IHRoZSBSUyBjYW5ub3QgcHJvY2VzcyAoZS5nLiwgYW4gdW5rbm93biBzY29wZSks IG9yIGlmDQogICAgPiAgICAgPiAgICAgICAgYW55IG9mIHRoZSBleHBlY3RlZCBwYXJhbWV0ZXJz IGluIHRoZSBPU0NPUkVfU2VjdXJpdHlfQ29udGV4dCBpcw0KICAgID4gICAgID4gICAgIA0KICAg ID4gICAgID4gICAgIEhtbSwgImFzc29jaWF0ZWQgdG8gY2xhaW1zIHRoYXQgdGhlIFJTIGNhbm5v dCBwcm9jZXNzIiBzb3VuZHMgbGlrZSB3ZSdyZQ0KICAgID4gICAgID4gICAgIHRlbGxpbmcgdGhl IFJTIHRvIGFib3J0IGlmIHRoZSB0b2tlbiBpbmNsdWRlcyBhbnkgdW5yZWNvZ25pemVkIGNsYWlt cywNCiAgICA+ICAgICA+ICAgICB3aGljaCBJSVVDIGlzIGF0IG9kZHMgd2l0aCB0aGUgT0F1dGgg Mi4wIHBoaWxvc29waHkgb2YgaWdub3JpbmcNCiAgICA+ICAgICA+ICAgICB1bnJlY29nbml6ZWQg cGFyYW1ldGVycy4gIChIb3BlZnVsbHkgc29tZW9uZSB3aWxsIGNvcnJlY3QgbWUgaWYgSSdtDQog ICAgPiAgICAgPiAgICAgbWlzcmVtZW1iZXJpbmcgdGhhdC4pDQogICAgPiAgICAgPiANCiAgICA+ ICAgICA+IEZQOiBUaGlzIHBhcmFncmFwaCBpcyBtZWFudCB0byBtaXJyb3Igd2hhdCBzcGVjaWZp ZWQgaW4gNS44LjEuMSBvZiBhY2Utb2F1dGgtYXV0aHo6DQogICAgPiAgICAgPiBJZiB0aGUgY2xh aW1zIGNhbm5vdCBiZSBvYnRhaW5lZCB0aGUgUlMgTVVTVCBkaXNjYXJkIHRoZSB0b2tlbg0KICAg ID4gICAgID4gICAgICAgYW5kLCBpbiBjYXNlIG9mIGFuIGludGVyYWN0aW9uIHZpYSB0aGUgYXV0 aHotaW5mbyBlbmRwb2ludCwgcmV0dXJuDQogICAgPiAgICAgPiAgICAgICBhbiBlcnJvciBtZXNz YWdlIHdpdGggYSByZXNwb25zZSBjb2RlIGVxdWl2YWxlbnQgdG8gdGhlIENvQVAgY29kZQ0KICAg ID4gICAgID4gICAgICAgNC4wMCAoQmFkIFJlcXVlc3QpLg0KICAgID4gICAgID4gTmV4dCwgdGhl IFJTIE1VU1QgdmVyaWZ5IGNsYWltcywgaWYgcHJlc2VudCwgY29udGFpbmVkIGluIHRoZSBhY2Nl c3MNCiAgICA+ICAgICA+ICAgIHRva2VuLiAgRXJyb3JzIGFyZSByZXR1cm5lZCB3aGVuIGNsYWlt IGNoZWNrcyBmYWlsLCBpbiB0aGUgb3JkZXIgb2YNCiAgICA+ICAgICA+ICAgIHByaW9yaXR5IG9m IHRoaXMgbGlzdDoNCiAgICA+ICAgICANCiAgICA+ICAgICBBaCwgbWF5YmUgdGhlIGFjZSBmcmFt ZXdvcmsgZGl2ZXJnZXMgZnJvbSBvYXV0aCBoZXJlIGFuZCBJIG1pc3JlbWVtYmVyZWQuDQogICAg PiAgICAgQnV0IGlzIHRoaXMgYmVoYXZpb3IgbGltaXRlZCB0byAiYW55IG9mIHRoZSBmb3VyIHN0 YW5kYXJkIGNsYWltcyB0aGF0IGhhdmUNCiAgICA+ICAgICBhIHZhbHVlIHRoYXQgY2Fubm90IGJl IHByb2Nlc3NlZCIgb3IgZG9lcyBpdCBhbHNvIGluY2x1ZGUgInRoZXJlIHdhcyBhbg0KICAgID4g ICAgIHVucmVjb2duaXplZCBjbGFpbSI/DQogICAgPiANCiAgICA+IEZQOiBZZXMsIEkgY2hlY2tl ZCB3aXRoIEx1ZHdpZyB3aG8gY29uZmlybWVkIHRoYXQgdGhlIGZyYW1ld29yayBkaXZlcmdlcyBm cm9tIG9hdXRoIGFuZCB0aGF0IGl0J3MgZm9yIGFueSB1bnJlY29nbml6ZWQgY2xhaW1zLiBTbyBJ IGRpZCBub3QgZG8gYW55IG1vZGlmaWNhdGlvbnMgaGVyZS4NCiAgICANCiAgICBPa2F5LCB0aGFu a3MgZm9yIGNvbmZpcm1pbmcgYW5kIHNvcnJ5IGZvciBtaXNyZW1lYm1lcmluZy4NCiAgICANCiAg ICA+ICAgICA+IDY3LiAgICAgICBBZnRlciBzZW5kaW5nIHRoZSAyLjAxIChDcmVhdGVkKSByZXNw b25zZSwgdGhlIFJTIE1VU1Qgc2V0IHRoZSBNYXN0ZXINCiAgICA+ICAgICA+ICAgICAgICBTYWx0 IG9mIHRoZSBTZWN1cml0eSBDb250ZXh0IGNyZWF0ZWQgdG8gY29tbXVuaWNhdGUgd2l0aCB0aGUg Y2xpZW50DQogICAgPiAgICAgPiAgICAgICAgdG8gdGhlIGNvbmNhdGVuYXRpb24gb2Ygc2FsdCwg TjEsIGFuZCBOMiwgaW4gdGhpcyBvcmRlcjogTWFzdGVyIFNhbHQNCiAgICA+ICAgICA+ICAgICAg ICA9IHNhbHQgfCBOMSB8IE4yLCB3aGVyZSB8IGRlbm90ZXMgYnl0ZSBzdHJpbmcgY29uY2F0ZW5h dGlvbiwgYW5kDQogICAgPiAgICAgPiAgICAgDQogICAgPiAgICAgPiAgICAgW0l0IG1pZ2h0IGJl IHdvcnRoIGJyZWFraW5nIHRoaXMgY29tcHV0YXRpb24gb2ZmIGludG8gYSBzdGFuZGFsb25lIHBp ZWNlIG9mDQogICAgPiAgICAgPiAgICAgdGV4dCB0aGF0IGFwcGxpZXMgdG8gYm90aCBDIGFuZCBS UywgaW5jbHVkaW5nIHRoZSBlZGl0cyBmb3IgaW5qZWN0aXZpdHkuXQ0KICAgID4gICAgID4gICAg IA0KICAgID4gICAgID4gRlA6IE9LDQogICAgPiANCiAgICA+IEZQOiBJIHRyaWVkIHRvIGRvIHRo aXMsIGJ1dCBkaWQgbm90IG1hbmFnZSB0byBpbXBsZW1lbnQgdGhlIGNoYW5nZSBpbiBhIHNhdGlz ZmFjdG9yeSB3YXkgdGhhdCB3b3VsZCBpbXByb3ZlIHJlYWRhYmlsaXR5LCBzbyBJIGdhdmUgdXAu IFRoZSByZWFzb24gaXMgdGhhdCB0aGUgdGV4dCB0aGF0IGlzIGFjdHVhbGx5IHRoZSBzYW1lIGlz IG9ubHkgIk1hc3RlciBTYWx0IGlzIHRoZSBjb25jYXRlbmF0aW9uIG9mIC4uLiIsIHdoaWxlIHRo ZSBzdXJyb3VuZGluZyB0ZXh0IGlzIHZlcnkgbXVjaCBub2RlLXNwZWNpZmljLiBBbHNvLCB0aGUg dGV4dCBpcyB3cml0dGVuIGluIGEgd2F5IHRvIHNlcXVlbnRpYWxseSBleHBsYWluIGNsaWVudCBh bmQgUlMgcHJvY2Vzc2luZy4gTW92aW5nIHRoaXMgdGV4dCBhcm91bmQgd291bGQgbWFrZSB0aGUg cmVhZGVyIGp1bXAgZnJvbSBhIHNlY3Rpb24gdG8gYW5vdGhlci4gSWYgeW91IGhhdmUgc3VnZ2Vz dGlvbnMgb24gYSBiZXR0ZXIgd2F5IHRvIHN0cnVjdHVyZSB0aGlzIHRleHQsIEknbGwgdGFrZSB0 aGVtLiANCiAgICANCiAgICBUaGFuayB5b3UgZm9yIHRyeWluZzsgSSBkb24ndCB0aGluayB3ZSBu ZWVkIHRvIGdvIHRvIGdyZWF0IGxlbmd0aHMgdG8gbWFrZQ0KICAgIHRoaXMgcmVmYWN0b3Jpbmcg aGFwcGVuLg0KICAgIA0KICAgID4gICAgID4gNzYuICAgICAgIGF1dGhvcml6YXRpb24gaW5mb3Jt YXRpb24gZnJvbSB0aGUgYWNjZXNzIHRva2VuIGFzc29jaWF0ZWQgdG8gdGhlDQogICAgPiAgICAg PiAgICAgICAgU2VjdXJpdHkgQ29udGV4dC4gIFRoZSBSUyB0aGVuIE1VU1QgdmVyaWZ5IHRoYXQg dGhlIGF1dGhvcml6YXRpb24NCiAgICA+ICAgICA+ICAgICAgICBpbmZvcm1hdGlvbiBjb3ZlcnMg dGhlIHJlc291cmNlIGFuZCB0aGUgYWN0aW9uIHJlcXVlc3RlZC4NCiAgICA+ICAgICA+ICAgICAN CiAgICA+ICAgICA+ICAgICBJbiB0aGUgdmVpbiBvZiBteSBwcmV2aW91cyBub3RlIGFib3V0IGFu IGFic3RyYWN0IGRhdGEgbW9kZWwsIHdlIG1heSBub3Qgd2FudA0KICAgID4gICAgID4gICAgIHRv IGJlIG92ZXJseSBwcmVzY3JpcHRpdmUgYWJvdXQgInJldHJpZXZlcyBbLi4uXSBmcm9tIHRoZSBh Y2Nlc3MgdG9rZW4iLg0KICAgID4gICAgID4gICAgIFBlci1yZXF1ZXN0IGludHJvc3BlY3Rpb24g aXMgYWxsb3dlZCwgYXMgaXMgY2FjaGluZyB0aGUgYXV0aG9yaXphdGlvbg0KICAgID4gICAgID4g ICAgIGluZm9ybWF0aW9uIGluIGEgbm9uLXRva2VuIGxvY2FsIGRhdGFzdG9yZS4NCiAgICA+ICAg ICA+IA0KICAgID4gICAgID4gRlA6IE9rLCBJIHVuZGVyc3RhbmQgYnV0IEkgYW0gbm90IHN1cmUg aG93IHRvIGltcGxlbWVudCB0aGlzIGNvbW1lbnQuIOKAnFJldHJpZXZl4oCdIG1heSBiZSBtaXNp bnRlcnByZXRlZCwgYnV0IGluIG15IG1pbmQgaXQgY2FuIG1lYW4gYm90aCBieSBsb29raW5nIHVw IGNhY2hpbmcgaW5mbyBhcyB3ZWxsIGFzIGludHJvc3BlY3RpbmcuIEhvdyB0byBtYWtlIHRoaXMg Y2xlYXJlcj8NCiAgICA+ICAgICANCiAgICA+ICAgICBXb3VsZCBzL2Zyb20vdXNpbmcvIHdvcms/ DQogICAgPiANCiAgICA+IEZQOiBZZXMhIFRoYW5rcy4NCiAgICA+ICAgICANCiAgICA+ICAgICA+ ICAgICANCiAgICA+ICAgICA+IDkyLiAgICAgICBvICBQcm9maWxlIERlc2NyaXB0aW9uOiBQcm9m aWxlIGZvciB1c2luZyBPU0NPUkUgdG8gc2VjdXJlDQogICAgPiAgICAgPiAgICAgICAgICAgY29t bXVuaWNhdGlvbiBiZXR3ZWVuIGNvbnN0cmFpbmVkIG5vZGVzIHVzaW5nIHRoZSBBdXRoZW50aWNh dGlvbg0KICAgID4gICAgID4gICAgICAgICAgIGFuZCBBdXRob3JpemF0aW9uIGZvciBDb25zdHJh aW5lZCBFbnZpcm9ubWVudHMgZnJhbWV3b3JrLg0KICAgID4gICAgID4gICAgIA0KICAgID4gICAg ID4gICAgIFRoaXMgaXMgdGhlIHJlZ2lzdHJ5IGZvciBBQ0UgcHJvZmlsZXM7ICJ1c2luZyB0aGUg QXV0aGVudGljYXRpb24gYW5kDQogICAgPiAgICAgPiAgICAgQXV0aG9yaXphdGlvbiBmb3IgQ29u c3RyYWluZWQgRW52aXJvcm5tZW50cyBmcmFtZXdvcmsiIGZlZWxzIHJlZHVuZGFudC4NCiAgICA+ ICAgICA+ICAgICBUaGVyZSdzIGFsc28gcGVyaGFwcyBzb21ldGhpbmcgdG8gc2F5IGFib3V0IGRl ZmluaW5nICJjb2FwX29zY29yZSIgZm9yIGFsbA0KICAgID4gICAgID4gICAgIHRocmVlIGludGVy YWN0aW9uIGZsb3dzIGV2ZW4gdGhvdWdoIHRoZSBwcm9jZWR1cmVzIGZvciB0d28gb2YgdGhlIHRo cmVlIGFyZQ0KICAgID4gICAgID4gICAgIGVzc2VudGlhbGx5IGp1c3QgIm91dCBvZiB0aGUgc2Nv cGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uIiwgdGhvdWdoIGhhdmluZw0KICAgID4gICAgID4gICAg ICpzb21lKiBpZGVudGlmaWVyIGZvciAidXNlIE9TQ09SRSIgaXMgcHJvYmFibHkgc3RpbGwgdXNl ZnVsLg0KICAgID4gICAgID4gICAgIA0KICAgID4gICAgID4gRlA6IE9rLCB3ZSBjYW4gcmVtb3Zl IHRoZSBsYXN0IHBhcnQuIEFib3V0IHRoZSBpbnRlcmFjdGlvbiBmbG93cyBiZXR3ZWVuIG5vZGVz LCBJIGFtIG5vdCBzdXJlIHdoYXQgeW91IG1lYW4sIGFzIGJ5IGZvbGxvd2luZyBkZWZpbml0aW9u IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFjZS1vYXV0aC1hdXRoei0z MSNzZWN0aW9uLTUuNi40LjMgaXQgaXMgbm90IG1hbmRhdG9yeSBmb3IgYSBwcm9maWxlIHRvIHNw ZWNpZnkgQy1BUyBhbmQgUlMtQVMsIHRob3NlIGZsb3dzIGNhbiBiZSBvdXQgb2Ygc2NvcGUuIEFt IEkgbWlzc2luZyBzb21ldGhpbmc/DQogICAgPiAgICAgDQogICAgPiAgICAgSXQncyBub3QgbWFu ZGF0b3J5LCB0aG91Z2ggZ2l2ZW4gdGhhdCB3ZSB0YWxrIGFib3V0IHByb2ZpbGVzIG5vdCBiZWlu ZyBhYmxlDQogICAgPiAgICAgdG8gYXNzdW1lIHRoYXQgdGhlIHNhbWUgcHJvZmlsZSBpcyB1c2Vk IGZvciBhbnkvYWxsIG9mIEMvUlMsIEMvQVMsIGFuZA0KICAgID4gICAgIFJTL0FTLCBJIGd1ZXNz IEkgYXNzdW1lZCB0aGF0IHdlIHVzZSB0aGUgcHJvZmlsZSBpZGVudGlmaWVyIHRvIHRhbGsgYWJv dXQNCiAgICA+ICAgICB0aGUgbGFzdCB0d28gY2FzZXMgYXMgd2VsbCBhcyB0aGUgZmlyc3Qgb25l LiAgTWF5YmUgSSdtIHdyb25nIHRvIGFzc3VtZQ0KICAgID4gICAgIHRoYXQhDQogICAgPiANCiAg ICA+IEZQOiBGcm9tIG15IHVuZGVyc3RhbmRpbmcsIHRoYXQncyBub3QgdGhlIGNhc2UsIGFzIEkg c2FpZCBhYm92ZS4gTWF5YmUgc29tZW9uZSBlbHNlIGNhbiBjb25maXJtLg0KICAgID4gICAgIA0K ICAgID4gICAgIFJlZ2FyZGxlc3MsIEkgdGhpbmsgdGhlIHF1ZXN0aW9uIGhlcmUgaXMgd2hldGhl ciB3ZSB3YW50IHRvIGhhdmUgcGVvcGxlIHVzZQ0KICAgID4gICAgIHRoZSAiY29hcF9vc2NvcmUi IHN0cmluZyB0byBpbmRpY2F0ZSB0aGF0IEMvQVMgYW5kL29yIFJTL0FTIHVzZSBPU0NPUkUsIG9y DQogICAgPiAgICAgaWYgdGhhdCBpbmZvcm1hdGlvbiBpcyBub3QgZXhwZWN0ZWQgdG8gYmUgZW5j b2RlZCBpbiBhbnkgcHJvdG9jb2wgZWxlbWVudDsNCiAgICA+ICAgICBpZiB0aGUgbGF0dGVyLCB0 aGVuIHRoZXJlJ3Mgbm90aGluZyB0byBjaGFuZ2UuDQogICAgPiANCiAgICA+IEZQOiBBcyBvZiBu b3csIHRoYXQgaW5mb3JtYXRpb24gaXMgbm90IGV4cGVjdGVkIHRvIGJlIGVuY29kZWQgaW4gYW55 IHByb3RvY29sIGVsZW1lbnQsIGFzIGZhciBhcyBJIHVuZGVyc3RhbmQuIEFnYWluLCBpZiBhbnli b2R5IGNhbiBjb25maXJtL3Nob3V0IGlmIHdyb25nLCBwbGVhc2UgZG8uDQogICAgDQogICAgT2th eS4gIEkgd291bGQgYmUgaGFwcHkgdG8gaGVhciBmcm9tIHRoZSBXRyBpZiB0aGVyZSBhcmUgb3Ro ZXIga25vd24gdXNlcw0KICAgIGxpa2UgdGhpcy4NCg0KW0ZQXSBJJ2xsIGJyaW5nIHRoaXMgdXAg aW4gdGhlIGludGVyaW0gbGF0ZXIgdG9kYXkuDQogICAgDQogICAgPiAgICAgPiA5Ni4gICAgIk9T Q09SRV9TZWN1cml0eV9Db250ZXh0IiBmZWVscyBsaWtlIGEgc29tZXdoYXQgbG9uZyBuYW1lIGlu IGxpZ2h0IG9mIHRoZQ0KICAgID4gICAgID4gICAgIHByZXZpb3VzIGNvbW1lbnRhcnkgYWJvdXQg c2hvcnRlciBuYW1lcyBiZWluZyBwcmVmZXJyZWQuIDopDQogICAgPiAgICAgPiAgICAgDQogICAg PiAgICAgPiBGUDogVHlwaWNhbGx5IHRoaXMgd2hvbGUgbmFtZSBzaG91bGQgbm90IGJlIHNlbnQg d2hlbiBDQk9SIGlzIHVzZWQgKHNvIGluIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cykuIEJ1dCB3 ZeKAmWxsIHNob3J0ZW4gaXQsIHdoYXQgYWJvdXQgIlNlY19DdHgiPw0KICAgID4gICAgIA0KICAg ID4gICAgIFRoZXJlJ3Mgbm8gbmVlZCB0byBzaG9ydGVuIGl0IGp1c3Qgb24gbXkgYWNjb3VudDsg YXMgeW91IG5vdGUsIGl0J3MNCiAgICA+ICAgICBnZW5lcmFsbHkgZ29pbmcgdG8gYmUgdGhlIENC T1IgdGFnIHRoYXQncyB1c2VkLg0KICAgID4gDQogICAgPiBGUDogSSBlbmRlZCB1cCBzaG9ydGVu aW5nIHRoZSBuYW1lIG9mIHRoZSBDV1QgcGFyYW1ldGVyIHRvICJvc2MiIChzYW1lIGFzIEpXVCks IGV2ZW4gdGhvdWdoIHRoZSBDQk9SIGxhYmVsIHdvdWxkIGJlIHVzZWQgaW5zdGVhZCwgYnV0IGtl cHQgdGhlICJPU0NPUkVfU2VjdXJpdHlfQ29udGV4dCIgYXMgdGhlIG5hbWUgZm9yIHRoZSBDQk9S IG1hcC4gSSB0aGluayBpdCdzIGJldHRlciB0byBzZXBhcmF0ZSBiZXR3ZWVuIHRoZSBDQk9SIG9i amVjdCBhbmQgdGhlIENXVCBmaWVsZCdzIG5hbWUuDQogICAgDQogICAgVGhhdCBzZWVtcyBsaWtl bHkgdG8gYmUgYSBnb29kIGlkZWE7IEknbGwgdHJ5IHRvIHJlbWVtYmVyIHRvIGxvb2sgZm9yIGl0 DQogICAgd2hlbiBJJ20gcmVhZGluZyB0aGUgZGlmZi4NCiAgICANCiAgICBUaGFua3MhDQogICAg DQogICAgLUJlbg0KICAgIA0KDQo= From nobody Tue Feb 25 03:05: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 25EE33A0988; Tue, 25 Feb 2020 03:04:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=risecloud.onmicrosoft.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 rClZ011cJukd; Tue, 25 Feb 2020 03:04:54 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50074.outbound.protection.outlook.com [40.107.5.74]) (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 284A53A08B1; Tue, 25 Feb 2020 03:04:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PLWjRwBSdYgHyubitAVMkymhEEK9W9+NJ2cgezTXnzdr1LbEWgcWBnKhXTHtW/CYChzm1M+fahwqYyxrKi8XHUymmwEfFU3Pn3kMnKjfnAIrGdcKFoFfa0UEYHIfJ3jxKbLtJRDk1pT3s65L+4EZiGHOrKBbesK+0QpWk65smu8dHUCeyo/3RoSXq2zvM2ZK29SNA/VdKy2QOiQS/Wn5laIe7iq0kYiu3WUPwwXiLQOtnUVKjRqYzOpDy0L35Pig8Q1xNBmBCvLPysclz2u5x+Psghys5zS0gByPE/ULUD7gUHh5iMabZLRirDYmaTgw6jWVWtgdY4I81A6ukxrAxg== 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=hfwweIPuvgU51jSooI8ptrl65cmWdu8459csQHPijl0=; b=BEU4m3NJCMqJ029DxKr4eOGTUlgHiCtPe/Wv2gEpTHkhWcsTWN71Jk213iD8NJvyQdSzNxcy6pfQ92GJvaEWqXNtGhTDEvTdv2z6b5tH9mUrOWJUHFgU6CuUdM1hg5I30alFL4ND+wFoX1/oLA8ZafUwnndLt2oHifhOD1UrfChiQGDq+DyhZViQ2IcF2NlkQj8h6eoSGh/rx0hDHauZ3IMhU7oSbdfklA05e06uHcRj8NAaHdiWIBQtuKrCpDmAjYXvdwoWNKtY9ADyVQ3D776vx5icN4MFNIDhhbmM+j6RBYY3zvC9RA7A7eEP0Lkv5ieNVRhnGPCStNUzhF1MrA== 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=RISEcloud.onmicrosoft.com; s=selector1-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hfwweIPuvgU51jSooI8ptrl65cmWdu8459csQHPijl0=; b=bBb+5qyZEh9+9o8557tZ3SE5PQceRST/Z3vtYzTh/ASXdYS91OjvLx3JCVexoh1bq5E0t4AjuUEzKVHl9LfCU3h0hlYKsOvilba/b3qa6xAWN3wt21dAi57vlJajjAQAxPv/tYeDyRJ7N7nuD5X6/m6t6TTh7yyk3uILW+U+J2I= Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (10.165.195.159) by VI1P189MB0336.EURP189.PROD.OUTLOOK.COM (10.165.196.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.21; Tue, 25 Feb 2020 11:04:49 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::80e4:7dc7:7d4e:c9cb]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::80e4:7dc7:7d4e:c9cb%4]) with mapi id 15.20.2750.021; Tue, 25 Feb 2020 11:04:49 +0000 Received: from [10.8.1.17] (185.236.42.19) by HE1PR0902CA0013.eurprd09.prod.outlook.com (2603:10a6:3:e5::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.21 via Frontend Transport; Tue, 25 Feb 2020 11:04:48 +0000 From: Marco Tiloca To: Jim Schaad , "draft-ietf-ace-key-groupcomm-oscore@ietf.org" CC: 'Ace Wg' Thread-Topic: Scope question Thread-Index: AdXrOKpmWNataaOcRlGMfJexQnZTiAAL2OEAAAyy1gAADCHagA== Date: Tue, 25 Feb 2020 11:04:49 +0000 Message-ID: <975ad712-ddf5-0010-beee-8f08817bc595@ri.se> References: <01b501d5eb3c$8e7d9e60$ab78db20$@augustcellars.com> <01f301d5eb9a$db047110$910d5330$@augustcellars.com> In-Reply-To: <01f301d5eb9a$db047110$910d5330$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-clientproxiedby: HE1PR0902CA0013.eurprd09.prod.outlook.com (2603:10a6:3:e5::23) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) authentication-results: spf=none (sender IP is ) smtp.mailfrom=marco.tiloca@ri.se; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [185.236.42.19] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 19457dd9-9cd2-4cda-cee6-08d7b9e287f3 x-ms-traffictypediagnostic: VI1P189MB0336: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0324C2C0E2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(199004)(189003)(53546011)(86362001)(8936002)(110136005)(7116003)(71200400001)(44832011)(52116002)(81156014)(16526019)(81166006)(31696002)(4326008)(8676002)(498600001)(3480700007)(36756003)(66446008)(66616009)(6486002)(66574012)(31686004)(66556008)(66476007)(2616005)(956004)(186003)(5660300002)(16576012)(966005)(2906002)(66946007)(26005)(64756008); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P189MB0336; H:VI1P189MB0398.EURP189.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ri.se does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 92FhJ3XunuKstfNMzqDe6Y6hg3S2D2I7Uy+6EaCEGV1Mm/tDnzjcdHtp7NU/R4IzpTdDEMIOwtqOYuWclORP99I6mMR6weEpE7HCo5zBlTJcJNVQxKd1OqcuWcyt3eA6YMvbuFJSF6Eq61yILCDDRM2FvU35pZYDHfs+CwOXhSPze2SEV2BQZDqXteO+KWT85hJS3j0PxQKYBeeEtWJ6ivcxDqkpgh1TvVdqi51SafQOTsD9yOYqrxgPH81ZczaOfq4DDQa49TFnW5q7uhdKnbBVBvoD4HU2OMPF6PoBDgh5nq2H9bISDEnYOsEMndsMMrys759VxymblrKH9JaS5ls0pxSd0rgXyGtBctUL0P8OQ9V6ZjNDDxivmiujQW+fpaktSHVLhanYw1Tj0lSldhiNj38EWulIUvh/msB7uXLDnDbe6C29R15LlDzWoRSktclZEgnNx1Zw6+DPw7Tuv4HSxkzKGnXFVVUQefKfQa+0pF9NDiA+Mpy7+xISXL5LDP5/11aIICK6rg5ugJAgjg== x-ms-exchange-antispam-messagedata: VwUOIHYp0s2Gg8jrL9BmoUQ3RZQ52ggl2wpoPfrFeBPjY5XGdnXBhHudCn9lp44OFiMJgnv3zZQOC3rVgedP1FfWe43NRSUsPAa1621jfXvmISOrvg77oYQihHhHdILddY4i0pXpRXe+p/YXh53MsA== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0ZbrTf40DBBXD7wmy9t0M6XNYnNhpUepn" MIME-Version: 1.0 X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 19457dd9-9cd2-4cda-cee6-08d7b9e287f3 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2020 11:04:49.3732 (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: tLFcKwCfoODRU94U+upNled7Jgrdjll5wFpDhQSpENF03TFmVhlUB4cZGPgVQvjtFfox8CTi0qY3CCtPMOTP6g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0336 Archived-At: Subject: Re: [Ace] Scope question 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, 25 Feb 2020 11:04:58 -0000 --0ZbrTf40DBBXD7wmy9t0M6XNYnNhpUepn Content-Type: multipart/mixed; boundary="sp7JEXI4EsquoxbAOBJ6QjDDEKfThdL6A" --sp7JEXI4EsquoxbAOBJ6QjDDEKfThdL6A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Jim, On 2020-02-25 06:17, Jim Schaad wrote: > > -----Original Message----- > From: Marco Tiloca =20 > Sent: Monday, February 24, 2020 2:14 PM > To: Jim Schaad ; draft-ietf-ace-key-groupcomm-o= score@ietf.org > Cc: 'Ace Wg' > Subject: Re: Scope question > > Hi Jim, > > On 2020-02-24 19:02, Jim Schaad wrote: >> I was starting to code up the encoding of scope and wanted to clarify = >> what the encoding is. >> >> The text appears to say that the encoding is: >> >> scope =3D [ groupId: tstr, ?[* role : any ]] >> >> I was expecting this to be more along the lines of >> >> scope =3D [ + scope_item ] >> scopeItem =3D [ groupId: tstr, ?[* role : any ]] >> >> This would allow for more than one group to be identified in a single = >> token which I think is important given some of the statements about=20 >> only having a single token for a client. This does not solve the=20 >> resource server having multiple audiences but that is fine. > =3D=3D>MT > At the January interim, we mentioned a multi group/topic scope as next = step. The format you suggest above is essentially the one we also had in = mind. This should be firstly defined in the ace-key-groupcomm document. > > This should be just fine for the Token request/response and the Access = Token itself. Then I am thinking of what happens next. In a general case,= in each of the specified groups a different signature algorithm > (etc.) is used. > > Then, in the 2.01 response from /authz-info , we would have 'sign_info'= > also as an array of arrays and 'pub_key_enc' as an array (unless the ve= ry same configuration applies for each scopeItem above). Same goes for 'r= snonce' becoming an array. The order of such arrays' elements is the same= as for the scopeItems in the 'scope' claim. > <=3D=3D > > [JLS] I am having some problems with thinking that this is a good idea.= The only reason to have different signing keys is to keep the different= signature keys isolated in terms of correlation. If this is the case t= hen adding a situation where we are going to share this information with = a specific entity seems to be a bad idea. I would think that if the sign= ing keys are going to be separate then that should be true all of the bac= k as far as possible. This would mean that, if possible, that even the A= S should not know that the different signing keys are associated with the= same entity. =3D=3D>MT I see your point, that holds regardless the simple or structured scope. So far, we have considered a client possibly providing different public keys to be able to join different types of groups, i.e. using different signature algorithms, under the same GM, hence requiring different public keys to correctly work. We haven't thought of a client interested in isolating its signature keys, which would of course fail by concentrating multiple public keys on the same entity. Let's build on limiting a client to have at most one public key under a same GM. Then the following should happen. 1) It's still possible for the GM to have different types of groups, i.e. using different signature algorithms. 2) The client cannot (ever?) join groups of different types, as that would require different public keys to be provided to the GM. 3) If an administrator changes the signature algorithm of one group, the same change should be enforced for consistency to the other groups of the same kind, in the interest of their current members. Those members would have to upload a new working public key, hence ending up exposing a second one anyway. On the good side, that would simplify the public key handling and caching at the GM in [1] :-) [1] https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore-04#sectio= n-5 <=3D=3D Best, /Marco > > Jim > > >> I am unsure if it makes sense to allow for the array to be removed for= =20 >> scope in the second example in the event that only one group is=20 >> specified. One byte saved at the expense of more code. > =3D=3D>MT > I think it makes sense to avoid that byte, and essentially revert to th= e original scope format when only one group is specified. > <=3D=3D > > Best, > /Marco > >> Jim >> >> > -- > 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 > > > --=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 --sp7JEXI4EsquoxbAOBJ6QjDDEKfThdL6A-- --0ZbrTf40DBBXD7wmy9t0M6XNYnNhpUepn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl5U/0kACgkQ7iZktA5Y 2kMSVgf7BVDkFr2AhMqs2X+6Aw7rAeELjnuxG4KwI9StWPkhbjQFWzbHC8pN2NP3 7JSXMNfNj91ng8DSFi7A5+rQlZao9mJkodAiEzbuac29SQYNcxTz0UuyLT0xylAD WTDM7fh/2mgDSmzFdPuUVSa2AzL1JqfNqeujh8oo1OkAWNVWG5hUZtX+oKzVBS3W 8H/JaXa3ZPXxpIMOm+OBJeEYUOa5VLV1iL4vGYVNzH0imuo2VFrWOH9jUWCkiK0z USvkbr/3Bupo6F4uIVLO6I7ke454mE/iGVKVxUEar55ZZUmyChEqldIYsABAP0hr Og5d7JcOprkrAf68Py0cRQbVFcnaWw== =vc5G -----END PGP SIGNATURE----- --0ZbrTf40DBBXD7wmy9t0M6XNYnNhpUepn-- From nobody Tue Feb 25 06:10:24 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 ECC113A0D99 for ; Tue, 25 Feb 2020 06:10:22 -0800 (PST) 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 Hhl6-WCayKwe for ; Tue, 25 Feb 2020 06:10:21 -0800 (PST) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (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 6B22A3A0D94 for ; Tue, 25 Feb 2020 06:10:21 -0800 (PST) Received: by mail-vs1-xe29.google.com with SMTP id b79so8028676vsd.9 for ; Tue, 25 Feb 2020 06:10:21 -0800 (PST) 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 :cc; bh=cCiQg+q/Wq1nVGeu5w4ucLfG3qWsFNosaAR6bb93uVs=; b=gL608rJ9HWR+/U6R8Jei9vzS3PXjesQJdtEZ9XHNIXKp5c6AVTDJQzrhuvP6dJja0l U6HqRAemkFt/hcLLm5li5fuIHDXbVKU6107KmV8W7P4yPCp7EsuWfeoWr5xV/J51Vs9k UAkRc7fq3SqkvFBP0pKHFojAyPjBRKyWjytg4SM6yOZL695IquCfyoThfRWkOslMq3M+ SgrOkU48qfiHJ0u5NTFtXEhWNNr0AjMFPiHXdQ45+Ra4NC3BAbkMhDb2RcqG8aIkEAwl rkhDeJxRjL6WEbo4jm6Gmou2T4mz9zlwBI2eYubuVdqkTd6C6G4h54eCgPXDkWps6e+s Jo4g== 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:cc; bh=cCiQg+q/Wq1nVGeu5w4ucLfG3qWsFNosaAR6bb93uVs=; b=ojhbnNRyNZcqan1+Esx77qhqcIRDA6O//fdWDlMCP2M9C/jjGR9Rp4TVG+MjFTirUR 2DgRxsJxj1bMg+X6nTp5UW0JG5NPFQlrzYaVwesqB2/RXZNBsTxAp2ygR7DIO+X3IiXl q4uG0+koSdSVo+otln3QDdh21ayjzy9f4E1NfHqJyqTzgSKLefisopj9oB11nPnDV8tj g8IJ1l+Y4qWAE2WMljOXm/puZ0lg2YnFDNQMcmmJytpaLcin76g/2Mni1vBabaYv9fbi sM9GhvXAhYRrhQVRmwKhZsRZCFto3sASyYVV1zRuuGsS6ebcJB8JqE4SSkFKPP1cX8ce 6Udw== X-Gm-Message-State: APjAAAURds06yVK17gkZaajWa0X3tYmkt1un4nG7w1Ck4HYOTWo3DQiv Ayh+SC6NDJ+LhWIzIY1Jc9G6VS27zd1v66OLn44= X-Google-Smtp-Source: APXvYqxxirbPtkFzNUbLFq69cBTBcKlxSxgqNW/ry1M2RVF3KuFkGdHS6rhNZMNp+T2nWS7YefoF3Yy/0wjoshJi3w4= X-Received: by 2002:a67:fd63:: with SMTP id h3mr31702926vsa.221.1582639820355; Tue, 25 Feb 2020 06:10:20 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Cigdem Sengul Date: Tue, 25 Feb 2020 14:10:10 +0000 Message-ID: To: Hannes Tschofenig Cc: "ace@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004cbf10059f670ce9" Archived-At: Subject: Re: [Ace] draft-ietf-ace-mqtt-tls-profile-03 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, 25 Feb 2020 14:10:23 -0000 --0000000000004cbf10059f670ce9 Content-Type: text/plain; charset="UTF-8" Hello Hannes, We used broker as it is a widely accepted term in the MQTT Community for "server" e.g., majority of the provider would list also a broker implementation to refer to their server implementation. With respect to whether 3.1,1 clients talking to v5, there may be some issues. This is what the spec says: *Non-normative Comment* If the Server distributes Application Messages to Clients at different protocol levels (such as MQTT V3.1.1) which do not support properties or other features provided by this specification, some information in the Application Message can be lost, and applications which depend on this information might not work correctly. The spec also defines a protocol version error message: If the [Client's] Protocol Version [in the CONNECT packet] is not 5 and the Server does not want to accept the CONNECT packet, the Server MAY send a CONNACK packet with Reason Code 0x84 (Unsupported Protocol Version) and then MUST close the Network Connection So, whether a broker provides dual support would depend on the provider. E.g., the Mosquitto broker supports the different protocol versions. Thanks, --Cigdem On Tue, Feb 25, 2020 at 10:01 AM Hannes Tschofenig < Hannes.Tschofenig@arm.com> wrote: > Hi Cigdem, Hi Anthony, Hi Paul, > > Why are you using the term MQTT broker? My understanding of the MQTT spec > is that there are only clients and servers - nothing more. > > Is a MQTT v3.1.1 client able to talk to a MQTT v5 server? Would a MQTT > v3.1.1 client talk to a MQTT v5 client via a server that supports both > v3.1.1 and v5? > > Ciao > Hannes > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --0000000000004cbf10059f670ce9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Hannes,

We used=C2=A0 broker as i= t is a widely accepted term in the MQTT Community for "server" e.= g.,=C2=A0=C2=A0
majority of the provider would list also a broker= implementation to refer to their server implementation.

With respect to whether 3.1,1 clients talking to v5, there may be so= me issues. This is what the spec says:


Non-norm= ative Comment

If the Ser= ver distributes Application Messages to Clients at different protocol level= s (such as MQTT V3.1.1) which do not support properties or other features p= rovided by this specification, some information in the Application Message = can be lost, and applications which depend on this information might not wo= rk correctly.


The spec also defines a protocol version er= ror message:

If the [= Client's] Protocol Version [in the CONNECT packet] is not 5 and the Ser= ver does not want to accept the CONNECT packet, the Server MAY send a CONNA= CK packet with Reason Code 0x84 (Unsupported Protocol Version) and then MUS= T close the Network Connection=C2=A0=C2=A0


So, whether a broker provides dual support would depend on the provider. E= .g., the Mosquitto broker supports the different protocol versions.=C2=A0

Thanks,
--Cigdem

On Tue, Feb 25, 202= 0 at 10:01 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:
Hi Cigdem, Hi Anthony, Hi Paul,

Why are you using the term MQTT broker? My understanding of the MQTT spec i= s that there are only clients and servers - nothing more.

Is a MQTT v3.1.1 client able to talk to a MQTT v5 server? Would a MQTT v3.1= .1 client talk to a MQTT v5 client via a server that supports both v3.1.1 a= nd v5?

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you.

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
--0000000000004cbf10059f670ce9-- From nobody Tue Feb 25 20:38: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 4EA8F3A0C99 for ; Tue, 25 Feb 2020 20:38:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2nq-dNf7r6BR for ; Tue, 25 Feb 2020 20:38:33 -0800 (PST) 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 CAD1B3A0C97 for ; Tue, 25 Feb 2020 20:38:32 -0800 (PST) Received: from Jude (50.224.60.41) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 25 Feb 2020 20:38:23 -0800 From: Jim Schaad To: 'Ace Wg' Date: Tue, 25 Feb 2020 20:38:22 -0800 Message-ID: <025b01d5ec5e$94f85000$bee8f000$@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: AdXsVzWimzIpNHbGTwi1hLO0NkxspA== Content-Language: en-us X-Originating-IP: [50.224.60.41] Archived-At: Subject: [Ace] Jim's Proposal on legal requestor 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, 26 Feb 2020 04:38:34 -0000 I do not seem to have been doing a good job of explaining the issue that I am raising here, so I am going to go scenario based for a description. * I get an access token from an AS with a scope of [ "coap://multicast-01", ["responder"]] * I join the group associated with that address * I then decide to send the message below out encrypted with the group symmetric key and signed with the public key I registered during the join GET coap://multicast-01/resource1 * The server TimeX receives the above message. It starts to process the message by checking the signature - that passes. It then decrypts the message and that succeeds. It then processes the get request because it does not know that this is a violation of the scope assigned to me by the AS. This will not happen for the MQTT profile as long as the AS (singular or plural) are setup correctly as the MQTT broker would not allow the publish operation to occur as it also has the set of operation permissions to enforce. The only way that I know for the server TimeX to enforce the allowable operations is for that information to be propagated along with the signature public key from the KDC to the server. One can create a similar scenario on the other side where a client sends a response when it is only authorized as a "requester". Jim From nobody Tue Feb 25 20:48:53 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 9AB7C3A0CD5 for ; Tue, 25 Feb 2020 20:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 iVHHweltfFx3 for ; Tue, 25 Feb 2020 20:48:50 -0800 (PST) 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 00C143A0CD0 for ; Tue, 25 Feb 2020 20:48:49 -0800 (PST) Received: from Jude (50.224.60.41) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 25 Feb 2020 20:48:40 -0800 From: Jim Schaad To: 'Ace Wg' Date: Tue, 25 Feb 2020 20:48:39 -0800 Message-ID: <025c01d5ec60$051d27b0$0f577710$@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: AdXsX/IbmrqFmhCJSri0/HmrHtF3eQ== Content-Language: en-us X-Originating-IP: [50.224.60.41] Archived-At: Subject: [Ace] Minutes for todays interim posted 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, 26 Feb 2020 04:48:52 -0000 I have posted up the minutes for todays interim https://datatracker.ietf.org/meeting/interim-2020-ace-04/materials/minutes-i nterim-2020-ace-04-202002251100 From nobody Wed Feb 26 05:17:10 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 9B83D3A0A2F for ; Wed, 26 Feb 2020 05:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, 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 nBsU9e3iUf8G for ; Wed, 26 Feb 2020 05:17:06 -0800 (PST) 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 E82B33A0A27 for ; Wed, 26 Feb 2020 05:17:05 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 9CAC338982; Wed, 26 Feb 2020 08:16:03 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A2D5468B; Wed, 26 Feb 2020 08:17:04 -0500 (EST) From: Michael Richardson To: Jim Schaad , ace@ietf.org In-Reply-To: <025b01d5ec5e$94f85000$bee8f000$@augustcellars.com> References: <025b01d5ec5e$94f85000$bee8f000$@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] Jim's Proposal on legal requestor 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, 26 Feb 2020 13:17:09 -0000 --=-=-= Content-Type: text/plain clarifying question. Jim Schaad wrote: > I do not seem to have been doing a good job of explaining the issue > that I am raising here, so I am going to go scenario based for a > description. > (1) I get an access token from an AS with a scope of [ > "coap://multicast-01", ["responder"]] > (2) I join the group associated > with that address > (3) I then decide to send the message below out > encrypted with the group symmetric key and signed with the public key I > registered during the join > GET coap://multicast-01/resource1 ... (I numbered the steps) I believe that (1) was intended to allow you to become a responder for this resource. > It then processes the get request > because it does not know that this is a violation of the scope assigned > to me by the AS. ! > The only way that I know for the server TimeX to enforce the allowable > operations is for that information to be propagated along with the > signature public key from the KDC to the server. One can create a > similar scenario on the other side where a client sends a response when > it is only authorized as a "requester". It seems to me that if the access control to the group is a group-shared symmetric key + asymmetric signature, that each responder requires the list of valid signers. Or, we need LAKE to turn the group key into 1:1. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl5Wb9AACgkQgItw+93Q 3WWZpwf/RFzGcJSeIGG5REqCn6dUhTJmMXR2xdvnxdUMzO/YLPI6wISSUFPvGL9N ifi3Ocz/TJUq/YY9zqfqmUFJ2zEs7XxaTupOjyawEDZ97IBXo62pFG6wBjnNOKHt jHqrgP7wEhSfLqpqlQre+51hYjTy7O2pAYKwsZ6vT9ODRqZd6/zKQtqdMTPRqo/z VTDGo1c27VHlXTh8vWoLOAAxX1a2CcgpBay33cIq3WGuXNEOeARMIraTewtmy7Ny clGW/hT3JdNI//ELDGz+czaNtIUkyuvu67uAAtlJ39m6odKmCIoDzPnMKF9uudLZ BgHN0/DhBSG7hoh6J6hNAkXPcGp7MA== =l34g -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 26 06:08: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 23A3F3A045E for ; Wed, 26 Feb 2020 06:08:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=risecloud.onmicrosoft.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 HmjEtCZwmv0e for ; Wed, 26 Feb 2020 06:08:12 -0800 (PST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2066.outbound.protection.outlook.com [40.107.22.66]) (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 D89593A0529 for ; Wed, 26 Feb 2020 06:08:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XAXXzzpexl6kNWwzrI/ZJ0how21EVAIj3f2t4fwibu24w/f6BqGX+U5DBGudZijg3TiCLPgRWRFlhXX81RD6kvIXxW6dd2H72eXV9nAJEJm6b/AX2IbEd335bavUOgdc5iWaNPIgXUOumvvpE8eGgTcca/3w4sRRgN3TUTEl3y3pw9VC0E56oPNbl/Wszp2OCxC7gpMootTtWcFM8N0dZyyguZDMdrzYxQvjx91sCsYKTS6yYgmSdzDR2IFNrsLtjGb/5BghCWBbp3VLod+M36/p1teFG1GryHLIQKlCq2mYmLOgjVN7KcxXPZL3PjwlIq+6AxpVWei6c1uwu6E5qw== 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=fNWGDG+q9qxLt2wTb0aaHkvf5FVQeGzaLMd6LGuUU0E=; b=ElA3148Tjq4pRLHvmSiorSinQHaz+sFlEQl2dQF/DAEyuM2r3dNJD1u5XbVHfudTMMRTZ0cxUNqGrQ99vhsXIkyv/irceTDYRmtDcglvhsI7frHHark4rgSkbYGsoCu3QElY15s/EVyE39G0iWKjquW9Tf35pX/DCwWVaTKQ7pqflUiACZOC2cAn7yIRLbbmycJpX7WbTGQtZEoAwHpg3rNI/MZM7qTvJoAldD9ZTthPfU4S/A+6nUr7fZvdxY9KzBh3Vemk9tWWY+r4H0+jONnnZ65QK9rqcKKL1MKuH12Iorg2K8juZ1XjmSTpjsCANSaGwsIsp2WEaIRHcvbLkQ== 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=RISEcloud.onmicrosoft.com; s=selector1-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fNWGDG+q9qxLt2wTb0aaHkvf5FVQeGzaLMd6LGuUU0E=; b=Xqr2VtVCK31sz8uC9bCRnWnDpMl1HRUkVTXahR0MItHxv9FvoSm8iU1KXu9Wtx87ptCCJD2TNqp7Ob1ohTLQWxQrMaJA1K0E8Yh4sxm8IC7qBqgk7lFZ/G/lRSfzCpJsvG5h76wPVYVR+AVSDHvNMWUoM9Hrpn9p1JJi6W7NR/M= Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (10.165.195.159) by VI1P189MB0463.EURP189.PROD.OUTLOOK.COM (10.165.195.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.21; Wed, 26 Feb 2020 14:07:58 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::80e4:7dc7:7d4e:c9cb]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::80e4:7dc7:7d4e:c9cb%4]) with mapi id 15.20.2750.021; Wed, 26 Feb 2020 14:07:58 +0000 Received: from [10.8.0.6] (45.12.220.44) by HE1PR0902CA0047.eurprd09.prod.outlook.com (2603:10a6:7:15::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.14 via Frontend Transport; Wed, 26 Feb 2020 14:07:58 +0000 From: Marco Tiloca To: Michael Richardson , Jim Schaad , "ace@ietf.org" Thread-Topic: [Ace] Jim's Proposal on legal requestor Thread-Index: AdXsVzWimzIpNHbGTwi1hLO0NkxspAAT9PYAAAHGCYA= Date: Wed, 26 Feb 2020 14:07:58 +0000 Message-ID: <0c16f230-3471-9215-e0dd-60604a1e1e02@ri.se> References: <025b01d5ec5e$94f85000$bee8f000$@augustcellars.com> <20646.1582723024@localhost> In-Reply-To: <20646.1582723024@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-clientproxiedby: HE1PR0902CA0047.eurprd09.prod.outlook.com (2603:10a6:7:15::36) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) authentication-results: spf=none (sender IP is ) smtp.mailfrom=marco.tiloca@ri.se; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [45.12.220.44] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4907fc1f-cbe0-4e75-cefe-08d7bac54891 x-ms-traffictypediagnostic: VI1P189MB0463: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0325F6C77B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(136003)(346002)(376002)(366004)(189003)(199004)(52116002)(31686004)(6486002)(53546011)(66476007)(66446008)(31696002)(66946007)(86362001)(16526019)(186003)(26005)(66556008)(64756008)(66616009)(956004)(2616005)(5660300002)(478600001)(81156014)(66574012)(2906002)(8936002)(966005)(81166006)(8676002)(44832011)(110136005)(316002)(36756003)(71200400001)(16576012); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P189MB0463; H:VI1P189MB0398.EURP189.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ri.se does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: NpLAgDOzQS1c02TqBfnNpDpFnjhD2IlDQnlj9EfaikU+D0TvP51hCiOfFf/azvKWDIAmDFI94OHWkXg4nRIERvXKrfFizNlamT3E3EAjf4P6UevDzB1vGs/Bn8lJf5rYyDx7Of+vG4hQYIxAThTC/wUUGRZhnwUuijtYM00acVFHxHqzIECNg+koXD+u8fsM13jzTLJO4D2GGHu05V9ySmFgfTNtrRvYDofAWUTW9s0LaEVyN6yRAfTMpU5AsGybZIe4PMKMy4mHDr9Pl4EKOwsYThyJ7Bpul/pVWdudLSi9q05B8tKZwXCpRi+c+N7Wihc1lqROtBJHs6zghBchEhdEaQ1yMCMuP4RZh7coLpEB2G9+izbr0l4D6bg9UGmqNm14Ko6AOtQVhNSOKUQCpONXmOzgj+wToI2SE5h0Pjzma9La6cawIv9lMXf3grBEUHW66TQqQebBO6seb+P9PNs9J+9r7g1NLOCaiZkfzxIE6njRFQUflBD0LLCSKLAe9SiP4ognLO6qkjDMlU4EOw== x-ms-exchange-antispam-messagedata: q+nv9IJK0z85vgnK3DkohmOmlywwxdYOSlP1AtgXyqQzcYb5ZMdvAZNX9/EtKm6RgzHhKgWpY9Ev2qZnxWzPknBzKy8GCs88TnBFZZaC9cuRcdYg3dYxdAnaqUqK7FNcYcNsgjEipZlhLGi25N9Azg== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IWRh5eSXo29bwsCoA9ONw990ioMx7GpEv" MIME-Version: 1.0 X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 4907fc1f-cbe0-4e75-cefe-08d7bac54891 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2020 14:07:58.7761 (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: TkJ62lHve1RnE2x61I5YK6bs9MjMQgX2EtsPjbLOdSaC6WvWAwm9WbwG69YwPGn4L8KYetNkKmP+T4ZAScNlYg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0463 Archived-At: Subject: Re: [Ace] Jim's Proposal on legal requestor 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, 26 Feb 2020 14:08:20 -0000 --IWRh5eSXo29bwsCoA9ONw990ioMx7GpEv Content-Type: multipart/mixed; boundary="3yWxTpEOkhl9ZFborEbxnF880PQ6q4aFx" --3yWxTpEOkhl9ZFborEbxnF880PQ6q4aFx Content-Type: multipart/alternative; boundary="------------9FB5FC3E62D814DEF78E18E2" Content-Language: en-US This is a multi-part message in MIME format. --------------9FB5FC3E62D814DEF78E18E2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi! Jim, I think now I understand your idea and it makes sense to me. Some comments in line below. Best, /Marco On 2020-02-26 14:17, Michael Richardson wrote: > clarifying question. > > Jim Schaad wrote: > > I do not seem to have been doing a good job of explaining the iss= ue > > that I am raising here, so I am going to go scenario based for a > > description. > > > (1) I get an access token from an AS with a scope of [ > > "coap://multicast-01", ["responder"]] > > (2) I join the group associated > > with that address > > (3) I then decide to send the message below out > > encrypted with the group symmetric key and signed with the public= key I > > registered during the join > > > GET coap://multicast-01/resource1 > > .... (I numbered the steps) > I believe that (1) was intended to allow you to become a responder for = this resource. =3D=3D>MT Step (1) is intended to allow access to the group-membership resource at the Group Manager (GM), to get the keying material for communicating in the group. Practically, the roles are currently used only at the GM to determine which public keys is relevant to return to a node upon its joining. <=3D=3D > > > It then processes the get request > > because it does not know that this is a violation of the scope as= signed > > to me by the AS. > > ! =3D=3D>MT As above, the original idea for that scope was to have it applied to the group joining itself and the resource at the GM to access for joining. But I agree that we should inform the other group members of that role, i.e. "allowed to send requests" and/or "allowed to send responses". <=3D=3D > > > The only way that I know for the server TimeX to enforce the allo= wable > > operations is for that information to be propagated along with th= e > > signature public key from the KDC to the server. =20 =3D=3D>MT This can be one more parameter in the Joining Response or in the Public Key Response, when request public keys of group members are included. Together with the array of public keys, we can have a same-ordered array of roles echoing the roles from the scope of the Access Token above. Each element of the array can possibly be an array of roles. How does it sound? <=3D=3D > One can create a > > similar scenario on the other side where a client sends a respons= e when > > it is only authorized as a "requester". =3D=3D>MT Right, if it's "requester"-only. <=3D=3D > It seems to me that if the access control to the group is a group-share= d > symmetric key + asymmetric signature, that each responder requires the = list of valid signers. > Or, we need LAKE to turn the group key into 1:1. =3D=3D>MT What I understand from Jim's proposal is essentially enabling at each group member a list of valid request signers and valid response signers. <=3D=3D =3D=3D>MT Just to complement, this is all fine for this level of "filtering", i.e. "this group member can send requests/responses or not". We have a separate draft at [1], defining a new Group OSCORE profile of ACE, to enforce access control within the group, i.e. to access group members' resources after having joined, i.e. as a group member towards another group member. That is, that profile considers a granularity of exact REST methods and resources, i.e. as fine-grained as ACE can be. Also, it enables having together ACE-based access control and Group OSCORE, which is so far not possible with other profiles. The current version -01 in the datatracker defines a "full mode" where both OSCORE and Group OSCORE are considered as security protocols between Client and RS. We plan to submit soon an updated version, focusing more on a lighter, intended-to-be main mode, that focuses on using only Group OSCORE as security protocol between Client and RS. [1] https://tools.ietf.org/html/draft-tiloca-ace-group-oscore-profile-01 <=3D=3D Best, /Marco > > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =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 --------------9FB5FC3E62D814DEF78E18E2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi!

Jim, I think now I understand your idea and it makes sense to me.
=
Some comments in line below.

Best,
/Marco

On 2020-02-26 14:17, Michael Richardso= n wrote:
clarifying question.

Jim Schaad <ietf@augustcellars.com> wrote:
    > I do not seem to have been doing a good job of explaining the is=
sue
    > that I am raising here, so I am going to go scenario based for a=

    > description.

    > (1) I get an access token from an AS with a scope of [
    > "coap://multicast-01", ["responder"]]
    > (2) I join the group associated
    > with that address
    > (3) I then decide to send the message below out
    > encrypted with the group symmetric key and signed with the publi=
c key I
    > registered during the join

    >    GET coap://multicast-01/resource1

=2E... (I numbered the steps)
I believe that (1) was intended to allow you to become a responder for th=
is resource.

=3D=3D>MT
Step (1) is intended to allow access to the group-membership resource at the Group Manager (GM), to get the keying material for communicating in the group.

Practically, the roles are currently used only at the GM to determine which public keys is relevant to return to a node upon its joining.
<=3D=3D


    > It then processes the get request
    > because it does not know that this is a violation of the scope a=
ssigned
    > to me by the AS.

!

=3D=3D>MT
As above, the original idea for that scope was to have it applied to the group joining itself and the resource at the GM to access for joining.

But I agree that we should inform the other group members of that role, i.e. "allowed to send requests" and/or "allowed to send responses".
<=3D=3D


    > The only way that I know for the server TimeX to enforce the all=
owable
    > operations is for that information to be propagated along with t=
he
    > signature public key from the KDC to the server.

=3D=3D>MT
This can be one more parameter in the Joining Response or in the Public Key Response, when request public keys of group members are included.

Together with the array of public keys, we can have a same-ordered array of roles echoing the roles from the scope of the Access Token above. Each element of the array can possibly be an array of roles.
How does it sound?
<=3D=3D

One can create a
    > similar scenario on the other side where a client sends a respon=
se when
    > it is only authorized as a "requester".

=3D=3D>MT
Right, if it's "requester"-only.
<=3D=3D

It seems to me that if the access control to the group is a group-shared
symmetric key + asymmetric signature, that each responder requires the li=
st of valid signers.
Or, we need LAKE to turn the group key into 1:1.

=3D=3D>MT
What I understand from Jim's proposal is essentially enabling at each group member a list of valid request signers and valid response signers.
<=3D=3D


=3D=3D>MT
Just to complement, this is all fine for this level of "filtering", i.e. "this group member can send requests/responses or not".

We have a separate draft at [1], defining a new Group OSCORE profile of ACE, to enforce access control within the group, i.e. to access group members' resources after having joined, i.e. as a group member towards another group member.

That is, that profile considers a granularity of exact REST methods and resources, i.e. as fine-grained as ACE can be. Also, it enables having together ACE-based access control and Group OSCORE, which is so far not possible with other profiles.

The current version -01 in the datatracker defines a "full mode" where both OSCORE and Group OSCORE are considered as security protocols between Client and RS. We plan to submit soon an updated version, focusing more on a lighter, intended-to-be main mode, that focuses on using only Group OSCORE as security protocol between Client and RS.

[1] https://tools.ietf.org/html/d= raft-tiloca-ace-group-oscore-profile-01
<=3D=3D

Best,
/Marco


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software =
Works
 -=3D IPv6 IoT consulting =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
--------------9FB5FC3E62D814DEF78E18E2-- --3yWxTpEOkhl9ZFborEbxnF880PQ6q4aFx-- --IWRh5eSXo29bwsCoA9ONw990ioMx7GpEv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl5We7cACgkQ7iZktA5Y 2kOYDwf/dz7FJtVhbNDYLWPV/fsyJGVuNghyp/zxgnC/QAp3i71XpAF+4qKjNmzr hi8Q14RIkaiysOuv9hrlNY41Gx442Z+Q/0oYmAUvsFLPBkmjBc7LcQ5UMceAOnvm IsHlTSz+9KUTFbzm+1rD4Rjc8SePUukim/QsfZ4c6SVoCjUHscL611yG+JT/uZrp 6MiDC+fhwYmynIBZuqDwwnK+ht0kjcu127fOvZ6zNL4W/DS2EUOLAcOhzMJ0jqCC /JJTccJPkfg3e+b2kXG4VZbggIO/pPztuB9ydMTQVkNi2FYbh1NZE8z36PZyz5YP +BVIE6sQkebClxQZoHeTc6rNQwzp9w== =yWEX -----END PGP SIGNATURE----- --IWRh5eSXo29bwsCoA9ONw990ioMx7GpEv-- From nobody Wed Feb 26 07:44:24 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 AA5973A0928 for ; Wed, 26 Feb 2020 07:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 yIzIEAJPt5Nv for ; Wed, 26 Feb 2020 07:44:17 -0800 (PST) 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 A122B3A0908 for ; Wed, 26 Feb 2020 07:44:17 -0800 (PST) Received: from Jude (50.224.60.41) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 26 Feb 2020 07:44:07 -0800 From: Jim Schaad To: 'Michael Richardson' , References: <025b01d5ec5e$94f85000$bee8f000$@augustcellars.com> <20646.1582723024@localhost> In-Reply-To: <20646.1582723024@localhost> Date: Wed, 26 Feb 2020 07:44:05 -0800 Message-ID: <028d01d5ecbb$9561c5f0$c02551d0$@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: AQHTIEb0x0somJcsjEup8+Yfh5OiXwJDpYxRqCEYIZA= Content-Language: en-us X-Originating-IP: [50.224.60.41] Archived-At: Subject: Re: [Ace] Jim's Proposal on legal requestor 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, 26 Feb 2020 15:44:23 -0000 -----Original Message----- From: Ace On Behalf Of Michael Richardson Sent: Wednesday, February 26, 2020 5:17 AM To: Jim Schaad ; ace@ietf.org Subject: Re: [Ace] Jim's Proposal on legal requestor clarifying question. Jim Schaad wrote: > I do not seem to have been doing a good job of explaining the issue > that I am raising here, so I am going to go scenario based for a > description. > (1) I get an access token from an AS with a scope of [ > "coap://multicast-01", ["responder"]] > (2) I join the group associated > with that address > (3) I then decide to send the message below out > encrypted with the group symmetric key and signed with the public key I > registered during the join > GET coap://multicast-01/resource1 .... (I numbered the steps) I believe that (1) was intended to allow you to become a responder for this resource. [JLS] Yes > It then processes the get request > because it does not know that this is a violation of the scope assigned > to me by the AS. ! > The only way that I know for the server TimeX to enforce the allowable > operations is for that information to be propagated along with the > signature public key from the KDC to the server. One can create a > similar scenario on the other side where a client sends a response when > it is only authorized as a "requester". It seems to me that if the access control to the group is a group-shared symmetric key + asymmetric signature, that each responder requires the list of valid signers. Or, we need LAKE to turn the group key into 1:1. [JLS] Having the list of valid signers in not in itself sufficient as both requests and responses are going to be signed so you know who sent the message and the fact that they are on the legal list. Doing the turn the group key into 1:1 doesn't work if you want to do a multicast request, as that would end up being all unicast. Jim -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- From nobody Wed Feb 26 09:59: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 040E93A0EFC for ; Wed, 26 Feb 2020 09:59:35 -0800 (PST) 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 NXwY4TlnVjIg for ; Wed, 26 Feb 2020 09:59:32 -0800 (PST) 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 44EC73A0EA7 for ; Wed, 26 Feb 2020 09:59:32 -0800 (PST) Received: from Jude (50.224.60.41) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 26 Feb 2020 09:59:22 -0800 From: Jim Schaad To: 'Marco Tiloca' , References: <025b01d5ec5e$94f85000$bee8f000$@augustcellars.com> <20646.1582723024@localhost> <0c16f230-3471-9215-e0dd-60604a1e1e02@ri.se> In-Reply-To: <0c16f230-3471-9215-e0dd-60604a1e1e02@ri.se> Date: Wed, 26 Feb 2020 09:59:21 -0800 Message-ID: <02b001d5ecce$7aa32cf0$6fe986d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02B1_01D5EC8B.6C812570" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHTIEb0x0somJcsjEup8+Yfh5OiXwJDpYxRAphcHmqoDFakwA== Content-Language: en-us X-Originating-IP: [50.224.60.41] Archived-At: Subject: Re: [Ace] Jim's Proposal on legal requestor 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, 26 Feb 2020 17:59:35 -0000 ------=_NextPart_000_02B1_01D5EC8B.6C812570 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Ace On Behalf Of Marco Tiloca Sent: Wednesday, February 26, 2020 6:08 AM To: Michael Richardson ; Jim Schaad = ; ace@ietf.org Subject: Re: [Ace] Jim's Proposal on legal requestor =20 Hi! Jim, I think now I understand your idea and it makes sense to me. Some comments in line below. Best, /Marco On 2020-02-26 14:17, Michael Richardson wrote: =20 clarifying question. =20 Jim Schaad = wrote: > I do not seem to have been doing a good job of explaining the = issue > that I am raising here, so I am going to go scenario based for a > description. =20 > (1) I get an access token from an AS with a scope of [ > "coap://multicast-01", ["responder"]] > (2) I join the group associated > with that address > (3) I then decide to send the message below out > encrypted with the group symmetric key and signed with the public = key I > registered during the join =20 > GET coap://multicast-01/resource1 =20 .... (I numbered the steps) I believe that (1) was intended to allow you to become a responder for = this resource. =3D=3D>MT Step (1) is intended to allow access to the group-membership resource at = the Group Manager (GM), to get the keying material for communicating in = the group. Practically, the roles are currently used only at the GM to determine = which public keys is relevant to return to a node upon its joining. <=3D=3D [JLS] When implies that the only roles of interest are = =E2=80=9Cmonitor=E2=80=9D vs not =E2=80=9Cmonitor=E2=80=9D. =20 =20 > It then processes the get request > because it does not know that this is a violation of the scope = assigned > to me by the AS. =20 ! =3D=3D>MT As above, the original idea for that scope was to have it applied to the = group joining itself and the resource at the GM to access for joining. But I agree that we should inform the other group members of that role, = i.e. "allowed to send requests" and/or "allowed to send responses". <=3D=3D =20 =20 > The only way that I know for the server TimeX to enforce the = allowable > operations is for that information to be propagated along with the > signature public key from the KDC to the server. =20 =3D=3D>MT This can be one more parameter in the Joining Response or in the Public = Key Response, when request public keys of group members are included. Together with the array of public keys, we can have a same-ordered array = of roles echoing the roles from the scope of the Access Token above. = Each element of the array can possibly be an array of roles. How does it sound? <=3D=3D [JLS] Yes this makes sense. The only potential issue is what happens if = the set of roles becomes in some sense unbounded for an application. = However, in that case I would expect that the list of roles would be = known to the joining clients. The one thing that comes up here is = should there be a compression of these values since we are sending them = to a larger group of people. One can create a > similar scenario on the other side where a client sends a response = when > it is only authorized as a "requester". =3D=3D>MT Right, if it's "requester"-only. <=3D=3D =20 It seems to me that if the access control to the group is a group-shared symmetric key + asymmetric signature, that each responder requires the = list of valid signers. Or, we need LAKE to turn the group key into 1:1. =3D=3D>MT What I understand from Jim's proposal is essentially enabling at each = group member a list of valid request signers and valid response signers. <=3D=3D =3D=3D>MT Just to complement, this is all fine for this level of "filtering", i.e. = "this group member can send requests/responses or not". We have a separate draft at [1], defining a new Group OSCORE profile of = ACE, to enforce access control within the group, i.e. to access group = members' resources after having joined, i.e. as a group member towards = another group member. That is, that profile considers a granularity of exact REST methods and = resources, i.e. as fine-grained as ACE can be. Also, it enables having = together ACE-based access control and Group OSCORE, which is so far not = possible with other profiles. The current version -01 in the datatracker defines a "full mode" where = both OSCORE and Group OSCORE are considered as security protocols = between Client and RS. We plan to submit soon an updated version, = focusing more on a lighter, intended-to-be main mode, that focuses on = using only Group OSCORE as security protocol between Client and RS. [1] https://tools.ietf.org/html/draft-tiloca-ace-group-oscore-profile-01 <=3D=3D Best, /Marco =20 =20 -- Michael Richardson = , Sandelman Software Works -=3D IPv6 IoT consulting =3D- =20 =20 =20 _______________________________________________ Ace mailing list Ace@ietf.org =20 https://www.ietf.org/mailman/listinfo/ace --=20 Marco Tiloca Ph.D., Senior Researcher =20 RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) =20 Phone: +46 (0)70 60 46 501 https://www.ri.se ------=_NextPart_000_02B1_01D5EC8B.6C812570 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From: Ace = <ace-bounces@ietf.org> On Behalf Of Marco = Tiloca
Sent: Wednesday, February 26, 2020 6:08 = AM
To: Michael Richardson <mcr+ietf@sandelman.ca>; Jim = Schaad <ietf@augustcellars.com>; ace@ietf.org
Subject: = Re: [Ace] Jim's Proposal on legal requestor

 

Hi!

Jim, I think now I understand = your idea and it makes sense to me.

Some comments in line = below.

Best,
/Marco

On = 2020-02-26 14:17, Michael Richardson = wrote:

 
clarifying =
question.
 
Jim Schaad <ietf@augustcellars.com>=
 wrote:
=C2=A0=C2=A0=C2=A0 > I do not seem to =
have been doing a good job of explaining the =
issue
=C2=A0=C2=A0=C2=A0 > that I am raising =
here, so I am going to go scenario based for =
a
=C2=A0=C2=A0=C2=A0 > =
description.
 
=C2=A0=C2=A0=
=C2=A0 > (1) I get an access token from an AS with a scope of =
[
=C2=A0=C2=A0=C2=A0 > =
"coap://multicast-01", =
["responder"]]
=C2=A0=C2=A0=C2=A0 > =
(2) I join the group associated
=C2=A0=C2=A0=C2=A0 =
> with that address
=C2=A0=C2=A0=C2=A0 > (3) =
I then decide to send the message below =
out
=C2=A0=C2=A0=C2=A0 > encrypted with the =
group symmetric key and signed with the public key =
I
=C2=A0=C2=A0=C2=A0 > registered during the =
join
 
=C2=A0=C2=A0=C2=A0 =
>=C2=A0=C2=A0=C2=A0 GET =
coap://multicast-01/resource1
 
.... (I numbered the steps)
I believe that =
(1) was intended to allow you to become a responder for this =
resource.


=3D=3D>MT
Step (1) is intended to allow = access to the group-membership resource at the Group Manager (GM), to = get the keying material for communicating in the = group.

Practically, the roles are currently used only at the GM = to determine which public keys is relevant to return to a node upon its = joining.
<=3D=3D

[JLS] When = implies that the only roles of interest are =E2=80=9Cmonitor=E2=80=9D vs = not =E2=80=9Cmonitor=E2=80=9D.




 
 
=C2=A0=C2=A0=C2=A0 > It then =
processes the get request
=C2=A0=C2=A0=C2=A0 > =
because it does not know that this is a violation of the scope =
assigned
=C2=A0=C2=A0=C2=A0 > to me by the =
AS.
 
!

=3D=3D>MT
As above, the =
original idea for that scope was to have it applied to the group joining =
itself and the resource at the GM to access for joining.

But I =
agree that we should inform the other group members of that role, i.e. =
"allowed to send requests" and/or "allowed to send =
responses".
<=3D=3D


 
 
=C2=A0=C2=A0=C2=A0 > The only way =
that I know for the server TimeX to enforce the =
allowable
=C2=A0=C2=A0=C2=A0 > operations is for =
that information to be propagated along with =
the
=C2=A0=C2=A0=C2=A0 > signature public key =
from the KDC to the server.=C2=A0 

=3D=3D>MT
This can be one more parameter in =
the Joining Response or in the Public Key Response, when request public =
keys of group members are included.

Together with the array of =
public keys, we can have a same-ordered array of roles echoing the roles =
from the scope of the Access Token above. Each element of the array can =
possibly be an array of roles.

How does it =
sound?
<=3D=3D
[JLS] Yes this makes sense.=C2=A0 The only =
potential issue is what happens if the set of roles becomes in some =
sense unbounded for an application.=C2=A0 However, in that case I would =
expect that the list of roles would be known to the joining =
clients.=C2=A0 The one thing that comes up here is should there be a =
compression of these values since we are sending them to a larger group =
of people.

One can create =
a
=C2=A0=C2=A0=C2=A0 > similar scenario on the =
other side where a client sends a response =
when
=C2=A0=C2=A0=C2=A0 > it is only authorized =
as a "requester".

=3D=3D>MT
Right, if it's =
"requester"-only.
<=3D=3D


 
It seems to me that if the access control to the group is a =
group-shared
symmetric key + asymmetric signature, =
that each responder requires the list of valid =
signers.
Or, we need LAKE to turn the group key =
into 1:1.


=3D=3D>MT
What I understand from Jim's = proposal is essentially enabling at each group member a list of valid = request signers and valid response = signers.
<=3D=3D


=3D=3D>MT
Just to complement, = this is all fine for this level of "filtering", i.e. = "this group member can send requests/responses or = not".

We have a separate draft at [1], defining a new Group = OSCORE profile of ACE, to enforce access control within the group, i.e. = to access group members' resources after having joined, i.e. as a group = member towards another group member.

That is, that profile = considers a granularity of exact REST methods and resources, i.e. as = fine-grained as ACE can be. Also, it enables having together ACE-based = access control and Group OSCORE, which is so far not possible with other = profiles.

The current version -01 in the datatracker defines a = "full mode" where both OSCORE and Group OSCORE are considered = as security protocols between Client and RS. We plan to submit soon an = updated version, focusing more on a lighter, intended-to-be main mode, = that focuses on using only Group OSCORE as security protocol between = Client and RS.

[1] https://tools.ietf.org/html/draft-tiloca-ace-group-oscore-profile-01=
<=3D=3D

Best,
/Marco


 
 
--
Michael =
Richardson <mcr+IETF@sandelman.ca>, =
Sandelman Software Works
 -=3D IPv6 IoT consulting =
=3D-
 
 
 


___________________________=
____________________
Ace mailing =
list
Ace@ietf.org
https://www.ietf.org/m=
ailman/listinfo/ace


-- =

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
------=_NextPart_000_02B1_01D5EC8B.6C812570-- From nobody Thu Feb 27 01:35: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 5530D3A166E for ; Thu, 27 Feb 2020 01:35:00 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=s1Xq04xV; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=s1Xq04xV Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zq4qynif-rZv for ; Thu, 27 Feb 2020 01:34:58 -0800 (PST) Received: from FRA01-MR2-obe.outbound.protection.outlook.com (mail-eopbgr90070.outbound.protection.outlook.com [40.107.9.70]) (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 B10AD3A1666 for ; Thu, 27 Feb 2020 01:34:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vJbtPdN5VVZk1ewGDhVzunrtVk0rUpZ7KGUusyXxzZM=; b=s1Xq04xVejMtXb7I2x5ax7VAjMfJhFa3qDST9VhvQZkkJTpK2xJtdr61nnbdbGN1oUjmnhsfEvlklKpbMM7wjNV27K+cx9EAGe4xwG0Ib/K5CSBh25HXyk19UL5V5hV/3p9b4fhh0uIqXRDUkeXArgHKnPTNOldHzFk3S2nC8no= Received: from VI1PR0802CA0032.eurprd08.prod.outlook.com (2603:10a6:800:a9::18) by PR2PR08MB4810.eurprd08.prod.outlook.com (2603:10a6:101:17::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.22; Thu, 27 Feb 2020 09:34:54 +0000 Received: from VE1EUR03FT051.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e09::201) by VI1PR0802CA0032.outlook.office365.com (2603:10a6:800:a9::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.15 via Frontend Transport; Thu, 27 Feb 2020 09:34:54 +0000 Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT051.mail.protection.outlook.com (10.152.19.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.15 via Frontend Transport; Thu, 27 Feb 2020 09:34:54 +0000 Received: ("Tessian outbound 1f9bda537fdc:v42"); Thu, 27 Feb 2020 09:34:54 +0000 X-CR-MTA-TID: 64aa7808 Received: from 8ccf925f30e7.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id D2562B0F-1ACB-4146-8F11-AFBE72AF1A55.1; Thu, 27 Feb 2020 09:34:49 +0000 Received: from EUR04-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 8ccf925f30e7.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 27 Feb 2020 09:34:49 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jxlbgsiMaKwc+FmXYHxk17/UQaryiVreaqW4c503grElETHQDAzwdqhYKMJ3a0HSeutqOBFr9nY6NY6d8FlpE488NT2a76DMTqj7AR0a01H775j/74gW8S/F01glWjx0wS4HiTUqXyo0MOWVXU+EUUimfeCOjPwHJfhpsF256DkEaVjVUrHhkbXMOdupmHgKDSEUElZ6uNSFlX4S2obEtn0lQbNVjSdvEriBiLAOSp/gtQnGBadi8Z7U8C0T9AR6A8joVx5HOZiTKh8/KCEQ6P0A4yA6aujeT6zFQ+XiATIlOttOHwwuYGcPnBTSRGsrwuEEzX2SquQLyGJVYfiwgw== 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=vJbtPdN5VVZk1ewGDhVzunrtVk0rUpZ7KGUusyXxzZM=; b=dc40CRoS5EDxgtU3vnuE1pLAoslLBVvA6Y61klguX8ib96suXxPExjl+uIHbFr227heUUG5eXeI+2metyswCdgI1C1BBLyGbRYg1Z9IKfGTQg86/HegEdE9/E0L1Yga3CAEHWAx4KSCI1KUZ9PFk/Xqx3LXAdWWXcNRDMTC2VTuMjjD5fWdel76pu3GWKd95auqS5FxPNEPExr8E9ViMQlOug9YVBQnSA86Kz4qnMXm7QQILh3VFtzHHXa88aEEaesGtsrC9CZ8rsIAThyJd32RlSWCZI6LOT3y2USarIgbtfY1+Dt1dgn2B/ymuxxwWuL7Gu4UC299OoJy8/qT15w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vJbtPdN5VVZk1ewGDhVzunrtVk0rUpZ7KGUusyXxzZM=; b=s1Xq04xVejMtXb7I2x5ax7VAjMfJhFa3qDST9VhvQZkkJTpK2xJtdr61nnbdbGN1oUjmnhsfEvlklKpbMM7wjNV27K+cx9EAGe4xwG0Ib/K5CSBh25HXyk19UL5V5hV/3p9b4fhh0uIqXRDUkeXArgHKnPTNOldHzFk3S2nC8no= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (20.178.23.205) by AM0PR08MB4451.eurprd08.prod.outlook.com (20.179.34.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.15; Thu, 27 Feb 2020 09:34:48 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::2159:870b:25df:e612]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::2159:870b:25df:e612%5]) with mapi id 15.20.2772.012; Thu, 27 Feb 2020 09:34:48 +0000 From: Hannes Tschofenig To: "ace@ietf.org" Thread-Topic: Virtual Interim Meeting for the PoP Discussion Thread-Index: AdXsyMgbOEQddn8uSq61fh+IFqH9YgAiBnpA Date: Thu, 27 Feb 2020 09:34:48 +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-ts-tracking-id: 37412198-a6e5-48e1-b8a4-bd288e994e94.1 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [156.67.195.207] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: f44eba54-e7f2-404f-329f-08d7bb684d88 X-MS-TrafficTypeDiagnostic: AM0PR08MB4451:|PR2PR08MB4810: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:8882;OLM:8882; x-forefront-prvs: 03264AEA72 X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(346002)(376002)(39850400004)(396003)(366004)(136003)(199004)(189003)(66946007)(76116006)(66556008)(64756008)(66576008)(52536014)(66446008)(16799955002)(66476007)(86362001)(81166006)(8936002)(6506007)(8676002)(81156014)(53546011)(478600001)(9686003)(6916009)(71200400001)(26005)(186003)(316002)(2906002)(55016002)(7696005)(966005)(5660300002)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR08MB4451; H:AM0PR08MB3716.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: LehWgfXovAzRt+GOHYRz7yRlh4I+1VziRZdEBo6qN9yEvq0cmSxGdxBlVsezG+mFA9o9NH1e16U9zi7Cymg1fRU/mgQ1kHx17eV3mJ5eEPeWSQmZ7Bm5UFYFdiWhbUhh73AQ8uj82cui5/BTKbgI49N6kAeLiTHIGVsNRIePKLPluTl7RtFsoQKUsNRSG7D4sseH2Oe3OZz4nY22h7ulSfis1DqZuXEhBRt1xpqXtSOVRiu+02CmNIgfpUgTNRIh6uc+dQ5IsrpFfRIgUzDib0xrX4UnOh8aqteLENSMTWtLb++mq8Q93t9+rdOYGaRrYNNUtuZZ7VvN3VAIzDVg+vKjfEXrKVvSs+8FOjXWhw9AaDyftRBiTvF3SAor3Xgqn4YmVwvs8VimgqEDNOQfTMvx/fvaf8yEDG16we/FiPFwiqkcx/g+x4Z4kREFZz29AtsNoFJQk90wq8g0DucK8K/nZYLirzKs1YEH+dHqm9aqjvt3OOUuPCsIykGAU/TpHVdsiSu4iig8/f/qEkTBVw== x-ms-exchange-antispam-messagedata: Zp5jhdFP4/y4DSL5+1Dsdy3RvJIf/UFd68BfaAPPRuWkJAaV11Xuw9/Es4+oXL9gDe5tfVo4IwyIXfZ74QwWt1JsFpgQYa+XjguBNR6sPjO08NsFOP9CNLYXdC6it01f72CyPUvT7Kcnvw/tutkx2g== x-ms-exchange-transport-forked: True Content-Type: multipart/mixed; boundary="_005_AM0PR08MB3716EE3BB7DFB66980E1AEC4FAEB0AM0PR08MB3716eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4451 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT051.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; IPV:CAL; SCL:-1; CTRY:IE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(39850400004)(396003)(346002)(376002)(136003)(189003)(199004)(36906005)(316002)(81156014)(8676002)(356004)(8936002)(81166006)(33656002)(45080400002)(53546011)(478600001)(186003)(26826003)(6506007)(2906002)(966005)(26005)(235185007)(6916009)(21480400003)(336012)(70586007)(5660300002)(16799955002)(52536014)(66576008)(70206006)(55016002)(9686003)(86362001)(7696005); DIR:OUT; SFP:1101; SCL:1; SRVR:PR2PR08MB4810; H:64aa7808-outbound-1.mta.getcheckrecipient.com; FPR:; SPF:Pass; LANG:en; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; MX:1; A:1; X-MS-Office365-Filtering-Correlation-Id-Prvs: e7469d6e-ee1c-421e-3c3b-08d7bb68498c X-Forefront-PRVS: 03264AEA72 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ChiX/HoN8Q6FgFRKmxm294OQ8ImMLTUtTK3o6XZ1QI4/8GXP1d+MSRzkFSgxa4QGabIKyESebYRwVeWd+QisGmdpVnlgPrJlPgkJObpM/EPtTDtunE5xP9EgEUUQhbCiB0ev/8tDQBmLilQkZrn7mhsK4y6MMNhN9GS1yr4IkEHdemtTKutcP1/RpwCccOuqIUAD8t9S1ulosfZh9zZ8T/FcfH1QZZ4plC+B8l04b/wuKCya1ZqeGDRLr4Huc8td2vN1USaxIOdwvcXM8eF9pYavt9dEh/OHASoNGMf9zOLJJ/45dSMVb1xfK9lTCGKg1eeB14H7vfYoVgo1iNscIyCqzUH53L7j66f8tI9+vDjtod+Oq54FijMl2MVPrcx28v14SDf/MqzDNTFYW2shfaJ34w5kIkiWw3utIs9UOYzx03MWFXtHtziUNdvnGymllWzo98P3jo7CJMeRoKsUMKsBrKynkk6ETSVzoqjnD169VnCIZbbx1GiD6SkVleRbmpS913+PYftMfsIqC3K3ug== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Feb 2020 09:34:54.6387 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f44eba54-e7f2-404f-329f-08d7bb684d88 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR2PR08MB4810 Archived-At: Subject: [Ace] FW: Virtual Interim Meeting for the PoP Discussion 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, 27 Feb 2020 09:35:00 -0000 --_005_AM0PR08MB3716EE3BB7DFB66980E1AEC4FAEB0AM0PR08MB3716eurp_ Content-Type: multipart/alternative; boundary="_000_AM0PR08MB3716EE3BB7DFB66980E1AEC4FAEB0AM0PR08MB3716eurp_" --_000_AM0PR08MB3716EE3BB7DFB66980E1AEC4FAEB0AM0PR08MB3716eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This virtual interim meeting could be of interest to you if you care about = getting access tokens using HTTP from the AS for use with some IoT protocol= with the RS. Some time ago we made the agreement that ACE would define the non-HTTP tran= sports of information related to PoP tokens while OAuth focuses on the HTTP= -based transport. From: OAuth On Behalf Of Hannes Tschofenig Sent: Wednesday, February 26, 2020 6:22 PM To: oauth Subject: [OAUTH-WG] Virtual Interim Meeting for the PoP Discussion Hi all, Here are the details for the virtual interim meeting to discuss the proof-o= f-possession tokens. Date: March, 9th Time: 6:00 PM - 7:30 PM Monday, (UTC+01:00) Amsterdam, Berlin, Bern, Rome, = Stockholm, Vienna Meeting number (access code): 641 458 628 Meeting password: BWsAF9rT Webex link: https://ietf.webex.com/ietf/j.php?MTID=3Dm03e9c040f9cd66650e1663f1da17d294 Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_AM0PR08MB3716EE3BB7DFB66980E1AEC4FAEB0AM0PR08MB3716eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This virtual interim meeting could be of interest to= you if you care about getting access tokens using HTTP from the AS for use= with some IoT protocol with the RS.

 

Some time ago we made the agreement that ACE would d= efine the non-HTTP transports of information related to PoP tokens while OA= uth focuses on the HTTP-based transport.

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of Hannes Tschofenig
Sent: Wednesday, February 26, 2020 6:22 PM
To: oauth <oauth@ietf.org>
Subject: [OAUTH-WG] Virtual Interim Meeting for the PoP Discussion

 

Hi all,

 

Here are the details for the virtual interim meet= ing to discuss the proof-of-possession tokens.

 

Date: March, 9th

Time: 6:00 PM - 7:30 PM Monday, (UTC+01:= 00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna

 

Meeting number (access = code): 641 458 628

Meeting password: BWsAF= 9rT

 

Webex link:

https://ietf.webex.com/ietf/j.php?MTI= D=3Dm03e9c040f9cd66650e1663f1da17d294

 

Ciao

Hannes

IMPORTANT NOTICE: The contents of this email and any= attachments are confidential and may also be privileged. If you are not th= e intended recipient, please notify the sender immediately and do not discl= ose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Th= ank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_AM0PR08MB3716EE3BB7DFB66980E1AEC4FAEB0AM0PR08MB3716eurp_-- --_005_AM0PR08MB3716EE3BB7DFB66980E1AEC4FAEB0AM0PR08MB3716eurp_ Content-Type: text/calendar; name="Webex_Meeting_OAuth_Virtual_InterimMeeting_9March.ics" Content-Description: Webex_Meeting_OAuth_Virtual_InterimMeeting_9March.ics Content-Disposition: attachment; filename="Webex_Meeting_OAuth_Virtual_InterimMeeting_9March.ics"; size=6784; creation-date="Wed, 26 Feb 2020 17:21:30 GMT"; modification-date="Wed, 26 Feb 2020 17:19:08 GMT" Content-ID: Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkV1cm9wZS9CZXJsaW4NClRaVVJMOmh0dHA6Ly90enVybC5vcmcvem9uZWlu Zm8tb3V0bG9vay9FdXJvcGUvQmVybGluDQpYLUxJQy1MT0NBVElPTjpFdXJvcGUvQmVybGluDQpC RUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOiswMTAwDQpUWk9GRlNFVFRPOiswMjAwDQpUWk5B TUU6Q0VTVA0KRFRTVEFSVDoxOTcwMDMyOVQwMjAwMDANClJSVUxFOkZSRVE9WUVBUkxZO0JZTU9O VEg9MztCWURBWT0tMVNVDQpFTkQ6REFZTElHSFQNCkJFR0lOOlNUQU5EQVJEDQpUWk9GRlNFVEZS T006KzAyMDANClRaT0ZGU0VUVE86KzAxMDANClRaTkFNRTpDRVQNCkRUU1RBUlQ6MTk3MDEwMjVU MDMwMDAwDQpSUlVMRTpGUkVRPVlFQVJMWTtCWU1PTlRIPTEwO0JZREFZPS0xU1UNCkVORDpTVEFO REFSRA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpEVFNUQU1QOjIwMjAwMjI2VDE3MDgz MVoNCkFUVEVOREVFO0NOPSIiO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1JTVlA9VFJVRTpNQUlMVE86 aGFubmVzLnRzY2hvZmVuaWdAYXJtLmNvbQ0KT1JHQU5JWkVSO0NOPSJXZWIgQXV0aG9yaXphdGlv biBQcm90b2NvbCBXb3JraW5nIEdyb3VwIjpNQUlMVE86b2F1dGgtY2hhaXJzQGlldGYub3JnDQpE VFNUQVJUO1RaSUQ9RXVyb3BlL0JlcmxpbjoyMDIwMDMwOVQxODAwMDANCkRURU5EO1RaSUQ9RXVy b3BlL0JlcmxpbjoyMDIwMDMwOVQxOTMwMDANCkxPQ0FUSU9OOmh0dHBzOi8vaWV0Zi53ZWJleC5j b20vaWV0Zi9qLnBocD9NVElEPW0wM2U5YzA0MGY5Y2Q2NjY1MGUxNjYzZjFkYTE3ZDI5NA0KVFJB TlNQOk9QQVFVRQ0KU0VRVUVOQ0U6MTU4MjczNjkxMQ0KVUlEOjIwNDVkMzU3LWZlNzgtNDkwYS1i OTA0LTU2MGRjN2FlMzYwMg0KREVTQ1JJUFRJT046XG5cblxuXG5KT0lOIFdFQkVYIE1FRVRJTkdc bmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW0wM2U5YzA0MGY5Y2Q2NjY1 MGUxNjYzZjFkYTE3ZDI5NFxuTWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogNjQxIDQ1OCA2 MjhcblxuXG5NZWV0aW5nIHBhc3N3b3JkOiBCV3NBRjlyVFxuXG5cblxuSk9JTiBCWSBQSE9ORVxu MS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKVxuVGFwIGhlcmUg dG8gY2FsbCAobW9iaWxlIHBob25lcyBvbmx5LCBob3N0cyBub3Qgc3VwcG9ydGVkKTogdGVsOiUy QjEtNjUwLTQ3OS0zMjA4LCwqMDEqNjQxNDU4NjI4JTIzJTIzKjAxKlxuXG5cblxuSk9JTiBGUk9N IEEgVklERU8gU1lTVEVNIE9SIEFQUExJQ0FUSU9OXG5EaWFsIHNpcDo2NDE0NTg2MjhAaWV0Zi53 ZWJleC5jb21cbllvdSBjYW4gYWxzbyBkaWFsIDE3My4yNDMuMi42OCBhbmQgZW50ZXIgeW91ciBt ZWV0aW5nIG51bWJlci5cblxuXG5Kb2luIHVzaW5nIE1pY3Jvc29mdCBMeW5jIG9yIE1pY3Jvc29m dCBTa3lwZSBmb3IgQnVzaW5lc3NcbkRpYWwgc2lwOjY0MTQ1ODYyOC5pZXRmQGx5bmMud2ViZXgu Y29tXG5cblxuXG5DYW4ndCBqb2luIHRoZSBtZWV0aW5nP1xuaHR0cHM6Ly9jb2xsYWJvcmF0aW9u aGVscC5jaXNjby5jb20vYXJ0aWNsZS9XQlgwMDAwMjkwNTVcblxuXG5JTVBPUlRBTlQgTk9USUNF OiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViZXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90 aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3 aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRo aXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3Mu IElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNv bmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uXG4NClgtQUxU LURFU0M7Rk1UVFlQRT10ZXh0L2h0bWw6PHN0eWxlIHR5cGU9InRleHQvY3NzIj5cbioge1xuICAg IHBhZGRpbmc6IDA7ICAgIG1hcmdpbjogMDt9XG50YWJsZSB7XG4JYm9yZGVyLWNvbGxhcHNlOiBz ZXBhcmF0ZTsgd2lkdGggPTEwMCU7CWJvcmRlcjogMDsJYm9yZGVyLXNwYWNpbmc6IDA7fVxuXG50 ciB7XG4JbGluZS1oZWlnaHQ6IDE4cHg7fVxuXG5hLCB0ZCB7XG4JZm9udC1zaXplOiAxNHB4Owlm b250LWZhbWlseTogQXJpYWw7CWNvbG9yOiAjMzMzOwl3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7CXdv cmQtYnJlYWs6IG5vcm1hbDsJcGFkZGluZzogMDt9XG5cbi50aXRsZSB7XG4JZm9udC1zaXplOiAy OHB4O31cblxuLmltYWdlIHtcbgl3aWR0aDogYXV0bzsJbWF4LXdpZHRoOiBhdXRvO31cblxuLmZv b3RlciB7XG4Jd2lkdGg6IDYwNHB4O31cblxuLm1haW4ge1xuXG59QG1lZGlhIHNjcmVlbiBhbmQg KG1heC1kZXZpY2Utd2lkdGg6IDgwMHB4KSB7XG4JLnRpdGxlIHtcbgkJZm9udC1zaXplOiAyMnB4 ICFpbXBvcnRhbnQ7CX1cbgkuaW1hZ2Uge1xuCQl3aWR0aDogYXV0byAhaW1wb3J0YW50OwkJbWF4 LXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CX1cbgkuZm9vdGVyIHtcbgkJd2lkdGg6IDEwMCUgIWlt cG9ydGFudDsJCW1heC13aWR0aDogNjA0cHggIWltcG9ydGFudFxuCX1cbgkubWFpbiB7XG4JCXdp ZHRoOiAxMDAlICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6IDYwNHB4ICFpbXBvcnRhbnRcbgl9XG59 XG48L3N0eWxlPlxuXG48dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIgc3R5bGU9InBhZGRpbmc6IDA7 IG1hcmdpbjogMDsgYm9yZGVyOiAwOyB3aWR0aDogMTAwJTsiIGFsaWduPSJsZWZ0Ij5cbgk8dHIg c3R5bGU9ImhlaWdodDogMjhweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj5cbgk8dHI+XG4JCTx0ZCBh bGlnbj0ibGVmdCIgc3R5bGU9InBhZGRpbmc6IDAgMjBweDsgbWFyZ2luOiAwIj5cbgkJCTwhLS08 dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIgc3R5bGU9ImJvcmRlcjogMHB4OyB3aWR0aDogMTAwJTsg cGFkZGluZy1sZWZ0OiA1MHB4OyBwYWRkaW5nLXJpZ2h0OiA1MHB4OyIgYWxpZ249ImxlZnQiIGNs YXNzPSJtYWluIj5cbgkJCQk8dHI+XG4JCQkJCTx0ZCBhbGlnbj0iY2VudGVyIiB2YWxpZ249InRv cCIgPiZuYnNwOwkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJPC90YWJsZT4tLT5cblxuXG5cblxu XG4JCQk8dGFibGU+XG4JCQkJPHRyPlxuCQkJCQk8dGQ+XG4JCQkJCQk8Rk9OVCBTSVpFPSI0IiBD T0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPldoZW4gaXQncyB0aW1lLCBqb2luIHRoZSBXZWJl eCBtZWV0aW5nIGhlcmUuPC9GT05UPlxuCQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4JCQkJPHRyIHN0 eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwv dGQ+PC90cj5cbgkJCQk8dHI+XG4JCQkJCTx0ZD5cbgkJCQkJCTxGT05UIFNJWkU9IjIiIENPTE9S PSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogNjQx IDQ1OCA2Mjg8L0ZPTlQ+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJCTwvdGFibGU+XG4JCQlc bgkJCTx0YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJh cmlhbCI+TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0iMiIgIENP TE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+QldzQUY5clQ8L0ZPTlQ+PC90ZD48L3RyPjwvdGFi bGU+XG5cbiAgICAgICAgPHRhYmxlPlxuICAgICAgICAJPHRyIHN0eWxlPSJsaW5lLWhlaWdodDog MjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj5cbgkJCTx0cj5c bgkJCQk8dGQgc3R5bGU9IndpZHRoOmF1dG8haW1wb3J0YW50OyAiPlxuCQkJCQk8dGFibGUgYm9y ZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiIHN0eWxlPSJ3aWR0aDphdXRv O3dpZHRoOmF1dG8haW1wb3J0YW50O2JhY2tncm91bmQtY29sb3I6IzQzQTk0MjsgYm9yZGVyOjBw eCBzb2xpZCAjNDNBOTQyOyBib3JkZXItcmFkaXVzOjI1cHg7IG1pbi13aWR0aDoxNjBweCFpbXBv cnRhbnQ7Ij5cbgkJCQkJCTx0cj5cbgkJCQkJCQk8dGQgYWxpZ249ImNlbnRlciIgc3R5bGU9InBh ZGRpbmc6MTBweCAzNnB4OyI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2ou cGhwP01USUQ9bTAzZTljMDQwZjljZDY2NjUwZTE2NjNmMWRhMTdkMjk0IiBzdHlsZT0iY29sb3I6 I0ZGRkZGRjsgZm9udC1zaXplOjIwcHg7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+Sm9pbiBtZWV0 aW5nPC9hPjwvdGQ+XG4JCQkJCQk8L3RyPlxuCQkJCQk8L3RhYmxlPlxuCQkJCTwvdGQ+XG4JCQk8 L3RyPlxuCQk8L3RhYmxlPlxuXG4gPEZPTlQgc2l6ZT0iMiIgQ09MT1I9IiNGRjAwMDAiIHN0eWxl PSJmb250LWZhbWlseTogQXJpYWw7Ij48L0ZPTlQ+XG48Rk9OVCBTSVpFPSIxIiBGQUNFPSJBUklB TCI+Jm5ic3A7PEJSPiZuYnNwOzxCUj48L0ZPTlQ+XG5cbiZuYnNwOyA8QlI+PEZPTlQgU0laRT0i NCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlh bCI+Sm9pbiBieSBwaG9uZTwvRk9OVD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0i IzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxiPjxhIGhyZWY9J3RlbDolMkIxLTY1MC00NzktMzIwOCws KjAxKjY0MTQ1ODYyOCUyMyUyMyowMSonIHN0eWxlPSdjb2xvcjojMDBBRkY5OyAgdGV4dC1kZWNv cmF0aW9uOm5vbmU7IGZvbnQtZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDE0cHg7bGluZS1oZWln aHQ6IDI0cHg7Jz4xLTY1MC00NzktMzIwODwvYT48L2I+IENhbGwtaW4gdG9sbCBudW1iZXIgKFVT L0NhbmFkYSk8L0ZPTlQ+ICZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYi IEZBQ0U9ImFyaWFsIj48L0ZPTlQ+Jm5ic3A7IDxCUj48QlI+PEJSPlxuXG48dGFibGU+PHRyIHN0 eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwv dGQ+PC90cj48L3RhYmxlPlxuXG48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+PEZPTlQgU0la RT0iMyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGZyb20gYSB2aWRlbyBzeXN0 ZW0gb3IgYXBwbGljYXRpb248L0ZPTlQ+PEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2 IiBGQUNFPSJhcmlhbCI+RGlhbDwvRk9OVD4gPGEgaHJlZj0ic2lwOjY0MTQ1ODYyOEBpZXRmLndl YmV4LmNvbSI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9ImFyaWFsIj42NDE0 NTg2MjhAaWV0Zi53ZWJleC5jb208L0ZPTlQ+PC9hPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIg Q09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Zb3UgY2FuIGFsc28gZGlhbCAxNzMuMjQzLjIu NjggYW5kIGVudGVyIHlvdXIgbWVldGluZyBudW1iZXIuPC9GT05UPiAmbmJzcDsgPEJSPjwvRk9O VD4mbmJzcDsgPEJSPlxuXG48dGFibGUgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIj48 dHI+PHRkICBzdHlsZT0iY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFtaWx5OiBBcmlhbDtmb250LXNp emU6IDEycHg7IGZvbnQtd2VpZ2h0OiBib2xkOyBsaW5lLWhlaWdodDogMjRweDsiPjxiPkpvaW4g dXNpbmcgTWljcm9zb2Z0IEx5bmMgb3IgTWljcm9zb2Z0IFNreXBlIGZvciBCdXNpbmVzczwvYj48 L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQgc3R5bGU9ImNvbG9yOiAjMzMzMzMz OyBmb250LWZhbWlseTogQXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IDI0cHg7 Ij5EaWFsIDxhIGhyZWY9IiBzaXA6NjQxNDU4NjI4LmlldGZAbHluYy53ZWJleC5jb20iICAgc3R5 bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2NvbG9yOiMwMEFGRjkiPjY0MTQ1ODYyOC5pZXRmQGx5 bmMud2ViZXguY29tPC9hPjwvdGQ+PC90cj48L3RhYmxlPlxuXG4JCQk8dGFibGUgc3R5bGU9Indp ZHRoOiAxMDAlOyIgYWxpZ249ImxlZnQiIGNsYXNzPSJtYWluIj5cbiAgICAgICAgICAgICAgICA8 dHIgc3R5bGU9ImhlaWdodDogNzJweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj5cbgkJCQk8dHI+XG4J CQkJCTx0ZCBzdHlsZT0iaGVpZ2h0OiAyNHB4OyBjb2xvcjogIzAwMDAwMDsgZm9udC1mYW1pbHk6 QXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij5OZWVkIGhlbHA/IEdv IHRvIDxhIGhyZWY9Imh0dHA6Ly9oZWxwLndlYmV4LmNvbSIgc3R5bGU9ImNvbG9yOiMwNDlGRDk7 IHRleHQtZGVjb3JhdGlvbjpub25lOyI+aHR0cDovL2hlbHAud2ViZXguY29tPC9hPlxuCQkJCQk8 L3RkPlxuCQkJCTwvdHI+XG4gICAgICAgICAgICAgICAgPHRyIHN0eWxlPSJoZWlnaHQ6IDQ0cHgi Pjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JCQk8L3RhYmxlPlxuCQk8L3RkPlxuCTwvdHI+XG48L3Rh YmxlPlxuDQpTVU1NQVJZOk9BdXRoIFdHIFZpcnR1YWwgT2ZmaWNlIEhvdXJzDQpQUklPUklUWTo1 DQpDTEFTUzpQVUJMSUMNClJFQ1VSUkVOQ0UtSUQ7VFpJRD1FdXJvcGUvQmVybGluOjIwMjAwMzA5 VDE4MDAwMA0KQkVHSU46VkFMQVJNDQpUUklHR0VSOi1QVDVNDQpBQ1RJT046RElTUExBWQ0KREVT Q1JJUFRJT046UmVtaW5kZXINCkVORDpWQUxBUk0NCkVORDpWRVZFTlQNCkVORDpWQ0FMRU5EQVIN Cg== --_005_AM0PR08MB3716EE3BB7DFB66980E1AEC4FAEB0AM0PR08MB3716eurp_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=130; creation-date="Wed, 26 Feb 2020 17:22:16 GMT"; modification-date="Wed, 26 Feb 2020 17:22:16 GMT" Content-ID: <4C5264FB2A7BD546BC50C0F4D2C6A182@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1h aWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGgNCg== --_005_AM0PR08MB3716EE3BB7DFB66980E1AEC4FAEB0AM0PR08MB3716eurp_-- From nobody Thu Feb 27 04:51:41 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 672733A041C for ; Thu, 27 Feb 2020 04:51:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, T_SPF_TEMPERROR=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=risecloud.onmicrosoft.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 83x3v1md377t for ; Thu, 27 Feb 2020 04:51:33 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2089.outbound.protection.outlook.com [40.107.21.89]) (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 96FDB3A041A for ; Thu, 27 Feb 2020 04:51:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VQWQqgP5OeCp4J4wGUuX2RhPh8GiRdwq0hVHJ32md4W1eDGUqt14Hee2hQa0Rp6hJyHJdqAeK1W5kcNdRziC98/Tm5FfnDFQUiM4nPrMO4aBTviyLhlOI8iiDrb+oz+1DOwzm8JGDlVH5exMfodQdQ3uzqnURnS7lmxhMSdsYSdDNAwb5/0s0KuHap87JNAqcXz9K0ue6jnrUKderFT+xvc4LcDcjf91psBBnTPn69SF5csZoRoBxlvEsZDgxAGA2yi6LIGwEOk4kkx9cb217EPIHgMNoak2fajEl2PcMQTbW/avJ3mwD/bco/VNSLMNAPMgIEc/C1EXOOih3cLyMw== 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=y13FDe9Wu+aTNlMOdFrAsamvufsCyqW0UTkd0RxXvek=; b=QqyXMEwFIqhZKF6rQgo3BalmOWScffuCeOehL8ZJ/nJScCHslfjrvXmuDgQVFeCFWoljEJbz6UU4HUu5qP3JTFfAzCQp/R6Ezh27SLm+LezY2jbe0yV4T39iIbRyO6qYzbpBy9DYTx23eilHekhMW5IBu45FTcLQ+yoIua3TJtZ3kBLR5Uze92Dwe1ITVRGeZp9yg7ZhueW8i3rbertn9Cffy3CNbMzPhCtYln+ZTUBC/jeCREQFBJmQHtvjUwm6vRICo5h/zrdEMSLFzsWo1In7jehx/wgMZFd07tEHYbOrfjteF13RZEW8eDROxDmhCNkgzDZyBDfuUcxkagP7CA== 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=RISEcloud.onmicrosoft.com; s=selector1-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=y13FDe9Wu+aTNlMOdFrAsamvufsCyqW0UTkd0RxXvek=; b=kIYbTKjbz5/kY4ufADAxbWVcUNn3Szjn/BAxnC1ARpQMpT6fj43KgbgiaqTw5OHUItKOSBq8gwKl2b2wRpCSg3ak3to9cNo510w+JF5EnhahXayLo6xuRQhg0+CaYRskX0LjYcrw06iiqAoX5Oz9G+UzWDJ6w/HFuUlwyqVKGlQ= Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (10.165.195.159) by VI1P189MB0542.EURP189.PROD.OUTLOOK.COM (10.165.197.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.21; Thu, 27 Feb 2020 12:51:26 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::80e4:7dc7:7d4e:c9cb]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::80e4:7dc7:7d4e:c9cb%4]) with mapi id 15.20.2750.021; Thu, 27 Feb 2020 12:51:25 +0000 Received: from [10.8.8.32] (31.13.191.141) by HE1PR05CA0258.eurprd05.prod.outlook.com (2603:10a6:3:fb::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.18 via Frontend Transport; Thu, 27 Feb 2020 12:51:25 +0000 From: Marco Tiloca To: Jim Schaad , "ace@ietf.org" Thread-Topic: [Ace] Jim's Proposal on legal requestor Thread-Index: AdXsVzWimzIpNHbGTwi1hLO0NkxspAAT9PYAAAHGCYAACBXGgAAniJKA Date: Thu, 27 Feb 2020 12:51:25 +0000 Message-ID: <22cfc98d-e11f-dd6d-5bd7-9f5153a43a3b@ri.se> References: <025b01d5ec5e$94f85000$bee8f000$@augustcellars.com> <20646.1582723024@localhost> <0c16f230-3471-9215-e0dd-60604a1e1e02@ri.se> <02b001d5ecce$7aa32cf0$6fe986d0$@augustcellars.com> In-Reply-To: <02b001d5ecce$7aa32cf0$6fe986d0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-clientproxiedby: HE1PR05CA0258.eurprd05.prod.outlook.com (2603:10a6:3:fb::34) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) authentication-results: spf=none (sender IP is ) smtp.mailfrom=marco.tiloca@ri.se; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [31.13.191.141] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a0d45322-f646-49c5-fe25-08d7bb83c13d x-ms-traffictypediagnostic: VI1P189MB0542: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1850; x-forefront-prvs: 03264AEA72 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(136003)(376002)(346002)(366004)(189003)(199004)(66946007)(66556008)(66616009)(66476007)(64756008)(71200400001)(66446008)(6486002)(8936002)(316002)(110136005)(16576012)(81166006)(31686004)(81156014)(52116002)(8676002)(956004)(44832011)(2616005)(66574012)(86362001)(26005)(5660300002)(53546011)(478600001)(36756003)(31696002)(186003)(966005)(16526019)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P189MB0542; H:VI1P189MB0398.EURP189.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ri.se does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Ln6H4iVGP0exclC1X9eCYQjkARC2b/52S9igwZ8igLKFWwAysj9ozZ4tsnNSbYpM5Ra9c+FQi0Bw/+rEdixgtgPv0FP+x0SNsoEcyGdbTDk715BzDmmV3ePpeVPHTC3BD9GG0yvGMjGFe233hxMSDOUkeWsN+ZYx+V0VqSBZ2wOCju4hiYg/6KGTmhNnTNqqP7nE5JDPQ6eMWQZ3eLvsA3gzD8diEbR+LHKzmd9BlAQcSx3th54aHvnlf1Zhz9EwKL2Un6TMXAF40TCfEs44M3/r+yCdMDCBwVc7stqlwlbxjFjWOZBp6b9q9UPWfV235lOtZagNHA10oM6nFSVIuznyP46KuVpbMuoLC1wcrzwzU/nEQhELCYyx5YKtLt5oFsEKgl3Qro0ziJpW5Kl1x7ee7vUsBKEl0IxWBNunZ9Gh9vMjyi2sKd2/lo26KVR2R9iPK84inv+6tzLzOmNcnbzFh2Pi+deNobUh4z9imBBdLz0CRAjSllUCbpWoJ+H+vEjEzc6EvNhROVrBh902vQ== x-ms-exchange-antispam-messagedata: x94SHr7Ik24/ZKLxJwbNMTVdwpR0zsjORJsKyCmnpX/aAk9tMjvfzCyZNVktpxL3gRYyRD+d5Rktnm4eVGz+gXjiu1Bx1Zq2aE7eIT+9fdPUB2WJ8jCirHdKQSmBIl9x4S9SXYp0b9YHnhzbB4Fluw== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MpPuRfeRQrBXXgGtYBVkJHI9ufenMzZIu" MIME-Version: 1.0 X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: a0d45322-f646-49c5-fe25-08d7bb83c13d X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2020 12:51:25.7697 (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: e34gE2KHKA8H5FrsmIPRSn913ILfMAk+pyYI+gMA/N24Rde82xbHdOPJ+Dp+TK2eqgfscPzeenifPGCaJo1BeA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0542 Archived-At: Subject: Re: [Ace] Jim's Proposal on legal requestor 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, 27 Feb 2020 12:51:40 -0000 --MpPuRfeRQrBXXgGtYBVkJHI9ufenMzZIu Content-Type: multipart/mixed; boundary="492bg5DSY1F8KhRDxWUZnUzzXRJsZ7vcM" --492bg5DSY1F8KhRDxWUZnUzzXRJsZ7vcM Content-Type: multipart/alternative; boundary="------------063958F4C2C735468A2D1D3B" Content-Language: en-US This is a multi-part message in MIME format. --------------063958F4C2C735468A2D1D3B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Jim, On 2020-02-26 18:59, Jim Schaad wrote: > > =C2=A0 > > =C2=A0 > > *From:* Ace *On Behalf Of *Marco Tiloca > *Sent:* Wednesday, February 26, 2020 6:08 AM > *To:* Michael Richardson ; Jim Schaad > ; ace@ietf.org > *Subject:* Re: [Ace] Jim's Proposal on legal requestor > > =C2=A0 > > Hi! > > Jim, I think now I understand your idea and it makes sense to me. > > Some comments in line below. > > Best, > /Marco > > On 2020-02-26 14:17, Michael Richardson wrote: > > =C2=A0 > > clarifying question. > > =C2=A0 > > Jim Schaad = wrote: > > =C2=A0=C2=A0=C2=A0 > I do not seem to have been doing a good job of= explaining the issue > > =C2=A0=C2=A0=C2=A0 > that I am raising here, so I am going to go sc= enario based for a > > =C2=A0=C2=A0=C2=A0 > description. > > =C2=A0 > > =C2=A0=C2=A0=C2=A0 > (1) I get an access token from an AS with a sc= ope of [ > > =C2=A0=C2=A0=C2=A0 > "coap://multicast-01", ["responder"]] > > =C2=A0=C2=A0=C2=A0 > (2) I join the group associated > > =C2=A0=C2=A0=C2=A0 > with that address > > =C2=A0=C2=A0=C2=A0 > (3) I then decide to send the message below ou= t > > =C2=A0=C2=A0=C2=A0 > encrypted with the group symmetric key and sig= ned with the public key I > > =C2=A0=C2=A0=C2=A0 > registered during the join > > =C2=A0 > > =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 GET coap://multicast-01/reso= urce1 > > =C2=A0 > > .... (I numbered the steps) > > I believe that (1) was intended to allow you to become a responder = for this resource. > > > =3D=3D>MT > Step (1) is intended to allow access to the group-membership resource > at the Group Manager (GM), to get the keying material for > communicating in the group. > > Practically, the roles are currently used only at the GM to determine > which public keys is relevant to return to a node upon its joining. > <=3D=3D > > [JLS] When implies that the only roles of interest are =E2=80=9Cmonitor= =E2=80=9D vs > not =E2=80=9Cmonitor=E2=80=9D. > > > > > =C2=A0 > > =C2=A0 > > =C2=A0=C2=A0=C2=A0 > It then processes the get request > > =C2=A0=C2=A0=C2=A0 > because it does not know that this is a violat= ion of the scope assigned > > =C2=A0=C2=A0=C2=A0 > to me by the AS. > > =C2=A0 > > ! > > > =3D=3D>MT > As above, the original idea for that scope was to have it applied to > the group joining itself and the resource at the GM to access for joini= ng. > > But I agree that we should inform the other group members of that > role, i.e. "allowed to send requests" and/or "allowed to send responses= ". > <=3D=3D > > > =C2=A0 > > =C2=A0 > > =C2=A0=C2=A0=C2=A0 > The only way that I know for the server TimeX = to enforce the allowable > > =C2=A0=C2=A0=C2=A0 > operations is for that information to be propa= gated along with the > > =C2=A0=C2=A0=C2=A0 > signature public key from the KDC to the serve= r.=C2=A0=20 > > > =3D=3D>MT > This can be one more parameter in the Joining Response or in the > Public Key Response, when request public keys of group members are > included. > > Together with the array of public keys, we can have a same-ordered > array of roles echoing the roles from the scope of the Access Token > above. Each element of the array can possibly be an array of roles. > > How does it sound? > <=3D=3D > [JLS] Yes this makes sense.=C2=A0 The only potential issue is what happ= ens > if the set of roles becomes in some sense unbounded for an > application.=C2=A0 However, in that case I would expect that the list o= f > roles would be known to the joining clients.=C2=A0 The one thing that c= omes > up here is should there be a compression of these values since we are > sending them to a larger group of people. > =3D=3D>MT Yes, I think so. One integer per role should work, registered by the profile or application defining that role. Other that the wider distribution you mention above, compression is good anyway considering the recently discussion on 'scope' covering multiple groups, each with its role(s) indicated. <=3D=3D Best, /Marco > > One can create a > > =C2=A0=C2=A0=C2=A0 > similar scenario on the other side where a cli= ent sends a response when > > =C2=A0=C2=A0=C2=A0 > it is only authorized as a "requester". > > > =3D=3D>MT > Right, if it's "requester"-only. > <=3D=3D > > > =C2=A0 > > It seems to me that if the access control to the group is a group-s= hared > > symmetric key + asymmetric signature, that each responder requires = the list of valid signers. > > Or, we need LAKE to turn the group key into 1:1. > > > =3D=3D>MT > What I understand from Jim's proposal is essentially enabling at each > group member a list of valid request signers and valid response signers= =2E > <=3D=3D > > > =3D=3D>MT > Just to complement, this is all fine for this level of "filtering", > i.e. "this group member can send requests/responses or not". > > We have a separate draft at [1], defining a new Group OSCORE profile > of ACE, to enforce access control within the group, i.e. to access > group members' resources after having joined, i.e. as a group member > towards another group member. > > That is, that profile considers a granularity of exact REST methods > and resources, i.e. as fine-grained as ACE can be. Also, it enables > having together ACE-based access control and Group OSCORE, which is so > far not possible with other profiles. > > The current version -01 in the datatracker defines a "full mode" where > both OSCORE and Group OSCORE are considered as security protocols > between Client and RS. We plan to submit soon an updated version, > focusing more on a lighter, intended-to-be main mode, that focuses on > using only Group OSCORE as security protocol between Client and RS. > > [1] https://tools.ietf.org/html/draft-tiloca-ace-group-oscore-profile-0= 1 > <=3D=3D > > Best, > /Marco > > > =C2=A0 > > =C2=A0 > > -- > > Michael Richardson , Sandelman Software Works > > -=3D IPv6 IoT consulting =3D- > > =C2=A0 > > =C2=A0 > > =C2=A0 > > > > _______________________________________________ > > Ace mailing list > > Ace@ietf.org > > https://www.ietf.org/mailman/listinfo/ace > > > > --=20 > Marco Tiloca > Ph.D., Senior Researcher > =C2=A0 > RISE Research Institutes of Sweden > Division ICT > Isafjordsgatan 22 / Kistag=C3=A5ngen 16 > SE-164 40 Kista (Sweden) > =C2=A0 > Phone: +46 (0)70 60 46 501 > https://www.ri.se > > _______________________________________________ > 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 --------------063958F4C2C735468A2D1D3B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Jim,

On 2020-02-26 18:59, Jim Schaad wrote:=

=C2=A0

=C2=A0

From: Ace <ace-bounces@ietf.org> On Behalf Of Marco Tiloca
Sent: Wednesday, February 26, 2020 6:08 AM
To: Michael Richardson <mcr+ietf@sandelman.ca>; Jim Schaad <ietf@augustcellars.com>; ace@ietf.org
Subject: Re: [Ace] Jim's Proposal on legal requestor

=C2=A0

Hi!

Jim, I think now I understand your idea and it makes sense to me.

Some comments in line below.

Best,
/Marco

On 2020-02-26 14:17, Michael Richardson wrote:

=C2=A0
clarifying question.
=C2=A0
Jim Schaad <ietf@augustcellars.com> wrote:<=
/pre>
          
=C2=A0=C2=A0=C2=A0 > I do not seem to have been doing a=
 good job of explaining the issue

          
=C2=A0=C2=A0=C2=A0 > that I am raising here, so I am go=
ing to go scenario based for a

          
=C2=A0=C2=A0=C2=A0 > description.

          
=C2=A0

          
=C2=A0=C2=A0=C2=A0 > (1) I get an access token from an =
AS with a scope of [

          
=C2=A0=C2=A0=C2=A0 > "coap://multicast-01", ["responder=
"]]

          
=C2=A0=C2=A0=C2=A0 > (2) I join the group associated

          
=C2=A0=C2=A0=C2=A0 > with that address
=

          
=C2=A0=C2=A0=C2=A0 > (3) I then decide to send the mess=
age below out

          
=C2=A0=C2=A0=C2=A0 > encrypted with the group symmetric=
 key and signed with the public key I

          
=C2=A0=C2=A0=C2=A0 > registered during the join

          
=C2=A0

          
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 GET coap://multi=
cast-01/resource1

          
=C2=A0

          
.... (I numbered the steps)

          
I believe that (1) was intended to allow you to become a r=
esponder for this resource.


=3D=3D>MT
Step (1) is intended to allow access to the group-membership resource at the Group Manager (GM), to get the keying material for communicating in the group.

Practically, the roles are currently used only at the GM to determine which public keys is relevant to return to a node upon its joining.
<=3D=3D

[JLS] When implies that the only roles of interest are =E2=80=9Cmonitor=E2=80=9D vs not =E2=80=9Cmonitor=E2= =80=9D.




=C2=A0
=C2=A0
=C2=A0=C2=A0=C2=A0 > It then processes the get request<=
o:p>
=C2=A0=C2=A0=C2=A0 > because it does not know that this=
 is a violation of the scope assigned
=C2=A0=C2=A0=C2=A0 > to me by the AS.
=C2=A0
!


=3D=3D>MT
As above, the original idea for that scope was to have it applied to the group joining itself and the resource at the GM to access for joining.

But I agree that we should inform the other group members of that role, i.e. "allowed to send requests" and/or "allowed to send responses".
<=3D=3D


=C2=A0
=C2=A0
=C2=A0=C2=A0=C2=A0 > The only way that I know for the s=
erver TimeX to enforce the allowable
=C2=A0=C2=A0=C2=A0 > operations is for that information=
 to be propagated along with the
=C2=A0=C2=A0=C2=A0 > signature public key from the KDC =
to the server.=C2=A0


=3D=3D>MT
This can be one more parameter in the Joining Response or in the Public Key Response, when request public keys of group members are included.

Together with the array of public keys, we can have a same-ordered array of roles echoing the roles from the scope of the Access Token above. Each element of the array can possibly be an array of roles.

How does it sound?
<=3D=3D
[JLS] Yes this makes sense.=C2=A0 The only potential issue is w= hat happens if the set of roles becomes in some sense unbounded for an application.=C2=A0 However, in that case I would expect = that the list of roles would be known to the joining clients.=C2=A0 = The one thing that comes up here is should there be a compression of these values since we are sending them to a larger group of people.


=3D=3D>MT
Yes, I think so. One integer per role should work, registered by the profile or application defining that role.

Other that the wider distribution you mention above, compression is good anyway considering the recently discussion on 'scope' covering multiple groups, each with its role(s) indicated.
<=3D=3D

Best,
/Marco


One can create a
=C2=A0=C2=A0=C2=A0 > similar scenario on the other side=
 where a client sends a response when
=C2=A0=C2=A0=C2=A0 > it is only authorized as a "reques=
ter".


=3D=3D>MT
Right, if it's "requester"-only.
<=3D=3D


=C2=A0
It seems to me that if the access control to the group is =
a group-shared
symmetric key + asymmetric signature, that each responder =
requires the list of valid signers.
Or, we need LAKE to turn the group key into 1:1.


=3D=3D>MT
What I understand from Jim's proposal is essentially enabling at each group member a list of valid request signers and valid response signers.
<=3D=3D


=3D=3D>MT
Just to complement, this is all fine for this level of "filtering", i.e. "this group member can send requests/responses or not".

We have a separate draft at [1], defining a new Group OSCORE profile of ACE, to enforce access control within the group, i.e. to access group members' resources after having joined, i.e. as a group member towards another group member.

That is, that profile considers a granularity of exact REST methods and resources, i.e. as fine-grained as ACE can be. Also, it enables having together ACE-based access control and Group OSCORE, which is so far not possible with other profiles.

The current version -01 in the datatracker defines a "full mode" where both OSCORE and Group OSCORE are considered as security protocols between Client and RS. We plan to submit soon an updated version, focusing more on a lighter, intended-to-be main mode, that focuses on using only Group OSCORE as security protocol between Client and RS.

[1] https://tools.ietf.org/html/draft-ti= loca-ace-group-oscore-profile-01
<=3D=3D

Best,
/Marco


=C2=A0
=C2=A0
--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman S=
oftware Works
 -=3D IPv6 IoT consulting =3D-
=C2=A0
=C2=A0
=C2=A0



_______________________________________________=

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



-- 
Marco Tiloca
Ph.D., Senior Researcher
=C2=A0
RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistag=C3=A5ngen 16
SE-164 40 Kista (Sweden)
=C2=A0
Phone: +46 (0)70 60 46 501
https=
://www.ri.se

____________________________=
___________________
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
--------------063958F4C2C735468A2D1D3B-- --492bg5DSY1F8KhRDxWUZnUzzXRJsZ7vcM-- --MpPuRfeRQrBXXgGtYBVkJHI9ufenMzZIu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl5Xu0cACgkQ7iZktA5Y 2kNzMQf/dJJokph3si+1YCaVgonmP6gppkio35t9nNvqXwl1uxwzdR01pnp/iDVG 7TBr8IAB1NrpA/1GGqphutM+wSD8nr5pDZTb5Tsb5W9agJxD7eKolfJNdUm7sXG2 ++QJ6mvvGmbx+n5m2NMv9LUZUB0e5694ATi33TbulxcwHCQD9qIzExvhs/m+1oFe eanGdLmzG7DpLhreMvmm8kjd30PAIBX+D97ON0MnuvTeE0/z4KB9XwSxepMjA1V1 tjB1fiShTAm0hucgP4l4Q6fGgZYt9Qp9Fnl6JaNFrs+53lWmfx9cnYMx0M7pX4zE WmgdzbbBSrqxZhJdvRAPMiwCuyV8hQ== =is9l -----END PGP SIGNATURE----- --MpPuRfeRQrBXXgGtYBVkJHI9ufenMzZIu-- From nobody Fri Feb 28 00:59:25 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 81C1D3A1383 for ; Fri, 28 Feb 2020 00:59:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=CgLv43do; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=CgLv43do Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDPp-AURn3ZX for ; Fri, 28 Feb 2020 00:59:22 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50070.outbound.protection.outlook.com [40.107.5.70]) (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 08C223A1382 for ; Fri, 28 Feb 2020 00:59:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DSsF/RObCVi2mS5cp3HDEjpKjKQNT5whO8oK2+nDsMw=; b=CgLv43doasTS8eUWxafT0bpDAVD4zbh54/kaHthdS+c87uBHrTJ7zPh2gnGCpCdsUJTprsyxW7tTX2y/k5D/elhJBoBtkpTOzIW5ReYeHvr0nw0Q81i1z43x8hCKJP5YNBhW9S+2mYuSpQtBSo0HLBY+his5tlpI9IHpKel+rGo= Received: from VI1PR0801CA0084.eurprd08.prod.outlook.com (2603:10a6:800:7d::28) by VI1PR08MB3182.eurprd08.prod.outlook.com (2603:10a6:803:46::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.16; Fri, 28 Feb 2020 08:59:19 +0000 Received: from DB5EUR03FT033.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e0a::202) by VI1PR0801CA0084.outlook.office365.com (2603:10a6:800:7d::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.14 via Frontend Transport; Fri, 28 Feb 2020 08:59:18 +0000 Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT033.mail.protection.outlook.com (10.152.20.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.15 via Frontend Transport; Fri, 28 Feb 2020 08:59:18 +0000 Received: ("Tessian outbound 0420f1404d58:v42"); Fri, 28 Feb 2020 08:59:18 +0000 X-CR-MTA-TID: 64aa7808 Received: from 44bec648fd12.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id E2219CA0-6DBB-4735-9CD8-DB8868B2F626.1; Fri, 28 Feb 2020 08:59:13 +0000 Received: from EUR03-VE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 44bec648fd12.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 28 Feb 2020 08:59:13 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nTZrW6NTMGp5u4H8GhVCSByns8qPrR1XoutFkXbU9eRTAPZM7592Uh/lUBB/8Jqei2Jn1x5IBTbswMfDOmJ6El2KQJRT7xAj9SDj+U5yS/S40PZH4C7VREt/wuVkgjUsx+SH0ooQLpAbddAV1GsBPQDm27SrZyaXeRdviE/K8cAxodv6CiYNOTCkxs96fwM0O1G+GM3gd8PpGrTSpDjohV09kpIUV7FmpQBcjgXBLmZhH3m9sb6e2P/cmbbCNJqGIoa1DV7QEJPBRKSrg4VsqDeFhfsN/Q0IPlinFvvTLhFl6Faxmox6oGeYzAO+J0PKawtFycPenMHNKjcAuLbgkA== 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=DSsF/RObCVi2mS5cp3HDEjpKjKQNT5whO8oK2+nDsMw=; b=exWFyQ09ovxN8klcu7Z64Hd1lPWA6DYpB6JQpiyre84zYghzbqUUQ7qawL90j3R8VpnbXM9+0YsoarSG+0TeCeXCd3SLLKXmdqDV9uBfKxZUCCkzxz4zDTuSyciUblKOBhk7pH1nMTfFSUs+DV7WgJejpEooXQItLwrf7ppvGfH3y/uj5ooB4JAiWahZiRaOwEH54OWTowme04zbZ5QAjnMl9L2HbSs40kNtvRM/YegV+LzQbR+rAsZvZQ1ufRQ/mhSJi1xfIJgr/e3Gv+bkYX1A6JIFvHDhQGkUj+6e6SyyXtB/pDQEQpcKGYTdc0G4M5q7fsrr+y+DV9acqYt1rA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DSsF/RObCVi2mS5cp3HDEjpKjKQNT5whO8oK2+nDsMw=; b=CgLv43doasTS8eUWxafT0bpDAVD4zbh54/kaHthdS+c87uBHrTJ7zPh2gnGCpCdsUJTprsyxW7tTX2y/k5D/elhJBoBtkpTOzIW5ReYeHvr0nw0Q81i1z43x8hCKJP5YNBhW9S+2mYuSpQtBSo0HLBY+his5tlpI9IHpKel+rGo= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (20.178.23.205) by AM0PR08MB3218.eurprd08.prod.outlook.com (52.134.92.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.17; Fri, 28 Feb 2020 08:59:11 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::2159:870b:25df:e612]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::2159:870b:25df:e612%5]) with mapi id 15.20.2772.018; Fri, 28 Feb 2020 08:59:11 +0000 From: Hannes Tschofenig To: Cigdem Sengul CC: "ace@ietf.org" Thread-Topic: [Ace] draft-ietf-ace-mqtt-tls-profile-03 Thread-Index: AdXrwPKVlOWry/rCSraJ6rVcwUtPZQAJFd8AAFsSKHA= Date: Fri, 28 Feb 2020 08:59:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: e7281a8d-4486-4699-9c69-ecd1b6a298b6.1 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.119.84] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: e511eead-10b9-4aa2-8025-08d7bc2c7eb4 X-MS-TrafficTypeDiagnostic: AM0PR08MB3218:|VI1PR08MB3182: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 0327618309 X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(346002)(366004)(396003)(376002)(136003)(39860400002)(199004)(189003)(52536014)(66946007)(66446008)(66556008)(71200400001)(66476007)(2906002)(8936002)(64756008)(316002)(478600001)(86362001)(81156014)(8676002)(81166006)(5660300002)(9686003)(26005)(55016002)(186003)(76116006)(6916009)(6506007)(33656002)(966005)(7696005)(4326008)(53546011); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR08MB3218; H:AM0PR08MB3716.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: fq2VQyF/Kud2BxAPxG/yh5u8X/7yEtxixMNd2zS2M8lU5Ru6Mmp3iSy6bi/UVHuMGdMPWPUOox/rwdvuJ4G0YuF3iOixugwoFtMXylJlqn0QzEo0Zaw9Sj6X+SjJXHIBtXqFFNJ3HZSZtjJp8TJlwS6sb9vuOpsPVK5W39FjhSPTNlQMKE4U0EfR2pF30yOpMeTYzMPdG3IC3flSYRjnMo+Fdu5gxROcbMHNUr8LPORv4yYwsRm/F5FEFFeRJolYBoG/0kpTXQoE5PCHoGY6lyrRKu98zM9q9r8KncVRpbrIiEZkbAbGRrQRvG0iHEat3ndb3vp1bIh7DKoYlk0Dwy/y9F22qTNQd7WSjNrBxy+dQy86o/KnmG7RUyQD4RBnjMJ/oHc2b+1m0JhBwus17xi+xm9eH2wZOsDboP6tEt3zEWz8dqFf0iaF4wD8CvrTLpKoqSBZuQ/T6CIM/uZ8jLHp+q92B0FjeH8qtQsEVoeYr3EBJsMUSx76Rpd83I9LDemXkaHv04LrDfmN3NC5vQ== x-ms-exchange-antispam-messagedata: 4q4B5C2zDcjCig3CBi7geGedyZ+1kkZG4EnG5zC5DfOJG2HwTKaIARXnUHLOhVhPvixri45DvkQLxhIUVi2cHvjcHD5h0De2EPIU2MEAqu2gf/YkM0kruxS+hqs2VrlZCnhiLNhBHJojEBQDDB4U4g== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3218 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT033.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; IPV:CAL; SCL:-1; CTRY:IE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(136003)(39860400002)(346002)(396003)(376002)(199004)(189003)(70206006)(33656002)(70586007)(52536014)(5660300002)(86362001)(7696005)(356004)(2906002)(9686003)(4326008)(55016002)(316002)(6862004)(53546011)(8676002)(336012)(478600001)(81156014)(81166006)(8936002)(26005)(6506007)(966005)(186003)(26826003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR08MB3182; H:64aa7808-outbound-1.mta.getcheckrecipient.com; FPR:; SPF:Pass; LANG:en; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; A:1; MX:1; X-MS-Office365-Filtering-Correlation-Id-Prvs: c13a0e88-b887-48dd-c414-08d7bc2c7a83 X-Forefront-PRVS: 0327618309 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: gvj72U6bGwH/4G0psJTM3F6JZGASSLCZKwF0UgIy0Gceu22L3i5xJEtNpwW1FHbuW3iqbmz9Dd9F354aQR/Ba4upmcHf9yq++CokEcf6nESrSDm+S+KqDoPwGD9rXj/lM42vCi5BLFAlxP3RpvUXHeiO3eCMfaVqy6WMQa0+qLYCBx3LP0aslrwhoavkLapV4Sw0WU8DruuF4zfFcbOt4xEGq4bkxyWkz5uLem+OHgXd54TDIvAVETd99EKLap5/3OVWeSChEOiEAlHEj4bfp68+tOTCtc+UXvMq/554GfeJOkGb6/dRv0JloNW2UB0ofQ+/gc9reSPSyX7ltFOPgzdli9IDljuzwWeHDvkb2d9lbZ/thi6xk/gXUbpd9/xRJUVDs/3/gCh8WUlLydkBBf/fWIX+ulzLL1X8Y0MiRp6JRYEUeXW903Ren9N/5jhs0CLbsWlpTVTVqxKsHl47Y7/uYPJKbtmk67QCncQ0yMLQH3nycEpKF6Lmt77RXyQHsEmryb1EbTl+UPBXHVW+kA== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Feb 2020 08:59:18.6495 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e511eead-10b9-4aa2-8025-08d7bc2c7eb4 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB3182 Archived-At: Subject: Re: [Ace] draft-ietf-ace-mqtt-tls-profile-03 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: Fri, 28 Feb 2020 08:59:25 -0000 SGkgQ2lnZGVtLA0KDQpUaGFua3MgZm9yIHlvdXIgcXVpY2sgcmVzcG9uc2UuDQoNCkZyb20gdGhl IHRleHQgeW91IGNpdGVkIHJlZ2FyZGluZyBNUVRUIHY1IGl0IGlzIG5vdCBiYWNrd2FyZHMgY29t cGF0aWJsZSB0byB2ZXJzaW9uIDMuMS4xLiBUaGUgZXhhY3QgaW1wYWN0IG9mIHdvcmtpbmcgYmV0 d2VlbiB0d28gZGV2aWNlcyBvZiBkaWZmZXJlbnQgdmVyc2lvbnMgaGFzIG5vdCBiZWVuIGRlc2Ny aWJlZCBpbiB0aGUgc3BlYyBlaXRoZXIuIFRoZSBmb2xsb3cgc2VudGVuY2UgaW4geW91ciBpbnRy b2R1Y3Rpb24gY2FuIGVhc2lseSBnaXZlIHJlYWRlcnMgdGhlIGltcHJlc3Npb24gdGhhdCB0aGUg dHdvIHZlcnNpb25zIGFyZSBiYWNrd2FyZHMgY29tcGF0aWJsZS4gSGVyZSBpcyB0aGUgc2VudGVu Y2U6DQoNCiIgSXQgaXMgZXhwZWN0ZWQgdGhhdCBNUVRUDQogICBkZXBsb3ltZW50cyB3aWxsIHJl dGFpbiBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IGZvciBNUVRUIHYzLjEuMQ0KICAgY2xpZW50cywg YW5kIHRoZXJlZm9yZSwgdGhpcyBkb2N1bWVudCBhbHNvIGRlc2NyaWJlcyBhIHJlZHVjZWQgc2V0 IG9mDQogICBwcm90b2NvbCBpbnRlcmFjdGlvbnMgZm9yIE1RVFQgdjMuMS4xIC0gdGhlIE9BU0lT IFN0YW5kYXJkDQogICBbTVFUVC1PQVNJUy1TdGFuZGFyZF0uDQoiDQoNCk1heWJlIHlvdSB3YW50 IHRvIGNoYW5nZSB0aGUgd29yZGluZyBhIGxpdHRsZSBiaXQuICBJIHRoaW5rIHRoZSByZWFzb24g d2h5IHlvdSB3YW50IHRvIGRlc2NyaWJlIGEgc29sdXRpb24gZm9yIHYzLjEuMSBpcyB0aGF0IHRo aXMgaXMgdGhlIHdpZGVseSBkZXBsb3llZCB2ZXJzaW9uLg0KDQpSZWdhcmRpbmcgdGhlIGJyb2tl ciB0ZXJtOiBJdCBpcyBwcm9iYWJseSBhIG1hdHRlciBvZiB0YXN0ZSBidXQgSSB3b3VsZCByZWZl ciB0byB0aGUgdGVybXMgdXNlZCBpbiB0aGUgc3BlYyBhbmQgd291bGQgbm90IHJlcGxpY2F0ZSB0 aGUgdGVybWlub2xvZ3kgZnJvbSB0aGUgT0FTSVMgTVFUVCBzcGVjcyBpbiB0aGUgZHJhZnQuIFNv bWVvbmUgd2hvIGltcGxlbWVudHMgdGhlIGRyYWZ0IHdpbGwgaGF2ZSB0byBiZWNvbWUgZmFtaWxp YXIgd2l0aCBNUVRUIGFueXdheS4gQnV0IHRoYXTigJlzIGp1c3QgbWUuIEZvciBleGFtcGxlLCBJ IG9mdGVuIHNlZSBwZW9wbGUgdXNpbmcgdGhlIHRlcm0g4oCcY2VydGlmaWNhdGUgYXV0aG9yaXRp ZXMgKENBKeKAnSBpbiB0aGVpciB3cml0ZS11cHMuIFJGQyA1MjgwIGRlZmluZXMgYW5kIHVzZXMg dGhlIHRlcm0g4oCcY2VydGlmaWNhdGlvbiBhdXRob3JpdHkgKENBKSIuIFdoaWxlIHRoZSB0d28g c291bmQgYW5kIGxvb2sgc2ltaWxhciBvbmx5IG9uZSBpcyBhY3R1YWxseSBjb3JyZWN0Lg0KDQpJ IG5vdGljZWQgeW91IGhhdmUgcHV0IGEgbm9ybWF0aXZlIGRlcGVuZGVuY3kgb24gW0ktRC5wYWxv bWJpbmktYWNlLWNvYXAtcHVic3ViLXByb2ZpbGVdLiBJIGRvbid0IHRoaW5rIGl0IGlzIG5lY2Vz c2FyeSBiZWNhdXNlIGl0IGlzIG5vdCBhIHJlcXVpcmVtZW50IHRvIGltcGxlbWVudCB0aGUgc3Bl Yy4gWW91IGNvdWxkIHVzZSBpdCBvbiB0b3Agb2YgaXQgLS0gb3IgeW91IGNvdWxkIHVzZSBzb21l dGhpbmcgZWxzZSBhcyB3ZWxsLiBJIHdvdWxkIG1vdmUgaXQgdG8gdGhlIGluZm9ybWF0aXZlIHBh cnQuIFRoZSBhZGRlZCBiZW5lZml0IG9mIGRvaW5nIHRoYXQgaXMgdGhhdCB5b3UgZG8gbm90IGJs b2NrIHlvdXIgc3BlYyB0aWxsIHRoYXQgZHJhZnQgYmVjb21lcyBSRkMuIE9uIHRoZSBvdGhlciBo YW5kLCBSRkMgNjc0OSwgUkZDIDc4MDAsIGFuZCBJLUQuaWV0Zi1hY2UtY3d0LXByb29mLW9mLXBv c3Nlc3Npb24gY2Fubm90IGJlIGluZm9ybWF0aXZlIHJlZmVyZW5jZXMgd2hlbiB5b3UgdXNlIFBv UCB0b2tlbnMgaW4geW91ciBzb2x1dGlvbi4NCg0KWW91IG1pZ2h0IGJlIGludGVyZXN0aW5nIHRv IGhlYXIgdGhhdCB0aGVyZSBpcyBjdXJyZW50bHkgbm8gd2F5IHRvIG9idGFpbiB0aGUga2V5cyBm b3IgYSBQb1AgdG9rZW4gb3ZlciBIVFRQLCB3aGljaCB5b3VyIHNvbHV0aW9uIHJlcXVpcmVzLiBU aGUgdmlydHVhbCBpbnRlcmltIG1lZXRpbmcgaW4gdGhlIE9BdXRoIGdyb3VwIHNob3VsZCBwcm9i YWJseSBiZSBvZiBpbnRlcmVzdCB0byB5b3UuDQoNCkNpYW8NCkhhbm5lcw0KDQpGcm9tOiBDaWdk ZW0gU2VuZ3VsIDxjaWdkZW0uc2VuZ3VsQGdtYWlsLmNvbT4NClNlbnQ6IFR1ZXNkYXksIEZlYnJ1 YXJ5IDI1LCAyMDIwIDM6MTAgUE0NClRvOiBIYW5uZXMgVHNjaG9mZW5pZyA8SGFubmVzLlRzY2hv ZmVuaWdAYXJtLmNvbT4NCkNjOiBhY2VAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbQWNlXSBkcmFm dC1pZXRmLWFjZS1tcXR0LXRscy1wcm9maWxlLTAzDQoNCkhlbGxvIEhhbm5lcywNCg0KV2UgdXNl ZCAgYnJva2VyIGFzIGl0IGlzIGEgd2lkZWx5IGFjY2VwdGVkIHRlcm0gaW4gdGhlIE1RVFQgQ29t bXVuaXR5IGZvciAic2VydmVyIiBlLmcuLA0KbWFqb3JpdHkgb2YgdGhlIHByb3ZpZGVyIHdvdWxk IGxpc3QgYWxzbyBhIGJyb2tlciBpbXBsZW1lbnRhdGlvbiB0byByZWZlciB0byB0aGVpciBzZXJ2 ZXIgaW1wbGVtZW50YXRpb24uDQoNCldpdGggcmVzcGVjdCB0byB3aGV0aGVyIDMuMSwxIGNsaWVu dHMgdGFsa2luZyB0byB2NSwgdGhlcmUgbWF5IGJlIHNvbWUgaXNzdWVzLiBUaGlzIGlzIHdoYXQg dGhlIHNwZWMgc2F5czoNCg0KTm9uLW5vcm1hdGl2ZSBDb21tZW50DQpJZiB0aGUgU2VydmVyIGRp c3RyaWJ1dGVzIEFwcGxpY2F0aW9uIE1lc3NhZ2VzIHRvIENsaWVudHMgYXQgZGlmZmVyZW50IHBy b3RvY29sIGxldmVscyAoc3VjaCBhcyBNUVRUIFYzLjEuMSkgd2hpY2ggZG8gbm90IHN1cHBvcnQg cHJvcGVydGllcyBvciBvdGhlciBmZWF0dXJlcyBwcm92aWRlZCBieSB0aGlzIHNwZWNpZmljYXRp b24sIHNvbWUgaW5mb3JtYXRpb24gaW4gdGhlIEFwcGxpY2F0aW9uIE1lc3NhZ2UgY2FuIGJlIGxv c3QsIGFuZCBhcHBsaWNhdGlvbnMgd2hpY2ggZGVwZW5kIG9uIHRoaXMgaW5mb3JtYXRpb24gbWln aHQgbm90IHdvcmsgY29ycmVjdGx5Lg0KDQpUaGUgc3BlYyBhbHNvIGRlZmluZXMgYSBwcm90b2Nv bCB2ZXJzaW9uIGVycm9yIG1lc3NhZ2U6DQpJZiB0aGUgW0NsaWVudCdzXSBQcm90b2NvbCBWZXJz aW9uIFtpbiB0aGUgQ09OTkVDVCBwYWNrZXRdIGlzIG5vdCA1IGFuZCB0aGUgU2VydmVyIGRvZXMg bm90IHdhbnQgdG8gYWNjZXB0IHRoZSBDT05ORUNUIHBhY2tldCwgdGhlIFNlcnZlciBNQVkgc2Vu ZCBhIENPTk5BQ0sgcGFja2V0IHdpdGggUmVhc29uIENvZGUgMHg4NCAoVW5zdXBwb3J0ZWQgUHJv dG9jb2wgVmVyc2lvbikgYW5kIHRoZW4gTVVTVCBjbG9zZSB0aGUgTmV0d29yayBDb25uZWN0aW9u DQoNClNvLCB3aGV0aGVyIGEgYnJva2VyIHByb3ZpZGVzIGR1YWwgc3VwcG9ydCB3b3VsZCBkZXBl bmQgb24gdGhlIHByb3ZpZGVyLiBFLmcuLCB0aGUgTW9zcXVpdHRvIGJyb2tlciBzdXBwb3J0cyB0 aGUgZGlmZmVyZW50IHByb3RvY29sIHZlcnNpb25zLg0KDQpUaGFua3MsDQotLUNpZ2RlbQ0KDQpP biBUdWUsIEZlYiAyNSwgMjAyMCBhdCAxMDowMSBBTSBIYW5uZXMgVHNjaG9mZW5pZyA8bWFpbHRv Okhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20+IHdyb3RlOg0KSGkgQ2lnZGVtLCBIaSBBbnRob255 LCBIaSBQYXVsLA0KDQpXaHkgYXJlIHlvdSB1c2luZyB0aGUgdGVybSBNUVRUIGJyb2tlcj8gTXkg dW5kZXJzdGFuZGluZyBvZiB0aGUgTVFUVCBzcGVjIGlzIHRoYXQgdGhlcmUgYXJlIG9ubHkgY2xp ZW50cyBhbmQgc2VydmVycyAtIG5vdGhpbmcgbW9yZS4NCg0KSXMgYSBNUVRUIHYzLjEuMSBjbGll bnQgYWJsZSB0byB0YWxrIHRvIGEgTVFUVCB2NSBzZXJ2ZXI/IFdvdWxkIGEgTVFUVCB2My4xLjEg Y2xpZW50IHRhbGsgdG8gYSBNUVRUIHY1IGNsaWVudCB2aWEgYSBzZXJ2ZXIgdGhhdCBzdXBwb3J0 cyBib3RoIHYzLjEuMSBhbmQgdjU/DQoNCkNpYW8NCkhhbm5lcw0KDQpJTVBPUlRBTlQgTk9USUNF OiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25m aWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBh bmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2Ug aXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBh bnkgbWVkaXVtLiBUaGFuayB5b3UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpBY2UgbWFpbGluZyBsaXN0DQptYWlsdG86QWNlQGlldGYub3JnDQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZQ0KSU1QT1JUQU5UIE5PVElD RTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29u ZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkg YW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNl IGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4g YW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K From nobody Fri Feb 28 01:45:39 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 1500D3A144F for ; Fri, 28 Feb 2020 01:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_BLOCKED=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 k3ejvdprxIP6 for ; Fri, 28 Feb 2020 01:45:35 -0800 (PST) Received: from mail-vk1-xa34.google.com (mail-vk1-xa34.google.com [IPv6:2607:f8b0:4864:20::a34]) (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 C3EFB3A144E for ; Fri, 28 Feb 2020 01:45:35 -0800 (PST) Received: by mail-vk1-xa34.google.com with SMTP id i78so755306vke.0 for ; Fri, 28 Feb 2020 01:45:35 -0800 (PST) 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 :cc; bh=XnZoyQXzOtF+2BP9H91EzXnwPVD3L3K+wQY0OwuO2B8=; b=PfIO+tFNoyODPx4LqdKr4IZwD74fShzuD6zSMTuJ8SFinEMZz6muc6ILXjfgVfkreZ 23V1G01kpf6ThhV12Nh474/5zT+fZtDcDGuGvj4ww8ziZWiouxuDpCNkgpzdkMRzF4O4 B+gjywGdOiLY0SAcZ/vwx5IAoJNoUO3GnsTbFefUtM3W6Mpkj1E+umrZg/N13TiZoDEu s2Tz8wvkrLVTfongdeklm2EG66YB53BX+0YJ3Dnc/JWCC8y3IXRFammeJiRQWtfnIoYh rpGFZB2Tt+08iuph+CJrKOnQOGobX2+7tytSMCdXQTEYOtjRa0tzY9ZizPnmZTy5dhZZ +KOg== 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:cc; bh=XnZoyQXzOtF+2BP9H91EzXnwPVD3L3K+wQY0OwuO2B8=; b=U1RdB+DBLptzK0bH8dSWIDIroViEvY5xdLnSjTQ51OKp3Kh7Fz4uC37Z1Me8HRek5y R+Mwl6SyYYuZMtKZaauIS1aOHcdnU7Jibvw9/eU117ULD6Geqr2PZOaEVL9rl8hcf7+y ixl+6hcft2WvL82FGqLaoM7Nsdsp59unYlX00lRLxQO2hR6YhjzszUcISuvb+p4j/bsa rBwpdO7QrCPRJC/QnAiktnmnaCeoIavp6ZuJ4MDMpwj0t5SLKGILhZf2iLOIkqxzGJgh WjuiczG6ETlNw9BkeTpFDr6iRETd3BRK7vCKmZZkLbKwg63vBcUwjFpWqeCMobieEHNl Ej5A== X-Gm-Message-State: ANhLgQ3VsKOa7WH+c8pKev+6tol/gbMrJbA4Q+xaWqWrVfHccgjsOrFH nc2wPpVOWFVl9QBARfR5hCAl3IyxAt7gx17HNicSEBO+nHo= X-Google-Smtp-Source: ADFU+vuBkr92zmH4FmVRKbS6zfjTexKMSh5fUm0Hayjm/GNUVWBqOwasayjtCjVuZ+XnEk+dc/PR6EZnph3hXmJ+Zng= X-Received: by 2002:a1f:1bc3:: with SMTP id b186mr560955vkb.96.1582883134745; Fri, 28 Feb 2020 01:45:34 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Cigdem Sengul Date: Fri, 28 Feb 2020 09:45:25 +0000 Message-ID: To: Hannes Tschofenig Cc: "ace@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f7b140059f9fb250" Archived-At: Subject: Re: [Ace] draft-ietf-ace-mqtt-tls-profile-03 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: Fri, 28 Feb 2020 09:45:38 -0000 --000000000000f7b140059f9fb250 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Hannes, Thank you very much for your comments. My responses are inside. > > From the text you cited regarding MQTT v5 it is not backwards compatible > to version 3.1.1. The exact impact of working between two devices of > different versions has not been described in the spec either. The follow > sentence in your introduction can easily give readers the impression that > the two versions are backwards compatible. Here is the sentence: > > " It is expected that MQTT > deployments will retain backward compatibility for MQTT v3.1.1 > clients, and therefore, this document also describes a reduced set of > protocol interactions for MQTT v3.1.1 - the OASIS Standard > [MQTT-OASIS-Standard]. > " > Maybe you want to change the wording a little bit. I think the reason wh= y > you want to describe a solution for v3.1.1 is that this is the widely > deployed version. > > I see where I am creating confusion. I should distinguish better that I expect solution providers to still support MQTT v3.1 clients by implementing both MQTT v5 and MQTT v3.1.1 servers, as you said because 3.1.1 is widely deployed. I was not meaning spec backward compatibility. > Regarding the broker term: It is probably a matter of taste but I would > refer to the terms used in the spec and would not replicate the terminolo= gy > from the OASIS MQTT specs in the draft. Someone who implements the draft will have to become familiar with MQTT > anyway. But that=E2=80=99s just me. For example, I often see people using= the term > =E2=80=9Ccertificate authorities (CA)=E2=80=9D in their write-ups. RFC 52= 80 defines and > uses the term =E2=80=9Ccertification authority (CA)". While the two sound= and look > similar only one is actually correct. > OK, you suggest we use MQTT server. I expect broker is more widely-used in practice, and it is not a misspelling of another term either. I would want to keep it, but I would like to see if others prefer MQTT server rather. > > I noticed you have put a normative dependency on > [I-D.palombini-ace-coap-pubsub-profile]. I don't think it is necessary > because it is not a requirement to implement the spec. You could use it on top of it -- or you could use something else as well. I > would move it to the informative part. The added benefit of doing that i= s > that you do not block your spec till that draft becomes RFC. True. Will fix. > On the other hand, RFC 6749, RFC 7800, and > I-D.ietf-ace-cwt-proof-of-possession cannot be informative references whe= n > you use PoP tokens in your solution. > > Yes, indeed. Will fix. > You might be interesting to hear that there is currently no way to obtain > the keys for a PoP token over HTTP, which your solution requires. The > virtual interim meeting in the OAuth group should probably be of interest > to you. > I plan to join. I have been aware of the issue, but could not follow how it was planned to be resolved. I was looking at this: draft-ietf-oauth-pop-key-distribution Thanks again, --Cigdem > > From: Cigdem Sengul > Sent: Tuesday, February 25, 2020 3:10 PM > To: Hannes Tschofenig > Cc: ace@ietf.org > Subject: Re: [Ace] draft-ietf-ace-mqtt-tls-profile-03 > > Hello Hannes, > > We used broker as it is a widely accepted term in the MQTT Community for > "server" e.g., > majority of the provider would list also a broker implementation to refer > to their server implementation. > > With respect to whether 3.1,1 clients talking to v5, there may be some > issues. This is what the spec says: > > Non-normative Comment > If the Server distributes Application Messages to Clients at different > protocol levels (such as MQTT V3.1.1) which do not support properties or > other features provided by this specification, some information in the > Application Message can be lost, and applications which depend on this > information might not work correctly. > > The spec also defines a protocol version error message: > If the [Client's] Protocol Version [in the CONNECT packet] is not 5 and > the Server does not want to accept the CONNECT packet, the Server MAY sen= d > a CONNACK packet with Reason Code 0x84 (Unsupported Protocol Version) and > then MUST close the Network Connection > > So, whether a broker provides dual support would depend on the provider. > E.g., the Mosquitto broker supports the different protocol versions. > > Thanks, > --Cigdem > > On Tue, Feb 25, 2020 at 10:01 AM Hannes Tschofenig Hannes.Tschofenig@arm.com> wrote: > Hi Cigdem, Hi Anthony, Hi Paul, > > Why are you using the term MQTT broker? My understanding of the MQTT spec > is that there are only clients and servers - nothing more. > > Is a MQTT v3.1.1 client able to talk to a MQTT v5 server? Would a MQTT > v3.1.1 client talk to a MQTT v5 client via a server that supports both > v3.1.1 and v5? > > Ciao > Hannes > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > > _______________________________________________ > Ace mailing list > mailto:Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > --000000000000f7b140059f9fb250 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Hannes,=C2=A0

Th= ank you very much for your comments. My responses are inside.
=
From the text you cited regarding MQTT v5 it is not backwards compatibl= e to version 3.1.1. The exact impact of working between two devices of diff= erent versions has not been described in the spec either. The follow senten= ce in your introduction can easily give readers the impression that the two= versions are backwards compatible. Here is the sentence:

" It is expected that MQTT
=C2=A0 =C2=A0deployments will retain backward compatibility for MQTT v3.1.1=
=C2=A0 =C2=A0clients, and therefore, this document also describes a reduced= set of
=C2=A0 =C2=A0protocol interactions for MQTT v3.1.1 - the OASIS Standard
=C2=A0 =C2=A0[MQTT-OASIS-Standard].
"=C2=A0

Maybe you want to change the wording a little bit.=C2=A0 I think the reason= why you want to describe a solution for v3.1.1 is that this is the widely = deployed version.



I see where I am c= reating confusion. I should distinguish=C2=A0better that I expect solution = providers to still support MQTT v3.1 clients by implementing both MQTT v5 a= nd MQTT v3.1.1 servers, as you said because 3.1.1 is widely deployed. I was= not meaning spec backward compatibility.=C2=A0

<= div>=C2=A0
Regarding the broker term: It is probably a matter of taste but I would ref= er to the terms used in the spec and would not replicate the terminology fr= om the OASIS MQTT specs in the draft.=C2=A0
Someone who implements the draft will have= to become familiar with MQTT anyway. But that=E2=80=99s just me. For examp= le, I often see people using the term =E2=80=9Ccertificate authorities (CA)= =E2=80=9D in their write-ups. RFC 5280 defines and uses the term =E2=80=9Cc= ertification authority (CA)". While the two sound and look similar onl= y one is actually correct.

OK, you suggest we use MQTT server. I expect broker is more widely-used in = practice, and it is not a misspelling of another term either. I would want = to keep it, but I would like to see if others prefer MQTT server rather.
=C2=A0=C2=A0

I noticed you have put a normative dependency on [I-D.palombini-ace-coap-pu= bsub-profile]. I don't think it is necessary because it is not a requir= ement to implement the spec.=C2=A0
You could use it on top of it -- or you could use som= ething else as well. I would move it to the informative part.=C2=A0 The added benefit of doing that is that you do not block your spec till tha= t draft becomes RFC.=20
=C2=A0 True. Will fix.=C2=A0=C2=A0
=C2=A0
On the other hand, RF= C 6749, RFC 7800, and I-D.ietf-ace-cwt-proof-of-possession cannot be inform= ative references when you use PoP tokens in your solution.

Yes, indeed. Will fix.
=C2=A0
You might be interesting to hear that there is currently no way to obtain t= he keys for a PoP token over HTTP, which your solution requires. The virtua= l interim meeting in the OAuth group should probably be of interest to you.=

I plan to join. I=C2=A0 have been awar= e of the issue, but could not follow how it was planned to be resolved.=C2= =A0
I was looking at this:=C2=A0draft-ietf-oauth-pop-ke= y-distribution

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

From: Cigdem Sengul <cigdem.sengul@gmail.com>
Sent: Tuesday, February 25, 2020 3:10 PM
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: ace@ietf.org
Subject: Re: [Ace] draft-ietf-ace-mqtt-tls-profile-03

Hello Hannes,

We used=C2=A0 broker as it is a widely accepted term in the MQTT Community = for "server" e.g.,
majority of the provider would list also a broker implementation to refer t= o their server implementation.

With respect to whether 3.1,1 clients talking to v5, there may be some issu= es. This is what the spec says:

Non-normative Comment
If the Server distributes Application Messages to Clients at different prot= ocol levels (such as MQTT V3.1.1) which do not support properties or other = features provided by this specification, some information in the Applicatio= n Message can be lost, and applications which depend on this information mi= ght not work correctly.

The spec also defines a protocol version error message:
If the [Client's] Protocol Version [in the CONNECT packet] is not 5 and= the Server does not want to accept the CONNECT packet, the Server MAY send= a CONNACK packet with Reason Code 0x84 (Unsupported Protocol Version) and = then MUST close the Network Connection

So, whether a broker provides dual support would depend on the provider. E.= g., the Mosquitto broker supports the different protocol versions.

Thanks,
--Cigdem

On Tue, Feb 25, 2020 at 10:01 AM Hannes Tschofenig <mailto:Hannes.Tschofenig@arm.com= > wrote:
Hi Cigdem, Hi Anthony, Hi Paul,

Why are you using the term MQTT broker? My understanding of the MQTT spec i= s that there are only clients and servers - nothing more.

Is a MQTT v3.1.1 client able to talk to a MQTT v5 server? Would a MQTT v3.1= .1 client talk to a MQTT v5 client via a server that supports both v3.1.1 a= nd v5?

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you.

_______________________________________________
Ace mailing list
mailto:Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you.
--000000000000f7b140059f9fb250-- From nobody Fri Feb 28 02:07:53 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 194053A1517 for ; Fri, 28 Feb 2020 02:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=w9eW2pyp; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=w9eW2pyp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnWHjEwDFhZP for ; Fri, 28 Feb 2020 02:07:48 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20057.outbound.protection.outlook.com [40.107.2.57]) (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 159FF3A1515 for ; Fri, 28 Feb 2020 02:07:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8ZSKlLSkbAAxXSt+HMYw78yjRkqNJ31N+vFnvcjN2x0=; b=w9eW2pyp/v9MGvIphTzK3QYdOEMIVmAkRueUBDyBVTgRcd8dLWTEp9UJdeeGXxxv8Jj9MbrDvgHMgExF8QTnEd9OM4gCjQxOIr/Ui5QlE5q0NF+fT+jstGa75jeZdLuQCBK5QvgDzujwLA14zxwgVXBifElpsDX2Zar+9bL7PgQ= Received: from VI1PR08CA0223.eurprd08.prod.outlook.com (2603:10a6:802:15::32) by DB8PR08MB5018.eurprd08.prod.outlook.com (2603:10a6:10:e2::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.21; Fri, 28 Feb 2020 10:07:44 +0000 Received: from VE1EUR03FT004.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e09::205) by VI1PR08CA0223.outlook.office365.com (2603:10a6:802:15::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.15 via Frontend Transport; Fri, 28 Feb 2020 10:07:44 +0000 Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT004.mail.protection.outlook.com (10.152.18.106) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.15 via Frontend Transport; Fri, 28 Feb 2020 10:07:44 +0000 Received: ("Tessian outbound 0420f1404d58:v42"); Fri, 28 Feb 2020 10:07:44 +0000 X-CR-MTA-TID: 64aa7808 Received: from 27df4a43891c.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 0727F0E7-4192-43FF-AF92-2DDCD7A5D612.1; Fri, 28 Feb 2020 10:07:38 +0000 Received: from EUR05-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 27df4a43891c.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 28 Feb 2020 10:07:38 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QgHzW725SejAAjm1dX0j1KZ1DrFtwJGpA8PiTlURkjdkPT+bJjGWhzxddoUv7WM2MZWlgXI0oHRUp9U44qfGZT/sz6bD9S/FpSy1JWNn/ArQEdLa8AtMgLsy4DuVjIHRdjHoZZsylqZt2K5y6dgN8PKcOGahfl0vV+Gni6/y8m6OA6cG2kXAdSinb3hl2f//AepE23ujaB88+I+UjG5h9dj2fZHwqv6/2zVQIposzjiIMMNBsa0iWq40dscD9Rq5vGA928sDrXROAc2kRHoAGwlXh6AQikzSZjHKw7Mat4Z5o15CglEqXuWBRjhulKMxyXZheWfJl2+xOXgHZNT8pw== 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=8ZSKlLSkbAAxXSt+HMYw78yjRkqNJ31N+vFnvcjN2x0=; b=DtjvvNGkLxFgesZhXmN3clHCQAy4PtUiwbv5Lz0Lzq8GKQk1Fk4udStvalfTgZnMSBIdkETZLJzIfhixWk9stpkQKNiEVNRHiwCmveYNS/JYtInH2IfaQzueTUPWCIVhk6Gg4I1ZczaBDRYuk7fiuIDXHACl69WIPqxiVPXufLNOEmZpUOn4ogMdfa/Q6GqezKw9dx1ejMv6lD6juyuq46SEyD9Eq0rF6ncALA8TcBHT26Mx1ilSp7n9cYUnO5eC3q2JVhaiYbh7r0ke9Sslv1/55MpIEh6roxwPEHe84U3IR7hA6N0MB2vlMtqDsU5OWX04BOAhxSXRN0qQnEblbQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8ZSKlLSkbAAxXSt+HMYw78yjRkqNJ31N+vFnvcjN2x0=; b=w9eW2pyp/v9MGvIphTzK3QYdOEMIVmAkRueUBDyBVTgRcd8dLWTEp9UJdeeGXxxv8Jj9MbrDvgHMgExF8QTnEd9OM4gCjQxOIr/Ui5QlE5q0NF+fT+jstGa75jeZdLuQCBK5QvgDzujwLA14zxwgVXBifElpsDX2Zar+9bL7PgQ= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (20.178.23.205) by AM0PR08MB3618.eurprd08.prod.outlook.com (20.177.109.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.14; Fri, 28 Feb 2020 10:07:37 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::2159:870b:25df:e612]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::2159:870b:25df:e612%5]) with mapi id 15.20.2772.018; Fri, 28 Feb 2020 10:07:37 +0000 From: Hannes Tschofenig To: Cigdem Sengul CC: "ace@ietf.org" Thread-Topic: [Ace] draft-ietf-ace-mqtt-tls-profile-03 Thread-Index: AdXrwPKVlOWry/rCSraJ6rVcwUtPZQAJFd8AAFsSKHAAMo6agAAAuhVQ Date: Fri, 28 Feb 2020 10:07:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 7d56ee64-dcb6-4e98-8db5-5dbb5e8fde48.1 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.119.84] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 4be23521-2b1b-486f-0bb5-08d7bc360dca X-MS-TrafficTypeDiagnostic: AM0PR08MB3618:|DB8PR08MB5018: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:10000; x-forefront-prvs: 0327618309 X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(366004)(376002)(39860400002)(396003)(199004)(189003)(316002)(186003)(6506007)(26005)(66476007)(66446008)(64756008)(66556008)(66946007)(76116006)(4744005)(7696005)(52536014)(5660300002)(2906002)(33656002)(55016002)(9686003)(4326008)(86362001)(71200400001)(6916009)(478600001)(8936002)(81166006)(81156014)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR08MB3618; H:AM0PR08MB3716.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 33Z0ujy44/sLqQLZ1C6PFzU99aYGh2Tk/5A/UxPR/X+sHlVXmhwWqAMer6Yuy9FFLdplhIyAfPxuEnSwJH0OXQ5pQzmQgWC5a73VHVY8u9hbsnaX6lzYk1DgpzsiSigRhCmfvrBn5KRPRvk1UEq+f+4E4jLViKE1kLjVEbw9x9slyDd5bcrt9ssNtervykxUIYXwF3q4PhFGPXJX0RTyihxfquSwf7z0etO9ieG2V784M38QAQ6j9g8IhnxnyypxHZj3kbwfim+hLQpzkCapqNoGuYvpYsvEcDHnJjVvWGHBjQHN2xbYnzBWir3VmETOXgvHa7MWajmh2SPjUWAxjofXeEb3CFQzZ9t6+cO7JCTqr7B12T7PI0sZw31pnvky8Tljnb5hQfKogMR/Ae/4k3RV2XuGvkqf9sF3hB8fUlqGtbaEZqm78mLuY1QLqzr0 x-ms-exchange-antispam-messagedata: i38Lv/eaDDLZ1iD3oGSKASb/CLcwpDgICIVKKC34WJJ8cZbSQGr3SR5N80rHef+SQ+B2gPFBkeT745HmWJ/2Rorb0+9+qSu1/uKiy9HGggbDkrqT0ltJvJ9cep7LA3SREmhBzM2/IGpRxcTkMm4YcQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR08MB37160FD0F8B34F8C1470EE82FAE80AM0PR08MB3716eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3618 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT004.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; IPV:CAL; SCL:-1; CTRY:IE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(346002)(136003)(396003)(199004)(189003)(26005)(7696005)(4326008)(478600001)(6506007)(8936002)(316002)(33964004)(36906005)(6862004)(26826003)(9686003)(81156014)(86362001)(70206006)(70586007)(356004)(8676002)(2906002)(33656002)(52536014)(55016002)(81166006)(336012)(186003)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB8PR08MB5018; H:64aa7808-outbound-1.mta.getcheckrecipient.com; FPR:; SPF:Pass; LANG:en; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; A:1; MX:1; X-MS-Office365-Filtering-Correlation-Id-Prvs: c4214d11-c78c-41e1-4742-08d7bc3609e7 X-Forefront-PRVS: 0327618309 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: UdyEVt5J1wWEsC1aM3fp4LNs8/r/f/40BTPBHoR7/BNQBNOwJE7DFJHB5qasw2ndmkJvYYI7MtU6Q8BcZkj5W8UfCMIOonEVEEdleQvWpPQMCaylZNzFnZmugyS6mFrSciIad64WAJYKkWBg8o7ElIs991ZuSfwi6coRMKW8kJCbi6fsGE9ClyP4ZLBNJDDkSAa4Fe6WXfxa6qdxXs54B1IS0cQmWM75KglyXy0dAAwEJLPRvS20YHLWlD7GdJrk6UFsJXguCMhzwHOuZmQTvxVbVkAznyEDbh4m5rTbm+6i1dWwQQMYn5H1b0Jrov9xwVIxmjKAuxcDtHCPLTJgnISljN14vozxBTphtAw68OfzdkVIrFpBoD+KqZuOgCGWpQBB0DtUeSU5gYxtw+BlmVUM4JeEolvWBG+d08AA/lyZUdGSXeeRUocxCRI/dWgQ X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Feb 2020 10:07:44.0424 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4be23521-2b1b-486f-0bb5-08d7bc360dca X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR08MB5018 Archived-At: Subject: Re: [Ace] draft-ietf-ace-mqtt-tls-profile-03 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: Fri, 28 Feb 2020 10:07:52 -0000 --_000_AM0PR08MB37160FD0F8B34F8C1470EE82FAE80AM0PR08MB3716eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgSSBwbGFuIHRvIGpvaW4uIEkgIGhhdmUgYmVlbiBhd2FyZSBvZiB0aGUgaXNzdWUsIGJ1 dCBjb3VsZCBub3QgZm9sbG93IGhvdyBpdCB3YXMgcGxhbm5lZCB0byBiZSByZXNvbHZlZC4NCiAg KiAgIEkgd2FzIGxvb2tpbmcgYXQgdGhpczogZHJhZnQtaWV0Zi1vYXV0aC1wb3Ata2V5LWRpc3Ry aWJ1dGlvbg0KDQpZZXMsIHRoYXTigJlzIHdoYXQgdGhlIGdyb3VwIHdhbnRlZCB0byBkby4gTm93 LCBuZXcgaWRlYXMgc2hvd2VkIHVwIG9uIHRoZSByYWRhciB0aGF0IGFyZSBpbmNvbXBhdGlibGUg d2l0aCB0aGF0IGFwcHJvYWNoIHRoYXQgb2ZmZXIgYSBtdWNoIHRpZ2h0ZXIgaW50ZWdyYXRpb24g d2l0aCBIVFRQIHNpZ25pbmcuDQoNCkNpYW8NCkhhbm5lcw0KDQoNCklNUE9SVEFOVCBOT1RJQ0U6 IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZp ZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGlu dGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFu ZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBp dCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFu eSBtZWRpdW0uIFRoYW5rIHlvdS4NCg== --_000_AM0PR08MB37160FD0F8B34F8C1470EE82FAE80AM0PR08MB3716eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJcGFub3NlLTE6MiAx IDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEBEZW5nWGlhbiI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuTXNvTGlzdFBhcmFn cmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0 eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21w b3NlOw0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjUzODMx OTc0NTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTExMzAyMjcxMDA7fQ0KQGxpc3QgbDA6bGV2 ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMQ0KCXttc28tbGlzdC1pZDoxNTcxMjM1NDIxOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczot Mzg0Nzg1ODQ4O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MjA0OTg2NTYxODsN Cgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTExMjYzNjkz NDYgMTU0MjEwNDA0MiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5 MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxl dmVsLXN0YXJ0LWF0OjI7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpEZW5nWGlhbjsNCgltc28tYmlkaS1m b250LWZhbWlseTpDYWxpYnJpO30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6 bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDgNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwy OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGlu IiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjBpbjttc28tbGlzdDpsMiBsZXZlbDEgbGZvMyI+SSBwbGFuIHRvIGpvaW4uIEkmbmJz cDsgaGF2ZSBiZWVuIGF3YXJlIG9mIHRoZSBpc3N1ZSwgYnV0IGNvdWxkIG5vdCBmb2xsb3cgaG93 IGl0IHdhcyBwbGFubmVkIHRvIGJlIHJlc29sdmVkLiZuYnNwOzxvOnA+PC9vOnA+PC9saT48ZGl2 Pg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21z by1saXN0OmwyIGxldmVsMSBsZm8zIj5JIHdhcyBsb29raW5nIGF0IHRoaXM6Jm5ic3A7PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjtjb2xv cjpibGFjayI+ZHJhZnQtaWV0Zi1vYXV0aC1wb3Ata2V5LWRpc3RyaWJ1dGlvbjwvc3Bhbj48bzpw PjwvbzpwPjwvbGk+PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcywgdGhhdOKAmXMgd2hhdCB0aGUgZ3JvdXAg d2FudGVkIHRvIGRvLiBOb3csIG5ldyBpZGVhcyBzaG93ZWQgdXAgb24gdGhlIHJhZGFyIHRoYXQg YXJlIGluY29tcGF0aWJsZSB3aXRoIHRoYXQgYXBwcm9hY2ggdGhhdCBvZmZlciBhIG11Y2ggdGln aHRlciBpbnRlZ3JhdGlvbiB3aXRoIEhUVFAgc2lnbmluZy4NCjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5DaWFvPGJyPg0KSGFubmVzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvdWw+DQo8L2Rpdj4NCklNUE9SVEFOVCBOT1RJQ0U6 IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZp ZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGlu dGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFu ZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBp dCBmb3IgYW55IHB1cnBvc2UsDQogb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4g YW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_AM0PR08MB37160FD0F8B34F8C1470EE82FAE80AM0PR08MB3716eurp_-- From nobody Fri Feb 28 14:39: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 097663A1F95; Fri, 28 Feb 2020 14:35:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: kaduk@mit.edu, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158292932802.19931.17231972515767796548@ietfa.amsl.com> Date: Fri, 28 Feb 2020 14:35:28 -0800 Archived-At: Subject: [Ace] ace - Requested session has been scheduled for IETF 107 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: Fri, 28 Feb 2020 22:35:35 -0000 Dear Daniel Migault, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. ace Session 1 (1:30 requested) Wednesday, 25 March 2020, Afternoon Session I 1330-1500 Room Name: Georgia A size: 100 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/107/sessions/ace.ics Request Information: --------------------------------------------------------- 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): 1.5 Hours Number of Attendees: 30 Conflicts to Avoid: Chair Conflict: tmrid calext cbor lamps Technology Overlap: teep lake tls oauth t2trg suit core cose Key Participant Conflict: secdispatch saag ipsecme cfrg lwig emu homenet dnsop abcd People who must be present: Daniel Migault Jim Schaad Benjamin Kaduk Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Feb 28 15:14: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 5B6AD3A1D7B; Fri, 28 Feb 2020 15:14:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 ES3ef0pgZ7Ge; Fri, 28 Feb 2020 15:14:02 -0800 (PST) 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 BB3B93A1E33; Fri, 28 Feb 2020 15:14:01 -0800 (PST) Received: from [172.16.42.113] (p548DC4D8.dip0.t-ipconnect.de [84.141.196.216]) (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 48Tlj32lpmz1802; Sat, 29 Feb 2020 00:13:59 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 604624438.807252-ba49cb160872526025462a7291810c55 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Sat, 29 Feb 2020 00:13:58 +0100 Message-Id: <0CE57F79-ADE0-45D5-9142-D79F687DC2A1@tzi.org> To: Ace Wg , "core@ietf.org WG" , cose@ietf.org, cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: [Ace] Constrained Node/Network Cluster @ IETF107: FINAL AGENDA 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: Fri, 28 Feb 2020 23:14:06 -0000 Here is my usual eclectic condensed agenda based on the FINAL AGENDA for IETF107. Remember that, occasionally, futher agenda changes do happen. Not much change from the DRAFT AGENDA. SUIT has moved to Friday, now on top of 6lo. The other security/not-so-much-security conflicts in the IoT space remain or have just been rearranged: ROLL vs. COSE/TEEP, LPWAN vs. SAAG, and LAKE vs. RATS, WPACK vs. ACE; as are MODEL-T vs. CORE and TXAUTH vs. T2TRG. (A lot of the rooms have changed.) All times are in PDT =3D=3D UTC - 7 hours. Note that North America is = on DST already during the IETF, while Europe will only go there on March 29, so we are in the three-week period of DST confusion (where the US is one hour closer to the EU than the rest of the year). (Pure UTC times at https://datatracker.ietf.org/meeting/agenda-utc are useful for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten FRIDAY, March 20, 2020 0900-1800 T2TRG/W3C WoT Workshop = https://github.com/t2trg/2020-03-vancouver SATURDAY, March 21, 2020 0830-2200 IETF Hackathon - Plaza Ballroom SUNDAY, March 22, 2020 0830-1600 IETF Hackathon - Plaza Ballroom 1700-1900 Welcome Reception - Regency A/B/C/D 1800-2000 Hot RFC Lightning Talks -- Plaza B/C MONDAY, March 23, 2020 1000-1200 Morning Session I Regency D ART dispatch Dispatch WG - Joint with ARTAREA Regency C INT 6man IPv6 Maintenance WG Plaza B/C IRTF pearg Privacy Enhancements and Assessments = Research Group 1330-1530 Afternoon Session I Regency C ART webtrans WebTransport WG Regency D IRTF maprg Measurement and Analysis for Protocols Georgia B SEC mls Messaging Layer Security WG Regency E SEC oauth Web Authorization Protocol WG Plaza A SEC *** rats Remote ATtestation ProcedureS WG 1550-1750 Afternoon Session II Regency F INT add Adaptive DNS Discovery WG Regency C IRTF irtfopen IRTF Open Meeting Regency E OPS anima Autonomic Networking Integrated Model = and Approach WG Plaza A RTG raw Reliable and Available Wireless WG Plaza B/C SEC secdispatch Security Dispatch WG 1810-1910 Afternoon Session III Plaza A RTG *** roll Routing Over Low power and Lossy = networks WG Georgia B SEC *** cose CBOR Object Signing and Encryption WG Plaza B/C SEC tls Transport Layer Security WG Regency C TSV tsvarea Transport Area Open Meeting TUESDAY, March 24, 2020 0830-0945 Side Meetings / Open Time Regency C tdd Technology Deep Dive 1000-1200 Morning Session I Regency D IRTF*** dinrg Decentralized Internet Infrastructure Regency F SEC acme Automated Certificate Management = Environment WG Regency E SEC *** teep Trusted Execution Environment = Provisioning WG Plaza B/C TSV quic QUIC WG 1330-1530 Afternoon Session I Regency C INT masque Multiplexed Application Substrate over = QUIC Encryption BOF Regency D IRTF coinrg Computing in the Network Research Group Georgia A RTG *** roll Routing Over Low power and Lossy = networks WG Regency E SEC emu EAP Method Update WG Georgia B SEC *** teep Trusted Execution Environment = Provisioning WG 1550-1720 Afternoon Session II Regency F ART *** core Constrained RESTful Environments WG Plaza A IRTF qirg Quantum Internet Proposed Research Group Georgia B SEC oauth Web Authorization Protocol WG Regency C TSV tsvwg Transport Area Working Group WG 1740-1840 Afternoon Session III Regency C INT 6man IPv6 Maintenance WG Georgia B INT *** drip Drone Remote ID Protocol WG Georgia A RTG babel Babel routing protocol WG Regency D RTG detnet Deterministic Networking WG Regency E RTG rift Routing In Fat Trees WG Plaza B/C TSV quic QUIC WG WEDNESDAY, March 25, 2020 1000-1200 Morning Session I Georgia B IRTF*** t2trg Thing-to-Thing Georgia A RTG bier Bit Indexed Explicit Replication WG Regency D SEC txauth Transactional Authorization and = Delegation BOF Plaza B/C TSV quic QUIC WG 1330-1500 Afternoon Session I Regency C ART wpack Web Packaging BOF Regency E IRTF panrg Path Aware Networking RG Georgia A SEC *** ace Authentication and Authorization for = Constrained Environments WG 1520-1650 Afternoon Session II Plaza A ART *** core Constrained RESTful Environments WG Georgia A IAB model-t Internet Threat Model Plaza B/C RTG rtgarea Routing Area Open Meeting 1710-1940 IETF Plenary - Regency C/D/E/F THURSDAY, March 26, 2020 1000-1200 Morning Session I Georgia A ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Georgia B INT dnssd Extensions for Scalable DNS Service = Discovery WG - Joint with HOMENET Georgia B INT homenet Home Networking WG - Joint with DNSSD Regency E IRTF icnrg Information-Centric Networking Regency C SEC privacypass privacy-pass BOF Plaza B/C TSV taps Transport Services WG 1330-1530 Afternoon Session I Regency E INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Regency F OPS v6ops IPv6 Operations WG Regency D SEC saag Security Area Open Meeting 1550-1720 Afternoon Session II Regency C ART httpbis HTTP WG Regency E INT intarea Internet Area Working Group WG Regency D IRTF cfrg Crypto Forum Plaza B/C RTG detnet Deterministic Networking WG 1740-1840 Afternoon Session III Plaza A ART uta Using TLS in Applications WG Regency D OPS anima Autonomic Networking Integrated Model = and Approach WG FRIDAY, March 27, 2020 1000-1200 Morning Session I Regency F INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Regency E SEC *** suit Software Updates for Internet of Things = WG Regency C SEC tls Transport Layer Security WG Plaza B/C TSV tsvwg Transport Area Working Group WG 1220-1350 Morning Session II Regency D ART httpbis HTTP WG Regency C IRTF coinrg Computing in the Network Research Group Regency F SEC *** lake Lightweight Authenticated Key Exchange = WG Plaza A SEC *** rats Remote ATtestation ProcedureS WG From nobody Sat Feb 29 06:38: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 2D37A3A0BE2; Sat, 29 Feb 2020 06:38:46 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=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 (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwQ0qqtsF20c; Sat, 29 Feb 2020 06:38:44 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 A0F6C3A0BDD; Sat, 29 Feb 2020 06:38:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1582987120; bh=4l9k+/dLmGrTCUjuW07KaRCBjV4xalfvvgXUEQ1j6PQ=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=khOX0Gk9xMIaMYID9TUSXvl28gHI53Eyvp+mHtIGfkum+3Dtgd33D0cMa0rA1NyBx smz7BwEjjuqu4lgMTgKb9r43bN/XZ/emqqjxI6pMo698V0dAZbjbWGRuBrfaG3KKga r4l+6tVil40vArp7ltou806G1tWTM29Tmi+DE900= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.220] ([84.217.44.37]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MJE2D-1inuxr3Rf9-00KdFp; Sat, 29 Feb 2020 15:25:00 +0100 To: drafts-expert-review@iana.org, cwt-reg-review@ietf.org Cc: "ace@ietf.org" , "draft-ietf-ace-oauth-authz@ietf.org" References: <03f0f73f-4c82-9089-0a81-471a5fb54ba8@gmx.de> From: Ludwig Seitz Message-ID: <4788cad0-d1dc-2947-9e17-cad4f2147a7b@gmx.de> Date: Sat, 29 Feb 2020 15:24:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:gzXLZYAxmB9Gz5+h8TUc7qBBXnQ8BCBEATgqLaWHD/C55CIZVnA uVfyczOuO065irWujV8J+Gl6CfGNxHV7zLTLX1NdzMY6yVZv3wGc/yt3iCXAf9cGBTZQ35o zlezkMdScz8aiw8vX3R6eRYpWvjYv7N4O6V0ezjgiI5DPMqtuVu2aCEZroSObySTGWZtQag 3/NoUsO380j1xZ8Hv6wIw== X-UI-Out-Filterresults: notjunk:1;V03:K0:O0CRZAQzvvI=:qAk7XgaFi+IjYbWyCudl4W k4V7AnxA4uVdST1U1HNjwt3WhRtKBWRVbxKyVeXz0hwftvk033wwAeRKMgoZf/i2UaNxCT2gR WCGvhgezQbOyEMFPLvOI0V4nyd+EBFxxnBdz+d7jHGLkuwsS13iEyU2GiYuM1A3XO5PllOyF8 RxwFnxsH/8bP5CsO24TZ1k6OYiFguxxvBqbJn8HwTs/rvdg1J7l6usHYEWcnGJKGoOyvZHyhB CzdNB1zXnustUnjczeYOH7tK7tGXTyv37OzOcfchJiMivU1qZVY+c1SjO293svkpCE4RYioi3 KBn+uxadPuhT8TlZnc3rtd1pIETGW01+Jp+ZUL6eWyEd+6DMpdyDpF4S/PBnucVXFpzZsMQmG F7HTAQ1pejpcueZ1kEG5hguRyNZizxxXajTNgCGqLcx7Ob/6Prib148CAmIZYyGW01vnArJqH +BwrnP+X1qmoTWDmJF8qxSSdlhndtR6JIRuHOUxGE8uhQc2G95BrRtL6929ByVCAs7MKDluX7 zqnivgtQ/leFNEISAXNS/KHjIZuwiXtX5nP+jSJkpfNjVuij35WYBaA57P4wFWuKuV0SAEGT4 8bNiS+zhdSe5RnRirl0QrGHu6yWp01ZU3yW35gEqHilv1C8Obn5OL7f4lOjKKJk5La5jycr/l qW94KoIlBRoFLFsREp+h76gGoyac6/TJ8GUBjg7ks56BB0rCBJ2u1e74NThvvJz2fXFRkw2yd 2hWYMxlQ9JmWv9E5EUGBGWscQXemWOdWdvWYLeOItEKcwmuk3LZIwX2pgC4mAHmCi1PpmugVd hXId2zlS3TDHhFm0SLcPIG7fCA5vS/BPYbMUZGbFoSs++x8T0yBaUpCfvQLYnshn7XTmEAsRK Zio9IR6LXfKbMqwtjz85AHABZiy/qxMueRNWAZZnuTSsjSK6upS591f6io0RCVcJBtP8E51t9 cFrfdsFvBdEWGx8ypxAZ8ULF5bL6iu//2xxZ+rIhEI9tvrI/xYg/Lp2+MPfBLObEWjpeZLtTz 6yExWvJIEEYJPV0G9VCLRGntIhtPj9Kzohe/9S9+dfQwpYeKjQEf9mHScEPDGpseFmibx8GTS EbzAhCwbQYAWMPnLNhEMwIlvH9RhrN6ea/lNl2JhV/1r30Hu0VxFNkVKCjUyEFop9T5q2lkSk ulaUNBdtTfyw+2pPszFmnriDsOW9CIqLCcKuYl5NPte2UK3TpqDV80mBUeH2kWpNjC+bUy19S 3ve9hH6kvJs6oZSa+ Archived-At: Subject: Re: [Ace] [IANA #1158953] Requested review for IANA registration in draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims) 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, 29 Feb 2020 14:38:47 -0000 On 2020-02-26 00:58, Amanda Baber via RT wrote: > Ludwig, Hannes, > > Can you confirm that you can make the CBOR Web Token Claim change > requested below? > > We also have Chuck Mortimore listed as an expert for this registry, > but our message to his Salesforce address bounced. > > Best regards, > > Amanda Baber Lead IANA Services Specialist > I strongly disagree with the assessment that the scope claim should be pushed into the two-byte range. The reason we introduced the scope claim is that an ACE RS typically does not have a direct connection to the AS, and is therefore unable to retrieve the scope of an access token from other sources than the access token itself. I therefore assert that ACE access tokens would often need to contain this claim in order to inform the RS. Since one of the major drivers of the ACE work has been to reduce the authorization overhead (otherwise we could just have used vanilla OAuth 2.0), I find it strange to needlessly add to the overhead by making the encoding of a frequently used claim longer than necessary. I am willing to listen to the arguments that have lead the expert reviewer to denying a value in the one-byte range, and discuss the reasoning further on list. Regards, Ludwig > On Tue Feb 18 22:42:22 2020, Michael.Jones@microsoft.com wrote: >> I'm mostly OK with these registrations, however, DO NOT assign the >> value 9 to "scope". Rather, please put it in the two-byte range >> - for instance, with the value 41. >> >> -- Mike >> >> -----Original Message----- From: Cwt-reg-review >> On Behalf Of Sabrina Tanamal via >> RT Sent: Tuesday, February 18, 2020 1:06 PM Cc: >> cwt-reg-review@ietf.org Subject: [EXTERNAL] [Cwt-reg-review] [IANA >> #1158953] Requested review for IANA registration in >> draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims) >> >> Hi all, >> >> Resending this request for draft-ietf-ace-oauth-authz. >> >> Thanks, >> >> Sabrina Tanamal Senior IANA Services Specialist >> >>> On Sat Dec 21 11:37:11 2019, ludwig_seitz@gmx.de wrote: >>>> Hello CWT registry reviewers, >>>> >>>> the IESG-designated experts for the CWT claims registry have >>>> asked me to send a review request to you about the claims >>>> registered here: >>>> >>>> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ft= o >>>> >>>> ols.ietf.org%2Fhtml%2Fdraft-ietf-ace-oauth-authz-29%23section- >>>> 8.13&a >>>> mp;data=3D02%7C01%7CMichael.Jones%40microsoft.com%7Ce23f64ac1ad74269c= 3 >>>> >>>> c408d7b4b65d45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63717656 >>>> 7656665548&sdata=3Dr01W5Bx0gJh9ZPH8eNS%2BY765CnGq11DkknsHYQ751Dk%= 3 >>>> >>>> D&reserved=3D0 >>>> >>>> Thank you in advance for you review comments. >>>> >>>> Regards, >>>> >>>> Ludwig >>>> >> >> _______________________________________________ Cwt-reg-review >> mailing list Cwt-reg-review@ietf.org >> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= .ietf.org%2Fmailman%2Flistinfo%2Fcwt- >> >> reg- >> review&data=3D02%7C01%7CMichael.Jones%40microsoft.com%7Ce23f64ac1ad= 74269c3c408d7b4b65d45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371765= 67656675543&sdata=3DXxBhQmqxGkCRiBxh0PdhX2IJD8TnbwWl%2Feo8VUsHOsg%3D&a= mp;reserved=3D0 >