From nobody Mon Oct 1 07:26:35 2018 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 53E02130E6F; Mon, 1 Oct 2018 07:26:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.85.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <153840397629.21683.3414013193539425000@ietfa.amsl.com> Date: Mon, 01 Oct 2018 07:26:16 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-oscore-profile-03.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 14:26:29 -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 : OSCORE profile of the Authentication and Authorization for Constrained Environments Framework Authors : Ludwig Seitz Francesca Palombini Martin Gunnarsson Göran Selander Filename : draft-ietf-ace-oscore-profile-03.txt Pages : 24 Date : 2018-10-01 Abstract: This memo specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Object Security for Constrained RESTful Environments (OSCORE) to provide communication security, server authentication, and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-profile/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-oscore-profile-03 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oscore-profile-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 2 01:33:43 2018 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 2A387130DD7; Tue, 2 Oct 2018 01:33:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.85.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <153846921409.5125.345954015678962174@ietfa.amsl.com> Date: Tue, 02 Oct 2018 01:33:34 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-oauth-authz-16.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: Tue, 02 Oct 2018 08:33:34 -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-16.txt Pages : 70 Date : 2018-10-02 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 CoAP, thus making a well-known and widely used authorization solution suitable for IoT devices. Existing specifications are used where possible, but where the constraints of IoT devices require it, extensions are added and profiles are defined. 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-16 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 2 01:35:40 2018 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 2E904130DD7 for ; Tue, 2 Oct 2018 01:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 W-RyT2FlPCtN for ; Tue, 2 Oct 2018 01:35:34 -0700 (PDT) Received: from smtp-out10.electric.net (smtp-out10.electric.net [185.38.180.36]) (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 B4F95130DE5 for ; Tue, 2 Oct 2018 01:35:34 -0700 (PDT) Received: from 1g7G9T-000DU5-TW by out10a.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1g7G9T-000DVU-UI for ace@ietf.org; Tue, 02 Oct 2018 01:35:31 -0700 Received: by emcmailer; Tue, 02 Oct 2018 01:35:31 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out10a.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1g7G9T-000DU5-TW for ace@ietf.org; Tue, 02 Oct 2018 01:35:31 -0700 Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 2 Oct 2018 10:35:30 +0200 References: <153846921439.5125.9306665639378083171.idtracker@ietfa.amsl.com> To: "ace@ietf.org" From: Ludwig Seitz X-Forwarded-Message-Id: <153846921439.5125.9306665639378083171.idtracker@ietfa.amsl.com> Message-ID: <4daf7229-0153-2a5e-e866-cce0082c91ad@ri.se> Date: Tue, 2 Oct 2018 10:35:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <153846921439.5125.9306665639378083171.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) X-PolicySMART: 14510320 Archived-At: Subject: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-16.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: Tue, 02 Oct 2018 08:35:39 -0000 Hello ACE, here is another update of draft-ietf-ace-oauth-authz with the following changes: * Added text on the RS using RFC6750 error codes. * Defined an error code for incompatible token request parameters. * Removed references to the actors draft. * Fixed errors in examples. -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-ace-oauth-authz-16.txt Date: Tue, 2 Oct 2018 01:33:34 -0700 From: internet-drafts@ietf.org To: Ludwig Seitz , Hannes Tschofenig , Goeran Selander , Samuel Erdtman , Erik Wahlstroem A new version of I-D, draft-ietf-ace-oauth-authz-16.txt has been successfully submitted by Ludwig Seitz and posted to the IETF repository. Name: draft-ietf-ace-oauth-authz Revision: 16 Title: Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) Document date: 2018-10-02 Group: ace Pages: 70 URL: https://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-authz-16.txt Status: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ Htmlized: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-16 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-16 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 CoAP, thus making a well-known and widely used authorization solution suitable for IoT devices. Existing specifications are used where possible, but where the constraints of IoT devices require it, extensions are added and profiles are defined. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Wed Oct 3 18:47:19 2018 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 C10BB130DCE for ; Wed, 3 Oct 2018 18:47:18 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 SszbpHrVFaNg for ; Wed, 3 Oct 2018 18:47:17 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C36EA128CFD for ; Wed, 3 Oct 2018 18:47:16 -0700 (PDT) Received: from Jude (192.168.0.11) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 3 Oct 2018 18:42:34 -0700 From: Jim Schaad To: Date: Wed, 3 Oct 2018 18:47:05 -0700 Message-ID: <037301d45b84$29065ac0$7b131040$@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: AdRbYYy5r/jk7lNmRgqSO7oPvlNH+g== Content-Language: en-us X-Originating-IP: [192.168.0.11] Archived-At: Subject: [Ace] JWT + OAuth Request 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, 04 Oct 2018 01:47:19 -0000 The OAuth group discovered a problem with some the names of our new OAuth fields that was caused by the fact that they have an ID that is someplace between the IESG and the RFC Editor which introduced the concept of using a JWT to as the transport for an OAuth request. This allows for doing end-to-end security on the OAuth request in the event it needs to be forwarded to another authorizer. Due to the design decision that they made, this was done by included all of the OAuth request fields as JWT claims thus combining the two namespaces. Based on this we now need to make a decision on what to do with our COSE versions of this. From my point of view we have two different options: 1. Ignore the problem and hope it goes away. 2. Deal with the problem by combining the current CWT registry with the OAuth registry that is going to be created. Why option 1 might be acceptable: A. The reason that they are doing this is because they want to get an E2E solution for requests. We have this already to some degree with the OSCORE profile of OAuth and could easily go the rest of the way by creating a COSE profile which allowed for full COSE rather than the restricted version of OSCORE. There may be some unknown benefits to using a JWT for this purpose, but I would then want to ask two questions: Is this really something that is useful and important? If is really that important or useful, why is it not part of the base OAuth protocol? B. If a CWT version is this is really needed, perhaps we can get a different design to be used. Specifically, create two new CWT claims: "oauth_req", "oauth_resp" and then place the OAuth parameters in those fields and not make them CWT claims. I am sure that there would be complaints about this, but much as COSE fixed problems that it saw as being wrong, the WG could do the same thing. Jim From nobody Wed Oct 3 23:48:11 2018 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 117A1130DC6 for ; Wed, 3 Oct 2018 23:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 pzMF48V_mEtY for ; Wed, 3 Oct 2018 23:48:07 -0700 (PDT) Received: from smtp-out11.electric.net (smtp-out11.electric.net [185.38.181.38]) (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 25664130DE6 for ; Wed, 3 Oct 2018 23:48:06 -0700 (PDT) Received: from 1g7xQa-000oGN-TO by out11d.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1g7xQa-000oGk-UB for ace@ietf.org; Wed, 03 Oct 2018 23:48:04 -0700 Received: by emcmailer; Wed, 03 Oct 2018 23:48:04 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out11d.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1g7xQa-000oGN-TO for ace@ietf.org; Wed, 03 Oct 2018 23:48:04 -0700 Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 4 Oct 2018 08:48:04 +0200 To: References: <037301d45b84$29065ac0$7b131040$@augustcellars.com> From: Ludwig Seitz Message-ID: <56b76a04-50d3-faa9-c136-d87c0c16d432@ri.se> Date: Thu, 4 Oct 2018 08:47:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <037301d45b84$29065ac0$7b131040$@augustcellars.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-1.sp.se (10.100.0.161) To sp-mail-2.sp.se (10.100.0.162) X-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) X-PolicySMART: 14510320 Archived-At: Subject: Re: [Ace] JWT + OAuth Request 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, 04 Oct 2018 06:48:10 -0000 On 04/10/18 03:47, Jim Schaad wrote: > The OAuth group discovered a problem with some the names of our new OAuth > fields that was caused by the fact that they have an ID that is someplace > between the IESG and the RFC Editor which introduced the concept of using a > JWT to as the transport for an OAuth request. This allows for doing > end-to-end security on the OAuth request in the event it needs to be > forwarded to another authorizer. Due to the design decision that they made, > this was done by included all of the OAuth request fields as JWT claims thus > combining the two namespaces. Based on this we now need to make a decision > on what to do with our COSE versions of this. From my point of view we have > two different options: > > 1. Ignore the problem and hope it goes away. > 2. Deal with the problem by combining the current CWT registry with the > OAuth registry that is going to be created. > > Why option 1 might be acceptable: > > A. The reason that they are doing this is because they want to get an E2E > solution for requests. We have this already to some degree with the OSCORE > profile of OAuth and could easily go the rest of the way by creating a COSE > profile which allowed for full COSE rather than the restricted version of > OSCORE. There may be some unknown benefits to using a JWT for this > purpose, but I would then want to ask two questions: Is this really > something that is useful and important? If is really that important or > useful, why is it not part of the base OAuth protocol? > > B. If a CWT version is this is really needed, perhaps we can get a different > design to be used. Specifically, create two new CWT claims: "oauth_req", > "oauth_resp" and then place the OAuth parameters in those fields and not > make them CWT claims. I am sure that there would be complaints about this, > but much as COSE fixed problems that it saw as being wrong, the WG could do > the same thing. > > Jim > I'm not sure if there really is a problem here. If an AS forwards a {C/J}WT to another AS, this would clearly not be an access token, meaning the claims can be interpreted accordingly. If there is room for confusion OAuth should define a token type such as e.g. "request_token" and make that a mandatory claim in the token or parameter of the request. Therefore I would lean towards option 1. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 From nobody Thu Oct 4 06:45:06 2018 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 B1AEB130E65 for ; Thu, 4 Oct 2018 06:45:03 -0700 (PDT) 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, 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 mSrn7OyTbrX2 for ; Thu, 4 Oct 2018 06:45:01 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52D97130EA4 for ; Thu, 4 Oct 2018 06:45:01 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id B19F420090; Thu, 4 Oct 2018 09:44:58 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 982BF1D24; Thu, 4 Oct 2018 09:44:59 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9563AAE8; Thu, 4 Oct 2018 09:44:59 -0400 (EDT) From: Michael Richardson To: Jim Schaad cc: ace@ietf.org In-Reply-To: <037301d45b84$29065ac0$7b131040$@augustcellars.com> References: <037301d45b84$29065ac0$7b131040$@augustcellars.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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] JWT + OAuth Request 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, 04 Oct 2018 13:45:04 -0000 --=-=-= Content-Type: text/plain Jim Schaad wrote: > The OAuth group discovered a problem with some the names of our new > OAuth fields that was caused by the fact that they have an ID that is > someplace between the IESG and the RFC Editor which introduced the Took a moment to realize that ID = Internet Draft, rather than being a reference a hash key id :-) (Which document is this?) > Why option 1 might be acceptable: ... > B. If a CWT version is this is really needed, perhaps we can get a > different design to be used. Specifically, create two new CWT claims: > "oauth_req", "oauth_resp" and then place the OAuth parameters in those > fields and not make them CWT claims. I am sure that there would be > complaints about this, but much as COSE fixed problems that it saw as > being wrong, the WG could do the same thing. I prefer this solution, but I feel unsufficiently informed about how the above ID might come back to bite us. (I can live with combining registries) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlu2GVsACgkQgItw+93Q 3WXmXwgAgW8YVnCbgO2Keu0yl3x26p9dy61Arc6IUEeyl4JYbBIaaJDBA2375MS4 l1TvMeezZr1mrplGXeGyF8m8z8AFyC7OwWsujYBUU2+YmzrlJbJUqQ5aAWCb86E0 I+Z34PXdhOiV7mG5imfTnH5DpwYsTn+1Cb0g6msgVhms2NqGhkYYFpxgDML0kk25 hzdDTj6KomGvtAZR6+o2q6FwGxOXu2wDRae5HQz57u3X3fETCrAB2cK1Q8gKF3VL WBALqh3ZyWCfh8ZoN5IaF0Hl/z1AWlS0+W9J08/QvLyMnGr2Pqsj29gMXa5AHgFv 9XOhFoIqrP8vMwNoRKaIH/Ag0WWCvw== =0WoE -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 4 08:00:41 2018 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 909C412958B for ; Thu, 4 Oct 2018 08:00:39 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 fLX_BU4vDGNu for ; Thu, 4 Oct 2018 08:00:36 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 023DC130E3C for ; Thu, 4 Oct 2018 08:00:36 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 4 Oct 2018 07:55:54 -0700 From: Jim Schaad To: 'Michael Richardson' CC: References: <037301d45b84$29065ac0$7b131040$@augustcellars.com> <20784.1538660699@localhost> In-Reply-To: <20784.1538660699@localhost> Date: Thu, 4 Oct 2018 08:00:26 -0700 Message-ID: <03d301d45bf2$fcc09600$f641c200$@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: AQFTZoccTLeV/bOEZ5u9yKg63nRqZALobkKPpfnVTrA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] JWT + OAuth Request 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, 04 Oct 2018 15:00:40 -0000 > -----Original Message----- > From: Michael Richardson > Sent: Thursday, October 4, 2018 6:45 AM > To: Jim Schaad > Cc: ace@ietf.org > Subject: Re: [Ace] JWT + OAuth Request > > > Jim Schaad wrote: > > The OAuth group discovered a problem with some the names of our new > > OAuth fields that was caused by the fact that they have an ID that is > > someplace between the IESG and the RFC Editor which introduced the > > Took a moment to realize that ID = Internet Draft, rather than being a > reference a hash key id :-) (Which document is this?) This is JWT Secured Authorization Request (JAR) https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ Jim > > > Why option 1 might be acceptable: > > ... > > > B. If a CWT version is this is really needed, perhaps we can get a > > different design to be used. Specifically, create two new CWT claims: > > "oauth_req", "oauth_resp" and then place the OAuth parameters in those > > fields and not make them CWT claims. I am sure that there would be > > complaints about this, but much as COSE fixed problems that it saw as > > being wrong, the WG could do the same thing. > > I prefer this solution, but I feel unsufficiently informed about how the above ID > might come back to bite us. > > (I can live with combining registries) > > -- > Michael Richardson , Sandelman Software Works - > = IPv6 IoT consulting =- > > From nobody Fri Oct 5 01:36:01 2018 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 B138E130DD5 for ; Fri, 5 Oct 2018 01:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 (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 gT6zfJCDiidy for ; Fri, 5 Oct 2018 01:35:55 -0700 (PDT) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 6BEA9130DE6 for ; Fri, 5 Oct 2018 01:35:55 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id 23-v6so5049862qkh.8 for ; Fri, 05 Oct 2018 01:35:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=R1WQj9gDFbDxTxyIzfnIYHhJrDcAE85Ts+Xkh6x3uUQ=; b=M3Z0RdFl1MycthsAo9h1n5OjVMP0dJJtMbu8JlR4doRx5SsUaiLy128u3uZpE/UDc7 6JdeghpTA/6G52PPLL8P8PIpVehvUxLYlrUHmoLjyhapkwGWZSgMLhRP3glOExkdstjo 1SgrhxZCE9otUi9fDDZtw69fcJbnoZstV4Ipj7yW0dohxTun/hJFaDrhA8CrtneC4u1+ tf+qKfXgjuCKGmve4+2svPOtd4n/bf2h9EyfliACQVw2ouz75LKWpZBuWdIAFqTIqjru Z+kE4HEyf9xPIGXMjlYnkM8wwjfxXdFab5ZGYWYOOmkUzYIXK8p8n1TlPwzVyU2MOsEY MZIg== 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=R1WQj9gDFbDxTxyIzfnIYHhJrDcAE85Ts+Xkh6x3uUQ=; b=OEI0Wc5QaUe1byLH09gK0gMvdfvzWJLnYj9JqVT8xU+YiEqjSKYq38h0w0xUz7bDDc KDOm4aMMgnzl0RPlfXCkA81vwhHVSRlHT+VR/C9aOjLwEE1vjiqAnlp4wqlRZpfGsUNf wJs8uniqyuhySAzLs2Y5zzPAUcRNZdx1A2YhcKf6PIQWQFWrO9r/8K4BAnfqwnN4Sd7a mBLrL10JfMlXe437/6cZZBoGHea3H10Rh/1sViuQjm14PJHmNhZAKXU8fD4nef7c3pWS 1YvSYH7QFPj37teTTaH5GJDCM7A0Sa04pkLgURMnL+MWPsV/WLw58zg9YmkNXnoHs7l5 72UA== X-Gm-Message-State: ABuFfohSYb0a6ZDoSKSARR7VyGxP2iQIAgy25ufqV2Afl+7fsUFqdGw3 AAX4Cr6lELT1vn4pQTjRB5fgVv5hiFj+TnF2lutIatQb X-Google-Smtp-Source: ACcGV61eNv72XJ2CsDvO4dRAkKbLVAY0zvQmP+FiIPphBZ3LsWk12vDEPmKmPYc51zjyP1eZ8bXK3NWfXGWuMYyRoyM= X-Received: by 2002:a37:1b4b:: with SMTP id b72-v6mr8194027qkb.48.1538728553549; Fri, 05 Oct 2018 01:35:53 -0700 (PDT) MIME-Version: 1.0 References: <153872786909.1031.6765450646719822547.idtracker@ietfa.amsl.com> <2F638E19-26FF-4647-933E-81075F8150DD@nominet.uk> In-Reply-To: <2F638E19-26FF-4647-933E-81075F8150DD@nominet.uk> From: Cigdem Sengul Date: Fri, 5 Oct 2018 09:35:41 +0100 Message-ID: To: ace@ietf.org Content-Type: multipart/alternative; boundary="000000000000d7130e05777728c6" Archived-At: Subject: [Ace] Fwd: FW: New Version Notification for draft-sengul-ace-mqtt-tls-profile-03.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, 05 Oct 2018 08:36:00 -0000 --000000000000d7130e05777728c6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello ACE, We submitted an update of draft-sengul-ace-mqtt-tls-profile with the following changes: Requirements language fixed according to the new IETF recommendation. The use of audience and scopes claims in access tokens has been clarified= . Encoding used in the access token has been clarified. Sections on IANA, security and privacy considerations are added. With these changes, we aimed to address the review comments of Ludwig Seitz on May 15, 2018. Thanks again Ludwig for the detailed review. Our response comments are also below. =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 1. Introduction " Section 4 of the ACE framework [I-D.ietf-ace-oauth-authz]" If you make that "Section 4 of [I-D.ietf-ace-oauth-authz]" the IETF html-izer will not turn this into a link to section 4 of your draft (I think). See: https://xml2rfc.tools.ietf.org/xml2rfcFAQ.html#anchor18 =E2=80=94 Together with Ludwig, we decided we did not have this problem. 1.1. Requirements Language There is a new recommendation how this section should be worded: "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here." =E2=80=94 Done. 1.2. ACE-Related Terminology "The term "Resource" is used to refer to an MQTT "topic", which is defined in Section 1.2." This references back to the same section, perhaps this was meant to reference to some other part of the draft? =E2=80=94 Fixed. 2.1. Authorizing Connection Establishment Figure 1 could clarify that steps E and F are optional. =E2=80=94 Fixed both in text and on figure. 2.1.1. Client Authorization Server (CAS) and Authorization Server (AS) Interaction "and the client is authorized to obtain a token for the indicated audience (e.g., topics) and scopes (e.g., publish/subscribe permissions)" Note that the audience claim is typically used to identify the RS (so in this case the MQTT broker), while the scope is intended to identify both the resource (=3Dtopic) and the actions (=3Dpublish, subscribe). See this for how OAuth scopes are typically used: https://www.brandur.org/oauth-scope =E2=80=94 Cleaned up after a mailing list discussion: authorizes the client= for the indicated audience (e.g. RS) and scopes (e.g. publish/subscribe permissions over topics) "This includes a token, which is assumed to be PoP by default." The abbreviation PoP is not defined at this point, I would write it out as in "... assumed to be a Proof-of-Possession (PoP) token ..." =E2=80=94 Fixed 2.1.2. Client connection request to the broker " For the basic operation described in this section, the Username field MUST be set to the token." I think this refers to the access token right? I'd suggest to be more specific, since there is room for confusion (CoAP has also the concept of a token, and then OAuth has different types of tokens, the access token being one of them). =E2=80=94 Fixed both in Figure 2 and text. =E2=80=9C the Username field MUS= T be set to the access token=E2=80=9D "The Password field MUST be set to the keyed message digest (MAC) or signature." Please make it explicit already here that this is the Proof-of-possession mechanism for the key associated to the token. =E2=80=94 Clarified with the following text. =E2=80=9CThe Password field M= UST be set to the keyed message digest (MAC) or signature associated with the access token for proof-of-possession. The client MAY apply the PoP key either to the token or the entire request by computing a keyed message digest (for symmetric key) or a digital signature (for asymmetric key).=E2=80=9D "(The Username field is a UTF-8 encoded string," You need to specify how the (possibly binary) access token is supposed to be converted into an UTF-8 string. Base64 encoding would be obvious, but it needs to be explicitly stated. =E2=80=94 Clarified with the following text. =E2=80=9C Section 3.1.3 of MQT= T v3.1 - the OASIS Standard [MQTT-OASIS-Standard] defines the MQTT Username as a UTF-8 encoded string, which is prefixed by a 2-byte length field followed by UTF-8 encoded character data up to 65535 bytes. Therefore an access token that is not valid UTF-8 MUST be Base64 [RFC4648] encoded. (The MQTT Password allows binary data (up to 65535 bytes) so does not require encoding.)=E2=80=9D General comment: An example of how the CONNECT message could look like would be good. =E2=80=94 Rather than a direct example, we clarified the text and the figur= e 2. 2.1.3. Token validation "The broker MAY cache the introspection result because it will need to decide whether to accept subsequent PUBLISH and SUBSCRIBE messages" This could warrant a section in the security considerations about the trade-off of caching introspection results (freshness vs. connectivity requirements). =E2=80=94 A discussion was added to the Security considerations section. "If the introspection result is not cached, then the RS needs to introspect the saved token for each request." This is only true if the token is not self-contained. I would rephrase this statement. =E2=80=94 This is clarified at the beginning of the paragraph that the save= d token is not self-contained. In 2.1.3: =E2=80=9C If the token is not self-contained and broker uses token introsp= ection=E2=80=9D "Note: Scope strings MAY follow ..." Note that a scope is a "space-delimited list strings" (OAuth 2.0 3.3.) so you could include several topics in one scope as in e.g. "connect publish_topic1 publish_topic2 subsrcibe_topic3" The use of 'aud' as described in this paragraph is definitely not the intended use, and I would not recommend this type of use. See https://tools.ietf.org/html/rfc7519#section-4.1.3 for the definition of aud= . =E2=80=94 This is clarified as follows after a discussion with Ludwig on th= e mailing list: In 2.1.3: =E2=80=9CScope strings SHOULD be encoded as a permission, followed by an underscore, followed by a topic filter. Two permissions apply to topics: 'publish' and 'subscribe'. An example scope field may contain multiple such strings, space delimited, e.g., 'publish_topic1 subscribe_topic2/#'. Hence, this access token would give 'publish' permission to the 'topic1', 'subscribe' permission to all the subtopics of 'topic2'. If there is a single RS, then scope strings MAY be simply the keywords 'publish' or 'subscribe,' and the 'aud' field in the access token MAY be used to define the topic filter.=E2=80= =9D 2.4. Token expiration "The token validation is done either by checking the 'exp' claim of a CWT/JWT or via performing an introspection request with the Authorization server as described in Section 8.2 of the ACE framework [I-D.ietf-ace-oauth-authz]." The word "token validation" here could be misconstrued to ignoring crypto wrappers, token issuers ect. While it is clear from the context (to me) that you only refer to checking the expiration of a token, the full validation of a token would include the following steps: 1. Check that the issuer of the token (=3D AS) is acceptable 2. Check the cryptographic wrapper of the token (may be MAC or signature or AEAD encryption) 3. Check that the token contains all expected claims 4. Check that the "exp" and "nbf" claims are fulfilled if present 5. Check that the "aud" claim applies to the recipient if present =E2=80=94 Token validation explains the aforementioned steps more clearly. = For token expiration in 2.4, the text is corrected. =E2=80=9CThe token expiration is checked by checking the 'exp' claim=E2=80= =9D 3.1. Token Transport via Authentication Exchange (AUTH) "The first option is that Authentication data contains both the token and the keyed message digest (MAC) or signature as described in Section 2.1.2." You need to specify how these two items are encoded. I would suggest a CBOR array since this property expects binary data. An example would also be very helpful here. =E2=80=94 We have put CBOR and COSE as a MAY. "... RS responds with a CONNACK reason code '0x87 (Not Authorized)' and includes a User Property set to the address of the AS." You need to specify the format of this user property, in order to mirror the framework's section 5.1.2. I guess you could use either a JSON map or binary data containing a CBOR map for this. =E2=80=94 Clarified in text: =E2=80=9CAS Information contains the absolute URI of AS, and MAY also conta= in a nonce as defined in the Section 5.1.2 of the ACE framework. This information my be CBOR encoded=E2=80=9D. 4. IANA Considerations " This memo includes no request to IANA." This should instead register the new profile identifier "mqtt_tls" in the soon-to-be-created IANA registry for ACE profile identifiers. See the DTLS profile for example: https://tools.ietf.org/html/draft-ietf-ace-dtls-authorize-03#section-7 =E2=80=94Added the relevant text. 5. Security Considerations You should add some text here about the security implications of the limitations of MQTT v3.1 (client disconnect only). I could imagine that you could perform some attacks on a client that hasn't realized it was disconnected for example. -- We added discussion on security implications, but a client disconnection should not be a problem. Even if the broker disconnects abruptly at the MQTT layer, it is expected the TCP/TLS session is terminated correctly. =EF=BB=BFOn 05/10/2018, 09:24, "internet-drafts@ietf.org" wrote: A new version of I-D, draft-sengul-ace-mqtt-tls-profile-03.txt has been successfully submitted by Cigdem Sengul and posted to the IETF repository. Name: draft-sengul-ace-mqtt-tls-profile Revision: 03 Title: MQTT-TLS profile of ACE Document date: 2018-10-05 Group: Individual Submission Pages: 22 URL: https://www.ietf.org/internet-drafts/draft-sengul-ace-mqtt-tls-profile-03.t= xt Status: https://datatracker.ietf.org/doc/draft-sengul-ace-mqtt-tls-profile/ Htmlized: https://tools.ietf.org/html/draft-sengul-ace-mqtt-tls-profile-03 Htmlized: https://datatracker.ietf.org/doc/html/draft-sengul-ace-mqtt-tls-profile Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-sengul-ace-mqtt-tls-profile-03 Abstract: This document specifies a profile for the ACE (Authentication and Authorization for Constrained Environments) to enable authorization in an MQTT-based publish-subscribe messaging system. Proof-of- possession keys, bound to OAuth2.0 access tokens, are used to authenticate and authorize publisher and subscriber clients. The protocol relies on TLS for confidentiality and server authentication= . Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --000000000000d7130e05777728c6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello ACE,=


We submitt= ed an update of draft-sengul-ace-mqtt-tls-profile with the following=C2=A0<= /p>

changes:


=C2=A0 Req= uirements language fixed according to the new IETF recommendation.=C2=A0

=C2=A0 The use of audience and sco= pes claims in access tokens has been clarified.

=C2=A0 Encoding used in the access= token has been clarified.=C2= =A0

=C2=A0=C2=A0Sections on IANA, secu= rity and privacy considerations are added.


With these= changes, we aimed to address the review comments of Ludwig Seitz on May 15= , 2018.=C2=A0

Thanks aga= in Ludwig for the detailed review. Our response comments are also below.=C2=A0


=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94


1. Introdu= ction


" Sec= tion 4 of the ACE framework [I-D.ietf-ace-oauth-authz]"


If you mak= e that "Section 4 of [I-D.ietf-ace-oauth-authz]" the IETF=C2=A0

html-izer = will not turn this into a link to section 4 of your draft (I=C2=A0

think).

See:=C2=A0https://xml2rfc.tools.ietf.org/xml2rfcFAQ.h= tml#anchor18


=E2=80=94 = Together with Ludwig, we decided we did not have this problem.=C2=A0



1.1. Requi= rements Language


There is a= new recommendation how this section should be worded:


=C2=A0 &qu= ot;The key words "MUST", "MUST NOT", "REQUIRED&quo= t;, "SHALL", "SHALL NOT",

=C2=A0 =C2= =A0 "SHOULD", "SHOULD NOT", "RECOMMENDED", &q= uot;NOT RECOMMENDED", "MAY", and

=C2=A0 =C2= =A0 "OPTIONAL" in this document are to be interpreted as describe= d in BCP

=C2=A0 =C2= =A0 14 [RFC2119] [RFC8174] when, and only when, they appear in all

=C2=A0 =C2= =A0 capitals, as shown here."


=E2=80=94 = Done.=C2=A0


1.2.=C2=A0= ACE-Related Terminology


"The = term "Resource" is used to refer to an=C2=A0MQTT=C2=A0"topic= ", which is

=C2=A0 =C2= =A0 defined in Section 1.2."


This refer= ences back to the same section, perhaps this was meant to=C2=A0

reference = to some other part of the draft?


=E2=80=94 = Fixed.=C2=A0


2.1.=C2=A0= Authorizing Connection Establishment


Figure 1 c= ould clarify that steps E and F are optional.


=E2=80=94 = Fixed both in text and on figure.=C2=A0


2.1.1.=C2= =A0 Client Authorization Server (CAS) and Authorization Server (AS)

=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Interaction


"and = the client is authorized to obtain a token for the indicated

=C2=A0 =C2= =A0 audience (e.g., topics) and scopes (e.g., publish/subscribe

=C2=A0 =C2= =A0 permissions)"


Note that = the audience claim is typically used to identify the RS (so in=C2=A0

this case = the=C2=A0MQTT=C2=A0broker), while the scope is intended to identify both=C2= =A0

the resour= ce (=3Dtopic) and the actions (=3Dpublish, subscribe).

See this f= or how OAuth scopes are typically used:

https://www.brandur.org/oauth-scope


=E2=80=94 Cleaned u= p after a mailing list discussion: authorizes the client for the ind= icated audience (e.g. RS) and scopes (e.g. publish/subscribe permissions ov= er topics)


"This= includes a token, which is assumed to be PoP by default."


The abbrev= iation PoP is not defined at this point, I would write it out=C2=A0

as in &quo= t;... assumed to be a Proof-of-Possession (PoP) token ..."


=E2=80=94 = Fixed=C2=A0


2.1.2.=C2= =A0 Client connection request to the broker


" For= the basic operation described in this section,

=C2=A0 =C2= =A0 the Username field MUST be set to the token."


I think th= is refers to the access token right? I'd suggest to be more=C2=A0

specific, = since there is room for confusion (CoAP has also the concept=C2=A0

of a token= , and then OAuth has different types of tokens, the access=C2=A0

token bein= g one of them).


=E2=80=94 = Fixed both in Figure 2 and text. =E2=80=9C the Username field MUST be set t= o the access token=E2=80=9D


"The = Password field MUST be set to the keyed message digest (MAC) or=C2=A0

signature.= "


Please mak= e it explicit already here that this is the=C2=A0

Proof-of-p= ossession mechanism for the key associated to the token.


=E2=80=94 = Clarified with the following text.=C2=A0 =E2=80=9CThe Password field MUST be set to the keyed messa= ge digest (MAC) or signature associated with the access token for proof-of-= possession.=C2=A0 The cl= ient MAY apply the PoP key either to the token or the entire request by com= puting a keyed message digest (for symmetric key) or a digital signature (f= or asymmetric key).=E2=80=9D



"(The= Username field is a UTF-8 encoded string,"


You need t= o specify how the (possibly binary) access token is supposed=C2=A0

to be conv= erted into an UTF-8 string. Base64 encoding would be obvious,=C2=A0

but it nee= ds to be explicitly stated.


=E2=80=94 = Clarified with the following text. =E2=80=9C Section 3.1.3 of MQTT v3.1 - t= he OASIS Standard [MQTT-OASIS-Standard] defines the MQTT Username as a UTF-= 8 encoded string, which is prefixed by a 2-byte length field followed by UT= F-8 encoded character data up to 65535 bytes.=C2=A0 Therefore an access token that is not valid UTF= -8 MUST be Base64 [RFC4648] encoded.=C2=A0 (The MQTT Password allows binary data (up to 65535 bytes= ) so does not require encoding.)=E2=80=9D


General co= mment:


An example= of how the CONNECT message could look like would be good.


=E2=80=94 = Rather than a direct example, we clarified the text and the figure 2.=C2=A0



2.1.3.=C2= =A0 Token validation


"The = broker MAY cache the introspection result because it will need to

=C2=A0 =C2= =A0 decide whether to accept subsequent PUBLISH and SUBSCRIBE messages"= ;


This could= warrant a section in the security considerations about the=C2=A0

trade-off = of caching introspection results (freshness vs. connectivity=C2=A0

requiremen= ts).


=E2=80=94<= span class=3D"gmail-Apple-converted-space">=C2=A0 A discussion was a= dded to the Security considerations section.=C2=A0


"If t= he introspection result is not cached, then the RS needs to=C2=A0

introspect= the saved token for each request."


This is on= ly true if the token is not self-contained. I would rephrase=C2=A0

this state= ment.=C2=A0


=E2=80=94 = This is clarified at the beginning of the paragraph that the saved token is= not self-contained.

In 2.1.3:<= /p>

=E2=80=9C = If the token is not self-contained and=C2=A0 broker uses token introspection=E2=80=9D


"Note= : Scope strings MAY follow ..."


Note that = a scope is a "space-delimited list strings" (OAuth 2.0 3.3.)

so you cou= ld include several topics in one scope as in e.g. "connect=C2=A0

publish_to= pic1 publish_topic2 subsrcibe_topic3"


The use of= 'aud' as described in this paragraph is definitely not the=C2=A0

intended u= se, and I would not recommend this type of use. See=C2=A0

https://tools.ietf.org/html/rf= c7519#section-4.1.3=C2=A0for the definition of aud.


=E2=80=94 = This is clarified as follows after a discussion with Ludwig on the mailing = list:

In 2.1.3:<= span class=3D"gmail-Apple-converted-space">=C2=A0

=C2=A0=E2=80=9CScope strings SHOUL= D be encoded as a permission, followed by an

=C2=A0=C2=A0 underscore, followed = by a topic filter.=C2=A0 Two permissions apply to

=C2=A0=C2=A0 topics: 'publish&= #39; and 'subscribe'.= =C2=A0 An example scope field may

=C2=A0=C2=A0 contain multiple such= strings, space delimited, e.g., 'publish_topic1

=C2=A0=C2=A0 subscribe_topic2/#= 9;.=C2=A0 Hence, this ac= cess token would give 'publish'

=C2=A0=C2=A0 permission to the = 9;topic1', 'subscribe' permission to all the

=C2=A0=C2=A0 subtopics of 'top= ic2'.=C2=A0 If there= is a single RS, then scope strings

=C2=A0=C2=A0 MAY be simply the key= words 'publish' or 'subscribe,' and the 'aud'

=C2=A0=C2=A0 field in the access t= oken MAY be used to define the topic filter.=E2=80=9D



2.4.=C2=A0= Token expiration


"The = token validation is done either by checking the 'exp' claim of a

=C2=A0 =C2= =A0 CWT/JWT or via performing an introspection request with the

=C2=A0 =C2= =A0 Authorization server as described in Section 8.2 of the ACE framework

=C2=A0 =C2= =A0 [I-D.ietf-ace-oauth-authz]."


The word &= quot;token validation" here could be misconstrued to ignoring=C2=A0

crypto wra= ppers, token issuers ect. While it is clear from the context=C2=A0

(to me) th= at you only refer to checking the expiration of a token, the=C2=A0

full valid= ation of a token would include the following steps:


1. Check t= hat the issuer of the token (=3D AS) is acceptable

2. Check t= he cryptographic wrapper of the token (may be MAC or signature or

AEAD encry= ption)

3. Check t= hat the token contains all expected claims

4. Check t= hat the "exp" and "nbf" claims are fulfilled if present=

5. Check t= hat the "aud" claim applies to the recipient if present


=E2=80=94 = Token validation explains the aforementioned steps more clearly. For token = expiration in 2.4, the text is corrected.

=C2=A0=E2=80=9CThe token expiratio= n is checked by checking the 'exp' claim=E2=80=9D



3.1.=C2=A0= Token Transport via Authentication Exchange (AUTH)


"The = first option is that Authentication data contains both the token

=C2=A0 =C2= =A0 and the keyed message digest (MAC) or signature as described in

=C2=A0 =C2= =A0 Section 2.1.2."


You need t= o specify how these two items are encoded. I would suggest a

CBOR array= since this property expects binary data. An example would also

be very he= lpful here.


=E2=80=94 = We have=C2=A0 put CBOR a= nd COSE as a MAY.=C2=A0<= /p>



"... = RS responds with a CONNACK reason code '0x87 (Not Authorized)' and<= /p>

=C2=A0 =C2= =A0 includes a User Property set to the address of the AS."


You need t= o specify the format of this user property, in order to mirror

the framew= ork's section 5.1.2. I guess you could use either a JSON map

or binary = data containing a CBOR map for this.


=C2=A0=E2=80=94 Clarified in text:=

=E2=80=9CA= S Information contains the absolute URI of AS, and MAY also contain a nonce= as defined in the Section 5.1.2 of the ACE framework.=C2=A0

This infor= mation my be CBOR encoded=E2=80=9D.=C2=A0


4.=C2=A0 I= ANA Considerations


"=C2= =A0 =C2=A0This memo includes no request to IANA."


This shoul= d instead register the new profile identifier "mqtt_tls" in=C2=A0=

the soon-t= o-be-created IANA registry for ACE profile identifiers. See=C2=A0

the DTLS p= rofile for example:


https://t= ools.ietf.org/html/draft-ietf-ace-dtls-authorize-03#section-7


=E2=80=94A= dded the relevant text.=C2=A0


5. Securit= y Considerations


You should= add some text here about the security implications of the=C2=A0

limitation= s of=C2=A0MQTT=C2=A0v3.1 (client disconnect only).

I could im= agine that you could perform some attacks on a client that=C2=A0

hasn't= realized it was disconnected for example.


-- We added discussion on security im= plications, but a client disconnection should not be a problem.

Even if the broker= disconnects abruptly at the MQTT layer, it is expected the TCP/TLS session= is terminated correctly.=C2=A0


=EF=BB=BFOn 05/10/2018, 09:24, "internet-drafts@ietf.org" <internet-drafts@ietf.org<= /a>> wrote:


=C2=A0 =C2=A0 A new version of I-D, draft-sengul-ace-mqtt-tls-profile-03.tx= t
=C2=A0 =C2=A0 has been successfully submitted by Cigdem Sengul and posted t= o the
=C2=A0 =C2=A0 IETF repository.

=C2=A0 =C2=A0 Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0d= raft-sengul-ace-mqtt-tls-profile
=C2=A0 =C2=A0 Revision:=C2=A0 =C2=A003
=C2=A0 =C2=A0 Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MQTT-T= LS profile of ACE
=C2=A0 =C2=A0 Document date:=C2=A0 =C2=A0 =C2=A0 2018-10-05
=C2=A0 =C2=A0 Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Indivi= dual Submission
=C2=A0 =C2=A0 Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 22
=C2=A0 =C2=A0 URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/d= raft-sengul-ace-mqtt-tls-profile-03.txt
=C2=A0 =C2=A0 Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-sengul-ace-mqt= t-tls-profile/
=C2=A0 =C2=A0 Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-sengul-ace-mqtt-tls-profile= -03
=C2=A0 =C2=A0 Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-sengul-ace= -mqtt-tls-profile
=C2=A0 =C2=A0 Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft= -sengul-ace-mqtt-tls-profile-03

=C2=A0 =C2=A0 Abstract:
=C2=A0 =C2=A0 =C2=A0 =C2=A0This document specifies a profile for the ACE (A= uthentication and
=C2=A0 =C2=A0 =C2=A0 =C2=A0Authorization for Constrained Environments) to e= nable authorization
=C2=A0 =C2=A0 =C2=A0 =C2=A0in an MQTT-based publish-subscribe messaging sys= tem.=C2=A0 Proof-of-
=C2=A0 =C2=A0 =C2=A0 =C2=A0possession keys, bound to OAuth2.0 access tokens= , are used to
=C2=A0 =C2=A0 =C2=A0 =C2=A0authenticate and authorize publisher and subscri= ber clients.=C2=A0 The
=C2=A0 =C2=A0 =C2=A0 =C2=A0protocol relies on TLS for confidentiality and s= erver authentication.




=C2=A0 =C2=A0 Please note that it may take a couple of minutes from the tim= e of submission
=C2=A0 =C2=A0 until the htmlized version and diff are available at tools.ietf.= org.

=C2=A0 =C2=A0 The IETF Secretariat



--000000000000d7130e05777728c6-- From nobody Fri Oct 5 15:57:23 2018 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 3971412872C; Fri, 5 Oct 2018 15:57:22 -0700 (PDT) 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, 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 JXlUVuQ1jvGz; Fri, 5 Oct 2018 15:57:19 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EBF91277D2; Fri, 5 Oct 2018 15:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w95MvFKx023069; Sat, 6 Oct 2018 00:57:15 +0200 (CEST) Received: from [192.168.217.102] (p54A6C3C7.dip0.t-ipconnect.de [84.166.195.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 42RlWb2wrXzDXqV; Sat, 6 Oct 2018 00:57:15 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 560473033.187742-8e755096de363303ad93055d3a5b5842 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sat, 6 Oct 2018 00:57:14 +0200 Message-Id: <17A2ED9E-8BDA-4686-A322-D952F36B1464@tzi.org> To: ace@ietf.org, core@ietf.org, cose@ietf.org, cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Ace] Constrained Node/Network Cluster @ IETF103: 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: Fri, 05 Oct 2018 22:57:22 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF103. Remember that there is still quite some potential for changes. cbor/teep and 6tisch/suit are annoying but probably livable. No qirg for core goers... All times are ICT (Indochina Time) =3D=3D UTC +7 hours. There is no daylight saving time in effect in Thailand. DST will have ended in Europe by then (e.g., CET =3D UTC+0100) and will end in the US during the initial weekend (On Sun, Nov 4; e.g. EST =3D UTC-0500). (You can get pure UTC times on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Please note that the Friday schedule is still evolving; plan to stick around until 13:20 or you may miss interesting conversations. Gr=C3=BC=C3=9Fe, Carsten SATURDAY/SUNDAY, November 3/4. 2018 -- Hackathon (including various interops) (Centre Ville) -- Sun 1700-1900 Welcome Reception - Garden at Queen's Park -- Sun 1800-2000 Hot RFC Lightning Talks - Thai Chitlada 3 MONDAY, November 5, 2018 0900-1100 Morning Session I Thai Chitlada 3 IRTF*** dinrg Decentralized Internet Infrastructure = Proposed RG Meeting 1 OPS v6ops IPv6 Operations WG Boromph. 1/2 RTG *** roll Routing Over Low power and Lossy = networks WG Thai Chitlada 1 SEC secdispatch Security Dispatch WG Thai Chitlada 2 TSV taps Transport Services WG 1120-1220 Morning Session II Thai Chitlada 1 IRTF cfrg Crypto Forum Thai Chitlada 2 TSV tsvarea Transport Area Open Meeting 1350-1550 Afternoon Session I Boromph. 1/2 ART *** core Constrained RESTful Environments WG Meeting 2 OPS anima Autonomic Networking Integrated Model = and Approach WG Thai Chitlada 2 SEC tls Transport Layer Security WG Thai Chitlada 3 TSV tsvwg Transport Area Working Group WG 1610-1810 Afternoon Session II Meeting 1 INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Thai Chitlada 1 IRTF irtfopen IRTF Open Meeting Thai Chitlada 2 SEC mls Messaging Layer Security WG TUESDAY, November 6, 2018 0900-1100 Morning Session I Thai Chitlada 2 ART httpbis Hypertext Transfer Protocol WG Meeting 1 INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Boromph. 1/2 SEC oauth Web Authorization Protocol WG 1120-1220 Morning Session II Thai Chitlada 3 INT ipwave IP Wireless Access in Vehicular = Environments WG Meeting 2 SEC oauth Web Authorization Protocol WG 1350-1550 Afternoon Session I Thai Chitlada 3 INT 6man IPv6 Maintenance WG Thai Chitlada 2 SEC rats Remote ATtestation ProcedureS BOF Thai Chitlada 1 TSV quic QUIC WG 1610-1810 Afternoon Session II Thai Chitlada 1 IRTF maprg Measurement and Analysis for Protocols Meeting 2 IRTF*** t2trg Thing-to-Thing WEDNESDAY, November 7, 2018 0900-1100 Morning Session ! Thai Chitlada 3 ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Boromph. 3 RTG bier Bit Indexed Explicit Replication WG Meeting 1 SEC *** teep Trusted Execution Environment = Provisioning WG Boromph. 1/2 SEC tokbind Token Binding WG Thai Chitlada 1 TSV quic QUIC WG 1120-1220 Morning Session II Boromph. 1/2 INT *** lwig Light-Weight Implementation Guidance WG Thai Chitlada 1 SEC tls Transport Layer Security WG Thai Chitlada 2 TSV tsvwg Transport Area Working Group WG 1350-1520 Afternoon Session I Meeting 1 GEN wugh WGs Using GitHub BOF Thai Chitlada 3 INT homenet Home Networking WG Meeting 2 IRTF panrg Path Aware Networking RG 1540-1710 Afternoon Session II Meeting 1 ART dispatch Dispatch WG - Joint with ARTAREA Thai Chitlada 3 INT intarea Internet Area Working Group WG Meeting 2 IRTF pearg Privacy Enhancements and Assessments = Proposed Research Group Boromph. 3 RTG babel Babel routing protocol WG Boromph. 1/2 RTG rift Routing In Fat Trees WG THURSDAY, November 8, 2018 0900-1100 Morning Session I Thai Chitlada 1 ART httpbis Hypertext Transfer Protocol WG Boromph. 4 INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Meeting 1 IRTF icnrg Information-Centric Networking Thai Chitlada 2 SEC *** suit Software Updates for Internet of Things = WG 1120-1220 Morning Session II Thai Chitlada 2 ART *** core Constrained RESTful Environments WG Thai Chitlada 3 IRTF qirg Quantum Internet Proposed Research Group Boromph. 4 RTG bier Bit Indexed Explicit Replication WG Thai Chitlada 1 SEC mls Messaging Layer Security WG Meeting 2 TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1350-1550 Afternoon Session I Meeting 1 INT dnssd Extensions for Scalable DNS Service = Discovery WG Thai Chitlada 2 RTG detnet Deterministic Networking WG Thai Chitlada 1 SEC saag Security Area Open Meeting 1610-1810 Afternoon Session II Thai Chitlada 3 RTG rtgarea Routing Area Open Meeting Thai Chitlada 1 SEC *** ace Authentication and Authorization for = Constrained Environments WG Boromph. 1/2 SEC acme Automated Certificate Management = Environment WG FRIDAY, November 9, 2018 Various ad-hoc meetings, please see https://trac.ietf.org/trac/ietf/meeting/wiki/103sidemeetings#FRIDAY -- 0900..1320 T2TRG work meeting -- 1000..??? COIN (Computing in the Network) From nobody Mon Oct 8 04:12:43 2018 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 2B3F2130E53; Mon, 8 Oct 2018 04:12:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.85.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <153899714711.31732.3467245306384135998@ietfa.amsl.com> Date: Mon, 08 Oct 2018 04:12:27 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-dtls-authorize-05.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 11:12:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) Authors : Stefanie Gerdes Olaf Bergmann Carsten Bormann Göran Selander Ludwig Seitz Filename : draft-ietf-ace-dtls-authorize-05.txt Pages : 20 Date : 2018-10-08 Abstract: This specification defines a profile that allows constrained servers to delegate client authentication and authorization. The protocol relies on DTLS for communication security between entities in a constrained network using either raw public keys or pre-shared keys. A resource-constrained server can use this protocol to delegate management of authorization information to a trusted host with less severe limitations regarding processing power and memory. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-dtls-authorize/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-dtls-authorize-05 https://datatracker.ietf.org/doc/html/draft-ietf-ace-dtls-authorize-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-dtls-authorize-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 8 04:30:05 2018 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 7BA4E130DC4 for ; Mon, 8 Oct 2018 04:30:03 -0700 (PDT) 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] 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 WqnFOPLHn0dl for ; Mon, 8 Oct 2018 04:30:01 -0700 (PDT) Received: from smtp.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 1B97912F1A5 for ; Mon, 8 Oct 2018 04:30:01 -0700 (PDT) Received: from wangari.tzi.org (w199-s-v4.eduroam.dynamic.rbg.tum.de [131.159.199.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id B508A26F78 for ; Mon, 8 Oct 2018 13:29:59 +0200 (CEST) From: Olaf Bergmann To: ace@ietf.org References: <153899714711.31732.3467245306384135998@ietfa.amsl.com> Date: Mon, 08 Oct 2018 13:29:59 +0200 In-Reply-To: <153899714711.31732.3467245306384135998@ietfa.amsl.com> (internet-drafts's message of "Mon, 08 Oct 2018 04:12:27 -0700") Message-ID: <87h8hwk760.fsf@tzi.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-dtls-authorize-05.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 11:30:04 -0000 Dear list, we have just submitted version -05 of the DTLS profile draft to address the open issues from Jim's review. Gr=C3=BC=C3=9Fe Olaf internet-drafts@ietf.org writes: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Authentication and Authorization for Con= strained Environments WG of the IETF. > > Title : Datagram Transport Layer Security (DTLS) Profil= e for Authentication and Authorization for Constrained Environments (ACE) > Authors : Stefanie Gerdes > Olaf Bergmann > Carsten Bormann > G=C3=B6ran Selander > Ludwig Seitz > Filename : draft-ietf-ace-dtls-authorize-05.txt > Pages : 20 > Date : 2018-10-08 > > Abstract: > This specification defines a profile that allows constrained servers > to delegate client authentication and authorization. The protocol > relies on DTLS for communication security between entities in a > constrained network using either raw public keys or pre-shared keys. > A resource-constrained server can use this protocol to delegate > management of authorization information to a trusted host with less > severe limitations regarding processing power and memory. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ace-dtls-authorize/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ace-dtls-authorize-05 > https://datatracker.ietf.org/doc/html/draft-ietf-ace-dtls-authorize-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-dtls-authorize-05 > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Mon Oct 8 07:30:44 2018 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 CF74F130E1E; Mon, 8 Oct 2018 07:30:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.86.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <153900903480.16464.17058352844633661279@ietfa.amsl.com> Date: Mon, 08 Oct 2018 07:30:34 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-06.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 14:30:35 -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 : EST over secure CoAP (EST-coaps) Authors : Peter van der Stok Panos Kampanakis Sandeep S. Kumar Michael C. Richardson Martin Furuhed Shahid Raza Filename : draft-ietf-ace-coap-est-06.txt Pages : 40 Date : 2018-10-08 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 low-resource 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-06 https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-est-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 8 08:01:45 2018 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 92F62130EF1; Mon, 8 Oct 2018 08:01:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.86.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <153901088355.16293.13681871563765179196@ietfa.amsl.com> Date: Mon, 08 Oct 2018 08:01:23 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-oscore-profile-04.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 15:01:35 -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 : OSCORE profile of the Authentication and Authorization for Constrained Environments Framework Authors : Francesca Palombini Ludwig Seitz Göran Selander Martin Gunnarsson Filename : draft-ietf-ace-oscore-profile-04.txt Pages : 26 Date : 2018-10-08 Abstract: This memo specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Object Security for Constrained RESTful Environments (OSCORE) to provide communication security, server authentication, and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-profile/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-oscore-profile-04 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oscore-profile-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 8 08:06:45 2018 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 BB125130EFF for ; Mon, 8 Oct 2018 08:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.757 X-Spam-Level: X-Spam-Status: No, score=-4.757 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=G0gIfQ46; dkim=pass (1024-bit key) header.d=ericsson.com header.b=OtfnSCG8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7s6vnT9xHZE for ; Mon, 8 Oct 2018 08:06:32 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 1C929130EE3 for ; Mon, 8 Oct 2018 08:06:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1539011189; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Ofz4hE+8p0yJWXvFEDR7H6ttQt7LR62C4VhN93fcpXY=; b=G0gIfQ46ieGLs2vxGEWD2bJ6B9gFPwyD7VO7aywCHxuyZX6lluUDEfi2rcmUosPr 6SGRuWSpevAXmgDQN8BpHayqirxgaNB5uSTpoYgtYN1mOBCEefRQvqGgMCCpzBv0 DACx7mSGUITU9213vVQP+sOGid1+KCCtRmWAZD1xweY=; X-AuditID: c1b4fb30-fe1ff700000055da-ad-5bbb7275bc68 Received: from ESESBMB505.ericsson.se (Unknown_Domain [153.88.183.118]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 10.2C.21978.5727BBB5; Mon, 8 Oct 2018 17:06:29 +0200 (CEST) Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 8 Oct 2018 17:06:29 +0200 Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 8 Oct 2018 17:06:28 +0200 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=Ofz4hE+8p0yJWXvFEDR7H6ttQt7LR62C4VhN93fcpXY=; b=OtfnSCG8n3catZkMUNrUvmuAIIiwU2HI0RalQDTaeDDQsvlg+yRHx8p3BXSeqGe5Sqm7bL2/PZiFJOza+l2ujWJUuA/LtIwDf8ak8Wim/5AJA5a7W7aHr8wQiepbeggBlJsbAF5MuW5oFL4s4tNT/GsPdOLet7CqqRqTyZQRsEM= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.188.140) by HE1PR0701MB1785.eurprd07.prod.outlook.com (10.167.246.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.9; Mon, 8 Oct 2018 15:06:27 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::c05a:fd61:6104:51e5]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::c05a:fd61:6104:51e5%6]) with mapi id 15.20.1228.020; Mon, 8 Oct 2018 15:06:27 +0000 From: Francesca Palombini To: "ace@ietf.org" CC: "draft-ietf-ace-oscore-profile@ietf.org" Thread-Topic: [Ace] I-D Action: draft-ietf-ace-oscore-profile-04.txt Thread-Index: AQHUXxgGhvMeF9GWAEmeU9q/RlH2uaUVlE+A Date: Mon, 8 Oct 2018 15:06:27 +0000 Message-ID: <73AE80B5-BE34-47EB-8DB4-1F488A4CF9A9@ericsson.com> References: <153901088355.16293.13681871563765179196@ietfa.amsl.com> In-Reply-To: <153901088355.16293.13681871563765179196@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US 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.87] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB1785; 6:QeSCELgGjBLaQMDtcR4WmE5TfMdxkxq5gdUJWX02T8fzsIOAO291GOpkYqV1c17LFZ4d7JzaYeHXIpwYBrsAEEC83bT7yXDpUbWZ4bLO9ep68XFSNbpt++LV9RTo60HCPulvhdgAIK13/wPcTRa8NWYQWhCTM2yjqJqRYboCGuJhbOsEGBZ9vmO7/hCu1rpy92NihcJET5avRLzmNLpyXo6cCgOrAAW6/3o6uaIMY7hB2Jeq/wIKJnJG5ov+uKe+xUHMc3ApxYpAfhVbEEoowUVSURu35gYw9iqagt3+LNn5//RoFO5D2UQF8H1ttqK30eRUoT3z5Aiddxf6TZiiT02UvdXfcOzYPMOAzU99mrclUjUx/hlG0Z0vXXddq66BUNyIP3GkugtEcZ6Ta+1QmO0waQ+k3ppUeTOeIBYUxbmajPeNAlr5z9zJPT3DvJJUk5n5+eI9kZO8eN6TTr6vKA==; 5:yqUJLehEIIoTvLnj/j/7UemCh/L8okg2Pwh0YDgYVqXoXXddJ9SSAzRduXrrOnphRCU5EMrr4FVFJjSLZwv9N6SLM4gjeMEaRqXntp2W6j7ffWcMud5qCN2dASiq6nRMlN9fM4f1WVBZk8U9KjvNcrQMVxVVwMHOMQrG4wH43TY=; 7:IltGqUve3hEkdFh/q/evN6Fz5y3uiVY/RgAaJyQ806THKV9CtWlcnctHPq4jWtAXwEiEYNMW8d7M/ibXEad5rDe9vxWdDkVhUYQz2KzVd7QPy80BhLAnZ+dtdcrqAJrXJwqQY9T0EKqzMth9Hwg7LFjHDwe3RYS6rCdDuV5WfeFn2gEVPGoK8GcturwrfVP7/kfXO8KvkSQHNqobviof3JNuVzyTVvLUhNkNtGdUXyvfuSuk3cR4bhxPzr2aey7I x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 01ed27dd-52e9-4b65-3cb5-08d62d2f9f0f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:HE1PR0701MB1785; x-ms-traffictypediagnostic: HE1PR0701MB1785: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(158342451672863)(120809045254105); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231355)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(201708071742011)(7699051); SRVR:HE1PR0701MB1785; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB1785; x-forefront-prvs: 081904387B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(346002)(39860400002)(396003)(366004)(189003)(199004)(53754006)(33656002)(5250100002)(8936002)(2501003)(68736007)(81156014)(8676002)(99286004)(316002)(36756003)(66066001)(3846002)(6246003)(6116002)(7736002)(450100002)(25786009)(4326008)(97736004)(81166006)(1730700003)(86362001)(2906002)(44832011)(2616005)(476003)(486006)(2900100001)(5660300001)(305945005)(82746002)(6436002)(71200400001)(11346002)(229853002)(83716004)(6486002)(2351001)(256004)(14444005)(105586002)(66574009)(71190400001)(106356001)(6916009)(14454004)(6506007)(102836004)(478600001)(76176011)(26005)(53936002)(966005)(5640700003)(6306002)(6512007)(186003)(446003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB1785; H:HE1PR0701MB2746.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-microsoft-antispam-message-info: dJ5s/lIRMKJ8fX4f6eQw2kwSQQh4VydZ2ujMnzQpVvBKcX5dUMwOfkv3fgfoLilbTsp2QacR9BGU5NS+eiqIiNBuRn6kVWFRUdhQYqw/AB9IPVqU9x2a6LPy7491CV/NJmyYXI+YsDvcWYhCwV8+yTck1kS9O7Du89fJ9B1WyvQ+crYKxLqzgo4J/NSUMOW+kfCJjy6wYqvDae7isBaLSfMqrbU97PEnoL1uvhpyLURQA5S1jZyiEINEzxyczJEXFuwkO1TF9xAAN9uATapnzWHWqgJvE3eMAzyizDSJBxDXGqPVl7atwak1kwdLL9GOT1JkaMmqZOir6C/ApoW2fJbsOsn+CeEvJWylxp0uikA= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <307B1D9DEBE6E842847E6CE38E7C3751@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 01ed27dd-52e9-4b65-3cb5-08d62d2f9f0f X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2018 15:06:27.3701 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB1785 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42KZGbG9TLe0aHe0wdzHohbfv/UwWzzd1sHs wOSxZMlPpgDGKC6blNSczLLUIn27BK6MN2sOsBackayY+WUbawPjD4kuRk4OCQETifkTDrN0 MXJxCAkcZZRoOnSOFcL5yiixfMZlVpAqIYHFTBIzTzqCJFgEJjBLHP28iB0iMZ1J4tesAoiO p4wSs1b+BkuwCdhIXHj4Hqibg0NEQFHi+qNEkDCzQLjEv/cHWUBsYQFniQePp7OB2CICLhI/ Dt2FKjeS2N1sCRJmEVCROHqiC6ycV8Beor99NRtIiRBQ+f4l+SAmp4CrxN4L0SAVjAKyEl8a VzNDLBKXuPVkPhPEjwISS/acZ4awRSVePv7HClGfLHHldh87yBgJAQWJJX8lIUpkJS7N72aE sA+wS0w4LwBh60p8mDoVaoyvxKu9HeBgkxA4ySjx/9RtqAYdiXn7HkMV5Us8WX2BHcKOlbjY 1wx1j5zEqt6HLBMYjWYhOXUW0BnMApoS63fpQ5geEpPvW0FUKEpM6X7IPgscDIISJ2c+YVnA yLqKUbQ4tTgpN93ISC+1KDO5uDg/Ty8vtWQTIzBtHNzy22AH48vnjocYBTgYlXh4O+J3Rwux JpYVV+YeYpTgYFYS4RXdvitaiDclsbIqtSg/vqg0J7X4EKM0B4uSOK+F3+YoIYH0xJLU7NTU gtQimCwTB6dUA6PlxyizFv6FtwJXfz5TxbJus8DLzU/uFokkPSufs46TwWam2fc9fr/L2P5f 3fRy8yJ7sfa7PJIKCz6fO7xW+4v5yYvaKyZ1nPX8rFrgtqN15u173oeKDiRdXDhlu3bepYNT VrTstzk1Y2JX+5W9xzSVWcsa9k5Pu6p2W8y1K0tIc2nQGy+u8pMPlViKMxINtZiLihMBUNR/ +RcDAAA= Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-oscore-profile-04.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 15:06:44 -0000 SGkgYWxsLA0KDQpXZSBoYXZlIGp1c3Qgc3VibWl0dGVkIGFuIHVwZGF0ZWQgdmVyc2lvbiBvZiB0 aGUgT1NDT1JFIHByb2ZpbGUgZm9yIEFDRS4gTWFpbmx5LCB0aGlzIHZlcnNpb24gYWRkcyBzb21l IGV4YW1wbGVzLCBleHBhbmRzIG9uIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLCBleHBhbmRzIG9u IHVwZGF0aW5nIHJpZ2h0cywgZml4ZXMgc29tZSByZWZlcmVuY2VzIGFuZCBtaW5vciBlcnJvcnMg bGVmdG92ZXIgYW5kIGltcHJvdmVzIHJlYWRhYmlsaXR5Lg0KDQpUaGFua3MsDQpGcmFuY2VzY2EN Cg0K77u/T24gMjAxOC0xMC0wOCwgMTc6MDMsICJBY2Ugb24gYmVoYWxmIG9mIGludGVybmV0LWRy YWZ0c0BpZXRmLm9yZyIgPGFjZS1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBpbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KDQogICAgDQogICAgQSBOZXcgSW50ZXJuZXQtRHJh ZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9y aWVzLg0KICAgIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIEF1dGhlbnRpY2F0aW9u IGFuZCBBdXRob3JpemF0aW9uIGZvciBDb25zdHJhaW5lZCBFbnZpcm9ubWVudHMgV0cgb2YgdGhl IElFVEYuDQogICAgDQogICAgICAgICAgICBUaXRsZSAgICAgICAgICAgOiBPU0NPUkUgcHJvZmls ZSBvZiB0aGUgQXV0aGVudGljYXRpb24gYW5kIEF1dGhvcml6YXRpb24gZm9yIENvbnN0cmFpbmVk IEVudmlyb25tZW50cyBGcmFtZXdvcmsNCiAgICAgICAgICAgIEF1dGhvcnMgICAgICAgICA6IEZy YW5jZXNjYSBQYWxvbWJpbmkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEx1ZHdpZyBT ZWl0eg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgR8O2cmFuIFNlbGFuZGVyDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBNYXJ0aW4gR3VubmFyc3Nvbg0KICAgIAlGaWxlbmFt ZSAgICAgICAgOiBkcmFmdC1pZXRmLWFjZS1vc2NvcmUtcHJvZmlsZS0wNC50eHQNCiAgICAJUGFn ZXMgICAgICAgICAgIDogMjYNCiAgICAJRGF0ZSAgICAgICAgICAgIDogMjAxOC0xMC0wOA0KICAg IA0KICAgIEFic3RyYWN0Og0KICAgICAgIFRoaXMgbWVtbyBzcGVjaWZpZXMgYSBwcm9maWxlIGZv ciB0aGUgQXV0aGVudGljYXRpb24gYW5kDQogICAgICAgQXV0aG9yaXphdGlvbiBmb3IgQ29uc3Ry YWluZWQgRW52aXJvbm1lbnRzIChBQ0UpIGZyYW1ld29yay4gIEl0DQogICAgICAgdXRpbGl6ZXMg T2JqZWN0IFNlY3VyaXR5IGZvciBDb25zdHJhaW5lZCBSRVNUZnVsIEVudmlyb25tZW50cw0KICAg ICAgIChPU0NPUkUpIHRvIHByb3ZpZGUgY29tbXVuaWNhdGlvbiBzZWN1cml0eSwgc2VydmVyIGF1 dGhlbnRpY2F0aW9uLA0KICAgICAgIGFuZCBwcm9vZi1vZi1wb3NzZXNzaW9uIGZvciBhIGtleSBv d25lZCBieSB0aGUgY2xpZW50IGFuZCBib3VuZCB0byBhbg0KICAgICAgIE9BdXRoIDIuMCBhY2Nl c3MgdG9rZW4uDQogICAgDQogICAgDQogICAgVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBh Z2UgZm9yIHRoaXMgZHJhZnQgaXM6DQogICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1hY2Utb3Njb3JlLXByb2ZpbGUvDQogICAgDQogICAgVGhlcmUgYXJlIGFs c28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KICAgIGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFjZS1vc2NvcmUtcHJvZmlsZS0wNA0KICAgIGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1hY2Utb3Njb3JlLXByb2Zp bGUtMDQNCiAgICANCiAgICBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFp bGFibGUgYXQ6DQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWll dGYtYWNlLW9zY29yZS1wcm9maWxlLTA0DQogICAgDQogICAgDQogICAgUGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz c2lvbg0KICAgIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFi bGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQogICAgDQogICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNv IGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KICAgIGZ0cDovL2Z0cC5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvDQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCiAgICBBY2UgbWFpbGluZyBsaXN0DQogICAgQWNlQGlldGYub3Jn DQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UNCiAgICANCg0K From nobody Mon Oct 8 14:34:50 2018 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 CB5CB13104C for ; Mon, 8 Oct 2018 14:34:47 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 GF8Kdpnctxlr for ; Mon, 8 Oct 2018 14:34:46 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC251131000 for ; Mon, 8 Oct 2018 14:34:45 -0700 (PDT) Received: from Jude (192.168.0.11) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 8 Oct 2018 14:30:01 -0700 From: Jim Schaad To: Date: Mon, 8 Oct 2018 14:34:36 -0700 Message-ID: <065a01d45f4e$b738ae60$25aa0b20$@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: AdRfTqcrNFwepW1pRaiIJNs5VwRdUA== Content-Language: en-us X-Originating-IP: [192.168.0.11] Archived-At: Subject: [Ace] WGLC for draft-ietf-ace-oscore-profile 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, 08 Oct 2018 21:34:48 -0000 The chairs believe that the set of documents dealing with the OAuth framework for constrained environments is nearing the point that we should be able to advance it to the IESG for publication. We therefore want to have a full list of issues that need to be dealt with at the Bangkok meeting. This starts a 2 week WGLC for draft-ietf-ace-oscore-profile We know that the following issues are outstanding: draft-ietf-ace-oscore-profile: * No current known issues Jim & Roman From nobody Mon Oct 8 14:34:56 2018 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 57989131000 for ; Mon, 8 Oct 2018 14:34:48 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 sq6PI3DOkJN3 for ; Mon, 8 Oct 2018 14:34:46 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81F0B131007 for ; Mon, 8 Oct 2018 14:34:46 -0700 (PDT) Received: from Jude (192.168.0.11) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 8 Oct 2018 14:30:04 -0700 From: Jim Schaad To: Date: Mon, 8 Oct 2018 14:34:40 -0700 Message-ID: <065b01d45f4e$b8d372a0$2a7a57e0$@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: AdRfTbZXRdy06+geSTKJtOzYofxg+g== Content-Language: en-us X-Originating-IP: [192.168.0.11] Archived-At: Subject: [Ace] WGLC for draft-ietf-ace-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 21:34:49 -0000 The chairs believe that the set of documents dealing with the OAuth framework for constrained environments is nearing the point that we should be able to advance it to the IESG for publication. We therefore want to have a full list of issues that need to be dealt with at the Bangkok meeting. This starts a 2 week WGLC for draft-ietf-ace-authz We know that the following issues are outstanding: draft-ietf-ace-authz * There are a couple of esoteric issues around listing AS servers associated with resources in a Resource Directory Jim & Roman From nobody Mon Oct 8 14:35:02 2018 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 82A251310C3 for ; Mon, 8 Oct 2018 14:34:50 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 yyisqpN-XkgI for ; Mon, 8 Oct 2018 14:34:49 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C278C131007 for ; Mon, 8 Oct 2018 14:34:48 -0700 (PDT) Received: from Jude (192.168.0.11) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 8 Oct 2018 14:30:06 -0700 From: Jim Schaad To: Date: Mon, 8 Oct 2018 14:34:40 -0700 Message-ID: <065c01d45f4e$ba68dfb0$2f3a9f10$@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: AdRfTnwZV6aQaeIRSdSUplY1V03Vdg== Content-Language: en-us X-Originating-IP: [192.168.0.11] Archived-At: Subject: [Ace] WGLC for draft-ietf-dtl-authorize 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, 08 Oct 2018 21:34:53 -0000 The chairs believe that the set of documents dealing with the OAuth framework for constrained environments is nearing the point that we should be able to advance it to the IESG for publication. We therefore want to have a full list of issues that need to be dealt with at the Bangkok meeting. This starts a 2 week WGLC for draft-ietf-ace-dtls-authorize We know that the following issues are outstanding: draft-ietf-ace-dtls-authorize: * No current known issues Jim & Roman From nobody Mon Oct 8 14:35:55 2018 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 BD405131007 for ; Mon, 8 Oct 2018 14:35:53 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 c0SXLpDZlSWe for ; Mon, 8 Oct 2018 14:35:52 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4472D131000 for ; Mon, 8 Oct 2018 14:35:52 -0700 (PDT) Received: from Jude (192.168.0.11) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 8 Oct 2018 14:30:09 -0700 From: Jim Schaad To: Date: Mon, 8 Oct 2018 14:34:40 -0700 Message-ID: <065d01d45f4e$bc227690$346763b0$@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: AdRfTjn+qfbLUnxrRYOILLAcZZbLow== Content-Language: en-us X-Originating-IP: [192.168.0.11] Archived-At: Subject: [Ace] WGLC for 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: Mon, 08 Oct 2018 21:35:54 -0000 The chairs believe that the set of documents dealing with the OAuth framework for constrained environments is nearing the point that we should be able to advance it to the IESG for publication. We therefore want to have a full list of issues that need to be dealt with at the Bangkok meeting. This starts a 2 week WGLC for draft-ietf-ace-oauth-params We know that the following issues are outstanding: draft-ietf-ace-oauth-params: * No current known issues Jim & Roman From nobody Mon Oct 8 14:48:49 2018 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 72993131065 for ; Mon, 8 Oct 2018 14:48:48 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 BNuttm2nW8Hi for ; Mon, 8 Oct 2018 14:48:46 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96F8213104E for ; Mon, 8 Oct 2018 14:48:46 -0700 (PDT) Received: from Jude (192.168.0.11) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 8 Oct 2018 14:43:44 -0700 From: Jim Schaad To: Date: Mon, 8 Oct 2018 14:48:18 -0700 Message-ID: <066801d45f50$a1ada080$e508e180$@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: AdRfUAXU+MBQz34oTo2KRjGx88hrig== Content-Language: en-us X-Originating-IP: [192.168.0.11] Archived-At: Subject: [Ace] Agenda for the Bangkok meeting X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 21:48:48 -0000 If you want a space on the agenda in Bangkok, please send the chairs (ace-chairs@ietf.org) a request. That request should include: * Document * Who is presenting * Is this going to be remote? (If yes then an alternate local presenter name is requested as well.) * How long do you believe you will need. We are currently scheduled for a 2 hour meeting and the primary focus is going to be dealing with WGLC issues (if any). Thus all other requests may be dropped due to a lack of time. Jim From nobody Wed Oct 10 07:24:31 2018 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 38955130F9D for ; Wed, 10 Oct 2018 07:24:14 -0700 (PDT) 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] 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 iNoF8E97jvrc for ; Wed, 10 Oct 2018 07:24:11 -0700 (PDT) Received: from smtp.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 97C69130DF4 for ; Wed, 10 Oct 2018 07:24:07 -0700 (PDT) Received: from [192.168.1.109] (p508A4EFC.dip0.t-ipconnect.de [80.138.78.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id BBE2425957 for ; Wed, 10 Oct 2018 16:24:05 +0200 (CEST) From: Stefanie Gerdes To: "Ace@ietf.org" Message-ID: <4519f58c-c6f7-5ac0-003c-7ae4f59bccd4@tzi.de> Date: Wed, 10 Oct 2018 16:24:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Ace] ACE Framework Review 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, 10 Oct 2018 14:24:21 -0000 Hi, I looked through the ACE framework document. I think there are some open issues that need to be addressed. I will try to summarize the main issues below. We provided a rough analysis of the DTLS profile in [1], which may also be interesting (many of the issues mentioned there were already fixed in the meantime). The protocol elements of the framework assume that responses are bound to requests in the sense that the receiver of a response can be certain that response actually belongs to a certain request. This requirement should be mentioned, e.g., in the security considerations. The minimal security requirements for the communication between two communication partners should be listed (C-AS, RS-AS, C-RS, respectively). Which pieces of information do they require prior to the communication? How must the communication be secured? Which keying material do they need to use? The framework should point out that all claims that influence the security must stem from claimants that were approved by the respective human being that is responsible for the device, i.e., the requesting party for the client and the resource owner for the AS and RS. Otherwise the solution is not secure. Validity of the access token (Token Expiration, Section 5.8.3): There seem to be additional requirements here that are currently not mentioned. It is not clear how RS determines the freshness of introspection messages (and how fresh they are). Also, the token introspection approach is particularly vulnerable to DoS attacks since introspection messages must be exchanged to validate every token. This should at least be mentioned in the security considerations. The sequence number approach has the problem that an attacker may withhold new tokens from RS. In this case, old tokens are infinitely valid. This is particularly damaging because C may have a strong interest to withhold new tokens and can easily do so by not relaying them to RS. This approach therefore must not be used unless there is an additional communication channel between RS and AS that regularly informs RS which the most recent sequence number is. Authorization of the AS on the RS side: in the ACE framework, RS checks the integrity of the access token (e.g., section 4, section 6, Appendix B: Resource Server). RS must also check that the access token stems from an AS that is authorized by RO to provide the token. If RS accepts tokens from authorization servers that are not approved by RO, the solution is not secure. Introspection messages must also stem from an AS that is approved by RO. Access token validation: Section 5.8.1 should point out that RS must check the integrity of the token and validate that it stems from AS that is authorized by RO. Also, it would be helpful if the section also contained information how a server must react to missing fields, e.g., missing authenticity of the token or tokens from unknown authorization servers. Confidentiality of access tokens: In the access token, confidentiality is only demanded for symmetric keys. The security considerations should point out that other data in the access token may be confidential and then require protection as well. Authorization Rules in Access Token: The framework should mention in section 5.6.2 that the authorization rules that are presented to RS in the scope of the access token must reflect RO's decisions. Management of the authz-info resource: * The authz-info resource is vulnerable to DoS attacks: clients may (with or without intention) send large numbers of access tokens to RS. A constrained RS may soon run out of memory/storage space if it needs to store large numbers of tokens. If introspection messages are used to check the validity of access tokens, the use of the authz-info resource amplifies the risk of DoS attacks since RS must send a message to its AS for every received token. These problems should be mentioned in the security considerations. The preferred mitigation should be that the authz-info resource is only used for protected communication. This does obviously not work for the RPK mode. In the PSK mode, RS should be able to decide that it uses the authz-info resource only for protected updates. * How must the authz-info resource be protected? E.g., an attacker that is able to modify the resource may change or delete access tokens. The framework leaves the protection of the resource to the profiles, but I think some general advice can be offered by the framework. Validity of the access information: It seems that the people who wrote the framework did not consider that the keying material is not only provided to RS but also to C. How does C determine if the keying material it receives from AS is still valid? The access token response may comprise an expires_in field that contains the validity period of the access token in seconds (RFC 6749), but does not specify the validity period of the keying material. But even if the validity periods are equal, C does not know when the access token was generated. Also, the use of the expires_in field is optional. Without protection, the access information is infinitely valid. C may use outdated and maybe compromised keying material to communicate with RS. The framework should provide information how C determines if the keying material is still valid. Also, C must check if the keying material it has for a communication partner is still valid before sending a request. The framework should also mention that C must determine if AS is authorized by its owner to provide keying material concerning RS to C. It is not clear how C makes plain to AS with which RS it wants to communicate. C may specify the intended audience in the token request using the req_aud parameter. How is RS represented in this case? C and AS must have a common understanding how RS is identified, otherwise C may communicate with the wrong RS! IP addresses may change and therefore are not suitable. If AS specifies identifiers for RS, C must securely obtain this knowledge. The framework must point out that AS must check if the keying material that it provides to C in the access token response actually refers to the RS that C wants to communicate with. The problem of mixups concerning the RS must be mentioned in the security considerations. Also, the framework should give advice how this problem may be addressed. Confidentiality of unauthorized requests: The data that the client sends to the RS in an unauthorized resource request may be confidential (e.g., because others must not know the requested resources). The framework should mention in the security considerations that the client must not send confidential data in the unauthorized resource request. Viele Grüße Steffi [1] https://dx.doi.org/10.14722/diss.2018.23006 From nobody Sun Oct 14 06:36:36 2018 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 5835C1293FB; Sun, 14 Oct 2018 06:36:34 -0700 (PDT) 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, 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 pK6yjU_JDrQA; Sun, 14 Oct 2018 06:36:32 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BB9112F1A6; Sun, 14 Oct 2018 06:36:32 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [82.117.217.154]) by relay.sandelman.ca (Postfix) with ESMTPS id C784F1F906; Sun, 14 Oct 2018 13:36:30 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 4C958E38; Sun, 14 Oct 2018 09:36:22 -0400 (EDT) From: Michael Richardson To: ace@ietf.org, anima@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Sun, 14 Oct 2018 15:36:22 +0200 Message-ID: <8106.1539524182@dooku.sandelman.ca> Archived-At: Subject: [Ace] FYI: EST COAP, and enrollment interop list 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, 14 Oct 2018 13:36:35 -0000 --=-=-= Content-Type: text/plain The group of people who want to do EST, EST-COAP, and ANIMA-BRSKI enrollment testing has become too unweidly for a CC list to be useful. The conclusion was that we probably do not need an @ietf.org archived list, etc. I created a list at: https://lists.sandelman.ca/mailman/listinfo/est-and-bootstrap-plugtesting We have planned a series of online/virtual testing sessions on EST-COAP, generally Tuesday at 1500UTC for an hour (Oct. 15 and Oct. 23). We expect to do work at/during the IETF103 Hackathon, and we would welcome remote hackathon participants as well: but obviously you'll need a public IPv4 and/or IPv6 so that we can get traffic to you. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAlvDRlUACgkQlUzhVv38 QpDcPQf+P2nqs4AhCr5jRpvv3jux31009UMWGDXCj+dWYcCNCuuUEvzXEyhtQcBw CMn1KGafARh6k07ViKboTgJ7zJic85fPCYKvXxvyjCosI4LV+tBgAKn1IW+hmmQF QxCCWIcaUn7m1G8cc16yFSryQ/Iplk/lY/zDGP+/RMCzPsy1QpxLePtUJxHDCo8W q4B2vTQqgHexDx8Dmj/Fd1wIYo0asa90wvsI3hS3dzEOHg9mY6OYALT6dYsQO+ny 8SXzdtWbc+dpJlE3MQPofl+SUuyLlIFFyDoHlRkcQS6RG3JL45BaSkC/SHIawutr kZFeiyPEfA0e8rkrU0beI2SJufu2kw== =VJ0b -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Oct 16 02:23:31 2018 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 A9202130DC4 for ; Tue, 16 Oct 2018 02:23:29 -0700 (PDT) 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] 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 ZRkaTSagviJ9 for ; Tue, 16 Oct 2018 02:23:27 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24C3312D4EE for ; Tue, 16 Oct 2018 02:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w9G9NINg017889 for ; Tue, 16 Oct 2018 11:23:23 +0200 (CEST) Received: from [134.102.29.87] (unknown [134.102.29.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 42Z8xL1J1Nz1Bqf; Tue, 16 Oct 2018 11:23:18 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 561374596.680451-b626b15f1df31f0d7911d1edcd1be7c7 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 16 Oct 2018 11:23:18 +0200 Message-Id: To: ace X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Ace] Updating draft-ietf-ace-actors for Bangkok 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, 16 Oct 2018 09:23:30 -0000 During processing the framework and profiles drafts, it became clear = that we do need the architectural considerations written up in = draft-ietf-ace-actors. While we had to put all energy into the = solutions documents so far, we now have an opportunity to fix the = informational document as well. Steffi has prepared a pull request that contains a number of editorial = cleanups (and removes some cobwebs): https://github.com/ace-wg/actors/pull/1 If there are no problems with this PR, I=E2=80=99d like to merge it and = submit an update of the I-D for Bangkok. We won=E2=80=99t have time on = the WG agenda (too much work fixing the solutions drafts), but I=E2=80=99m= sure there will be opportunity in the hallways. We continue to be = pretty close to WGLC for this one=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Oct 17 07:38:13 2018 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 B93E6130DE0; Wed, 17 Oct 2018 07:38:10 -0700 (PDT) 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, 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 TDmTa8ynpbKc; Wed, 17 Oct 2018 07:38:07 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D52AC130DDE; Wed, 17 Oct 2018 07:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w9HEbvei026196; Wed, 17 Oct 2018 16:38:02 +0200 (CEST) Received: from [192.168.217.114] (p54A6CA9F.dip0.t-ipconnect.de [84.166.202.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 42Zvsw4klHz1Bql; Wed, 17 Oct 2018 16:37:56 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 561479874.377188-fedd7e99c522a9762603e0f7657e5add Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 17 Oct 2018 16:37:55 +0200 Message-Id: To: ace , "core@ietf.org WG" , cose , cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Ace] Constrained Node/Network Cluster @ IETF103: "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: Wed, 17 Oct 2018 14:38:11 -0000 Here is my usual eclectic condensed agenda based on the "FINAL" AGENDA for IETF103. A few changes from the DRAFT AGENDA. I waited a bit with sending this as a few more side meetings have become known, as well. Of course, "FINAL" doesn't mean final. cbor/teep and 6tisch/ace (was suit) are annoying but probably livable. qirg no longer conflicts with core :-). dinrg is now on top of lpwan. secdispatch on top of t2trg will all but make sure no security people attend t2trg. All times are ICT (Indochina Time) =3D=3D UTC +7 hours. There is no daylight saving time in effect in Thailand. DST will have ended in Europe by then (e.g., CET =3D UTC+0100) and will end in the US during the initial weekend (On Sun, Nov 4; e.g. EST =3D UTC-0500). (You can get pure UTC times on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Please note that the Friday schedule is still evolving; plan to stick around until 13:20 or you may miss interesting conversations. Gr=C3=BC=C3=9Fe, Carsten SATURDAY/SUNDAY, November 3/4. 2018 -- Hackathon (including various interops) (Centre Ville), e.g.: T2TRG WISHI, possibly some CBOR, LPWAN, TLS 1.3, EST-COAPS, TEEP Please see https://trac.ietf.org/trac/ietf/meeting/wiki/103hackathon -- Sun 1700-1900 Welcome Reception - Garden at Queen's Park -- Sun 1800-2000 Hot RFC Lightning Talks - Chitlada 3 MONDAY, November 5, 2018 0900-1100 Morning Session I Chitlada 2 ART dispatch Dispatch WG - Joint with ARTAREA Meeting 1 OPS v6ops IPv6 Operations WG Boromph. 1/2 RTG *** roll Routing Over Low power and Lossy = networks WG Meeting 2 SEC oauth Web Authorization Protocol WG 1120-1220 Morning Session II Chitlada 1 IRTF cfrg Crypto Forum Chitlada 2 TSV tsvarea Transport Area Open Meeting 1350-1550 Afternoon Session I Boromph. 1/2 ART *** core Constrained RESTful Environments WG Meeting 1 OPS anima Autonomic Networking Integrated Model = and Approach WG Chitlada 2 SEC tls Transport Layer Security WG Chitlada 3 TSV tsvwg Transport Area Working Group WG 1610-1810 Afternoon Session II Meeting 2 INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Chitlada 1 IRTF irtfopen IRTF Open Meeting Chitlada 2 SEC mls Messaging Layer Security WG TUESDAY, November 6, 2018 0900-1100 Morning Session I Chitlada 1 ART httpbis Hypertext Transfer Protocol WG Meeting 1 INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Meeting 2 IRTF*** dinrg Decentralized Internet Infrastructure = Proposed RG Boromph. 4 SEC tokbind Token Binding WG 1120-1220 Morning Session II Chitlada 3 INT ipwave IP Wireless Access in Vehicular = Environments WG Chitlada 2 IRTF qirg Quantum Internet Proposed Research Group Meeting 1 SEC oauth Web Authorization Protocol WG 1350-1550 Afternoon Session I Chitlada 3 INT 6man IPv6 Maintenance WG Chitlada 2 SEC rats Remote ATtestation ProcedureS BOF Chitlada 1 TSV quic QUIC WG 1610-1810 Afternoon Session II Chitlada 1 IRTF maprg Measurement and Analysis for Protocols Meeting 1 IRTF*** t2trg Thing-to-Thing Meeting 2 SEC secdispatch Security Dispatch WG Pagoda -- 1700..1800 CACAO side meeting Apartment 3 -- 1800..2000 IoT Onboarding side meeting (lear/mcr) WEDNESDAY, November 7, 2018 0900-1100 Morning Session I Chitlada 3 ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Boromph. 3 RTG bier Bit Indexed Explicit Replication WG Meeting 2 SEC *** teep Trusted Execution Environment = Provisioning WG Chitlada 1 TSV quic QUIC WG 1120-1220 Morning Session II Meeting 2 INT *** lwig Light-Weight Implementation Guidance WG Chitlada 1 SEC tls Transport Layer Security WG Chitlada 2 TSV tsvwg Transport Area Working Group WG 1350-1520 Afternoon Session I Meeting 2 GEN wugh WGs Using GitHub BOF Chitlada 3 INT homenet Home Networking WG Meeting 1 IRTF panrg Path Aware Networking RG -- 1400..1500 IoT Onboarding Mechanisms side meeting 1540-1710 Afternoon Session II Chitlada 3 INT intarea Internet Area Working Group WG Meeting 1 IRTF pearg Privacy Enhancements and Assessments = Proposed Research Group Boromph. 3 RTG babel Babel routing protocol WG Boromph. 1/2 RTG rift Routing In Fat Trees WG Meeting 2 TSV taps Transport Services WG THURSDAY, November 8, 2018 0900-1100 Morning Session I Chitlada 1 ART httpbis Hypertext Transfer Protocol WG Meeting 2 IRTF icnrg Information-Centric Networking Chitlada 2 SEC *** suit Software Updates for Internet of Things = WG 1120-1220 Morning Session II Chitlada 2 ART *** core Constrained RESTful Environments WG Boromph. 1/2 RTG bier Bit Indexed Explicit Replication WG Chitlada 1 SEC mls Messaging Layer Security WG Meeting 1 TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1350-1550 Afternoon Session I Meeting 2 INT dnssd Extensions for Scalable DNS Service = Discovery WG Chitlada 2 RTG detnet Deterministic Networking WG Chitlada 1 SEC saag Security Area Open Meeting 1610-1810 Afternoon Session II Boromph. 3 INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Chitlada 3 RTG rtgarea Routing Area Open Meeting Chitlada 1 SEC *** ace Authentication and Authorization for = Constrained Environments WG Boromph. 1/2 SEC acme Automated Certificate Management = Environment WG FRIDAY, November 9, 2018 Various ad-hoc meetings, please see https://trac.ietf.org/trac/ietf/meeting/wiki/103sidemeetings#FRIDAY Boromph. 4 -- 0900..1320 T2TRG work meeting Boromph. 3 -- 1000..1200 COIN (Computing in the Network) From nobody Fri Oct 19 12:04:05 2018 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 AEB161310D8; Fri, 19 Oct 2018 11:56:41 -0700 (PDT) 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.87.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153997540170.6592.361953638891641634.idtracker@ietfa.amsl.com> Date: Fri, 19 Oct 2018 11:56:41 -0700 Archived-At: Subject: [Ace] ace - Requested session has been scheduled for IETF 103 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, 19 Oct 2018 18:56:50 -0000 Dear Jim Schaad, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. ace Session 1 (2:00 requested) Thursday, 8 November 2018, Afternoon Session II 1610-1810 Room Name: Chitlada 1 size: 300 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/103/sessions/ace.ics Request Information: --------------------------------------------------------- Working Group Name: Authentication and Authorization for Constrained Environments Area Name: Security Area Session Requester: Jim Schaad Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: saag cbor core tls lamps cfrg secdispatch ace emu dots Second Priority: quic oauth secevent tokbind t2trg lwig anima suit teep mile Third Priority: doh httpbis uta 6tisch homenet curdle People who must be present: Roman Danyliw Jim Schaad Benjamin Kaduk Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Oct 22 05:59:54 2018 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 9284D12D7F8 for ; Mon, 22 Oct 2018 05:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.365 X-Spam-Level: X-Spam-Status: No, score=-4.365 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 header.b=ChvowoJ9; dkim=pass (1024-bit key) header.d=ericsson.com header.b=XDxKGSYI Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kjn_H_PUQI8r for ; Mon, 22 Oct 2018 05:59:50 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21D79128D0C for ; Mon, 22 Oct 2018 05:59:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1540213188; x=1542805188; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=esE+8f3sbXiJrIgQN4fbJIB3tEESfxEPzUQejypBHOg=; b=ChvowoJ9enzMWrGNsQvCOyi/AWBnEREt+vuZNYFpxV7rtf/CVzptvIt2qPD/oWiu P918YRB0kfSZ/k8dy9ncqxstBJW4OOC8QDLSnIyCHXA2UduALEaVNy0qyRu872hf Bu264DIoDu43GNUV5dZYPJM/BmbrpZ1rLG5+3cgj5SY=; X-AuditID: c1b4fb2d-fb3d09e000003a27-7d-5bcdc9c475b6 Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id E5.D0.14887.4C9CDCB5; Mon, 22 Oct 2018 14:59:48 +0200 (CEST) Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 22 Oct 2018 14:59:47 +0200 Received: from EUR04-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 22 Oct 2018 14:59:47 +0200 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=esE+8f3sbXiJrIgQN4fbJIB3tEESfxEPzUQejypBHOg=; b=XDxKGSYIbEtyIkpXeFng9DJSAthC3QbavANWV2Ly1Mg6MPv83Zpv9agG91Xl7YL2kxMrX/z903zNigRCz94VrX3X3jTc0If5juxXqxDocoM/V3LfE8D34nE6HfvqZQ/NRlyhh7W72YXcmHC447GG/8bYjGtRvofsd0WnRgcaMbg= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.188.140) by HE1PR0701MB2698.eurprd07.prod.outlook.com (10.168.188.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1273.10; Mon, 22 Oct 2018 12:59:47 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::c05a:fd61:6104:51e5]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::c05a:fd61:6104:51e5%6]) with mapi id 15.20.1273.014; Mon, 22 Oct 2018 12:59:47 +0000 From: Francesca Palombini To: "ace@ietf.org" CC: "draft-palombini-ace-key-groupcomm@ietf.org" Thread-Topic: New Version Notification for draft-palombini-ace-key-groupcomm-02.txt Thread-Index: AQHUagWT75KGZGBxWUSGFgqR2zwTxqUrW7MA Date: Mon, 22 Oct 2018 12:59:46 +0000 Message-ID: <4E794B49-5F94-4258-B231-17486F88048C@ericsson.com> References: <154021251097.15369.12957645691483192537.idtracker@ietfa.amsl.com> In-Reply-To: <154021251097.15369.12957645691483192537.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US 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.80] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2698; 6:YiDT1VNf6C2TA2R0pXOcH75fNDrG5STdeQ0ujU6moAqEu2ebxXmDzQxssneGI++rQCDbsfcifWPB+elfU7MxmgyAFV+jWNN8l6ClLhTjHAvQkiJ3tQdT0+wAMHBuHkKBgSY5Yat7IGJNmPqp0ZivGSkEHvZSqvQf8A8mJT+pkdq2QcPsrlR9DjJ61CJN46d7h9+zAtn9akxi0quxF3z5wZnavTefaeTJsFjg6qhMeosCUcR/cOsLl2EcQgden9dZ/Ix6nWP6fpINdxuZR6uOHBYUwpMSOx3mfpjPQNSANRaaLkVYpKCG3E7RVgSWhzWcYoiKLJ88i4ylX8NfaSmE8uo2qJsYuGGgYG02cfcufkrDfgzVUSL1JwbS1SDYYwdyO0OJ9/1dFnVFDrS6uiUY1BbiOc2WLPO97sav2fHaM8Y/pi3p9+gpu/yn2HxeAj4csDDHoJaeHSZ9QaOS8l5LxA==; 5:HDtLmsgk0N2HdhrQtX+aQ+4L4jmrIe2lEOmJaj+/cDBVLpEwn/2OMukMoZeudmxAyi2O+jb3SBElkN73aF/cehtt5amRWqmVj9zUKal4eit2uZflZOrbwMstPW774bH5VxAJ32++iZTKDIe5H9aClZfG+8Qz3GJjQ+c4LVdfG4Q=; 7:pQQdtM47i7ZQ7nFvOaC2BRdh3MT9IO+9FF7Sh/qcKdH89EDpRoGco5NBS8cHxL33UxjozVERvcej0svNh/eBzTLxgoykerwq48NTghWAOzzPBn1XxfzLTZvJzMqP0RhUXL+Uk7Wy741n7tp6mBtw4g== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 75be8cda-3790-4dbe-b733-08d6381e3eae x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:HE1PR0701MB2698; x-ms-traffictypediagnostic: HE1PR0701MB2698: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231355)(944501410)(52105095)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:HE1PR0701MB2698; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2698; x-forefront-prvs: 08331F819E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(39860400002)(136003)(346002)(396003)(199004)(189003)(53754006)(186003)(83716004)(26005)(446003)(11346002)(2616005)(44832011)(71200400001)(71190400001)(486006)(5250100002)(256004)(14444005)(97736004)(476003)(4001150100001)(76176011)(2900100001)(99286004)(305945005)(82746002)(2501003)(86362001)(66066001)(7736002)(3846002)(33656002)(6916009)(2906002)(14454004)(966005)(229853002)(6116002)(450100002)(4326008)(5660300001)(6436002)(6486002)(2351001)(36756003)(25786009)(8936002)(316002)(102836004)(6506007)(6306002)(106356001)(2473003)(6512007)(81156014)(81166006)(478600001)(15650500001)(53936002)(1730700003)(5640700003)(105586002)(8676002)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2698; H:HE1PR0701MB2746.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-microsoft-antispam-message-info: 7jccILNQYeFpQeUyTDLP1MENPMjh3Nz5W6xvhIsmUHyWcJH92qtuyWnDSTbMbKSpbsUg61Jwi+4A/dJmnx89lR04Xz/rRGL11FMfC+dqeWQY8z8ql5BKqOfq63/1aGX78A1n1jqXyEAp/Qjikh7nhO7qZeo0rtsKhJMV6yJFuJGSbh0oVJ2GYjU+Gpsd9KXSKwqpfIX/Nc1cim8bc+pP6g3ywz9eFG774B/qfcRUAxV2F12XsozLRfapLTW/uJrJ2GAy7iSs9EYrauQTejJl4T7tfsOFZJlnBQkUG6ebUCEGXvEpjU/45pK4Vep3oZxsk+HgEmYGiqPCCP5f9mEFe+z1serVwcpgFv2GuKTUorc= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 75be8cda-3790-4dbe-b733-08d6381e3eae X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2018 12:59:46.9784 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2698 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphleLIzCtJLcpLzFFi42KZGbG9XPfIybPRBss/yll8/9bDbNF06jCj A5PHkiU/mQIYo7hsUlJzMstSi/TtErgyOi6eZix4JVLx9M5f1gbGJSJdjJwcEgImElOvb2Tq YuTiEBI4yigx79ICKOcbo0TnzffsEM4SJomFL/cxgjgsAhOYJf4uOcgGkZnBJLH93zoo5xmj xKpTk9hBJrMJ2EhcePietYuRg0NEQFHi+qNEkDCzQLzEsYkzGEFsYYEQifd3XjOD2CICoRKn rs1ihbCNJDqPf2ABsVkEVCU6P69nA7F5BewlJly9DFYvJOAn8f3OBbA5nAL+EhcX7wSLMwrI SnxpXM0MsUtc4taT+UwQjwpILNlznhnCFpV4+fgfK0R9ssSV233sEHEFiSVfJkLZshKX5neD fSwhcINN4umub1CDdCU+TJ0KNchXYu+sv2wQRScZJd49eMIGkdCRWHRkJSOEnS9x6uMVqAZr iROLb7JA2HISq3ofskxgNJqF5NhZwPBiFtCUWL9LHyLsIbH36xlWCFtRYkr3Q/ZZ4LAQlDg5 8wnLAkbWVYyixanFxbnpRsZ6qUWZycXF+Xl6eaklmxiBaeTglt+6OxhXv3Y8xCjAwajEw2ux 72y0EGtiWXFl7iFGCQ5mJRHelUuAQrwpiZVVqUX58UWlOanFhxilOViUxHn1Vu2JEhJITyxJ zU5NLUgtgskycXBKNTCyfWwoceTUfiavus9kvUqW5sti1ZlHqm6zfRdUEJuw16f7z6PKpZav 8tenptzYdbEotLttbsrFXYk3NvJNX9teXz5FcrfllalLFpu5buwKjr9Xf2VCZY7L25ktD6U/ Zh+JZPvvvj9SyqDl+rryjjdKPNZRTtWXooIY3F5cs/e8Eqlr9buo/6YSS3FGoqEWc1FxIgDi PiIKHwMAAA== Archived-At: Subject: [Ace] FW: New Version Notification for draft-palombini-ace-key-groupcomm-02.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, 22 Oct 2018 12:59:52 -0000 SGkgYWxsLA0KDQpXZSBoYXZlIGp1c3Qgc3VibWl0dGVkIHYtMDIgb2YgdGhlIGFjZS1rZXktZ3Jv dXBjb21tIGRyYWZ0Lg0KDQpUaGlzIHZlcnNpb24gZXhwYW5kcyBvbiB0aGUgcmUta2V5aW5nIG9m IGdyb3VwIG1lbWJlcnMsIGFmdGVyIG5vZGVzIGpvaW4gb3IgbGVhdmUgdGhlIGdyb3VwLiBJdCBh bHNvIHRyaWVzIHRvIGNsYXJpZnkgdGhlIG1lc3NhZ2UgZXhjaGFuZ2UsIGdpdmluZyBhbiBoaWdo IGxldmVsIGludHJvZHVjdGlvbiBiZWZvcmUgZXZlcnkgc3Vic2VjdGlvbi4NCg0KV2l0aCB0aGlz IHVwZGF0ZSwgd2UgaG9wZSB0byBoYXZlIGFuc3dlcmVkIG1vc3Qgb2YgdGhlIHJldmlldyBjb21t ZW50cyBmcm9tIEppbSBhbmQgUGV0ZXIgKHRoYW5rIHlvdSEpLCB3ZSB3aWxsIGNvbWUgYmFjayB0 byB5b3VyIHJldmlld3MgYW5kIGFuc3dlciB0byB0aG9zZSBpbiBkZXRhaWwgc29vbi4NCg0KVGhh bmtzLA0KRnJhbmNlc2NhDQoNCu+7v09uIDIyLzEwLzIwMTgsIDE0OjQ4LCAiaW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnIiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiB3cm90ZToNCg0KICAgIA0K ICAgIEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1wYWxvbWJpbmktYWNlLWtleS1ncm91cGNv bW0tMDIudHh0DQogICAgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBGcmFuY2Vz Y2EgUGFsb21iaW5pIGFuZCBwb3N0ZWQgdG8gdGhlDQogICAgSUVURiByZXBvc2l0b3J5Lg0KICAg IA0KICAgIE5hbWU6CQlkcmFmdC1wYWxvbWJpbmktYWNlLWtleS1ncm91cGNvbW0NCiAgICBSZXZp c2lvbjoJMDINCiAgICBUaXRsZToJCUtleSBQcm92aXNpb25pbmcgZm9yIEdyb3VwIENvbW11bmlj YXRpb24gdXNpbmcgQUNFDQogICAgRG9jdW1lbnQgZGF0ZToJMjAxOC0xMC0yMg0KICAgIEdyb3Vw OgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQogICAgUGFnZXM6CQkxNw0KICAgIFVSTDogICAgICAg ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcGFsb21iaW5p LWFjZS1rZXktZ3JvdXBjb21tLTAyLnR4dA0KICAgIFN0YXR1czogICAgICAgICBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wYWxvbWJpbmktYWNlLWtleS1ncm91cGNvbW0v DQogICAgSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1w YWxvbWJpbmktYWNlLWtleS1ncm91cGNvbW0tMDINCiAgICBIdG1saXplZDogICAgICAgaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1wYWxvbWJpbmktYWNlLWtleS1n cm91cGNvbW0NCiAgICBEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlm Zj91cmwyPWRyYWZ0LXBhbG9tYmluaS1hY2Uta2V5LWdyb3VwY29tbS0wMg0KICAgIA0KICAgIEFi c3RyYWN0Og0KICAgICAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBtZXNzYWdlIGZvcm1hdHMgYW5k IHByb2NlZHVyZXMgZm9yIHJlcXVlc3RpbmcNCiAgICAgICBhbmQgZGlzdHJpYnV0aW5nIGdyb3Vw IGtleWluZyBtYXRlcmlhbCB1c2luZyB0aGUgQUNFIGZyYW1ld29yaywgdG8NCiAgICAgICBwcm90 ZWN0IGNvbW11bmljYXRpb25zIGJldHdlZW4gZ3JvdXAgbWVtYmVycy4NCiAgICANCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgDQogICAgDQogICAgDQogICAgUGxlYXNlIG5vdGUgdGhhdCBp dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lv bg0KICAgIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQgdG9vbHMuaWV0Zi5vcmcuDQogICAgDQogICAgVGhlIElFVEYgU2VjcmV0YXJpYXQNCiAgICAN CiAgICANCg0K From nobody Mon Oct 22 06:07:47 2018 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 9EC54130E2A for ; Mon, 22 Oct 2018 06:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 hmiX_YAWYT7p for ; Mon, 22 Oct 2018 06:07:41 -0700 (PDT) Received: from smtp-out11.electric.net (smtp-out11.electric.net [185.38.181.47]) (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 AB3E5130E1A for ; Mon, 22 Oct 2018 06:07:41 -0700 (PDT) Received: from 1gEZvn-000CQR-UG by out11c.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1gEZvn-000CRc-Uz for ace@ietf.org; Mon, 22 Oct 2018 06:07:39 -0700 Received: by emcmailer; Mon, 22 Oct 2018 06:07:39 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out11c.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1gEZvn-000CQR-UG for ace@ietf.org; Mon, 22 Oct 2018 06:07:39 -0700 Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Mon, 22 Oct 2018 15:07:39 +0200 To: References: <4519f58c-c6f7-5ac0-003c-7ae4f59bccd4@tzi.de> From: Ludwig Seitz Message-ID: <43b3b90f-996a-8b8a-2439-e3d6adcc3b0f@ri.se> Date: Mon, 22 Oct 2018 15:07:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <4519f58c-c6f7-5ac0-003c-7ae4f59bccd4@tzi.de> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-1.sp.se (10.100.0.161) To sp-mail-2.sp.se (10.100.0.162) X-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) X-PolicySMART: 14510320 Archived-At: Subject: Re: [Ace] ACE Framework Review 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, 22 Oct 2018 13:07:46 -0000 On 10/10/2018 16:24, Stefanie Gerdes wrote: > Hi, > > I looked through the ACE framework document. I think there are some open > issues that need to be addressed. I will try to summarize the main > issues below. We provided a rough analysis of the DTLS profile in [1], > which may also be interesting (many of the issues mentioned there were > already fixed in the meantime). Thank you for your review. Sorry for the long response time. Answers inline. I also tried to add issues in the issue tracker, but github seems to be experiencing trouble at the moment. /Ludwig > > The protocol elements of the framework assume that responses are bound > to requests in the sense that the receiver of a response can be certain > that response actually belongs to a certain request. This requirement > should be mentioned, e.g., in the security considerations. > Agree. I will add a paragraph. > The minimal security requirements for the communication between two > communication partners should be listed (C-AS, RS-AS, C-RS, > respectively). Which pieces of information do they require prior to the > communication? How must the communication be secured? Which keying > material do they need to use? The first one I agree with. However the other questions seem more specific to the commSec solution to me, which would put them into the profiles. > The framework should point out that all > claims that influence the security must stem from claimants that were > approved by the respective human being that is responsible for the > device, i.e., the requesting party for the client and the resource owner > for the AS and RS. Otherwise the solution is not secure. > Are there claims that do not influence security? The specification says (section 4): The consent of the resource owner, for giving a client access to a protected resource, can be provided dynamically as in the traditional OAuth flows, or it could be pre-configured by the resource owner as authorization policies at the AS, which the AS evaluates when a token request arrives. The resource owner and the requesting party (i.e., client owner) are not shown in Figure 1. I believe this is what you were looking for, if not please explain what is missing. > Validity of the access token (Token Expiration, Section 5.8.3): There > seem to be additional requirements here that are currently not > mentioned. It is not clear how RS determines the freshness of > introspection messages (and how fresh they are). That would be up to the commSec protocol, also it is covered in the security considerations of RFC 7662. I will add a reference to those considerations in our security considerations section. > Also, the token > introspection approach is particularly vulnerable to DoS attacks since > introspection messages must be exchanged to validate every token. This problem applies to regular OAuth introspection as well and is covered in the security considerations of RFC 7662. > The sequence number approach has the problem that an attacker may > withhold new tokens from RS. In this case, old tokens are infinitely > valid. This is particularly damaging because C may have a strong > interest to withhold new tokens and can easily do so by not relaying > them to RS. This approach therefore must not be used unless there is an > additional communication channel between RS and AS that regularly > informs RS which the most recent sequence number is. > This is a best effort approach when the RS has no internal sense of time. Also the idea was that several client could submit tokens with an ever increasing unique serial number maintained by the AS. Thus even if one client would withhold it's newer tokens to keep the old ones from expiring, the other clients would eventually submit enough new tokens (with higher sequence numbers) so that the token expires. AFAIK the RS with no internal clock at all is a very rare occurrence, thus you can usually expect some form of wallclock time, and thus implement an expiration based on "time-since-you-received-this-token". > Authorization of the AS on the RS side: in the ACE framework, RS checks > the integrity of the access token (e.g., section 4, section 6, Appendix > B: Resource Server). RS must also check that the access token stems from > an AS that is authorized by RO to provide the token. If RS accepts > tokens from authorization servers that are not approved by RO, the > solution is not secure. Introspection messages must also stem from an AS > that is approved by RO. This is implicit, if the RS has the key that allows it to verify the integrity of the token that means that it is an AS approved by its RO. I will try to add a sentence to make that more explicit. > > Access token validation: Section 5.8.1 should point out that RS must > check the integrity of the token and validate that it stems from AS that > is authorized by RO. We can expand on this phrase I think: "The RS receiving the token MUST verify the validity of the token." > Also, it would be helpful if the section also > contained information how a server must react to missing fields, e.g., > missing authenticity of the token or tokens from unknown authorization > servers. > This would be the following sentence in 5.8.1: "If the token is not valid, the RS MUST respond with a response code equivalent to the CoAP code 4.01 (Unauthorized)." > Confidentiality of access tokens: > In the access token, confidentiality is only demanded for symmetric > keys. The security considerations should point out that other data in > the access token may be confidential and then require protection as well. > This should be covered in RFC 6749 and RFC 6819 which are referenced in the security considerations. > Authorization Rules in Access Token: The framework should mention in > section 5.6.2 that the authorization rules that are presented to RS in > the scope of the access token must reflect RO's decisions. That is already covered by the text in section 4 (see comment above). > > Management of the authz-info resource: > * The authz-info resource is vulnerable to DoS attacks: clients may > (with or without intention) send large numbers of access tokens to RS. A > constrained RS may soon run out of memory/storage space if it needs to > store large numbers of tokens. A RS is not expected to store large numbers of tokens. Section 5.8.1 specifies: "The RS MUST be prepared to store at least one access token for future use." Thus the RS can adapt the number of tokens it stores to its constrained storage resources. > If introspection messages are used to > check the validity of access tokens, the use of the authz-info resource > amplifies the risk of DoS attacks since RS must send a message to its AS > for every received token. These problems should be mentioned in the > security considerations. I will add a section describing the problem. > The preferred mitigation should be that the > authz-info resource is only used for protected communication. This does > obviously not work for the RPK mode. In the PSK mode, RS should be able > to decide that it uses the authz-info resource only for protected updates. I don't think that will help, since somehow the initial access token must get to the RS. So even when passing it through the DTLS handshake (as with PSK in the DTLS profile) the same DoS risk exists. > * How must the authz-info resource be protected? E.g., an attacker that > is able to modify the resource may change or delete access tokens. The > framework leaves the protection of the resource to the profiles, but I > think some general advice can be offered by the framework. I can add a paragraph on this in section 5. > > Validity of the access information: > It seems that the people who wrote the framework did not consider that > the keying material is not only provided to RS but also to C. > How does C determine if the keying material it receives from AS is still > valid? It is valid as long as you don't get a 4.01 (Unauthorized) from the RS. > The access token response may comprise an expires_in > field that contains the validity period of the access token in seconds > (RFC 6749), but does not specify the validity period of the keying > material. But even if the validity periods are equal, C does not know > when the access token was generated. Also, the use of the expires_in > field is optional. Without protection, the access information is > infinitely valid. C may use outdated and maybe compromised keying > material to communicate with RS. The framework should provide > information how C determines if the keying material is still valid. > Also, C must check if the keying material it has for a communication > partner is still valid before sending a request. > I would think that in most cases it is acceptable that the client just optimistically sends its request with the existing keying material and renews it if it gets back a 4.01. Use cases where the security policy is such that this is unacceptable should use a specific profile that defines additional mechanisms for the client to check its tokens and associated keying material (e.g. by using client introspection). > The framework should also mention that C must determine if AS is > authorized by its owner to provide keying material concerning RS to C. If C is configured to communicate with RS, this implies that the owner of C accepts the AS in charge of RS. Otherwise the owner of C shouldn't have configured C to communicate with RS in the first place. > It is not clear how C makes plain to AS with which RS it wants to > communicate. C may specify the intended audience in the token request > using the req_aud parameter. How is RS represented in this case? > C and AS must have a common understanding how RS is identified, > otherwise C may communicate with the wrong RS! > IP addresses may change and therefore are not suitable. If AS specifies > identifiers for RS, C must securely obtain this knowledge. Identifying the RS (using the audience claim and the req_aud parameter) is application specific. Some applications may want to use public keys, others will want to use fixed identifiers that are manually assigned or otherwise generated. The framework does not suggest IP addresses as a way to identify an RS. > The framework must point out that AS must check if the keying material > that it provides to C in the access token response actually refers to > the RS that C wants to communicate with. The problem of mixups > concerning the RS must be mentioned in the security considerations. > Also, the framework should give advice how this problem may be addressed. > I will add a paragraph describing the problem and giving some basic suggestions (such as public keys as identifiers). > Confidentiality of unauthorized requests: > The data that the client sends to the RS in an unauthorized resource > request may be confidential (e.g., because others must not know the > requested resources). The framework should mention in the security > considerations that the client must not send confidential data in the > unauthorized resource request. I can add a sentence about this, although it seems very obvious. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 From nobody Mon Oct 22 06:51:24 2018 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 B70E112D4F1; Mon, 22 Oct 2018 06:51:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <154021628260.15118.1570448578564971399@ietfa.amsl.com> Date: Mon, 22 Oct 2018 06:51:22 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-actors-07.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 13:51: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 : An architecture for authorization in constrained environments Authors : Stefanie Gerdes Ludwig Seitz Goeran Selander Carsten Bormann Filename : draft-ietf-ace-actors-07.txt Pages : 31 Date : 2018-10-22 Abstract: Constrained-node networks are networks where some nodes have severe constraints on code size, state memory, processing capabilities, user interface, power and communication bandwidth (RFC 7228). This document provides terminology, and identifies the elements that an architecture needs to address, providing a problem statement, for authentication and authorization in these networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-actors/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-actors-07 https://datatracker.ietf.org/doc/html/draft-ietf-ace-actors-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-actors-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 22 07:13:36 2018 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 562E3126BED for ; Mon, 22 Oct 2018 07:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 jWtZ4SAHFxRt for ; Mon, 22 Oct 2018 07:13:30 -0700 (PDT) Received: from smtp-out10.electric.net (smtp-out10.electric.net [185.38.180.34]) (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 E1529124408 for ; Mon, 22 Oct 2018 07:13:12 -0700 (PDT) Received: from 1gEaxC-0002ge-Uo by out10c.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1gEaxC-0002hx-Vd for ace@ietf.org; Mon, 22 Oct 2018 07:13:10 -0700 Received: by emcmailer; Mon, 22 Oct 2018 07:13:10 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out10c.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1gEaxC-0002ge-Uo for ace@ietf.org; Mon, 22 Oct 2018 07:13:10 -0700 Received: from [10.112.11.37] (10.100.0.158) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Mon, 22 Oct 2018 16:13:10 +0200 References: <154021705018.5365.5695387336827056516.idtracker@ietfa.amsl.com> To: From: Marco Tiloca Openpgp: preference=signencrypt Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= xsBNBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAHNJ01hcmNvIFRpbG9jYSA8bWFyY28udGlsb2NhODRAZ21haWwuY29tPsLAewQTAQIAJQIb AwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AFAlSNerkCGQEACgkQ7iZktA5Y2kMiuwgAt/bV ZKqD92JNWDTX6h1MUsgejwj4RXs6UYqFdWW/4nw4mFHzYS+gBjOQAWCBhzVZLOk6gKcRZ/s8 6ncVygiDUh9fbSDTcuzOp2qgu9nsc8sEsYp1hwmiIEbI6FHPtyeQQNilsfU8+VHX2C9yQtMK /OXlf5qNkJMj9k55u+e1ELQ2sjUXkMB4MxMhmi/3P3hMz9PDcB66BtQcDFYkx5PIaz/izCST 0o28AJq0dionJpPsQ+hFOIAkJi6aCAt3xQf0KnXlAczWxCD3J3XTFK4MES/b3n3oc2GJY8I+ tsfT5jpNsWhfWGBkMaQSKZ939D4oFAhAq3gnNRgZszJeTvsMvc7ATQRUjXkVAQgAlpqfpOi5 GOP3su3gO7pmFXNtoslagBF5ssA2MxI3sGMEXI06x/zcdRKsIyA7lvgQRKDC0WThwoJo6Oh0 ZliLrXGFQrfYnqJLpbZKK/QQaEFT4iPk6edTqdNon5BnKxEDWYu6t35jrYRWcGejSZ1GwNm8 nGimfKApbwwkI+gIxMnQT50u91GhKA7KrBlY2cAoXzjIOTshZvdEI6SMPJtLg1XAsyin8at0 /8+7ckYLnCFHvOBMwbriQREhIyv4RdJ0diw4dUoQ9vRVqxWUjVVQlbtVGGSwGsn/KCihx6TP sIX4xGDuF7A6VeM0NeQPg9eR0Yh0egHX+Dw7TzNQwsIIIwARAQABwsBfBBgBAgAJBQJUjXkV AhsMAAoJEO4mZLQOWNpDxhMH/1jY08t8++Ly5h8nFbBV16EPFtfvOfJkcgHdGvCWM2N8Qewl baiNx8vPeEHMOB+hu/fQNTi/QdRHgPGI92js9DW1Mn+RlvoqLa94fPiiAjmGd+PwUGji83bw zZkaBh5/jXk84Re3knojyoto3sfjVaHYYzlRl8PBIWBpHmS78pxxG6IizOE28j21UfR7HVai hlUw8SkhN52pqN5L7WOrMkRSIlM+VsyX2ALqm7ept08QxG/LAPac2i7oZn5yUXNdh+TVWRGZ hPxJCRU5ZD+MJ2cjkn/69v1XdIh2rgcL+e3KWOhxRTHu67yuLOzBOc3LThJcuQujQrtWWjbX VLqg0jw= X-Forwarded-Message-Id: <154021705018.5365.5695387336827056516.idtracker@ietfa.amsl.com> Message-ID: <260af220-44ff-6eb3-eb21-e009d8426a5a@ri.se> Date: Mon, 22 Oct 2018 16:13:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <154021705018.5365.5695387336827056516.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1YGxCFOAvLxw3QKiFpXt4TwMjDTImUsvr" X-Originating-IP: [10.100.0.158] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-Outbound-IP: 194.218.146.197 X-Env-From: marco.tiloca@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) X-PolicySMART: 14510320 Archived-At: Subject: [Ace] Fwd: New Version Notification for draft-tiloca-ace-oscoap-joining-05.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 14:13:33 -0000 --1YGxCFOAvLxw3QKiFpXt4TwMjDTImUsvr Content-Type: multipart/mixed; boundary="vlVOhN1TjRDT3WOKK6r0oz8JM8pFESNEY"; protected-headers="v1" From: Marco Tiloca To: ace@ietf.org Message-ID: <260af220-44ff-6eb3-eb21-e009d8426a5a@ri.se> Subject: Fwd: New Version Notification for draft-tiloca-ace-oscoap-joining-05.txt References: <154021705018.5365.5695387336827056516.idtracker@ietfa.amsl.com> In-Reply-To: <154021705018.5365.5695387336827056516.idtracker@ietfa.amsl.com> --vlVOhN1TjRDT3WOKK6r0oz8JM8pFESNEY Content-Type: multipart/alternative; boundary="------------CDF10088CBBA06365ECFF747" Content-Language: en-US This is a multi-part message in MIME format. --------------CDF10088CBBA06365ECFF747 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, We have just submitted v -05 of the ace-oscoap-joining draft. This version also expands on the rekeying of current group members, and is aligned with the latest ace-key-groupcomm draft submitted earlier toda= y. Best, /Marco -------- Forwarded Message -------- Subject: New Version Notification for draft-tiloca-ace-oscoap-joining-05.txt Date: Mon, 22 Oct 2018 07:04:10 -0700 From: internet-drafts@ietf.org To: Marco Tiloca , Jiye Park , Francesca Palombini A new version of I-D, draft-tiloca-ace-oscoap-joining-05.txt has been successfully submitted by Marco Tiloca and posted to the IETF repository. Name: draft-tiloca-ace-oscoap-joining Revision: 05 Title: Key Management for OSCORE Groups in ACE Document date: 2018-10-22 Group: Individual Submission Pages: 17 URL: https://www.ietf.org/internet-drafts/draft-tiloca-ace-oscoap-joining-05.t= xt Status: https://datatracker.ietf.org/doc/draft-tiloca-ace-oscoap-joining/= Htmlized: https://tools.ietf.org/html/draft-tiloca-ace-oscoap-joining-05 Htmlized: https://datatracker.ietf.org/doc/html/draft-tiloca-ace-oscoap-joining Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-tiloca-ace-oscoap-joining= -05 Abstract: This document describes a method to request and provision keying material in group communication scenarios where communications are based on CoAP and secured with Object Security for Constrained RESTful Environments (OSCORE). The proposed method delegates the authentication and authorization of new client nodes that join an OSCORE group through a Group Manager server. This approach builds on the ACE framework for Authentication and Authorization, and leverages protocol-specific profiles of ACE to achieve communication security, proof-of-possession and server authentication. Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------CDF10088CBBA06365ECFF747 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all,

We have just submitted v -05 of the ace-oscoap-joining draft.

This version also expands on the rekeying of current group members, and is aligned with the latest ace-key-groupcomm draft submitted earlier today.

Best,
/Marco


-------- Forwarded Message --------
Sub= ject: New Version Notification for draft-tiloca-ace-oscoap-joining-05.txt
Dat= e: Mon, 22 Oct 2018 07:04:10 -0700
Fro= m: internet-drafts@ietf.org
To:= Marco Tiloca <marco.tiloca@ri.se>, Jiye Park <ji-ye.park@uni-due.de>, Francesca Palombini <francesca.palombini@ericsson.com>



A new version of I-D, draft-tiloca-ace-oscoap-joining-05.txt
has been successfully submitted by Marco Tiloca and posted to the IETF repository.

Name: draft-tiloca-ace-oscoap-joining
Revision: 05
Title: Key Management for OSCORE Groups in ACE
Document date: 2018-10-22
Group: Individual Submission
Pages: 17
URL: https://www.ietf.org/inter= net-drafts/draft-tiloca-ace-oscoap-joining-05.txt
Status: https://datatracker.ietf.org= /doc/draft-tiloca-ace-oscoap-joining/
Htmlized: https://tools.ietf.org/html/draft= -tiloca-ace-oscoap-joining-05
Htmlized: https://datatracker.ietf= =2Eorg/doc/html/draft-tiloca-ace-oscoap-joining
Diff: https://www.ietf.org/rfcd= iff?url2=3Ddraft-tiloca-ace-oscoap-joining-05

Abstract:
This document describes a method to request and provision keying material in group communication scenarios where communications are<= br> based on CoAP and secured with Object Security for Constrained
RESTful Environments (OSCORE). The proposed method delegates the authentication and authorization of new client nodes that join an OSCORE group through a Group Manager server. This approach builds on
the ACE framework for Authentication and Authorization, and leverages
protocol-specific profiles of ACE to achieve communication security,
proof-of-possession and server authentication.



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

The IETF Secretariat

--------------CDF10088CBBA06365ECFF747-- --vlVOhN1TjRDT3WOKK6r0oz8JM8pFESNEY-- --1YGxCFOAvLxw3QKiFpXt4TwMjDTImUsvr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAlvN2u4ACgkQ7iZktA5Y 2kM2gwgAobm+ozDtTHGTis+OKqhxdUjGTuNGbS49/8QCmUwaXOVJ+OxdtI/DoUx6 DrOx2kxAGTtQQnH2PKVwcc9PcInyDXUX4pgbXua/A2oR55v2LurSnPMKO7R+2eBu vhHvCHoyBMRrO0K1UlAFt6+Bl+V9mt297TGpN0JYDsTr5VhC5g8TOyc3zO+Y8q4n rHHJqTYg6J+szALdkQwhjom+RdoMlGkevniBRPI/hq66KFv74rkb2rCsFAIS1od7 qJL9J4jV/2njbM82X0Z6XBO+wu1GS5taN9PPQqfprwDppUe2CnESIy/NFn3V0UTk EzoDOIkWCQmCeyjuvT/4AJnGEpu69A== =S7mN -----END PGP SIGNATURE----- --1YGxCFOAvLxw3QKiFpXt4TwMjDTImUsvr-- From nobody Mon Oct 22 07:29:30 2018 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 255E6126BED for ; Mon, 22 Oct 2018 07:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3] 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 vPLunmv4FIYM for ; Mon, 22 Oct 2018 07:29:27 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D32EC124408 for ; Mon, 22 Oct 2018 07:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w9MDvlck007558 for ; Mon, 22 Oct 2018 15:57:52 +0200 (CEST) Received: from [192.168.217.114] (p54A6CA9F.dip0.t-ipconnect.de [84.166.202.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 42dylH4xhlz1Bqf; Mon, 22 Oct 2018 15:57:47 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Mon, 22 Oct 2018 15:57:46 +0200 X-Mao-Original-Outgoing-Id: 561909464.81683-8c79274bef96797980b7c9277186010e Content-Transfer-Encoding: quoted-printable Message-Id: References: To: ace X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Ace] Updating draft-ietf-ace-actors for Bangkok 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, 22 Oct 2018 14:29:29 -0000 Done: Htmlized: https://tools.ietf.org/html/draft-ietf-ace-actors-07 Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-actors-07 Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Oct 22 11:49:14 2018 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 30567128D0C for ; Mon, 22 Oct 2018 11:49:12 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 iRPKwrwbgdU3 for ; Mon, 22 Oct 2018 11:49:10 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3941128CB7 for ; Mon, 22 Oct 2018 11:49:09 -0700 (PDT) Received: from Jude (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 22 Oct 2018 11:44:21 -0700 From: Jim Schaad To: References: <154023232135.6914.15880413602580970925.idtracker@ietfa.amsl.com> In-Reply-To: <154023232135.6914.15880413602580970925.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2018 11:49:01 -0700 Message-ID: <028201d46a37$e7a7daf0$b6f790d0$@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: AQNukA3iva4B8Xm+9oNMU+fr5z53zqH3Tw5A Content-Language: en-us X-Originating-IP: [192.168.1.162] Archived-At: Subject: [Ace] FW: New Version Notification for draft-schaad-cnf-cwt-id-00.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, 22 Oct 2018 18:49:12 -0000 I did not like the idea of using key identifiers when linking together = CWTs for authorization purposes. As part of that discussion I came up = with the idea of using the CWT identifier instead since that is going to = be specific to an AS. This draft is a brief description of the idea and = I would like to know how interested people would be in getting it = finished. Jim -----Original Message----- From: internet-drafts@ietf.org =20 Sent: Monday, October 22, 2018 11:19 AM To: Jim Schaad Subject: New Version Notification for draft-schaad-cnf-cwt-id-00.txt A new version of I-D, draft-schaad-cnf-cwt-id-00.txt has been = successfully submitted by Jim Schaad and posted to the IETF repository. Name: draft-schaad-cnf-cwt-id Revision: 00 Title: Use of a CWT identifier as a Confirmation Method Document date: 2018-10-22 Group: Individual Submission Pages: 6 URL: = https://www.ietf.org/internet-drafts/draft-schaad-cnf-cwt-id-00.txt Status: = https://datatracker.ietf.org/doc/draft-schaad-cnf-cwt-id/ Htmlized: https://tools.ietf.org/html/draft-schaad-cnf-cwt-id-00 Htmlized: = https://datatracker.ietf.org/doc/html/draft-schaad-cnf-cwt-id Abstract: TBD = =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. The IETF Secretariat From nobody Mon Oct 22 12:09:25 2018 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 EE06A1277C8; Mon, 22 Oct 2018 12:09:23 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 NSwBoUHDdNiv; Mon, 22 Oct 2018 12:09:22 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA4341294D7; Mon, 22 Oct 2018 12:09:21 -0700 (PDT) Received: from Jude (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 22 Oct 2018 12:04:13 -0700 From: Jim Schaad To: CC: References: <065a01d45f4e$b738ae60$25aa0b20$@augustcellars.com> In-Reply-To: <065a01d45f4e$b738ae60$25aa0b20$@augustcellars.com> Date: Mon, 22 Oct 2018 12:08:53 -0700 Message-ID: <028c01d46a3a$ae1b9e40$0a52dac0$@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: AQIoMJGW0ffnzj4eMWBhJ41cSURLyKSBBagw Content-Language: en-us X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [Ace] WGLC for draft-ietf-ace-oscore-profile 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, 22 Oct 2018 19:09:25 -0000 * Section 1 - I understand the reasoning behind having the server send back a nonce, although it would be good to have a description someplace about why this is being done. (I would also make it optional as not all RS need to do this.) I do not understand the reasoning behind having the client send a nonce to the server. * Section 3.1 - This is more general than the section, but you should not use the URI path in the text, instead you should be using the name that is in the authz document. * Section 3.2 - Does it really make sense to use 'COSE_Key' to transport the key data? Would a different field name be better? * Section 3.2 - Please provide a justification for the requirement that the ids must be unique over the set of all clients and RS. I can see that the client ids need to be unique on a single RS and RS ids need to be unique for any given client but not the broader statement. * Please add an explicit section on when a RS and a client should discard the security context. * Section 6 - Ok I'll bite - how does not echoing the nonce allow for a man-in-the-middle attack given that the salt and shared secret are still going to be known only to the C and RS and not to the MITM. I can see a DOS attack being made, but that can be done even without this just by causing the response to never be delivered. * Appendix - I am not sure that I think that the EDHOC profile should be in this document as oppose to being in it's own document. The fact that we have not even tried to get this to work in any of the interop tests means that I am less sure that it is well baked. Jim > -----Original Message----- > From: Ace On Behalf Of Jim Schaad > Sent: Monday, October 8, 2018 2:35 PM > To: ace@ietf.org > Subject: [Ace] WGLC for draft-ietf-ace-oscore-profile > > The chairs believe that the set of documents dealing with the OAuth > framework for constrained environments is nearing the point that we should > be able to advance it to the IESG for publication. We therefore want to > have a full list of issues that need to be dealt with at the Bangkok > meeting. > > This starts a 2 week WGLC for draft-ietf-ace-oscore-profile > > We know that the following issues are outstanding: > > draft-ietf-ace-oscore-profile: > * No current known issues > > > Jim & Roman > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Mon Oct 22 12:09:38 2018 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 97A97130E6B; Mon, 22 Oct 2018 12:09:30 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Mg6GfeE3x7L5; Mon, 22 Oct 2018 12:09:28 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F22421277C8; Mon, 22 Oct 2018 12:09:24 -0700 (PDT) Received: from Jude (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 22 Oct 2018 12:04:37 -0700 From: Jim Schaad To: CC: References: <065b01d45f4e$b8d372a0$2a7a57e0$@augustcellars.com> In-Reply-To: <065b01d45f4e$b8d372a0$2a7a57e0$@augustcellars.com> Date: Mon, 22 Oct 2018 12:09:19 -0700 Message-ID: <028d01d46a3a$bc6414f0$352c3ed0$@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: AQJ+t/TOEyNDXiHpy0JlO2vTIlTnzKPBWyBw Content-Language: en-us X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [Ace] WGLC for draft-ietf-ace-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 19:09:37 -0000 * Section 3.1 - Refresh Token - I don't think that refresh tokens are going to be strings because binary is more efficient. * Section 3.2 - we need to reference TLS 1.3 even if DTLS 1.3 is not yet available. * Description for Figure 6 - Should the example somehow indicate in the message that it is going to be an application/ace+cbor content. Also, I don't know that this is a good example in some ways because this is not a currently documented profile anywhere. * Section 5.6.3 - Should the content type for an error response be application/ace+cbor ? * Section 5.7.1 - Is the content format for a request application/ace+cbor? I assume it is but that is not documented in this section. Section 5.8 - bytes arrays or byte strings? I think CBOR uses the latter * Section 5.8.1 - What is the purpose of creating an identifier for a token? Is this supposed to be used rather than the one from the AS for something like shared secret TLS? Note that this is an unprotected value. * Section 5.8.1 - Given the change in the OSCORE profile, you might want to make this an application/ace+cbor structure as well. * Section 5.8.1 - If the token is "not valid" is the RS required (i.e. MUST) to try introspection before returning a response if the RS does introspection? The text currently says MAY. If this is really MAY then the text should say that the token is always successfully accepted by the RS. * Section 5.8.2 - If the RS is going to do introspection, can it send some type of "Server Busy - try again in xxx" while it does the introspection rather than just doing an ack of the request and possibly waiting a long time? * Section 5.8.3 - third point - I think that the correct text would be "The method does not provide timely expiration, but it makes sure that older tokens will cease to be valid after newer issued tokens are registered with the RS." My problem is that just issuing tokens is not enough as they may be going to a different RS for use. This may also need to have some type of rate limit to issued tokens or making the sequence number be on an RS/audience basis. * Section 6. - The recommendation not to use a shared secret for an audience which is hosted by multiple servers is interesting. This does require that a multiple recipient COSE structure be used and it may be worth calling that out. Also the size of the CWT is going to grow for that. You are also now losing the low-level authentication and thus a signature wrapping is now also needed. * Section 6 - "Developers MUST" para - May want to add that this can also be mitigated to some extent by making sure that keys roll over more frequently. * Section 6 - I am not sure that I agree with the SHOULD NOT in the last paragraph. Think multicast. * Section 6.4 - This also applies to sending back some type of identifier from the RS->C when a token is registered. * Section 8.6.1 - Is pop still this document or is it Mike's document? * Section 8.9 - The description of reference is wrong. * Section 8.12 - some of these should move to the OAuth parameters document? * Section 8.13 - ditto * Appendix A - para "CBOR, COSE, CWT" - Is it really a requirement to use CBOR or is that a recommended? I thought this was part of what Hannes was looking at. * Appendix A - para Client Credentials Grant s/can the/can then/ * Registries - I am wondering if we should think about re-writing a couple of the registries. As things stand it appears that the application/ace+cbor content type is being used in 5 or 6 places. It might make more sense to have a registry for all of the CBOR abbreviations that are being used in a single table and have multiple columns for each of the different places were the content format is being used. This would make it easier to keep everything constant and can make re-use of integer values easier to see. * Comments on protection of CWT/Token: I am wondering if there needs to be any comments on how a CWT is going to be protected. While it is ok to use either a symmetric key or a direct key agreement operation for a single recipient without forcing a signature operation to occur. If the token is going to be targeted a single audience hosted on multiple RSs then a signature operation would be required for the purposes of authentication. * I am not sure where this issue should be raised so I am putting it here. Both of the profiles have as their last security consideration a statement that the use of multiple access tokens is a bad idea. Both of them also devote a large section of text to how to deal with multiple access tokens as does this document. More methods of having multiple access tokens seem to be coming down the path from the OAuth group. This appears to be a distinct contradiction within the set of documents that should be resolved. Jim From nobody Mon Oct 22 12:09:52 2018 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 C24E5130E4B for ; Mon, 22 Oct 2018 12:09:35 -0700 (PDT) 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] 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 oJG1cNgPwPat for ; Mon, 22 Oct 2018 12:09:34 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FC7B130E5E for ; Mon, 22 Oct 2018 12:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w9MJ9GU7016276; Mon, 22 Oct 2018 21:09:21 +0200 (CEST) Received: from [192.168.217.114] (p54A6CA9F.dip0.t-ipconnect.de [84.166.202.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 42f5fg5fX7z1Bqf; Mon, 22 Oct 2018 21:09:15 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <028201d46a37$e7a7daf0$b6f790d0$@augustcellars.com> Date: Mon, 22 Oct 2018 21:09:14 +0200 Cc: ace@ietf.org X-Mao-Original-Outgoing-Id: 561928153.187759-8a958757b32b3b37a940224b95797060 Content-Transfer-Encoding: quoted-printable Message-Id: References: <154023232135.6914.15880413602580970925.idtracker@ietfa.amsl.com> <028201d46a37$e7a7daf0$b6f790d0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Ace] FW: New Version Notification for draft-schaad-cnf-cwt-id-00.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, 22 Oct 2018 19:09:38 -0000 On Oct 22, 2018, at 20:49, Jim Schaad wrote: >=20 > I did not like the idea of using key identifiers when linking together = CWTs for authorization purposes. =20 Right, they are not very useful as they don=E2=80=99t say anything about = the authorization information that is attached to that key in a specific = CWT. > As part of that discussion I came up with the idea of using the CWT = identifier instead since that is going to be specific to an AS. =20 Sounds better. I would feel even better if I knew what exactly that = scope =E2=80=9Can AS=E2=80=9D is (it is not represented in the CWT, so = there is some misuse potential). > This draft is a brief description of the idea and I would like to know = how interested people would be in getting it finished. Will read it after the frenzy=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Oct 22 12:10:40 2018 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 4261A1294D7; Mon, 22 Oct 2018 12:10:38 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 2-JlRAJXxlGQ; Mon, 22 Oct 2018 12:10:37 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC03C128B14; Mon, 22 Oct 2018 12:10:33 -0700 (PDT) Received: from Jude (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 22 Oct 2018 12:04:43 -0700 From: Jim Schaad To: , References: <065d01d45f4e$bc227690$346763b0$@augustcellars.com> In-Reply-To: <065d01d45f4e$bc227690$346763b0$@augustcellars.com> Date: Mon, 22 Oct 2018 12:09:25 -0700 Message-ID: <028f01d46a3a$c04bfd80$40e3f880$@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: AQKvzUUhmh2spFwNttxau3uvFoFXr6NfFulA Content-Language: en-us X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [Ace] WGLC for 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: Mon, 22 Oct 2018 19:10:39 -0000 Here are my WGLC comments: * I am not sure that I understand what the protocol flow is when JAR is being used. Is there a potential case where a JWT would be used as the structure of an OAuth response? If so then is there a problem with defining cnf in section 4.1? * We need to have a OAuth CBOR integer mapping registry - the items in section 6 need to be registered into that registry. * Review - is the 'cnf' parameter in section 3.2 ok with the OAuth group or does it need to be renamed as well? * Check that cnf in 4.1 is going to be ok with draft-ietf-oauth-jwt-introspection-response Jim From nobody Mon Oct 22 12:36:14 2018 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 9F9B8130E94 for ; Mon, 22 Oct 2018 12:36:03 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 8g1qURWV9dH6 for ; Mon, 22 Oct 2018 12:36:00 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9FD4130EAB for ; Mon, 22 Oct 2018 12:35:59 -0700 (PDT) Received: from Jude (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 22 Oct 2018 12:31:11 -0700 From: Jim Schaad To: References: In-Reply-To: Date: Mon, 22 Oct 2018 12:35:52 -0700 Message-ID: <029e01d46a3e$72bad330$58307990$@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: AdRnTEAL0JSHf2QBS9irbfSoo+ynjwC8isgg Content-Language: en-us X-Originating-IP: [192.168.1.162] Archived-At: Subject: [Ace] FW: WGLC comments on draft-ietf-ace-dtls-authorize 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, 22 Oct 2018 19:36:11 -0000 This was cc-ed to the wrong list -----Original Message----- From: Jim Schaad Sent: Monday, October 22, 2018 12:09 PM To: 'draft-ietf-ace-dtls-authorize@ietf.org' Cc: 'core@ietf.org' Subject: WGLC comments on draft-ietf-ace-dtls-authorize Section 3 - Am I just missing where you talk about introspection or is it missing from the text? Section 3.2 - looks like you missed a "cnf" in the first paragraph - should be req_cnf Section 3.3 - Figure 4 - Where is the 'alg' parameter defined at that level? Section 3.3 - I am always bothered by the fact that PSK should really be PSS at this point. The secret value is no longer a key and thus does not necessarily have a length. There is also a problem of trying to decide what the length of this value would be based on the algorithm. If the client offers TLS_PSK_WITH_AES_128_CCM_8 and TLS_PSK_WITH_AES_256_CCM_8 (I may have gotten these wrong but the intent should be understandable) then what length is the PSK supposed to be? Section 3.3 - Figure 5 - Is this defining a new set of entries for cnf or is there a missing layer someplace? Section 3.3 - Should some type of key identifier also be defined so that the entire token is not always sent on every DTLS setup? Also so that the key can be referenced on a second request to the AS. Section 3.4 - Is it worth while to make it explicit when the DTLS session is required to be shutdown and that a simple authorization error is not one of them? Looks like it should be - these errors SHOULD NOT cause the DTLS connection to be closed. Section 4 - The requirement that the "kid" be in a previously issued token would have problems with this if you were to use the "kid" of an RPK which can be constant rather than being changed on each newly created token. Section 4 - The term "must associate" is slightly ambiguous - does this mean add to (augment) or replace the previous token. Section 4 - Should a secondary access token have a later expiration date that the one that contains the actual key value? Section 5 - this seems to be a very strange place to define the new parameter. Section 8 - you need to put your kid in the IANA considerations as well Section 9.1 - Having tilicoa-tls-dos-handshake as a normative reference may cause problems unless this is on a publication track. Section 9.3 - Can we get these URLs converted over to normal references? Jim From nobody Mon Oct 22 14:00:02 2018 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 92C0D1292AD for ; Mon, 22 Oct 2018 13:59:59 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 2MjwTSfFO47g for ; Mon, 22 Oct 2018 13:59:57 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8620A128CB7 for ; Mon, 22 Oct 2018 13:59:56 -0700 (PDT) Received: from Jude (50.39.87.30) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 22 Oct 2018 13:55:07 -0700 From: Jim Schaad To: 'Ludwig Seitz' , References: <4519f58c-c6f7-5ac0-003c-7ae4f59bccd4@tzi.de> <43b3b90f-996a-8b8a-2439-e3d6adcc3b0f@ri.se> In-Reply-To: <43b3b90f-996a-8b8a-2439-e3d6adcc3b0f@ri.se> Date: Mon, 22 Oct 2018 13:59:47 -0700 Message-ID: <02af01d46a4a$2c629790$8527c6b0$@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: AQJDl5Bm99e9zGnxaPJuM5ZpOzU3eQGM5yWFpED2GxA= Content-Language: en-us X-Originating-IP: [50.39.87.30] Archived-At: Subject: Re: [Ace] ACE Framework Review 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, 22 Oct 2018 21:00:00 -0000 > -----Original Message----- > From: Ace On Behalf Of Ludwig Seitz > Sent: Monday, October 22, 2018 6:08 AM > To: ace@ietf.org > Subject: Re: [Ace] ACE Framework Review > > On 10/10/2018 16:24, Stefanie Gerdes wrote: > > Hi, > > > > I looked through the ACE framework document. I think there are some > > open issues that need to be addressed. I will try to summarize the > > main issues below. We provided a rough analysis of the DTLS profile in > > [1], which may also be interesting (many of the issues mentioned there > > were already fixed in the meantime). > > Thank you for your review. Sorry for the long response time. Answers inline. I > also tried to add issues in the issue tracker, but github seems to be > experiencing trouble at the moment. > > /Ludwig > > > Validity of the access token (Token Expiration, Section 5.8.3): There > > seem to be additional requirements here that are currently not > > mentioned. It is not clear how RS determines the freshness of > > introspection messages (and how fresh they are). > > That would be up to the commSec protocol, also it is covered in the security > considerations of RFC 7662. I will add a reference to those considerations in > our security considerations section. This seems to be a bit of an odd requirement to impose on the protocol and not on the RS. The RS should have some type of idea of when it last asked the AS if it was valid and also some idea of when the AS said this was going to expire relative to when it last asked. If the RS asks twice and the AS returns a cached answer that is on the AS and not on the RS. An RS with no sense of time could still implement a counter and ask the AS every nth access to the resource (potentially spreading that over all accesses by anybody). > > > The sequence number approach has the problem that an attacker may > > withhold new tokens from RS. In this case, old tokens are infinitely > > valid. This is particularly damaging because C may have a strong > > interest to withhold new tokens and can easily do so by not relaying > > them to RS. This approach therefore must not be used unless there is > > an additional communication channel between RS and AS that regularly > > informs RS which the most recent sequence number is. > > > This is a best effort approach when the RS has no internal sense of time. Also > the idea was that several client could submit tokens with an ever increasing > unique serial number maintained by the AS. Thus even if one client would > withhold it's newer tokens to keep the old ones from expiring, the other > clients would eventually submit enough new tokens (with higher sequence > numbers) so that the token expires. > > AFAIK the RS with no internal clock at all is a very rare occurrence, thus you > can usually expect some form of wallclock time, and thus implement an > expiration based on "time-since-you-received-this-token". Additionally one could use the clear everything after n accesses to resources. > > Management of the authz-info resource: > > * The authz-info resource is vulnerable to DoS attacks: clients may > > (with or without intention) send large numbers of access tokens to RS. A > > constrained RS may soon run out of memory/storage space if it needs to > > store large numbers of tokens. > > A RS is not expected to store large numbers of tokens. Section 5.8.1 > specifies: > > "The RS MUST be prepared to store at least one access token for future > use." > > Thus the RS can adapt the number of tokens it stores to its constrained > storage resources. This might be a good place to reference the new core draft - too many requests - as a reasonable response for an overloaded server in this case. > > The preferred mitigation should be that the > > authz-info resource is only used for protected communication. This does > > obviously not work for the RPK mode. In the PSK mode, RS should be able > > to decide that it uses the authz-info resource only for protected updates. > > I don't think that will help, since somehow the initial access token > must get to the RS. So even when passing it through the DTLS handshake > (as with PSK in the DTLS profile) the same DoS risk exists. Going the DTLS handshake route might actually make things worse as you are now doing lots of additional process on the server side since you have added all of the DTLS work to the token validation work. > > Validity of the access information: > > It seems that the people who wrote the framework did not consider that > > the keying material is not only provided to RS but also to C. > > How does C determine if the keying material it receives from AS is still > > valid? > > It is valid as long as you don't get a 4.01 (Unauthorized) from the RS. > > > The access token response may comprise an expires_in > > field that contains the validity period of the access token in seconds > > (RFC 6749), but does not specify the validity period of the keying > > material. But even if the validity periods are equal, C does not know > > when the access token was generated. Also, the use of the expires_in > > field is optional. Without protection, the access information is > > infinitely valid. C may use outdated and maybe compromised keying > > material to communicate with RS. The framework should provide > > information how C determines if the keying material is still valid. > > Also, C must check if the keying material it has for a communication > > partner is still valid before sending a request. > > > > I would think that in most cases it is acceptable that the client just > optimistically sends its request with the existing keying material and > renews it if it gets back a 4.01. > > Use cases where the security policy is such that this is unacceptable > should use a specific profile that defines additional mechanisms for the > client to check its tokens and associated keying material (e.g. by using > client introspection). I think that the use of the expires_in field in an AS response should cover this case sufficiently well for most cases where the client might care. I would agree that the failure of a request is a good clue that a new token needs to be obtained. I am not sure that it makes any sense to say that keying material has expired for the RPK case. It only makes sense to have key lifetime for a POP symmetric token. In that case I would expect that the lifetime of the token and the key material to be the same. I would not think that a new token with expanded privileges on the same key material should last beyond the original POP token. This does mean that there will need to be a more frequent DTLS negotiation but that is not difficult for a simple PSK with no asymmetric key. > > It is not clear how C makes plain to AS with which RS it wants to > > communicate. C may specify the intended audience in the token request > > using the req_aud parameter. How is RS represented in this case? > > C and AS must have a common understanding how RS is identified, > > otherwise C may communicate with the wrong RS! > > IP addresses may change and therefore are not suitable. If AS specifies > > identifiers for RS, C must securely obtain this knowledge. > > Identifying the RS (using the audience claim and the req_aud parameter) > is application specific. Some applications may want to use public keys, > others will want to use fixed identifiers that are manually assigned or > otherwise generated. > > The framework does not suggest IP addresses as a way to identify an RS. There are two cases here that need to be thought about. The first is that the audience and the RS are synonymous. In that case there is not a problem here. The second case is an audience that exists on multiple servers. The question then is should the token be setup for a single RS or for every RS that hosts the audience? I would expect it to be the latter as one could get a redirect at some point from RS1 to RS2 but it should not require that a new token be obtained just that it be re-posted. The question you ask would only be if interest if one said that multiple RSs hosted a single audience and they all had to be keyed separately. Jim > > /Ludwig > > > -- > Ludwig Seitz, PhD > Security Lab, RISE > Phone +46(0)70-349 92 51 > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Mon Oct 22 14:00:17 2018 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 CFB2D130E3F for ; Mon, 22 Oct 2018 14:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xHMGRBplS8L for ; Mon, 22 Oct 2018 14:00:07 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 DD7EA130E74 for ; Mon, 22 Oct 2018 14:00:06 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w9ML05J7024062 for ; Mon, 22 Oct 2018 17:00:05 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu w9ML05J7024062 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1540242005; bh=DrZz7bcZhv9ihuF6wpCC7tuZ1UJU45ObLu81WfzZ4U0=; h=From:To:Subject:Date:From; b=mZYeUg43sRU3pWtdORgPoaMIUNKIzBb/yvKOIHe0Kb4MrYDz5dMA8ukG0FfDtH9TA 2KNCLr1WePwXPEUh6jiM12wrodhRY5AiZpvCpcwLsmNQR/Sfw6mgHLpFsr6wExWf+v qta4de5g+ARHFKK18lg9Gf0fE0l9qzmeweArudv4= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w9ML05Nb029967 for ; Mon, 22 Oct 2018 17:00:05 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0399.000; Mon, 22 Oct 2018 17:00:04 -0400 From: Roman Danyliw To: "ace@ietf.org" Thread-Topic: WGLC Reminder on draft-ietf-ace-{oauth-params, dtls-authorize, authz, oscore-profile} Thread-Index: AdRqRCD2BIbTodxqR42V4LgxBBbx5A== Date: Mon, 22 Oct 2018 21:00:04 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0181A193FF@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Ace] WGLC Reminder on draft-ietf-ace-{oauth-params, dtls-authorize, authz, oscore-profile} 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, 22 Oct 2018 21:00:15 -0000 Hello WG! On October 8, a WGLC was started on these four drafts to identify issues in= advance of the Bangkok meeting: draft-ietf-ace-oauth-params https://www.ietf.org/mail-archive/web/ace/current/msg02994.html draft-ietf-ace-dtls-authorize https://www.ietf.org/mail-archive/web/ace/current/msg02993.html draft-ietf-ace-authz https://www.ietf.org/mail-archive/web/ace/current/msg02992.html draft-ietf-ace-oscore-profile https://www.ietf.org/mail-archive/web/ace/current/msg02991.html There has been limited feedback to date. Additional review would be helpfu= l to assess the readiness of the drafts. Please send any comments to the l= ist. Regards, Roman and Jim=20 From nobody Mon Oct 22 14:02:31 2018 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 8142112DD85 for ; Mon, 22 Oct 2018 14:02:23 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 up4p3yh_V-ot for ; Mon, 22 Oct 2018 14:02:22 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 831E6130E85 for ; Mon, 22 Oct 2018 14:02:21 -0700 (PDT) Received: from Jude (50.39.87.30) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 22 Oct 2018 13:57:34 -0700 From: Jim Schaad To: 'Carsten Bormann' CC: References: <154023232135.6914.15880413602580970925.idtracker@ietfa.amsl.com> <028201d46a37$e7a7daf0$b6f790d0$@augustcellars.com> In-Reply-To: Date: Mon, 22 Oct 2018 14:02:14 -0700 Message-ID: <02b201d46a4a$83c95140$8b5bf3c0$@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: AQNukA3iva4B8Xm+9oNMU+fr5z53zgMc7e/VAnQxvUOhyuvNIA== Content-Language: en-us X-Originating-IP: [50.39.87.30] Archived-At: Subject: Re: [Ace] FW: New Version Notification for draft-schaad-cnf-cwt-id-00.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, 22 Oct 2018 21:02:30 -0000 > -----Original Message----- > From: Carsten Bormann > Sent: Monday, October 22, 2018 12:09 PM > To: Jim Schaad > Cc: ace@ietf.org > Subject: Re: [Ace] FW: New Version Notification for = draft-schaad-cnf-cwt-id- > 00.txt >=20 > On Oct 22, 2018, at 20:49, Jim Schaad wrote: > > > > I did not like the idea of using key identifiers when linking = together CWTs > for authorization purposes. >=20 > Right, they are not very useful as they don=E2=80=99t say anything = about the > authorization information that is attached to that key in a specific = CWT. >=20 > > As part of that discussion I came up with the idea of using the CWT > identifier instead since that is going to be specific to an AS. >=20 > Sounds better. I would feel even better if I knew what exactly that = scope =E2=80=9Can > AS=E2=80=9D is (it is not represented in the CWT, so there is some = misuse potential) Actually this can be placed in a CWT as the issuer field. Jim . >=20 > > This draft is a brief description of the idea and I would like to = know how > interested people would be in getting it finished. >=20 > Will read it after the frenzy=E2=80=A6 >=20 > Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Oct 23 00:50:06 2018 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 121AB130EBC; Tue, 23 Oct 2018 00:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 ML7aYqEGxrn2; Tue, 23 Oct 2018 00:50:02 -0700 (PDT) Received: from smtp-out10.electric.net (smtp-out10.electric.net [185.38.180.33]) (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 8E4D5130DDB; Tue, 23 Oct 2018 00:50:01 -0700 (PDT) Received: from 1gErRv-000jli-TH by out10d.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1gErRv-000jml-V7; Tue, 23 Oct 2018 00:49:59 -0700 Received: by emcmailer; Tue, 23 Oct 2018 00:49:59 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out10d.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1gErRv-000jli-TH; Tue, 23 Oct 2018 00:49:59 -0700 Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Tue, 23 Oct 2018 09:49:58 +0200 To: Jim Schaad , , References: <065d01d45f4e$bc227690$346763b0$@augustcellars.com> <028f01d46a3a$c04bfd80$40e3f880$@augustcellars.com> From: Ludwig Seitz Message-ID: Date: Tue, 23 Oct 2018 09:49:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <028f01d46a3a$c04bfd80$40e3f880$@augustcellars.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-1.sp.se (10.100.0.161) To sp-mail-2.sp.se (10.100.0.162) X-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) X-PolicySMART: 14510320 Archived-At: Subject: Re: [Ace] WGLC for 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, 23 Oct 2018 07:50:05 -0000 On 22/10/2018 21:09, Jim Schaad wrote: > Here are my WGLC comments: > > * I am not sure that I understand what the protocol flow is when JAR is > being used. Is there a potential case where a JWT would be used as the > structure of an OAuth response? If so then is there a problem with defining > cnf in section 4.1? I wouldn't think so, all the other possible parameters in the introspection response are defined to be the claims of the token in RFC 7662, cnf is a claim of the token, so I don't see why it shouldn't go unchanged into the introspection response. > > * We need to have a OAuth CBOR integer mapping registry - the items in > section 6 need to be registered into that registry. That was an oversight. Issue created. > > * Review - is the 'cnf' parameter in section 3.2 ok with the OAuth group or > does it need to be renamed as well? > I don't see how this could collide with another meaning. The AS is responding with the token and additional information about the token here. This parameter was called 'key' in draft-ietf-oauth-pop-key-distribution, which felt more phrone to misunderstandings to me ("what key?"). > * Check that cnf in 4.1 is going to be ok with > draft-ietf-oauth-jwt-introspection-response > If I understood it correctly draft only proposes to replace the whole introspection response with a JWT. I don't see why this shouldn't work with a CWT as well. No additional data but the JWT/CWT would be sent in the introspection response, so there should not be any issue with the cnf claim here. -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 From nobody Tue Oct 23 07:43:31 2018 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 313BA128DFD; Tue, 23 Oct 2018 07:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 dWJ1-rNvxmdJ; Tue, 23 Oct 2018 07:43:26 -0700 (PDT) Received: from smtp-out10.electric.net (smtp-out10.electric.net [185.38.180.41]) (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 8080F128BCC; Tue, 23 Oct 2018 07:43:26 -0700 (PDT) Received: from 1gExtz-000Pba-UR by out10a.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1gExtz-000Pd5-Vz; Tue, 23 Oct 2018 07:43:23 -0700 Received: by emcmailer; Tue, 23 Oct 2018 07:43:23 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out10a.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1gExtz-000Pba-UR; Tue, 23 Oct 2018 07:43:23 -0700 Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Tue, 23 Oct 2018 16:43:23 +0200 From: Ludwig Seitz To: Jim Schaad , CC: References: <065b01d45f4e$b8d372a0$2a7a57e0$@augustcellars.com> <028d01d46a3a$bc6414f0$352c3ed0$@augustcellars.com> Message-ID: Date: Tue, 23 Oct 2018 16:43:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <028d01d46a3a$bc6414f0$352c3ed0$@augustcellars.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) X-PolicySMART: 14510320 Archived-At: Subject: Re: [Ace] WGLC for draft-ietf-ace-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 14:43:30 -0000 Hallo Jim, thank you for the review! Comments inline. /Ludwig On 22/10/2018 21:09, Jim Schaad wrote: > * Section 3.1 - Refresh Token - I don't think that refresh tokens are going > to be strings because binary is more efficient. This refers to the way it is defined in OAuth. I'll add a word to clarify. > > * Section 3.2 - we need to reference TLS 1.3 even if DTLS 1.3 is not yet > available. > Agree. > * Description for Figure 6 - Should the example somehow indicate in the > message that it is going to be an application/ace+cbor content. Also, I > don't know that this is a good example in some ways because this is not a > currently documented profile anywhere. True. I'll change this to OSCORE. > > * Section 5.6.3 - Should the content type for an error response be > application/ace+cbor ? That makes sense. I'll add a sentence to that effect. > > * Section 5.7.1 - Is the content format for a request application/ace+cbor? > I assume it is but that is not documented in this section.I'll add that. > > Section 5.8 - bytes arrays or byte strings? I think CBOR uses the latter Right that slipped through. I'll replace it. > > * Section 5.8.1 - What is the purpose of creating an identifier for a token? > Is this supposed to be used rather than the one from the AS for something > like shared secret TLS? Note that this is an unprotected value. > AFAIK cti is not a mandatory claim of an access token, thus a RS might want to create an identifier for tokens that do not have a cti. > * Section 5.8.1 - Given the change in the OSCORE profile, you might want to > make this an application/ace+cbor structure as well. Right > > * Section 5.8.1 - If the token is "not valid" is the RS required (i.e. MUST) > to try introspection before returning a response if the RS does > introspection? The text currently says MAY. If this is really MAY then the > text should say that the token is always successfully accepted by the RS. > I'm not sure I understand the issue. Introspection is optional in general, and may be required in specific use cases. If the RS determines that the token is not valid on its own, why would it want to do introspection on top of this? > * Section 5.8.2 - If the RS is going to do introspection, can it send some > type of "Server Busy - try again in xxx" while it does the introspection > rather than just doing an ack of the request and possibly waiting a long > time? This is probably transport protocol specific, and we were asked not to link the framework to a specific protocol, thus I don't know if we can provide guidance here. > > * Section 5.8.3 - third point - I think that the correct text would be "The > method does not provide timely expiration, but it makes sure that older > tokens will cease to be valid after newer issued tokens are registered with > the RS." My problem is that just issuing tokens is not enough as they may > be going to a different RS for use. This may also need to have some type of > rate limit to issued tokens or making the sequence number be on an > RS/audience basis. I think the sentence here: "The AS increments this number for each access token it issues" needs to be ammended to "... for each access token it issues for this RS". > > * Section 6. - The recommendation not to use a shared secret for an audience > which is hosted by multiple servers is interesting. This does require that > a multiple recipient COSE structure be used and it may be worth calling that > out. Also the size of the CWT is going to grow for that. You are also now > losing the low-level authentication and thus a signature wrapping is now > also needed. > Right, I'll extend the paragraph to add this information. > * Section 6 - "Developers MUST" para - May want to add that this can also be > mitigated to some extent by making sure that keys roll over more frequently. > Ok > * Section 6 - I am not sure that I agree with the SHOULD NOT in the last > paragraph. Think multicast. Any suggestions on how to mitigate the issue then? If I issue a token bound to a symmetric key for audience {R1, R2, R3}, as soon as R1 got this token it can impersonate the client and gain access to R2 and R3. > > * Section 6.4 - This also applies to sending back some type of identifier > from the RS->C when a token is registered. > That is correct, however the token identifier should be just as opaque to attackers as the token itself. > * Section 8.6.1 - Is pop still this document or is it Mike's document? The token type pop is currently not part of draft-ietf-ace-cwt-proof-of-possession. I wouldn't argue against putting it there. > > * Section 8.9 - The description of reference is wrong. Can you explain how? I'm not seeing the issue (assuming you mean the reference to RFC8126). > > * Section 8.12 - some of these should move to the OAuth parameters document? > These are new claims. We could move them to the params draft, which would then become the params and claims draft. I have not strong opinion either way. > * Section 8.13 - ditto > > * Appendix A - para "CBOR, COSE, CWT" - Is it really a requirement to use > CBOR or is that a recommended? I thought this was part of what Hannes was > looking at. > Yes that should be RECOMMENED as well. > * Appendix A - para Client Credentials Grant s/can the/can then/ > Ok > * Registries - I am wondering if we should think about re-writing a couple > of the registries. As things stand it appears that the application/ace+cbor > content type is being used in 5 or 6 places. It might make more sense to > have a registry for all of the CBOR abbreviations that are being used in a > single table and have multiple columns for each of the different places were > the content format is being used. This would make it easier to keep > everything constant and can make re-use of integer values easier to see. > > * Comments on protection of CWT/Token: I am wondering if there needs to be > any comments on how a CWT is going to be protected. While it is ok to use > either a symmetric key or a direct key agreement operation for a single > recipient without forcing a signature operation to occur. If the token is > going to be targeted a single audience hosted on multiple RSs then a > signature operation would be required for the purposes of authentication. > > * I am not sure where this issue should be raised so I am putting it here. > Both of the profiles have as their last security consideration a statement > that the use of multiple access tokens is a bad idea. Both of them also > devote a large section of text to how to deal with multiple access tokens as > does this document. More methods of having multiple access tokens seem to > be coming down the path from the OAuth group. This appears to be a distinct > contradiction within the set of documents that should be resolved. > I will get back to those last 3 comments (running out of time). Regards, Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 From nobody Tue Oct 23 11:45:16 2018 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 8F9A8130F06; Tue, 23 Oct 2018 11:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 cS-ToiSAJN93; Tue, 23 Oct 2018 11:45:10 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D75FF130E1D; Tue, 23 Oct 2018 11:45:09 -0700 (PDT) Received: from Jude (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 23 Oct 2018 11:39:59 -0700 From: Jim Schaad To: 'Ludwig Seitz' , CC: References: <065b01d45f4e$b8d372a0$2a7a57e0$@augustcellars.com> <028d01d46a3a$bc6414f0$352c3ed0$@augustcellars.com> In-Reply-To: Date: Tue, 23 Oct 2018 11:44:39 -0700 Message-ID: <038001d46b00$767a8520$636f8f60$@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: AQJ+t/TOEyNDXiHpy0JlO2vTIlTnzAJjpp42AY2H+FqjuQSp8A== Content-Language: en-us X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [Ace] WGLC for draft-ietf-ace-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 18:45:14 -0000 > -----Original Message----- > From: Ludwig Seitz > Sent: Tuesday, October 23, 2018 7:43 AM > To: Jim Schaad ; draft-ietf-ace-oauth- > authz@ietf.org > Cc: ace@ietf.org > Subject: Re: [Ace] WGLC for draft-ietf-ace-authz >=20 > Hallo Jim, >=20 > thank you for the review! Comments inline. >=20 > /Ludwig >=20 > On 22/10/2018 21:09, Jim Schaad wrote: > > * Section 5.8.1 - What is the purpose of creating an identifier for = a token? > > Is this supposed to be used rather than the one from the AS for > > something like shared secret TLS? Note that this is an unprotected = value. > > > AFAIK cti is not a mandatory claim of an access token, thus a RS might = want > to create an identifier for tokens that do not have a cti. Ok - so the client has this cti - what could it use it for? > > * Section 5.8.1 - If the token is "not valid" is the RS required = (i.e. MUST) > > to try introspection before returning a response if the RS does > > introspection? The text currently says MAY. If this is really MAY = then the > > text should say that the token is always successfully accepted by = the RS. > > > I'm not sure I understand the issue. Introspection is optional in > general, and may be required in specific use cases. If the RS = determines > that the token is not valid on its own, why would it want to do > introspection on top of this? The RS has just received a token. The RS wants to validate said token. = It can do it on its own or it can do it with introspection. If it is = going to do it with introspection can it defer this validation until = first use or does it need to do it immediately so it is not going to = store an invalid token? It is possible that an RS is going to both = support some tokens and require introspection on others. In that case = it would decide the token was not valid, but would not necessarily know = if it was a legal introspection token. >=20 >=20 > > * Section 5.8.2 - If the RS is going to do introspection, can it = send some > > type of "Server Busy - try again in xxx" while it does the = introspection > > rather than just doing an ack of the request and possibly waiting a = long > > time? >=20 > This is probably transport protocol specific, and we were asked not to > link the framework to a specific protocol, thus I don't know if we can > provide guidance here. > > * Section 6 - I am not sure that I agree with the SHOULD NOT in the = last > > paragraph. Think multicast. > Any suggestions on how to mitigate the issue then? If I issue a token > bound to a symmetric key for audience {R1, R2, R3}, as soon as R1 got > this token it can impersonate the client and gain access to R2 and R3. I am not sure that I think this is an issue that needs to be mitigated. = It needs to be acknowledged, but the assumption would be that if you = have three resource servers that are hosting the same audience they are = going to be run by the same RO and already be coupled. After all it = should not matter which of them you do a GET from, you should get the = same answer. Similarly a PUT to one should propagate to the others so = that it is available to all clients. >=20 > > * Section 8.6.1 - Is pop still this document or is it Mike's = document? >=20 > The token type pop is currently not part of > draft-ietf-ace-cwt-proof-of-possession. I wouldn't argue against = putting > it there. I would only because it would delay that document. I just could not = remember where if it was there and was too lazy to look. >=20 > > > > * Section 8.9 - The description of reference is wrong. >=20 > Can you explain how? I'm not seeing the issue (assuming you mean the > reference to RFC8126). Reference This contains a pointer to the public specification of the grant type abbreviation, if one exists. This is not about grant types. >=20 > > > > * Section 8.12 - some of these should move to the OAuth parameters > document? > > > These are new claims. We could move them to the params draft, which > would then become the params and claims draft. I have not strong = opinion > either way. I have no opinion either way - was just asking. > > * Registries - I am wondering if we should think about re-writing a = couple > > of the registries. As things stand it appears that the = application/ace+cbor > > content type is being used in 5 or 6 places. It might make more = sense to > > have a registry for all of the CBOR abbreviations that are being = used in a > > single table and have multiple columns for each of the different = places > were > > the content format is being used. This would make it easier to keep > > everything constant and can make re-use of integer values easier to = see. > > > > * Comments on protection of CWT/Token: I am wondering if there = needs > to be > > any comments on how a CWT is going to be protected. While it is ok = to > use > > either a symmetric key or a direct key agreement operation for a = single > > recipient without forcing a signature operation to occur. If the = token is > > going to be targeted a single audience hosted on multiple RSs then a > > signature operation would be required for the purposes of = authentication. > > > > * I am not sure where this issue should be raised so I am putting it = here. > > Both of the profiles have as their last security consideration a = statement > > that the use of multiple access tokens is a bad idea. Both of them = also > > devote a large section of text to how to deal with multiple access = tokens as > > does this document. More methods of having multiple access tokens = seem > to > > be coming down the path from the OAuth group. This appears to be a > distinct > > contradiction within the set of documents that should be resolved. > > > I will get back to those last 3 comments (running out of time). >=20 > Regards, >=20 > Ludwig >=20 >=20 > -- > Ludwig Seitz, PhD > Security Lab, RISE > Phone +46(0)70-349 92 51 From nobody Tue Oct 23 12:09:56 2018 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 BC1FC130F17 for ; Tue, 23 Oct 2018 12:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-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=armh.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 RnuJ6BDacXAA for ; Tue, 23 Oct 2018 12:09:51 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02on0600.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe07::600]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67B99130EEC for ; Tue, 23 Oct 2018 12:09:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=21TXq20PKxSdjRhpF8UIvWA6VmG/B3OOKOr04sR4M8I=; b=HRsB/GP3BszaGm1M3ALVFszgpa0qrv1/62xSkMZ6UgPkiOg6TYg7HKgpkISZd+LI36txiDYE0A69QlG5bZBj6Lr3TDIn0i1oRC4mexcpeRSKsiM7EHMt31L2Km1rKa3k5sO20SjDwdBtyF4nfyn6GfsKzGCnPXHm3do23Zx12jA= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1758.eurprd08.prod.outlook.com (10.168.67.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.29; Tue, 23 Oct 2018 19:09:48 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7165:6199:a54f:510c]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7165:6199:a54f:510c%2]) with mapi id 15.20.1273.014; Tue, 23 Oct 2018 19:09:48 +0000 From: Hannes Tschofenig To: "Ace@ietf.org" Thread-Topic: Review of draft-ietf-ace-oauth-params-00 Thread-Index: AdRrA+0cVyM+dWrcQLCmuAJtHJOHpQ== Date: Tue, 23 Oct 2018 19:09:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [64.71.18.60] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1758; 6:KisEjCg53rjKLT0+Q/n4BumQUfcj0OX5NLS7pjU4sMWXs/QO4HtDstiEAZZeEx/eTcWaYuA1eSImBzCbwBoLNgpeCp+HR7qa4vOrt6OoT80n32Qo+tfkx5hVsQhZVag11RQ+fvswRMWL5fAo689a4EeYqYZfhmrbs3kc3uEDqRxL7yn8HKydl8QoQuAEx1wRo3U3DhuQYr3UIv1iS8YfSb0vgc5hI1x76wO8VRi/+gkaRnMUL6YHFSNN40nlCiiBP7iaeeaElWnpm06FGs6eO8TGKyCa9Sa2vKOtqdp97h3f4Bxbxf29gKaWB6iQrqX7yl1DI+gUOXo9zf+NjyBQ6y6iYTV1bbHXRQKjt4tDqxIIu1WRyYoWoRTCGt9RbKc890lLN24NT/PTqzb9XDTvlUlfLHQsScFaoahpE/V+SFCodsW5kyUCufR7ueWsPXrW0YWfD/syyM0KPBKdTOY8fw==; 5:HG9C+VdHS6SoF3tFectbkXHsf3bW4GvHVaXY4GYnmO4KvmJGeIcjLQGQBrHB5dxt9JIvNA+QB9xpuaANULVey65GhSKKi9KiC3JDa8uIOM8088q+Lj6zdJMI5Y7gJlmV48AXsdaXYrSWTi0gX2r2qMTUpNcU70kjid914zlkbZg=; 7:Do6CHXLBtQldVENR/7GcTU1BzuEnAgTfkeckj683RtWTQBEBVgogkBDv65U6WBc06BRSlpdbqJNTU+QEdlxnrbLYy/TANmMPVGQ+iY7iuYdpJBPH63VZLsatBboq6EVCnNRDWmWp+GPjjyLFm6/229rx6n9qDKmNV8lubcdM0TrJzV+MEvJYXgCF+FPtMFLyDkYIU3/n3ki6kNjCQts7aOmpdvivj/oBiH7+7FY58EoesGmD1BPUZL5TmOqXSK0C x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: c08c84f1-842a-4ea2-e0e8-08d6391b1a5a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1758; x-ms-traffictypediagnostic: VI1PR0801MB1758: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155)(28532068793085)(190501279198761)(227612066756510); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231355)(944501410)(4982022)(52105095)(3002001)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:VI1PR0801MB1758; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1758; x-forefront-prvs: 0834BAF534 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(136003)(366004)(346002)(376002)(40434004)(199004)(189003)(53754006)(102836004)(5630700001)(9686003)(26005)(2906002)(6306002)(54896002)(68736007)(105586002)(6506007)(5660300001)(72206003)(6436002)(25786009)(5640700003)(33656002)(2900100001)(53936002)(478600001)(97736004)(2351001)(14454004)(966005)(2501003)(5250100002)(66066001)(71200400001)(71190400001)(486006)(3846002)(790700001)(7696005)(55016002)(6116002)(8936002)(86362001)(81156014)(476003)(6916009)(81166006)(8676002)(14444005)(99286004)(256004)(74316002)(186003)(7736002)(316002)(5024004)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1758; H:VI1PR0801MB2112.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-microsoft-antispam-message-info: x9i7uA1zoZ648d3zgtNcyev1qZjX2GlE7wxFAcyAO9r8eIlZF8ou2ndKF+fhJ6HHUjkaw+7qlL1u4rbpT3HjFFR+1/fqZ5tyQxRn0pPUj3z9Y60t3kT1RZutAAmhWweWcGvWWpHhHMyfjCJmMOfDvewSNrqwXiCePw+GgYqnEB9kT8g/mXGfBrAnvECoykrZcc98+MH0N1UiIgKvQS1wMdGEO5Tnxo4oMtkyHnPJX3RXWTKOQtafm+uoH6MExGabUwopIdOvJ8Pn16L6WNL33cv33IZoeT3XGP2IBFLvhmhFz+2W/hCg+sTWsmvwyl9/22wlrvj2CHBS6WhAuXm/2MooJ42pXuQOM1g0uNnT5MY= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB2112DD9ECD09B98C5060D868FAF50VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: c08c84f1-842a-4ea2-e0e8-08d6391b1a5a X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2018 19:09:48.7786 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1758 Archived-At: Subject: [Ace] Review of draft-ietf-ace-oauth-params-00 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, 23 Oct 2018 19:09:55 -0000 --_000_VI1PR0801MB2112DD9ECD09B98C5060D868FAF50VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I read through draft-ietf-ace-oauth-params-00 and have a few comments. 1) I believe the document should explain in more detail about how it fits i= nto the rest of the OAuth PoP token work. The story essentially is that we have the HTTP-based transport in the OAuth= WG and we have the CoAP-based transport in ACE. draft-ietf-ace-oauth-params-00 is about registering the necessary p= arameters for use with CoAP only. Neither the abstract nor the intro says this. 2) 'req_aud' parameter At the last IETF OAuth meeting in Montreal we agreed to adopt a new documen= t, called resource indicators, and it can be found here: https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-01 I believe the parameter name and semantics defined in draft-ietf-oauth-reso= urce-indicators-01 should match what is defined in draft-ietf-ace-oauth-par= ams-00. The name of the parameter in draft-ietf-oauth-resource-indicators-01 is 're= source' and it is defined as resource Indicates the location of the target service or resource where access is being requested. Its value MUST be an absolute URI, as specified by Section 4.3 of [RFC3986], which MAY include a query component but MUST NOT include a fragment component. Multiple "resource" parameters MAY be used to indicate that the requested token is intended to be used at multiple resources. In a nutshell I believe you should do the following: a) rename the parameter to 'resource' to get it inline with draft-ietf-oau= th-resource-indicators-01 b) use the same semantics as in draft-ietf-oauth-resource-indicators-01 c) find out what the encoding considerations are when using CoAP 3) 'req_cnf' parameter Changing the name of the parameter name from the previous 'cnf' is good and= that was also requested at the last IETF due to the potential confusion wi= th the 'cnf' claim name. However, I believe the semantics is different to t= he semantics defined in draft-ietf-oauth-pop-key-distribution. Unless I mis= understand but the relevant text regarding the req_cnf parameter content is= this: o "req_cnf" in the token request C -> AS, OPTIONAL to indicate the client's raw public key, or the key-identifier of a previously established key between C and RS that the client wishes to use for proof-of-possession of the access token. For example, in draft-ietf-oauth-pop-key-distribution there is no key ident= ifier passed from the client to the server when making the request for a Po= P token. Instead, the server just mints one (along with the symmetric key) = and sends it to the client. Ciao Hannes PS: Why was a standalone document written instead of leaving the parameters= in the ACE-OAuth framework spec? I guess there are reasons (which I may ha= ve missed). 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_VI1PR0801MB2112DD9ECD09B98C5060D868FAF50VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I read through draft-ietf-ace-oauth-params-00 and ha= ve a few comments.

 

1) I believe the document should explain in more det= ail about how it fits into the rest of the OAuth PoP token work.

The story essentially is that we have the HTTP-based= transport in the OAuth WG and we have the CoAP-based transport

in ACE. draft-ietf-ace-oauth-params-00 is about regi= stering the necessary parameters for use with CoAP only.

 

Neither the abstract nor the intro says this. <= /o:p>

 

2) 'req_aud' parameter

 

At the last IETF OAuth meeting in Montreal we agreed= to adopt a new document, called resource indicators, and it can be found h= ere:

https://tools.ietf.org/html/draft-ietf-oauth-resourc= e-indicators-01

 

I believe the parameter name and semantics defined i= n draft-ietf-oauth-resource-indicators-01 should match what is defined in d= raft-ietf-ace-oauth-params-00.

 

The name of the parameter in draft-ietf-oauth-resour= ce-indicators-01 is 'resource' and it is defined as

 

   resource

      Indicates the locatio= n of the target service or resource where

      access is being reque= sted.  Its value MUST be an absolute URI, as

      specified by Section = 4.3 of [RFC3986], which MAY include a query

      component but MUST NO= T include a fragment component.  Multiple

      "resource" = parameters MAY be used to indicate that the requested

      token is intended to = be used at multiple resources.

        &nbs= p;      

In a nutshell I believe you should do the following:=

 a) rename the parameter to 'resource' to get i= t inline with draft-ietf-oauth-resource-indicators-01

b) use the same semantics as in draft-ietf-oauth-res= ource-indicators-01

c) find out what the encoding considerations are whe= n using CoAP

 

3) 'req_cnf' parameter

 

Changing the name of the parameter name from the pre= vious 'cnf' is good and that was also requested at the last IETF due to the= potential confusion with the 'cnf' claim name. However, I believe the sema= ntics is different to the semantics defined in draft-ietf-oauth-pop-key-distribution. Unless I misunderstand b= ut the relevant text regarding the req_cnf parameter content is this:

 

   o  "req_cnf" in the toke= n request C -> AS, OPTIONAL to indicate the

      client's raw public k= ey, or the key-identifier of a previously

      established key betwe= en C and RS that the client wishes to use for

      proof-of-possession o= f the access token.

        &nbs= p;      

For example, in draft-ietf-oauth-pop-key-distributio= n there is no key identifier passed from the client to the server when maki= ng the request for a PoP token. Instead, the server just mints one (along w= ith the symmetric key) and sends it to the client.

 

 

Ciao

Hannes

 

PS: Why was a standalone document written instead of= leaving the parameters in the ACE-OAuth framework spec? I guess there are = reasons (which I may have missed).

 

 

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_VI1PR0801MB2112DD9ECD09B98C5060D868FAF50VI1PR0801MB2112_-- From nobody Tue Oct 23 14:20:31 2018 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 89A48130D7A for ; Tue, 23 Oct 2018 14:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-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=armh.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 tmI_XfAg5umj for ; Tue, 23 Oct 2018 14:20:28 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40059.outbound.protection.outlook.com [40.107.4.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DB88130DC7 for ; Tue, 23 Oct 2018 14:20:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gZQepE55X6FxHeSkgAx0hFqjBraS7Dc8bqIgO+mEedQ=; b=V8ccqtiYppHyB3fED1WT2JOwigloOEsEqhGP4yIdW6yupzFK4kWzr7AUpygmvcMaMQmBt26wf7dLidXEMoSevdBzPxQisw9YZ8W7OFXMkK8RKnul5nsgMJ3WdpD3vr7WDXkXmE1pNhkfTct0ssdL7qTXCDI+2Bw020NqFxNfdLc= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1344.eurprd08.prod.outlook.com (10.167.198.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.30; Tue, 23 Oct 2018 21:20:25 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7165:6199:a54f:510c]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7165:6199:a54f:510c%2]) with mapi id 15.20.1273.014; Tue, 23 Oct 2018 21:20:25 +0000 From: Hannes Tschofenig To: "Ace@ietf.org" Thread-Topic: draft-ietf-oauth-pop-key-distribution-04 Thread-Index: AdRrFbjk8H/jJ0g6SqSNJ6nGbsSaoQAAFuGQ Date: Tue, 23 Oct 2018 21:20:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [64.71.18.60] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1344; 6:9I+QfZDF4HNHGAW+s1bFTpcC1/3EmWcHA6TCf77Dwam2Atk6j+Z8ir6VG4V+b16SHUeT1xOkOdeEdICNooR9OllkGv25w9G9RRp0llWMahoU5vOpry0bSaO8O+ZazmUskjC801yito/CXr1oh70GzwCpOk/QYWhAugyzrk38rWXikodUIQ8b+mEhQzmXLs+fcgzu7JjsHYrX5eS6Ci16RgrXZJFUnm/2sFW9zWB+y7He5Xiz/py9QJ6iPDoA3QouLfnLKQluTKMNaYGHksgMdtTXi7n8LmThq0OoWhEPGFoIRRcXeBsfuxn8U4FErj8l+IIwvUHsR/VYfvwXanQB6VWeS2xiwD7ldzawFGro7n0bpveZt8k0ovq168nKUJC+q4r8JoWRxAqqWLoU4a0MzPjBJ9PGYtHRuviPQumwAYybvIPVWTzSGBAQaGQVgaUPYB2IgQb/2yio22VfG4h66Q==; 5:7fewJ8b5j47542wc0zHticSePPvD6G5NvkmPGdyueg36r0y6ltYY9ewWOPUJjix/2LLZzL9JGNNfeWnt5a5xVnhBzfOd3P+P976sCgGPBfLZq6/ObF4Eo5erbvr2AXr28ixzvHbOLxdYL8mF7/x1rBQph0TUK1uQAp5F5ma4pMc=; 7:a+vhCwWk5KbZSw8+jVgaF2+CSGXkCW5mjeDOa0PEo3FtOS4U+WCq2coIZTEQlqDDIWPCYhGTB+W7mIUFaUoEQ0BWY1mfDycxblw0kXhqLM7vJR+1O3KPyOWB2tfed0Gkw0FsdQyN95R5jen/XFPPRRqQ1mTnhckCYXr45FjgADGt5F2WCJOwilKTi7/tTfzKmsjfyTU6YYUHKdLR30Oa3Ty9Ea0HpYMp3RLUmsofwdlc2rtpkN20LQyKOVEj6ORM x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 34d604e4-abce-405c-c65e-08d6392d5985 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1344; x-ms-traffictypediagnostic: VI1PR0801MB1344: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155)(28532068793085)(190501279198761)(227612066756510); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231355)(944501410)(52105095)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:VI1PR0801MB1344; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1344; x-forefront-prvs: 0834BAF534 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(376002)(346002)(39860400002)(396003)(189003)(199004)(40434004)(53754006)(2906002)(486006)(54896002)(97736004)(9686003)(2473003)(236005)(81166006)(71200400001)(316002)(5640700003)(55016002)(5250100002)(5660300001)(6436002)(53936002)(86362001)(81156014)(8676002)(446003)(71190400001)(8936002)(93156006)(6306002)(476003)(5024004)(11346002)(256004)(25786009)(186003)(14444005)(478600001)(102836004)(26005)(6506007)(229853002)(53546011)(106356001)(105586002)(606006)(2940100002)(6916009)(2501003)(2351001)(74316002)(5630700001)(33656002)(14454004)(2900100001)(68736007)(72206003)(7736002)(99286004)(3846002)(790700001)(7696005)(66066001)(76176011)(966005)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1344; H:VI1PR0801MB2112.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-microsoft-antispam-message-info: KXE/pv1jdQUHRHnYxm199ahjC9ZdRcXrzsu++P5t+hJSIFx2AxQQiFY8zqpWdfPbRU0OA5ShfZXI1TSjx0fygre0rLRwPVKDtR9vjsPo6hOQ6zgG8M3lZsMV+CPAlo4qwl09z/BNwNgS9azM1ievc3T3wG5PhQm+rN/i2g3I+cw38K3lQMBoiEwPu1raZflcxND9YvDY0SLztcP83FUQIYW0d1K7CrG0TGum51LVFZha6xQBH7UpbvtKLmo/nwA9YjuCNApvQlx9Hj34SexY5LAUxgWPbsPbv98sfSF11r1u7/GrPiVRLaf0NrodFxfLUZ7lsR4WZMSDf5AVKvLqGrbv/vrfXwc/ZsnHAr5JIoQ= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB2112BF5C7FA8F7CD8B124634FAF50VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 34d604e4-abce-405c-c65e-08d6392d5985 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2018 21:20:25.6504 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1344 Archived-At: Subject: [Ace] FW: draft-ietf-oauth-pop-key-distribution-04 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, 23 Oct 2018 21:20:30 -0000 --_000_VI1PR0801MB2112BF5C7FA8F7CD8B124634FAF50VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I submitted an update of the PoP key distribution document to get it in syn= c with what is happening with the ACE OAuth framework. Ciao Hannes From: Hannes Tschofenig Sent: Tuesday, October 23, 2018 2:19 PM To: oauth Subject: draft-ietf-oauth-pop-key-distribution-04 Hi all, I refreshed the PoP key distribution document today, see https://tools.ietf= .org/html/draft-ietf-oauth-pop-key-distribution-04, in an attempt to get th= e document inline with the agreements we made at the Montreal IETF meeting,= the Resource Indicators draft, and the work happening in ACE. Thanks to Mike for going through the draft with me and for spotting several= copy-and-paste mistakes. 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. --_000_VI1PR0801MB2112BF5C7FA8F7CD8B124634FAF50VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I submitted an update of the PoP key distribution do= cument to get it in sync with what is happening with the ACE OAuth framewor= k.

 

Ciao
Hannes

 

From: Hannes Tschofenig
Sent: Tuesday, October 23, 2018 2:19 PM
To: oauth <oauth@ietf.org>
Subject: draft-ietf-oauth-pop-key-distribution-04<= /p>

 

Hi all,

 

I refreshed the PoP key distribution document today,= see https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-04, i= n an attempt to get the document inline with the agreements we made at the = Montreal IETF meeting, the Resource Indicators draft, and the work happenin= g in ACE.

 

Thanks to Mike for going through the draft with me a= nd for spotting several copy-and-paste mistakes.

 

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. --_000_VI1PR0801MB2112BF5C7FA8F7CD8B124634FAF50VI1PR0801MB2112_-- From nobody Tue Oct 23 18:45:05 2018 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 93825130DC5; Tue, 23 Oct 2018 18:45:02 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...] X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 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, UNPARSEABLE_RELAY=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 pWtJTzRVH2jh; Tue, 23 Oct 2018 18:45:00 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 4DD2E130DE8; Tue, 23 Oct 2018 18:45:00 -0700 (PDT) X-AuditID: 12074424-ce7ff700000052c8-f8-5bcfce992f8c Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id F8.F6.21192.99ECFCB5; Tue, 23 Oct 2018 21:44:58 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.14.7/8.9.2) with ESMTP id w9O1it90022271; Tue, 23 Oct 2018 21:44:56 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id w9O1ipmA002257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Oct 2018 21:44:54 -0400 Date: Tue, 23 Oct 2018 20:44:51 -0500 From: Benjamin Kaduk To: Ludwig Seitz Cc: Jim Schaad , draft-ietf-ace-oauth-authz@ietf.org, ace@ietf.org Message-ID: <20181024014450.GN45914@kduck.kaduk.org> References: <065b01d45f4e$b8d372a0$2a7a57e0$@augustcellars.com> <028d01d46a3a$bc6414f0$352c3ed0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixCmqrDvr3Plog2+NvBbfv/UwW1xYsJzd YvX072wWrz5PZ3Vg8dg4Zzqbx5IlP5k8ljZtZgpgjuKySUnNySxLLdK3S+DKeLlxH1tBG0fF 5N3XmRoY17J1MXJwSAiYSJz/odfFyMkhJLCGSeL/VOMuRi4geyOjxI51b1kgnLtMEm8XTmUF qWIRUJV4OaOZEcRmE1CRaOi+zAxiiwDFTz79AmYzCyRLPNszgQXEFhYwkHh86QkTiM0LtOzm lJtMEEOXMEq8P3qIGSIhKHFy5hMWiGYtiRv/XjKBXMcsIC2x/B8HSJhTwFKi42Yf2BxRAWWJ vX2H2CcwCsxC0j0LSfcshO4FjMyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdM31cjNL9FJTSjcx gkKY3UVlB2N3j/chRgEORiUe3gO156OFWBPLiitzDzFKcjApifJePQwU4kvKT6nMSCzOiC8q zUktPsQowcGsJMKrrAGU401JrKxKLcqHSUlzsCiJ805sWRwtJJCeWJKanZpakFoEk5Xh4FCS 4DU5C9QoWJSanlqRlplTgpBm4uAEGc4DNNwZpIa3uCAxtzgzHSJ/ilFRSpzXHiQhAJLIKM2D 6wWlGIns/TWvGMWBXhHmnQdSxQNMT3Ddr4AGMwENvq5+BmRwSSJCSqqBsa/J2bD/xYKnFw0W M+e8ni8xRXTztfcLzqysb368O1Ba9bOz19lN+yp2LdT6/bpg7cROu23HWaYtU9Q/q17SX1TG ot2buYvvzKt2s6OOsrustn8+xJ3dEv0ziXlx1/FLBwIKGpKmlfIrTHvOf2FhgvcRC7ss5ZMO n3hCXsw+lVvAIXbAuSN1shJLcUaioRZzUXEiAPZxc18MAwAA Archived-At: Subject: Re: [Ace] WGLC for draft-ietf-ace-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 01:45:03 -0000 Just one minor note -- this is a great discussion to see happening! On Tue, Oct 23, 2018 at 04:43:14PM +0200, Ludwig Seitz wrote: > > On 22/10/2018 21:09, Jim Schaad wrote: > > * Section 5.8.2 - If the RS is going to do introspection, can it send some > > type of "Server Busy - try again in xxx" while it does the introspection > > rather than just doing an ack of the request and possibly waiting a long > > time? > > This is probably transport protocol specific, and we were asked not to > link the framework to a specific protocol, thus I don't know if we can > provide guidance here. I think it would be okay to say something like "some transport protocols may provide a way to indicate that the server is busy and the client should retry after an interval; this type of status update would be appropriate while the server is waiting for an introspection response". Which does provide guidance, but in a non-normative fashion that does not require or prohibit any given transport protocol. -Ben From nobody Wed Oct 24 00:39:44 2018 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 E8D3112F1A2 for ; Wed, 24 Oct 2018 00:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 7bsPuagrgK9i for ; Wed, 24 Oct 2018 00:39:40 -0700 (PDT) Received: from smtp-out10.electric.net (smtp-out10.electric.net [185.38.180.39]) (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 8BB581293FB for ; Wed, 24 Oct 2018 00:39:40 -0700 (PDT) Received: from 1gFDlS-000XxL-VD by out10c.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1gFDlS-000XyP-Vu for ace@ietf.org; Wed, 24 Oct 2018 00:39:38 -0700 Received: by emcmailer; Wed, 24 Oct 2018 00:39:38 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out10c.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1gFDlS-000XxL-VD for ace@ietf.org; Wed, 24 Oct 2018 00:39:38 -0700 Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Wed, 24 Oct 2018 09:39:38 +0200 To: References: From: Ludwig Seitz Message-ID: Date: Wed, 24 Oct 2018 09:39:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) X-PolicySMART: 14510320 Archived-At: Subject: Re: [Ace] Review of draft-ietf-ace-oauth-params-00 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, 24 Oct 2018 07:39:43 -0000 On 23/10/2018 21:09, Hannes Tschofenig wrote: > Hi all, > > I read through draft-ietf-ace-oauth-params-00 and have a few comments. > > 1) I believe the document should explain in more detail about how it > fits into the rest of the OAuth PoP token work. > Ok I can update the introduction. > The story essentially is that we have the HTTP-based transport in the > OAuth WG and we have the CoAP-based transport > > in ACE. draft-ietf-ace-oauth-params-00 is about registering the > necessary parameters for use with CoAP only. > > Neither the abstract nor the intro says this. > Actually at the moment it is about registering necessary parameters for both HTTP and CoAP and whatever other transport you can want, since when I wrote it draft-ietf-oauth-pop-key-distribution was dormant. > 2) 'req_aud' parameter > > At the last IETF OAuth meeting in Montreal we agreed to adopt a new > document, called resource indicators, and it can be found here: > > https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-01 > I'll have a look at that draft. How close is it to WGLC? > > 3) 'req_cnf' parameter > > Changing the name of the parameter name from the previous 'cnf' is good > and that was also requested at the last IETF due to the potential > confusion with the 'cnf' claim name. However, I believe the semantics is > different to the semantics defined in > draft-ietf-oauth-pop-key-distribution. Unless I misunderstand but the > relevant text regarding the req_cnf parameter content is this: > > o "req_cnf" in the token request C -> AS, OPTIONAL to indicate the > > client's raw public key, or the key-identifier of a previously > > established key between C and RS that the client wishes to use for > > proof-of-possession of the access token. > > For example, in draft-ietf-oauth-pop-key-distribution there is no key > identifier passed from the client to the server when making the request > for a PoP token. Instead, the server just mints one (along with the > symmetric key) and sends it to the client. > Weird, because in the RFC7800 there is a cnf claim with just a key-id. I thought that you would want to be able to do something similar when requesting a specific, previously known key. > PS: Why was a standalone document written instead of leaving the > parameters in the ACE-OAuth framework spec? I guess there are reasons > (which I may have missed). The idea was that OAuth could obsolete that document when they sort the pop stuff out, without obsoleting the ACE framework. Thus a different standalone document. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 From nobody Wed Oct 24 01:00:36 2018 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 71802130DC0 for ; Wed, 24 Oct 2018 01:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 faMNt3b7wPy8 for ; Wed, 24 Oct 2018 01:00:32 -0700 (PDT) Received: from smtp-out10.electric.net (smtp-out10.electric.net [185.38.180.37]) (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 C17ED1293FB for ; Wed, 24 Oct 2018 01:00:32 -0700 (PDT) Received: from 1gFE5d-000JWx-Vx by out10c.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1gFE5e-000Ja4-TY for ace@ietf.org; Wed, 24 Oct 2018 01:00:30 -0700 Received: by emcmailer; Wed, 24 Oct 2018 01:00:30 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out10c.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1gFE5d-000JWx-Vx for ace@ietf.org; Wed, 24 Oct 2018 01:00:29 -0700 Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Wed, 24 Oct 2018 10:00:29 +0200 To: References: From: Ludwig Seitz Message-ID: Date: Wed, 24 Oct 2018 10:00:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-PolicySMART: 14510320 X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) Archived-At: Subject: Re: [Ace] Review of draft-ietf-ace-oauth-params-00 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, 24 Oct 2018 08:00:35 -0000 On 23/10/2018 21:09, Hannes Tschofenig wrote: > 2) 'req_aud' parameter > > At the last IETF OAuth meeting in Montreal we agreed to adopt a new > document, called resource indicators, and it can be found here: > > https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-01 > > I believe the parameter name and semantics defined in > draft-ietf-oauth-resource-indicators-01 should match what is defined in > draft-ietf-ace-oauth-params-00. > > The name of the parameter in draft-ietf-oauth-resource-indicators-01 is > 'resource' and it is defined as > > resource > > Indicates the location of the target service or resource where > > access is being requested. Its value MUST be an absolute URI, as > > specified by Section 4.3 of [RFC3986], which MAY include a query > > component but MUST NOT include a fragment component. Multiple > > "resource" parameters MAY be used to indicate that the requested > > token is intended to be used at multiple resources. > > Looking closer at this draft: The resource parameter seems to be much more limited than the audience claim, since a URI is required. As Steffi recently remarked in her review of draft-ietf-oauth-authz, URIs are not a good way to identify resources in constrained environments, since the address of a device can change. Furthermore there seems also to be an overlap with the 'scope' parameter, since the 'resource' parameter can be used to indicate specific resources and not only the target RS. What if we want to identify the audience by its public key instead of an URI? What if a client wants to request a token for a group of RS identified by a specific audience value (e.g. "thermostats-building-1")? /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 From nobody Wed Oct 24 02:02:42 2018 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 770BE130F75; Wed, 24 Oct 2018 02:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 OUpJKKYUb7tj; Wed, 24 Oct 2018 02:02:31 -0700 (PDT) Received: from smtp-out11.electric.net (smtp-out11.electric.net [185.38.181.35]) (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 EE955130F3E; Wed, 24 Oct 2018 02:02:30 -0700 (PDT) Received: from 1gFF3c-000Qww-U6 by out11d.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1gFF3c-000Qyb-VS; Wed, 24 Oct 2018 02:02:28 -0700 Received: by emcmailer; Wed, 24 Oct 2018 02:02:28 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out11d.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1gFF3c-000Qww-U6; Wed, 24 Oct 2018 02:02:28 -0700 Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Wed, 24 Oct 2018 11:02:28 +0200 To: Jim Schaad , CC: References: <065b01d45f4e$b8d372a0$2a7a57e0$@augustcellars.com> <028d01d46a3a$bc6414f0$352c3ed0$@augustcellars.com> <038001d46b00$767a8520$636f8f60$@augustcellars.com> From: Ludwig Seitz Message-ID: <0e01455c-4337-c51a-c199-fd5b56cf717d@ri.se> Date: Wed, 24 Oct 2018 11:02:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <038001d46b00$767a8520$636f8f60$@augustcellars.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) X-PolicySMART: 14510320 Archived-At: Subject: Re: [Ace] WGLC for draft-ietf-ace-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 09:02:41 -0000 On 23/10/2018 20:44, Jim Schaad wrote: > > > >>> * Section 6 - I am not sure that I agree with the SHOULD NOT in >>> the last paragraph. Think multicast. >> Any suggestions on how to mitigate the issue then? If I issue a >> token bound to a symmetric key for audience {R1, R2, R3}, as soon >> as R1 got this token it can impersonate the client and gain access >> to R2 and R3. > > I am not sure that I think this is an issue that needs to be > mitigated. It needs to be acknowledged, but the assumption would be > that if you have three resource servers that are hosting the same > audience they are going to be run by the same RO and already be > coupled. After all it should not matter which of them you do a GET > from, you should get the same answer. Similarly a PUT to one should > propagate to the others so that it is available to all clients. > Say the client is a cleaning service and the audience is the locks of the different apartments it is allowed to open. If the token uses symmetric keys, as soon as the cleaning service sends the token to one apartment, this apartment can open the other apartments. This is the situation I want to avoid. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 From nobody Wed Oct 24 02:03:12 2018 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 DF943130E7F; Wed, 24 Oct 2018 02:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 JfhBiPGlPKjy; Wed, 24 Oct 2018 02:03:09 -0700 (PDT) Received: from smtp-out11.electric.net (smtp-out11.electric.net [185.38.181.43]) (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 186A8130E7E; Wed, 24 Oct 2018 02:03:09 -0700 (PDT) Received: from 1gFF4D-000RNH-TB by out11c.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1gFF4D-000RR2-VL; Wed, 24 Oct 2018 02:03:05 -0700 Received: by emcmailer; Wed, 24 Oct 2018 02:03:05 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out11c.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1gFF4D-000RNH-TB; Wed, 24 Oct 2018 02:03:05 -0700 Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Wed, 24 Oct 2018 11:03:04 +0200 To: Benjamin Kaduk CC: Jim Schaad , , References: <065b01d45f4e$b8d372a0$2a7a57e0$@augustcellars.com> <028d01d46a3a$bc6414f0$352c3ed0$@augustcellars.com> <20181024014450.GN45914@kduck.kaduk.org> From: Ludwig Seitz Message-ID: Date: Wed, 24 Oct 2018 11:02:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20181024014450.GN45914@kduck.kaduk.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) X-PolicySMART: 14510320 Archived-At: Subject: Re: [Ace] WGLC for draft-ietf-ace-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 09:03:11 -0000 On 24/10/2018 03:44, Benjamin Kaduk wrote: > Just one minor note -- this is a great discussion to see happening! > > On Tue, Oct 23, 2018 at 04:43:14PM +0200, Ludwig Seitz wrote: >> >> On 22/10/2018 21:09, Jim Schaad wrote: >>> * Section 5.8.2 - If the RS is going to do introspection, can it send some >>> type of "Server Busy - try again in xxx" while it does the introspection >>> rather than just doing an ack of the request and possibly waiting a long >>> time? >> >> This is probably transport protocol specific, and we were asked not to >> link the framework to a specific protocol, thus I don't know if we can >> provide guidance here. > > I think it would be okay to say something like "some transport protocols > may provide a way to indicate that the server is busy and the client should > retry after an interval; this type of status update would be appropriate > while the server is waiting for an introspection response". Which does > provide guidance, but in a non-normative fashion that does not require or > prohibit any given transport protocol. > > -Ben > Thank you for the suggestion. I will integrate that text. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 From nobody Wed Oct 24 06:53:49 2018 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 EF082129619 for ; Wed, 24 Oct 2018 06:53:47 -0700 (PDT) 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] 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 uTeannrD72fi for ; Wed, 24 Oct 2018 06:53:43 -0700 (PDT) Received: from smtp.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 9540112785F for ; Wed, 24 Oct 2018 06:53:29 -0700 (PDT) Received: from [192.168.1.109] (p508A4EFC.dip0.t-ipconnect.de [80.138.78.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 2269127F8E; Wed, 24 Oct 2018 15:53:27 +0200 (CEST) From: Stefanie Gerdes To: Ludwig Seitz , ace@ietf.org References: <4519f58c-c6f7-5ac0-003c-7ae4f59bccd4@tzi.de> <43b3b90f-996a-8b8a-2439-e3d6adcc3b0f@ri.se> Message-ID: <121cc6e8-65cc-a32e-9d50-68c620b57543@tzi.de> Date: Wed, 24 Oct 2018 15:53:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <43b3b90f-996a-8b8a-2439-e3d6adcc3b0f@ri.se> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] ACE Framework Review 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, 24 Oct 2018 13:53:48 -0000 Hi Ludwig, On 10/22/2018 03:07 PM, Ludwig Seitz wrote: > >> The minimal security requirements for the communication between two >> communication partners should be listed (C-AS, RS-AS, C-RS, >> respectively). Which pieces of information do they require prior to the >> communication? How must the communication be secured? Which keying >> material do they need to use? > > The first one I agree with. However the other questions seem more > specific to the commSec solution to me, which would put them into the > profiles. In Appendix C, you specify that the security protocol between C and RS must provide encryption, integrity and replay protection. It would be useful to list similar requirements for the communication between C and AS and RS and AS. In section 5 you state "Nevertheless, it is REQUIRED that the data exchanged with the AS is encrypted and integrity protected. Does that refer to both the communication between the AS and C and between the AS and RS? It would be useful to clarify that in the sentence. The client may specify a key in the request to the AS. The AS must ascertain that the client that sent the request is associated with this key. Otherwise a client may request tokens for other clients. Although the client cannot gain access with these tokens without the corresponding keying material, it may use the token for DoS attacks on the resource server's authorization information endpoint. Since the tokens are valid, RS cannot throw them away. > >> The framework should point out that all >> claims that influence the security must stem from claimants that were >> approved by the respective human being that is responsible for the >> device, i.e., the requesting party for the client and the resource owner >> for the AS and RS. Otherwise the solution is not secure. >> > > Are there claims that do not influence security? > > The specification says (section 4): > > The consent of the resource owner, for giving a client access to a > protected resource, can be provided dynamically as in the traditional > OAuth flows, or it could be pre-configured by the resource owner as > authorization policies at the AS, which the AS evaluates when a token > request arrives. The resource owner and the requesting party (i.e., > client owner) are not shown in Figure 1. > > I believe this is what you were looking for, if not please explain what > is missing. As I read it, this paragraph only addresses authorization information that is meant for the server. The client may receive keying material for RS from AS. In this case, C's owner, i.e., RqP, must authorize AS to provide keying material to C. > >> Validity of the access token (Token Expiration, Section 5.8.3): There >> seem to be additional requirements here that are currently not >> mentioned. It is not clear how RS determines the freshness of >> introspection messages (and how fresh they are). > > That would be up to the commSec protocol, also it is covered in the > security considerations of RFC 7662. I will add a reference to those > considerations in our security considerations section. > >> Also, the token >> introspection approach is particularly vulnerable to DoS attacks since >> introspection messages must be exchanged to validate every token. > > This problem applies to regular OAuth introspection as well and is > covered in the security considerations of RFC 7662. It might be useful to mention that in the security considerations. > >> The sequence number approach has the problem that an attacker may >> withhold new tokens from RS. In this case, old tokens are infinitely >> valid. This is particularly damaging because C may have a strong >> interest to withhold new tokens and can easily do so by not relaying >> them to RS. This approach therefore must not be used unless there is an >> additional communication channel between RS and AS that regularly >> informs RS which the most recent sequence number is. >> > This is a best effort approach when the RS has no internal sense of > time. Also the idea was that several client could submit tokens with an > ever increasing unique serial number maintained by the AS. Thus even if > one client would withhold it's newer tokens to keep the old ones from > expiring, the other clients would eventually submit enough new tokens > (with higher sequence numbers) so that the token expires. > > AFAIK the RS with no internal clock at all is a very rare occurrence, > thus you can usually expect some form of wallclock time, and thus > implement an expiration based on "time-since-you-received-this-token". I don't think it is reasonable to require that the RS must have multiple clients to ensure that the mechanism works. If you expect the RS to have a wallclock time, you may want to omit the sequence number approach. If the mechanism only works when additional requirements are met, these requirements must be mentioned. If the RS calculates the expiration of the token from the time it received the token (an appraoch which currently does not seem to be mentioned in the document?), the approach is vulnerable to attacks where an attacker manages to withhold messages. > >> Authorization of the AS on the RS side: in the ACE framework, RS checks >> the integrity of the access token (e.g., section 4, section 6, Appendix >> B: Resource Server). RS must also check that the access token stems from >> an AS that is authorized by RO to provide the token. If RS accepts >> tokens from authorization servers that are not approved by RO, the >> solution is not secure. Introspection messages must also stem from an AS >> that is approved by RO. > > This is implicit, if the RS has the key that allows it to verify the > integrity of the token that means that it is an AS approved by its RO. > I will try to add a sentence to make that more explicit. > >> >> Access token validation: Section 5.8.1 should point out that RS must >> check the integrity of the token and validate that it stems from AS that >> is authorized by RO. > > We can expand on this phrase I think: "The RS receiving the token MUST > verify the validity of the token." That sounds like a good idea. > > >> Also, it would be helpful if the section also >> contained information how a server must react to missing fields, e.g., >> missing authenticity of the token or tokens from unknown authorization >> servers. >> > This would be the following sentence in 5.8.1: > "If the token is not valid, the RS MUST respond with a response code > equivalent to the CoAP code 4.01 (Unauthorized)." It would be useful to add when the RS can consider a token to be valid, i.e., which requirements a token must meet to be valid. > >> Confidentiality of access tokens: >> In the access token, confidentiality is only demanded for symmetric >> keys. The security considerations should point out that other data in >> the access token may be confidential and then require protection as well. >> > This should be covered in RFC 6749 and RFC 6819 which are referenced in > the security considerations. > > >> Authorization Rules in Access Token: The framework should mention in >> section 5.6.2 that the authorization rules that are presented to RS in >> the scope of the access token must reflect RO's decisions. > > That is already covered by the text in section 4 (see comment above). Section 5.6.2 describes how AS specifies the response to the client. I think it would help to avoid implementation errors if the section describes that the authorization rules that the AS defines in the access token must reflect RO's decisions. > >> >> Management of the authz-info resource: >> * The authz-info resource is vulnerable to DoS attacks: clients may >> (with or without intention) send large numbers of access tokens to RS. A >> constrained RS may soon run out of memory/storage space if it needs to >> store large numbers of tokens. > > A RS is not expected to store large numbers of tokens. Section 5.8.1 > specifies: > > "The RS MUST be prepared to store at least one access token for future > use." > > Thus the RS can adapt the number of tokens it stores to its constrained > storage resources. I don't really understand how storing at least one access token helps to mitigate the problem of DoS attacks. > >> If introspection messages are used to >> check the validity of access tokens, the use of the authz-info resource >> amplifies the risk of DoS attacks since RS must send a message to its AS >> for every received token. These problems should be mentioned in the >> security considerations. > > I will add a section describing the problem. > > >> The preferred mitigation should be that the >> authz-info resource is only used for protected communication. This does >> obviously not work for the RPK mode. In the PSK mode, RS should be able >> to decide that it uses the authz-info resource only for protected >> updates. > > I don't think that will help, since somehow the initial access token > must get to the RS. So even when passing it through the DTLS handshake > (as with PSK in the DTLS profile) the same DoS risk exists. If the client is not able to finish the DTLS handshake, the RS can throw the token away immediately. Also, DTLS has some protection against DoS attacks. If a resource is used, clients can upload large numbers of tokens to the resource, and no protection against DoS attacks is available. If the tokens are valid, the RS must in the worst case store them until they expire, even if the client never tries to communicate with RS. > >> * How must the authz-info resource be protected? E.g., an attacker that >> is able to modify the resource may change or delete access tokens. The >> framework leaves the protection of the resource to the profiles, but I >> think some general advice can be offered by the framework. > > I can add a paragraph on this in section 5. > >> >> Validity of the access information: >> It seems that the people who wrote the framework did not consider that >> the keying material is not only provided to RS but also to C. >> How does C determine if the keying material it receives from AS is still >> valid? > > It is valid as long as you don't get a 4.01 (Unauthorized) from the RS. > >> The access token response may comprise an expires_in >> field that contains the validity period of the access token in seconds >> (RFC 6749), but does not specify the validity period of the keying >> material. But even if the validity periods are equal, C does not know >> when the access token was generated. Also, the use of the expires_in >> field is optional. Without protection, the access information is >> infinitely valid. C may use outdated and maybe compromised keying >> material to communicate with RS. The framework should provide >> information how C determines if the keying material is still valid. >> Also, C must check if the keying material it has for a communication >> partner is still valid before sending a request. >> > > I would think that in most cases it is acceptable that the client just > optimistically sends its request with the existing keying material and > renews it if it gets back a 4.01. You mean if the client communicates with a compromised RS, it just continues to do so? I don't think that this is such a good idea. I think the AS must check that the the keying material is valid at least as long as the token and must then set the expires_in field to the remaining lifetime of the token. Additionally, the AS should provide the time when the token was issued in an iat field. A client that wants to communicate with an RS must check if the keying material it has for the RS is still valid. > > Use cases where the security policy is such that this is unacceptable > should use a specific profile that defines additional mechanisms for the > client to check its tokens and associated keying material (e.g. by using > client introspection). > >> The framework should also mention that C must determine if AS is >> authorized by its owner to provide keying material concerning RS to C. > > If C is configured to communicate with RS, this implies that the owner > of C accepts the AS in charge of RS. Otherwise the owner of C shouldn't > have configured C to communicate with RS in the first place. And how does C know that a certain AS is in charge of RS? > >> It is not clear how C makes plain to AS with which RS it wants to >> communicate. C may specify the intended audience in the token request >> using the req_aud parameter. How is RS represented in this case? >> C and AS must have a common understanding how RS is identified, >> otherwise C may communicate with the wrong RS! >> IP addresses may change and therefore are not suitable. If AS specifies >> identifiers for RS, C must securely obtain this knowledge. > > Identifying the RS (using the audience claim and the req_aud parameter) > is application specific. Some applications may want to use public keys, > others will want to use fixed identifiers that are manually assigned or > otherwise generated. > > The framework does not suggest IP addresses as a way to identify an RS. > >> The framework must point out that AS must check if the keying material >> that it provides to C in the access token response actually refers to >> the RS that C wants to communicate with. The problem of mixups >> concerning the RS must be mentioned in the security considerations. >> Also, the framework should give advice how this problem may be addressed. >> > > I will add a paragraph describing the problem and giving some basic > suggestions (such as public keys as identifiers). > > >> Confidentiality of unauthorized requests: >> The data that the client sends to the RS in an unauthorized resource >> request may be confidential (e.g., because others must not know the >> requested resources). The framework should mention in the security >> considerations that the client must not send confidential data in the >> unauthorized resource request. > > I can add a sentence about this, although it seems very obvious. > > /Ludwig > > Viele Gre Steffi -- Stefanie Gerdes Tel: +49 421 218 63906 TZI Universitt Bremen E-Mail: gerdes@tzi.de Bibliothekstr. 1, MZH 5150 28359 Bremen, Germany From nobody Wed Oct 24 06:53:58 2018 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 3F7C4127133 for ; Wed, 24 Oct 2018 06:53:49 -0700 (PDT) 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] 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 Mt4V7W0xnK-V for ; Wed, 24 Oct 2018 06:53:46 -0700 (PDT) Received: from smtp.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 28995130EC2 for ; Wed, 24 Oct 2018 06:53:32 -0700 (PDT) Received: from [192.168.1.109] (p508A4EFC.dip0.t-ipconnect.de [80.138.78.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 4F27427F8D; Wed, 24 Oct 2018 15:53:30 +0200 (CEST) To: Jim Schaad , 'Ludwig Seitz' , ace@ietf.org References: <4519f58c-c6f7-5ac0-003c-7ae4f59bccd4@tzi.de> <43b3b90f-996a-8b8a-2439-e3d6adcc3b0f@ri.se> <02af01d46a4a$2c629790$8527c6b0$@augustcellars.com> From: Stefanie Gerdes Message-ID: <03bdbb0c-0641-e933-8eef-eed9b99289b9@tzi.de> Date: Wed, 24 Oct 2018 15:53:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <02af01d46a4a$2c629790$8527c6b0$@augustcellars.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] ACE Framework Review 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, 24 Oct 2018 13:53:49 -0000 Hi Jim, On 10/22/2018 10:59 PM, Jim Schaad wrote: > > >> -----Original Message----- >> From: Ace On Behalf Of Ludwig Seitz >> Sent: Monday, October 22, 2018 6:08 AM >> To: ace@ietf.org >> Subject: Re: [Ace] ACE Framework Review >> >> On 10/10/2018 16:24, Stefanie Gerdes wrote: >>> Hi, >>> >>> I looked through the ACE framework document. I think there are some >>> open issues that need to be addressed. I will try to summarize the >>> main issues below. We provided a rough analysis of the DTLS profile in >>> [1], which may also be interesting (many of the issues mentioned there >>> were already fixed in the meantime). >> >> Thank you for your review. Sorry for the long response time. Answers > inline. I >> also tried to add issues in the issue tracker, but github seems to be >> experiencing trouble at the moment. >> >> /Ludwig > > >> >>> Validity of the access token (Token Expiration, Section 5.8.3): There >>> seem to be additional requirements here that are currently not >>> mentioned. It is not clear how RS determines the freshness of >>> introspection messages (and how fresh they are). >> >> That would be up to the commSec protocol, also it is covered in the > security >> considerations of RFC 7662. I will add a reference to those considerations > in >> our security considerations section. > > This seems to be a bit of an odd requirement to impose on the protocol and > not on the RS. The RS should have some type of idea of when it last asked > the AS if it was valid and also some idea of when the AS said this was going > to expire relative to when it last asked. If the RS asks twice and the AS > returns a cached answer that is on the AS and not on the RS. > > An RS with no sense of time could still implement a counter and ask the AS > every nth access to the resource (potentially spreading that over all > accesses by anybody). A counter that RS starts before sending the introspection message would help to solve this problem if a timeout is defined or if the introspection message contains the lifetime of the token. If this is the expected behavior of RS, it should be mentioned in the document. > >> >>> The sequence number approach has the problem that an attacker may >>> withhold new tokens from RS. In this case, old tokens are infinitely >>> valid. This is particularly damaging because C may have a strong >>> interest to withhold new tokens and can easily do so by not relaying >>> them to RS. This approach therefore must not be used unless there is >>> an additional communication channel between RS and AS that regularly >>> informs RS which the most recent sequence number is. >>> >> This is a best effort approach when the RS has no internal sense of time. > Also >> the idea was that several client could submit tokens with an ever > increasing >> unique serial number maintained by the AS. Thus even if one client would >> withhold it's newer tokens to keep the old ones from expiring, the other >> clients would eventually submit enough new tokens (with higher sequence >> numbers) so that the token expires. >> >> AFAIK the RS with no internal clock at all is a very rare occurrence, thus > you >> can usually expect some form of wallclock time, and thus implement an >> expiration based on "time-since-you-received-this-token". > > Additionally one could use the clear everything after n accesses to > resources. > >>> Management of the authz-info resource: >>> * The authz-info resource is vulnerable to DoS attacks: clients may >>> (with or without intention) send large numbers of access tokens to RS. A >>> constrained RS may soon run out of memory/storage space if it needs to >>> store large numbers of tokens. >> >> A RS is not expected to store large numbers of tokens. Section 5.8.1 >> specifies: >> >> "The RS MUST be prepared to store at least one access token for future >> use." >> >> Thus the RS can adapt the number of tokens it stores to its constrained >> storage resources. > > This might be a good place to reference the new core draft - too many > requests - as a reasonable response for an overloaded server in this case. > >>> The preferred mitigation should be that the >>> authz-info resource is only used for protected communication. This does >>> obviously not work for the RPK mode. In the PSK mode, RS should be able >>> to decide that it uses the authz-info resource only for protected > updates. >> >> I don't think that will help, since somehow the initial access token >> must get to the RS. So even when passing it through the DTLS handshake >> (as with PSK in the DTLS profile) the same DoS risk exists. > > Going the DTLS handshake route might actually make things worse as you are > now doing lots of additional process on the server side since you have added > all of the DTLS work to the token validation work. As I already pointed out in my response to Ludwig, transporting the token in the DTLS handshake has the advantage that the RS can discard the token if C is not able to finish the handshake. Also, DTLS has some protection against DoS attacks. Uploading large amounts of access tokens to a resource is very easy for a client. > >>> Validity of the access information: >>> It seems that the people who wrote the framework did not consider that >>> the keying material is not only provided to RS but also to C. >>> How does C determine if the keying material it receives from AS is still >>> valid? >> >> It is valid as long as you don't get a 4.01 (Unauthorized) from the RS. >> >>> The access token response may comprise an expires_in >>> field that contains the validity period of the access token in seconds >>> (RFC 6749), but does not specify the validity period of the keying >>> material. But even if the validity periods are equal, C does not know >>> when the access token was generated. Also, the use of the expires_in >>> field is optional. Without protection, the access information is >>> infinitely valid. C may use outdated and maybe compromised keying >>> material to communicate with RS. The framework should provide >>> information how C determines if the keying material is still valid. >>> Also, C must check if the keying material it has for a communication >>> partner is still valid before sending a request. >>> >> >> I would think that in most cases it is acceptable that the client just >> optimistically sends its request with the existing keying material and >> renews it if it gets back a 4.01. >> >> Use cases where the security policy is such that this is unacceptable >> should use a specific profile that defines additional mechanisms for the >> client to check its tokens and associated keying material (e.g. by using >> client introspection). > > I think that the use of the expires_in field in an AS response should cover > this case sufficiently well for most cases where the client might care. I > would agree that the failure of a request is a good clue that a new token > needs to be obtained. I am not sure that it makes any sense to say that > keying material has expired for the RPK case. It only makes sense to have > key lifetime for a POP symmetric token. In that case I would expect that > the lifetime of the token and the key material to be the same. I would not > think that a new token with expanded privileges on the same key material > should last beyond the original POP token. This does mean that there will > need to be a more frequent DTLS negotiation but that is not difficult for a > simple PSK with no asymmetric key. RPKs do not have semantic information attached to them and they do expire eventually. The AS must check if the keying material that it provides to C is still valid at least as long as the token and then must set the expires_in field to the remaining lifetime. To avoid attacks where an attacker manages to withhold messages, the AS should specify when the token was issued in an iat field. > >>> It is not clear how C makes plain to AS with which RS it wants to >>> communicate. C may specify the intended audience in the token request >>> using the req_aud parameter. How is RS represented in this case? >>> C and AS must have a common understanding how RS is identified, >>> otherwise C may communicate with the wrong RS! >>> IP addresses may change and therefore are not suitable. If AS specifies >>> identifiers for RS, C must securely obtain this knowledge. >> >> Identifying the RS (using the audience claim and the req_aud parameter) >> is application specific. Some applications may want to use public keys, >> others will want to use fixed identifiers that are manually assigned or >> otherwise generated. >> >> The framework does not suggest IP addresses as a way to identify an RS. > > There are two cases here that need to be thought about. The first is that > the audience and the RS are synonymous. In that case there is not a > problem here. The second case is an audience that exists on multiple > servers. The question then is should the token be setup for a single RS or > for every RS that hosts the audience? I would expect it to be the latter as > one could get a redirect at some point from RS1 to RS2 but it should not > require that a new token be obtained just that it be re-posted. The > question you ask would only be if interest if one said that multiple RSs > hosted a single audience and they all had to be keyed separately. The audience seems to be some string that (not necessarily uniquely) identifies RS. Appendix B states that the AS is expected to know which audiences refer to the RS. I wonder how C knows which audience identifies an RS. I think it is very important to point out that AS and C must have a common understanding how RS is identified because otherwise C will communicate with the wrong RS. Viele Gre Steffi From nobody Wed Oct 24 07:10:08 2018 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 D92DD12F295; Wed, 24 Oct 2018 07:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 oejjJyXPyO2g; Wed, 24 Oct 2018 07:09:55 -0700 (PDT) Received: from smtp-out10.electric.net (smtp-out10.electric.net [185.38.180.38]) (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 A77C5129AB8; Wed, 24 Oct 2018 07:09:53 -0700 (PDT) Received: from 1gFJr4-000RUK-Ux by out10b.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1gFJr5-000RWL-TY; Wed, 24 Oct 2018 07:09:51 -0700 Received: by emcmailer; Wed, 24 Oct 2018 07:09:51 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out10b.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1gFJr4-000RUK-Ux; Wed, 24 Oct 2018 07:09:50 -0700 Received: from [10.112.11.37] (10.100.0.158) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Wed, 24 Oct 2018 16:09:50 +0200 To: , Core , References: <866876ae4798de793536ea7f13396df2@bbhmail.nl> <0029fdca1c78326bc10e5332ed55b99c@bbhmail.nl> From: Marco Tiloca Openpgp: preference=signencrypt Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= xsBNBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAHNJ01hcmNvIFRpbG9jYSA8bWFyY28udGlsb2NhODRAZ21haWwuY29tPsLAewQTAQIAJQIb AwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AFAlSNerkCGQEACgkQ7iZktA5Y2kMiuwgAt/bV ZKqD92JNWDTX6h1MUsgejwj4RXs6UYqFdWW/4nw4mFHzYS+gBjOQAWCBhzVZLOk6gKcRZ/s8 6ncVygiDUh9fbSDTcuzOp2qgu9nsc8sEsYp1hwmiIEbI6FHPtyeQQNilsfU8+VHX2C9yQtMK /OXlf5qNkJMj9k55u+e1ELQ2sjUXkMB4MxMhmi/3P3hMz9PDcB66BtQcDFYkx5PIaz/izCST 0o28AJq0dionJpPsQ+hFOIAkJi6aCAt3xQf0KnXlAczWxCD3J3XTFK4MES/b3n3oc2GJY8I+ tsfT5jpNsWhfWGBkMaQSKZ939D4oFAhAq3gnNRgZszJeTvsMvc7ATQRUjXkVAQgAlpqfpOi5 GOP3su3gO7pmFXNtoslagBF5ssA2MxI3sGMEXI06x/zcdRKsIyA7lvgQRKDC0WThwoJo6Oh0 ZliLrXGFQrfYnqJLpbZKK/QQaEFT4iPk6edTqdNon5BnKxEDWYu6t35jrYRWcGejSZ1GwNm8 nGimfKApbwwkI+gIxMnQT50u91GhKA7KrBlY2cAoXzjIOTshZvdEI6SMPJtLg1XAsyin8at0 /8+7ckYLnCFHvOBMwbriQREhIyv4RdJ0diw4dUoQ9vRVqxWUjVVQlbtVGGSwGsn/KCihx6TP sIX4xGDuF7A6VeM0NeQPg9eR0Yh0egHX+Dw7TzNQwsIIIwARAQABwsBfBBgBAgAJBQJUjXkV AhsMAAoJEO4mZLQOWNpDxhMH/1jY08t8++Ly5h8nFbBV16EPFtfvOfJkcgHdGvCWM2N8Qewl baiNx8vPeEHMOB+hu/fQNTi/QdRHgPGI92js9DW1Mn+RlvoqLa94fPiiAjmGd+PwUGji83bw zZkaBh5/jXk84Re3knojyoto3sfjVaHYYzlRl8PBIWBpHmS78pxxG6IizOE28j21UfR7HVai hlUw8SkhN52pqN5L7WOrMkRSIlM+VsyX2ALqm7ept08QxG/LAPac2i7oZn5yUXNdh+TVWRGZ hPxJCRU5ZD+MJ2cjkn/69v1XdIh2rgcL+e3KWOhxRTHu67yuLOzBOc3LThJcuQujQrtWWjbX VLqg0jw= Message-ID: Date: Wed, 24 Oct 2018 16:09:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <0029fdca1c78326bc10e5332ed55b99c@bbhmail.nl> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="BywBIX1sslxAqy1bSqEkJJs9495ZT3870" X-Originating-IP: [10.100.0.158] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-Outbound-IP: 194.218.146.197 X-Env-From: marco.tiloca@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) X-PolicySMART: 14510320 Archived-At: Subject: Re: [Ace] [core] Fwd: review oscore-groupcomm-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: Wed, 24 Oct 2018 14:10:00 -0000 --BywBIX1sslxAqy1bSqEkJJs9495ZT3870 Content-Type: multipart/mixed; boundary="spS6n55020iR20htThQDENPPukal2TCAZ"; protected-headers="v1" From: Marco Tiloca To: consultancy@vanderstok.org, Core , ace@ietf.org Message-ID: Subject: Re: [core] Fwd: [Ace] review oscore-groupcomm-2 References: <866876ae4798de793536ea7f13396df2@bbhmail.nl> <0029fdca1c78326bc10e5332ed55b99c@bbhmail.nl> In-Reply-To: <0029fdca1c78326bc10e5332ed55b99c@bbhmail.nl> --spS6n55020iR20htThQDENPPukal2TCAZ Content-Type: multipart/alternative; boundary="------------B54995C963EF72A2ACF2E6B6" Content-Language: en-US This is a multi-part message in MIME format. --------------B54995C963EF72A2ACF2E6B6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Peter, Thanks a lot for your comments! We considered them for version -03. Please, find our answers in line. Best, /Marco On 9/20/18 10:02 AM, Peter van der Stok wrote: > > Hi authors, > > Thanks for this useful document. > > I have no comments on sections 3 and 4 that read rather easily. > > Some comments on the other sections follow below: > > Section 1.1 > > Introduce group request (GR)-message and response message in relation > to GR-client and GR-server to clarify text in section 2. To be used > consistently throughout the text. > MT: The text actually uses the same terminology from CoAP and OSCORE, i.e. "client", "server", "sender" and "recipient", as also stated in Section 1.1. RFC7390 does not use those or similar terms. MT: To simplify the text, we replaced "group message" with "message". > End page 3. The phrase on the use of DTLS seems a bit far-fetched; Do > you mean that multiple DTLS sessions are started for each group > request sent by a client? > MT: We tried to clarify by adding the last sentence "Note that DTLS cannot be used to secure messages sent over multicast." Other than that, same considerations as in OSCORE apply here. > Group ID: s/a same Group Manager/a given Group Manager/ > MT: Done. > End section 1.1; remove: =E2=80=9Cby a different group member or by a > non-group-member=E2=80=9D This only excludes itself. > MT: It's actually two different cases that we are both covering. We rephrased as: "This also provides assurance that the message was not tampered with by anyone, be it a different legitimate group member or an endpoint which is not a group member". > Section 2 > > Where does the endpoint store all these contexts? I assume local > storage is used. > MT: On this point, this document simply follows what defined in Section 7.5 of draft-ietf-core-object-security-15. > Text substitution suggestions: > > s/Each endpoint in the group stores:/Each endpoint in a group makes > use of:/ > > s/endpoints in the group/endpoints in a given group/ > > s/The ID Context parameter stores the group ID/The ID Context > parameter contains the group ID/ > MT: Done. > The Sender context description is confusing. I understood that both a > client when sending a group request, and a receiver when sending a > response message use the sender context for sending the message. The > text seems to suggest that only a group request need a sender context > and not the response message. > MT: The first interpretation you give is in fact correct. An endpoint always uses its own single sender context to secure an outgoing message, regardless if it is a request or a response. Hopefully this is clearer now that we have removed the term "group message". > If the Sender context applies only to group request messages, the term > request context is more appropriate and distinguishes from the sender > context in OSCORE > MT: See above. > Same confusion about the recipient context; the text seems to exclude > that a group request client also needs a recipient context. > MT: An endpoint always decrypts an incoming message using its own recipient context associated to the other group member sending that message. This applies to all incoming messages, regardless if it is a request or a response. > Table 1:=C2=A0 why =E2=80=9Ceach=E2=80=9D Recipient context and not =E2= =80=9Ceach=E2=80=9D sender context? > MT: The table refers to one given endpoint, which has: i) one common context; ii) one sender context, used to secure its own outgoing messages; iii) multiple recipient contexts to process incoming messages, i.e. one recipient context for each other endpoint in the group sending such incoming messages to this recipient endpoint. > Public key of the associated other endpoint: is this the group request > client endpoint or any endpoint sending to this recipient? > MT: Any other endpoint sending to this recipient endpoint. > Section 2.1:=C2=A0 should the section not refer to oscoap-joining draft= in ACE? > MT: The text in this section has been slightly restructured. It still gives an intuition of the issue at hand, while also pointing at the ace-oscoap-joining draft now covering also group rekeying through the Group Manager. > Section 3 =E2=80=98kid=E2=80=99 parameter value; Does this only apply t= o response > messages sent by group request servers? > MT: Now the text explicitly says that, unlike in OSCORE, 'kid' is always present in all messages, i.e. both requests and responses. > Section 5; I don=E2=80=99t think that I understand the problem. One of = the > conditions is that a client which is not part of a group cannot > decrypt the group messages, and a client that has left the group > cannot decrypt the group messages either. That constitutes already a > pretty firm synchronization. My assumption was that this would be > effectuated by distributing new master secret every time the group > changes. In Appendix C, you suggest the epoch in the GID (Chaging the > epoch, the GID may remain constant over group changes). My > recommendation is to make the epoch compulsory for synchronization > purposes. > MT: These are two different aspects. Section 5.1 (former Section 5) is about enabling a late-joiner or a rebooted device to be synchronized with the sequence numbers of requests sent by other group members. Should this synchronization be lost, such a device would not be able to assert the freshness of request messages using the replay window as per Section 8.2 of draft-ietf-core-object-security-15. MT: The epoch part of the Group ID enforces synchronization on the same Common Security Context, so that all group members have the same Master Secret, from which they can correctly derive the rest of the keying material. For the time being, we are referring to the Prefix+Epoch structure in Appendix C as an example of Gid format, since it would be good to keep the possibility to have different ones as defined by the application. MT: We have extended Section 5.1 (former Section 5), with the new third paragraph about sender endpoints that should store their outgoing messages for an application-specific amount of time, sufficient to handle possible retransmission of Non-Confirmable messages (such as requests over Multicast). > During membership of a group, a GR-client can consecutively number its > messages starting at zero every time a new epoch is started (with a > new master secret as specified in section 2.1). See also remark on A.2.= > MT: The anti-replay check would be as simple as possible and just like in draft-ietf-core-object-security-15. That is, sender Sequence Numbers used as Partial IVs grow only as requests are transmitted. They are not related with the occurring of a group rekeying and the consequent change of Gid (e.g., as an increment of the Epoch part). > Section 6, > > what is the relation of section 6 with with oscoap-joining. Is > oscoap-joining required to validate all the requirements of section 6? > MT: The list in Section 7 (former Section 6) has been compacted. All points but the first one are now directly related to the ace-oscoap-joining draft, which now addresses also group rekeying. > Methods to handle loss of synchronization are not responsibility of GM > but responsibility of the sender of group request messages. No total > ordering on all messages is required, only partial ordering on the > messages of a given sender. I assume that the ordering of epochs is > done by GM. > MT: We have removed the bullet on synchronization methods from the list. MT: Ordering of epochs is indeed up to the GM. > Trusted key repository: Also when the group manager makes use of an > additional secure storage device, it remains responsible for the key > repository. > MT: We have rephrased accordingly the last point in the list of Section 7 (former Section 6). > Acting as a network router is out of scope IMO. RFCs exist to create > and route group messages and it is immaterial which devices host the > routing agents. This is also a subject of appendix D; same remark > applies there as well. > MT: We have removed that bullet point from the list in Section 7 (former Section 6). > Autonomously and locally enforcing=E2=80=A6 ; what is the difference wi= th > bullet 2=C2=A0 of section 6? > MT: Thinking of the ace-oscoap-joining draft, bullet 2 meant that the GM (i.e. an ACE RS) is expected to define group access policies to be enforced by a third party (i.e. an ACE AS). The sentence you mention considers the case where there is no such third party and the GM entirely enforces access policies locally on its own. MT: In the current list in Section 7 (former Section 6), the two points have been merged into the current bullet 2. > 7.1 I don=E2=80=99t understand the remark that all group members are tr= usted. > What does that mean? IMU, They have been authorized to join a group > and are trusted per definition. > MT: We have hopefully clarified by rephrasing the last paragraph of Section 8.1 (former Section 7.1). > 7.2 Case A and Case B refer to cases in OSCORE draft? > MT: Yes, we have now recalled them explicitly in Section 8.2 (former Section 7.2) > 7.3 Does it not need an explanation how one sender belonging to two > groups with the same GID can be distinguished by a receiver that is > member of these two groups as well? The text at the end of appendix C > is not very convincing. > MT: We have slightly extended Section 8.5 (former Section 7.3), now also referred by Section 2 when introducing the Gid and the handling of possible collisions. MT: The only problem at hand is an overlap of Group IDs, which results in the recipient endpoint retrieving multiple Common Security Contexts. As per Appendix C, the way to find the right Security Context is by trial and error. Note that each attempt considers the same Sender ID associated to the client sending the request, and specified in the 'kid' parameter of the request. Also, uniqueness of Sender ID values within a given group is ensured by the responsible GM. It follows that, once found the right group and related Common Security Context, there is no risk for the recipient endpoint to confuse the sender endpoint with a different one in that group. > A.1 bullet 2; remove: =E2=80=9Ce.g. by grouping lights=E2=80=A6..=E2=80= =9D=C2=A0 (it is unknown how > large groups in one room can be, leave alone a floor) > MT: Done. > A.1 Establishments an management of security contexts: I hope that a > general key management scheme is not necessary to provide the GM with > a protocol to distribute new master secrets for the next group epoch. > MT: We don't need a whole new "general scheme". The GM can refer to one rekeying protocol in agreement with all the group members. MT: The exact protocol the GM uses to rekey the group is out of the scope of this document. An actual way to rekey the group is now provided in the ace-oscoap-joining draft. > A.2 > > Source Authentication, s/ensure/verify/ > MT: Here "ensure" is more a short equivalent of "make it possible to verify". > Message Integrity, s/ensure/verify/ > MT: Here "ensure" is more a short equivalent of "make it possible to verify". > Message ordering: Messages should be given a sequence number by the > sender, a new coap option could be defined. Total ordering of the > messages in a Group is not required. > MT: Like in draft-ietf-core-object-security-15 , each sender maintains sequence numbers, and uses them as Partial IVs included in the OSCORE option of requests and used for building the AEAD nonce. MT: Current Section 5 now points explicitly to Section 7 "Message Binding, Sequence Numbers, Freshness and Replay Protection" of draft-ietf-core-object-security-15 > > Appendix C: Could this text (or a variant) not become normative text > to provide simple source ordering. > MT: For the time being, we think it would be good to allow for different Gid structures, as defined by the application. > Appendix D: first three paragraphs double with Appendix A, just > differently formulated. Suggest to remove or better review separation > with appendix A. > MT: We have re-written Appendix D. It is now much shorter, gives only a high-level overview of a new endpoint set-up, and points at the ace-oscoap-joining draft for the actual join process. > See router comment of section 6. > MT: Done. > Appendix D.1 is very informative but provides many choices. Oscoap > join should specify the choices. According to me much of the text of > Appendix D.1 should go to oscoap-join to motivate the choices made for > oscoap join. > MT: The Appendix has been rewritten (see above). > Appendix D.2. My suggestion is to make the GM the key repository, or > connect a key repository to it, that needs to be accessed through the G= M. > MT: The Appendix has been rewritten (see above). MT: The draft now considers the GM as the key repository. > Appendix D3. Should this not be normative text in oscoap-join? > MT: The Appendix has been rewritten (see above). > Appendix E. A relation between message freshness and message ordering > is suggested that I do not understand. When a sender sends only one > message ever, the ordering is assured, but freshness is not guaranteed > on reception. > MT: A recipient endpoint can have lost synchronization with the sender's sequence number and hence not be able anymore to assert freshness by relying only on its own local anti-replay window. > Suppose only ordering is guaranteed with sequence numbers in the > message; Losing messages can be detected. A procedure to receive lost > messages is indeed necessary. But this involves storage of messages at > the sender (how many?), and possibly re-encrypting to guarantee > freshness when they are repeated on loss detection. > MT: Handling lost messages through retransmission happens like in OSCORE.= MT: We have added the new third paragraph in Section 5.1 (former Section 5) about sender endpoints storing Non-Confirmable messages to handle possible retransmissions. Details are application-specific and out of the scope of this document. > Hope this helps. MT: It really does, thanks a lot again! > > Greetings, > > peter > --=20 > Peter van der Stok > vanderstok consultancy > mailto: consultancy@vanderstok.org > , stokcons@bbhmail.nl > > www: www.vanderstok.org > tel NL: +31(0)492474673 =C2=A0=C2=A0=C2=A0=C2=A0F: +33(0)966015248 > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=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 --------------B54995C963EF72A2ACF2E6B6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Peter,

Thanks a lot for your comments! We considered them for version -03.
Please, find our answers in line.

Best,
/Marco

On 9/20/18 10:02 AM, Peter van der Sto= k wrote:

Hi authors,

Thanks for this useful document.

I have no comments on sections 3 and 4 that read rather easily.<= /p>

Some comments on the other sections follow below:

Section 1.1

Introduce group request (GR)-message and response message in relation to GR-client and GR-server to clarify text in section 2. To be used consistently throughout the text.


MT: The text actually uses the same terminology from CoAP and OSCORE, i.e. "client", "server", "sender" and "recipient", as also stated in Section 1.1. RFC7390 does not use those or similar terms.
MT: To simplify the text, we replaced "group message" with "message".

End page 3. The phrase on the use of DTLS seems a bit far-fetched; Do you mean that multiple DTLS sessions are started for each group request sent by a client?


MT: We tried to clarify by adding the last sentence "Note that DTLS cannot be used to secure messages sent over multicast." Other than that, same considerations as in OSCORE apply here.

Group ID: s/a same Group Manager/a given Group Manager/


MT: Done.

End section 1.1; remove: =E2=80=9Cby a different group member or= by a non-group-member=E2=80=9D This only excludes itself.


MT: It's actually two different cases that we are both covering. We rephrased as: "This also provides assurance that the message was not tampered with by anyone, be it a different legitimate group member or an endpoint which is not a group member".

Section 2

Where does the endpoint store all these contexts? I assume local storage is used.


MT: On this point, this document simply follows what defined in Section 7.5 of draft-ietf-core-object-security-15.

Text substitution suggestions:

s/Each endpoint in the group stores:/Each endpoint in a group makes use of:/

s/endpoints in the group/endpoints in a given group/

s/The ID Context parameter stores the group ID/The ID Context parameter contains the group ID/


MT: Done.

The Sender context description is confusing. I understood that both a client when sending a group request, and a receiver when sending a response message use the sender context for sending the message. The text seems to suggest that only a group request need a sender context and not the response message.


MT: The first interpretation you give is in fact correct. An endpoint always uses its own single sender context to secure an outgoing message, regardless if it is a request or a response. Hopefully this is clearer now that we have removed the term "group message".

If the Sender context applies only to group request messages, the term request context is more appropriate and distinguishes from the sender context in OSCORE


MT: See above.

Same confusion about the recipient context; the text seems to exclude that a group request client also needs a recipient context.


MT: An endpoint always decrypts an incoming message using its own recipient context associated to the other group member sending that message. This applies to all incoming messages, regardless if it is a request or a response.

Table 1:=C2=A0 why =E2=80=9Ceach=E2=80=9D Recipient context and = not =E2=80=9Ceach=E2=80=9D sender context?


MT: The table refers to one given endpoint, which has: i) one common context; ii) one sender context, used to secure its own outgoing messages; iii) multiple recipient contexts to process incoming messages, i.e. one recipient context for each other endpoint in the group sending such incoming messages to this recipient endpoint.

Public key of the associated other endpoint: is this the group request client endpoint or any endpoint sending to this recipient?


MT: Any other endpoint sending to this recipient endpoint.

Section 2.1:=C2=A0 should the section not refer to oscoap-joinin= g draft in ACE?


MT: The text in this section has been slightly restructured. It still gives an intuition of the issue at hand, while also pointing at the ace-oscoap-joining draft now covering also group rekeying through the Group Manager.

Section 3 =E2=80=98kid=E2=80=99 parameter value; Does this only = apply to response messages sent by group request servers?


MT: Now the text explicitly says that, unlike in OSCORE, 'kid' is always present in all messages, i.e. both requests and responses.
=

Section 5; I don=E2=80=99t think that I understand the problem. = One of the conditions is that a client which is not part of a group cannot decrypt the group messages, and a client that has left the group cannot decrypt the group messages either. That constitutes already a pretty firm synchronization. My assumption was that this would be effectuated by distributing new master secret every time the group changes. In Appendix C, you suggest the epoch in the GID (Chaging the epoch, the GID may remain constant over group changes). My recommendation is to make the epoch compulsory for synchronization purposes.


MT: These are two different aspects. Section 5.1 (former Section 5) is about enabling a late-joiner or a rebooted device to be synchronized with the sequence numbers of requests sent by other group members. Should this synchronization be lost, such a device would not be able to assert the freshness of request messages using the replay window as per Section 8.2 of draft-ietf-core-object-security-15.

MT: The epoch part of the Group ID enforces synchronization on the same Common Security Context, so that all group members have the same Master Secret, from which they can correctly derive the rest of the keying material. For the time being, we are referring to the Prefix+Epoch structure in Appendix C as an example of Gid format, since it would be good to keep the possibility to have different ones as defined by the application.

MT: We have extended Section 5.1 (former Section 5), with the new third paragraph about sender endpoints that should store their outgoing messages for an application-specific amount of time, sufficient to handle possible retransmission of Non-Confirmable messages (such as requests over Multicast).

During membership of a group, a GR-client can consecutively number its messages starting at zero every time a new epoch is started (with a new master secret as specified in section 2.1). See also remark on A.2.


MT: The anti-replay check would be as simple as possible and just like in draft-ietf-core-object-security-15. That is, sender Sequence Numbers used as Partial IVs grow only as requests are transmitted. They are not related with the occurring of a group rekeying and the consequent change of Gid (e.g., as an increment of the Epoch part).

Section 6,

what is the relation of section 6 with with oscoap-joining. Is oscoap-joining required to validate all the requirements of section 6?


MT: The list in Section 7 (former Section 6) has been compacted. All points but the first one are now directly related to the ace-oscoap-joining draft, which now addresses also group rekeying.

Methods to handle loss of synchronization are not responsibility of GM but responsibility of the sender of group request messages. No total ordering on all messages is required, only partial ordering on the messages of a given sender. I assume that the ordering of epochs is done by GM.


MT: We have removed the bullet on synchronization methods from the list.

MT: Ordering of epochs is indeed up to the GM.

Trusted key repository: Also when the group manager makes use of an additional secure storage device, it remains responsible for the key repository.


MT: We have rephrased accordingly the last point in the list of Section 7 (former Section 6).

Acting as a network router is out of scope IMO. RFCs exist to create and route group messages and it is immaterial which devices host the routing agents. This is also a subject of appendix D; same remark applies there as well.


MT: We have removed that bullet point from the list in Section 7 (former Section 6).

Autonomously and locally enforcing=E2=80=A6 ; what is the differ= ence with bullet 2=C2=A0 of section 6?


MT: Thinking of the ace-oscoap-joining draft, bullet 2 meant that the GM (i.e. an ACE RS) is expected to define group access policies to be enforced by a third party (i.e. an ACE AS). The sentence you mention considers the case where there is no such third party and the GM entirely enforces access policies locally on its own.

MT: In the current list in Section 7 (former Section 6), the two points have been merged into the current bullet 2.

7.1 I don=E2=80=99t understand the remark that all group members= are trusted. What does that mean? IMU, They have been authorized to join a group and are trusted per definition.


MT: We have hopefully clarified by rephrasing the last paragraph of Section 8.1 (former Section 7.1).

7.2 Case A and Case B refer to cases in OSCORE draft?


MT: Yes, we have now recalled them explicitly in Section 8.2 (former Section 7.2)

7.3 Does it not need an explanation how one sender belonging to two groups with the same GID can be distinguished by a receiver that is member of these two groups as well? The text at the end of appendix C is not very convincing.


MT: We have slightly extended Section 8.5 (former Section 7.3), now also referred by Section 2 when introducing the Gid and the handling of possible collisions.

MT: The only problem at hand is an overlap of Group IDs, which results in the recipient endpoint retrieving multiple Common Security Contexts. As per Appendix C, the way to find the right Security Context is by trial and error. Note that each attempt considers the same Sender ID associated to the client sending the request, and specified in the 'kid' parameter of the request. Also, uniqueness of Sender ID values within a given group is ensured by the responsible GM. It follows that, once found the right group and related Common Security Context, there is no risk for the recipient endpoint to confuse the sender endpoint with a different one in that group.

A.1 bullet 2; remove: =E2=80=9Ce.g. by grouping lights=E2=80=A6.= =2E=E2=80=9D=C2=A0 (it is unknown how large groups in one room can be, leave alone a floor)


MT: Done.

A.1 Establishments an management of security contexts: I hope that a general key management scheme is not necessary to provide the GM with a protocol to distribute new master secrets for the next group epoch.


MT: We don't need a whole new "general scheme". The GM can refer to one rekeying protocol in agreement with all the group members.

MT: The exact protocol the GM uses to rekey the group is out of the scope of this document. An actual way to rekey the group is now provided in the ace-oscoap-joining draft.

A.2

Source Authentication, s/ensure/verify/


MT: Here "ensure" is more a short equivalent of "make it possible to verify".

Message Integrity, s/ensure/verify/


MT: Here "ensure" is more a short equivalent of "make it possible to verify".

Message ordering: Messages should be given a sequence number by the sender, a new coap option could be defined. Total ordering of the messages in a Group is not required.


MT: Like in draft-ietf-core-object-security-15 , each sender maintains sequence numbers, and uses them as Partial IVs included in the OSCORE option of requests and used for building the AEAD nonce.
MT: Current Section 5 now points explicitly to Section 7 "Message Binding, Sequence Numbers, Freshness and Replay Protection" of draft-ietf-core-object-security-15


Appendix C: Could this text (or a variant) not become normative text to provide simple source ordering.


MT: For the time being, we think it would be good to allow for different Gid structures, as defined by the application.

Appendix D: first three paragraphs double with Appendix A, just differently formulated. Suggest to remove or better review separation with appendix A.


MT: We have re-written Appendix D. It is now much shorter, gives only a high-level overview of a new endpoint set-up, and points at the ace-oscoap-joining draft for the actual join process.

See router comment of section 6.


MT: Done.

Appendix D.1 is very informative but provides many choices. Oscoap join should specify the choices. According to me much of the text of Appendix D.1 should go to oscoap-join to motivate the choices made for oscoap join.


MT: The Appendix has been rewritten (see above).

Appendix D.2. My suggestion is to make the GM the key repository, or connect a key repository to it, that needs to be accessed through the GM.


MT: The Appendix has been rewritten (see above).

MT: The draft now considers the GM as the key repository.

Appendix D3. Should this not be normative text in oscoap-join?


MT: The Appendix has been rewritten (see above).

Appendix E. A relation between message freshness and message ordering is suggested that I do not understand. When a sender sends only one message ever, the ordering is assured, but freshness is not guaranteed on reception.


MT: A recipient endpoint can have lost synchronization with the sender's sequence number and hence not be able anymore to assert freshness by relying only on its own local anti-replay window.

Suppose only ordering is guaranteed with sequence numbers in the message; Losing messages can be detected. A procedure to receive lost messages is indeed necessary. But this involves storage of messages at the sender (how many?), and possibly re-encrypting to guarantee freshness when they are repeated on loss detection.


MT: Handling lost messages through retransmission happens like in OSCORE.

MT: We have added the new third paragraph in Section 5.1 (former Section 5) about sender endpoints storing Non-Confirmable messages to handle possible retransmissions. Details are application-specific and out of the scope of this document.

Hope this helps.

MT: It really does, thanks a lot again!


Greetings,

peter
--
Peter van der Stok
vanderstok consultancy
mailto: consultancy@vande= rstok.org, stokcons@bbhmail.nl
www: www.vanderstok.or= g
tel NL: +31(0)492474673 =C2=A0=C2=A0=C2=A0=C2=A0F: +33(0)966015= 248

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

____________________________=
___________________
core mailing list
core@=
ietf.org
https://www.ietf.org/mailman/listinfo/core


--=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
--------------B54995C963EF72A2ACF2E6B6-- --spS6n55020iR20htThQDENPPukal2TCAZ-- --BywBIX1sslxAqy1bSqEkJJs9495ZT3870 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAlvQfSkACgkQ7iZktA5Y 2kOzJggAoDftNXo+Aw5KxjKAUlcXAu7KB+8noChLXDyCovfsMieobC0UgjxVyqln 7ZJBVWkUC1cSR/56JJ02uI9VxBb/TGeMlJzpd53/w8vUVbQEI5SzyHT147cZkPfX k1bO9FWJ2wXYrRbGBtwLVAnhAAye0Johex0A+uuKVVv8uO7PKgW+jbsTJZRgsIlY bdAc1yEMg35STnkXcuZzJTqRAMXGySHR35eCiah0u963ZeZiGWm7BlHOmRzjgDaC 4mGog+RZZmbq59OQieAj0ImZxM7OkiLKd14ZNozHwjoNSNYXVyQG8XXmKZ0+f3kr hgbPUGAD+0MYWsCTlddZbH54cXM88Q== =ffxS -----END PGP SIGNATURE----- --BywBIX1sslxAqy1bSqEkJJs9495ZT3870-- From nobody Wed Oct 24 11:20:36 2018 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 89F8B12777C; Wed, 24 Oct 2018 11:20:35 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 hu4X0nFNNAZv; Wed, 24 Oct 2018 11:20:33 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25AE4124C04; Wed, 24 Oct 2018 11:20:32 -0700 (PDT) Received: from Jude (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 24 Oct 2018 11:15:21 -0700 From: Jim Schaad To: 'Ludwig Seitz' , CC: References: <065b01d45f4e$b8d372a0$2a7a57e0$@augustcellars.com> <028d01d46a3a$bc6414f0$352c3ed0$@augustcellars.com> <038001d46b00$767a8520$636f8f60$@augustcellars.com> <0e01455c-4337-c51a-c199-fd5b56cf717d@ri.se> In-Reply-To: <0e01455c-4337-c51a-c199-fd5b56cf717d@ri.se> Date: Wed, 24 Oct 2018 11:20:01 -0700 Message-ID: <00b001d46bc6$2f9fde90$8edf9bb0$@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: AQJ+t/TOEyNDXiHpy0JlO2vTIlTnzAJjpp42AY2H+FoCbDZgzwL8GF23o49PCGA= Content-Language: en-us X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [Ace] WGLC for draft-ietf-ace-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 18:20:36 -0000 > -----Original Message----- > From: Ludwig Seitz > Sent: Wednesday, October 24, 2018 2:02 AM > To: Jim Schaad ; draft-ietf-ace-oauth- > authz@ietf.org > Cc: ace@ietf.org > Subject: Re: [Ace] WGLC for draft-ietf-ace-authz >=20 > On 23/10/2018 20:44, Jim Schaad wrote: > > >=20 > > > > > >>> * Section 6 - I am not sure that I agree with the SHOULD NOT in = the > >>> last paragraph. Think multicast. > >> Any suggestions on how to mitigate the issue then? If I issue a = token > >> bound to a symmetric key for audience {R1, R2, R3}, as soon as R1 = got > >> this token it can impersonate the client and gain access to R2 and > >> R3. > > > > I am not sure that I think this is an issue that needs to be > > mitigated. It needs to be acknowledged, but the assumption would be > > that if you have three resource servers that are hosting the same > > audience they are going to be run by the same RO and already be > > coupled. After all it should not matter which of them you do a GET > > from, you should get the same answer. Similarly a PUT to one should > > propagate to the others so that it is available to all clients. > > >=20 >=20 > Say the client is a cleaning service and the audience is the locks of = the > different apartments it is allowed to open. >=20 > If the token uses symmetric keys, as soon as the cleaning service = sends the > token to one apartment, this apartment can open the other apartments. = This > is the situation I want to avoid. I would not expect that the locks would all be a single audience. You = might have all of the locks in a single apartment be one audience but = you would want to separate the apartments into different security = groups. The cleaning service should be required to obtain a token = specific to an apartment and not generally for all apartments. If you have a situation where a single audience encompasses multiple = security objects that are to be controlled differently then you run = across the problem that Stefanie was raising where you cannot know which = RS to make the token for because you are now needing to map audience, = scope and actions all to a different RS which seems to be defeating the = purpose of having an audience.=20 Jim >=20 > /Ludwig >=20 >=20 >=20 > -- > Ludwig Seitz, PhD > Security Lab, RISE > Phone +46(0)70-349 92 51 From nobody Wed Oct 24 13:49:40 2018 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 76951130E13 for ; Wed, 24 Oct 2018 13:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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=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 g5ZruuQYGMEI for ; Wed, 24 Oct 2018 13:49:34 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-dm3nam06on0709.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe56::709]) (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 4C3E4128B14 for ; Wed, 24 Oct 2018 13:49:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jILfqa01XNAcEldprHtGRR/jVTv3hNCY3OFM/5woE9A=; b=AgANYcR2JftzBY/9tccDdfNPGpcoDVd1Lo2W/0Rfdo1QpUYUSLhs3o1nyGJuoOoi1cnIU8Cl1CVRN0Luc46NHd78E0UyiAsMenHqehIUrj888HRN9GUkfrHrheSsxVGYA4Bc38IyGf/CTByazVxGloAOk0eIprjGKvHefzuvdhs= Received: from SN6PR00MB0301.namprd00.prod.outlook.com (52.132.117.155) by SN6PR00MB0320.namprd00.prod.outlook.com (52.132.118.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1314.0; Wed, 24 Oct 2018 20:49:32 +0000 Received: from SN6PR00MB0301.namprd00.prod.outlook.com ([fe80::e9dc:6f27:e9b3:a5b6]) by SN6PR00MB0301.namprd00.prod.outlook.com ([fe80::e9dc:6f27:e9b3:a5b6%3]) with mapi id 15.20.1313.000; Wed, 24 Oct 2018 20:49:32 +0000 From: Mike Jones To: Jim Schaad , "ace@ietf.org" Thread-Topic: [Ace] WGLC for draft-ietf-ace-oauth-params Thread-Index: AdRfTjn+qfbLUnxrRYOILLAcZZbLowMimzCg Date: Wed, 24 Oct 2018 20:49:32 +0000 Message-ID: References: <065d01d45f4e$bc227690$346763b0$@augustcellars.com> In-Reply-To: <065d01d45f4e$bc227690$346763b0$@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_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-10-24T20:49:29.7808803Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [64.71.18.60] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR00MB0320; 6:gCITnkpGEoZ4q550cNddetOa2gHKRf+d1UmqIh6pFZ0f6SXHSCGWRkqEIcq9cSYggEYJipXVuHKetmUJuBdZOUJIt0HlNxkZOlpprpn212npxZMtW5kYEs0/MD03QTvvJNS5bMGNBsX/QVmljEm/qtJ9mzsYOVXjxtX1wgoDcO7r4DtMNkcSNCuUTF9KmxiMs3gk3ZaLT1/I+qQHxrqjVKflP9wvgGRUuc28e504r20lEWS6rJYbBt0EB/3Y4mBzq54fDqZCcYuHHKo6dG7gUyT7WpbOzLkLUCF90wgdf8BlrsPCFZX/mr9wN5tPQKGd141QR4WNjN6S18PrCIQOEpqjfqqJqK/5f0xJrIzL6UoP8YCNGoXPEd9BZiA34T/4f5zJ7MLTQtSVmkgsNMa1uMQaGqQBNzh77H1cBPy0s2m+NjAhMy8Ag+iuVJMlNArEgE2nG5frFNE2bgdnA9T4CA==; 5:5NJ17f/+I1hjWdEydXe45G9VkEptrqipxeUcWFmVYD9CKO2tclXbI2gX3TXYnC/2o2x5G3wnkZ+FHjdqyeOIUTiZVU7OzQpqfh0XxtUSHvmz/g/lc269ao7MtO/pL7ovyTOs6mClKmSbDmTqtPSdo5QWrNCHiTQJPh13fuM6j/0=; 7:H5G6OndpCGeOdFd1CTbTRuhKvb00019V2f2uh8yjHYf8kaCiMM+VFYLT2UWwNf7r2JNTqCVrYHxFIMVn0VpjADnBDXvIILLM61PegKuwM+OShnE9slwQnoZwz+jqGO256J7M28cqNsaXetq2YdJFvA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 131dacea-97f6-48eb-c75f-08d639f23324 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7193020); SRVR:SN6PR00MB0320; x-ms-traffictypediagnostic: SN6PR00MB0320: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155)(28532068793085)(190501279198761)(227612066756510); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(8220027)(2401047)(5005006)(8121501046)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(10201501046)(93006095)(93001095)(3002001)(3231355)(944501410)(52105095)(2018427008)(6055026)(148016)(149066)(150057)(6041310)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:SN6PR00MB0320; BCL:0; PCL:0; RULEID:; SRVR:SN6PR00MB0320; x-forefront-prvs: 083526BF8A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(376002)(366004)(346002)(136003)(13464003)(199004)(189003)(22452003)(99286004)(110136005)(316002)(76176011)(6346003)(6506007)(7736002)(53546011)(10290500003)(74316002)(2900100001)(6116002)(102836004)(790700001)(3846002)(26005)(14454004)(71200400001)(8676002)(72206003)(71190400001)(5250100002)(86362001)(8936002)(2501003)(81156014)(97736004)(7696005)(68736007)(81166006)(966005)(229853002)(86612001)(6436002)(66066001)(256004)(54896002)(6306002)(106356001)(53936002)(9686003)(236005)(55016002)(14444005)(105586002)(8990500004)(5660300001)(33656002)(606006)(6246003)(186003)(478600001)(10090500001)(2906002)(446003)(486006)(11346002)(25786009)(476003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR00MB0320; H:SN6PR00MB0301.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) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-message-info: piV39GPLgQ+c6seCEt2uV9f8QBS7WnSjx6/Gu1UHh4rH39D8J30Du9Vumjjzoh4Wzj6of37r9l5lSi+zM9iPv5cmnkIvBNJ2bKGEiCz0gQ3spiHE/RDs1+3xTKLGXme97NWjL8K38LYbXjUereV0yYoQhQElwXTet/NvwafDN4cA7oGGNlsVTADrv2iXKlItIjB6SM6TYkt6FSFIX6f8i7heYPzd2uflJQ+LR8E8c1RIvsT4syvVKbPvOLQT59spUaYT4W+hMkfpGbW7az23H00IyF6NY3QrPXtGcw+BTBO9AkTe52FahUC+sxxMeX2ZbAce7KzzUP0UwnANgv6bT/Qef3V3U2drJIrxCCzns0A= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN6PR00MB0301ABCD934F20361EB6A02DF5F60SN6PR00MB0301namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 131dacea-97f6-48eb-c75f-08d639f23324 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Oct 2018 20:49:32.1480 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR00MB0320 Archived-At: Subject: Re: [Ace] WGLC for 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: Wed, 24 Oct 2018 20:49:39 -0000 --_000_SN6PR00MB0301ABCD934F20361EB6A02DF5F60SN6PR00MB0301namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 3.1, 3.2, and 4.1, parameter definitions: None of these parameter definitio= ns specify the syntax of the parameters defined, making understanding these= quite confusing. Yes, this is talked about later in the doc but there are= not even forward references to where the definitions are completed in most= cases. Please fully specify the parameters when they are defined. 3.1 req_aud: Doesn't this duplicate the "resource" parameter defined by htt= ps://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-01? If so, p= lease delete this parameter. If not, say how it is different and why the d= ifferences are necessary. 5 cnf in the introspection response: Which token is being referred to by th= e phrase "bound to the token". The access token? The refresh token? Anot= her kind of token? Please make this more specific. 6 CBOR Mappings. The table contains the magic numbers 8, 17, 18, and 19. = >From what space are these numbers being allocated and what registry are the= y in? Per my earlier reviews of the ace-authz spec, I believe that the ACE= OAuth parameters should all be registered in the CWT Claims registry becau= se of the possibility of them being used in signed requests in a manner ana= logous to https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17. The para= meters need to be registered to avoid claim number conflicts. Missing Examples: The best thing you could do to help developers understan= d what these values are and how they use them is to add examples, just as w= as done in RFC 7800. Please add examples of each of the parameters using t= he JSON representations of them. Optionally, also add CBOR examples if you= believe that they will convey important information to developers that the= JSON example's don't. Thank you, -- Mike -----Original Message----- From: Ace On Behalf Of Jim Schaad Sent: Monday, October 8, 2018 2:35 PM To: ace@ietf.org Subject: [Ace] WGLC for draft-ietf-ace-oauth-params The chairs believe that the set of documents dealing with the OAuth framewo= rk for constrained environments is nearing the point that we should be able to advance it to the IESG for publication. We therefore want to have a full list of issues that need to be dealt with at the Bangkok meetin= g. This starts a 2 week WGLC for draft-ietf-ace-oauth-params We know that the following issues are outstanding: draft-ietf-ace-oauth-params: * No current known issues Jim & Roman _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace --_000_SN6PR00MB0301ABCD934F20361EB6A02DF5F60SN6PR00MB0301namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3.1, 3.2, and 4.1, parameter definitions: None of= these parameter definitions specify the syntax of the parameters defined, = making understanding these quite confusing.  Yes, this is talked about= later in the doc but there are not even forward references to where the definitions are completed in most cases.&n= bsp; Please fully specify the parameters when they are defined.<= /p>

 

3.1 req_aud: Doesn’t this duplicate the = 220;resource” parameter defined by https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-01?  If so, please delete this parameter.  If not, say how it is d= ifferent and why the differences are necessary.

 

5 cnf in the introspection response: Which token = is being referred to by the phrase “bound to the token”.  = The access token?  The refresh token?  Another kind of token?&nbs= p; Please make this more specific.

 

6 CBOR Mappings.  The table contains the mag= ic numbers 8, 17, 18, and 19.  From what space are these numbers being= allocated and what registry are they in?  Per my earlier reviews of t= he ace-authz spec, I believe that the ACE OAuth parameters should all be registered in the CWT Claims registry because of the possibi= lity of them being used in signed requests in a manner analogous to https://= tools.ietf.org/html/draft-ietf-oauth-jwsreq-17.  The parameters ne= ed to be registered to avoid claim number conflicts.

 

Missing Examples:  The best thing you could = do to help developers understand what these values are and how they use the= m is to add examples, just as was done in RFC 7800.  Please add exampl= es of each of the parameters using the JSON representations of them.  Optionally, also add CBOR examples if you b= elieve that they will convey important information to developers that the J= SON example’s don’t.

 

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            Thank = you,

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            -- Mik= e

 

-----Original Message-----
From: Ace <ace-bounces@ietf.org> On Behalf Of Jim Schaad
Sent: Monday, October 8, 2018 2:35 PM
To: ace@ietf.org
Subject: [Ace] WGLC for draft-ietf-ace-oauth-params

 

The chairs believe that the set of documents deal= ing with the OAuth framework for constrained environments is nearing the po= int that we should

be able to advance it to the IESG for publication= .   We therefore want to

have a full list of issues that need to be dealt = with at the Bangkok meeting.

 

This starts a 2 week WGLC for draft-ietf-ace-oaut= h-params

 

We know that the following issues are outstanding= :

 

draft-ietf-ace-oauth-params:

*  No current known issues

 

 

Jim & Roman

 

 

 

_______________________________________________

Ace mailing list

Ace@ietf.org

https://www.ietf.org/mailman/list= info/ace

--_000_SN6PR00MB0301ABCD934F20361EB6A02DF5F60SN6PR00MB0301namp_-- From nobody Wed Oct 24 17:58:20 2018 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 7079B1292AD for ; Wed, 24 Oct 2018 17:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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 ftixdDgKfOP8 for ; Wed, 24 Oct 2018 17:58:13 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-bl2nam06on0118.outbound.protection.outlook.com [104.47.53.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DC67129BBF for ; Wed, 24 Oct 2018 17:58:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1CDj8Fc62rJXX2L3bcL51izz6m7O4bC+1hMoG4PmwUo=; b=jTqrD2cpgC9HBQViV1/gZKc5PWm7t+/b3NgTbKYxgkNhEdnGWCo0uIBUerfxrMj3u5DKA7d16qKFxuzeLD6F5RHK/5ab0B7/3qDD0ASeERnS6jL7P9XtO72vaSW0pFqfXg8t7kfkZsfeOzoeXc7hcLDrBylLIT47cbI5EVPoSm4= Received: from SN6PR00MB0301.namprd00.prod.outlook.com (52.132.117.155) by SN6PR00MB0349.namprd00.prod.outlook.com (52.132.118.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1312.0; Thu, 25 Oct 2018 00:58:11 +0000 Received: from SN6PR00MB0301.namprd00.prod.outlook.com ([fe80::e9dc:6f27:e9b3:a5b6]) by SN6PR00MB0301.namprd00.prod.outlook.com ([fe80::e9dc:6f27:e9b3:a5b6%3]) with mapi id 15.20.1313.000; Thu, 25 Oct 2018 00:58:11 +0000 From: Mike Jones To: Jim Schaad , "ace@ietf.org" Thread-Topic: [Ace] WGLC for draft-ietf-ace-authz Thread-Index: AdRfTbZXRdy06+geSTKJtOzYofxg+gMqrfqQ Date: Thu, 25 Oct 2018 00:58:10 +0000 Message-ID: References: <065b01d45f4e$b8d372a0$2a7a57e0$@augustcellars.com> In-Reply-To: <065b01d45f4e$b8d372a0$2a7a57e0$@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_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-10-25T00:58:09.0382471Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [64.71.18.60] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR00MB0349; 6:DV9W9EElv2DNWdFLmToCAX7mwZGuktp5w0vUMDcLo/vbx/UE4w/gbQyj4wBgBBapLYqoRTr/1DUWnZfwyuQDhZ5bTnBh1+m/90ReMuk4uSncnHaAhXISDgGFIRk5HocGejijX1cCCihlyDxzg/N5S2rOQW+FinR5Ose71SmA8mQD5ZCET/GtCW/IxtktdXNMY6jIK/cmecw7hTC4/9dm24y/daJlYI4gUyXnr/pf3aN08d8677RJH4yelJ3uF5R7wEG9dJ7MVxAaUGaoC44XsMijZY5JEa7sDVw5eqczgRIi0VCfRSRdADALSeaHFvoUiFtrJsAF88BYBD766JRkdiODUHv9VppDJ7VSktBLLyMWnT3fo/dVrsVGccMkWyxutWmvMUqqmQY50V4XtQf8Lb/g0m/5ieYp+hVE8I80dA+lAGhqFzbgbfwkrBND0cHR4LWFq2BHAdvAzocLFM48sg==; 5:4VTeyEKTdHQtaubp545IFHkR7wMTZKnyihes6GgBVFfKIJBYUP+zlBAvC8ES2slYgMYnnhZmum0qjyjkW+zdQAwEFNt0QHwfle5Agiw8TJGPTPKEg6eEdg157dkPMpahchuhcdkk/D31bJreCTfgk9GmRVk3XcuJaKGWOStAa2s=; 7:mJi8e7gvzBpA4F69/kT2cHALIDWXdDQuHaGkAqLKxHAYF4bhtoySTOl29ji3QGMDXrobFpJAhcvajElooco0vFtZ+bOXcHTp9SVCW5LK7sui3/x2jlRnecJw+lJ10/P41rgjJ3rM+5+g2HduqU2odQ== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: a90cf635-9e69-4aec-9b4b-08d63a14ef89 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:SN6PR00MB0349; x-ms-traffictypediagnostic: SN6PR00MB0349: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(1591387915157); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(8220027)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(93006095)(93001095)(10201501046)(3231355)(944501410)(52105095)(2018427008)(3002001)(6055026)(148016)(149066)(150057)(6041310)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:SN6PR00MB0349; BCL:0; PCL:0; RULEID:; SRVR:SN6PR00MB0349; x-forefront-prvs: 083691450C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(396003)(376002)(366004)(39860400002)(13464003)(199004)(189003)(5660300001)(10290500003)(33656002)(8990500004)(7736002)(74316002)(305945005)(478600001)(14454004)(966005)(72206003)(25786009)(106356001)(10090500001)(2501003)(8936002)(6246003)(8676002)(68736007)(81156014)(81166006)(2900100001)(97736004)(53936002)(9686003)(6436002)(55016002)(99286004)(14444005)(256004)(71200400001)(71190400001)(105586002)(5250100002)(86612001)(476003)(6306002)(11346002)(446003)(53546011)(186003)(26005)(6506007)(7696005)(110136005)(76176011)(6116002)(486006)(102836004)(86362001)(2906002)(22452003)(316002)(3846002)(66066001)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR00MB0349; H:SN6PR00MB0301.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-microsoft-antispam-message-info: VZ6rt/9fuAG+TDihvG8VmqTsVzx1K7oKXq+iIW1b54AkID6uxT+DIOqMwNvggx7NZMTyKzi8DvtCjLjZdS4++O+ELbBYVs14CV8kcIdWy/eKTjvz3XOurtEQKcmW1OAAsdNMUwaarQRG26lS9ZbbHMCWU/DSFe5vVg4qfEv/moWJPgeCKQ8Wg6TF+58UEYv7ZhLaf2FMO6ZL7ZTaKShmCWvGFSgKfVBguMgVAR6cGwdZBt/9Pv7Clmww2MxdoyiYWHf55d9pDz+QnqfquXRmlIUh1+vG5GDWHE/6/sMv+vFf4NV+i8EYb/42ZR6WbOU1/ZqKg9hfdYKE+V8tMUTInJY0yWlyvoBH4q6YrAEHVQM= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: a90cf635-9e69-4aec-9b4b-08d63a14ef89 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2018 00:58:11.0202 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR00MB0349 Archived-At: Subject: Re: [Ace] WGLC for draft-ietf-ace-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 00:58:19 -0000 IT CAN'T BE A COINCIDENCE: There's clearly a relationship between many of = the CBOR numeric values used in this this specification and corresponding C= BOR Web Token (CWT) claim identifiers, but oddly, the relationship is curre= ntly unspecified and the goals behind it are undefined. The spec should be= augmented to make the nature and goals of this relationship explicit. I i= nfer that there's such a relationship because the Mapping Parameters to CBO= R in Section 5.6.5 apparently carefully do not overlap with the values regi= stered in the IANA CWT Claims registry at https://www.iana.org/assignments/= cwt/cwt.xhtml. The Introspection mappings in Section 5.7.4 apparently care= fully use the same values as CWT for the same things, but then adds additio= nal values. And some of these values are the same as values proposed for t= he CWT Claims registry in 8.13. This has to be more than a coincidence but= the spec doesn't currently say why. Per my earlier reviews of the ace-authz spec, I believe that the ACE OAuth = parameters should all be registered in the CWT Claims registry because of t= he possibility of them being used in signed requests in a manner analogous = to https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17. The parameters = need to be registered to avoid future claim number conflicts. While confli= cts have clearly been carefully avoided to date, they will inevitably occur= in the future unless the values are actually registered. Please do so. DON'T SQUAT ON NUMERIC REGISTRY VALUES: Please change all instances of num= bers to be assigned by designated experts in existing registries from speci= fic values to "TBD". For instance, all the values for the CWT Claims Regis= try in Section 8.13 (currently 12, 16, and 17) should be changed to TBD. O= ur chair, Jim Schaad has been a vigorous advocate of not squatting in my pa= st interactions with him as a Designated Expert and I believe would support= this request. Likewise, the "19" in the CoAP Content-Format Registration = in Section 8.15 should become TBD. req_aud: Several examples use the "req_aud" parameter without defining it. = Doesn't this duplicate the "resource" parameter defined by https://tools.i= etf.org/html/draft-ietf-oauth-resource-indicators-01? If so, please delete= this parameter and use "resource". If not, say how it is different and wh= y the differences are necessary. rs_cnf: There isn't a clear normative definition of this parameter. It's = mentioned obliquely but its purpose, syntax, and semantics should be plainl= y stated (as with each other newly defined parameter). The proposed numbers in Figures 12 and 16 contain mismatches. For instance= , token_type is "14" in Figure 12 in Section 5.6.5 and "13" in Figure 16 in= Section 5.7.4. There's too much alignment for it to be a coincidence but = if you intend alignment, please say so explicitly and fix the alignment. T= he proposed ongoing alignment should also be described in the registration = instructions for the Designated Experts. -- Mike P.S. Per my earlier reviews of this specification, in my view as a Designa= ted Expert for the CWT Claims registry, I believe that it's not appropriate= to use up rare single-byte identifiers for most of the OAuth parameter enc= odings specified in 5.6.5. I could be persuaded that "scope" merits one of= these rare numbers, but "profile", "error", "grant_type", "access_token", = and "token_type" probably do not, as they are application-specific and not = of general applicability. I also believe that some of the other Designated= Experts for this registry agree with me. -----Original Message----- From: Ace On Behalf Of Jim Schaad Sent: Monday, October 8, 2018 2:35 PM To: ace@ietf.org Subject: [Ace] WGLC for draft-ietf-ace-authz The chairs believe that the set of documents dealing with the OAuth framewo= rk for constrained environments is nearing the point that we should be able to advance it to the IESG for publication. We therefore want to have a full list of issues that need to be dealt with at the Bangkok meetin= g. This starts a 2 week WGLC for draft-ietf-ace-authz We know that the following issues are outstanding: draft-ietf-ace-authz * There are a couple of esoteric issues around listing AS servers associat= ed with resources in a Resource Directory Jim & Roman _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Wed Oct 24 22:34:28 2018 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 67F7A12D4E6 for ; Wed, 24 Oct 2018 22:34:27 -0700 (PDT) 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] 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 pEAtrNiKsJFB for ; Wed, 24 Oct 2018 22:34:26 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EB3A130E1E for ; Wed, 24 Oct 2018 22:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w9P5Xdqg005440; Thu, 25 Oct 2018 07:33:44 +0200 (CEST) Received: from [192.168.217.102] (p54A6CA9F.dip0.t-ipconnect.de [84.166.202.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 42gbQC0gfnz1Bqf; Thu, 25 Oct 2018 07:33:39 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Thu, 25 Oct 2018 07:33:38 +0200 Cc: Jim Schaad , "ace@ietf.org" X-Mao-Original-Outgoing-Id: 562138416.779465-350b3d1e83ea0c9025960d5ffd94e33b Content-Transfer-Encoding: quoted-printable Message-Id: <3B32C31E-11C3-4808-82DC-3C75C949A0E9@tzi.org> References: <065b01d45f4e$b8d372a0$2a7a57e0$@augustcellars.com> To: Mike Jones X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Ace] WGLC for draft-ietf-ace-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 05:34:27 -0000 +1 for making all the CWT-like structures into real CWTs. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Oct 25 01:45:59 2018 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 9427D130E18 for ; Thu, 25 Oct 2018 01:45:56 -0700 (PDT) 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, 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 PgxJBsG4Ij1E for ; Thu, 25 Oct 2018 01:45:54 -0700 (PDT) Received: from smtp.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 06AFA12F1AC for ; Thu, 25 Oct 2018 01:45:54 -0700 (PDT) Received: from wangari.tzi.org (dynamic-218-j.informatik.uni-bremen.de [134.102.218.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 52159206D9; Thu, 25 Oct 2018 10:45:52 +0200 (CEST) From: Olaf Bergmann To: Carsten Bormann Cc: Mike Jones , Jim Schaad , "ace\@ietf.org" References: <065b01d45f4e$b8d372a0$2a7a57e0$@augustcellars.com> <3B32C31E-11C3-4808-82DC-3C75C949A0E9@tzi.org> Date: Thu, 25 Oct 2018 10:45:52 +0200 In-Reply-To: <3B32C31E-11C3-4808-82DC-3C75C949A0E9@tzi.org> (Carsten Bormann's message of "Thu, 25 Oct 2018 07:33:38 +0200") Message-ID: <877ei6tnwf.fsf@tzi.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ace] WGLC for draft-ietf-ace-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 08:45:57 -0000 Carsten Bormann writes: > +1 for making all the CWT-like structures into real CWTs. Not every key/value-pair encoded as CBOR is automatically a CWT. What happens here is that we are trying to force every protocol element that is required to solve an application-specific problem to fit into existing registered OAuth elements. As already pointed out by Mike, this does not work well because ACE is different from vanilla OAuth. The best solution I can imagine to conserve precious number space is to use the media type (Content-Format in CoAP) as differientiator and use CWT-numbers only for things that are CWTs Gr=C3=BC=C3=9Fe Olaf From nobody Thu Oct 25 04:46:48 2018 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 8E26C130E3D for ; Thu, 25 Oct 2018 04:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.77 X-Spam-Level: X-Spam-Status: No, score=-4.77 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 header.b=Zdq/z5I6; dkim=pass (1024-bit key) header.d=ericsson.com header.b=Wf66IKg+ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cxSwIp81G6J for ; Thu, 25 Oct 2018 04:46:44 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 EB75C1286E3 for ; Thu, 25 Oct 2018 04:46:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1540468001; x=1543060001; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=bHmH815DWauc4hS6ozbnA9xsY2caxrA/caW+htYaukI=; b=Zdq/z5I6NThOK2/EM95bTrTAiv7a22FDoVb40BaIzAH3LMbSrNMWbEA+25LyGcHe skC5tWUv0TnmQ0Cl6ukpiZfgu4TyXJo4gvre3GsJSp3qxU/h4AssSA3C16RrueWG q5vf+HncqmQZ8LKXISJzSVR/6jj3Y3Uc536+e3Q1uGI=; X-AuditID: c1b4fb30-1ebff70000007d19-18-5bd1ad204222 Received: from ESESBMB504.ericsson.se (Unknown_Domain [153.88.183.117]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F1.03.32025.02DA1DB5; Thu, 25 Oct 2018 13:46:41 +0200 (CEST) Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 25 Oct 2018 13:46:40 +0200 Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 25 Oct 2018 13:46:40 +0200 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=bHmH815DWauc4hS6ozbnA9xsY2caxrA/caW+htYaukI=; b=Wf66IKg+HJRwYUZrUhtW5iBSxXRQIjkbM/RKKcERdbK8y+tjWajmeuerxOqXXoEQuuDjet+Dp7u7wDhbP1uYrK8Aslna3jALuYBOaZP3Z1+it2LwawkwhP35IEzYm9CPp5kuA7ibcr9LELaPzqH4BvFcYuXpTexxIfMSptXFalw= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.188.140) by HE1PR0701MB2219.eurprd07.prod.outlook.com (10.168.36.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1273.14; Thu, 25 Oct 2018 11:46:39 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::c05a:fd61:6104:51e5]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::c05a:fd61:6104:51e5%6]) with mapi id 15.20.1273.019; Thu, 25 Oct 2018 11:46:39 +0000 From: Francesca Palombini To: Jim Schaad , "draft-ietf-ace-oscore-profile@ietf.org" CC: "ace@ietf.org" Thread-Topic: [Ace] WGLC for draft-ietf-ace-oscore-profile Thread-Index: AdRfTqcrNFwepW1pRaiIJNs5VwRdUAK7AUGAAIueqwA= Date: Thu, 25 Oct 2018 11:46:39 +0000 Message-ID: <45F876B9-6BF8-448B-9EFF-28609FC8A805@ericsson.com> References: <065a01d45f4e$b738ae60$25aa0b20$@augustcellars.com> <028c01d46a3a$ae1b9e40$0a52dac0$@augustcellars.com> In-Reply-To: <028c01d46a3a$ae1b9e40$0a52dac0$@augustcellars.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [217.31.165.122] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2219; 6:/gzwH3bCJ/5BBeZ5ITvS3ilKvDIT+kOJRAfZK3L1mRiUd9SAxuEEpnBR837jb1Fmss2yGYchlangzWNPToRmPc4KQdSntMHUxqU/01o+/ir7i0GKlFnzPH97AKlhXQ7q5YCqCGkL0Tq9Uz1mIe3ZwJOihz0QvDr3CM5o7WVcXwRyyibZcAZ7IhOs483YazRtkgQedHnEUzsv4Kdn5ufCjm/rEcVBNl9wp8WHIzvf+F+EiqxX1v002/hcd5XRprh9fU62l+K452smg1jDRBoz+LPdbz6JGrIEgGxoFEr0jxSTlyjIvD+5BNmw6agSOuJZIrkhHAcjBK64kvrGHd5+0YqPVYEshfFLS4EldEBY6DV/Rf/d6H6a9TYvkyBff3Km+HJPHxLD6CQI3+OLMbh/aNiUlLzdFbIqNai9C2FhLHrGEmEt+uMP5iMMDTJ5QY4w1JpWOFCtScD3fZSt3D4N5g==; 5:u8bwu0xHtpPyMwbn/VxV9iyNdX53Y0lKpI1VoHXjpalmlXHWAsvupOdzwKkIMiRWvD5iaKkZiWSJLxd+ZdMU2TVIq0AfnUx2qYsWzzxJCppKj8aYdL4nRWSBoCE6DaqAJRHoLuyGUpfcRn080PTfTYnDja2XoeYjorApxj7i+/Q=; 7:vPwem7vt20eMOOU3I++6CsS4jTXgVY5HPltWw6Hcv9uRb8hXMgqDbjJcERZMJrQNKkRj20jUL1Dpm0Ye0hXKL5uwWOJT7nCpD6HkL6OGcsDrdachzdeQbpLG2XeMi1UoX295037s7bwB2+uanqHOXQ== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 34705049-accf-4b4e-59f6-08d63a6f86d7 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:HE1PR0701MB2219; x-ms-traffictypediagnostic: HE1PR0701MB2219: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(158342451672863)(192374486261705)(788757137089); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231355)(944501410)(52105095)(148016)(149066)(150057)(6041310)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:HE1PR0701MB2219; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2219; x-forefront-prvs: 083691450C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(346002)(396003)(39860400002)(366004)(199004)(189003)(51444003)(13464003)(82746002)(486006)(476003)(7736002)(2616005)(229853002)(5660300001)(966005)(2900100001)(105586002)(33656002)(106356001)(5250100002)(6506007)(86362001)(53546011)(2501003)(102836004)(305945005)(6512007)(6306002)(6246003)(26005)(53936002)(97736004)(446003)(11346002)(44832011)(256004)(14444005)(8676002)(99286004)(8936002)(81166006)(14454004)(3846002)(478600001)(81156014)(76176011)(345774005)(6486002)(4326008)(186003)(68736007)(6116002)(6436002)(2906002)(36756003)(25786009)(66066001)(71190400001)(71200400001)(316002)(110136005)(83716004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2219; H:HE1PR0701MB2746.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-microsoft-antispam-message-info: Y0HaS2+euAV0BpYT+hlVLgPsVaF3tB/wvnbazJwwS2WOfo5xhUaSCrsqqbd7nnHJcANlyZH2tEqwnmyesEIPCmTr325pvAOOUWMHIF2o6WijuiHr9pt0lIc0c/R5NWW/WrmeDAX/RTKczWQNuyulnc2jmCnzkvlYoxatzJTgX3haHcsiEAMfd8oZGyi1+9CfS7NGFhfvwGF2lAWkTa0BW5eQFdMjK1J1klifDVs4Yos0J2qf2lClEOfe7indMU1Tj6aL6a4V8gtzl2SaXszuvVA/TUKBeateMIjrRi/BxSpFj+27tgksnN9PU8mUjTFyqbkhKFAZxusQMcn46CuZhFn6jt1lIv/fHIig5Neqqoc= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <83298B3490A2E345AF59CCF8CC9B98C3@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 34705049-accf-4b4e-59f6-08d63a6f86d7 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2018 11:46:39.6353 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2219 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEKsWRmVeSWpSXmKPExsUyM2J7qa7i2ovRBruNLb5/62G2eLqtg9li 9fTvbA7MHhvnTGfzWLLkJ1MAUxSXTUpqTmZZapG+XQJXxvY9AgXrjCuerlVsYGwx6mLk5JAQ MJE4/GshSxcjF4eQwFFGiWWrm9khnG9Azo2ZjBDOEiaJuwfuMoM4LAITmCV6fi9mhcjMYJLo 2XUGquwZo8T6f2vZQSazCdhIXHj4nhXEFhGok7j/fjMLiM0soCixbk4fE4gtLGApcfP6Y0aI GiuJRT0zWGDsHU0PweawCKhK3Dx8mg3E5hWwl7h9cwKYLSRQKnHj+QOw+ZwCDhJz/m0Fm8ko ICvxpXE1M8QucYlbT+YzQXwqILFkz3lmCFtU4uXjf6wQ9ckSV273sUPElSQu/VkIVSMrcWl+ N9hjEgI32CROXDvNCpHQlfgwdSpUka/E7bVLoBacZJT43ZTYxcgBZOtIzD+kARHOl5jd2gTV mi2x88t0NghbTmJV70OWCYxGs5CcOguom1lAU2L9Ln2IsIfEimvfWWZBQ25K90P2WeCQEJQ4 OfMJywJG1lWMosWpxUm56UZGeqlFmcnFxfl5enmpJZsYgSnl4JbfBjsYXz53PMQowMGoxMP7 eO7FaCHWxLLiytxDjBIczEoivM5xQCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8Fn6bo4QE0hNL UrNTUwtSi2CyTBycUg2Mbtn1vLlrHCYsf5JeeuG932cx/6IdlroWHrl6VzT2VNQ592q9vR0U 2rbtkZO9qni4gFMof4/X0YZq0cD7zHJtGew3yj3cInPbf3JUqGVHpVyqKPpUvfiWStXkmP2X 6ivNNQzsrzIf3a0gxFO8e81Tsffea9p2LnHadmBO+RH1iPDkQzerXymxFGckGmoxFxUnAgCq ok0tJQMAAA== Archived-At: Subject: Re: [Ace] WGLC for draft-ietf-ace-oscore-profile 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, 25 Oct 2018 11:46:46 -0000 SGkgSmltLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcmV2aWV3IGNvbW1lbnRzLiBXZSBhZ3JlZSB3 aXRoIGFsbCB5b3VyIHBvaW50cywgYW5kIGhhdmUgb3BlbmVkIGlzc3VlczogaHR0cHM6Ly9naXRo dWIuY29tL2FjZS13Zy9hY2Utb3Njb3JlLXByb2ZpbGUvaXNzdWVzIHRvIGdldCB0aGlzIGZpeGVk Lg0KDQpJbmxpbmUgc29tZSBkZXRhaWxlZCBhbnN3ZXIuDQoNClRoYW5rcywNCkZyYW5jZXNjYQ0K DQrvu79PbiAyMi8xMC8yMDE4LCAyMTowOSwgIkppbSBTY2hhYWQiIDxpZXRmQGF1Z3VzdGNlbGxh cnMuY29tPiB3cm90ZToNCg0KICAgICogU2VjdGlvbiAxIC0gSSB1bmRlcnN0YW5kIHRoZSByZWFz b25pbmcgYmVoaW5kIGhhdmluZyB0aGUgc2VydmVyIHNlbmQgYmFjaw0KICAgIGEgbm9uY2UsIGFs dGhvdWdoIGl0IHdvdWxkIGJlIGdvb2QgdG8gaGF2ZSBhIGRlc2NyaXB0aW9uIHNvbWVwbGFjZSBh Ym91dCB3aHkNCiAgICB0aGlzIGlzIGJlaW5nIGRvbmUuICAoSSB3b3VsZCBhbHNvIG1ha2UgaXQg b3B0aW9uYWwgYXMgbm90IGFsbCBSUyBuZWVkIHRvIGRvDQogICAgdGhpcy4pICBJIGRvIG5vdCB1 bmRlcnN0YW5kIHRoZSByZWFzb25pbmcgYmVoaW5kIGhhdmluZyB0aGUgY2xpZW50IHNlbmQgYQ0K ICAgIG5vbmNlIHRvIHRoZSBzZXJ2ZXIuDQoNCkZQOiBUaGUgbW90aXZhdGlvbiBmb3IgdGhlIG5v bmNlIGNvbnN0cnVjdGlvbiB3YXMgaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLCBidXQg SSBhZ3JlZSB0aGF0IGhhdmluZyBpdCBpbiB0aGUgUHJvdG9jb2wgT3ZlcnZpZXcgbWFrZXMgc2Vu c2UsIHNvIEkgb3BlbmVkIGFuIGlzc3VlIHRvIGZpeCB0aGF0LiBUaGUgcmVhc29uIGJlaGluZCBo YXZpbmcgdGhlIGNsaWVudCBjcmVhdGUgYSBub25jZSBpcyB0aGF0IHdlIGFyZSBwcm90ZWN0aW5n IGFnYWluc3QgYW4gYXR0YWNrZXIgcmVwbGF5aW5nIGFuIG9sZCBSUyBtZXNzYWdlIChjb250YWlu aW5nIGFuIG9sZCBub25jZSksIHdoaWNoIHdvdWxkIHByb3Zva2UgdGhlIGNyZWF0aW9uIG9mIGFu IG9sZCBzZWN1cml0eSBjb250ZXh0IG9uIHRoZSBDbGllbnQsIGFuZCByZXVzZSBvZiBrZXlzIGFu ZCBub25jZXMgZm9yIGEgZGlmZmVyZW50IChuZXcpIG1lc3NhZ2UuDQogICAgDQogICAgKiBTZWN0 aW9uIDMuMSAtIFRoaXMgaXMgbW9yZSBnZW5lcmFsIHRoYW4gdGhlIHNlY3Rpb24sIGJ1dCB5b3Ug c2hvdWxkIG5vdA0KICAgIHVzZSB0aGUgVVJJIHBhdGggaW4gdGhlIHRleHQsIGluc3RlYWQgeW91 IHNob3VsZCBiZSB1c2luZyB0aGUgbmFtZSB0aGF0IGlzDQogICAgaW4gdGhlIGF1dGh6IGRvY3Vt ZW50Lg0KDQpGUDogQWdyZWVkLCBpc3N1ZSBvcGVuZWQgdG8gZml4IHRoaXMuDQogICAgDQogICAg KiBTZWN0aW9uIDMuMiAtIERvZXMgaXQgcmVhbGx5IG1ha2Ugc2Vuc2UgdG8gdXNlICdDT1NFX0tl eScgdG8gdHJhbnNwb3J0IHRoZQ0KICAgIGtleSBkYXRhPyAgV291bGQgYSBkaWZmZXJlbnQgZmll bGQgbmFtZSBiZSBiZXR0ZXI/DQoNCkZQOiBUaGlzIHdhcyBicm91Z2h0IHVwIHNldmVyYWwgdGlt ZXMsIHNvIHdlIHdpbGwgbWFrZSB0aGlzIGNoYW5nZSBub3cuDQogICAgDQogICAgKiBTZWN0aW9u IDMuMiAtIFBsZWFzZSBwcm92aWRlIGEganVzdGlmaWNhdGlvbiBmb3IgdGhlIHJlcXVpcmVtZW50 IHRoYXQgdGhlDQogICAgaWRzIG11c3QgYmUgdW5pcXVlIG92ZXIgdGhlIHNldCBvZiBhbGwgY2xp ZW50cyBhbmQgUlMuICAgSSBjYW4gc2VlIHRoYXQgdGhlDQogICAgY2xpZW50IGlkcyBuZWVkIHRv IGJlIHVuaXF1ZSBvbiBhIHNpbmdsZSBSUyBhbmQgUlMgaWRzIG5lZWQgdG8gYmUgdW5pcXVlIGZv cg0KICAgIGFueSBnaXZlbiBjbGllbnQgYnV0IG5vdCB0aGUgYnJvYWRlciBzdGF0ZW1lbnQuDQoN CkZQOiBZb3UgYXJlIHJpZ2h0LCB0aGlzIHJlcXVpcmVtZW50IGlzIHRvbyB3aWRlLiBXZSB3aWxs IHJlcGxhY2Ugd2l0aCB5b3VyIHN1Z2dlc3Rpb24uDQogICAgDQogICAgKiBQbGVhc2UgYWRkIGFu IGV4cGxpY2l0IHNlY3Rpb24gb24gd2hlbiBhIFJTIGFuZCBhIGNsaWVudCBzaG91bGQgZGlzY2Fy ZA0KICAgIHRoZSBzZWN1cml0eSBjb250ZXh0Lg0KDQpGUDogT2sgd2Ugd2lsbCBhZGQgdGhpcy4g QXMgbWVudGlvbmVkIGluIHRoZSBpc3N1ZSwgSSBoYXZlIG5vdyBvbmx5IHRoaXMgMyBjYXNlcyBp biBtaW5kOiBQYXJ0aWFsIElWIHNwYWNlIGVuZHMgKGVpdGhlciBDIG9yIFJTKTsgdGhlIGtpZCBj b250ZXh0IG9uIHRoZSBSUyBzaWRlIGRvZXMgbm90IG1hdGNoIHdpdGggTjEgKFJTKTsgQyByZWNl aXZlcyBhIG51bWJlciBvZiBVbmF1dGhvcml6ZWQgKEMpLCBhbHRob3VnaCB0aGF0IGlzIGEgY29u c2lkZXJhdGlvbi9yZWNvbW1lbmRhdGlvbnMsIGRldGFpbHMgd291bGQgYmUgYXBwbGljYXRpb24g c3BlY2lmaWMuIERvIHlvdSBzZWUgYW55IG90aGVyIGNhc2UgcmVsZXZhbnQgZm9yIHRoaXMgc2Vj dGlvbj8NCiAgICANCiAgICAqIFNlY3Rpb24gNiAtIE9rIEknbGwgYml0ZSAgLSBob3cgZG9lcyBu b3QgZWNob2luZyB0aGUgbm9uY2UgYWxsb3cgZm9yIGENCiAgICBtYW4taW4tdGhlLW1pZGRsZSBh dHRhY2sgZ2l2ZW4gdGhhdCB0aGUgc2FsdCBhbmQgc2hhcmVkIHNlY3JldCBhcmUgc3RpbGwNCiAg ICBnb2luZyB0byBiZSBrbm93biBvbmx5IHRvIHRoZSBDIGFuZCBSUyBhbmQgbm90IHRvIHRoZSBN SVRNLiAgSSBjYW4gc2VlIGEgRE9TDQogICAgYXR0YWNrIGJlaW5nIG1hZGUsIGJ1dCB0aGF0IGNh biBiZSBkb25lIGV2ZW4gd2l0aG91dCB0aGlzIGp1c3QgYnkgY2F1c2luZw0KICAgIHRoZSByZXNw b25zZSB0byBuZXZlciBiZSBkZWxpdmVyZWQuDQoNCkZQOiBPayBzbyBvdXIgbWlzdGFrZSBoZXJl IGlzIHRvIHVzZSB0aGUgdGVybSBNaXRNLCBzbyB0byBzb2x2ZSB0aGlzIHdlIHdpbGwgcmVwbGFj ZSB3aXRoICJvbi1wYXRoIGF0dGFja2VyIi4gVGhlIGZvbGxvd2luZyBzZW50ZW5jZSBzaG91bGQg YmUgY29ycmVjdCB3aXRoIHRoYXQgZml4ICJNb3Jlb3ZlciwgdGhlIGNsaWVudCBlY2hvZXMgdGhl IG5vbmNlIGNyZWF0ZWQgYnkgdGhlIFJTLCB3aGljaCB2ZXJpZmllcyBpdCBiZWZvcmUgZGVyaXZp bmcgdGhlIFNlY3VyaXR5IENvbnRleHQsIGFuZCB0aGlzIHByb3RlY3RzIGFnYWluc3QgYW4gYWR2 ZXJzYXJ5IGFjdGluZyBhcyBhbiBvbiBwYXRoIGF0dGFja2VyIGFuZCBzdWJzdGl0dXRpbmcgdGhl IG5vbmNlIGluIHRyYW5zaXQgZnJvbSBjbGllbnQgdG8gUlMgdG8gcHJvdm9rZSB0aGUgY3JlYXRp b24gb2YgZGlmZmVyZW50IFNlY3VyaXR5IENvbnRleHRzIGluIHRoZSBjbGllbnQgYW5kIFJTLiIg WWVzIHRoaXMgaXMgYSBET1MsIGJ1dCBjb3VsZCBhbHNvIGxlYWQgdG8gcmV1c2Ugb2Yga2V5cyBh bmQgbm9uY2VzLCBhcyBtZW50aW9uZWQgYmVmb3JlLg0KICAgIA0KICAgICogQXBwZW5kaXggLSBJ IGFtIG5vdCBzdXJlIHRoYXQgSSB0aGluayB0aGF0IHRoZSBFREhPQyBwcm9maWxlIHNob3VsZCBi ZSBpbg0KICAgIHRoaXMgZG9jdW1lbnQgYXMgb3Bwb3NlIHRvIGJlaW5nIGluIGl0J3Mgb3duIGRv Y3VtZW50LiAgVGhlIGZhY3QgdGhhdCB3ZQ0KICAgIGhhdmUgbm90IGV2ZW4gdHJpZWQgdG8gZ2V0 IHRoaXMgdG8gd29yayBpbiBhbnkgb2YgdGhlIGludGVyb3AgdGVzdHMgbWVhbnMNCiAgICB0aGF0 IEkgYW0gbGVzcyBzdXJlIHRoYXQgaXQgaXMgd2VsbCBiYWtlZC4NCg0KRlA6IEFncmVlZCwgd2Ug d2lsbCByZW1vdmUgdGhpcyBmcm9tIHRoaXMgZG9jdW1lbnQgYW5kIG1vdmUgaXQgdG8gaXRzIG93 biBkb2N1bWVudA0KICAgIA0KICAgIEppbQ0KICAgIA0KICAgIA0KICAgID4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCiAgICA+IEZyb206IEFjZSA8YWNlLWJvdW5jZXNAaWV0Zi5vcmc+IE9u IEJlaGFsZiBPZiBKaW0gU2NoYWFkDQogICAgPiBTZW50OiBNb25kYXksIE9jdG9iZXIgOCwgMjAx OCAyOjM1IFBNDQogICAgPiBUbzogYWNlQGlldGYub3JnDQogICAgPiBTdWJqZWN0OiBbQWNlXSBX R0xDIGZvciBkcmFmdC1pZXRmLWFjZS1vc2NvcmUtcHJvZmlsZQ0KICAgID4gDQogICAgPiBUaGUg Y2hhaXJzIGJlbGlldmUgdGhhdCB0aGUgc2V0IG9mIGRvY3VtZW50cyBkZWFsaW5nIHdpdGggdGhl IE9BdXRoDQogICAgPiBmcmFtZXdvcmsgZm9yIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cyBpcyBu ZWFyaW5nIHRoZSBwb2ludCB0aGF0IHdlIHNob3VsZA0KICAgID4gYmUgYWJsZSB0byBhZHZhbmNl IGl0IHRvIHRoZSBJRVNHIGZvciBwdWJsaWNhdGlvbi4gICBXZSB0aGVyZWZvcmUgd2FudCB0bw0K ICAgID4gaGF2ZSBhIGZ1bGwgbGlzdCBvZiBpc3N1ZXMgdGhhdCBuZWVkIHRvIGJlIGRlYWx0IHdp dGggYXQgdGhlIEJhbmdrb2sNCiAgICA+IG1lZXRpbmcuDQogICAgPiANCiAgICA+IFRoaXMgc3Rh cnRzIGEgMiB3ZWVrIFdHTEMgZm9yIGRyYWZ0LWlldGYtYWNlLW9zY29yZS1wcm9maWxlDQogICAg PiANCiAgICA+IFdlIGtub3cgdGhhdCB0aGUgZm9sbG93aW5nIGlzc3VlcyBhcmUgb3V0c3RhbmRp bmc6DQogICAgPiANCiAgICA+IGRyYWZ0LWlldGYtYWNlLW9zY29yZS1wcm9maWxlOg0KICAgID4g KiAgTm8gY3VycmVudCBrbm93biBpc3N1ZXMNCiAgICA+IA0KICAgID4gDQogICAgPiBKaW0gJiBS b21hbg0KICAgID4gDQogICAgPiANCiAgICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQogICAgPiBBY2UgbWFpbGluZyBsaXN0DQogICAgPiBBY2VAaWV0 Zi5vcmcNCiAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQog ICAgDQogICAgDQoNCg== From nobody Thu Oct 25 06:32:49 2018 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 4ABCA130E55 for ; Thu, 25 Oct 2018 06:32:42 -0700 (PDT) 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, 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 WRAn_KDW9wP0 for ; Thu, 25 Oct 2018 06:32:41 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F88D130E5C for ; Thu, 25 Oct 2018 06:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w9PDVrGZ012536; Thu, 25 Oct 2018 15:31:58 +0200 (CEST) Received: from [192.168.217.114] (p54A6CA9F.dip0.t-ipconnect.de [84.166.202.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 42gp2072FPz1Bqk; Thu, 25 Oct 2018 15:31:52 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <877ei6tnwf.fsf@tzi.org> Date: Thu, 25 Oct 2018 15:31:52 +0200 Cc: Mike Jones , Jim Schaad , "ace@ietf.org" X-Mao-Original-Outgoing-Id: 562167110.484911-d50da1a89401296c726e9b002cd2a7b9 Content-Transfer-Encoding: quoted-printable Message-Id: References: <065b01d45f4e$b8d372a0$2a7a57e0$@augustcellars.com> <3B32C31E-11C3-4808-82DC-3C75C949A0E9@tzi.org> <877ei6tnwf.fsf@tzi.org> To: Olaf Bergmann X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Ace] WGLC for draft-ietf-ace-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 13:32:42 -0000 Well, I was a bit terse, was I. I really meant to address the CWT-like structures, not everything that = is ever encoded in CBOR. If it doesn=E2=80=99t feel like a claim set, then of course there is no = point in mimicking CWT. Gr=C3=BC=C3=9Fe, Carsten > On Oct 25, 2018, at 10:45, Olaf Bergmann wrote: >=20 > Carsten Bormann writes: >=20 >> +1 for making all the CWT-like structures into real CWTs. >=20 > Not every key/value-pair encoded as CBOR is automatically a CWT. What > happens here is that we are trying to force every protocol element = that > is required to solve an application-specific problem to fit into > existing registered OAuth elements. As already pointed out by Mike, = this > does not work well because ACE is different from vanilla OAuth. >=20 > The best solution I can imagine to conserve precious number space is = to > use the media type (Content-Format in CoAP) as differientiator and use > CWT-numbers only for things that are CWTs >=20 > Gr=C3=BC=C3=9Fe > Olaf >=20 >=20 From nobody Thu Oct 25 10:41:34 2018 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 EF7FA130DFC for ; Thu, 25 Oct 2018 10:41:33 -0700 (PDT) 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_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 NhwkAfo2OH52 for ; Thu, 25 Oct 2018 10:41:32 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42525126F72 for ; Thu, 25 Oct 2018 10:41:32 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DB40320008 for ; Thu, 25 Oct 2018 13:41:28 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 688C4230D; Thu, 25 Oct 2018 13:41:31 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6597C1891 for ; Thu, 25 Oct 2018 13:41:31 -0400 (EDT) From: Michael Richardson To: "ace\@ietf.org" In-Reply-To: <877ei6tnwf.fsf@tzi.org> References: <065b01d45f4e$b8d372a0$2a7a57e0$@augustcellars.com> <3B32C31E-11C3-4808-82DC-3C75C949A0E9@tzi.org> <877ei6tnwf.fsf@tzi.org> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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] WGLC for draft-ietf-ace-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 17:41:34 -0000 --=-=-= Content-Type: text/plain Olaf Bergmann wrote: >> +1 for making all the CWT-like structures into real CWTs. > Not every key/value-pair encoded as CBOR is automatically a CWT. What > happens here is that we are trying to force every protocol element that > is required to solve an application-specific problem to fit into > existing registered OAuth elements. As already pointed out by Mike, this > does not work well because ACE is different from vanilla OAuth. We tried at first to fit RFC8366 (vouchers) into JWTs (and thus CWTs for constrained vouchers), but we found the OAuth claim statements too confusing for what we were doing. We could have made it work, but it just felt wrong. > The best solution I can imagine to conserve precious number space is to > use the media type (Content-Format in CoAP) as differientiator and use > CWT-numbers only for things that are CWTs I would agree. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlvSAEoACgkQgItw+93Q 3WUa2gf+OioSoBGh1vDrKbGfpp7Vn7WGb9Yqa/1m0EeIvxFRUy4TyaN5AAuHq5oS K8cphfRXVEr1ajaYHwTDuBBNKW39XBuuflZG8z8qvlgpIseQCp0V/smQd+c3fRcD PTp0HhZOMjEphrxnDvp6JNm9gfmkwGTpUO3JwhXITSxr4kMgmG5fGMGJGy19WMPy XiMSeXamWbQqSgj3zyKQ/kyC5TmE5yyBXwLjyM4MFZ51M8sH/6I6Q3J+PYyifOMH c7hXovbnqpB1iqcDMecXWAy3iMnSWn3XBa0nnJiqx7/QMsxJ3KOhR5b3gyaFFFFa 7jfz+AGw6ABtMXzU2ZVG8yRDr9SD/g== =iVMm -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 25 11:30:51 2018 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 CD6EF128A6E for ; Thu, 25 Oct 2018 11:30:49 -0700 (PDT) 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, 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 QhOFyHtFcjXV for ; Thu, 25 Oct 2018 11:30:48 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1894130E3A for ; Thu, 25 Oct 2018 11:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w9PIUdLu029668; Thu, 25 Oct 2018 20:30:44 +0200 (CEST) Received: from [192.168.217.114] (p54A6CA9F.dip0.t-ipconnect.de [84.166.202.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 42gwfl1JMVz1Bqf; Thu, 25 Oct 2018 20:30:39 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <10375.1540489291@localhost> Date: Thu, 25 Oct 2018 20:30:38 +0200 Cc: "ace@ietf.org" X-Mao-Original-Outgoing-Id: 562185036.623503-df62d3a5e5fe95af19722c97fc8abd28 Content-Transfer-Encoding: quoted-printable Message-Id: <6FB6F67E-CC8A-442F-AFCC-DDC825D87FF3@tzi.org> References: <065b01d45f4e$b8d372a0$2a7a57e0$@augustcellars.com> <3B32C31E-11C3-4808-82DC-3C75C949A0E9@tzi.org> <877ei6tnwf.fsf@tzi.org> <10375.1540489291@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Ace] WGLC for draft-ietf-ace-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 18:30:50 -0000 On Oct 25, 2018, at 19:41, Michael Richardson = wrote: >=20 > OAuth claim statements too confusing Indeed, there is a problem there (as with many things inherited from = OAuth). We might want to fix those issues for the purposes ACE, even if it = wasn=E2=80=99t in the domain for the ANIMA work. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Oct 25 13:51:38 2018 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 4A0031276D0 for ; Thu, 25 Oct 2018 13:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 kecQJbSCChNm for ; Thu, 25 Oct 2018 13:51:35 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FF51124C04 for ; Thu, 25 Oct 2018 13:51:34 -0700 (PDT) Received: from Jude (50.252.25.182) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 25 Oct 2018 13:46:42 -0700 From: Jim Schaad To: 'Ludwig Seitz' , References: In-Reply-To: Date: Thu, 25 Oct 2018 13:51:21 -0700 Message-ID: <018301d46ca4$7e091db0$7a1b5910$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJ8qlZiinhkNDNE8EN7qIRibxZqnwJPovo6o81xeLA= Content-Language: en-us X-Originating-IP: [50.252.25.182] Archived-At: Subject: Re: [Ace] Review of draft-ietf-ace-oauth-params-00 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, 25 Oct 2018 20:51:37 -0000 > -----Original Message----- > From: Ace On Behalf Of Ludwig Seitz > Sent: Wednesday, October 24, 2018 1:00 AM > To: ace@ietf.org > Subject: Re: [Ace] Review of draft-ietf-ace-oauth-params-00 >=20 > On 23/10/2018 21:09, Hannes Tschofenig wrote: >=20 > > 2) 'req_aud' parameter > > > > At the last IETF OAuth meeting in Montreal we agreed to adopt a new > > document, called resource indicators, and it can be found here: > > > > https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-01 > > > > I believe the parameter name and semantics defined in > > draft-ietf-oauth-resource-indicators-01 should match what is defined > > in draft-ietf-ace-oauth-params-00. > > > > The name of the parameter in draft-ietf-oauth-resource-indicators-01 > > is 'resource' and it is defined as > > > > =A0=A0 resource > > > > =A0=A0=A0=A0=A0 Indicates the location of the target service or = resource where > > > > =A0=A0=A0=A0=A0 access is being requested.=A0 Its value MUST be an = absolute URI, > > as > > > > =A0=A0=A0=A0=A0 specified by Section 4.3 of [RFC3986], which MAY = include a > > query > > > > =A0=A0=A0=A0=A0 component but MUST NOT include a fragment = component.=A0 Multiple > > > > =A0=A0=A0=A0=A0 "resource" parameters MAY be used to indicate that = the > > requested > > > > =A0=A0=A0=A0=A0 token is intended to be used at multiple resources. > > > > >=20 >=20 > Looking closer at this draft: >=20 > The resource parameter seems to be much more limited than the audience > claim, since a URI is required. As Steffi recently remarked in her = review of > draft-ietf-oauth-authz, URIs are not a good way to identify resources = in > constrained environments, since the address of a device can change. I rather have to agree that these do not seem to be doing the same = thing. The 'resource' parameter looks like it could actually be used in = parallel with the 'aud' parameter if you want to refer to a specific RS which is hosting the audience in question. But that would be some form of = narrowing of scope. >=20 > Furthermore there seems also to be an overlap with the 'scope' > parameter, since the 'resource' parameter can be used to indicate = specific > resources and not only the target RS. >=20 > What if we want to identify the audience by its public key instead of = an URI? Ludwig, this is not actually a problem since there is a URI for doing = that. >=20 > What if a client wants to request a token for a group of RS identified = by a > specific audience value (e.g. "thermostats-building-1")? One of the things that I kept hearing is that an audience may be hosted = by multiple resource servers as long as I have been going to ACE meetings. This does not seem to be a problem with the OAuth in HTTP right now as a = CDN would hide that level of detail. =20 Jim >=20 >=20 > /Ludwig >=20 >=20 > -- > Ludwig Seitz, PhD > Security Lab, RISE > Phone +46(0)70-349 92 51 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Thu Oct 25 14:12:13 2018 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 0476812DDA3 for ; Thu, 25 Oct 2018 14:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 ebuFdZw4KFbE for ; Thu, 25 Oct 2018 14:12:10 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D99412D4E9 for ; Thu, 25 Oct 2018 14:12:09 -0700 (PDT) Received: from Jude (50.252.25.182) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 25 Oct 2018 14:07:20 -0700 From: Jim Schaad To: 'Stefanie Gerdes' , 'Ludwig Seitz' , References: <4519f58c-c6f7-5ac0-003c-7ae4f59bccd4@tzi.de> <43b3b90f-996a-8b8a-2439-e3d6adcc3b0f@ri.se> <121cc6e8-65cc-a32e-9d50-68c620b57543@tzi.de> In-Reply-To: <121cc6e8-65cc-a32e-9d50-68c620b57543@tzi.de> Date: Thu, 25 Oct 2018 14:11:59 -0700 Message-ID: <018a01d46ca7$5fab3120$1f019360$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJDl5Bm99e9zGnxaPJuM5ZpOzU3eQGM5yWFAblebpKkN+M58A== Content-Language: en-us X-Originating-IP: [50.252.25.182] Archived-At: Subject: Re: [Ace] ACE Framework Review 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, 25 Oct 2018 21:12:13 -0000 > -----Original Message----- > From: Ace On Behalf Of Stefanie Gerdes > Sent: Wednesday, October 24, 2018 6:53 AM > To: Ludwig Seitz ; ace@ietf.org > Subject: Re: [Ace] ACE Framework Review >=20 > Hi Ludwig, >=20 > On 10/22/2018 03:07 PM, Ludwig Seitz wrote: > > > >> The minimal security requirements for the communication between two > >> communication partners should be listed (C-AS, RS-AS, C-RS, > >> respectively). Which pieces of information do they require prior to > >> the communication? How must the communication be secured? Which > >> keying material do they need to use? > > > > The first one I agree with. However the other questions seem more > > specific to the commSec solution to me, which would put them into = the > > profiles. >=20 > In Appendix C, you specify that the security protocol between C and RS must > provide encryption, integrity and replay protection. It would be = useful to list > similar requirements for the communication between C and AS and RS and > AS. I would find this request quite reasonable. >=20 > In section 5 you state "Nevertheless, it is REQUIRED that the data exchanged > with the AS is encrypted and integrity protected. Does that refer to = both the > communication between the AS and C and between the AS and RS? It would > be useful to clarify that in the sentence. >=20 > The client may specify a key in the request to the AS. The AS must ascertain > that the client that sent the request is associated with this key. Otherwise a > client may request tokens for other clients. Although the client = cannot gain > access with these tokens without the corresponding keying material, it = may > use the token for DoS attacks on the resource server's authorization > information endpoint. Since the tokens are valid, RS cannot throw them > away. I completely agree with this and have made the same argument multiple = times. >=20 > > > >> The framework should point out that all claims that influence the > >> security must stem from claimants that were approved by the > >> respective human being that is responsible for the device, i.e., = the > >> requesting party for the client and the resource owner for the AS = and > >> RS. Otherwise the solution is not secure. > >> > > > > Are there claims that do not influence security? > > > > The specification says (section 4): > > > > The consent of the resource owner, for giving a client access to = a > > protected resource, can be provided dynamically as in the = traditional > > OAuth flows, or it could be pre-configured by the resource owner = as > > authorization policies at the AS, which the AS evaluates when a = token > > request arrives. The resource owner and the requesting party = (i.e., > > client owner) are not shown in Figure 1. > > > > I believe this is what you were looking for, if not please explain > > what is missing. >=20 > As I read it, this paragraph only addresses authorization information = that is > meant for the server. The client may receive keying material for RS = from AS. > In this case, C's owner, i.e., RqP, must authorize AS to provide = keying > material to C. >=20 > > > >> Validity of the access token (Token Expiration, Section 5.8.3): = There > >> seem to be additional requirements here that are currently not > >> mentioned. It is not clear how RS determines the freshness of > >> introspection messages (and how fresh they are). > > > > That would be up to the commSec protocol, also it is covered in the > > security considerations of RFC 7662. I will add a reference to those > > considerations in our security considerations section. > > > >> Also, the token > >> introspection approach is particularly vulnerable to DoS attacks > >> since introspection messages must be exchanged to validate every = token. > > > > This problem applies to regular OAuth introspection as well and is > > covered in the security considerations of RFC 7662. >=20 > It might be useful to mention that in the security considerations. >=20 > > > >> The sequence number approach has the problem that an attacker may > >> withhold new tokens from RS. In this case, old tokens are = infinitely > >> valid. This is particularly damaging because C may have a strong > >> interest to withhold new tokens and can easily do so by not = relaying > >> them to RS. This approach therefore must not be used unless there = is > >> an additional communication channel between RS and AS that = regularly > >> informs RS which the most recent sequence number is. > >> > > This is a best effort approach when the RS has no internal sense of > > time. Also the idea was that several client could submit tokens with > > an ever increasing unique serial number maintained by the AS. Thus > > even if one client would withhold it's newer tokens to keep the old > > ones from expiring, the other clients would eventually submit enough > > new tokens (with higher sequence numbers) so that the token expires. > > > > AFAIK the RS with no internal clock at all is a very rare = occurrence, > > thus you can usually expect some form of wallclock time, and thus > > implement an expiration based on = "time-since-you-received-this-token". >=20 > I don't think it is reasonable to require that the RS must have = multiple clients > to ensure that the mechanism works. If you expect the RS to have a > wallclock time, you may want to omit the sequence number approach. If = the > mechanism only works when additional requirements are met, these > requirements must be mentioned. >=20 > If the RS calculates the expiration of the token from the time it = received the > token (an appraoch which currently does not seem to be mentioned in = the > document?), the approach is vulnerable to attacks where an attacker > manages to withhold messages. The other day I was thinking about this and I am wondering if a server = which has this level of abilities would be more likely to just act as a client posting it's information to some type of pub-sub server rather than = acting directly as a server which would be queried by other clients. This is = the type of server one would expect to send most of its time sleeping and = thus trying to time talking to it correctly would be difficult. >=20 > > > >> Authorization of the AS on the RS side: in the ACE framework, RS > >> checks the integrity of the access token (e.g., section 4, section = 6, > >> Appendix > >> B: Resource Server). RS must also check that the access token stems > >> from an AS that is authorized by RO to provide the token. If RS > >> accepts tokens from authorization servers that are not approved by > >> RO, the solution is not secure. Introspection messages must also = stem > >> from an AS that is approved by RO. > > > > This is implicit, if the RS has the key that allows it to verify the > > integrity of the token that means that it is an AS approved by its = RO. > > I will try to add a sentence to make that more explicit. > > > >> > >> Access token validation: Section 5.8.1 should point out that RS = must > >> check the integrity of the token and validate that it stems from AS > >> that is authorized by RO. > > > > We can expand on this phrase I think: "The RS receiving the token = MUST > > verify the validity of the token." >=20 > That sounds like a good idea. >=20 > > > > > >> Also, it would be helpful if the section also contained information > >> how a server must react to missing fields, e.g., missing = authenticity > >> of the token or tokens from unknown authorization servers. > >> > > This would be the following sentence in 5.8.1: > > "If the token is not valid, the RS MUST respond with a response code > > equivalent to the CoAP code 4.01 (Unauthorized)." >=20 > It would be useful to add when the RS can consider a token to be = valid, i.e., > which requirements a token must meet to be valid. >=20 > > > >> Confidentiality of access tokens: > >> In the access token, confidentiality is only demanded for symmetric > >> keys. The security considerations should point out that other data = in > >> the access token may be confidential and then require protection as well. > >> > > This should be covered in RFC 6749 and RFC 6819 which are = referenced > > in the security considerations. > > > > > >> Authorization Rules in Access Token: The framework should mention = in > >> section 5.6.2 that the authorization rules that are presented to RS > >> in the scope of the access token must reflect RO's decisions. > > > > That is already covered by the text in section 4 (see comment = above). >=20 > Section 5.6.2 describes how AS specifies the response to the client. > I think it would help to avoid implementation errors if the section describes > that the authorization rules that the AS defines in the access token = must > reflect RO's decisions. >=20 > > > >> > >> Management of the authz-info resource: > >> * The authz-info resource is vulnerable to DoS attacks: clients may > >> (with or without intention) send large numbers of access tokens to > >> RS. A constrained RS may soon run out of memory/storage space if it > >> needs to store large numbers of tokens. > > > > A RS is not expected to store large numbers of tokens. Section 5.8.1 > > specifies: > > > > "The RS MUST be prepared to store at least one access token for = future > > use." > > > > Thus the RS can adapt the number of tokens it stores to its > > constrained storage resources. >=20 > I don't really understand how storing at least one access token helps = to > mitigate the problem of DoS attacks. I don't think that it will mitigate the DoS attack. What it will = mitigate is the memory resource exhaustion problem. I would expect that = something along the lines of the "too many requests" error code would be used for = a DoS attack based on lots of requests. >=20 > > > >> If introspection messages are used to check the validity of access > >> tokens, the use of the authz-info resource amplifies the risk of = DoS > >> attacks since RS must send a message to its AS for every received > >> token. These problems should be mentioned in the security > >> considerations. > > > > I will add a section describing the problem. > > > > > >> The preferred mitigation should be that the authz-info resource is > >> only used for protected communication. This does obviously not work > >> for the RPK mode. In the PSK mode, RS should be able to decide that > >> it uses the authz-info resource only for protected updates. > > > > I don't think that will help, since somehow the initial access token > > must get to the RS. So even when passing it through the DTLS = handshake > > (as with PSK in the DTLS profile) the same DoS risk exists. >=20 > If the client is not able to finish the DTLS handshake, the RS can = throw the > token away immediately. Also, DTLS has some protection against DoS > attacks. If a resource is used, clients can upload large numbers of = tokens to > the resource, and no protection against DoS attacks is available. If = the > tokens are valid, the RS must in the worst case store them until they expire, > even if the client never tries to communicate with RS. I am unaware of any DoS attacks that DTLS protects against that are not = also implementable for the resource. This is esp. true with the newest "too = many requests" and "echo" drafts which are progressing. What do you think = you have. By the way if the server is forced to validate the token on every connect then that will consume resources as well. This is really true = for introspection. Jim >=20 > > > >> * How must the authz-info resource be protected? E.g., an attacker > >> that is able to modify the resource may change or delete access > >> tokens. The framework leaves the protection of the resource to the > >> profiles, but I think some general advice can be offered by the framework. > > > > I can add a paragraph on this in section 5. > > > >> > >> Validity of the access information: > >> It seems that the people who wrote the framework did not consider > >> that the keying material is not only provided to RS but also to C. > >> How does C determine if the keying material it receives from AS is > >> still valid? > > > > It is valid as long as you don't get a 4.01 (Unauthorized) from the = RS. > > > >> The access token response may comprise an expires_in field that > >> contains the validity period of the access token in seconds (RFC > >> 6749), but does not specify the validity period of the keying > >> material. But even if the validity periods are equal, C does not = know > >> when the access token was generated. Also, the use of the = expires_in > >> field is optional. Without protection, the access information is > >> infinitely valid. C may use outdated and maybe compromised keying > >> material to communicate with RS. The framework should provide > >> information how C determines if the keying material is still valid. > >> Also, C must check if the keying material it has for a = communication > >> partner is still valid before sending a request. > >> > > > > I would think that in most cases it is acceptable that the client = just > > optimistically sends its request with the existing keying material = and > > renews it if it gets back a 4.01. >=20 > You mean if the client communicates with a compromised RS, it just > continues to do so? I don't think that this is such a good idea. I = think the AS > must check that the the keying material is valid at least as long as = the token > and must then set the expires_in field to the remaining lifetime of = the token. > Additionally, the AS should provide the time when the token was issued = in an > iat field. A client that wants to communicate with an RS must check if = the > keying material it has for the RS is still valid. >=20 > > > > Use cases where the security policy is such that this is = unacceptable > > should use a specific profile that defines additional mechanisms for > > the client to check its tokens and associated keying material (e.g. = by > > using client introspection). > > > >> The framework should also mention that C must determine if AS is > >> authorized by its owner to provide keying material concerning RS to = C. > > > > If C is configured to communicate with RS, this implies that the = owner > > of C accepts the AS in charge of RS. Otherwise the owner of C > > shouldn't have configured C to communicate with RS in the first = place. >=20 > And how does C know that a certain AS is in charge of RS? >=20 > > > >> It is not clear how C makes plain to AS with which RS it wants to > >> communicate. C may specify the intended audience in the token = request > >> using the req_aud parameter. How is RS represented in this case? > >> C and AS must have a common understanding how RS is identified, > >> otherwise C may communicate with the wrong RS! > >> IP addresses may change and therefore are not suitable. If AS > >> specifies identifiers for RS, C must securely obtain this = knowledge. > > > > Identifying the RS (using the audience claim and the req_aud > > parameter) is application specific. Some applications may want to = use > > public keys, others will want to use fixed identifiers that are > > manually assigned or otherwise generated. > > > > The framework does not suggest IP addresses as a way to identify an = RS. > > > >> The framework must point out that AS must check if the keying > >> material that it provides to C in the access token response = actually > >> refers to the RS that C wants to communicate with. The problem of > >> mixups concerning the RS must be mentioned in the security > considerations. > >> Also, the framework should give advice how this problem may be > addressed. > >> > > > > I will add a paragraph describing the problem and giving some basic > > suggestions (such as public keys as identifiers). > > > > > >> Confidentiality of unauthorized requests: > >> The data that the client sends to the RS in an unauthorized = resource > >> request may be confidential (e.g., because others must not know the > >> requested resources). The framework should mention in the security > >> considerations that the client must not send confidential data in = the > >> unauthorized resource request. > > > > I can add a sentence about this, although it seems very obvious. > > > > /Ludwig > > > > >=20 > Viele Gr=FC=DFe > Steffi >=20 > -- > Stefanie Gerdes Tel: +49 421 218 63906 > TZI Universit=E4t Bremen E-Mail: gerdes@tzi.de > Bibliothekstr. 1, MZH 5150 > 28359 Bremen, Germany >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Thu Oct 25 14:15:35 2018 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 DA3D012F295 for ; Thu, 25 Oct 2018 14:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 whL-M6ZEqAXV for ; Thu, 25 Oct 2018 14:15:31 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A5521277BB for ; Thu, 25 Oct 2018 14:15:31 -0700 (PDT) Received: from Jude (50.252.25.182) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 25 Oct 2018 14:10:43 -0700 From: Jim Schaad To: 'Carsten Bormann' , 'Mike Jones' CC: References: <065b01d45f4e$b8d372a0$2a7a57e0$@augustcellars.com> <3B32C31E-11C3-4808-82DC-3C75C949A0E9@tzi.org> In-Reply-To: <3B32C31E-11C3-4808-82DC-3C75C949A0E9@tzi.org> Date: Thu, 25 Oct 2018 14:15:21 -0700 Message-ID: <018b01d46ca7$d88ffbc0$89aff340$@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: AQJ+t/TOEyNDXiHpy0JlO2vTIlTnzAMjXR8HAr5ehJGjrNGcAA== Content-Language: en-us X-Originating-IP: [50.252.25.182] Archived-At: Subject: Re: [Ace] WGLC for draft-ietf-ace-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 21:15:33 -0000 Looking back to the message I sent on 10/3 I don't believe that the = OAuth requests are the same thing as CWTs and I proposed a solution = there about how to fix thing in the future so that they don't become = them. > -----Original Message----- > From: Carsten Bormann > Sent: Wednesday, October 24, 2018 10:34 PM > To: Mike Jones > Cc: Jim Schaad ; ace@ietf.org > Subject: Re: [Ace] WGLC for draft-ietf-ace-authz >=20 > +1 for making all the CWT-like structures into real CWTs. >=20 > Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Oct 25 14:25:16 2018 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 2CBEB130DFB; Thu, 25 Oct 2018 14:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 n3GjOXxKNJ2f; Thu, 25 Oct 2018 14:25:10 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 597EF12D4E9; Thu, 25 Oct 2018 14:25:09 -0700 (PDT) Received: from Jude (50.252.25.182) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 25 Oct 2018 14:20:20 -0700 From: Jim Schaad To: 'Francesca Palombini' , CC: References: <065a01d45f4e$b738ae60$25aa0b20$@augustcellars.com> <028c01d46a3a$ae1b9e40$0a52dac0$@augustcellars.com> <45F876B9-6BF8-448B-9EFF-28609FC8A805@ericsson.com> In-Reply-To: <45F876B9-6BF8-448B-9EFF-28609FC8A805@ericsson.com> Date: Thu, 25 Oct 2018 14:24:59 -0700 Message-ID: <018c01d46ca9$30c0c6c0$92425440$@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: AQIoMJGW0ffnzj4eMWBhJ41cSURLyANvcssxAUg2R1SkYzGVIA== Content-Language: en-us X-Originating-IP: [50.252.25.182] Archived-At: Subject: Re: [Ace] WGLC for draft-ietf-ace-oscore-profile 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, 25 Oct 2018 21:25:12 -0000 > -----Original Message----- > From: Francesca Palombini > Sent: Thursday, October 25, 2018 4:47 AM > To: Jim Schaad ; draft-ietf-ace-oscore- > profile@ietf.org > Cc: ace@ietf.org > Subject: Re: [Ace] WGLC for draft-ietf-ace-oscore-profile >=20 > Hi Jim, >=20 > Thank you for your review comments. We agree with all your points, and > have opened issues: = https://github.com/ace-wg/ace-oscore-profile/issues to > get this fixed. >=20 > Inline some detailed answer. >=20 > Thanks, > Francesca >=20 > =EF=BB=BFOn 22/10/2018, 21:09, "Jim Schaad" = wrote: >=20 > * Section 1 - I understand the reasoning behind having the server = send back > a nonce, although it would be good to have a description someplace = about > why > this is being done. (I would also make it optional as not all RS = need to do > this.) I do not understand the reasoning behind having the client = send a > nonce to the server. >=20 > FP: The motivation for the nonce construction was in the security > considerations, but I agree that having it in the Protocol Overview = makes > sense, so I opened an issue to fix that. The reason behind having the = client > create a nonce is that we are protecting against an attacker replaying = an old > RS message (containing an old nonce), which would provoke the creation = of > an old security context on the Client, and reuse of keys and nonces = for a > different (new) message. So what you are looking at is a client which is going to "forget" the = current security context that it possesses for an RS but not the token, = re-posting the token to the RS because it apparently thinks that the RS = has forgotten the token and context without and then accepting the = replay as being valid. =20 I think that a client which has forgotten the security context is also = going to forget the token and thus need a new one. I think that a client which is going to remember the security context is = also going to remember the nonce from the server and thus not rebuild = the context if the same nonce comes back. If this needs to be explicit - then it should be made so. >=20 > * Section 3.1 - This is more general than the section, but you = should not > use the URI path in the text, instead you should be using the name = that is > in the authz document. >=20 > FP: Agreed, issue opened to fix this. >=20 > * Section 3.2 - Does it really make sense to use 'COSE_Key' to = transport the > key data? Would a different field name be better? >=20 > FP: This was brought up several times, so we will make this change = now. >=20 > * Section 3.2 - Please provide a justification for the requirement = that the > ids must be unique over the set of all clients and RS. I can see = that the > client ids need to be unique on a single RS and RS ids need to be = unique for > any given client but not the broader statement. >=20 > FP: You are right, this requirement is too wide. We will replace with = your > suggestion. >=20 > * Please add an explicit section on when a RS and a client should = discard > the security context. >=20 > FP: Ok we will add this. As mentioned in the issue, I have now only = this 3 > cases in mind: Partial IV space ends (either C or RS); the kid context = on the RS > side does not match with N1 (RS); C receives a number of Unauthorized = (C), > although that is a consideration/recommendations, details would be > application specific. Do you see any other case relevant for this = section? Well - there are thing like expiration of the token which would make = sense as well. If you re-register the token because of an = unauthorized and get back a different nonce value. >=20 > * Section 6 - Ok I'll bite - how does not echoing the nonce allow = for a > man-in-the-middle attack given that the salt and shared secret are = still > going to be known only to the C and RS and not to the MITM. I can = see a > DOS > attack being made, but that can be done even without this just by = causing > the response to never be delivered. >=20 > FP: Ok so our mistake here is to use the term MitM, so to solve this = we will > replace with "on-path attacker". The following sentence should be = correct > with that fix "Moreover, the client echoes the nonce created by the = RS, > which verifies it before deriving the Security Context, and this = protects > against an adversary acting as an on path attacker and substituting = the nonce > in transit from client to RS to provoke the creation of different = Security > Contexts in the client and RS." Yes this is a DOS, but could also lead = to reuse > of keys and nonces, as mentioned before. See my above comment. But there are no problems here with the server = doing anything interesting as it would presumably not have generated the = same nonce value as the last time. This means that the client would = generate new keys only if the previous comment was wrong. I just don't see this as being a problem. Merits discussion in Bangkok Jim >=20 > * Appendix - I am not sure that I think that the EDHOC profile = should be in > this document as oppose to being in it's own document. The fact = that we > have not even tried to get this to work in any of the interop = tests means > that I am less sure that it is well baked. >=20 > FP: Agreed, we will remove this from this document and move it to its = own > document >=20 > Jim >=20 >=20 > > -----Original Message----- > > From: Ace On Behalf Of Jim Schaad > > Sent: Monday, October 8, 2018 2:35 PM > > To: ace@ietf.org > > Subject: [Ace] WGLC for draft-ietf-ace-oscore-profile > > > > The chairs believe that the set of documents dealing with the = OAuth > > framework for constrained environments is nearing the point that = we > should > > be able to advance it to the IESG for publication. We = therefore want to > > have a full list of issues that need to be dealt with at the = Bangkok > > meeting. > > > > This starts a 2 week WGLC for draft-ietf-ace-oscore-profile > > > > We know that the following issues are outstanding: > > > > draft-ietf-ace-oscore-profile: > > * No current known issues > > > > > > Jim & Roman > > > > > > _______________________________________________ > > Ace mailing list > > Ace@ietf.org > > https://www.ietf.org/mailman/listinfo/ace >=20 >=20 From nobody Thu Oct 25 14:43:53 2018 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 89B23124BE5 for ; Thu, 25 Oct 2018 14:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 bdZvzuXrR_tn for ; Thu, 25 Oct 2018 14:43:50 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F5FD130E50 for ; Thu, 25 Oct 2018 14:43:50 -0700 (PDT) Received: from Jude (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 25 Oct 2018 14:38:43 -0700 From: Jim Schaad To: 'Mike Jones' , References: <065b01d45f4e$b8d372a0$2a7a57e0$@augustcellars.com> In-Reply-To: Date: Thu, 25 Oct 2018 14:43:22 -0700 Message-ID: <018d01d46cab$c23b9880$46b2c980$@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: AQJ+t/TOEyNDXiHpy0JlO2vTIlTnzAMjXR8Ho8LLuLA= Content-Language: en-us X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [Ace] WGLC for draft-ietf-ace-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 21:43:52 -0000 > -----Original Message----- > From: Mike Jones > Sent: Wednesday, October 24, 2018 5:58 PM > To: Jim Schaad ; ace@ietf.org > Subject: RE: [Ace] WGLC for draft-ietf-ace-authz > > IT CAN'T BE A COINCIDENCE: There's clearly a relationship between many of > the CBOR numeric values used in this this specification and corresponding > CBOR Web Token (CWT) claim identifiers, but oddly, the relationship is > currently unspecified and the goals behind it are undefined. The spec should > be augmented to make the nature and goals of this relationship explicit. I > infer that there's such a relationship because the Mapping Parameters to > CBOR in Section 5.6.5 apparently carefully do not overlap with the values > registered in the IANA CWT Claims registry at > https://www.iana.org/assignments/cwt/cwt.xhtml. The Introspection > mappings in Section 5.7.4 apparently carefully use the same values as CWT > for the same things, but then adds additional values. And some of these > values are the same as values proposed for the CWT Claims registry in 8.13. > This has to be more than a coincidence but the spec doesn't currently say > why. You are right it is not a coincidence. You have been asking that they match up for quite a while and at one time the authors tried to do this. This does not mean that it should be that way. > > Per my earlier reviews of the ace-authz spec, I believe that the ACE OAuth > parameters should all be registered in the CWT Claims registry because of > the possibility of them being used in signed requests in a manner analogous > to https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17. The parameters > need to be registered to avoid future claim number conflicts. While conflicts > have clearly been carefully avoided to date, they will inevitably occur in the > future unless the values are actually registered. Please do so. This is something that I think is incorrect - see my mail on 10/3. > > DON'T SQUAT ON NUMERIC REGISTRY VALUES: Please change all instances > of numbers to be assigned by designated experts in existing registries from > specific values to "TBD". For instance, all the values for the CWT Claims > Registry in Section 8.13 (currently 12, 16, and 17) should be changed to TBD. > Our chair, Jim Schaad has been a vigorous advocate of not squatting in my > past interactions with him as a Designated Expert and I believe would > support this request. Likewise, the "19" in the CoAP Content-Format > Registration in Section 8.15 should become TBD. If they are creating a new registry - which means not going in the CWT claim registry then it makes sense for them to assign numbers. I agree on the content format registration unless they have gotten an early registry done. > > req_aud: Several examples use the "req_aud" parameter without defining it. > Doesn't this duplicate the "resource" parameter defined by > https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-01? If so, > please delete this parameter and use "resource". If not, say how it is > different and why the differences are necessary. > > rs_cnf: There isn't a clear normative definition of this parameter. It's > mentioned obliquely but its purpose, syntax, and semantics should be plainly > stated (as with each other newly defined parameter). > > The proposed numbers in Figures 12 and 16 contain mismatches. For > instance, token_type is "14" in Figure 12 in Section 5.6.5 and "13" in Figure 16 > in Section 5.7.4. There's too much alignment for it to be a coincidence but if > you intend alignment, please say so explicitly and fix the alignment. The > proposed ongoing alignment should also be described in the registration > instructions for the Designated Experts. > > -- Mike > > P.S. Per my earlier reviews of this specification, in my view as a Designated > Expert for the CWT Claims registry, I believe that it's not appropriate to use > up rare single-byte identifiers for most of the OAuth parameter encodings > specified in 5.6.5. I could be persuaded that "scope" merits one of these rare > numbers, but "profile", "error", "grant_type", "access_token", and > "token_type" probably do not, as they are application-specific and not of > general applicability. I also believe that some of the other Designated > Experts for this registry agree with me. Yet another reason why we should not be combining these registries into a single one in my opinion. Jim > > -----Original Message----- > From: Ace On Behalf Of Jim Schaad > Sent: Monday, October 8, 2018 2:35 PM > To: ace@ietf.org > Subject: [Ace] WGLC for draft-ietf-ace-authz > > The chairs believe that the set of documents dealing with the OAuth > framework for constrained environments is nearing the point that we should > be able to advance it to the IESG for publication. We therefore want to > have a full list of issues that need to be dealt with at the Bangkok meeting. > > This starts a 2 week WGLC for draft-ietf-ace-authz > > We know that the following issues are outstanding: > > draft-ietf-ace-authz > * There are a couple of esoteric issues around listing AS servers associated > with resources in a Resource Directory > > > Jim & Roman > > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Fri Oct 26 05:46:13 2018 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 B8E29130DCB for ; Fri, 26 Oct 2018 05:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.771 X-Spam-Level: X-Spam-Status: No, score=-4.771 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 header.b=K+hm0nZk; dkim=pass (1024-bit key) header.d=ericsson.com header.b=S1GJkFrw Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEWsiyf7N3nz for ; Fri, 26 Oct 2018 05:46:07 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 1B1A71286D9 for ; Fri, 26 Oct 2018 05:46:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1540557965; x=1543149965; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0dd9XsY1JB0aOS9o9ZcLCJ9bTAwdqUo2HMsU1jrFiQw=; b=K+hm0nZkjGNSWKzXS+w/oEn3WP/HmawNINLgv46antSU4LmVYDT/ctD2Zx5Scl/B feY2Hu/FFyQ029XADFNBe4A/CxZKfsYSB2rW6BDFBPD4rGSeqLZ5LvTMbz4AuxPS xI7XIdlksz+kzJEkkCANvB3TkG+4o3on1flzYkIgMSU=; X-AuditID: c1b4fb30-671b09e000007d19-40-5bd30c8da760 Received: from ESESSMB503.ericsson.se (Unknown_Domain [153.88.183.121]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 83.6D.32025.D8C03DB5; Fri, 26 Oct 2018 14:46:05 +0200 (CEST) Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 26 Oct 2018 14:46:02 +0200 Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 26 Oct 2018 14:46:02 +0200 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=0dd9XsY1JB0aOS9o9ZcLCJ9bTAwdqUo2HMsU1jrFiQw=; b=S1GJkFrw/wHkyVgqn9xwJ2EKRgMP9usq/xx8EBzOjX/lS6VxO+kqbkYKj9MgJ4xvxZ5/jRv/h6usGHy6aYqLx0LM1fm05DV/icXn5tfHXXU/Vfl33LqtWRIl3GYWNJx4pisV2+6cmNiNU9EWeL+1mVmlh18D+Jz6XCbHz2hXukg= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.188.140) by HE1PR0701MB2076.eurprd07.prod.outlook.com (10.167.190.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.14; Fri, 26 Oct 2018 12:46:01 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::c05a:fd61:6104:51e5]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::c05a:fd61:6104:51e5%6]) with mapi id 15.20.1273.019; Fri, 26 Oct 2018 12:46:01 +0000 From: Francesca Palombini To: Jim Schaad , "draft-ietf-ace-oscore-profile@ietf.org" CC: "ace@ietf.org" Thread-Topic: [Ace] WGLC for draft-ietf-ace-oscore-profile Thread-Index: AdRfTqcrNFwepW1pRaiIJNs5VwRdUAK7AUGAAIueqwAAEAH4gAAkW2oA Date: Fri, 26 Oct 2018 12:46:01 +0000 Message-ID: References: <065a01d45f4e$b738ae60$25aa0b20$@augustcellars.com> <028c01d46a3a$ae1b9e40$0a52dac0$@augustcellars.com> <45F876B9-6BF8-448B-9EFF-28609FC8A805@ericsson.com> <018c01d46ca9$30c0c6c0$92425440$@augustcellars.com> In-Reply-To: <018c01d46ca9$30c0c6c0$92425440$@augustcellars.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [217.31.165.122] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2076; 6:lW811Y8DtW8I8rdVcujb/04DQjFyVCXk+y6LUuFFBrIC3H95Zxx3O+cL+/iCjfHZLTyHwrxDMNmS+i3Lxyd/BcBbOawMpSNJFGl3RcXeiA5jRgmoYr9mlH0WkCzPYOvC/cOvPS0OmgBUEuzddcEWrMQQR5kM4w0EneJAuKO6JrWxrlDx3whhH5WlLHFn7/Na7ZBQG6KHU+kugKLTnU85N4U1CAvRpkduBJLsc6W210cdbI6UEwLmMDVYVGSBr+Tqit0z37iXceUUIResFxmtUFwhXEVbJknY6eFvS3mbyZ1ehUy3TDB+BoZvh5bIP+PVFK7+RdESwXb7CoHDXN+A6vELCk3GsWXHvZTsC8EWGFRo7WdIAwbe4Fie4TSO+spAr1MHl9yh8y8vF/CrPgavTtDjlwi87+igevhTPnTuUA/Iowdo9D9cYdi12yjiSqmVJYxo9HTLeykJ821w40AcgA==; 5:XEQfbUd0N0gerccqiSHhJ5MVEj72MZng7lQGVACMMQPpjOMU0eYsvpJA+7ct3v+J7ZmGM4tA1g0oPbyjHmUsnjjAKFo/LLnlGBWqssllkFRnf4Fda81dhLzrXaoSRZBZmn5TuSaN3FTkw2Axln4ko9/ymBz6nCIuAdp+2kaV0uQ=; 7:OZK5Blo1zPC9hu47flBIIaw0p0TmyJUlAy6r5dxhzuqjGpuWks50ZZKfhW3+usP3shytdQ3jliFBZCwwEMJP0yfhXWuAZzA3vxdcOJtuuyrrWk3sUATetsJp3SLMxtrRj7QPlWiF7rm4+yMz5w80mA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 1c989ab7-f8de-40a7-0310-08d63b40fc16 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:HE1PR0701MB2076; x-ms-traffictypediagnostic: HE1PR0701MB2076: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(166708455590820)(158342451672863)(788757137089)(248295561703944)(37575265505322); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(148016)(149066)(150057)(6041310)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:HE1PR0701MB2076; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2076; x-forefront-prvs: 083751FCA6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(396003)(346002)(39860400002)(366004)(376002)(136003)(189003)(199004)(51444003)(13464003)(446003)(53546011)(6486002)(6436002)(6512007)(3846002)(6116002)(256004)(14444005)(14454004)(229853002)(966005)(97736004)(6306002)(93886005)(316002)(33656002)(478600001)(2501003)(6246003)(83716004)(5660300001)(36756003)(53936002)(5250100002)(4326008)(25786009)(2900100001)(71200400001)(71190400001)(486006)(86362001)(345774005)(99286004)(66066001)(2616005)(476003)(6506007)(186003)(8676002)(102836004)(26005)(82746002)(2906002)(81156014)(81166006)(110136005)(8936002)(7736002)(11346002)(68736007)(106356001)(44832011)(305945005)(76176011)(105586002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2076; H:HE1PR0701MB2746.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-microsoft-antispam-message-info: +8g3z9HDREjHHxs2fRG7S7wjGVPP0ilU0A58AUaPflo/no2lE2TWTu2y/geLqhsJ7+8RgZ8KGIhppgzdrZI4ovNiOH95TlZ9V71i41fmgvIdTz5esCk8IcqaTQQbR/g9QWudJ928lVloIS5VYnYogjJwi8oLrDSD3Na/t7bv9eyTljOlu1zTdMPCl5Q/CwG18qlmIzIyZkfoFORBA/KvAuRT6ezFXul3DdeZkgZgfSaP9s/W3BZYF+cz/vXv4Wj36BLf2Fg2viCXC9KSSnRR0PyW++UN93RfLpkBytJ0bBaZFx+pXe1qJMRyLcPkz1dakPpd0MllkYhBy51Eu5r7HOrARZpk2cRnMWtHKQiM6Y0= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 1c989ab7-f8de-40a7-0310-08d63b40fc16 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2018 12:46:01.1029 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2076 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTURzHObv3zqs4Oi6nPwxLBwmJr6RgiaSBhGJJRYEo5JZeHzSn7Zql f8QSwpi6JDOdDzRfoILhIzXt5cDyESg+Mk2NMdMG1YJEs3S16zHov8/3cc7v8OOwlLSM8WIz NDmcVqNSy8UutDG+Ly+wxHU6MaTW4KrY3CimFJ9671KK9opNcSQV3VlTIY5uatoSnRMluISn cOqMXE4bfFLpkr5smKWyDfE3rbpBpENfLukRywI+Bj1dF/XIhZXiYQRL+hGGiA0E69MbYiKa RDD5qpASBI1LKZh5V41IUimCX2VLjsTZIVYRrG3KBBbjcJg02xiB3fEt+GjrpgWmsC901BhE Au/HJ2B+zoJIJwwaiitpwqeh988PJ4FpfBiaW14zwlslOAIK7mSTUWYEIwtYYGccCabV2t0r EfaG9dvtFBnlCQsrdbs+YAxNzyYowjKwWuwM6SfDzAeDE/HlMLX9aK/jDVN1RYjwezHMPPUj HAjfy8v3OmfB0vBzd0OARxH0WfoR2WkAFE4mkE4WLJbMO5FOMYLlxR2GBAehrcRMl6LQqv/e WuU4TuEj8HggmNjR0DlnRFV7m3tQZHYSWILdYNS4Qtcjpg3JeI6/kpkWGhrEaTOSeT5LE6Th crqQ46sM9fwO6UfWtVMmhFkkd5WMfZ5KlDKqXD4v04SApeTukjjBkqSo8vI5bVaS9rqa403o AEvLPSWKuO4EKU5T5XBXOS6b0/5LRayzlw49GbjxJtkQM3Rt1q3V1vZibDwgpd52zz+mWaTn wzyl21aN387DVLusekv5Va7bZhvfJmXFuBdfAI9QdaW1/3lUTeH5cQ+1DKeuTsTofV4eb22Z OpRWcMYX79gv+yjL12P9DPvsypDR2PyyyI6F+7XD3Ep+49Bg1Le1OqN7RIec5tNVR/0pLa/6 C7Sewe4mAwAA Archived-At: Subject: Re: [Ace] WGLC for draft-ietf-ace-oscore-profile 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, 26 Oct 2018 12:46:11 -0000 SGkgSmltLA0KDQpJdCBzb3VuZHMgbGlrZSB5b3UgYXJlIGFzc3VtaW5nIHRoYXQgdGhlIENsaWVu dCB3b3VsZCBoYXZlIHRvIHJlbWVtYmVyIG9ubHkgb25lIHNlY3VyaXR5IGNvbnRleHQsIGJ1dCBp dCBpcyBwb3NzaWJsZSB0aGF0IHRoZSBjbGllbnQgaGFzIHNldmVyYWwgKG9sZCkgc2VjdXJpdHkg Y29udGV4dHMgYXNzb2NpYXRlZCB3aXRoIG9uZSBhY2Nlc3MgdG9rZW4sIGZvciBleGFtcGxlIGlm IHRoZSBSUyBoYXMgcmVib290ZWQgc2V2ZXJhbCB0aW1lcy4gSXQgd291bGQgYmUgdW5yZWFzb25h YmxlIHRvIHJlcXVpcmUgdGhlIGNsaWVudCB0byBzdG9yZSBhbmQgY2hlY2sgYWxsIG9mIHRob3Nl IHdoZW4gZGVyaXZpbmcgYSBuZXcgb25lIChldmVuIGlmIGl0IGlzIGp1c3QgdGhlIG5vbmNlcyku IA0KDQpBbHNvLCBpdCBpcyBub3QgcmVxdWlyZWQgdGhhdCB0aGUgQVMgcHJvdmlkZXMgYSBuZXcg YWNjZXNzIHRva2VuIHRvIHRoZSBDbGllbnQsIGFzIGl0IG1heSBiZSBwcmUtZ2VuZXJhdGVkIGFu ZCBub3QgZXhwaXJlZC4gU28gaW4gdGhhdCBjYXNlLCBpZiB0aGUgY2xpZW50IGRvZXMgbm90IGtl ZXAgdHJhY2sgb2YgYWNjZXNzIHRva2VucyBhbmQgc2VjdXJpdHkgY29udGV4dHMgaXQgaGFzIHVz ZWQsIGl0IG1pZ2h0IGVuZCB1cCB3aXRoIHJldXNlZCBrZXlzIGFuZCBub25jZXMuDQoNCkZvciBi b3RoIHRoZXNlIHJlYXNvbnMsIHdlIHRoaW5rIHRoYXQgdGhlIGNsaWVudCBnZW5lcmF0ZWQgbm9u Y2UgaXMgbmVlZGVkLiBJZiB5b3UgYWdyZWUgd2l0aCB0aGF0LCB3ZSBjYW4gZGlzY3VzcyB3aGVy ZSB0byB0cmFuc3BvcnQgdGhlc2Ugbm9uY2VzLCBmb3IgZXhhbXBsZSB3ZSBjYW4gYXZvaWQgZWNo b2luZyBOMSBpZiB3ZSB1c2UgaXQgYXMgc2FsdC4gQWxzbywgYXMgeW91IHN1Z2dlc3RlZCwgaXQg c2VlbXMgbGlrZSBhIGdvb2QgaWRlYSB0byBtYWtlIHRoaXMgbWVjaGFuaXNtIG9wdGlvbmFsLiBX ZSBwcmVwYXJlIGZvciBkaXNjdXNzaW9uIGFib3V0IHRoaXMgaW4gQmFuZ2tvay4NCg0KVGhhbmtz LA0KRnJhbmNlc2NhDQoNCu+7v09uIDI1LzEwLzIwMTgsIDIzOjI1LCAiSmltIFNjaGFhZCIgPGll dGZAYXVndXN0Y2VsbGFycy5jb20+IHdyb3RlOg0KDQogICAgDQogICAgDQogICAgPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgID4gRnJvbTogRnJhbmNlc2NhIFBhbG9tYmluaSA8ZnJh bmNlc2NhLnBhbG9tYmluaUBlcmljc3Nvbi5jb20+DQogICAgPiBTZW50OiBUaHVyc2RheSwgT2N0 b2JlciAyNSwgMjAxOCA0OjQ3IEFNDQogICAgPiBUbzogSmltIFNjaGFhZCA8aWV0ZkBhdWd1c3Rj ZWxsYXJzLmNvbT47IGRyYWZ0LWlldGYtYWNlLW9zY29yZS0NCiAgICA+IHByb2ZpbGVAaWV0Zi5v cmcNCiAgICA+IENjOiBhY2VAaWV0Zi5vcmcNCiAgICA+IFN1YmplY3Q6IFJlOiBbQWNlXSBXR0xD IGZvciBkcmFmdC1pZXRmLWFjZS1vc2NvcmUtcHJvZmlsZQ0KICAgID4gDQogICAgPiBIaSBKaW0s DQogICAgPiANCiAgICA+IFRoYW5rIHlvdSBmb3IgeW91ciByZXZpZXcgY29tbWVudHMuIFdlIGFn cmVlIHdpdGggYWxsIHlvdXIgcG9pbnRzLCBhbmQNCiAgICA+IGhhdmUgb3BlbmVkIGlzc3Vlczog aHR0cHM6Ly9naXRodWIuY29tL2FjZS13Zy9hY2Utb3Njb3JlLXByb2ZpbGUvaXNzdWVzIHRvDQog ICAgPiBnZXQgdGhpcyBmaXhlZC4NCiAgICA+IA0KICAgID4gSW5saW5lIHNvbWUgZGV0YWlsZWQg YW5zd2VyLg0KICAgID4gDQogICAgPiBUaGFua3MsDQogICAgPiBGcmFuY2VzY2ENCiAgICA+IA0K ICAgID4gT24gMjIvMTAvMjAxOCwgMjE6MDksICJKaW0gU2NoYWFkIiA8aWV0ZkBhdWd1c3RjZWxs YXJzLmNvbT4gd3JvdGU6DQogICAgPiANCiAgICA+ICAgICAqIFNlY3Rpb24gMSAtIEkgdW5kZXJz dGFuZCB0aGUgcmVhc29uaW5nIGJlaGluZCBoYXZpbmcgdGhlIHNlcnZlciBzZW5kIGJhY2sNCiAg ICA+ICAgICBhIG5vbmNlLCBhbHRob3VnaCBpdCB3b3VsZCBiZSBnb29kIHRvIGhhdmUgYSBkZXNj cmlwdGlvbiBzb21lcGxhY2UgYWJvdXQNCiAgICA+IHdoeQ0KICAgID4gICAgIHRoaXMgaXMgYmVp bmcgZG9uZS4gIChJIHdvdWxkIGFsc28gbWFrZSBpdCBvcHRpb25hbCBhcyBub3QgYWxsIFJTIG5l ZWQgdG8gZG8NCiAgICA+ICAgICB0aGlzLikgIEkgZG8gbm90IHVuZGVyc3RhbmQgdGhlIHJlYXNv bmluZyBiZWhpbmQgaGF2aW5nIHRoZSBjbGllbnQgc2VuZCBhDQogICAgPiAgICAgbm9uY2UgdG8g dGhlIHNlcnZlci4NCiAgICA+IA0KICAgID4gRlA6IFRoZSBtb3RpdmF0aW9uIGZvciB0aGUgbm9u Y2UgY29uc3RydWN0aW9uIHdhcyBpbiB0aGUgc2VjdXJpdHkNCiAgICA+IGNvbnNpZGVyYXRpb25z LCBidXQgSSBhZ3JlZSB0aGF0IGhhdmluZyBpdCBpbiB0aGUgUHJvdG9jb2wgT3ZlcnZpZXcgbWFr ZXMNCiAgICA+IHNlbnNlLCBzbyBJIG9wZW5lZCBhbiBpc3N1ZSB0byBmaXggdGhhdC4gVGhlIHJl YXNvbiBiZWhpbmQgaGF2aW5nIHRoZSBjbGllbnQNCiAgICA+IGNyZWF0ZSBhIG5vbmNlIGlzIHRo YXQgd2UgYXJlIHByb3RlY3RpbmcgYWdhaW5zdCBhbiBhdHRhY2tlciByZXBsYXlpbmcgYW4gb2xk DQogICAgPiBSUyBtZXNzYWdlIChjb250YWluaW5nIGFuIG9sZCBub25jZSksIHdoaWNoIHdvdWxk IHByb3Zva2UgdGhlIGNyZWF0aW9uIG9mDQogICAgPiBhbiBvbGQgc2VjdXJpdHkgY29udGV4dCBv biB0aGUgQ2xpZW50LCBhbmQgcmV1c2Ugb2Yga2V5cyBhbmQgbm9uY2VzIGZvciBhDQogICAgPiBk aWZmZXJlbnQgKG5ldykgbWVzc2FnZS4NCiAgICANCiAgICBTbyB3aGF0IHlvdSBhcmUgbG9va2lu ZyBhdCBpcyBhIGNsaWVudCB3aGljaCBpcyBnb2luZyB0byAiZm9yZ2V0IiB0aGUgY3VycmVudCBz ZWN1cml0eSBjb250ZXh0IHRoYXQgaXQgcG9zc2Vzc2VzIGZvciBhbiBSUyBidXQgbm90IHRoZSB0 b2tlbiwgcmUtcG9zdGluZyB0aGUgdG9rZW4gdG8gdGhlIFJTIGJlY2F1c2UgaXQgYXBwYXJlbnRs eSB0aGlua3MgdGhhdCB0aGUgUlMgaGFzIGZvcmdvdHRlbiB0aGUgdG9rZW4gYW5kIGNvbnRleHQg d2l0aG91dCBhbmQgdGhlbiBhY2NlcHRpbmcgdGhlIHJlcGxheSBhcyBiZWluZyB2YWxpZC4gIA0K ICAgIA0KICAgIEkgdGhpbmsgdGhhdCBhIGNsaWVudCB3aGljaCBoYXMgZm9yZ290dGVuIHRoZSBz ZWN1cml0eSBjb250ZXh0IGlzIGFsc28gZ29pbmcgdG8gZm9yZ2V0IHRoZSB0b2tlbiBhbmQgdGh1 cyBuZWVkIGEgbmV3IG9uZS4NCiAgICBJIHRoaW5rIHRoYXQgYSBjbGllbnQgd2hpY2ggaXMgZ29p bmcgdG8gcmVtZW1iZXIgdGhlIHNlY3VyaXR5IGNvbnRleHQgaXMgYWxzbyBnb2luZyB0byByZW1l bWJlciB0aGUgbm9uY2UgZnJvbSB0aGUgc2VydmVyIGFuZCB0aHVzIG5vdCByZWJ1aWxkIHRoZSBj b250ZXh0IGlmIHRoZSBzYW1lIG5vbmNlIGNvbWVzIGJhY2suDQogICAgDQogICAgSWYgdGhpcyBu ZWVkcyB0byBiZSBleHBsaWNpdCAtIHRoZW4gaXQgc2hvdWxkIGJlIG1hZGUgc28uDQogICAgDQog ICAgPiANCiAgICA+ICAgICAqIFNlY3Rpb24gMy4xIC0gVGhpcyBpcyBtb3JlIGdlbmVyYWwgdGhh biB0aGUgc2VjdGlvbiwgYnV0IHlvdSBzaG91bGQgbm90DQogICAgPiAgICAgdXNlIHRoZSBVUkkg cGF0aCBpbiB0aGUgdGV4dCwgaW5zdGVhZCB5b3Ugc2hvdWxkIGJlIHVzaW5nIHRoZSBuYW1lIHRo YXQgaXMNCiAgICA+ICAgICBpbiB0aGUgYXV0aHogZG9jdW1lbnQuDQogICAgPiANCiAgICA+IEZQ OiBBZ3JlZWQsIGlzc3VlIG9wZW5lZCB0byBmaXggdGhpcy4NCiAgICA+IA0KICAgID4gICAgICog U2VjdGlvbiAzLjIgLSBEb2VzIGl0IHJlYWxseSBtYWtlIHNlbnNlIHRvIHVzZSAnQ09TRV9LZXkn IHRvIHRyYW5zcG9ydCB0aGUNCiAgICA+ICAgICBrZXkgZGF0YT8gIFdvdWxkIGEgZGlmZmVyZW50 IGZpZWxkIG5hbWUgYmUgYmV0dGVyPw0KICAgID4gDQogICAgPiBGUDogVGhpcyB3YXMgYnJvdWdo dCB1cCBzZXZlcmFsIHRpbWVzLCBzbyB3ZSB3aWxsIG1ha2UgdGhpcyBjaGFuZ2Ugbm93Lg0KICAg ID4gDQogICAgPiAgICAgKiBTZWN0aW9uIDMuMiAtIFBsZWFzZSBwcm92aWRlIGEganVzdGlmaWNh dGlvbiBmb3IgdGhlIHJlcXVpcmVtZW50IHRoYXQgdGhlDQogICAgPiAgICAgaWRzIG11c3QgYmUg dW5pcXVlIG92ZXIgdGhlIHNldCBvZiBhbGwgY2xpZW50cyBhbmQgUlMuICAgSSBjYW4gc2VlIHRo YXQgdGhlDQogICAgPiAgICAgY2xpZW50IGlkcyBuZWVkIHRvIGJlIHVuaXF1ZSBvbiBhIHNpbmds ZSBSUyBhbmQgUlMgaWRzIG5lZWQgdG8gYmUgdW5pcXVlIGZvcg0KICAgID4gICAgIGFueSBnaXZl biBjbGllbnQgYnV0IG5vdCB0aGUgYnJvYWRlciBzdGF0ZW1lbnQuDQogICAgPiANCiAgICA+IEZQ OiBZb3UgYXJlIHJpZ2h0LCB0aGlzIHJlcXVpcmVtZW50IGlzIHRvbyB3aWRlLiBXZSB3aWxsIHJl cGxhY2Ugd2l0aCB5b3VyDQogICAgPiBzdWdnZXN0aW9uLg0KICAgID4gDQogICAgPiAgICAgKiBQ bGVhc2UgYWRkIGFuIGV4cGxpY2l0IHNlY3Rpb24gb24gd2hlbiBhIFJTIGFuZCBhIGNsaWVudCBz aG91bGQgZGlzY2FyZA0KICAgID4gICAgIHRoZSBzZWN1cml0eSBjb250ZXh0Lg0KICAgID4gDQog ICAgPiBGUDogT2sgd2Ugd2lsbCBhZGQgdGhpcy4gQXMgbWVudGlvbmVkIGluIHRoZSBpc3N1ZSwg SSBoYXZlIG5vdyBvbmx5IHRoaXMgMw0KICAgID4gY2FzZXMgaW4gbWluZDogUGFydGlhbCBJViBz cGFjZSBlbmRzIChlaXRoZXIgQyBvciBSUyk7IHRoZSBraWQgY29udGV4dCBvbiB0aGUgUlMNCiAg ICA+IHNpZGUgZG9lcyBub3QgbWF0Y2ggd2l0aCBOMSAoUlMpOyBDIHJlY2VpdmVzIGEgbnVtYmVy IG9mIFVuYXV0aG9yaXplZCAoQyksDQogICAgPiBhbHRob3VnaCB0aGF0IGlzIGEgY29uc2lkZXJh dGlvbi9yZWNvbW1lbmRhdGlvbnMsIGRldGFpbHMgd291bGQgYmUNCiAgICA+IGFwcGxpY2F0aW9u IHNwZWNpZmljLiBEbyB5b3Ugc2VlIGFueSBvdGhlciBjYXNlIHJlbGV2YW50IGZvciB0aGlzIHNl Y3Rpb24/DQogICAgDQogICAgV2VsbCAtIHRoZXJlIGFyZSB0aGluZyBsaWtlIGV4cGlyYXRpb24g b2YgdGhlIHRva2VuIHdoaWNoIHdvdWxkIG1ha2Ugc2Vuc2UgYXMgd2VsbC4gICAgSWYgeW91IHJl LXJlZ2lzdGVyIHRoZSB0b2tlbiBiZWNhdXNlIG9mIGFuIHVuYXV0aG9yaXplZCBhbmQgZ2V0IGJh Y2sgYSBkaWZmZXJlbnQgbm9uY2UgdmFsdWUuDQogICAgDQogICAgPiANCiAgICA+ICAgICAqIFNl Y3Rpb24gNiAtIE9rIEknbGwgYml0ZSAgLSBob3cgZG9lcyBub3QgZWNob2luZyB0aGUgbm9uY2Ug YWxsb3cgZm9yIGENCiAgICA+ICAgICBtYW4taW4tdGhlLW1pZGRsZSBhdHRhY2sgZ2l2ZW4gdGhh dCB0aGUgc2FsdCBhbmQgc2hhcmVkIHNlY3JldCBhcmUgc3RpbGwNCiAgICA+ICAgICBnb2luZyB0 byBiZSBrbm93biBvbmx5IHRvIHRoZSBDIGFuZCBSUyBhbmQgbm90IHRvIHRoZSBNSVRNLiAgSSBj YW4gc2VlIGENCiAgICA+IERPUw0KICAgID4gICAgIGF0dGFjayBiZWluZyBtYWRlLCBidXQgdGhh dCBjYW4gYmUgZG9uZSBldmVuIHdpdGhvdXQgdGhpcyBqdXN0IGJ5IGNhdXNpbmcNCiAgICA+ICAg ICB0aGUgcmVzcG9uc2UgdG8gbmV2ZXIgYmUgZGVsaXZlcmVkLg0KICAgID4gDQogICAgPiBGUDog T2sgc28gb3VyIG1pc3Rha2UgaGVyZSBpcyB0byB1c2UgdGhlIHRlcm0gTWl0TSwgc28gdG8gc29s dmUgdGhpcyB3ZSB3aWxsDQogICAgPiByZXBsYWNlIHdpdGggIm9uLXBhdGggYXR0YWNrZXIiLiBU aGUgZm9sbG93aW5nIHNlbnRlbmNlIHNob3VsZCBiZSBjb3JyZWN0DQogICAgPiB3aXRoIHRoYXQg Zml4ICJNb3Jlb3ZlciwgdGhlIGNsaWVudCBlY2hvZXMgdGhlIG5vbmNlIGNyZWF0ZWQgYnkgdGhl IFJTLA0KICAgID4gd2hpY2ggdmVyaWZpZXMgaXQgYmVmb3JlIGRlcml2aW5nIHRoZSBTZWN1cml0 eSBDb250ZXh0LCBhbmQgdGhpcyBwcm90ZWN0cw0KICAgID4gYWdhaW5zdCBhbiBhZHZlcnNhcnkg YWN0aW5nIGFzIGFuIG9uIHBhdGggYXR0YWNrZXIgYW5kIHN1YnN0aXR1dGluZyB0aGUgbm9uY2UN CiAgICA+IGluIHRyYW5zaXQgZnJvbSBjbGllbnQgdG8gUlMgdG8gcHJvdm9rZSB0aGUgY3JlYXRp b24gb2YgZGlmZmVyZW50IFNlY3VyaXR5DQogICAgPiBDb250ZXh0cyBpbiB0aGUgY2xpZW50IGFu ZCBSUy4iIFllcyB0aGlzIGlzIGEgRE9TLCBidXQgY291bGQgYWxzbyBsZWFkIHRvIHJldXNlDQog ICAgPiBvZiBrZXlzIGFuZCBub25jZXMsIGFzIG1lbnRpb25lZCBiZWZvcmUuDQogICAgDQogICAg U2VlIG15IGFib3ZlIGNvbW1lbnQuICBCdXQgdGhlcmUgYXJlIG5vIHByb2JsZW1zIGhlcmUgd2l0 aCB0aGUgc2VydmVyIGRvaW5nIGFueXRoaW5nIGludGVyZXN0aW5nIGFzIGl0IHdvdWxkIHByZXN1 bWFibHkgbm90IGhhdmUgZ2VuZXJhdGVkIHRoZSBzYW1lIG5vbmNlIHZhbHVlIGFzIHRoZSBsYXN0 IHRpbWUuICBUaGlzIG1lYW5zIHRoYXQgdGhlIGNsaWVudCB3b3VsZCBnZW5lcmF0ZSBuZXcga2V5 cyBvbmx5IGlmIHRoZSBwcmV2aW91cyBjb21tZW50IHdhcyB3cm9uZy4NCiAgICANCiAgICBJIGp1 c3QgZG9uJ3Qgc2VlIHRoaXMgYXMgYmVpbmcgYSBwcm9ibGVtLiAgTWVyaXRzIGRpc2N1c3Npb24g aW4gQmFuZ2tvaw0KICAgIA0KICAgIEppbQ0KICAgIA0KICAgIA0KICAgID4gDQogICAgPiAgICAg KiBBcHBlbmRpeCAtIEkgYW0gbm90IHN1cmUgdGhhdCBJIHRoaW5rIHRoYXQgdGhlIEVESE9DIHBy b2ZpbGUgc2hvdWxkIGJlIGluDQogICAgPiAgICAgdGhpcyBkb2N1bWVudCBhcyBvcHBvc2UgdG8g YmVpbmcgaW4gaXQncyBvd24gZG9jdW1lbnQuICBUaGUgZmFjdCB0aGF0IHdlDQogICAgPiAgICAg aGF2ZSBub3QgZXZlbiB0cmllZCB0byBnZXQgdGhpcyB0byB3b3JrIGluIGFueSBvZiB0aGUgaW50 ZXJvcCB0ZXN0cyBtZWFucw0KICAgID4gICAgIHRoYXQgSSBhbSBsZXNzIHN1cmUgdGhhdCBpdCBp cyB3ZWxsIGJha2VkLg0KICAgID4gDQogICAgPiBGUDogQWdyZWVkLCB3ZSB3aWxsIHJlbW92ZSB0 aGlzIGZyb20gdGhpcyBkb2N1bWVudCBhbmQgbW92ZSBpdCB0byBpdHMgb3duDQogICAgPiBkb2N1 bWVudA0KICAgID4gDQogICAgPiAgICAgSmltDQogICAgPiANCiAgICA+IA0KICAgID4gICAgID4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCiAgICA+ICAgICA+IEZyb206IEFjZSA8YWNlLWJv dW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBKaW0gU2NoYWFkDQogICAgPiAgICAgPiBTZW50 OiBNb25kYXksIE9jdG9iZXIgOCwgMjAxOCAyOjM1IFBNDQogICAgPiAgICAgPiBUbzogYWNlQGll dGYub3JnDQogICAgPiAgICAgPiBTdWJqZWN0OiBbQWNlXSBXR0xDIGZvciBkcmFmdC1pZXRmLWFj ZS1vc2NvcmUtcHJvZmlsZQ0KICAgID4gICAgID4NCiAgICA+ICAgICA+IFRoZSBjaGFpcnMgYmVs aWV2ZSB0aGF0IHRoZSBzZXQgb2YgZG9jdW1lbnRzIGRlYWxpbmcgd2l0aCB0aGUgT0F1dGgNCiAg ICA+ICAgICA+IGZyYW1ld29yayBmb3IgY29uc3RyYWluZWQgZW52aXJvbm1lbnRzIGlzIG5lYXJp bmcgdGhlIHBvaW50IHRoYXQgd2UNCiAgICA+IHNob3VsZA0KICAgID4gICAgID4gYmUgYWJsZSB0 byBhZHZhbmNlIGl0IHRvIHRoZSBJRVNHIGZvciBwdWJsaWNhdGlvbi4gICBXZSB0aGVyZWZvcmUg d2FudCB0bw0KICAgID4gICAgID4gaGF2ZSBhIGZ1bGwgbGlzdCBvZiBpc3N1ZXMgdGhhdCBuZWVk IHRvIGJlIGRlYWx0IHdpdGggYXQgdGhlIEJhbmdrb2sNCiAgICA+ICAgICA+IG1lZXRpbmcuDQog ICAgPiAgICAgPg0KICAgID4gICAgID4gVGhpcyBzdGFydHMgYSAyIHdlZWsgV0dMQyBmb3IgZHJh ZnQtaWV0Zi1hY2Utb3Njb3JlLXByb2ZpbGUNCiAgICA+ICAgICA+DQogICAgPiAgICAgPiBXZSBr bm93IHRoYXQgdGhlIGZvbGxvd2luZyBpc3N1ZXMgYXJlIG91dHN0YW5kaW5nOg0KICAgID4gICAg ID4NCiAgICA+ICAgICA+IGRyYWZ0LWlldGYtYWNlLW9zY29yZS1wcm9maWxlOg0KICAgID4gICAg ID4gKiAgTm8gY3VycmVudCBrbm93biBpc3N1ZXMNCiAgICA+ICAgICA+DQogICAgPiAgICAgPg0K ICAgID4gICAgID4gSmltICYgUm9tYW4NCiAgICA+ICAgICA+DQogICAgPiAgICAgPg0KICAgID4g ICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAg ICA+ICAgICA+IEFjZSBtYWlsaW5nIGxpc3QNCiAgICA+ICAgICA+IEFjZUBpZXRmLm9yZw0KICAg ID4gICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UNCiAgICA+ IA0KICAgID4gDQogICAgDQogICAgDQogICAgDQoNCg== From nobody Fri Oct 26 11:09:53 2018 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 1C3E212D4E7 for ; Fri, 26 Oct 2018 11:09:52 -0700 (PDT) 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, 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 reAw1vnDDKvH for ; Fri, 26 Oct 2018 11:09:50 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18495128BCC for ; Fri, 26 Oct 2018 11:09:49 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CF09320008; Fri, 26 Oct 2018 14:09:45 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 76C6D25F0; Fri, 26 Oct 2018 14:09:48 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 760E725B0; Fri, 26 Oct 2018 14:09:48 -0400 (EDT) From: Michael Richardson To: Carsten Bormann cc: "ace\@ietf.org" In-Reply-To: <6FB6F67E-CC8A-442F-AFCC-DDC825D87FF3@tzi.org> References: <065b01d45f4e$b8d372a0$2a7a57e0$@augustcellars.com> <3B32C31E-11C3-4808-82DC-3C75C949A0E9@tzi.org> <877ei6tnwf.fsf@tzi.org> <10375.1540489291@localhost> <6FB6F67E-CC8A-442F-AFCC-DDC825D87FF3@tzi.org> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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] WGLC for draft-ietf-ace-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2018 18:09:52 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > On Oct 25, 2018, at 19:41, Michael Richardson = wrote: >> >> OAuth claim statements too confusing > Indeed, there is a problem there (as with many things inherited from = OAuth). > We might want to fix those issues for the purposes ACE, even if it > wasn=E2=80=99t in the domain for the ANIMA work. I should clarify, I think. It wasn't that OAUTH was confusing, but rather that mapping the standardized claim tags to what we needed did not seem to leverage very much. =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | network architect= [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlvTWGwACgkQgItw+93Q 3WVv7wf/YMYTxJIs2VydSPpSJ74JYO1lZMdOQNe02945zLuQkp6ceAZC96KysIHG VU4aAXBDDAYDKc7c2TUvubcIx8RLs2AKnmIjSEc/vt6N3P3NeKb9EqEe1D2yG6C3 jvDqMlIRrcscWlkpVrVwLv+g7rORllaXVkjUl7nZYwtCqLLLTkWIYKTjyY40vcDN O09V4teeLfo346fHh2OMJFhmv3phgbGpBDOkDcy1Gl9yJDQ2C4NsJgIkHpgABSZe EhiBawlZkWyTx1Z1GhXC9aH5kiljmI846xx3Lph5vLk8lM8xxu5PeM0iDO5GoqFG O0yNtHNnTBt3X2+2nVReT8Bl/3lMCQ== =C0w8 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Oct 29 01:48:27 2018 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 15342130DF6 for ; Mon, 29 Oct 2018 01:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.77 X-Spam-Level: X-Spam-Status: No, score=-4.77 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=KwNSMpqI; dkim=pass (1024-bit key) header.d=ericsson.com header.b=WO3GY1co Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzPOELAsFNoA for ; Mon, 29 Oct 2018 01:48:24 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 1CAC3130DF4 for ; Mon, 29 Oct 2018 01:48:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1540802901; x=1543394901; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ZYuV73c9MKuTNhhsH+wOdIavxQh8Ob8hx6rNvLdRvac=; b=KwNSMpqIWYnDr3Lf9oDYYsrNz/BzkpjW8mSXlLCj7cMGG4TZ1sskarBYamq5CV9q II72J1ZrfDSMhCIx+9ozCUVNbdtIZ10gcPoSkyfGw9G5K9a9YSrQh33cIDqnfCCY f7rDYExF+JdfIonPnc3KPRKocH5jSnqt9P3vGjPjnBg=; X-AuditID: c1b4fb30-671b09e000007d19-8a-5bd6c955d38f Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id D2.A3.32025.559C6DB5; Mon, 29 Oct 2018 09:48:21 +0100 (CET) Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 29 Oct 2018 09:48:20 +0100 Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 29 Oct 2018 09:48:20 +0100 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=ZYuV73c9MKuTNhhsH+wOdIavxQh8Ob8hx6rNvLdRvac=; b=WO3GY1coQTCJ5C7f0o2bQk9uoD+1RspDPz62UILcbdBGGG0iltdK0Jmr1qgHEAGL7DK3Kbs2C2nK3nDFgfW49HEr6rk1KFJ9jEQRPOjp3MuOpwOC3PT7xlB9LOBrEQPayBzfQQXdqYeUSqAU/XbTpJ4qWGC9ZTaZDSflpcrc/kc= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.188.140) by HE1PR0701MB2556.eurprd07.prod.outlook.com (10.168.187.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.14; Mon, 29 Oct 2018 08:48:19 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::5d31:ff09:b9ba:29c3]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::5d31:ff09:b9ba:29c3%9]) with mapi id 15.20.1294.015; Mon, 29 Oct 2018 08:48:19 +0000 From: Francesca Palombini To: Jim Schaad CC: 'ace' , "draft-palombini-ace-key-groupcomm@ietf.org" Thread-Topic: [Ace] Comments on ace key groupcomm -01 Thread-Index: AdQaKsDewY+WehuqT9eenvy1Jp1rRxVQcQsA Date: Mon, 29 Oct 2018 08:48:18 +0000 Message-ID: References: <013e01d41ad8$b2ce7540$186b5fc0$@augustcellars.com> In-Reply-To: <013e01d41ad8$b2ce7540$186b5fc0$@augustcellars.com> Accept-Language: en-GB, en-US Content-Language: en-US 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.80] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2556; 6:ZElik2LecwyGmNk8w09U6db4j0yQrogrJBolvn98ClMZLg3oNq5yu9Nr4sfXgVPNHkcuCAgBeCjNbNU/TBMNSrKuo6KMA6H3Ft0XjIYM9drk5danPBvpRDzMeHNTve4H6mJGXgmLXeiYThvztqI3PlB2j/oXNN3X/y/vGs1BPIBhcubOFbmQ5Ir76OtInBNYE8XAp0goe9Gu37uJpXI+9hNNm2jk3plgNYMaGbXLjCRLE+BitxzTE35+WifUQKklDlzK1FyVksvdUf5JblBfjUxnS6iLNbEP2hDbR17eJVGnm6MtxLsLKvK6glDHUWEZCaR2xiPmJ3fEPl5HdYlZZdQZ/TICATUo12POWmffA24X02a+61q/zIVmhwLIerDGQIsu7rVg4COvxxTwXZ0QQvSdMvap5uIj/1xKjLt4bsTp0pjSsTGlJUmdJYFuA60ySFq+yg4cTvZqfMwsZmfA2w==; 5:H4IhHzrYNASnooYmyzID5r9zUx4ll4APJ/eJP1cx5X75UWRx3eNnv93l7Uy27EwWGGdaATd5J0yjZ8wfRCXrX8doDXBmty6gI4pMxujvKQB1lsTp1RaQV9I5+QIYqXC6/A8/fglEzzPhBZnqfV5MaD+kANWrDL8PLNXuT8CL95w=; 7:ZUvSxg+RPJoCGtS/7ED6wkG6xCzgv3Hrc8UwxofZfzMB9/7hy6dxAjrBlvJ2lTjgOyw07F4PVLChJlv8gHU8DhiQFrOzfrrb+k5T95LsP89h/qpfAcHrsBue9d/xxHKYEBYQnn/4jVTrGv9MZ+scFw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 2b83e63f-95d6-46ee-0179-08d63d7b4665 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:HE1PR0701MB2556; x-ms-traffictypediagnostic: HE1PR0701MB2556: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(192374486261705); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231382)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:HE1PR0701MB2556; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2556; x-forefront-prvs: 084080FC15 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(39860400002)(136003)(396003)(366004)(189003)(199004)(186003)(82746002)(305945005)(44832011)(7736002)(86362001)(25786009)(81156014)(81166006)(8676002)(26005)(6506007)(106356001)(2900100001)(4326008)(256004)(102836004)(229853002)(105586002)(316002)(8936002)(68736007)(11346002)(446003)(476003)(486006)(2616005)(14444005)(53546011)(54906003)(6916009)(36756003)(478600001)(6306002)(6512007)(66066001)(33656002)(14454004)(53936002)(76176011)(6436002)(5250100002)(6486002)(83716004)(71200400001)(3846002)(6116002)(71190400001)(97736004)(99286004)(5660300001)(6246003)(2906002)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2556; H:HE1PR0701MB2746.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-microsoft-antispam-message-info: aKCoM9mvTrzMWpNGHv0C8zqtCL9R4PHLetmmDATnydHQd1e4mkUNYnIDDNhlnhP1G5RnEn/JFc43fzL+ATlokP7gn89HdaF6HKKkIrF/RKO4r5SPtOFQ3mELsxMpmjQGe6OkY+W/bmaBVmlWbcfya7lqdfK2r91Vbe3mIJAZwI7H8YIbFiOP2iQbwfL3rry6hirXsYaKae1SIt3ghalc76QgagKbhdwnZUlVQ4mYU3DhZbm1bER5HQPYSOKI8wTvMGpiKBOefFYM03DwmUicbw4ayUcwU2NlCXN7WS9dj0cAvSpWy0cO2R1wlLWyWlyxfXEBg9gto51GYe+wHsIwo4JBt4wS3VrQ9EtuZcQyqJg= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <9458E60D37D88D429B09C377DF48843C@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2b83e63f-95d6-46ee-0179-08d63d7b4665 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Oct 2018 08:48:18.9550 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2556 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTYRTHed6br+Lwad4OpmKDCCMvrYx9sLSM2oduH8pEP7Spr7rSKXu9 pERMQ6NZZql4SVHsLchV3rVGId6oSZmoiLeilRQLSaOlpBltvhP69jv/8z//8xx4WFJaRfux Gm02p9Oq02WMG1Ub15sXcs48lRBuG3JXrK7cJBVFI4NIYaxeZaJJZXt9NaMUhN/EGSLeLTKZ S9fkcrqwQyq3tBvF3VTWUNzltpJpQo+aYg3IlQW8H5qfCLQBubFSPIRgseg2JRYrCDYm+kmx EAgYbBgkHAWFy0nQj0w7Z2oIqFx965z5gmDs+TDhSGZwJIxZlmgHe+Fd0G2c2dRJnAN9bY3I gFjW0769d85HtETAy6fXKJHlUNP1gXQwhXfCe1MJ5bBLcBSUdsc4ZKkdr3+f30x0xdGw3GFC DkY4AGyFRlLc5AuzC42EeCcG4cU7UmRvsH7+S4v+JJicK3MR9SAQbHecHADjjaXIcRbgaQbe dFgYsRECy1VVzqCTcP/TL0I0mREUCyu02NgDrZ1rzqRMMFVsDZ+AspoGSuRAaLllocqRvO6/ x9bZ7yRxMLSawkRZCRXfml1E3gGVpZZNluBtYK5doJoQ3YK8eY5PzEiVy0M5nSaJ5zO1oVou uwPZP0t/13r4M2T9engAYRbJ3CX+r6YSpLQ6l8/PGEDAkjIvCX5tlyTJ6vwCTpd5QZeTzvED aDtLyXwlilOd8VKcqs7mLnFcFqfb6hKsq58eGVIqPa0aZlH9o94SVDt7JTQ4Vu5xvGKd75T2 3J1UKU77PmxInuP6VI+jHpVWpdUZIwrX5j/eKzzPjC8lnp1uVZIJVn3ssFChlPaMqujAfQfj UtaObjwYMfsWhEzkhOWPWn/GBBxh9Cm2Yx6KvBn/qxcT/8QfmCj3i/TxWGw/I6P4NPXe3aSO V/8DBYOeVSgDAAA= Archived-At: Subject: Re: [Ace] Comments on ace key groupcomm -01 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, 29 Oct 2018 08:48:26 -0000 SGkgSmltLA0KDQpUaGFua3MgYSBsb3QgZm9yIHlvdXIgZGV0YWlsZWQgcmV2aWV3LCBhcyB5b3Ug bWlnaHQgaGF2ZSBzZWVuIHdlIGhhdmUgaW5jbHVkZWQgbW9zdCBjb21tZW50cyBpbiB0aGUgbGF0 ZXN0IHZlcnNpb246IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1wYWxvbWJpbmkt YWNlLWtleS1ncm91cGNvbW0tMDIgDQpQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgdmVyc2lvbiBpbmNs dWRlcyBhbHNvIHJldmlldyBjb21tZW50cyBmcm9tIFBldGVyLCB3aGljaCBpbiBzb21lIGNhc2Vz IG92ZXJsYXBwZWQsIHNvIHNvbWUgdGV4dCBtaWdodCBiZSByZWZvcm11bGF0ZWQgdG8gaW5jbHVk ZSBib3RoIGlucHV0cy4NCg0KSW5saW5lLCBkZXRhaWxlZCBjb21tZW50cyBhbmQgc29tZSBxdWVz dGlvbnMuDQoNClRoYW5rcywNCkZyYW5jZXNjYQ0KDQpPbiAxMy8wNy8yMDE4LCAyMDozOCwgIkFj ZSBvbiBiZWhhbGYgb2YgSmltIFNjaGFhZCIgPGFjZS1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFs ZiBvZiBpZXRmQGF1Z3VzdGNlbGxhcnMuY29tPiB3cm90ZToNCg0KICAgICogU2VjdGlvbiAyIC0g Y2xpZW50ICAtIHdyaXRlIHJpZ2h0cyBhbmQvb3IgcmVhZCByaWdodHMuICBVbmxlc3MgeW91IHRo aW5rDQogICAgdGhhdCB3cml0ZSBpbXBsaWVzIHJlYWQgaW4gd2hpY2ggY2FzZSB5b3Ugc2hvdWxk IHN0YXRlIHRoYXQNCiAgICANCkZQOiBSaWdodCwgd2Ugbm93IHNwZWNpZnk6ICIgSXQgY2FuIHJl cXVlc3Qgd3JpdGUgYW5kL29yIHJlYWQgcmlnaHRzLiINCg0KICAgICogU2VjdGlvbiAyIC0gS0RD IC0gc2hvdWxkIGFsc28gc2F5IHdoYXQgaXQgZG9lcyBpbiB0aGUgbGF0ZXIgcGFydHMgLQ0KDQpG UDogT2ssIHdlIGFkZGVkIHRoZSBmb2xsb3dpbmcgdGV4dDogIiBEdXJpbmcgdGhlIHNlY29uZCBw YXJ0IChTZWN0aW9uIDQpLCB3aGljaCBpcyBub3QgYmFzZWQNCiAgICAgIG9uIHRoZSBBQ0UgRnJh bWV3b3JrLCBpdCBkaXN0cmlidXRlcyB0aGUga2V5aW5nIG1hdGVyaWFsLiIgV2UgYWxzbyBhZGRl ZCBkZXRhaWxzIGFib3V0IHRoZSByb2xlIG9mIHRoZSBLREMgZm9yIHJlZGlzdHJpYnV0aW9uIG9m IGtleWluZyBtYXRlcmlhbC4NCiAgICANCiAgICAqIFNlY3Rpb24gMiAtIERpc3BhdGNoZXIgLSBJ ZiB0aGlzIGlzIGEgYnVzLCB0aGVuIHlvdSBhcmUgbm90IHJlYWxseQ0KICAgIGNvbW11bmljYXRp bmcgd2l0aCBpdCBzZWN1cmVseS4gIEFueWJvZHkgY2FuIHdyaXRlIG9uIGl0LCBidXQgcGVvcGxl IHdpbGwNCiAgICBqdXN0IGlnbm9yZSB3aGF0IGNvbWVzIG91dCB0aGUgb3RoZXIgZW5kLg0KICAg IA0KRlA6IFJpZ2h0LCByZWZvcm11bGF0ZWQgaW4gIiBlbnRpdHkgdGhyb3VnaCB3aGljaCB0aGUg Q2xpZW50cyBjb21tdW5pY2F0ZSB3aXRoIHRoZQ0KICAgICAgZ3JvdXAgYW5kIHdoaWNoIGRpc3Ry aWJ1dGVzIG1lc3NhZ2VzIHRvIHRoZSBncm91cCBtZW1iZXJzLiINCg0KICAgICogU2VjdGlvbiAz LSAgQSBicmllZiBkZXNjcmlwdGlvbiBvZiBhbGwgb2YgdGhlIG9wZXJhdGlvbnMgd291bGQgYmUN CiAgICBhcHByZWNpYXRlZC4NCiAgICANCkZQOiB3ZSBoYXZlIG5vdyBhZGRlZCBzZXZlcmFsIHNl Y3Rpb25zIHRvIGRlc2NyaWJlIHRoZSBvcGVyYXRpb25zLiBJbiBzZWN0aW9uIDIgKHN0YXJ0aW5n IHdpdGggIiBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyB0aGUgbWVzc2FnZSBmbG93cyBhbmQgZm9y bWF0cyBmb3I6Iikgd2UgZGVzY3JpYmUgdGhlIGhpZ2ggbGV2ZWwgb3BlcmF0aW9ucy4gQXQgdGhl IGJlZ2lubmluZyBvZiBlYWNoIHNlY3Rpb24gKDMuIGFuZCA0Likgd2UgYWxzbyBnaXZlIGFuIG92 ZXJ2aWV3IG9mIHRoZSBleGNoYW5nZSBkZXNjcmliZWQgaW4gdGhlIHN1YnNlY3Rpb25zLg0KDQog ICAgKiBTZWN0aW9uIDMuMSAtIENhbiBJIGdldCBhdXRob3JpemF0aW9uIGZvciBtdWx0aXBsZSBp dGVtcyBhdCBhIHNpbmdsZSB0aW1lPw0KICAgIA0KRlA6IEluIHRoZW9yeSwgaXQgd291bGQgYmUg cG9zc2libGUsIGFuZCB0aGF0IHdvdWxkIHJlcXVpcmUgdG8gY2hhbmdlIHRoZSBmb3JtYXQgb2Yg c2NvcGUsIGdvaW5nIGZyb20gWyBncm91cC1pZCwgW3JvbGUxLCByb2xlMl0gXSB0byBbIFtncm91 cC1pZDEsIGdyb3VwLWlkMl0sIFtbcm9sZTEsIHJvbGUyXSwgW3JvbGUxXV0gXS4gV2UgaGF2ZW4n dCBpbXBsZW1lbnRlZCB0aGlzIGNoYW5nZSwgYmVjYXVzZSBpdCBzZWVtcyB0byBjYXVzZSBhIGxv dCBvZiBvdmVyaGVhZCBhbmQgY29tcGxleGl0eSwgZm9yIHdoYXQgc2VlbXMgdG8gYmUgYSBjb3Ju ZXIgY2FzZS4gQnV0IGlmIHBlb3BsZSB0aGluayB0aGlzIGlzIGEgdmFsaWQgdXNlIGNhc2UsIHdl IGNhbiByZWNvbnNpZGVyLiBXZSBoYXZlIGFkZGVkIGEgcGxhY2Vob2xkZXIgY29tbWVudCBpbiB0 aGUgbWQgZm9yIHRoaXMuDQoNCiAgICAqIFNlY3Rpb24gMy4xIC0gRG9lcyBpdCBtYWtlIHNlbnNl IHRvIGFsbG93IGZvciBtdWx0aXBsZSBhdWRpZW5jZXMgdG8gYmUgb24NCiAgICBhIHNpbmdsZSBL REM/ICANCiAgICANCkZQOiBJIGFtIG5vdCBzdXJlIEkgdW5kZXJzdGFuZCB0aGUgc2NlbmFyaW8s IGNvdWxkIHlvdSBleHBhbmQgb24gdGhpcz8gKFdlIGhhdmUgYWRkZWQgYSBjb21tZW50IGluIHRo ZSBtZCBmb3IgdGhpcyBhcyB3ZWxsKQ0KDQogICAgKiBTZWN0aW9uIDQueCAgLSBjbmYgLSB0ZXh0 IGRvZXMgbm90IGFsbG93IGZvciBrZXkgaWRlbnRpZmllcg0KICAgIA0KRlA6IERpZCB5b3UgZ2V0 IHRoZSBzZWN0aW9uIHdyb25nPyBJbiA0Lnggd2UgZG8gbm90IHVzZSBjbmYuIEluIHdoaWNoIHNl Y3Rpb24gZXhhY3RseSB3b3VsZCB5b3Ugc2VuZCB0aGUga2lkIGluIHRoZSBjbmY/IFRoYXQgc2hv dWxkIGJlIGRlZmluZWQgaW4gdGhlIEFjZSBmcmFtZXdvcmsgKGFuZCBwYXJhbXMpLi4uDQoNCiAg ICAqIFNlY3Rpb24gWC5YIC0gRGVmaW5lIGEgbmV3IGNuZiBtZXRob2QgdG8gaG9sZCB0aGUgT1ND T1JFIGNvbnRleHQNCiAgICBwYXJhbWV0ZXJzIC0gc2hvdWxkIGl0IGJlIGEgbm9ybWFsIENPU0Vf S2V5IG9yIHNvbWV0aGluZyBuZXcganVzdCB0byBtYWtlcw0KICAgIHN1cmUgdGhhdCBpdCBpcyBk aWZmZXJlbnQuDQogICAgDQpGUDogVGhpcyBpcyB0aGUgc2FtZSBjb21tZW50IGFzIGluIHRoZSBP U0NPUkUgUHJvZmlsZS4gQWdhaW4sIEkgYW0gbm90IHN1cmUgd2h5IHdlIHJlYWxseSBuZWVkIGEg bmV3IHN0cnVjdHVyZSBzaW5jZSBDT1NFX0tleSBpcyBnZW5lcmFsIGVub3VnaCB0byB0cmFuc2Zl ciBhbGwgdGhlIGtleWluZyBtYXRlcmlhbCwgd2l0aCB0aGUgYWRkaXRpb24gb2YgdGhlIGNvdXBs ZSBvZiBuZXcgcGFyYW1ldGVycyBkZWZpbmVkLiBCdXQgaWYgeW91IHRoaW5rIHRoaXMgaXMgbmVj ZXNzYXJ5LCB3ZSBjYW4gZGVmaW5pdGVseSBjaGFuZ2UuDQoNCiAgICAqIFNlY3Rpb24gMy5YIC0g SSBhbSBub3Qgc3VyZSBpZiB3cml0ZSBvciBQT1NUIGlzIGEgYmV0dGVyIGFuc3dlciBmb3Igd2hh dA0KICAgIHRoZSByb2xlIGJlaW5nIHJlcXVlc3RlZCBpcy4NCg0KRlA6IEFnYWluLCBJIGRvbid0 IHVuZGVyc3RhbmQgdGhpcyBjb21tZW50LiBXZSBkb24ndCByZWFsbHkgZGVmaW5lIHdoYXQgb25l IHNob3VsZCB1c2UgYXMgcm9sZSwgd3JpdGUgb3IgUE9TVCBhcmUgYm90aCBwb3NzaWJsZS4NCiAg ICANCiAgICAqIFNlY3Rpb24gNCAtIFNob3VsZCBvbmUgdGFsayBhYm91dCB0aGUgYWJpbGl0eSB0 byB1c2UgT0JTRVJWRSBhcyBwYXJ0IG9mDQogICAga2V5IGRpc3RyaWJ1dGlvbj8NCiAgICANCkZQ OiBXZSBhZGRlZCBhIGNvbW1lbnQgYXMgYSBwbGFjZWhvbGRlciBmb3IgdGhpcyBpbiB0aGUgbWQu IE9ic2VydmUgd2FzIGp1c3QgYnJpZWZseSBtZW50aW9uZWQgYmVmb3JlIGFuZCBub3QgcmVhbGx5 IGVsYWJvcmF0ZWQuIEFsdGhvdWdoIGl0IHdvdWxkIHdvcmssIGl0IHNlZW1zIG5vdCB1c2VmdWwg dG8gaGF2ZSBpdCB0b2dldGhlciB3aXRoIGEgcHJvcGVyIHJla2V5aW5nIHNjaGVtZSB3aGVyZSB0 aGUgS0RDIHRha2VzIHRoZSBpbml0aWF0aXZlIGFueXdheS4NCg0KICAgICogU2VjdGlvbiA0Lngg LSBJIGFtIGhhdmluZyBhIGhhcmQgdGltZSB0cnlpbmcgdG8gZmlndXJlIG91dCB0aGUgZGlmZmVy ZW5jZQ0KICAgIGJldHdlZW4gYSBncm91cCBhbmQgYSB0b3BpYy4gIFRoZSB0ZXh0IGRvZXMgbm90 IGFsd2F5cyBzZWVtIHRvIGRpc3Rpbmd1aXNoDQogICAgdGhlc2Ugd2VsbC4NCg0KRlA6IEl0IHdh cyBvdXIgcHVycG9zZSB0byBrZWVwIHRoZSB0ZXh0IGhpZ2ggbGV2ZWwgZW5vdWdoIHNvIHRoYXQg aXQgd291bGQgYXBwbHkgdG8gYm90aC4gRG9lcyB0aGF0IGNyZWF0ZSBhbnkgcHJvYmxlbS9jb25m dXNpb24/DQogICAgDQogICAgKiBTZWNpdG9uIDQuMSAtIFBPUCBvbiBjbGllbnQga2V5ICBlc3Ag aWYgYm91bmQgdG8gYW4gaWRlbnRpdHkgKE5vdGUgdXNpbmcNCiAgICBpdCB0byBhY2Nlc3MgdGhl IEtEQyBpcyBvbmUgUE9QKQ0KDQpGUDogTm93IGFkZGVkIHRoZSBmb2xsb3dpbmcgdGV4dCBhdCB0 aGUgZW5kIG9mIHNlY3Rpb24gNC46ICIgTm90ZSB0aGF0IHByb29mLW9mLXBvc3Nlc3Npb24gdG8g YmluZCB0aGUgYWNjZXNzIHRva2VuIHRvIHRoZSBDbGllbnQJDQoJICAgaXMgcGVyZm9ybWVkIGJ5 IHVzaW5nIHRoZSBwcm9vZi1vZi1wb3NzZXNzaW9uIGtleSBib3VuZCB0byB0aGUgYWNjZXNzCQ0K CSAgIHRva2VuIGZvciBlc3RhYmxpc2hpbmcgc2VjdXJlIGNvbW11bmljYXRpb24gYmV0d2VlbiB0 aGUgQ2xpZW50IGFuZAkNCgkgICB0aGUgS0RDLiINCiAgICANCiAgICAqIFNlY3Rpb24gNC4yIC0g d2h5IG5vdCB1c2UgdGhlIGV4cCBmaWVsZCBmcm9tIE9BVVRIIGluIHRoZSByZXNwb25zZQ0KDQpG UDogdGhlIGV4cCBmaWVsZCBmcm9tIHRoZSBBUyBpbiB0aGUgcmVzcG9uc2UgcmVsYXRlcyB0byB0 aGUgdG9rZW4uIFRoaXMgZXhwIHJlbGF0ZXMgdG8gdGhlIGtleWluZyBtYXRlcmlhbC4gWWVzLCB3 aGVuIHRoZSB0b2tlbiBleHBpcmVzIHRoZSBrZXlpbmcgbWF0ZXJpYWwgc2hvdWxkIGV4cGlyZSAo YW5kIHRoYXQgaXMgc3BlY2lmaWVkIGUuZy4gaW4gdGhlIE9TQ09SRSBwcm9maWxlKSwgYnV0IGl0 IGNvdWxkIGV4cGlyZSBiZWZvcmUvaW5kZXBlbmRlbnRseSBhcyB3ZWxsLg0KICAgIA0KICAgICog UXVlc3Rpb24gLSBkb2VzIHNvbWVib2R5IHRhbGsgYWJvdXQgZG9pbmcga2V5IGRlcml2YXRpb24g Zm9yIGEgbmV3IGtpZA0KICAgIHNob3dpbmcgdXAgYW5kIGJ5IHRoZSB3YXkgd2hlcmUgaXMgdGhl IGdpZA0KICAgIA0KRlA6IEl0J3MgaW4gb3Njb3JlLWdyb3VwY29tbSB0aGF0IHdlIGRlc2NyaWJl IGhvdyBhIG5ldyBSZWNpcGllbnQgQ29udGV4dCBpcyBkZXJpdmVkLiBUaGlzIGRvY3VtZW50IGtl ZXBzIGEgaGlnaCBsaXZlbCBwZXJzcGVjdGl2ZSAoc28gaXQgZG9lcyBub3QgdGFsayBhYm91dCBH aWQpLCB3aGlsZSBpbiBhY2Utb3Njb2FwLWpvaW4gd2UgZXhwbGFpbiBob3cgdGhlIGN1cnJlbnQg R3JvdXAgSUQgaXMgcHJvdmlkZWQgdG8gYSBqb2luaW5nIG5vZGUgKGluIHRoZSAnc2VydmVySUQn IHBhcmFtZXRlciBvZiB0aGUgQ09TRSBLZXkgaW4gdGhlIEpvaW4gUmVzcG9uc2UpLg0KDQogICAg KiBTZWNpdG9uIDQuMiAtIGlmIHlvdSBhcmUgdXNpbmcgcHJvZmlsZSwgdGhlbiB5b3Ugc2hvdWxk IHJldHVybiBpdA0KDQpGUDogVGhlIEtleSBkaXN0cmlidXRpb24gcmVxdWVzdCBhbmQgcmVzcG9u c2UsIGFsdGhvdWdoIGluc3BpcmVkIGJ5IEFDRSwgZG8gbm90IHVzZSBBQ0UsIHNvICJwcm9maWxl IiBpcyBub3QgcmVhbGx5IGRlZmluZWQgaGVyZS4gVGhlIHByb2ZpbGUgaXMgdXNlZCBpbiB0aGUg Zmlyc3QgcGhhc2UsIGJldHdlZW4gQyAtIEFTIC0gS0RDLCBhbmQgaXQgaXMgcmV0dXJuZWQgdGhl cmUuDQogICAgDQogICAgKiBJbnRyb2R1Y3Rpb24gLSBpbnRyb2R1Y2UgdGhlIGNvbmNlcHQgb2Yg YSBrZXkgbWFuYWdlbWVudCBwcm90b2NvbCBhbmQNCiAgICBwb2ludCB0byBzb21lLiAgR2l2ZSBz b21lIGJhc2ljIHByb3BlcnRpZXMgZXhwZWN0ZWQgZnJvbSBvbmUuDQogICAgDQpGUDogU29tZSB0 ZXh0IHdhcyBhZGRlZCBhdCB0aGUgZW5kIG9mIHRoZSBpbnRyb2R1Y3Rpb246ICIgICBJZiB0aGUg YXBwbGljYXRpb24gcmVxdWlyZXMgYmFja3dhcmQgYW5kIGZvcndhcmQgc2VjdXJpdHksIHVwZGF0 ZWQNCiAgIGtleWluZyBtYXRlcmlhbCBpcyBnZW5lcmF0ZWQgYW5kIGRpc3RyaWJ1dGVkIHRvIHRo ZSBncm91cCBtZW1iZXJzDQogICAocmVrZXlpbmcpLCB3aGVuIG1lbWJlcnNoaXAgY2hhbmdlcy4g IEEga2V5IG1hbmFnZW1lbnQgc2NoZW1lDQogICBwZXJmb3JtcyB0aGUgYWN0dWFsIGRpc3RyaWJ1 dGlvbiBvZiB0aGUgdXBkYXRlZCBrZXlpbmcgbWF0ZXJpYWwgdG8NCiAgIHRoZSBncm91cC4gIElu IHBhcnRpY3VsYXIsIHRoZSBrZXkgbWFuYWdlbWVudCBzY2hlbWUgcmVrZXlzIHRoZQ0KICAgY3Vy cmVudCBncm91cCBtZW1iZXJzIHdoZW4gYSBuZXcgbm9kZSBqb2lucyB0aGUgZ3JvdXAsIGFuZCB0 aGUNCiAgIHJlbWFpbmluZyBncm91cCBtZW1iZXJzIHdoZW4gYSBub2RlIGxlYXZlcyB0aGUgZ3Jv dXAuICBUaGlzIGRvY3VtZW50DQogICBwcm92aWRlcyBhIG1lc3NhZ2UgZm9ybWF0IGZvciBncm91 cCByZWtleWluZyB0aGF0IGFsbG93cyB0byBmdWxmaWxsDQogICB0aGVzZSByZXF1aXJlbWVudHMu ICBSZWtleWluZyBtZWNoYW5pc21zIGNhbiBiZSBiYXNlZCBvbiBbUkZDMjA5M10sDQogICBbUkZD MjA5NF0gYW5kIFtSRkMyNjI3XS4iDQoNCiAgICAqIFNlY3Rpb24gNS4yIC0gV2hhdCBpcyB0aGUg bWVzc2FnZSB0byBsZWF2ZSAtIGNhbiBJIGxlYXZlIG9uZSBzY29wZSBidXQgbm90DQogICAgYW5v dGhlcj8gIENhbiBJIGp1c3QgZ2l2ZSB1cCBhIHJvbGU/DQoNCkZQOiBXZSBoYXZlIG5vdyBhZGRl ZCBhIFRCRDogZm9ybWF0IG9mIHRoZSBtZXNzYWdlIHRvIGxlYXZlIHRoZSBncm91cCBwbGFjZWhv bGRlciBpbiBTZWN0aW9uIDUuMi4gV2Ugd2lsbCBhZGRyZXNzIHRoaXMgaW4gYSBmdXR1cmUgdXBk YXRlLiBUaGUgbGVhdmUgaXMgaW50ZW5kZWQgcGVyIGdyb3VwLCBzbyBvbmUgc2NvcGUgYXQgdGhl IHRpbWUgbG9zaW5nIGFsbCB0aGUgcm9sZXMgaW4gdGhhdCBncm91cC4gR2l2aW5nIHVwIGEgc2lu Z2xlIHJvbGUgd2hpbGUgcmVtYWluaW5nIGluIHRoZSBncm91cCBkb2VzIG5vdCByZXF1aXJlIGFu eSBwYXJ0aWN1bGFyIGludGVyYWN0aW9uIHdpdGggdGhlIEdNLiBJdCdzIGp1c3Qgc3VmZmljaWVu dCB0byBzdG9wIGJlaGF2aW5nIGFzIHRoYXQgcm9sZS4NCiAgICANCiAgICAqIFNlY2l0b24gNi4x IC0gYXNzdW1lcyBzY29wZXMgYXJlIHVuaXF1ZSBhY3Jvc3MgYWxsIGF1ZGllbmNlcy4gIE9yIGFz c3VtZXMNCiAgICB0aGF0IEkgbG9vayB1cCB0aGUgY29ycmVjdCB0b2tlbiAtIHNob3VsZCBoYXZl IGFuIGFyZ3VtZW50IGFib3V0IHdoeSB0aGlzIGlzDQogICAgcG9zc2libGUgc28gdGhhdCBwZW9w bGUgY2FuIGltcGxlbWVudCBpdCByaWdodA0KICAgIA0KRlA6IFdlIGFscmVhZHkgaGFkIHRoZSBj aGVjayBmb3IgdGhlIGFjY2VzcyB0b2tlbiBmb3IgYSBmaXJzdCB0aW1lIGtleSBkaXN0cmlidXRp b24uIFdlIGhhdmUgYWRkZWQgdGhlIGZvbGxvd2luZyB0ZXh0IGluIHNlY3Rpb24gNi4yOiAidGhl IEtEQyByZWNlaXZpbmcgYSBLZXkgUmUtRGlzdHJpYnV0aW9uIFJlcXVlc3QgTVVTVCBjaGVjayB0 aGF0IGl0IGlzIHN0b3JpbmcgYSB2YWxpZCBBY2Nlc3MgVG9rZW4gZnJvbSB0aGF0IGNsaWVudCBm b3IgdGhhdCBzY29wZS4iIFdlIGFsc28gaGF2ZSBhZGRlZCBhIFRPRE86IGRlZmluZXMgZXJyb3Ig cmVzcG9uc2UgaWYgaXQgZG9lcyBub3QgaGF2ZSBpdCAvIGlzIG5vdCB2YWxpZC4gV291bGQgdGhh dCBiZSBlbm91Z2g/DQoNCiAgICAqIENvbW1lbnQgc29tZXdoZXJlIGFib3V0IGdldHRpbmcgc3Ry aWtlIHpvbmVzIHNldHVwIGNvcnJlY3RseSBmb3IgYSBuZXdseQ0KICAgIHNlZW4gc2VuZGVyIG9m IG1lc3NhZ2VzLiBQdHIgdG8gT1NDT1JFPw0KDQpGUDogU29ycnkgSSBkb24ndCB1bmRlcnN0YW5k IHdoYXQgeW91IG1lYW4gYnkgc3RyaWtlIHpvbmVzLiBDb3VsZCB5b3UgZXhwYW5kIG9uIHRoYXQ/ DQogICAgDQogICAgSmltDQogICAgDQogICAgDQogICAgDQogICAgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBBY2UgbWFpbGluZyBsaXN0DQogICAg QWNlQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9h Y2UNCiAgICANCg0KDQo= From nobody Mon Oct 29 03:33:08 2018 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 E8C0F130E44 for ; Mon, 29 Oct 2018 03:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.769 X-Spam-Level: X-Spam-Status: No, score=-4.769 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 header.b=Wb0U3QEI; dkim=pass (1024-bit key) header.d=ericsson.com header.b=ho0sDOsB Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e_9u4AjoWR2B for ; Mon, 29 Oct 2018 03:33:04 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A064412D4EE for ; Mon, 29 Oct 2018 03:33:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1540809180; x=1543401180; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=nIQgj/llbKKiDHUlFRMxx2cP3bNUqKkNrdmsh60TFgw=; b=Wb0U3QEIWbk02HV0If5ejqu1ruIOFz1tkPqqIBUTKOBBz4W3KQRUfxYxdPterP3p 7ywT7WamynLurphC3kFWxV6m07pHJoXeM2nig1qjRIXq2Rbn5j0Ez5ZlVjRViYFy CFHTJpcHx7x+ViV4j5O9k//yz0k6AjAahJ9JWCDnG8w=; X-AuditID: c1b4fb2d-887c49e00000434d-fb-5bd6e1dc44ad Received: from ESESBMB503.ericsson.se (Unknown_Domain [153.88.183.116]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A7.8E.17229.CD1E6DB5; Mon, 29 Oct 2018 11:33:00 +0100 (CET) Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 29 Oct 2018 11:32:57 +0100 Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 29 Oct 2018 11:32:57 +0100 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=eKReAUG4NrHH/yoHFjvLhGgluxVuwDul3FjRZUgY2KU=; b=ho0sDOsBYDfLIhO5C3bPk7LiHRdsDWfjWiDZsTVZ08HNleJ/I3Et0bLNz7TMmqLhKi6yEix9G4GHsKTBdsvScbjyBdSjk81Or7ULqHr5T0HL28RVKYFU+ihPPh9vGi6+PunOJOI5KcwZKR212Xz/SWMmnRHKVV/rzLH/1TP73Sc= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.188.140) by HE1PR0701MB1819.eurprd07.prod.outlook.com (10.167.247.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.9; Mon, 29 Oct 2018 10:32:56 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::5d31:ff09:b9ba:29c3]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::5d31:ff09:b9ba:29c3%9]) with mapi id 15.20.1294.015; Mon, 29 Oct 2018 10:32:56 +0000 From: Francesca Palombini To: "consultancy@vanderstok.org" , "ace@ietf.org" Thread-Topic: [Ace] Fwd: review of palombini-ace-key-groupcomm Thread-Index: AQHUKKvCA6RzdvdPhEiSI6h3vJK40KU2pO2A Date: Mon, 29 Oct 2018 10:32:55 +0000 Message-ID: <1AE4350A-DF53-49AE-A209-A04CB488215C@ericsson.com> References: <23af2ffc9ec791bec0653d4a5baab467@bbhmail.nl> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.176.1.80] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB1819; 6:B38b4Iek8/1O7jtbQFTJrWVq9jOpwUGaxGa/YXihrkIzILXFzbEK2pBiYxXZsy7oCtlSgx+pbdPisJBJVYUa0wXBdIWqm3dKp4hzakbXKDl5g66IPy8quzfPgwasatPbnObU1upLV7gz0CtyUH+5eIQlfVjGm/+uPrgfNgDQizSU0iKyaT3POdCMAPBtyK0EPQo8Tbnu1BPJMAEKGLjZUWZZGmBqlFPeP1iTbI1UueOVl/r2D3NiCJHTgunG63I+qocH7YUz6honYEjs8IsovYOHmx8LZwd40FBBXKZMwIOvweScY8dA+BJCTTJNxzmgWfAnWBV2kjR17YO4JkNomW4wuPliiKPGNJFYwsUoQpdMLUPfyAoffjbgGP4aHqxASQlIQScVJ0rrIrf2O3lA4TwNo0GKH8jozi90zxQ+Bk8BULhWOa2SrZk52xXgpwE6GgZx4N0gt7ltp8IjUaR3hg==; 5:Va0skRIvKVSl3O4DCd/LJCtIFInWJossIG1E+rGHK1ROmJ1EGgcZCIU9RfkfWMF7N6gtBAXeNCgKmrO8GHpoFqw6R28kzEPF/qbS6xpVLTtOestsiZBqDsKfG4b7LkEvucZ9LKTjFM2C7SM37qTgwoJwEQ9yTN6qmnb18fKYk00=; 7:BnZImexOlBS2Vx5qmkPNpg8yC7t3TYr/EKtPFZaifeHII52IuArgkc38HetMg70aaOxkA/Baexk3pj+h76RcxoDqHtHkl+SwwtgosZviyXewI5tJlpTb1F6dBgp6Qaj5ZFfAmKUy5qbIPjQI319yOw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 60e7c6a4-23e1-4e55-9fa0-08d63d89e3d1 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:HE1PR0701MB1819; x-ms-traffictypediagnostic: HE1PR0701MB1819: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155)(28532068793085)(190501279198761)(227612066756510); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231382)(944501410)(4983020)(52105095)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:HE1PR0701MB1819; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB1819; x-forefront-prvs: 084080FC15 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(376002)(39860400002)(396003)(346002)(199004)(189003)(129404003)(76176011)(476003)(2616005)(11346002)(33656002)(446003)(36756003)(229853002)(790700001)(6116002)(486006)(82746002)(3846002)(26005)(110136005)(99936001)(7736002)(478600001)(66066001)(53386004)(99286004)(83716004)(2900100001)(71190400001)(71200400001)(68736007)(4744004)(316002)(186003)(6506007)(9326002)(25786009)(6306002)(54896002)(97736004)(6436002)(8936002)(14454004)(8676002)(733005)(256004)(54556002)(606006)(14444005)(105586002)(53936002)(2906002)(6486002)(6246003)(5250100002)(44832011)(81166006)(81156014)(102836004)(2501003)(53946003)(86362001)(5660300001)(6512007)(236005)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB1819; H:HE1PR0701MB2746.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-microsoft-antispam-message-info: D3/szpb4PbqFoMFU0TYpIAn9AkkVa9WpBvVhSf6rSCB8uptlehhusmTRLHahlN6U1jQYRs2JEhgT3I+flDjlsFIY7Ku5tTPQ9IyHlF/+rvkN5RWDfp2Qt8DbJoN4aZKxRPSpF9Uf6DbHv9QXrsn5N0wA+Qv2kBY0o0dMYAV3REMyzY9KyxpoM9XYNGYluymjeK2t944d7bmftcDL/XOIakArfKgIpgK1QP9/RxGfwbsMPKPvTbRc7A4Fh4ce0jfOKXAUqqNgkVG44v0JDb/UVkJgNddajUru/TRVTWf8Nme2gNyUfFQfv4IKTya+lqkzXggIA6fmSd+C2XXOdX/1H2SYipgTNj93BpTzR2dQRbU= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/related; boundary="_005_1AE4350ADF5349AEA209A04CB488215Cericssoncom_"; type="multipart/alternative" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 60e7c6a4-23e1-4e55-9fa0-08d63d89e3d1 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Oct 2018 10:32:56.0233 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB1819 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA22Se0hTYRjG+845OzuuFl/L4ZtR1NDualnZ3S70hyFFUERot5GHtNyUHQst KiOtTC1brnAaJm0Wjky7YEZWrstSUSydmoo2s8gJWeKtpOhs34yg/vu97/O87/e8h8PRChvr y8VoE3idVh2rYmVMzs6yhIB2R1PkwvbU+cuHhzLo5V1Pi9h1VJjJ9J0Ke51cJt1KRchWR/Gx MUd4XVDoPll0mnVQGn/7C5vY3/WESUYZzex55MUBXgIV33pElnEK/ALB7c9GmhRDCNpe5UpJ YaKgujjNrTA4iwZzdipDlCsU9OcWI1J8QmDuqJS4NrN4NdQ7+tzsjfdA+acyysWT8RoYSRlF pB8KjdVWsc+JHAz95jmuNoP9wX4zk3axHK+Fmqd69xoFjoGKMykSl90Lr4QLZ1e42ghPg4FT Fredxj7Q2p1Pkdu8wfGmxnOnEno+/JIQngGmgUtSwtPgbX66Oz7gFhaqzJ00EQLgq8Hg4c1w ubDWY2pAcMVWj4iwAEb7TrMkxX5obLvg2RoHF7P0DOHjUHHV5kk0HYoyHQxZ1EmDqd3BZqEg 41/JCZ+E0w162uj+AJOgKqebMYpH0+Ib5hvxBOfCnUeeyZmQne6QEp4DqXnXPBwG9zKymX89 Yuqh8+xYv81ukBjFRDQuRFCRl8+OmR7YnJL/DeeUt/xZantpp/4MG+72Skg40TQy9+/Z62hy EVIKvCBoDgQvDuR1MfsFIU4bqOUT7iLxl668PxrwEFl611sR5pBqgryksylSIVEfEZI0VuQn 7ukqsdQjX0Ybp+VV3nJnrSjLo9RJR3ld3F7d4VhesKKpHKPykQcWPY5Q4APqBP4Qz8fzujGV 4rx8k1FSznDpibSOM85thmMletnsuvGJE3rb/DTKoR7LrnNblOX59p9rbSW3sF0fUtrcvf1g ZUTk1IlLUz5utBbMShynqX6bsaNh05Rz77m6zlanMn1J+Fl1fNT2Z0Eq27IaS+kh/5GlBeGD PzQv/Jp/hU5MathQk1n8LtZp3e0VcnXVc32zihGi1Yvm0TpB/RsqJcfo2gMAAA== Archived-At: Subject: Re: [Ace] Fwd: review of palombini-ace-key-groupcomm 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, 29 Oct 2018 10:33:07 -0000 --_005_1AE4350ADF5349AEA209A04CB488215Cericssoncom_ Content-Type: multipart/alternative; boundary="_000_1AE4350ADF5349AEA209A04CB488215Cericssoncom_" --_000_1AE4350ADF5349AEA209A04CB488215Cericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUGV0ZXIsDQoNClRoYW5rcyBhIGxvdCBmb3IgdGhpcyBkZXRhaWxlZCByZXZpZXchIFdlIGhh dmUgdXBsb2FkZWQgYSBuZXcgdmVyc2lvbiB0aGF0IGluY2x1ZGVzIChtb3N0IG9mKSB5b3VyIGNv bW1lbnRzOmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1wYWxvbWJpbmktYWNlLWtl eS1ncm91cGNvbW0tMDINCg0KRGV0YWlsZWQgcmVwbGllcyBhbmQgc29tZSBxdWVzdGlvbnMgaW5s aW5lIChzZWUgRlAgaW4gcmVkIGJlbG93KS4NCg0KVGhhbmtzLA0KRnJhbmNlc2NhDQoNCkZyb206 IEFjZSA8YWNlLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmFjZS1ib3VuY2VzQGlldGYub3JnPj4g b24gYmVoYWxmIG9mIFBldGVyIHZhbiBkZXIgU3RvayA8c3Rva2NvbnNAYmJobWFpbC5ubDxtYWls dG86c3Rva2NvbnNAYmJobWFpbC5ubD4+DQpPcmdhbml6YXRpb246IHZhbmRlcnN0b2sgY29uc3Vs dGFuY3kNClJlcGx5LVRvOiAiY29uc3VsdGFuY3lAdmFuZGVyc3Rvay5vcmc8bWFpbHRvOmNvbnN1 bHRhbmN5QHZhbmRlcnN0b2sub3JnPiIgPGNvbnN1bHRhbmN5QHZhbmRlcnN0b2sub3JnPG1haWx0 bzpjb25zdWx0YW5jeUB2YW5kZXJzdG9rLm9yZz4+DQpEYXRlOiBUdWVzZGF5LCAzMSBKdWx5IDIw MTggYXQgMTA6NTINClRvOiBBY2UgV2cgPGFjZUBpZXRmLm9yZzxtYWlsdG86YWNlQGlldGYub3Jn Pj4NClN1YmplY3Q6IFtBY2VdIEZ3ZDogcmV2aWV3IG9mIHBhbG9tYmluaS1hY2Uta2V5LWdyb3Vw Y29tbQ0KDQpIaSBrZXktZ3JvdXBjb21tIGF1dGhvcnMsDQoNClRvIHN0YXJ0IHRoZSByZXZpZXcg SSBoYXZlIGxvb2tlZCBhdCB0aGUgZGVwZW5kZW5jaWVzIGJldHdlZW4gdGhlIGRpZmZlcmVudCBp bnZvbHZlZCBkcmFmdHMgYW5kIGNhbWUgdXAgd2l0aCB0aGUgZmlndXJlIGJlbG93Lg0KDQpbY2lk OjE1MzMwMjcxMDg1YjYwMjMyNDkxMTI4Nzk3ODI0NDI3QGJiaG1haWwubmxdDQpUaGUgYXJyb3dz IGluZGljYXRlIHRoYXQgYSBkcmFmdCByZWZlcmVuY2VzIGFub3RoZXIgZHJhZnQuIFRoZSBkb3Rz IHJlZmVyZW5jZSBhcnJvdyBtZWFucyBJbmZvcm1hdGl2ZSByZWZlcmVuY2UuIEFjY29yZGluZyB0 byBtZSwgdGhpcyBtZWFucyB0aGF0IHRoZSB3b3JrIG9uIENPUkUgY2FuIHByb2NlZWQgaW5kZXBl bmRlbnRseSBvZiB0aGUgd29yayBpbiBBQ0UuIFRoZSBvc2NvYXAtam9pbiBhbmQga2V5LWdyb3Vw Y29tbSBjYW4gcHJvY2VlZCB0b2dldGhlciB0byB0aGVpciBjb25jbHVzaW9uIHdpdGhvdXQgb3Ro ZXIgZGVwZW5kZW5jaWVzLiBUaGF0IGd1YXJhbnRlZXMgdGhhdCB3ZSBjYW4gZGV2ZWxvcCB0aGUg Z3JvdXAgY29tbXVuaWNhdGlvbiBkcmFmdHMgaW4gQUNFIHdpdGhvdXQgdW53YW50ZWQgZGVwZW5k ZW5jaWVzIG9uIHB1YnN1Yi4gVGhlIHB1YnN1Yi1wcm9maWxlIGRlcGVuZHMgb24gY29yZS1wdXN1 YiBhbmQga2V5LWdyb3VwY29tbSwgd2hpY2ggZG9lcyBub3QgYm90aGVyIG1lIHRvbyBtdWNoLg0K DQoNCkZQOiBUaGF0IGlzIGFic29sdXRlbHkgY29ycmVjdCwgdGhlIGdyb3VwIGNvbW11bmljYXRp b24gZHJhZnRzIGRvIG5vdCBkZXBlbmQgb24gdGhlIHB1YnN1YiB3b3JrLCBhbmQgY2FuIGJlIG1v dmUgZm9yd2FyZCB3aXRob3V0IGRlcGVuZGVuY2llcy4NCg0KS2VlcGluZyB0aGlzIGluIG1pbmQs IEkgaGF2ZSByZXZpZXdlZCB0aGUga2V5LWdyb3VwY29tbSBkcmFmdC4NCg0KQlRXLCBpdCBtaWdo dCBiZSBoZWxwZnVsIHRvIGluY2x1ZGUgYSBzaW1pbGFyIG92ZXJ2aWV3IGluIHRoZSBvc2NvYXAt am9pbiBkcmFmdC4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KDQpBYnN0cmFjdA0KT0xEOlRoaXMgZG9jdW1lbnQgZGVm aW5lcyBhIG1lc3NhZ2UgZm9ybWF0IGZvciBkaXN0cmlidXRpbmcga2V5aW5nDQptYXRlcmlhbCBp biBncm91cCBjb21tdW5pY2F0aW9uIHNjZW5hcmlvcyAoc3VjaCBhcyBiYXNlZCBvbiBtdWx0aWNh c3QNCm9yIHB1Ymxpc2hlci1zdWJzY3JpYmVyIG1vZGVsKSB1c2luZyB0aGUgQUNFIGZyYW1ld29y ay4NCg0KTkVXOlRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG1lc3NhZ2UgZm9ybWF0IGZvciBkaXN0 cmlidXRpbmcga2V5aW5nDQptYXRlcmlhbCB0byBncm91cHMgdG8gcHJvdGVjdCB0aGUgY29tbXVu aWNhdGlvbiBiZXR3ZWVuIGdyb3VwIG1lbWJlcnMgdXNpbmcgdGhlIEFDRSBmcmFtZXdvcmsuDQoN Cg0KRlA6IHdlIHN0YXJ0ZWQgd2l0aCB5b3VyIGlucHV0IGFuZCByZWZvcm11bGF0ZWQgdG86DQog ICBUaGlzIGRvY3VtZW50IGRlZmluZXMgbWVzc2FnZSBmb3JtYXRzIGFuZCBwcm9jZWR1cmVzIGZv ciByZXF1ZXN0aW5nDQogICBhbmQgZGlzdHJpYnV0aW5nIGdyb3VwIGtleWluZyBtYXRlcmlhbCB1 c2luZyB0aGUgQUNFIGZyYW1ld29yaywgdG8NCiAgIHByb3RlY3QgY29tbXVuaWNhdGlvbnMgYmV0 d2VlbiBncm91cCBtZW1iZXJzLg0KDQpJbnRyb2R1Y3Rpb24NCk9MRDogUHJvZmlsZXMgdGhhdCB1 c2UgZ3JvdXAgY29tbXVuaWNhdGlvbiBjYW4gYnVpbGQgb24gdGhpcyBkb2N1bWVudCB0byBzcGVj aWZ5IGV4YWN0bHkgd2hpY2ggb2YgdGhlIG1lc3NhZ2UgcGFyYW1ldGVycyBkZWZpbmVkIGluIHRo aXMgZG9jdW1lbnRzIGFyZSB1c2VkLCBhbmQgd2hhdCBhcmUgdGhlaXIgdmFsdWVzLg0KDQpORVc6 IFByb2ZpbGVzIHRoYXQgdXNlIGdyb3VwIGNvbW11bmljYXRpb24gY2FuIGJ1aWxkIG9uIHRoaXMg ZG9jdW1lbnQgdG8gc3BlY2lmeSBhIHNlbGVjdGlvbiBvZiB0aGUgbWVzc2FnZSBwYXJhbWV0ZXJz IGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBhbmQgdGhlaXIgdmFsdWVzLg0KDQoNCkZQOiB3ZSBp bmNsdWRlZCB0aGlzIHdpdGggdGhlIHNtYWxsZXN0IGRpZmZlcmVuY2U6DQogICBQcm9maWxlcyB0 aGF0IHVzZSBncm91cCBjb21tdW5pY2F0aW9uIGNhbiBidWlsZCBvbiB0aGlzIGRvY3VtZW50IHRv DQogICBzcGVjaWZ5IHRoZSBzZWxlY3Rpb24gb2YgdGhlIG1lc3NhZ2UgcGFyYW1ldGVycyBkZWZp bmVkIGluIHRoaXMNCiAgIGRvY3VtZW50IHRvIHVzZSBhbmQgdGhlaXIgdmFsdWVzLg0KDQoNCkF0 IHRoZSBlbmQgb2Ygc2VjdGlvbiAxOiAuLi4uIFtSRkM4MTUyXSwgbGlrZSBBdXRob3JpemF0aW9u IFNlcnZlciAoQVMpIGFuZCBSZXNvdXJjZSBTZXJ2ZXIgKFJTKS4NCkZQOiBPaywgYWRkZWQuDQoN Cg0KW2NpZDoxNTMzMDI3MTA4NWI2MDIzMjQ5MTNmZDM5NjMzNjIwMEBiYmhtYWlsLm5sXQ0KRmln dXJlIDEgaXMgbm90IHJlZmVyZW5jZWQgaW4gdGhlIHRleHQuIEkgc3VnZ2VzdCBhIHNsaWdodGx5 IGRpZmZlcmVudCBmaWd1cmUgd2hlcmUgZGlzcGF0Y2hlciBhbmQgS0RDIGFyZSBlbmRwb2ludHMg b2YgdGhlIFJTLCBhbmQgZm9yIG11bHRpY2FzdCB0aGUgY29tbXVuaWNhdGlvbiBpcyBkaXJlY3Rs eSBiZXR3ZWVuIENsaWVudCBhbmQgZ3JvdXAgbWVtYmVycyB3aXRob3V0IHBhc3NpbmcgdGhyb3Vn aCB0aGUgUlMuDQoNCg0KRlA6IFdlIGhhdmUgbm93IHJlZmVyZW5jZWQgdGhlIGZpZ3VyZSBpbiB0 aGUgdGV4dC4gV2UgaGF2ZSBub3QgbW9kaWZpZWQgdGhlIHBpY3R1cmVzLCBzaW5jZSB3ZSBhcmUg bm90IHN1cmUgdGhlIGNoYW5nZSBzaW1wbGlmaWVzIGl0LiBSZWFkaW5nIHRoZSBwcm9wb3NlZCBm aWd1cmUsIGl0IHNlZW1zIGxpa2UgS0RDIGFuZCBEaXNwYXRjaGVyIGFyZSBsb2dpY2FsIGVudGl0 aWVzIGluIHRoZSBzYW1lIHBoeXNpY2FsIGVudGl0eSAodGhlIFJTKSwgd2hpY2ggaXMgbm90IGNv cnJlY3QuDQpLZXkgRGlzdHJpYnV0aW9uIENlbnRlciAoS0RDKTogTWFpbnRhaW5zIHRoZSBrZXlp bmcgbWF0ZXJpYWwgdG8gcHJvdGVjdCBncm91cCBjb21tdW5pY2F0aW9ucywgYW5kIHByb3ZpZGVz IGtleXMgdG8gY2xpZW50cyBhdXRob3JpemVkIHRvIGpvaW4gdGhlIGdyb3VwLiBJdCBjb3JyZXNw b25kcyB0byBhbiBlbmRwb2ludCBvZiB0aGUgUlMgaW4gdGhlIEFDRSBGcmFtZXdvcmsuDQpGUDog V2UgaGF2ZSBub3cgcmVwaHJhc2VkIGJhc2VkIG9uIHlvdXIgYW5kIEppbXMgaW5wdXRzOg0KbyAg S2V5IERpc3RyaWJ1dGlvbiBDZW50ZXIgKEtEQyk6IG1haW50YWlucyB0aGUga2V5aW5nIG1hdGVy aWFsIHRvDQogICAgICBwcm90ZWN0IGdyb3VwIGNvbW11bmljYXRpb25zLCBhbmQgcHJvdmlkZXMg aXQgdG8gQ2xpZW50cw0KICAgICAgYXV0aG9yaXplZCB0byBqb2luIHRoZSBncm91cC4gIER1cmlu ZyB0aGUgZmlyc3QgcGFydCBvZiB0aGUNCiAgICAgIGV4Y2hhbmdlIChTZWN0aW9uIDM8aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBhbG9tYmluaS1hY2Uta2V5LWdyb3VwY29tbS0w MiNzZWN0aW9uLTM+KSwgaXQgdGFrZXMgdGhlIHJvbGUgb2YgdGhlIFJTIGluIHRoZSBBQ0UNCiAg ICAgIEZyYW1ld29yay4NCkFsc28sIGl0IGlzIHdvcnRoIG5vdGluZyB0aGF0IGluIHRoaXMgZG9j dW1lbnQgd2UgdXNlIHRoZSB0ZXJtIOKAnGVuZHBvaW504oCdIGFzIGRlZmluZWQgaW4gQUNFIChl cXVpdmFsZW50IHRvIOKAnHJlc291cmNl4oCdIGluIENvQVApLCB3aGljaCBpcyBkaWZmZXJlbnQg ZnJvbSB0aGUg4oCcZW5kcG9pbnTigJ0gdGVybSBpbiBDb1JFL0NvQVAuDQoNCkRpc3BhdGNoZXI6 IHRoaXMgaXMgdGhlIGVudGl0eSB0aGUgQ2xpZW50IHdhbnRzIHRvIHNlY3VyZWx5DQpjb21tdW5p Y2F0ZSB3aXRoIGFuZCBpcyByZXNwb25zaWJsZSBmb3IgZGlzdHJpYnV0aW9uIG9mIGdyb3VwDQpt ZXNzYWdlcy4gRXhhbXBsZSBkaXNwYXRjaGVycyBhcmUgdGhlIEJyb2tlciBpbiBhIHB1Yi1zdWIg c2V0dGluZyBvciB0aGUgZ2VuZXJhdG9yIG9mIHVuaWNhc3QgbWVzc2FnZXMgdG8gYWxsIGdyb3Vw IG1lbWJlcnMgZm9yIGdyb3VwIGNvbW11bmljYXRpb24uDQpBbHRlcm5hdGl2ZWx5LCBHcm91cCBj b21tdW5pY2F0aW9uIGlzIGRvbmUgYnkgdHJhbnNtaXR0aW5nIHRvIGEgbXVsdGljYXN0IElQIGFk ZHJlc3MsIGFuZCBlbnRydXN0aW5nIG1lc3NhZ2UgZGVsaXZlcnkgdG8gdGhlIHRyYW5zcG9ydCBj aGFubmVscyBiZXR3ZWVuIENsaWVudCBhbmQgR3JvdXAgbWVtYmVycy4NCg0KDQpGUDogV2UgZG9u 4oCZdCB0aGluayDigJxnZW5lcmF0b3LigJ0gaXMgdGhlIGJlc3Qgd29yZCwgdGhlIHRydWUgZ2Vu ZXJhdG9yIHdvdWxkIHN0aWxsIGJlIHRoZSBncm91cCBtZW1iZXIsIHNvIHdlIHJlcGxhY2VkIHRo YXQgd2l0aCByZWxheWVyLiBJbmNsdWRpbmcgdGhlIGNvbW1lbnRzIGZyb20gSmltLCB0aGlzIGdp dmVzOg0KICAgbyAgRGlzcGF0Y2hlcjogZW50aXR5IHRocm91Z2ggd2hpY2ggdGhlIENsaWVudHMg Y29tbXVuaWNhdGUgd2l0aCB0aGUNCiAgICAgIGdyb3VwIGFuZCB3aGljaCBkaXN0cmlidXRlcyBt ZXNzYWdlcyB0byB0aGUgZ3JvdXAgbWVtYmVycy4NCiAgICAgIEV4YW1wbGVzIG9mIGRpc3BhdGNo ZXJzIGFyZTogdGhlIEJyb2tlciBub2RlIGluIGEgcHViLXN1YiBzZXR0aW5nOw0KICAgICAgYSBy ZWxheWVyIG5vZGUgZm9yIGdyb3VwIGNvbW11bmljYXRpb24gdGhhdCBkZWxpdmVycyBncm91cA0K ICAgICAgbWVzc2FnZXMgYXMgbXVsdGlwbGUgdW5pY2FzdCBtZXNzYWdlcyB0byBhbGwgZ3JvdXAg bWVtYmVyczsgYW4NCiAgICAgIGltcGxpY2l0IGVudGl0eSBhcyBpbiBhIG11bHRpY2FzdCBjb21t dW5pY2F0aW9uIHNldHRpbmcsIHdoZXJlDQogICAgICBtZXNzYWdlcyBhcmUgdHJhbnNtaXR0ZWQg dG8gYSBtdWx0aWNhc3QgSVAgYWRkcmVzcyBhbmQgZGVsaXZlcmVkDQogICAgICBvbiB0aGUgdHJh bnNwb3J0IGNoYW5uZWwuDQoNCg0KV2hhdCBpcyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuICJhZGRp bmcgbm9kZSB0byBncm91cCIgYW5kICJkaXN0cmlidXRpb24gb2Yga2V5aW5nIG1hdGVyaWFsIi4g SSBmaW5kIHRoZSBwaHJhc2UgZGlmZmljdWx0IHRvIHVuZGVyc3RhbmQuDQoNCg0KRlA6IEFzc3Vt aW5nIHRoaXMgd2FzIGFib3V0IHRoZSB0aXRsZSBvZiBzZWN0aW9uIDQsIHdlIHJlcGhyYXNlZCB0 aGF0IHRvIOKAnEF1dGhvcml6YXRpb24gdG8gSm9pbiBhIEdyb3Vw4oCdLg0KDQpGaWd1cmUgMiA6 IEkgc3VnZ2VzdCB0byBhZGQgR3JvdXAgTWVtYmVyIChHTSkgYXMgY29tbXVuaWNhdGlvbiBlbnRp dHkuDQpGUDogR29vZCBpZGVhLCBpdCBpcyBub3cgaW5jbHVkZWQuDQoNCg0KQXQgdGhlIGVuZCBv ZiBzZWN0aW9uIDIsIEkgc3VnZ2VzdCBzb21lIHRleHQgb24gZ3JvdXAgaWRlbnRpZmllciBhbmQg cm9sZSBpZGVudGlmaWVyLCBzdWNoIHRoYXQgdGhlc2UgdGVybXMgY2FuIGJlIHVzZWQgaW5kZXBl bmRlbnQgb2YgdGhlIGFwcGxpY2F0aW9uIHByb2ZpbGVzIHNwZWNpZmllZCBpbiBvdGhlciBkb2N1 bWVudHMuDQoNCg0KRlA6IEkgYW0gbm90IHN1cmUgd2h5IGRvIHlvdSB0aGluayB0aGVzZSB0ZXJt cyAod2hpY2ggYXBwZWFyIGZpcnN0IGluIHNlY3Rpb24gMy4xKSBhcmUgbm90IGluZGVwZW5kZW50 IG9mIHRoZSBhcHBsaWNhdGlvbiBwcm9maWxlcyBzcGVjaWZpZWQgaW4gb3RoZXIgZG9jdW1lbnRz LiBDb3VsZCB5b3UgcGxlYXNlIGV4cGFuZCBvbiB0aGF0Pw0KDQpTZWN0aW9uIDMuDQoNClJlbW92 ZTogIndoZXJlIHRoZSBSREMgdGFrZXMgdGhlIHJvbGUgb2YgUlMiLg0KRlA6IE9rLCBkb25lLg0K DQpTdWdnZXN0IHRvIGFkZCB0aGUgbWVzc2FnZSBleGNoYW5nZSBiZWZvcmUgc2VjdGlvbiAzLjEN Cg0KUE9TVCAtLS0gQXV0aG9yaXphdGlvbiBSZXF1ZXN0IChhcHBsaWNhdGlvbi9DQk9SKSAtLS0t Pg0KPC0tIEF1dGhvcml6YXRpb24gUmVzcG9uc2UgKD8/Pz8gKSAtLS0tLQ0KDQoNCkZQOiBXZSBo YXZlIG5vdyBhZGRlZCBtZXNzYWdlIGV4Y2hhbmdlcyBhcyBzdWdnZXN0ZWQsIGFsdGhvdWdoIGZv ciBsYWNrIG9mIHNwYWNlIHdlIG9ubHkgaW5jbHVkZSBuYW1lIG9mIHRoZSBtZXNzYWdlLCBDb0FQ IENvZGUgb3IgTWV0aG9kIGFuZCB0aGUgdXJpIGlmIGFwcGxpY2FibGUuDQoNCkl0IHdvdWxkIGJl IG5pY2UgaWYgaGVyZSB0aGUgdXNlIG9mIERUTFMgKG9yIG5vdCkgYW5kIHRoZSBjb250ZW50IGZv cm1hdCBpcyBzcGVjaWZpZWQ6IGFwcGxpY2F0aW9uL2Nib3Igb3IgYXBwbGljYXRpb24vQ29zZStj Ym9yDQpGUDogdGhhdCB3b3VsZCByZWFsbHkgYmUgcHJvZmlsZSBzcGVjaWZpYywgc28gd2UgaGF2 ZSBub3Qgc3BlY2lmaWVkIGl0IGhlcmUuDQoNCg0Kc2VjdGlvbiAzLjENCnNjb3BlOiB3aXRoIGFz IHZhbHVlcyB0aGUgZ3JvdXAgaWRlbnRpZmllciBhbmQgb3B0aW9uYWxseSB0aGUgcm9sZSAuLi4u DQpGUDogYWRkZWQgb3B0aW9uYWxseS4NCg0KDQoiVGhlIGVuY29kaW5nIG9mIHRoZSBncm91cCBp ZGVudGlmaWVyIGFuZCB0aGUgcm9sZShzKSBpcyBhcHBsaWNhdGlvbiBzcGVjaWZpYy4iDQpGUDog dGhhbmtzLCByZXBocmFzZWQgdG8gbWF0Y2ggeW91ciBzdWdnZXN0aW9uOg0KICAgICAgVGhlIGVu Y29kaW5nIG9mIHRoZSBncm91cCBvciB0b3BpYyBpZGVudGlmaWVyIGFuZCBvZiB0aGUgcm9sZQ0K ICAgICAgaWRlbnRpZmllcnMgaXMgYXBwbGljYXRpb24gc3BlY2lmaWMuDQoNCg0KY25mOiBPcHRp b25hbGx5LCB0aGUgcHVibGljIGtleSBvciB0aGUgY2VydGlmaWNhdGUgb2YgdGhlIGNsaWVudA0K RlA6IFJpZ2h0LCB0aGFua3MNCg0KDQpRdWVzdGlvbjogaXMgdGhpcyBhIGNlcnRpZmljYXRlIGlk ZW50aWZpZXIsIG9yIHRoZSBwdWJsaWMga2V5IGV4dHJhY3RlZCBmcm9tIHRoZSBjZXJ0aWZpY2F0 ZSwgb3IgYSBoYXNoPz8/Pz8NCkZQOiBUaGlzIGlzIGRlZmluZWQgaW4gb3RoZXIgZG9jdW1lbnRz IG9mIEFDRSwgc2VlIGRyYWZ0LWlldGYtYWNlLWN3dC1wcm9vZi1vZi1wb3NzZXNzaW9uLTAzIHNl Y3Rpb25zIDMuMiBhbmQgMy40DQoNCg0Kc2VjdGlvbiAzLjI6DQowIGFjY2VzcyB0b2tlbiBjb250 YWluaW5nIGFsbCB0aGUgcGFyYW1ldGVycyBkZWZpbmVkIGJlbG93OyBUaGlzIGlzIHZlcnkgY29u ZnVzaW5nLiBJIHVuZGVyc3Rvb2QgdGhhdCBhY2Nlc3MgdG9rZW4gcGFyYW1ldGVyIGlzIGF0IHNh bWUgbGV2ZWwgYXMgY25mLCByc19jbmYsIGFuZCBleHAuIEFuZCBoZXJlIHlvdSB3cml0ZSB0aGF0 IHRoZXkgYXJlIGNvbnRhaW5lZCBpbiBhY2Nlc3MgdG9rZW4uIElmIHRoYXQgaXMgdHJ1ZSwgSSBz dWdnZXN0IHRvIG1ha2UgdGhlIG90aGVyIHRocmVlIHBhcmFtZXRlciBzdWItYnVsbGV0cyBvZiBh Y2Nlc3MtdG9rZW4gYnVsbGV0Lg0KRlA6IFdlIGhhdmUgdHJpZWQgdG8gaW1wcm92ZSB0aGlzIHRo ZSBmb2xsb3dpbmcgd2F5OiBUaGUgYWNjZXNzX3Rva2VuIGJ1bGxldCBvbmx5IHNheXMgdGhhdCBp dCBjb250YWlucyB0aGUgYWNjZXNzIHRva2VuLiBBZnRlciB0aGUgYnVsbGV0IGxpc3QgKGFuZCBh bGwgdGhlIHBhcmFtZXRlcnMgYXJlIGxpc3RlZCksIHdlIHNwZWNpZnk6DQogICBUaGUgYWNjZXNz IHRva2VuIE1VU1QgY29udGFpbiBhbGwgdGhlIHBhcmFtZXRlcnMgZGVmaW5lZCBhYm92ZQ0KICAg KGluY2x1ZGluZyB0aGUgc2FtZSAnc2NvcGUnIGFzIGluIHRoaXMgbWVzc2FnZSwgaWYgcHJlc2Vu dCwgb3IgdGhlDQogICAnc2NvcGUnIG9mIHRoZSBBdXRob3JpemF0aW9uIFJlcXVlc3Qgb3RoZXJ3 aXNlKSwgYW5kIGFkZGl0aW9uYWxseQ0KICAgb3RoZXIgb3B0aW9uYWwgcGFyYW1ldGVycyB0aGUg cHJvZmlsZSByZXF1aXJlcy4NCg0KDQpGb3IgdG9waWMgYW5kIHJvbGUgc2VlIHNlY3Rpb24gMy4x DQpGUDogT2ssIHNhbWUgZml4IGFwcGxpZWQuDQoNCnNlY3Rpb24gMy4zOg0Kc2FtZSByZXF1ZXN0 IHJlc3BvbnNlIGZpZ3VyZSBhcyBzdWdnZXN0ZWQgaW4gc2VjdGlvbiAzIGJlZm9yZSBzZWN0aW9u IDMuMQ0KRlA6IFRoaXMgaXMgcGFydCBvZiB0aGUgZmlndXJlIDMsIGluIHNlY3Rpb24gMy4NCg0K ImEgZGlmZmVyZW50IGVuZHBvaW50IiBpcyB2ZXJ5IHZhZ3VlLiBQbGVhc2UgZXhwbGFpbi4NCkZQ OiBSZXBocmFzZWQgdG86IOKAnHRoZSBDbGllbnQgTUFZIHVzZSBhIGRpZmZlcmVudCBlbmRwb2lu dCB0aGFuIC9hdXRoei1pbmZv4oCdDQpBZ2FpbiwgdGhpcyBkZXJpdmVzIGZyb20gdGhlIHVzZSBv ZiDigJxlbmRwb2ludOKAnSBhcyBBQ0UgZGVmaW5lcyBpdC4NCg0Kc2VjdGlvbiA0Og0KDQovVGhl IHNhbWUgdHlwZXMgb2YgbWVzc2FnZXMgY2FuIGFsc28gYmUvdGhlIHNhbWUgc2V0IG9mIG1lc3Nh Z2VzIGlzLw0KDQoNCkZQOiBQYXJ0bHkgaW5jbHVkZWQuIFdlIGtlZXAgdGhlIOKAnGNhbiBhbHNv IGJl4oCdLCBzaW5jZSB3ZSBsZWF2ZSBpdCB0byB0aGUgYXBwbGljYXRpb24gdG8gZGVjaWRlIHRv IHVzZSBvciBub3QgdXNlIHRoZXNlIG1lY2hhbmlzbXMuIFdlIHdhbnQgdG8gYWxsb3cgZm9yIGZs ZXhpYmlsaXR5Lg0KDQpqdXN0IGJlZm9yZSBzZWN0aW9uIDQuMSBzYW1lIGZpZ3VyZSBhbmQgaW5m b3JtYXRpb24gYXMgcmVxdWVzdGVkIGluIHNlY3Rpb24gMyBiZWZvcmUgc2VjdGlvbiAzLjENCkZQ OiBEb25lIG5vdyBpbiBzZWN0aW9uIDQsIHNlZSBmaWd1cmUgNC4NCg0KDQpzZWN0aW9uIDQuMQ0K Ii4uLi5yZXF1ZXN0IHRvIHRoZSBlbmRwb2ludCBpbiB0aGUgS0RDIGFzc29jaWF0ZWQuLi4iIE5v dCBjbGVhciB3aGF0IGlzIG1lYW50Og0KLSBvbmUgZW5kcG9pbnQgZm9yIGFsbCBncm91cHM/DQot IG9uZSBlbmRwb2ludCBwZXIgZ3JvdXA/DQotIG9uZSBlbmRwb2ludCBwZXIgc3Vic2V0IG9mIGdy b3Vwcz8NCg0KDQpGUDogV2UgbWVhbnQgb25lIGVuZHBvaW50IChvciByZXNvdXJjZSkgcHJlIGdy b3VwLCB3aGljaCB0aGUgQ2xpZW50IGtub3dzIHZpYSB0aGUgU2NvcGUgKGl0IGlzIOKAnGFzc29j aWF0ZWTigJ0gdG8gaXQpLiBXZSBkbyBub3Qgc2F5IHRoYXQgdGhlIGVuZHBvaW50IGhhcyB0aGUg c2FtZSB2YWx1ZSBhcyB0aGUgZ3JvdXAgaWRlbnRpZmllciwgaXQgbWlnaHQgYmUgc29tZXRoaW5n IGRlcml2ZWQgZnJvbSBpdC4gV2UgaGF2ZSBub3cgdHJpZWQgdG8gY2xhcmlmeSBieSByZXBocmFz aW5nOiAgVGhpcw0KICAgY29ycmVzcG9uZHMgdG8gYSBDb0FQIFBPU1QgcmVxdWVzdCB0byB0aGUg ZW5kcG9pbnQgaW4gdGhlIEtEQw0KICAgYXNzb2NpYXRlZCB0byB0aGUgZ3JvdXAgdG8gam9pbi4g IFRoZSBlbmRwb2ludCBpbiB0aGUgS0RDIGlzDQogICBhc3NvY2lhdGVkIHRvIHRoZSAnc2NvcGUn IHZhbHVlIG9mIHRoZSBBdXRob3JpemF0aW9uIFJlcXVlc3QvDQogICBSZXNwb25zZS4NCg0Kc2Nv cGU6IHJlbW92ZSB0b3BpYzsgd2hhdCByZXNvdXJjZSBpcyByZWZlcnJlZCB0bz8NCg0KDQpGUDog cmVwaHJhc2VkIHRvOg0KICAgbyAgJ3Njb3BlJywgd2l0aCB2YWx1ZSB0aGUgc3BlY2lmaWMgcmVz b3VyY2UgdGhhdCB0aGUgQ2xpZW50IGlzDQogICAgICBhdXRob3JpemVkIHRvIGFjY2VzcyAoaS5l LiBncm91cCBvciB0b3BpYyBpZGVudGlmaWVyKSBhbmQgcm9sZShzKSwNCiAgICAgIGVuY29kZWQg YXMgaW4gU2VjdGlvbiAzLjE8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBhbG9t YmluaS1hY2Uta2V5LWdyb3VwY29tbS0wMiNzZWN0aW9uLTMuMT4uDQoNCg0KZ2V0X3B1Yl9rZXlz OiBJbnN0ZWFkIG9mIGVtcHR5IENCT1IgYXJyYXksIGFuIGVtcHR5IHBheWxvYWQgaXMgYWxzbyBw b3NzaWJsZT8NCkZQOiBQcm9iYWJseSBwYXlsb2FkIGlzIHdyb25nLiBJZiB5b3UgbWVhbnQgZW1w dHkgYnl0ZSBzdHJpbmcsIHllcyB0aGF0IHdhcyBhbHNvIHBvc3NpYmxlLCBidXQgd2UgdHJpZWQg dG8gYmUgY29uc2lzdGVudCB3aXRoIHRoZSBmb3JtYXQgb2YgZ2V0X3B1Yl9rZXlzIHVzZWQgYWZ0 ZXJ3YXJkLg0KDQoNCmNsaWVudF9jcmVkOiBzYW1lIHF1ZXN0aW9uIG9uIGNlcnRpZmljYXRlIGFz IGZvciBzZWN0aW9uIDMuMQ0KRlA6IHNlZSBwcmV2aW91cyBhbnN3ZXINCg0KDQpiZWxvdyBmaWd1 cmUgMw0KL2FkZGl0aW9uYWxseS9PcHRpb25hbGx5Lw0KRlA6IE9rLCBkb25lLg0KDQoNClRoZSBw YXJhbWV0ZXJzIGdyb3VwX3BvbGljaWVzIGFuZCBtZ3Rfa2V5X21hdGVyaWFsIGFyZSBub3Qgc3Bl Y2lmaWVkIGluIHB1YnN1Yi1wcm9maWxlIGRyYWZ0LiBEbyB5b3UgZXZlciB1c2UgdGhlbT8NCkZQ OiBXZSBkbyB1c2UgdGhlbSBpbiB0aGUgam9pbmluZyBkcmFmdC4gVGhleSBhcmUgcmVsZXZhbnQg Zm9yIHRoZSBwdWJzdWIgZHJhZnQsIGJ1dCBJIGhhdmVu4oCZdCBnb3R0ZW4gdGhlbSBpbiB5ZXQu DQoNCg0KU2VjdGlvbiA1LjINCiJOT3RlIHRoYXQgLi4uLiBsZWF2aW5nIG5vZGUiIEl0IGlzIG5v dCBjbGVhciBpZiB0aGUgY2xpZW50IGhhcyBsZWZ0IHRoZSBncm91cCBpbiB0aGlzIGNhc2UsIGFu ZCB3aGF0IHRoYXQgbWVhbnMuIFRoZSBhY3Rpb25zIGxvb2sgcXVpdGUgY29udHJhZGljdG9yeSB0 byBtZS4NCkZQOiBXZSBoYXZlIG5vdyByZXBocmFzZWQ6DQogICBOb3RlIHRoYXQsIGFmdGVyIGhh dmluZyBsZWZ0IHRoZSBncm91cCwgYSBub2RlIG1heSB3aXNoIHRvIGpvaW4gaXQNCiAgIGFnYWlu LiAgVGhlbiwgYXMgbG9uZyBhcyB0aGUgbm9kZSBpcyBzdGlsbCBhdXRob3JpemVkIHRvIGpvaW4g dGhlDQogICBncm91cCwgaS5lLiBpdCBoYXMgYSBzdGlsbCB2YWxpZCBhY2Nlc3MgdG9rZW4sIGl0 IGNhbiByZS1yZXF1ZXN0IHRvDQogICBqb2luIHRoZSBncm91cCBkaXJlY3RseSB0byB0aGUgS0RD IHdpdGhvdXQgbmVlZGluZyB0byByZXRyaWV2ZSBhIG5ldw0KICAgYWNjZXNzIHRva2VuIGZyb20g dGhlIEFTLiAgVGhpcyBtZWFucyB0aGF0IHRoZSBLREMgbmVlZHMgdG8ga2VlcA0KICAgdHJhY2sg b2Ygbm9kZXMgd2l0aCB2YWxpZCBhY2Nlc3MgdG9rZW5zLCBiZWZvcmUgZGVsZXRpbmcgYWxsDQog ICBpbmZvcm1hdGlvbiBhYm91dCB0aGUgbGVhdmluZyBub2RlLg0KDQoNCg0Kc2VjdGlvbiA2DQov bm90IGFibGUgdG8gcGFydGljaXBhdGUgdG8vbm90IGFibGUgdG8gcmVjZWl2ZSBvciBkZWNyeXB0 Lw0KRlA6IE9rLCBkb25lDQoNCnNlY3Rpb24gNi4xDQpzY29wZTogc2FtZSByZW1hcmtzIGFib3V0 IHRvcGljIGFuZCBncm91cCBpZGVudGlmaWVyLg0KRlA6IFNhbWUgcXVlc3Rpb24gYXMgYWJvdmUN Cg0KDQoiSW4gc29tZSBjYXNlcyAuLi4gc2FtZSBLREMiLiBTdWdnZXN0IHRvIHJlbW92ZS4gSW4g YSBmYXN0IGNoYW5naW5nIGVudmlyb25tZW50LCB0aGlzIG1heSBsZWFkIHRvIG1hbnkgZXJyb3Ig bWVzc2FnZXMgaWYgbm90IHdyb25nIGJlaGF2aW9yOyBJbWFnaW5lIGdyb3VwIEdBIGlzIHRoZSBv bmx5IGdyb3VwLiBDIGlzIG1lbWJlciBvZiBHQS4gR0EgaXMgcmVtb3ZlZCBhbmQgR0IgaXMgZW50 ZXJlZCBhcyB0aGUgb25seSBncm91cC4gQyB3YW50cyB0byBsZWF2ZS9qb2luIEdBLCBhbmQgYWNj ZXNzZXMgR0IuDQpGUDogVGhhbmtzIGZvciB0aGlzIGlucHV0LCB0aGlzIG1ha2VzIHNlbnNlLiBX ZSBoYXZlIG5vdyByZW1vdmVkIHRoaXMgdGV4dCBhbmQgbWFkZSB0aGUg4oCcc2NvcGXigJ0gcGFy YW1ldGVyIG1hbmRhdG9yeS4NCg0KDQpTZWN0aW9uIDcNCkFnYWluIHN1Z2dlc3QgdG8gYWRkIGZp Z3VyZSB3aXRoIHJlcXVlc3QgYmVmb3JlIHNlY3Rpb24gNy4xDQoNCg0KRlA6IE9rLCBhZGRlZCBp biBzZWN0aW9uIDcgKGZpZ3VyZSA2KQ0KDQpzY29wZTogc2FtZSBjb21tZW50IG9uIGdyb3VwIGlk ZW50aWZpZXIgYW5kIHRvcGljLg0KRlA6IHNhbWUgcXVlc3Rpb24NCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpIb3BlIHRoaXMgaGVs cHMsDQpGUDogSXQgaGVscHMgYSBsb3QsIHRoYW5rcyEgOikNCg0KDQpncmVldGluZ3MsDQoNClBl dGVyDQoNCg0KLS0NClBldGVyIHZhbiBkZXIgU3Rvaw0KdmFuZGVyc3RvayBjb25zdWx0YW5jeQ0K bWFpbHRvOiBjb25zdWx0YW5jeUB2YW5kZXJzdG9rLm9yZzxtYWlsdG86Y29uc3VsdGFuY3lAdmFu ZGVyc3Rvay5vcmc+LHN0b2tjb25zQGJiaG1haWwubmw8bWFpbHRvOnN0b2tjb25zQGJiaG1haWwu bmw+DQp3d3c6IHd3dy52YW5kZXJzdG9rLm9yZzxodHRwOi8vd3d3LnZhbmRlcnN0b2sub3JnPg0K dGVsIE5MOiArMzEoMCk0OTI0NzQ2NzMgICAgIEY6ICszMygwKTk2NjAxNTI0OA0KDQo= --_000_1AE4350ADF5349AEA209A04CB488215Cericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6LXdlYmtpdC1z dGFuZGFyZDsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uYXBwbGUtY29udmVy dGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFu LkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRl ZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg UHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4w cHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5IaSBQZXRlciw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+VGhhbmtzIGEgbG90IGZvciB0aGlzIGRldGFpbGVkIHJldmlldyEg V2UgaGF2ZSB1cGxvYWRlZCBhIG5ldyB2ZXJzaW9uIHRoYXQgaW5jbHVkZXMgKG1vc3Qgb2YpIHlv dXIgY29tbWVudHM6PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBh bG9tYmluaS1hY2Uta2V5LWdyb3VwY29tbS0wMiI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBhbG9tYmluaS1hY2Uta2V5LWdyb3Vw Y29tbS0wMjwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkRldGFp bGVkIHJlcGxpZXMgYW5kIHNvbWUgcXVlc3Rpb25zIGlubGluZSAoc2VlIEZQIGluIHJlZCBiZWxv dykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoYW5rcyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PkZyYW5jZXNjYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOiZuYnNw Ozwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5BY2UgJmx0OzxhIGhyZWY9Im1h aWx0bzphY2UtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+YWNl LWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDsgb24gYmVoYWxmIG9mIFBldGVyIHZhbiBk ZXIgU3RvayAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN0b2tjb25zQGJiaG1haWwubmwiPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPnN0b2tjb25zQGJiaG1haWwubmw8L3NwYW4+PC9hPiZndDs8YnI+ DQo8Yj5Pcmdhbml6YXRpb246Jm5ic3A7PC9iPnZhbmRlcnN0b2sgY29uc3VsdGFuY3k8YnI+DQo8 Yj5SZXBseS1UbzombmJzcDs8L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmNvbnN1bHRhbmN5QHZh bmRlcnN0b2sub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5jb25zdWx0YW5jeUB2YW5k ZXJzdG9rLm9yZzwvc3Bhbj48L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Y29uc3VsdGFu Y3lAdmFuZGVyc3Rvay5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmNvbnN1bHRhbmN5 QHZhbmRlcnN0b2sub3JnPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTombmJzcDs8L2I+VHVl c2RheSwgMzEgSnVseSAyMDE4IGF0IDEwOjUyPGJyPg0KPGI+VG86Jm5ic3A7PC9iPkFjZSBXZyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmFjZUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBs ZSI+YWNlQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDombmJzcDs8L2I+ W0FjZV0gRndkOiByZXZpZXcgb2YgcGFsb21iaW5pLWFjZS1rZXktZ3JvdXBjb21tPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LHNl cmlmO2NvbG9yOmJsYWNrIj5IaSBrZXktZ3JvdXBjb21tIGF1dGhvcnMsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxicj4NClRvIHN0YXJ0IHRoZSByZXZpZXcgSSBo YXZlIGxvb2tlZCBhdCB0aGUgZGVwZW5kZW5jaWVzIGJldHdlZW4gdGhlIGRpZmZlcmVudCBpbnZv bHZlZCBkcmFmdHMgYW5kIGNhbWUgdXAgd2l0aCB0aGUgZmlndXJlIGJlbG93Ljxicj4NCjxicj4N CjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iNTgwIiBoZWlnaHQ9IjMwNiIgc3R5bGU9IndpZHRoOjYu MDQxNmluO2hlaWdodDozLjE4NzVpbiIgaWQ9IlBpY3R1cmVfeDAwMjBfNCIgc3JjPSJjaWQ6aW1h Z2UwMDEucG5nQDAxRDQ2RjdCLjIyQUQyNEEwIiBhbHQ9ImNpZDoxNTMzMDI3MTA4NWI2MDIzMjQ5 MTEyODc5NzgyNDQyN0BiYmhtYWlsLm5sIj48YnI+DQpUaGUgYXJyb3dzIGluZGljYXRlIHRoYXQg YSBkcmFmdCByZWZlcmVuY2VzIGFub3RoZXIgZHJhZnQuIFRoZSBkb3RzIHJlZmVyZW5jZSBhcnJv dyBtZWFucyBJbmZvcm1hdGl2ZSByZWZlcmVuY2UuIEFjY29yZGluZyB0byBtZSwgdGhpcyBtZWFu cyB0aGF0IHRoZSB3b3JrIG9uIENPUkUgY2FuIHByb2NlZWQgaW5kZXBlbmRlbnRseSBvZiB0aGUg d29yayBpbiBBQ0UuIFRoZSBvc2NvYXAtam9pbiBhbmQga2V5LWdyb3VwY29tbSBjYW4gcHJvY2Vl ZCB0b2dldGhlcg0KIHRvIHRoZWlyIGNvbmNsdXNpb24gd2l0aG91dCBvdGhlciBkZXBlbmRlbmNp ZXMuIFRoYXQgZ3VhcmFudGVlcyB0aGF0IHdlIGNhbiBkZXZlbG9wIHRoZSBncm91cCBjb21tdW5p Y2F0aW9uIGRyYWZ0cyBpbiBBQ0Ugd2l0aG91dCB1bndhbnRlZCBkZXBlbmRlbmNpZXMgb24gcHVi c3ViLiBUaGUgcHVic3ViLXByb2ZpbGUgZGVwZW5kcyBvbiBjb3JlLXB1c3ViIGFuZCBrZXktZ3Jv dXBjb21tLCB3aGljaCBkb2VzIG5vdCBib3RoZXIgbWUgdG9vIG11Y2guPGJyPg0KPGJyPg0KPGJy Pg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5GUDogVGhhdCBpcyBh YnNvbHV0ZWx5IGNvcnJlY3QsIHRoZSBncm91cCBjb21tdW5pY2F0aW9uIGRyYWZ0cyBkbyBub3Qg ZGVwZW5kIG9uIHRoZSBwdWJzdWIgd29yaywgYW5kIGNhbiBiZSBtb3ZlIGZvcndhcmQgd2l0aG91 dCBkZXBlbmRlbmNpZXMuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxicj4NCktlZXBpbmcgdGhpcyBpbiBt aW5kLCBJIGhhdmUgcmV2aWV3ZWQgdGhlIGtleS1ncm91cGNvbW0gZHJhZnQuPGJyPg0KPGJyPg0K QlRXLCBpdCBtaWdodCBiZSBoZWxwZnVsIHRvIGluY2x1ZGUgYSBzaW1pbGFyIG92ZXJ2aWV3IGlu IHRoZSBvc2NvYXAtam9pbiBkcmFmdC48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KPGJyPg0KQWJz dHJhY3Q8YnI+DQpPTEQ6VGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbWVzc2FnZSBmb3JtYXQgZm9y IGRpc3RyaWJ1dGluZyBrZXlpbmc8YnI+DQptYXRlcmlhbCBpbiBncm91cCBjb21tdW5pY2F0aW9u IHNjZW5hcmlvcyAoc3VjaCBhcyBiYXNlZCBvbiBtdWx0aWNhc3Q8YnI+DQpvciBwdWJsaXNoZXIt c3Vic2NyaWJlciBtb2RlbCkgdXNpbmcgdGhlIEFDRSBmcmFtZXdvcmsuPGJyPg0KPGJyPg0KTkVX OlRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG1lc3NhZ2UgZm9ybWF0IGZvciBkaXN0cmlidXRpbmcg a2V5aW5nPGJyPg0KbWF0ZXJpYWwgdG8gZ3JvdXBzIHRvIHByb3RlY3QgdGhlIGNvbW11bmljYXRp b24gYmV0d2VlbiBncm91cCBtZW1iZXJzIHVzaW5nIHRoZSBBQ0UgZnJhbWV3b3JrLjxicj4NCjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjpyZWQiPkZQOiB3ZSBzdGFydGVkIHdpdGggeW91ciBpbnB1dCBhbmQg cmVmb3JtdWxhdGVkIHRvOjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7IFRoaXMgZG9j dW1lbnQgZGVmaW5lcyBtZXNzYWdlIGZvcm1hdHMgYW5kIHByb2NlZHVyZXMgZm9yIHJlcXVlc3Rp bmc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpyZWQiPiZuYnNwOyZuYnNwOyBhbmQgZGlzdHJpYnV0aW5nIGdyb3Vw IGtleWluZyBtYXRlcmlhbCB1c2luZyB0aGUgQUNFIGZyYW1ld29yaywgdG88L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6cmVkIj4mbmJzcDsmbmJzcDsgcHJvdGVjdCBjb21tdW5pY2F0aW9ucyBiZXR3ZWVuIGdy b3VwIG1lbWJlcnMuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SW50cm9k dWN0aW9uPGJyPg0KT0xEOiBQcm9maWxlcyB0aGF0IHVzZSBncm91cCBjb21tdW5pY2F0aW9uIGNh biBidWlsZCBvbiB0aGlzIGRvY3VtZW50IHRvIHNwZWNpZnkgZXhhY3RseSB3aGljaCBvZiB0aGUg bWVzc2FnZSBwYXJhbWV0ZXJzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudHMgYXJlIHVzZWQsIGFu ZCB3aGF0IGFyZSB0aGVpciB2YWx1ZXMuPGJyPg0KPGJyPg0KTkVXOiBQcm9maWxlcyB0aGF0IHVz ZSBncm91cCBjb21tdW5pY2F0aW9uIGNhbiBidWlsZCBvbiB0aGlzIGRvY3VtZW50IHRvIHNwZWNp ZnkgYSBzZWxlY3Rpb24gb2YgdGhlIG1lc3NhZ2UgcGFyYW1ldGVycyBkZWZpbmVkIGluIHRoaXMg ZG9jdW1lbnQgYW5kIHRoZWlyIHZhbHVlcy48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5G UDogd2UgaW5jbHVkZWQgdGhpcyB3aXRoIHRoZSBzbWFsbGVzdCBkaWZmZXJlbmNlOjxicj4NCjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6cmVkIj4mbmJzcDsmbmJzcDsgUHJvZmlsZXMgdGhhdCB1c2UgZ3JvdXAgY29tbXVuaWNhdGlv biBjYW4gYnVpbGQgb24gdGhpcyBkb2N1bWVudCB0bzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOnJlZCI+Jm5ic3A7 Jm5ic3A7IHNwZWNpZnkgdGhlIHNlbGVjdGlvbiBvZiB0aGUgbWVzc2FnZSBwYXJhbWV0ZXJzIGRl ZmluZWQgaW4gdGhpczwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7IGRvY3VtZW50IHRv IHVzZSBhbmQgdGhlaXIgdmFsdWVzLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YnI+DQpBdCB0aGUgZW5kIG9mIHNlY3Rpb24g MTogLi4uLiBbUkZDODE1Ml0sIGxpa2UgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgKEFTKSBhbmQgUmVz b3VyY2UgU2VydmVyIChSUykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVk Ij5GUDogT2ssIGFkZGVkLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YnI+DQo8YnI+DQo8aW1nIGJvcmRl cj0iMCIgd2lkdGg9IjU5MSIgaGVpZ2h0PSIyOTEiIHN0eWxlPSJ3aWR0aDo2LjE1NjJpbjtoZWln aHQ6My4wMzEyaW4iIGlkPSJQaWN0dXJlX3gwMDIwXzMiIHNyYz0iY2lkOmltYWdlMDAyLnBuZ0Aw MUQ0NkY3Qi4yMkFEMjRBMCIgYWx0PSJjaWQ6MTUzMzAyNzEwODViNjAyMzI0OTEzZmQzOTYzMzYy MDBAYmJobWFpbC5ubCI+PGJyPg0KRmlndXJlIDEgaXMgbm90IHJlZmVyZW5jZWQgaW4gdGhlIHRl eHQuIEkgc3VnZ2VzdCBhIHNsaWdodGx5IGRpZmZlcmVudCBmaWd1cmUgd2hlcmUgZGlzcGF0Y2hl ciBhbmQgS0RDIGFyZSBlbmRwb2ludHMgb2YgdGhlIFJTLCBhbmQgZm9yIG11bHRpY2FzdCB0aGUg Y29tbXVuaWNhdGlvbiBpcyBkaXJlY3RseSBiZXR3ZWVuIENsaWVudCBhbmQgZ3JvdXAgbWVtYmVy cyB3aXRob3V0IHBhc3NpbmcgdGhyb3VnaCB0aGUgUlMuPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5GUDogV2UgaGF2ZSBub3cgcmVmZXJl bmNlZCB0aGUgZmlndXJlIGluIHRoZSB0ZXh0LiBXZSBoYXZlIG5vdCBtb2RpZmllZCB0aGUgcGlj dHVyZXMsIHNpbmNlIHdlIGFyZSBub3Qgc3VyZSB0aGUgY2hhbmdlIHNpbXBsaWZpZXMgaXQuIFJl YWRpbmcgdGhlIHByb3Bvc2VkIGZpZ3VyZSwgaXQgc2VlbXMgbGlrZSBLREMgYW5kDQogRGlzcGF0 Y2hlciBhcmUgbG9naWNhbCBlbnRpdGllcyBpbiB0aGUgc2FtZSBwaHlzaWNhbCBlbnRpdHkgKHRo ZSBSUyksIHdoaWNoIGlzIG5vdCBjb3JyZWN0Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5LZXkgRGlzdHJp YnV0aW9uIENlbnRlciAoS0RDKTogTWFpbnRhaW5zIHRoZSBrZXlpbmcgbWF0ZXJpYWwgdG8gcHJv dGVjdCBncm91cCBjb21tdW5pY2F0aW9ucywgYW5kIHByb3ZpZGVzIGtleXMgdG8gY2xpZW50cyBh dXRob3JpemVkIHRvIGpvaW4gdGhlIGdyb3VwLiBJdCBjb3JyZXNwb25kcyB0byBhbiBlbmRwb2lu dA0KIG9mIHRoZSBSUyBpbiB0aGUgQUNFIEZyYW1ld29yay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5GUDogV2UgaGF2 ZSBub3cgcmVwaHJhc2VkIGJhc2VkIG9uIHlvdXIgYW5kIEppbXMgaW5wdXRzOjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6cmVkIj4N Cjxicj4NCm8mbmJzcDsgS2V5IERpc3RyaWJ1dGlvbiBDZW50ZXIgKEtEQyk6IG1haW50YWlucyB0 aGUga2V5aW5nIG1hdGVyaWFsIHRvPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6cmVkIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgcHJvdGVjdCBncm91cCBjb21tdW5pY2F0aW9ucywgYW5kIHByb3ZpZGVz IGl0IHRvIENsaWVudHM8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6cmVkIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgYXV0aG9yaXplZCB0byBqb2luIHRoZSBncm91cC4mbmJzcDsgRHVyaW5nIHRo ZSBmaXJzdCBwYXJ0IG9mIHRoZTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpyZWQiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBleGNoYW5nZSAoPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXBhbG9tYmluaS1hY2Uta2V5LWdyb3VwY29tbS0wMiNzZWN0aW9uLTMiPjxz cGFuIHN0eWxlPSJjb2xvcjpyZWQiPlNlY3Rpb24gMzwvc3Bhbj48L2E+KSwgaXQgdGFrZXMgdGhl IHJvbGUgb2YgdGhlIFJTIGluIHRoZSBBQ0U8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6cmVkIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRnJhbWV3b3JrLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+QWxzbywg aXQgaXMgd29ydGggbm90aW5nIHRoYXQgaW4gdGhpcyBkb2N1bWVudCB3ZSB1c2UgdGhlIHRlcm0g 4oCcZW5kcG9pbnTigJ0gYXMgZGVmaW5lZCBpbiBBQ0UgKGVxdWl2YWxlbnQgdG8g4oCccmVzb3Vy Y2XigJ0gaW4gQ29BUCksIHdoaWNoIGlzIGRpZmZlcmVudCBmcm9tIHRoZSDigJxlbmRwb2ludOKA nSB0ZXJtIGluIENvUkUvQ29BUC48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGJyPg0KRGlzcGF0Y2hlcjog dGhpcyBpcyB0aGUgZW50aXR5IHRoZSBDbGllbnQgd2FudHMgdG8gc2VjdXJlbHk8YnI+DQpjb21t dW5pY2F0ZSB3aXRoIGFuZCBpcyByZXNwb25zaWJsZSBmb3IgZGlzdHJpYnV0aW9uIG9mIGdyb3Vw PGJyPg0KbWVzc2FnZXMuIEV4YW1wbGUgZGlzcGF0Y2hlcnMgYXJlIHRoZSBCcm9rZXIgaW4gYSBw dWItc3ViIHNldHRpbmcgb3IgdGhlIGdlbmVyYXRvciBvZiB1bmljYXN0IG1lc3NhZ2VzIHRvIGFs bCBncm91cCBtZW1iZXJzIGZvciBncm91cCBjb21tdW5pY2F0aW9uLjxicj4NCkFsdGVybmF0aXZl bHksIEdyb3VwIGNvbW11bmljYXRpb24gaXMgZG9uZSBieSB0cmFuc21pdHRpbmcgdG8gYSBtdWx0 aWNhc3QgSVAgYWRkcmVzcywgYW5kIGVudHJ1c3RpbmcgbWVzc2FnZSBkZWxpdmVyeSB0byB0aGUg dHJhbnNwb3J0IGNoYW5uZWxzIGJldHdlZW4gQ2xpZW50IGFuZCBHcm91cCBtZW1iZXJzLjxicj4N Cjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPkZQOiBXZSBkb27igJl0IHRoaW5rIOKAnGdlbmVyYXRv cuKAnSBpcyB0aGUgYmVzdCB3b3JkLCB0aGUgdHJ1ZSBnZW5lcmF0b3Igd291bGQgc3RpbGwgYmUg dGhlIGdyb3VwIG1lbWJlciwgc28gd2UgcmVwbGFjZWQgdGhhdCB3aXRoIHJlbGF5ZXIuIEluY2x1 ZGluZyB0aGUgY29tbWVudHMgZnJvbSBKaW0sIHRoaXMgZ2l2ZXM6PGJyPg0KPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpyZWQiPiZu YnNwOyZuYnNwOyBvJm5ic3A7IERpc3BhdGNoZXI6IGVudGl0eSB0aHJvdWdoIHdoaWNoIHRoZSBD bGllbnRzIGNvbW11bmljYXRlIHdpdGggdGhlPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6cmVkIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgZ3JvdXAgYW5kIHdoaWNoIGRpc3RyaWJ1dGVzIG1lc3NhZ2Vz IHRvIHRoZSBncm91cCBtZW1iZXJzLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IEV4YW1wbGVzIG9mIGRpc3BhdGNoZXJzIGFyZTogdGhlIEJyb2tlciBu b2RlIGluIGEgcHViLXN1YiBzZXR0aW5nOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGEgcmVsYXllciBub2RlIGZvciBncm91cCBjb21tdW5pY2F0aW9u IHRoYXQgZGVsaXZlcnMgZ3JvdXA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpyZWQiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBtZXNzYWdlcyBhcyBtdWx0aXBsZSB1bmljYXN0IG1lc3NhZ2VzIHRvIGFs bCBncm91cCBtZW1iZXJzOyBhbjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGltcGxpY2l0IGVudGl0eSBhcyBpbiBhIG11bHRpY2FzdCBjb21tdW5pY2F0 aW9uIHNldHRpbmcsIHdoZXJlPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6cmVkIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgbWVzc2FnZXMgYXJlIHRyYW5zbWl0dGVkIHRvIGEgbXVsdGljYXN0IElQIGFk ZHJlc3MgYW5kIGRlbGl2ZXJlZDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IG9uIHRoZSB0cmFuc3BvcnQgY2hhbm5lbC48L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGJyPg0KV2hhdCBp cyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuICZxdW90O2FkZGluZyBub2RlIHRvIGdyb3VwJnF1b3Q7 IGFuZCAmcXVvdDtkaXN0cmlidXRpb24gb2Yga2V5aW5nIG1hdGVyaWFsJnF1b3Q7LiBJIGZpbmQg dGhlIHBocmFzZSBkaWZmaWN1bHQgdG8gdW5kZXJzdGFuZC48YnI+DQo8YnI+DQo8YnI+DQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPkZQOiBBc3N1bWluZyB0aGlzIHdh cyBhYm91dCB0aGUgdGl0bGUgb2Ygc2VjdGlvbiA0LCB3ZSByZXBocmFzZWQgdGhhdCB0byDigJxB dXRob3JpemF0aW9uIHRvIEpvaW4gYSBHcm91cOKAnS48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGJyPg0K RmlndXJlIDIgOiBJIHN1Z2dlc3QgdG8gYWRkIEdyb3VwIE1lbWJlciAoR00pIGFzIGNvbW11bmlj YXRpb24gZW50aXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+RlA6 IEdvb2QgaWRlYSwgaXQgaXMgbm93IGluY2x1ZGVkLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YnI+DQo8 YnI+DQpBdCB0aGUgZW5kIG9mIHNlY3Rpb24gMiwgSSBzdWdnZXN0IHNvbWUgdGV4dCBvbiBncm91 cCBpZGVudGlmaWVyIGFuZCByb2xlIGlkZW50aWZpZXIsIHN1Y2ggdGhhdCB0aGVzZSB0ZXJtcyBj YW4gYmUgdXNlZCBpbmRlcGVuZGVudCBvZiB0aGUgYXBwbGljYXRpb24gcHJvZmlsZXMgc3BlY2lm aWVkIGluIG90aGVyIGRvY3VtZW50cy48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPkZQOiBJIGFtIG5vdCBzdXJlIHdoeSBkbyB5b3UgdGhp bmsgdGhlc2UgdGVybXMgKHdoaWNoIGFwcGVhciBmaXJzdCBpbiBzZWN0aW9uIDMuMSkgYXJlIG5v dCBpbmRlcGVuZGVudCBvZiB0aGUgYXBwbGljYXRpb24gcHJvZmlsZXMgc3BlY2lmaWVkIGluIG90 aGVyIGRvY3VtZW50cy4gQ291bGQgeW91IHBsZWFzZSBleHBhbmQNCiBvbiB0aGF0Pzwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48YnI+DQpTZWN0aW9uIDMuPGJyPg0KPGJyPg0KUmVtb3ZlOiAmcXVvdDt3aGVy ZSB0aGUgUkRDIHRha2VzIHRoZSByb2xlIG9mIFJTJnF1b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNw YW4gc3R5bGU9ImNvbG9yOnJlZCI+RlA6IE9rLCBkb25lLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YnI+ DQpTdWdnZXN0IHRvIGFkZCB0aGUgbWVzc2FnZSBleGNoYW5nZSBiZWZvcmUgc2VjdGlvbiAzLjE8 YnI+DQo8YnI+DQpQT1NUIC0tLSBBdXRob3JpemF0aW9uIFJlcXVlc3QgKGFwcGxpY2F0aW9uL0NC T1IpIC0tLS0mZ3Q7PGJyPg0KJmx0Oy0tIEF1dGhvcml6YXRpb24gUmVzcG9uc2UgKD8/Pz8gKSAt LS0tLTxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9y OnJlZCI+RlA6IFdlIGhhdmUgbm93IGFkZGVkIG1lc3NhZ2UgZXhjaGFuZ2VzIGFzIHN1Z2dlc3Rl ZCwgYWx0aG91Z2ggZm9yIGxhY2sgb2Ygc3BhY2Ugd2Ugb25seSBpbmNsdWRlIG5hbWUgb2YgdGhl IG1lc3NhZ2UsIENvQVAgQ29kZSBvciBNZXRob2QgYW5kIHRoZSB1cmkgaWYgYXBwbGljYWJsZS48 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+PGJyPg0KSXQgd291bGQgYmUgbmljZSBpZiBoZXJlIHRoZSB1c2Ug b2YgRFRMUyAob3Igbm90KSBhbmQgdGhlIGNvbnRlbnQgZm9ybWF0IGlzIHNwZWNpZmllZDogYXBw bGljYXRpb24vY2JvciBvciBhcHBsaWNhdGlvbi9Db3NlJiM0MztjYm9yPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5GUDogdGhhdCB3b3VsZCByZWFsbHkgYmUgcHJvZmls ZSBzcGVjaWZpYywgc28gd2UgaGF2ZSBub3Qgc3BlY2lmaWVkIGl0IGhlcmUuPC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxicj4NCjxicj4NCnNlY3Rpb24gMy4xJm5ic3A7PGJyPg0Kc2NvcGU6IHdpdGggYXMg dmFsdWVzIHRoZSBncm91cCBpZGVudGlmaWVyIGFuZCBvcHRpb25hbGx5IHRoZSByb2xlIC4uLi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPkZQOiBhZGRlZCBvcHRpb25h bGx5Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YnI+DQo8YnI+DQomcXVvdDtUaGUgZW5jb2Rpbmcgb2Yg dGhlIGdyb3VwIGlkZW50aWZpZXIgYW5kIHRoZSByb2xlKHMpIGlzIGFwcGxpY2F0aW9uIHNwZWNp ZmljLiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjpyZWQiPkZQOiB0aGFua3MsIHJlcGhyYXNlZCB0byBtYXRjaCB5b3Vy IHN1Z2dlc3Rpb246PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpyZWQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBUaGUgZW5jb2Rpbmcgb2YgdGhlIGdyb3VwIG9yIHRvcGljIGlkZW50aWZpZXIgYW5kIG9mIHRo ZSByb2xlPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6cmVkIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg aWRlbnRpZmllcnMgaXMgYXBwbGljYXRpb24gc3BlY2lmaWMuPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxicj4NCmNuZjogT3B0 aW9uYWxseSwgdGhlIHB1YmxpYyBrZXkgb3IgdGhlIGNlcnRpZmljYXRlIG9mIHRoZSBjbGllbnQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPkZQOiBSaWdodCwgdGhhbmtz PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxicj4NCjxicj4NClF1ZXN0aW9uOiBpcyB0aGlzIGEgY2VydGlm aWNhdGUgaWRlbnRpZmllciwgb3IgdGhlIHB1YmxpYyBrZXkgZXh0cmFjdGVkIGZyb20gdGhlIGNl cnRpZmljYXRlLCBvciBhIGhhc2g/Pz8/PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImNv bG9yOnJlZCI+RlA6IFRoaXMgaXMgZGVmaW5lZCBpbiBvdGhlciBkb2N1bWVudHMgb2YgQUNFLCBz ZWUgZHJhZnQtaWV0Zi1hY2UtY3d0LXByb29mLW9mLXBvc3Nlc3Npb24tMDMgc2VjdGlvbnMgMy4y IGFuZCAzLjQ8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGJyPg0KPGJyPg0Kc2VjdGlvbiAzLjI6PGJyPg0K MCBhY2Nlc3MgdG9rZW4gY29udGFpbmluZyBhbGwgdGhlIHBhcmFtZXRlcnMgZGVmaW5lZCBiZWxv dzsgVGhpcyBpcyB2ZXJ5IGNvbmZ1c2luZy4gSSB1bmRlcnN0b29kIHRoYXQgYWNjZXNzIHRva2Vu IHBhcmFtZXRlciBpcyBhdCBzYW1lIGxldmVsIGFzIGNuZiwgcnNfY25mLCBhbmQgZXhwLiBBbmQg aGVyZSB5b3Ugd3JpdGUgdGhhdCB0aGV5IGFyZSBjb250YWluZWQgaW4gYWNjZXNzIHRva2VuLiBJ ZiB0aGF0IGlzIHRydWUsIEkgc3VnZ2VzdCB0bw0KIG1ha2UgdGhlIG90aGVyIHRocmVlIHBhcmFt ZXRlciBzdWItYnVsbGV0cyBvZiBhY2Nlc3MtdG9rZW4gYnVsbGV0LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPkZQOiBX ZSBoYXZlIHRyaWVkIHRvIGltcHJvdmUgdGhpcyB0aGUgZm9sbG93aW5nIHdheTogVGhlIGFjY2Vz c190b2tlbiBidWxsZXQgb25seSBzYXlzIHRoYXQgaXQgY29udGFpbnMgdGhlIGFjY2VzcyB0b2tl bi4gQWZ0ZXIgdGhlIGJ1bGxldCBsaXN0IChhbmQgYWxsIHRoZSBwYXJhbWV0ZXJzIGFyZSBsaXN0 ZWQpLCB3ZSBzcGVjaWZ5Ojxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6cmVkIj4mbmJzcDsmbmJzcDsgVGhlIGFjY2VzcyB0 b2tlbiBNVVNUIGNvbnRhaW4gYWxsIHRoZSBwYXJhbWV0ZXJzIGRlZmluZWQgYWJvdmU8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpyZWQiPiZuYnNwOyZuYnNwOyAoaW5jbHVkaW5nIHRoZSBzYW1lICdzY29wZScgYXMg aW4gdGhpcyBtZXNzYWdlLCBpZiBwcmVzZW50LCBvciB0aGU8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6cmVk Ij4mbmJzcDsmbmJzcDsgJ3Njb3BlJyBvZiB0aGUgQXV0aG9yaXphdGlvbiBSZXF1ZXN0IG90aGVy d2lzZSksIGFuZCBhZGRpdGlvbmFsbHk8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6cmVkIj4mbmJzcDsmbmJz cDsgb3RoZXIgb3B0aW9uYWwgcGFyYW1ldGVycyB0aGUgcHJvZmlsZSByZXF1aXJlcy48L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJj b2xvcjpyZWQiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YnI+DQpGb3IgdG9waWMgYW5kIHJv bGUgc2VlIHNlY3Rpb24gMy4xPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVk Ij5GUDogT2ssIHNhbWUgZml4IGFwcGxpZWQuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxicj4NCnNlY3Rp b24gMy4zOiZuYnNwOzxicj4NCnNhbWUgcmVxdWVzdCByZXNwb25zZSBmaWd1cmUgYXMgc3VnZ2Vz dGVkIGluIHNlY3Rpb24gMyBiZWZvcmUgc2VjdGlvbiAzLjE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFu IHN0eWxlPSJjb2xvcjpyZWQiPkZQOiBUaGlzIGlzIHBhcnQgb2YgdGhlIGZpZ3VyZSAzLCBpbiBz ZWN0aW9uIDMuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxicj4NCiZxdW90O2EgZGlmZmVyZW50IGVuZHBv aW50JnF1b3Q7IGlzIHZlcnkgdmFndWUuIFBsZWFzZSBleHBsYWluLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPkZQOiBS ZXBocmFzZWQgdG86IOKAnDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6cmVkIj50aGUgQ2xpZW50IE1BWSB1c2UgYSBkaWZmZXJlbnQg ZW5kcG9pbnQgdGhhbiAvYXV0aHotaW5mb+KAnTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5BZ2FpbiwgdGhpcyBkZXJp dmVzIGZyb20gdGhlIHVzZSBvZiDigJxlbmRwb2ludOKAnSBhcyBBQ0UgZGVmaW5lcyBpdC48L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YnI+DQo8YnI+DQpzZWN0aW9uIDQ6PGJyPg0K PGJyPg0KL1RoZSBzYW1lIHR5cGVzIG9mIG1lc3NhZ2VzIGNhbiBhbHNvIGJlL3RoZSBzYW1lIHNl dCBvZiBtZXNzYWdlcyBpcy88YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFu IHN0eWxlPSJjb2xvcjpyZWQiPkZQOiBQYXJ0bHkgaW5jbHVkZWQuIFdlIGtlZXAgdGhlIOKAnGNh biBhbHNvIGJl4oCdLCBzaW5jZSB3ZSBsZWF2ZSBpdCB0byB0aGUgYXBwbGljYXRpb24gdG8gZGVj aWRlIHRvIHVzZSBvciBub3QgdXNlIHRoZXNlIG1lY2hhbmlzbXMuIFdlIHdhbnQgdG8gYWxsb3cg Zm9yIGZsZXhpYmlsaXR5Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YnI+DQpqdXN0IGJlZm9yZSBzZWN0 aW9uIDQuMSBzYW1lIGZpZ3VyZSBhbmQgaW5mb3JtYXRpb24gYXMgcmVxdWVzdGVkIGluIHNlY3Rp b24gMyBiZWZvcmUgc2VjdGlvbiAzLjE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xv cjpyZWQiPkZQOiBEb25lIG5vdyBpbiBzZWN0aW9uIDQsIHNlZSBmaWd1cmUgNC48L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PGJyPg0KPGJyPg0Kc2VjdGlvbiA0LjE8YnI+DQomcXVvdDsuLi4ucmVxdWVzdCB0 byB0aGUgZW5kcG9pbnQgaW4gdGhlIEtEQyBhc3NvY2lhdGVkLi4uJnF1b3Q7IE5vdCBjbGVhciB3 aGF0IGlzIG1lYW50Ojxicj4NCi0gb25lIGVuZHBvaW50IGZvciBhbGwgZ3JvdXBzPzxicj4NCi0g b25lIGVuZHBvaW50IHBlciBncm91cD88YnI+DQotIG9uZSBlbmRwb2ludCBwZXIgc3Vic2V0IG9m IGdyb3Vwcz88YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5GUDogV2UgbWVhbnQgb25lIGVu ZHBvaW50IChvciByZXNvdXJjZSkgcHJlIGdyb3VwLCB3aGljaCB0aGUgQ2xpZW50IGtub3dzIHZp YSB0aGUgU2NvcGUgKGl0IGlzIOKAnGFzc29jaWF0ZWTigJ0gdG8gaXQpLiBXZSBkbyBub3Qgc2F5 IHRoYXQgdGhlIGVuZHBvaW50IGhhcyB0aGUgc2FtZSB2YWx1ZSBhcyB0aGUgZ3JvdXAgaWRlbnRp ZmllciwgaXQgbWlnaHQgYmUgc29tZXRoaW5nDQogZGVyaXZlZCBmcm9tIGl0LiBXZSBoYXZlIG5v dyB0cmllZCB0byBjbGFyaWZ5IGJ5IHJlcGhyYXNpbmc6PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpyZWQiPiZuYnNwOyBUaGlzPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6cmVkIj4mbmJzcDsmbmJzcDsgY29ycmVzcG9uZHMgdG8gYSBDb0FQIFBPU1Qg cmVxdWVzdCB0byB0aGUgZW5kcG9pbnQgaW4gdGhlIEtEQzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOnJlZCI+Jm5i c3A7Jm5ic3A7IGFzc29jaWF0ZWQgdG8gdGhlIGdyb3VwIHRvIGpvaW4uJm5ic3A7IFRoZSBlbmRw b2ludCBpbiB0aGUgS0RDIGlzPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6cmVkIj4mbmJzcDsmbmJzcDsgYXNzb2Np YXRlZCB0byB0aGUgJ3Njb3BlJyB2YWx1ZSBvZiB0aGUgQXV0aG9yaXphdGlvbiBSZXF1ZXN0Lzwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7IFJlc3BvbnNlLjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxi cj4NCnNjb3BlOiByZW1vdmUgdG9waWM7IHdoYXQgcmVzb3VyY2UgaXMgcmVmZXJyZWQgdG8/PGJy Pg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+RlA6IHJlcGhyYXNlZCB0bzo8YnI+DQo8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOnJl ZCI+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgJ3Njb3BlJywgd2l0aCB2YWx1ZSB0aGUgc3BlY2lmaWMg cmVzb3VyY2UgdGhhdCB0aGUgQ2xpZW50IGlzPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6cmVkIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgYXV0aG9yaXplZCB0byBhY2Nlc3MgKGkuZS4gZ3JvdXAgb3Ig dG9waWMgaWRlbnRpZmllcikgYW5kIHJvbGUocyksPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6cmVkIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZW5jb2RlZCBhcyBpbg0KPGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBhbG9tYmluaS1hY2Uta2V5LWdyb3VwY29tbS0wMiNz ZWN0aW9uLTMuMSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5TZWN0aW9uIDMuMTwvc3Bhbj48 L2E+Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48YnI+DQpnZXRfcHViX2tleXM6IEluc3RlYWQgb2YgZW1wdHkgQ0JPUiBhcnJh eSwgYW4gZW1wdHkgcGF5bG9hZCBpcyBhbHNvIHBvc3NpYmxlPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNw YW4gc3R5bGU9ImNvbG9yOnJlZCI+RlA6IFByb2JhYmx5IHBheWxvYWQgaXMgd3JvbmcuIElmIHlv dSBtZWFudCBlbXB0eSBieXRlIHN0cmluZywgeWVzIHRoYXQgd2FzIGFsc28gcG9zc2libGUsIGJ1 dCB3ZSB0cmllZCB0byBiZSBjb25zaXN0ZW50IHdpdGggdGhlIGZvcm1hdCBvZiBnZXRfcHViX2tl eXMgdXNlZCBhZnRlcndhcmQuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxicj4NCjxicj4NCmNsaWVudF9j cmVkOiBzYW1lIHF1ZXN0aW9uIG9uIGNlcnRpZmljYXRlIGFzIGZvciBzZWN0aW9uIDMuMTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+RlA6IHNlZSBwcmV2aW91cyBhbnN3 ZXI8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PGJyPg0KPGJyPg0KYmVsb3cgZmlndXJlIDM8YnI+DQovYWRk aXRpb25hbGx5L09wdGlvbmFsbHkvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6 cmVkIj5GUDogT2ssIGRvbmUuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxicj4NCjxicj4NClRoZSBwYXJh bWV0ZXJzIGdyb3VwX3BvbGljaWVzIGFuZCBtZ3Rfa2V5X21hdGVyaWFsIGFyZSBub3Qgc3BlY2lm aWVkIGluIHB1YnN1Yi1wcm9maWxlIGRyYWZ0LiBEbyB5b3UgZXZlciB1c2UgdGhlbT88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPkZQOiBXZSBkbyB1c2UgdGhlbSBpbiB0 aGUgam9pbmluZyBkcmFmdC4gVGhleSBhcmUgcmVsZXZhbnQgZm9yIHRoZSBwdWJzdWIgZHJhZnQs IGJ1dCBJIGhhdmVu4oCZdCBnb3R0ZW4gdGhlbSBpbiB5ZXQuPC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxi cj4NCjxicj4NClNlY3Rpb24gNS4yPGJyPg0KJnF1b3Q7Tk90ZSB0aGF0IC4uLi4gbGVhdmluZyBu b2RlJnF1b3Q7IEl0IGlzIG5vdCBjbGVhciBpZiB0aGUgY2xpZW50IGhhcyBsZWZ0IHRoZSBncm91 cCBpbiB0aGlzIGNhc2UsIGFuZCB3aGF0IHRoYXQgbWVhbnMuIFRoZSBhY3Rpb25zIGxvb2sgcXVp dGUgY29udHJhZGljdG9yeSB0byBtZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5GUDogV2UgaGF2ZSBub3cgcmVwaHJh c2VkOjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6cmVkIj4mbmJzcDsmbmJzcDsgTm90ZSB0aGF0LCBhZnRlciBoYXZpbmcg bGVmdCB0aGUgZ3JvdXAsIGEgbm9kZSBtYXkgd2lzaCB0byBqb2luIGl0PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 cmVkIj4mbmJzcDsmbmJzcDsgYWdhaW4uJm5ic3A7IFRoZW4sIGFzIGxvbmcgYXMgdGhlIG5vZGUg aXMgc3RpbGwgYXV0aG9yaXplZCB0byBqb2luIHRoZTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOnJlZCI+Jm5ic3A7 Jm5ic3A7IGdyb3VwLCBpLmUuIGl0IGhhcyBhIHN0aWxsIHZhbGlkIGFjY2VzcyB0b2tlbiwgaXQg Y2FuIHJlLXJlcXVlc3QgdG88L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpyZWQiPiZuYnNwOyZuYnNwOyBqb2luIHRo ZSBncm91cCBkaXJlY3RseSB0byB0aGUgS0RDIHdpdGhvdXQgbmVlZGluZyB0byByZXRyaWV2ZSBh IG5ldzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7IGFjY2VzcyB0b2tlbiBmcm9tIHRo ZSBBUy4mbmJzcDsgVGhpcyBtZWFucyB0aGF0IHRoZSBLREMgbmVlZHMgdG8ga2VlcDwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7IHRyYWNrIG9mIG5vZGVzIHdpdGggdmFsaWQgYWNjZXNz IHRva2VucywgYmVmb3JlIGRlbGV0aW5nIGFsbDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOnJlZCI+Jm5ic3A7Jm5i c3A7IGluZm9ybWF0aW9uIGFib3V0IHRoZSBsZWF2aW5nIG5vZGUuPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxicj4NCjxicj4N CnNlY3Rpb24gNjxicj4NCi9ub3QgYWJsZSB0byBwYXJ0aWNpcGF0ZSB0by9ub3QgYWJsZSB0byBy ZWNlaXZlIG9yIGRlY3J5cHQvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVk Ij5GUDogT2ssIGRvbmU8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YnI+ DQpzZWN0aW9uIDYuMSZuYnNwOzxicj4NCnNjb3BlOiBzYW1lIHJlbWFya3MgYWJvdXQgdG9waWMg YW5kIGdyb3VwIGlkZW50aWZpZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6 cmVkIj5GUDogU2FtZSBxdWVzdGlvbiBhcyBhYm92ZTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YnI+DQo8 YnI+DQomcXVvdDtJbiBzb21lIGNhc2VzIC4uLiBzYW1lIEtEQyZxdW90Oy4gU3VnZ2VzdCB0byBy ZW1vdmUuIEluIGEgZmFzdCBjaGFuZ2luZyBlbnZpcm9ubWVudCwgdGhpcyBtYXkgbGVhZCB0byBt YW55IGVycm9yIG1lc3NhZ2VzIGlmIG5vdCB3cm9uZyBiZWhhdmlvcjsgSW1hZ2luZSBncm91cCBH QSBpcyB0aGUgb25seSBncm91cC4gQyBpcyBtZW1iZXIgb2YgR0EuIEdBIGlzIHJlbW92ZWQgYW5k IEdCIGlzIGVudGVyZWQgYXMgdGhlIG9ubHkgZ3JvdXAuIEMgd2FudHMgdG8NCiBsZWF2ZS9qb2lu IEdBLCBhbmQgYWNjZXNzZXMgR0IuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6 cmVkIj5GUDogVGhhbmtzIGZvciB0aGlzIGlucHV0LCB0aGlzIG1ha2VzIHNlbnNlLiBXZSBoYXZl IG5vdyByZW1vdmVkIHRoaXMgdGV4dCBhbmQgbWFkZSB0aGUg4oCcc2NvcGXigJ0gcGFyYW1ldGVy IG1hbmRhdG9yeS48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGJyPg0KPGJyPg0KU2VjdGlvbiA3PGJyPg0K QWdhaW4gc3VnZ2VzdCB0byBhZGQgZmlndXJlIHdpdGggcmVxdWVzdCBiZWZvcmUgc2VjdGlvbiA3 LjE8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpy ZWQiPkZQOiBPaywgYWRkZWQgaW4gc2VjdGlvbiA3IChmaWd1cmUgNik8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PGJyPg0Kc2NvcGU6IHNhbWUgY29tbWVudCBvbiBncm91cCBpZGVudGlmaWVyIGFuZCB0b3Bp Yy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPkZQOiBzYW1lIHF1ZXN0 aW9uPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KPGJyPg0KSG9wZSB0aGlzIGhlbHBz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+RlA6IEl0IGhlbHBzIGEg bG90LCB0aGFua3MhIDopPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxicj4NCjxicj4NCjwvc3Bhbj48c3Bh biBsYW5nPSJTViIgc3R5bGU9ImNvbG9yOmJsYWNrIj5ncmVldGluZ3MsPGJyPg0KPGJyPg0KUGV0 ZXI8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImNvbG9yOmJsYWNrIj4tLSZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlNWIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlBl dGVyIHZhbiBkZXIgU3Rvazxicj4NCnZhbmRlcnN0b2sgY29uc3VsdGFuY3k8YnI+DQptYWlsdG86 Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRvOmNvbnN1bHRhbmN5QHZhbmRlcnN0b2su b3JnIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImNvbG9yOnB1cnBsZSI+Y29uc3VsdGFuY3lAdmFu ZGVyc3Rvay5vcmc8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4sPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ PGEgaHJlZj0ibWFpbHRvOnN0b2tjb25zQGJiaG1haWwubmwiPjxzcGFuIGxhbmc9IlNWIiBzdHls ZT0iY29sb3I6cHVycGxlIj5zdG9rY29uc0BiYmhtYWlsLm5sPC9zcGFuPjwvYT48L3NwYW4+PHNw YW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+PGJyPg0Kd3d3OiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHA6Ly93 d3cudmFuZGVyc3Rvay5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9 ImNvbG9yOnB1cnBsZSI+d3d3LnZhbmRlcnN0b2sub3JnPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4g bGFuZz0iU1YiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+PGJyPg0KdGVsIE5MOiAmIzQzOzMxKDApNDkyNDc0NjczICZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO0Y6ICYjNDM7MzMoMCk5NjYwMTUyNDg8L3NwYW4+PHNwYW4gbGFuZz0iU1YiIHN0 eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iU1YiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_1AE4350ADF5349AEA209A04CB488215Cericssoncom_-- --_005_1AE4350ADF5349AEA209A04CB488215Cericssoncom_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=18643; creation-date="Mon, 29 Oct 2018 10:32:55 GMT"; modification-date="Mon, 29 Oct 2018 10:32:55 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAkQAAAEyCAYAAAAbc88bAAAgAElEQVR4Ae3dD3xT9b0//ldC5aK0 pVZ6JUGEB+0qOLhutL+6DXdpi8J3A/98i+LviiYTHndlY/y9hfJnzi+boJg8QECmzG8rgckdaHJR dBtgC2w6pb+EjYsCzToeApLWC2JpiyJt8/k9TnKSnLRpSdr8z4vHg0dOz/mcz5/n5+Scd875JB+V EEKA/yhAAQpQgAIUoEAKC6hTuO1sOgUoQAEKUIACFHAJMCDigUABClCAAhSgQMoLMCBK+UOAABSg AAUoQAEKMCDiMUABClCAAhSgQMoLMCBK+UOAABSgAAUoQAEKMCDiMUABClCAAhSgQMoLMCBK+UOA ABSgAAUoQAEKMCDiMUABClCAAhSgQMoLMCBK+UOAABSgAAUoQAEKMCDiMUABClCAAhSgQMoLMCBK +UOAABSgAAUoQAEKMCDiMUABClCAAhSgQMoLMCBK+UOAABSgAAUoQAEKMCDiMUABClCAAhSgQMoL MCBK+UOAABSgAAUoQAEKMCDiMUABClCAAhSgQMoLMCBK+UOAABSgAAUoQAEKMCDiMUABClCAAhSg QMoLMCBK+UOAABSgAAUoQAEKMCDiMUABClCAAhSgQMoLMCBK+UOAABSgAAUoQAEKMCDiMUABClCA AhSgQMoLMCBK+UOAABSgAAUoQAEKMCDiMUABClCAAhSgQMoLMCBK+UOAABSgAAUoQAEKMCDiMUAB ClCAAhSgQMoLMCBK+UOAABSgAAUoQAEKMCBK9GOgwwZjngoq1VxYGjui0poOmxF5KhVUegsao1Ii C6EABShAAQpEViAtstkz94gLpBWg4pQVGPNKxIvyFJBWUAFXkZs8a/hKAQpQgAIUSGwB3iFK7P5j 7SlAAQpQgAIUCIMAA6IwIIaahe+R007Y6rZAr5Ueeamg0uphtNjQ6HTn6EvneTTVBpuxxJ020OOq 1lOwVE51b1eNh964D/Y2OTO5ks7GOpi8abQoqVyDypKfeR+3hVamE612CypLtL76H7CjLVQQpqcA BShAgagI+F8DVNDqN+CAvaVL2dfQaNvhO7erpqLS+B8o6XbdaYH9wAbfNUxKV/0yKqdvgE0xguP6 ZUrlvY1qv2vTK3jT1gjPFcx3ber9utmlISH9yYAoJK7wJHY/cjIgt8GETXsyscD2NYQQEI7NeABv Yvn6OldQIaVrcJih8xabjoKKgxB+6zwbrdg8/0WcmbENnVJe4n2suusE1szYCJs3KLqIQy9sxIm7 N6LVleZT7J0z1pOB6zWkMhu2YP66RszY+Ym7/vZVuOvYOswwuuvvlzH/oAAFKECB2Aq01WH98gMY sWiv+5wtBByvzsSAbSthtDX76tbyHl5YeRJ3bz0lp3sdc0b/k2+7a+kazlt+gfnvjsQqe6ecbi8W jetE05lOX9qgyhyIW7Wj8G1vvT7F3icHwvLoZhxqcYdEwV43fQWHvsSAKHSz8O2R/ihWPfMECjQD 5Twzkf/QY5h06G3UyQdB8IUNw7S1z2FxkQbuTs1E/n0/wapH67G77pKczVdobvpSkaUa6fllWHfw RZRp+jCcbOADWLvxJyjy1D89H/ctWYpH+1R/RbW4SAEKUIACYRa4CvvualzQl6PUc86WSlAPR+n8 UpzcfRTe+0RXmtF0TVl8JvLL1uKgqQwaz+qO4/jPp29C5aqHkJ/uCSUGQlM0D6bjFShwXVKCL1Ot GYdve+ulRvqYUjw48Us0X/HcI5ILDut109MY96unFf5r+Vd0BIZlIaNrD6gHI+uWlu4HwXVrdBtG a9O7pEpDRtYgNDV/Ja8fjimrngA2lyJDekQn/S+pRHVtHx9z3T4SWu8bQS6iz/XvUnX+SQEKUIAC YRToQOulr5AzZFD3PHNGYmzNUfzd85hLcy9WzQc23zFEHoIhDa+oRq3y0dqFMzg+oRBjM7texJTZ B1um9MjMAqN+vFyedH26HTO2X1Vm5l4O63XTP/veWuKfkn+FX6CpGa1dgl84r6D580xkDe65a5yt zWjqVptPcdrRdfROB1qbr2JY1o1yas8dIYd8e/NrOIx345JpPn5Ve7FbjsoVAcs8ewYO7+M4OXUQ 9Vfmy2UKUIACFIiGQBoysm/Ehcvdgwzn6WM4NHkCvuF9UCDfEXINrRAQnTYY774E0w+fQ63n6cXg LAx734qTnr8DNiG4Mp323+LfN53BXave9z7KE+IszLoAwVsfr5sBq9dlZc9X3S4J+WcEBNp2Yc3P d8DW6Lk32QL7HjPqy2aiyBN1Swdd03GcdKVxD2B7sngO9nerThPeWbkcG+rkQWjORthMT2P+4e/i yaJsV2qnvRpTS1bC4o3ypee2t2JA17yCLfPaW1i58CXUyfV3DZxb8QscVta/a978mwIUoAAFYiAw CPkzZyPHtElxDQDQdgp7qo6ieOYEZLpqdRX26lkoqbT4vpSjvgXa2zwfrOWqZ96DBc9/iXVr9vjS oQX22l0w6ueg2i4FXsGV6Wy9hDNpI3FnnrsGaLOj9o1dePNA9+ANwVw3+6or+C8mAu1Wg8jVvS7q 681iWbFGABDQ6IRhf71o9avRZVFvXiGKpe3QiOJl24XV+prQSX/rzMLRbhWGXGlbuTDXHxfmZVPc eWGc0Bn+KOpbO725ddZXiWk6g/idQSc0rvz6VuZZqe6u8oOpv7d4LlCAAhSgQIwFOh1HxDbvdQJC o1sv9tdfVtTqK1FfNVvoDFXCoBsnX08CpZN2uSzq968XOo10DZL+S9ed34kav/yEuG6ZnQ5xZL3i ulS8TFTV/FFU6XIFUCwMVvdVMfjrpqI5ISyqpLR9Daa4X98FpK8Qjtk0Gn9WDlLre3bckwIUoAAF KJDUApG+bvKRWVIfPmwcBShAAQpQgALBCPAOUTBKYU7jinILl+Ifnnx1Zjh4p8ijwVcKUIACFKCA n0A0rpsMiPzI+QcFKEABClCAAqkowEdmqdjrbDMFKEABClCAAn4CDIj8OPgHBShAAQpQgAKpKMCA KBV7nW2mAAUoQAEKUMBPgAGRHwf/8BPosMGYVwKjresvYPul4h8UoAAFKJBoAmE8v0sDnvPyjH4z 3Ccah1RfBkSJ2Gv9rvM1NNZtgV4rz2fmmtNsA2xdp+HotZw22Iwl3nln8ow2eKbB6XU3bqQABShA AQrEoQC/ZRaHnRLxKrXUonLCa7jj7Q2YPUb+qfR+FCp9OvjOwRJ8WFEA71Q4/ciPu1KAAhSgAAWi LcA7RNEWj4fyrjSjaeI0/CAMwVA8NId1oAAFKEABCvRXgAFRfwX7sL/reav0mEq/EzbloyutHkaL DY1OT6YdaLTMlR9LzYXl/DnYTJUokfZVTcXK2vPwJnVN5urZpoJKyuuAHX6jf1zPjKVtM7B9+wxo XflIeXUZJ+RJ59reZZunasG+OhtRt0GvKGsqKqtrFZMBBpsR01GAAhSgQH8EvNce77lfBVXAsT/X 0GjbgcoSrXz9GQ+9cV+387ZffgHzOQeLPg8q1VxY7H9FtX68Oz+t3jcReX8aFOZ9GRCFGTSY7NIK KnDKakBugwmb9mRige1rSFPKCcdmPIA3sXx9nRzIpEFT9jKEOAuzrh6bH/8hKk6Mg9HxNUTrZtyL K/jSVWAzbOvXwDxiAWqkfFx5vYJZA17HPKMnLwBpBahokMoxQyf9OrYnrTiIioJ0X9U96UQrrIbb fetDXpLqVYEt+DFsnXK9xOuYM+IY1lXswXlvNBdyxtyBAhSgAAVCFJCuPQ3e8758LeiWhxNttpex 3DwMi2oc7uuJOI5XZ6mxbd6LfmNNvfm1W2HI6pYRgBEoMx10X7/Kf4kG/R/RKTrRWluKvz22GYda 4usiwIAoUB9Ga136o1j1zBMo0AyUS8xE/kOPYdKht1HX7UDJwnef+iNq1snp0/NRWpoPKYxx2i14 +kIZlpcOV4ySHwhNqQ4PnvxDgLyi1MCWo9h9aDJWLZwIjfdIy0T+fT9BZdHfsK/hapQqwmIoQAEK UCAoAacdu5++CP3yyYrzNqDWlGD+g+exu+5SUNn4J7qG0fNfwDOua5Qa6WNK8eDEL9F8hQGRv1Mq /zUsCxneQEGGUA9G1i0tAQ6UkSgce6si4PHBOVsvoSlnCG7yrZKXbsbIsadx9O/u+0jdNkd6hTRW 6Z05uGOA4ttsrlu1N+KOOTtx+KMLka4B86cABShAgVAEnFdwqSkTQ27qenFKQ87IHNQcPdOHbxT/ P5j2XeUH9lAqFL20XVscvZJZEtDUjNauAbLzCpo/z0TW4OC7Rp2RjWEXLsuPzxSwzk9x7NBITPhG 91BJkSpyi7feiUnl21DvfVzmeWwmvTbAVDYicmUzZwpQgAIUCF1APRjZw1pw+cuuF6erOH2sAZMn jEzabxMHf9UNnZV7XE+gbRfW/HwHbI3X5JQtsO8xo75sJooyg+8adX4ZVudYsMZySjGIWsprJw4X Tw8pr+tVOaTt6tH4wcwLqFpvUbQRQNspWCpnobL2YkjZMTEFKEABCkRYQJ2PmauHwrRmj2IQtRNt 9t+j6vCdmFmUHeEKxDB7wX8xEWi3GkSu7nVRX28Wy4o1AoCARicM++tFq7dGZ4VZl+veJm33/s8V OvNZbyrXQqdDWLctE8WeNN3yEkI4zELn2e73Wi7MjnY5v1ZhNRQrylKWWywMVnftXPX3y8OXLtdg FZ7chPhaOKxmYdCN8+ap0RmE2eoQnf4t4F8UoAAFKBBNAemakGsQVt8JWy5dOm9v912bME7oDH8U 9a2Ks3a7VRhyfed93/UJAt48ldcw+frht5/vmhLNZvdUFn+YMUbBqPR1xTGbRuPPpjJoYlQHFksB ClCAAiksIP3EyiPH8IB5NvKDfyiRtGAkSNquZcMoQAEKUIACPQlcQ+Of3saB/FEYxkjAhUSGno6V CK533R0qXIp/eH4cUW9BYwTLY9YUoAAFKEABvx9SVI3CY/tGY+2ie9D/CZySw5aPzJKjH9kKClCA AhSgAAX6IcA7RP3A464UoAAFKEABCiSHAAOi5OhHtoICFKAABShAgX4IMCDqBx53pQAFKEABClAg OQQYECVHP7IVFKAABShAAQr0Q4ABUT/wortrG2xGPYy2tigWG4syo9g8FkUBClCAAr0IhPcaIH3L rdBo68NcaL1UMYybGBCFEZNZUYACFKAABSiQmAIMiBKz31hrClCAAhSgAAXCKMCAKIyYzIoCFKAA BShAgcQUYECUmP3GWlOAAhSgAAUoEEYBBkRhxGRWFKAABShAAQokpgADosTsN9aaAhSgAAUoQIEw CjAgCiMms6IABShAAQpQIDEFGBAlZr+x1hSgAAUoQAEKhFGAAVEYMZkVBShAAQpQgAKJKcCAKDH7 jbWmAAUoQAEKUCCMAgyIwogZ+axuRnZGWuSL8SshFmX6VYB/UIACFKBAzATCeQ0YgBHZgxGvgYdK CCFi5syCKUABClCAAhSgQBwIxGugFgc0rAIFKEABClCAAqkiwIAoVXqa7aQABShAAQpQoEcBBkQ9 0nADBShAAQpQgAKpIsCAKFV6mu2kAAUoQAEKUKBHAQZEPdJwAwUoQAEKUIACqSLAgChheroNNqMe RltbwtSYFaVAtAQ6bEbkqVRQ5Rlh64hWqSyHAhQIRUB6nxYabYjXtygDolB6M+XSMghLuS6PWoPP waKfCP2G99Ho7H+haQUVaHCYoet/VvGTQ5sdB4x6aKdWwx4Go/hpGGuSOAKpdQ1gQJQ4RyZrSoEk EhiBslffwDz8BgWTK2GyNYLXfE/3tsB+YAP0+fPxbs482P4wG/k8U3tw+EqBiAnwbRYxWmZMAQr0 KqDWoGjxq7BvLcWFTfdjcuUO2Bqv9bpLsBu9j9Ckx2iqEt+jZmcj6jbooXWtl7ZNRWV1LextnnBM unOVB1XX/Rot0LvW5UFvORdsNUJO52ysg6nyMZS/OxQLbHuxTl8EDc/SITtyBwr0RYBvtb6ocR8K UCBMAmqk509FhakWW++9iE0F96PSVNfPx2hOXM0YjRm6p2CuvwwhDqKiIB1AM2zrK7AFP4atU0D6 kX4hXsecEcewrmIPzrtiIunO1duomvI9LKt5Xd4PgOYhbLGux5Rlv8HmshFharsiG2cjbKZKTC7Y ggv3rsfedU+gQDNQkYCLFKBAxAWkqTv4LxEEWoXVoBMGa2tkK9tuFYZcSNO5BPyfa7CKdiFEu9Ug cq+TRgipzsUB8wGKfW3prcxcg7BKBaZMmali1sNh7DALHSA0s83i084e0vS0Wto3d4mo+t0KMUX3 ojji+No/5eUasWxalajvlu9Xor7qKVFV/5WcvlNcrlkhNFMUaTs/EebZsxVp/LPu11+dJ0XVFI0A yoXZIR/sATNM9GMj0esfi/NeDMx6Ox8DwnMNCHiIXmeldN0okK8h10kak83SpyT+SwgB6Y0RhYDI zyIWZfpVgH+kjMBlUb9/vdBppohl244IR7egJQgIVzA1Tjyme0RMWbG/ex5ysBU42M8VOvNZXyGu IOV7YlnNBSFEp2i1bhQ6wxERsY8jnQ5h3bZMFGt0wrC/PnLl+FrIJQoEIRDea0C8B0R8ZBbxe3As gAIU6FnAiTb7Phj1peEZN5Orx5Kq/4uNeWb86OcH/B+93XonJpVvQ733cZnnsZn02gCT8lGYOh8P V07CjnVvwd5xDvtfOY8H/+1bkB68ReSfWoMC/TrU2OYh5935yNdvQV2YxlNFpL7MlAJJKMCAKAk7 lU2iQEIIuAY4P4n88lrkLNiLmrCNm8nEmNnPY2PeO/j5to/g/eUu9Wj8YOYFVK23+A/ebjsFS+Us VNZeVLCpkVmswzP4Ndas2oA382ZgyvDIj+lRa4qgX/c6Dj1+DVvCMp5K0SQuUoACvQowIOqVhxsp QIGICDhPofoH97sHONesg75Ag/6cjFzfKtPOwHZvZS/jxOG3UT1nPDJUnm+GDYSmdAEWlQAHlxfI 3yRTQTvvbWCmEc+WDvXu7VpQ52Pm2lk4u6MjsneH/EsFkIn8+xbDZN+Mey9swfdX1KKlWxquoAAF wi2gkh4ihjtT5hcJAekHsubhYMkW3zdfIlEM86QABWQBJ9psL2Lewe9gS0VR5B6X0ZsCKSIgfXD5 zsESfFhRgLQ4bHN/PpTFYXOSvUo3IzsjHg+jZHdn+1JSwBmFsUMpCctGp67AAIzIHtyvu8GRtOMd okjqMm8KUCDBBDrQaPkZtDO2KupdDIN1L+/MKkS4SIFkFGBAlIy9yjZRgAIUoAAFKBCSAB+ZhcTF xBSgAAUoQAEKJKMAA6Jk7FW2iQIUoAAFKECBkAQYEIXExcQUoAAFKEABCiSjAAOiZOxVtokCFKAA BShAgZAEGBCFxBXLxNLvEOlhtHl/dzeWlWHZFKAABShAgZAEpN8hKjTa0BHSXtFLzIAoetYJWBKD sATsNFaZAhSgAAX6IMCAqA9o3IUCFKAABShAgeQSYECUXP3J1lAgcQScjbCZKlGiUrnmFdNKM7zb dkIv/Z1nhM11X/0cLPo897xjegvON9bBVDnV/XfJatR6Z4S/hkbbDlSWaOU5ysZDb9wHe5tT9pDu dpZA5Z3XDECHDcY8qWzPXGfSKiPypPL1O2Gr2wK91l03lVYPo8WGRk92rlydaLPvg1E/Xi5Ti5LK l1FdOcf/0XaXdrryOmCXJ5311Gs89M+tdpWn1Ztwwr4PK11tmYqVtefh9NRVq8dzz+mhVY2HvtoG e+1qt5+fReIcAqwpBeJJgAFRPPUG60KBlBFowalt6/DrSw9gZ6eANKXip899C+9vehbbdWY4GipQ 4JqlZgTKTA0QDjN0DZvxeMFTOHHnr+Do7ETr1lKg9SoAac6xl7HcPAyLahyuvIQ4jldnqbFt3ouw uYKidBRUHIDDPN0nnFaAioZ2v3VpBRU4ZTUgt8GETXsyscD2tTs/x2Y8gDexfH2dHMgAzvN7sHD+ YYxe9b5cpgM1i8bjctMlXxlohm39GphHLECNcLdTOF7BrAGvY55Rykuq115YDUOxfR+gt13GoUnv 4JvFu5H30gm0Wv8XPjAdwWdSXU9ZYbjpAPa1PA5b++uYtOt+FJtG4aXWz2Gd9jFMH3ymKJeLFKBA qAIMiEIVS/b0nk+irk/tGShcuh1LCzPkT8Aq5MXxgLhk75qkal+LFa9a/gWVCydCI5+F1JqJWLhq Mab01NCBxXjKthfr9EXQqNVIz/8+SvMzAacdu5++CP3yyd68pCzUmhLMf/A8dtcpA5SeMu+yPv1R rHrmCRRoBsobMpH/0GOYdOht1LVIt4na8Nf//B2GVi5BmVQH+Z/UhsWm//JO8+G0W/D0hTIsLx2u mL9pIDSlOjx48g9yXtLOt8Ng/A+UajIx+q4iFCz5KXRjspCuHYnbPZlLr1lLYPzlfdCk3Ya77rsP SxbMwJj0TGhHa5WpuEwBCvRBgAFRH9CSehfXp2b5k6xohdWgg8HaKn8CFmiI01mKk7pPkrFxV5rR dEsWMrqcgdQZWRjWU3tvH4+x3gBFkch5BZeaMjHkpi6ZIQ05I3NQc/RM6N9qGda9blAPRtYtLWi+ IgVEX+DMcS3uHpulqEj3RWfrJTTlDMFN3TbdjJFjT+Po37/stoUrKECB2Ah0PYPEphYslQIUSC2B wVkY9nkzWruOyXGcwdlQJdSDkT2sBZe/9MsMwFWcPtaAyRNGwvX0LWC+HWht/qL7lqaudZOezF1B 8+eZyBosnTZvRNawBhw52dx9X8UadUY2hl24jG5hj/NTHDs0EhO+0T1UUuzORQpQIIoCDIiiiJ2U RbXVwega/DkdRltPFwdpjMcGefDnBnlMRyCNZtiM06FSaVHiGl8RKI30tCIVykwCsx66z7U6sxBP lv031m18Xx6oLA1Q3oNfVRhwqLf9Am1T52Pm6qEwrdmjGEQt5fd7VB2+EzOLsuW91BiclYkm6yl3 mW12HDCWo3jO+91zbduFNT/fAZt30HYL7HvMqC+biaJM6bQ5FMULZuPiuvWw2Fvk/aUyD+EN4xxM rz4FKTxT55dhdY4FayynvGOPACmvnThcPF3Oq3vxXEMBCkRfgAFR9M1ZIgUogEyMmf1LVI58B48N kL7JNQD5axoxw2iETqnTaHF/60w7A9u3z4BW/kaaSjUXlkbPz7upkV4wF8/NvIKq+2+Tx7vdhXlv DcacLT9DQbrnNKdGZtFjKO80QiuVmTEf7+b8GHtfvxfbZ5RAbznnKznv37HqR4Ox+7FR7vy08/FW xiN4avY4pMup1MMfwsbNk3B6zUS5TKkNVmBCJX43e4w8ZigLBUtWYWbrq7jfU3dXXo9jS0UR0iF9 y+x+eazet7x1aF5aiDGe8Xqedt9QiKW2pSi8wdP2s1haeL/8jbar2D7jdo7x8/UglygQsoBKSF/v 4L8EEJBOnPNwsGSLd8BmAlSaVaRAaAJSALQceM5UBk1oe4YttfTV+zGbRuPPMaxD2BrDjCgQRwLS e+s7B0vwYZyORfV8dIojMlalZ4GbkZ3R82iInvfjFgokgIDzPGo3V+Ps+NuQkQDVZRUpQIFQBQZg RPZgxTcuQ90/sul5hyiyvsydAhToUaADjZafQTtjq5xiHHTrX8Zziq/i97hrhDa47g4VLsU/PPlL v4nEO0UeDb5SIKkFGBAldfeycRSgAAUoQAEKBCPAR2bBKDENBShAAQpQgAJJLcCAKKm7l42jAAUo QAEKUCAYAQZEwSgxDQUoQAEKUIACSS3AgCipu5eNo0CqCUg/jnhM8QONqdZ+tpcCFOirAAOivspF fT/pd4j08o+wRb1wFkiBhBBwzUBf/AOUv2xV/DJ0QlSdlaRA0gtI3+Is9PzgaBy2lgFRHHYKq0QB CvRBwHkGe36xGdj0W8w7WYmFljOu6TP6kBN3oQAFUlCAv/KXgp3OJlMg+QSaYVu/CJvHrsPeh4tw 08ROHP3Rs9h25/OYPSYz+ZrLFlGAAmEX4B2isJMmS4bBTi6aLO1lOxJZwGm34OnjD+GluYWuucbU mslYufYO7Fj4BuzSLKv8RwEKUOA6ArxDdB0gbqYABeJfQJ0/G2+blPWUJnxdjIP7lOu4TAEKUKBn AQZEPduk+Bb5giIWp7gDm08BClCAAqkgwEdmqdDLbCMFKEABClCAAr0KMCDqlYcbKUABClCAAhRI BQEGRKnQy31qIwdV94mNO1GAAhSgQEIKMCBKyG5jpSlAAQpQgAIUCKcAB1WHUzOp8uKg6qTqTjaG AhSgAAV6FeAdol554m3jzcjOYAwbb73C+lCAAhSgQDACAzAiezDiNfBQCSFEMM1gGgpQgAIUoAAF KJCsAvEaqCWrN9tFAQpQgAIUoEAcCjAgisNOYZUoQAEKUIACFIiuAAOi6HqzNApQgAIUoAAF4lCA AVEcdgqrRAEKUIACFKBAdAUYEEXXm6VRgAIUoAAFKBCHAgyI4rBTWCUKUIACFKAABaIrwIAout79 KK0NNqMeRltbP/LgrhSgAAUoQAEKBBJgQBRIhesoQAEKxLUAPyDFdfewcgEFOmxGFBpt6Ai4NfYr GRDFvg9YAwpQgAIUoAAFYizAgCjGHRC/xXO2+/jtG9YssACP2cAuXEsBCgQjwIAoGCWmoQAFKEAB ClAgqQUYECV19/ancZ7Z7gXEwcUoSOeh0h9N7hsNgSQ/ZjtsMOapoFJJ/zNQuHQ7lhZmyH+rkOcZ m+GXzpNefs0zwiYP4JDGc+S58uqSRqXIC9JYpRJvGe6yPelLfF/yCKrMcOYFRL/+sSgz0c38639D 4VLYlhbiBs9xpzgeo3GGuF4ZnNz1ekJxs106sObhYMkWVBSkx02tWBEKUCAWAjwfxEKdZfZPQApi v3OwBB9WFCCtf1lFZG9+7I8IKzOlAAUoQAEKUCCRBBgQJVJvRbWuHKAaVW4WFgYBHrNhQGQWFEhZ AQZEKdv1bDgFKEABClCAAh4BjiHySMT9KxbfNPcAACAASURBVMcMxH0XsYIUoAAFKJCwArxDlFBd dzOyM+JxKFpCIbKyFKAABShAgW4CvEPUjYQrKEABClCAAhRINQHeIUq1Hmd7KUABClCAAhToJsCA qBsJV1CAAhSgAAUokGoCDIhSrcfZXgpQgAIUoAAFugkwIOpGwhUUoAAFKEABCqSaAAOiVOtxtpcC FKAABShAgW4CDIi6kcTrCul3iPS+yRTjtZqsFwUoEAUBng+igMwiwiwgzWVW6JmEOMx5hyM7tXv2 Yi1KjHVoC5SjsxE2ixF6rTzDcUklTLYP8YZ+ESyNHdL0v4oZmD2zIHte86C3nAuUK9dRgAIUoAAF KECBuBFQf2pehvLXf4PHDr2NuhZnl4o1w7bxNzh2549hcggIISBqFmHsn17Cgu1X3WnTClDRcBZm 3UKYHe3uNFI60Q6HeXqX/PgnBShAAQpQgAIUiD8B9b7qf8LMKaWYVPY/2Ge95FdDp92Cp5u+j4fH ZPrWqzUoWrgCz0zhLyb7UJJxiRNlJmOvJnebeMwmd/+ydRSIrIDa8s1iFGbehPyHZ2LA7j/hvPcm UQc+++i/ccvd34AiHHLXRj0Gs/e9iDJNoKDoHCyux2mApuwFmMpGRLYFzJ0CFKAABShAAQr0U0Bd Nud77oAn819w75D92NcgPwoLOeO3MUN7A1Sq2zHD8zgt5Dy4Q/wIqJFesBgHpcefBxejIJ3j7+On b1iTwAI8ZgO7cC0FKBCMgHrOHTfCPbA6B5Offwu73vsE3ptE6EBT8xXF371lOV0eQySNJxrUW0Ju owAFKEABClCAAnEloO50DYCWB0x31uJRy04ccg2uTsOtd5fiNstf0OCLkIKo/AiUmV6QH6edw5vV f0ZLEHsxCQUoQAEKUIACFIiVgNrvQYh6FO5RDK5WD5+OZ5Y0Ys0KC+xtnqioBfbaXTDqZ8Foa+69 3o3/Hyxrj+DvHb0n49Z4FOAA1XjsFdapNwEes73pcBsFKNC7gDrP8yNJrt8TuhF3zNmK5yfnwL1+ IDSlS/HcTOCteXfJj9bGoHzfFUxY9RIqCrLk3yGSxg1tlMcQeX6DSAWVdga2914+t1KAAhSgAAUo QIGYC6iE9ONC/JcAAtIv087DwZItqChIT4D6sooUoEDkBHg+iJwtc46UgPRL1d85WIIPKwoQ6Dvq kSo32Hz9npgFuxPTxUrgZmRnxONhFCsPlkuBVBbg+SCVez8x2z4AI7IHI14DD94hSsyjirWmAAUo QAEKUCCMAvEaqIWxicyKAhSgAAUoQAEK9C7AgKh3H26lAAUoQAEKUCAFBBgQpUAns4kUoAAFKEAB CvQuwICodx9upQAFKEABClAgBQQYEKVAJ7OJFKAABShAAQr0LsCAqHefONoq/e6IHkZbWxzViVWh AAViI8DzQWzcWWp/BKTfISr0/Bh0fzKK0L4MiCIEy2wpQAEKUIACFEgcAQZEidNXrCkFKEABClCA AhESYEAUIdjEz5YTZSZ+H6ZaC3jMplqPs70UCKcAA6JwajIvClCAAhSgAAUSUoATYyVkt0Wj0mqk FyzGQbE4GoWxDAqEQYDHbBgQmQUFUlaAd4hStuvZcApQgAIUoAAFPAIMiDwSfKUABShAAQpQIGUF GBClbNdfr+EcoHo9IW6PNwEes/HWI6wPBRJJgAFRIvUW60oBClCAAhSgQEQEOKg6IqzJkCkHqCZD L6ZWG3jMplZ/s7UUCK8A7xCF1zPCud2M7AzGsBFGZvYUSBABng8SpKNYTa/AAIzIHox4DTxUQgjh rSsXKEABClCAAhSgQIoKSAER/8ebQa5BWNulcLW3f+3CYS4PW9/lGqziukWKs8Ksyw1bmTz2+N7r 3zFQLAzW1t7eJEKI8L5P+lffPvZ3DM4HMWlnvJ2HWZ9+nOtj8N7MfUToHun79Yl3iFI0CmazKUAB ClCAAhTwCcTrozxfDblEAQpQgAIUoAAFIizAgCjCwMyeAhSgAAUoQIH4F2BAFP99xBpSgAIUoAAF KBBhAQZEEQYOX/ZtsBn1MNrawpclc6IABRJUgOeDBO24lK52h82IQqMNHXGqwIAoTjuG1aIABShA AQpQIHoCDIiiZ82SKEABClCAAhSIUwEGRHHaMbGvFifKjH0fsAahCfCYDc2LqSlAAaUAAyKlBpcp QAEKUIACFEhJAU6MlZLdHkyjOVFmMEpME08CPGbjqTdYFwokmgDvECVaj7G+FKAABShAAQqEXYAB UdhJmSEFKEABClCAAokmwIAo0XosavXlANWoUbOgMAnwmA0TJLOhQEoKMCBKyW5noylAAQpQgAIU UApwULVSg8sKAQ5QVWBwMSEEeMwmRDexkhSIUwHeIYrTjglcrZuRncEYNrAN11Ig1QR4Pki1Hk/8 9g7AiOzBiNfAQyWEEImPzBZQgAIUoAAFKECBvgvEa6DW9xZxTwpQgAIUoAAFKBCiAAOiEMGYnAIU oAAFKECB5BNgQJR8fcoWUYACFKAABSgQogADohDBmJwCFKAABShAgeQTYECUfH3KFlGAAhSgAAUo EKIAA6IQwWKXvA02ox5GW1vsqsCSKUCBOBHg+SBOOoLVCEGgw2ZEodGGjhD2iWZSBkTR1GZZFKAA BShAAQrEpQADorjsFlaKAhSgAAUoQIFoCjAgiqZ2QpXFiTITqrtYWQA8ZnkYUIACfRdgQNR3O+5J AQpQgAIUoECSCHBirCTpyPA3gxNlht+UOUZWgMdsZH2ZOwWSW4B3iJK7f9k6ClCAAhSgAAWCEGBA FAQSk1CAAhSgAAUokNwCDIiSu3/70ToOUO0HHneNiQCP2Ziws1AKJIkAA6Ik6Ug2gwIUoAAFKECB vgtwUHXf7ZJ8Tw5QTfIOTsLm8ZhNwk5lkygQNQHeIYoadTgKuhnZGYxhwyHJPCiQ+AI8HyR+H6Za CwZgRPZgxGvgoRJCiFTrEraXAhSgAAUoQAEKKAXiNVBT1pHLFKAABShAAQpQIKICDIgiysvMKUAB ClCAAhRIBAEGRInQS6wjBShAAQpQgAIRFWBAFFFeZk4BClCAAhSgQCIIMCBKhF5iHSlAAQpQgAIU iKgAA6KI8jJzClCAAhSgAAUSQYABUSL0EutIAQpQgAIUoEBEBdRG/XioVCqoVFNRaXoftjcWQW85 5yvU2QibxQi9Vkqjgkqrh/GAHW2eFI0W6F37y9s9yyWVMNka4ZTTddiMyPNs6/Y6F5bGDk+OfKUA BShAAQpQgAJRFVDPNR2H9NuMQuzForF/w6YFbysq0Azb+p+i4sitWGD72pWu0/ZjDPjtY7jfWOcO ijRlMLVbYcgth9nRLuf1NRzGcThRUYFt9quu/NIKKtDgMEOnM8PhKk8qU/p/FmbdIEWZXKQABShA AQpQgALRFVCne8sbCE3RHKx6ZqK8Rpo5+lWsPPkEfvvsEyjQDHStV2smYvGWX2PaOxuxWw52vFl4 FwZCU/AI5jyRhsMfXfCu5UIoAm2wGUvku3cqqPKMsHV0oNEy17dOVQKjzXuvLpTMe0gbizJ7qApX UyBkgWSe7Z7vzZAPB+4QcwH/J0Py9arLU6U8ow1x83xImroj8L+vRH1VuVhWcyHA5nbhMM8TU6pO ik5pa7tVGHLLhdnRLqe9LOr3rxe6Kf9H1Di+9u3vMAudziwc0hrlsi8Fl/wEOkWrdb2YsqxGXFas 7/zULGZPqxL1LnzFhrAsxqLMsFScmaS8gPvYLQYEitcLa2tE3iAxVOZ7M4b4LLqvAq1HhGHKU6Lm suL92PmJMM+eLarqv+prrhHZr5dB1R1ovfQVcoYEepyVhpyRo/D5pSveMULAVszQ3iDfvZiINcdG YsG2FSiV7yx5Q9XtM6CVxhBpZ2C7dyUXAguokf7tMpRffA1veO/GXUXDvv0YuuQB5PfSe4HzC2Zt LMoMpl5MQ4HrCXhmuxcQBxejID0ib5DrVSKC2/nejCAus46UQPq38G/lLVj/ht0bLzgbalA9dBYe zg8UX0SqItfPt5czRhoysm/EhcvuMUD+WXXgwplPcIvfrLWeMUSdaK1fjWEH9uNYoH09Y4ik8UT+ mfKvQALqEbh31nDseuu/3WO2Wv6Cql13YGZRdqDU4VkXizLDU3PmQoHkFuB7M7n7NylbNxDD730A 39z1B/y1Tfqa1UUcqjqM4pkTkBln7e0lIBqEvHuK8PFrf8J5z1fFPJVvO4rXNn+BR+8Zhe4ZqJGe X4Znq6fg/YUbUNt4zbOX/6s0GNtUBo20tnEfqmsv+m/nX7KAGpnFj+HRQzux/3wL7G+8hovlZfh2 RD/9xqJMdjgFKHB9Ab43r2/EFHEnkPk9zHn0I/x6/zl02N/C+osP4t++nRV31VRb7C1ypZxosx/C G8Y5mCp/g0ydX4bVY3fg8RU7YJMDG2fj+9gw76d4Z9pCzOzldpd6+HT8svwCfvzCe/CUELj1HWj8 4L+w9uiZ+BlYFbiisVurzsfDSzJR/Z87Ydk1HLPuHREgEA1z9WJRZpibwOxSTSCZB1Ur+pLvTQUG FxNDYBDyH56FodW/xXbLYXxz1r9iePe7KTFvihpvzXeP6VENQEb5H9AyoRLmiiK4v32WhYIKE7be exGbCv7JNT5oQMFv0Pn4Tuz1pJFGjN9QiKX/kMcQ6S1odDVrIIY/9DOs/NvjGJJnxIcfGpEnjRvy jCHy/hbRDdDO2BpziPiugBqZRdNR/I4RBx99DMWZ0TiSYlFmfPcCa0eB+BDgezM++oG1CEkgcwJm Fn+AOQcnYU7x0JB2jVZilTRUO1qFsRwKUIACFKAABSgQjwLRuNUQj+1mnShAAQpQgAIUoIBXgAGR l4ILFKAABShAAQqkqgADolTtebabAhSgAAUoQAGvAAMiLwUXKEABClCAAhRIVQEGRKna82w3BShA AQpQgAJeAQZEXgouUIACFKAABSiQqgIMiFK159luClCAAhSgAAW8AgyIvBRcoAAFKEABClAgVQUY EKVqz7PdFKBAdAScjbBZjNBrVa5f+1dp9TAesLsna1bWoO0ULJVT3WlUWpRUVqO6chaMtjZFqmto tFlg1I+X001Fpel92N5YBL3lnC/d9cqUZhjwzhYg10v6u6QSJlujPCt5G2zGErkcRRrPft5ZCXzF cokCiSzAgCiRe491pwAF4lygGbb1P0XFkVuxwPY1pIkBOm0/xoDfPob75TkjXQ1wnoFl4S9gnVqN TiEgxClsvbsBO553KNonzdVWjReO5WOu6bgrLyH2YtHYv2HTgrcV6YIoU5pcu90KQ245zI52Oa+v 4TCOw4mKCmyzXwWQjoKKA3CYF0JnPiunkeomIBxm6BQlcpECySDAgCiWvdhmxwGjXp5Lzv3prLq6 EtONNsVEt9Inwh2oLNHKn9TGQ2/cB3ubU1Hzc7Do89zb9Racb6yDyfNJs2Q1auWJeYFraKzb4vuk Kn8KrfVO8KvIkosUSDiBeJvcVarPq1h58gn89tknUKAZ6BJVayZi8ZZfY9o7G7HbFXgAcF7E6WNF mPGvw+WJmzORX7YETy3L8fWC047dTzsw9eE75bkmpU0DoSmag1XPTJTThVCmL2d5aSA0BY9gzhNp OPzRhW5buYICyS7AgChWPez6RPhzvDt6BeyuT4QComYRxl1uwhlvnaST28tYbh6GRTUO+RPacbw6 S41t816EzRsUjUCZqcH9qa1hMx4veAon7vwVHJ2daN1aCrRKn/akvLbgR1uAefInVSE+xd45w3F0 3RpYzl/zlsoFClAgHALX4DhWj28Fmtk7fQJmzb8Zu977xP14Sj0Uo+96B5teUH7YGYrSdbtRUeCe ahufncDhW76Fsd0mdx6E/NkmmMpGQPrQE3SZ3ZrYAvuBl7Bm12jov3trt61ABxot8qM56Q6TqQya AKm4igKJKsCAKEY91/HX1/H00LlYVTbG92lPrUHRYhOOVxQgTaqX6xPhReiXT4ZG0VNqTQnmP3ge u+suda/9wGI8ZduLdfoiaNRqpOd/H6X5mQAuoW53PR5dNQdF8idVQNo+FUsq78T+faflcQPds+Qa CiSGgBrpBYtxUPqAcXAxCtIVb5qYNKADrZe+Qs6QQQFKT0POyFH4/NIVOSAaibKNW6EfdRxr8gdA 5bp7+wostQHGGgXIzbcqhDJdO23FDO0N8t3niVhzbCQWbFuBUu85Qkp0Fdtn3A6V6gZoZygfzflK 5RIFkkEg1meMZDDsQxs6cOHMp5hw9zcghSo9/nNewaWmTAy5qWs3SSfTHNQcPaN4tCbncvt4jPU7 mXly/wrNTe9izh03dhskOeCOH2Hr4RP4zJOUrxSgQBgE0pCRfSMuXJbu0Hb9J50DPsEt2YPlR2TS kJ18lD5cAZNDGqcj3b29HadN5VhoOeP7sNLUjFbl0/Ku2SLEMuEZQ9SJ1vrVGHZgP451q+8geQxR Oxzm6d1K5AoKJItA1yttsrQrztuhxuCsm/D+kb+jpbeaqgcje1gLLn/Z9Qx4FaePNWDyhJHuO0m9 5eHdloNxkx5DVf1X/oMjPY/rePvbK8UFCoRHYBDy7inCx6/9Cee7voXbjuK1zV/g0XtGQQ0nWmp/ genVp3yBj3z3dtGCaTh2+qJ7/a0FePC29/FeQ6AAy1PjYMv0pPe8SneLy/Bs9RS8v3CDYtyhZ7v0 mgZN2Qvyo7kONL65E7UtXRumTM9lCiSWAAOimPSXGpnF5Xj+4stYYznl+/ptmx21bxihn14Nu3Se Uedj5uqhMK3ZoxhE7USb/feoOnwnZhZlh1D7Qcj7wffxSdVLsHi/Vivt3gK7ZSWmVtb2HpyFUBKT UiA2AtI4uQ0ocX19fINijF1saiOVqs4vw+qxO/D4ih2wyV9ucDa+jw3zfop3pi3EzHzpcZoTV5r/ B+/8/Fms9/s6fjOOHTzu++CjHomHnvl/0bBmLSzeL0JI54NDeMM4B1Plb60FV2ZgE/Xw6fhl+QX8 +IX3rnM+aMQHlp04+vcvA2fEtRRIRAHBf7ETaK0X+w06oQEEpP8anTC8flDUt3Yq6vS1cFi3i2XF GncajBM6wx/90zjMQufJw++1XJgd7Yq8hOh0WIW5a5lmq3Aoi/Tbg39QIFEEOkWrdb0olt4DxeuF 1e99FMs2XBb1+9cLnUbxPt9fL1q9VeoUl2ueEtMMr4s/Kt+bxctEVY0ynXuHbu/hgOmuU2bXc4bO LBye+nSeFFVTNAK5y4ThmWL5vCPX3e/8UiwMVl8rPLvzlQKJKqCSKp6IgRzrTAEKUIACFKAABcIl wEdm4ZJkPhSgAAUoQAEKJKwAA6KE7TpWnAIUoAAFKECBcAkwIAqXJPOhAAUoQAEKUCBhBRgQJWzX seIUoAAFKEABCoRLgAFRuCSZDwUoQAEKUIACCSvAgChhu44VpwAFKEABClAgXAIMiMIlyXwoQAEK UIACFEhYAQZEcdt1bbAZS6BS5UFvORelWsaizCg1jcVQgAIUoAAFehFgQNQLTmw3paOgYi+shjFR rEYsyoxi81hUCghIQb0eRltbFNoqTZuxD0b9eHnC5PHQG99GbfXPovghpn/NdDbaYDHqoZWmO1Fp UVK5AzbbTuj1FjT2L2vuHRaBDjRa5kKr34I6eeqX/mbr3+cqaPUbcMA7FYwnd+nYtqCyRCsf21NR uesVVBYaYevwpJFmnWmEzWKEXisdPyqoSiphsn2IN/SLYGn0Jey9THcbXfu7jkM5L8/x6G235wO7 Z3uX1zAcswyIFH3LRQpQgALBCUjzpm3EjDVNmL7lmDxh8nGY5o7CJ4f/GlwWsU7VVoeNL5zAnXNf hcM1ybMDNYtG40+bnsX2WNeN5csC0oS6m2CbB2wpuB+Vpjo09mc+3bY6rH/saRzJmQdbp4AQX8M2 byB+W/wYjLZmr7rz/B4snH8cU3d+4j62Wzfi7qNv4HlfEgDNsG38DY7d+WOYHFJeAqJmEcb+6SUs 2K6YgPi6ZUptfBntVgNydWb5WBQQnTYY7/wIFT/6rXtuT0gf2A/AYV4Infms/yTlDjN03tr3fYEB Ud/tuu/ZYYMxT4pa5+IN2yFs8PvkaPFO7ghFOk8U3WEzIs8VHc/1i6zdhVx2TcDqmrRS1UNEL0Xq pkr3xJauSP0/YKz8375PqpEos7sA11AgNQScdux++gzK1/4bxqQrTqPp4zDb9L48I7xEcQ4WfZ77 07PegvONdTBVTpU/Ta/2m1XeqdwW4H3uPUd4PwkrPjF71ine572eg3AV9t3VaJr6A7/6qzUTsXDV YkxR9mLXc4tWD6N3ElpPHcZD/9xq150Crd6EE/Z9WOm6uzAVK2vPw+mpl1aP556T7kiNh77aBnvt ankyXn8LZfFcHghN0TyY7Jtx74UtKJgs3YVpROhxUTNsL2/Eyflb8Ky+CBrXYSvl/RNs2TsZ76y0 yIEH4Gw6jWP3Tce/aga6+dPHoGxVJZbd6OsNp92Cp5u+j4fHZPpWqjUoWrgCz0xJk9cFX6YvE3lJ rUHBE0/iCRzFR5/57jZ1SxfGFYp3chhzTdWs0gpQccoKQ64VWzbVInvBfnS6Pnkdw5YHgN3LX3bP wC2lazgLs06a6dr9L62gAg3Cf517SzsaNi/HujPTsNMV0XfCvupOHFvzE0VE70TLoZew8sTd2Nra 6Y6c9/47Rnsyl17DXqYycy5TIMUEPjuBw+3/gnGeC0aPzR+BMlMDhPQJtmEzHi94Cifu/BUcnZ1o 3VoKtMqfpKVP0csPYMSivd5Pvo5XZ2LAtpXe97nrHOH3SVj6xHzQnben/GDPQbiAjw4Pwt1jszx7 el/V+bOxz1QGjWtNM2zr18A8YgFqXOcyAeF4BbMGvI55xjq0uT61S4/2h2L7PkBvu4xDk97BN4t3 I++lE2i1/i98YDqCzzz1uukA9rU8Dlv765i0634Um0bhpdbPYZ32MUwffOatAxcCCKTn476KV2Hf WooLm+7HZOnxpvdxUoD0XVc5m3DsUC5m3TsC/hd+NdILHsb8YYfxXoP7eFQPG427Xt6EF7yBL4DM Uqw7XoECV6zTgc8++m/ccvc3oAiH3CWqx2D2vhdRpkmTIqugy+xaXbTZcWC9AbsKHsR3b/UEWMpU 0qO2Re4P/ZoymLzHrDJNaMv+LqHty9Q9CozGE6tWQl+gkQ88NdLzf4g5k05gd92lHvfqacPAab/A xsUT5YheymsqlqyajEO7j6LFtZMTV5ov4ZoyAymiX/dfik+qyo3XX75+mdfPgykoEBUBz90H1x3W DBQu3Y6lhRny2AcV8ow2ROTz5bAsZIRyBh1YjKdse7HO9elceh9/H6X50uXEfbfmgr4cpcoASz0c pfNLcdL7Pg9FMzznINddgAtlWF46XHERHQhNqQ4PnvwD6lo89yluh8H4HyjVZGL0XUUoWPJT6MZk IV07Ercrq521BMZf3gdN2m246777sGTBDIxJz4R2tFaZKqhl7x0zv3En7nElvj733MHqMt7EtU+J b6yZ3zHUJW2eb9xMLMr0x3Cf/ytM/4X5TatRWLAElvN+Z37/5Mq/nFdwqSkTQ24KdNDejJHjgUut 7neKevhD2Pj7JzHq2Brku6ymorLagtpuY42UBQRYDqFM197bZ8jj2VRQ5a/BsdE/xbZn7pOvfZ78 r2L7jNuhUt0A7Yy3PSvD8hpIJiwZp3Ym2cjK6BrRpiEjaxCamr8KkeYG3D5ag/Que6kzsnBLUzOu uNanQTPlZ5iPrbgjY4B8IZAO4FrY2zwnrC4Z9PpnMGX2mgE3UiB6Aq67n/IYBtEKq0EHg7XVe6el oaIAXd+NYa9cowV6vwtzgEfft4/HWGXA461EB1ovfYWcIb47xt5NOSMxtuYo/h5yRBfMOegLNMsX QG95XRacrZfQlDMEN3VZD9yMkWNP4+jfv+y2JVor3HfVPf3u/+rrc/kumufult/rQVQUyGdWv2PI Py/R4LkrIt1ol+7kd9ku/x2pMv09PQP5/zc2D3saVtt6lA2XH2v5J+z+l3owsoe14PKXga4JX+DM cSDbe92SAq9iPFxhksf0vI45I87A9MOVigCsA03NV3p/dBdSmQC8Y4guo/7F4Tjw5kcB6jtIHkPU Dod5evd29mMNA6J+4PW866UAJ5oOtDZfxbAsxUPYrhk4r6C5qeuZrx1nTzei63dmnK3N+HxYFgZ7 8nDdEdrnvQh0Otbi7ksm/PBXh+S7SJ6EXV77U2aXrPgnBVJG4NY7Menzv+Gk5w6JdMvedWGUTtLS oM9V7kcGQYGkISP7Rly4rBiIKu/nPH0MhyZPwDd6ieikc0FTt3Kudw66FXc/eDMs733S6wVNnZGN YRcuo1vY4/wUxw6NxIRvdA+VulWFK8IjID1CMj6J/PJa5CzYi5p1T6AgYIDdQ3HqUbin7Dxee/dc lz6XviDwBjY3TcI9eVJQfhG1lXNRbVcej5nIv+/fsWBuK043SXek0nDr3aW4zfIXNASKrzxVCLpM zw6e10zkl/0fVD/4VyxcW9PDQHJpMPYL8lOQDjS+uRO1nvejJ5sQXxkQhQgWXPLT2LFmrWLgmxTV /x7b6ifiyaJsOYsbkTXsAqwnP4MTctT/5COYs79rQARce+eXWLjhffmguIZG2w6smF+HsicL3c9v nadQPXU6Ki2nvIGT+lYtbhvQtbZhLLNr1vybAgkj0Aybcbr7a+aucTA9VLytDkbXwODp3nE83pTq fMxcPRSmNXu63IWVPvh84U0W3MIg5M+cjRzTJliUjyTaTmFP1VEUz5zgG6cxOAvDmo7jpGvsSAvs BzbgyeI52N+toOudgwZi+ENLsaThBaxQnDekcRu1bxihn7rBNd5RnV+G1TkWrFGmQQvse3bicPF0 FGXyEtKNPuwrrqGxbgv0+fPxrvTtsJp1iuEYoRQmHWflGLt5HlZ4v60m5f0S5t1fg2lry5Dv6s6v 0Nz0Ln6+5iX/r+O3ncDBA74gWD18Z57XZQAACIFJREFUOp5Z0og1KyyK90AL7LW7YNTPkt8zwZYZ qB3SMboY5Z8Z8cKhi4ESKNY14gPLzv7fsRT8F16Bdqsw5JYLc/1xYV42RQAQwDihM/xR1Ld2Ksrq FK31ZrGsWONOU7xMbLN+IF7X5QqgXJgdXwiroVgAuUJnPi7qzStEsSsvCI1uvdhff9mXV+dJUTVt tjD8ziB0Gqm8KJTpK51LFIgjgVZhNeiEwdraS52k99Y0AWhEseGI6DFl6xFhcL0/pwmD9YsA+XV5 D0vvO41OGMxW4fC81R1moZPft+73pef9Kb3H2/3y7HQcEdu854wA73NX6suKc4FGFC/bLqzW19xl 6MzCIaUJ+hwkhOh0CKtZed6YIpZV1fifq6Q025Z5zz+uNu6vl90kb+k8JbVLOledFe1Wg8gFRK7B KtoDtl95fit22TrM5a48XPv4qaT6H1+J+qpHhEb3ojji+Do8GK31Yr9BJzTycdnteiIuiJpls4XB bBYG3Ti5b6VjrUrUKK87rtp8LRzWINL1Wma78PS/8jjyNLazvkpMcR1PNeID77HmeR8pX6Vjqcd3 sye7Xl9V0lZFmMXF/gpIg/PGvILRf5ZH2fc3P+5PAQpQIBQBnoNC0WJaCngFeL/TS8EFClCAAhSg AAVSVYB3iMLZ865PZoVY+g9PpuUwO3inyKPBVwpQIMICPAdFGJjZJ7MAA6Jk7l22jQIUoAAFKECB oAT4yCwoJiaiAAUoQAEKUCCZBRgQJXPvsm0UoAAFKEABCgQlwIAoKCYmogAFKEABClAgmQUYECVz 77JtFKAABShAAQoEJcCAKCimyCZSThjom5QwMmVGs6zItIC5UiC5BaL5Ho1mWcnda8naOuXkuIrJ cCPS3GiWFbgBDIgCu0R9bZbBinYh4J0gUPr6bJ5i1mXXjMsdaLTM9c7irVLlQW85J9fV/TP+eq28 j1YP44F9qNYvgqXRNx2IZ3LCdqsBWVFvJQukAAWCEeD5IBglpomOwO3yZMm+yXCVgbRKpYL7g/w5 WPR5iuuTYoJj1zxseu9M9lr9BhyofQV6vQWN3kZ4JuKVJmi+3bs2mgsMiKKpHUpZ0uzLfzZD55n9 1zXjsjSZ3cuuCVw766swbdlvsLlsBABpbqafYM25+7DFIc/E7HgVc0c04fAB5QR9oVSAaSlAgbgR 4PkgbrqCFQHSChbhz65JjM+6rkfuD/IjUGZqgBBfob6qHMtqnnFPcCzNCThjPc5N3wyHawJkAYdp DkZ88iEOxBkmA6I46xC/6kgTOR49DYd0g8c1gasW2spatEiTwX7agDM5QyDNNe20W/D0yRlY+6Nx SPdmoEb6GD1MjpdDmHXbuzMXKECBeBPg+SDeeiSF66PG4KybcPT0/8B1ebJXY6qqEJW10iSsbfi0 /hJyhgwCcBX23VtxsnwFfjQmU+GViTGzq+AwlUGjWBvrRQZEse6B3sq/aQhycAmXv3TC2fAXWIbe h5KPP0GT04krzV9iwuh/Rho68NlHR9E+8U5o2Ju9aXIbBRJbgOeDxO6/pKq9GjcNyQYuXMaXuIqG 997HUN1ofPzJRTjxFZqbtBitlQKiC/jocAcmjrsViXB5SoQ6JtVhFFJj0v4Zoyd8ieYrX6LhvcO4 ZcYCzPlmHd5raIbj9BcYP/JmObs0DMsanBAHXEjtZ2IKUMAnwPOBz4JLMRdI047GhKZmXHF+gvd2 3YgZK+bgm5a/oOHa/+D0x7dhZE6aXMebkZXhWY55tXutAAOiXnlivfFmjBz/BU6fO4H3dnVg0rhc 3HZHK3a99xEuXbgR2QEPsq4Dr1VQ+Q1ci3WbWD4FKNA3AZ4P+ubGvSIikDMS4z8+jXOn/oJdmIBx eSNxR3sN3vtbIy4My0ZGwOii68Br5ReDIlLLkDINWOWQcmDiCAqkISMbOH7sKOpvmIx78rKQd89k 3PDxh7B9/M8YNWwggDTcOu5f8PmRv6PFVRPfwGshzsKsWwjzcw/E1XPaCIIxawoksQDPB0ncuYnX NPVgZN/SgGMf1uOGR7+HvLRRuOfRDHz8pzp8/M1RGOaKLnIwbtJVHDnZLLfPM/BaQDikLw09j+dc XwyKj+YzIIqPfuihFgMxbNRInN25Cx+XfQ95akCd9z2UfbQJK05lYshN7u5T55dhdY4Fayyn0KbM yXkFzU2+r9wrN3GZAhRINAGeDxKtx5K6vuqhGPWtT7FzRxPK7hkFNQYh754ifLT0Vzglf+EHGIT8 mbORY9oEi939kd1j4mxtRpPnjzh5ZUAUJx0RuBrSwLVMnDsEFN91m3uMkPo23HXfHcDE0dB6H8tm oaBiLeZgO+5X+X67SPvk28hauwoPabwJAxfDtRSgQAII8HyQAJ2UQlUchCE5V3Do3HjcNVoaQA2o R9+F+3JzMdH1hR+ZIr0IFVseA6oeUfxG0Xg8+VYW1j43Pa6eXvBKGeeHr/uHFCsUtZR/vEqxxr2Y ifyytTgo1nbbwhUUoEByCPB8kBz9mBytkK9FysuT9HtZDQ3dm5c+BmXr9kGs674pntbwDlGc9Ebz 0kLc4P3Fz8hVyvMLozcULoXnqW7kSmPOFKBAXwR4PuiLGveJjMBZLC3MgEoVrak7MlC49GxkmnKd XFVCCHGdNNxMAQpQgAIUoAAFklqAd4iSunvZOApQgAIUoAAFghFgQBSMEtNQgAIUoAAFKJDUAgyI krp72TgKUIACFKAABYIRYEAUjBLTUIACFKAABSiQ1AIMiJK6e9k4ClCAAhSgAAWCEWBAFIwS01CA AhSgAAUokNQCDIiSunvZOApQgAIUoAAFghFgQBSMEtNQgAIUoAAFKJDUAgyIkrp72TgKUIACFKAA BYIRYEAUjBLTUIACFKAABSiQ1AIMiJK6e9k4ClCAAhSgAAWCEfj/AbvKtQCuJ3z2AAAAAElFTkSu QmCCAA== --_005_1AE4350ADF5349AEA209A04CB488215Cericssoncom_ Content-Type: image/png; name="image002.png" Content-Description: image002.png Content-Disposition: inline; filename="image002.png"; size=14318; creation-date="Mon, 29 Oct 2018 10:32:55 GMT"; modification-date="Mon, 29 Oct 2018 10:32:55 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAk8AAAEjCAYAAAArGeXSAAAgAElEQVR4Ae3dD3RU9Z338c+ExNqS UJqVlcRG+0g2pa6uT515gD5ut0xQeayydYOrPbZmFE4LeyiiPBNTtdbaFinNPCrQHKE9UINdd0vN 1C26LSIJ9mx3KSfjPjx2FbKpKyoJXa1LIbYqMPc5N5k7mZlMkplk/tx7551zcmbmzu/+/rx+v3vn O/f+5l6PYRiG+EMAAQQQQAABBBDISKAso1QkQgABBBBAAAEEEBgSIHhiICCAAAIIIIAAAlkIEDxl gUVSBBBAAAEEEECA4IkxgAACCCCAAAIIZCFA8JQFFkkRQAABBBBAAAGCJ8YAAggggAACCCCQhQDB UxZYJEUAAQQQQAABBAieGAMIIIAAAggggEAWAgRPWWCRtMQFTkcU8oUUOV3iDjTfFgKnIyH5QhEx HG3RHVSixAQInkqsw2kuAggggAACCExNgOBpan6sjQACCCCAAAIlJkDwVGIdTnMRQAABBBBAYGoC BE9T82NtlwuY80rqPR55zP8Kn1oiLfJVxF57/ApFBocEktJZ6WOP9fF5KYOKhPzDeaWk8STkJXNu Vb1VRspj/cicq1yWmcu8ilH/YpRZeLPk8VPha1GkxacKaywljA2Xb5Y0D4GiC3gMwzCKXgsqgIAT BMygZkG3/PuD8pY7ocLU0c0CZvC2oNuv/UGvGI5u7mnaZkcBjjzZsVeoEwIIIIAAAgjYVoDgybZd Q8UQQAABBBBAwI4CBE927BXqhAACCCCAAAK2FWDOk227hoohgAACCCCAgB0FOPJkx16hTggggAAC CCBgWwGCJ9t2DRVDAAEEEEAAATsKEDzZsVeoEwIIIIAAAgjYVoDgybZdQ8UQQAABBBBAwI4CBE92 7BXqhAACCCCAAAK2FSB4sm3XUDEEEEAAAQQQsKMAwZMde4U6IYAAAggggIBtBQiebNs1VMx2Aua9 7XwjN+a1Xf2oUEkJmPe288VvOl1STaexCBRdIIvgybyjdyB+F/mi15wKTE2AQGBqflNem+1pyoQ2 yoBAxkadQVUQKIBAFsFTAWpDEQgggAACCCCAgM0FCJ5s3kFUDwEEEEAAAQTsJUDwZK/+oDYIIIAA AgggYHOB8YMnc15MvUcej/lfJV/LDrX4qmKvPaq3JismpbPSxx7rRybYmvMC6ofySknjSchL5lwQ f7yM4bKt9P6ROVdFKNNV9a/wqSXSIl9FGlubD1rHVi9pzNpre3L62FaSrTWmY4952Qcl76cqfC2K tPhUYe3fEsp07Hil4gggMKaAxzAMY8x3k94wdxar1O1vV9BbmfQOLxwoYH7YLOiWf39Q3nIH1r8Y Vc6pGdtTMbowX2WaweeCbr/2B70q1OZUjDLz5Ue+CDhNYPwjT05rDfVFAAEEEEAAAQTyLEDwlGdg skcAAQQQQAABdwkQPLmrP2kNAggggAACCORZIIs5T3muCdkjYHeBnM55sntjqZ/dBZjzZPceon5u FuDIk5t7l7blXqCuWlVsNbl3JcdJCExTXfV0MRwnQccqCExRgCNPUwRkdQQQQAABBBAoLQG+tJRW f9NaBBBAAAEEEJiiAMHTFAFZHQEEEEAAAQRKS4DgqbT6m9YigAACCCCAwBQFCJ6mCMjqCCCAAAII IFBaAgRPpdXftBYBBBBAAAEEpiiQRfBk3osrMHJj3ikWzOpFFjCvWeQbuWlzkWvjjOJzasb25IxO z6yW5jWXfNaN0jNbZcqpilHmlCtNBgi4RCCL4MklLU7bjNMaCK+Ux7ojuqdW/tABDaZLO3hI4dbF sbS18rdu1/bWzxFUprNimYsEUreRegXC/5G83QTCGpBkfqjXx7clT2xbuUSB0G71DkaTTKIDEYVD AdUOpTe3p8cUiTyuQCyvpMS8QAABBGwiQPA01BHlqmnaIsN4V6933qkVP/qubtr3lA6cSN7RK3pE 4TVfVc/i7TpjGDKMQ9o6v0+PfbvfJt1JNRDIl0BsG+nvVHNzp/qNPnU0/TfVXPUlbWteqOZtL+hk R5NqJJV7g+qLpzO3E/P/oNr9L2r1mid11NqsBg9o48Mv6qKV31f/UJp+7b39Qv1803rtyFczyBcB BBDIgQDBUyJi9GXt3v4+3XBVoz7V9J/a3fNW4rtS9E29fHCelv7FebGr+s5QQ9Na3XvnrOR0vEKg BASiA3t099KH9LtVj+v7yy5W5bhtLlOl92+0+fJntGnfm5LeUe/O7Tq2+GrNrRzZDZXVXK4199yh q8bNizcRQACB4gqM7LWKWw9blB7t+2eF/3ShfDM+oIbrb9C0nT8f+ZZs1rDsHF146dPa9HDi6Ydz 1Lhhp4Le8T86bNFAKoFATgTeUf+Bdt3q3ajqB/6P7phXk+EtQs7WhZfWa+/zR3Rab+hXz52t+R+b OapGZQ3LtDt2FGvUmyxAAAEEbCBA8BTvhOP6158cVtPy/6kZ5rIZf6YrPviMdve9E0+hsgvUtHGr Ah95Qesapsljzo1q/Z7CXb3p50eNrMkzBNwjsONzWtL+By35zk3Spi/q7q6jss7EuaeRtAQBBBAY W4DgybI58bx2PvhtLf/o+2MTXGdp0bd/oh/+0yvJHwyVDWq8PqiOfnMex+vatfx8vdyxQmvCR5LT WfnyiIDbBBY+qF3ta3V9000KtgdVvaFNTx59bxKt/C8dP3l6EuuxCgIIIFBcAYKnIf+oTvTs0799 86XYRPDYJNczXbox/Lj2DU0cj+pE11d17fZDCUFSmSobFuv2267RwZffTFhe3E6ldATyKnD+Baq1 5ilV+vTF1hnavvvlDMb/O3r5YJ8WXXaBynWu5n/mQwqnfjnJa8XJHAEEEMiNAMGT6Rh9Tc/ufFfL Fl+YPHej7CP68/jE8ajePv6fevor6/XgnsTTdMd1sPuF2AdCbjqFXBBwjkCZZsy7Vgt/aH3JGKvm 72ngwDZtOHCVblt4jqSzdN51LVrb97DuCh8aOe092KuuJ0IKLH5IkZTLGoyVM8sRQACBQgsQPJkX Pmz4iJZu/baWfvh9qrcudGcur3+/Prp8q769aJbqQ8/rfTP/WNesXaJLDq5Tg3UdG/96HbzsHt3b aH4g8IeAWwVi13mqXaodO5aq1mNe5+m14cZW/pn+8sZDWvTBhqFlQ9d5iqezrvPk1Zd/Xq/W0HU6 z9rrlJ2nxm/epxv0lFbVxtJVrdbuE5fpns418lpHt9xKSrsQQMCxAuWOrXmuKl7uVbDPUDA1v7TL 5+mpRjPh9eoPdqSuwWsEXCxgXQttS5o2nq2GZTtlLLPeCqrPGLVFWW8mP5bVyNsUVIf5n/wOrxBA AAHbCljfATOs4IdUXUW8lSGW/ZPVVasqyxFg/0bluYY5NWN7ynNvFTD7aaqrnp582j/vpRejzLw3 igIQcISAxzAv/8sfAggggAACCCCAQEYCHHfIiIlECCCAAAIIIIDAsADBEyMBAQQQQAABBBDIQoDg KQsskiKAAAIIIIAAAgRPjAEEEEAAAQQQQCALAYKnLLBIigACCCCAAAIIZBE8DSoSCigUGUTNDQLm RUB9IUW4tViRepPtqUjweSnWvDCoz7rAbl5KGJ1pMcocXQuWIFCaAlkET6UJRKtzJ+Denf3w1bdr A+06MDCZG+TmzpicEEAAAQTyL0DwlH9jSnC9gHn17U2KrJLavUvU2nFAA1HXN5oGIoAAAiUrQPBU sl1Pw3MrcJZq5q1SR+9mXfFGu7yLWtURGRAxVG6VyQ0BBBCwgwDBkx16gTq4R6CyQVcGv6/erY16 Y9MSLWp9TBFO5bmnf2kJAgggIBX4VkyQl5iAOSnaL4/HM/Rf4WtRpMWnithrT701YT05nZV++NE/ 8iMFc5J7/XBeyWk8GslLMudW1VtlpDzWxyf15rbM5I4tU2XDYgU7fqzVx+6Xz7tW4aPMhUo24hUC CCDgXAHu8uvcvnNAzSvlDXbLCA5X1QxqFnT7tT/oVfLAS043ZsPKvQr2GYplN06yoPqsQsdMldsy k4uJarB3j7asu0dPz75PPZEb5a05KzkJrxBAAAEEHCuQ/Bnm2GZQcQRsIjDYqz1b1inw9GytD+3S Xm8Nh3dt0jVUAwEEEMiVAMFTriTJp8QF3tPAge/py9f9RLPXf0ORvfNUw4zCEh8TNB8BBNwqQPDk 1p6lXQUUeEe925u18LlP6cnILs3jFF0B7SkKAQQQKLwAwVPhzUu2xHJvUD1eNzb/bDUs26n+ZW5s G21CAAEEEEgVyPLEwodUXUW8lYro2Nd11arKcgQ4tq22rDjbky27ZVKVmqa66ukFnt9WjDInhcNK CLhOwGMYhuG6VtEgBBBAAAEEEEAgTwIcd8gTLNkigAACCCCAgDsFCJ7c2a+0CgEEEEAAAQTyJEDw lCdYskUAAQQQQAABdwoQPLmzX2kVAggggAACCORJgOApT7BkiwACCCCAAALuFCB4cme/0ioEEEAA AQQQyJMAwVOeYMl2tIB5Y2BfKKLTo99yxpLTEYV8IUUc2wBnMFPLzAQcvz1l1kxSIWBLgSyCp0FF QgGFIoO2bAiVylKAQCBLsFwnZ3vKtWgx8yOQKaY+ZSNQeIEsgqfCV44SEUAAAQQQQAABuwkQPNmt R6gPAggggAACCNhagODJ1t1D5RBAAAEEEEDAbgLjB0/mvJh6jzwe879KvpYdavFVxV57VG9N/k1K Z6WPPdaPTLA15wXUD+WVksaTkJfMuSD+eBnDZVvp/SNzropQpqvqX+FTS6RFvoo0tnYbpW6pT9KY tdf25PSxrSRba0zHHvOyD0reT1X4WhRp8anC2r8llOmW4Us7EEBgRCCLGwObO4tV6va3K+itHMmB Z84UMD9sFnTLvz8ob3lhmmB+QC/o9mt/0KsCFZnbhuXUjO0pt51T3NyKMbaLUWZxlSkdAfsIjH/k yT71pCYIIIAAAggggIAtBAiebNENVAIBBBBAAAEEnCJA8OSUnqKeCCCAAAIIIGALgSymnlTKG+yQ 1xbVphJTFij3KthDb07ZcdIZsD1Nms6GK5Z7g2JzsmHHUCUE8iTAkac8wZJtOoFpqqueLkcPurpq VTm6Aen6hWXOFHDB9uRMeGqNgLL4tR1aCCCAAAIIIIAAAnyHZgwggAACCCCAAAJZCBA8ZYFFUgQQ QAABBBBAgOCJMYAAAggggAACCGQhQPCUBRZJEUAAAQQQQAABgqdRYyCqwd6D6h2MjnqHBQgggAAC CCCAAMFTyhiIHn1SaxZerRVbejSY8h4vpyZg3ovLZ91MempZFWdt8952vpEbXRenEpSKwLCA47cn OhIBBwsQPCV2XvSInvzqZmnTD7TqpVatCR8Rx58SgXiOAAIIIIAAAllcYdztWMcVefB2bf7YBu26 fp4+cPkZPX/Lej160be1bO4Mtzee9iGAAAIIIIBAhgIceYpBRXvDuu+F6/TISp8qJZXVLNLdD3xU j615Qr0cfspwOJEMAQQQQAAB9wtw5CnWx2UNy/RUR2KHl6nSe4e6dycu4zkCCCCAAAIIlLoAR55K fQTQfgQQQAABBBDISoDgKSsuEiOAAAIIIIBAqQsQPJX6CKD9CCCAAAIIIJCVAMFTVlwkRgABBBBA AIFSFyB4KvURQPsRQAABBBBAICsBgqesuEiMAAIIIIAAAqUuQPBU6iOgoO2fprrq6XL0oKurVpWj G1DQDqewvAq4YHvKqw+ZI5A/AY9hGEb+sidnBBBAAAEEEEDAXQJ8h3ZXf9IaBBBAAAEEEMizAMFT noHJHgEEEEAAAQTcJUDw5K7+pDUIIIAAAgggkGcBgqc8A5M9AggggAACCLhLgODJXf1JaxBAAAEE EEAgzwIET6OABxUJBRSKDI56hwVTEzgdCckXiuj01LIp3tqnIwr5Qoo4tgHFo6Pk3As4fnvKPQk5 IlAwAYKnglFTEAKlIPCawoF6eTyelP/Fau04oIFoisHgIYVbF8fS1srful3bWz/Hl5cUJl4igIC9 BAie7NUf1AYBhwvUqanj/6qn7Ro1d74q8zJy5v+Z/m/oohe/rlsePaR4/BQ9ovCar6pn8XadGUp3 SFvn9+mxb/c73IDqI4CA2wUIntzew7QPARsIlNXM083Lm6TnXtRvrPpE39TLB+dp6V+cF7vq/Aw1 NK3VvXfOslLwiAACCNhSgODJlt1CpRBwk0BUg7279eC6n8kbmK9zraaVnaMLL31amx7erd5B63jU OWrcsFNBb6WVikcEEEDAdgIET7brEiqEgBsE3taOpefH5jJNU8O6F3ThbRv1zUbrKJOksgvUtHGr Ah95QesapsnjMec8fU/hrl7xcw03jAHagIB7BQie3Nu3tAyBIgpMH5nzdPIlfWf2Af3Dwd/q96k1 qmxQ4/VBdfSbc6Ne167l5+vljhVaEz4yMjcqdR1eI4AAAkUWIHgqcgdQPAKuF6icq6b1bfrML76u B7qOxoKiqE50fVXXbk+YQK4yVTYs1u23XaODL79J8OT6gUEDEXCuAMGTc/uOmiPgHIGyC3Td1z+r 33yxXftOmPObonr7+H/q6a+s14N7Ek/THdfB7he06LILVO6c1lFTBBAoMQGCpxLrcJqLQH4FzOs8 /Xf5Wp6OzXlaqfDA8FVFy877tFrv7tOiDy5SKPJ7TZ/5x7pm7RJdcnCdGqzrQvnX6+Bl9+jexnPy W01yRwABBKYgwJe7KeCxKgIIpAqY13nqk9GRutx8fbYalu2Uscx67+t6qtF8fr36g2lXsBLyiAAC CNhKgCNPabvjQ6quIq5MSzOlhdNUVz09dk2fKWVUvJXrqlXFVlM8f0pOEHDB9pTQGp4i4CQBj2Fe /pc/BBBAAAEEEEAAgYwE+A6dEROJEEAAAQQQQACBYQGCJ0YCAggggAACCCCQhQDBUxZYJEUAAQQQ QAABBAieGAMIIIAAAggggEAWAgRPWWCRFAEEEEAAAQQQIHhiDBRM4HQkJF8oouFLJhas2NwVdDqi kC+kiGMbkDsKciq+gOO3p+ITUgMEJi1A8DRpOlZEAAEEELCFAF9sbNENuaqEE74YEDzlqrfJBwEE EEAAAQRKQoDgSYOKhPzyWPfWqjdPy5zWQHjlyDKPX6HIYEkMCBqJAAIIIIAAAuMLcA8SVcob3KuT /o1auvNS/WhDo2aYZk1bdOb1q/SFFcfV+pNlaiDMHH8k8S4CCCCAAAIlIkBIMNTRZar8eJNWvPm3 eqL3nVjXv6O+3c/onLV/SeBUIhsDzUQAAecImPNi6q0zBhU+tURa5KvwxM4YjJwtSEpnpY891sd/ wJJyBiIp3UheMudW1VtlpDwOnbUY9nN6mYWvf7J/ha9FkRafKqx+SLC1ywjl3nbxnojqRNfX9NfP X6vO4DxVnuhS618f1A2da+StJMaMM03hiblBLuj2a3/QK0ce8jR3nAu65d8flNeRDZhC57Gq7QQc vz3lUpRtM5eaRc/LCWObqCA+TMo0Y+FNunHf43rm6An1PvG3enNFkz5O4BQX4gkCCCCAAAIIyJkH APLWcWUNun7tDN30d4/rz/ecp8/9qE5El3nTJmMEEEAAAQQcKUBskNRtZZox71otfDqk7htv0sIZ 8CTx8AIBBBBAAAEEOPI0agxUzlOwu0/BUW+wAAEEEEDAlgLlXgV7vLasGpXKXqDcG5Tdu5NDK9n3 K2tMWmCa6qqnO/tUaF21qthqJj0CWDGXAi7YnnLJQV4IFFCAX9sVEJuiEEAAAQQQQMD5AnyHdn4f 0gIEEEAAAQQQKKAAwVMBsSkKAQQQQAABBJwvQPDk/D6kBQgggAACCCBQQAGCpwJiUxQCCCCAAAII OF+A4Mn5fUgLEEAAAQQQQKCAAgRPBcQu9aLM+xX54jfidKCGef8sX0iR0w6sO1V2nYDjt6dc9gjb Zi41ySsDgSyCJ/OuxwGFIoMZZEsS2wuwsylyF7E9FbkDilA8fV4E9KQiCTiTOBz+orjbUxbBk8Od qT4CCCCAAAIIIJADAYKnHCCSBQIIIIAAAgiUjgDBU+n0NS1FAAEEEEAAgVwIGOP9neox2ubIkNL/ z2nrMU6Z64+Xbk6b0TOUyEzWZsyZKC/jpNHTtnCMMhcabT0nh2tchDLdXH8pwXa8MTGF90w/rzVm ppBP0VY1x5x3ZDxnXY/xxqxkFHN7cvrYLsY+KCOzTPs868E0vD919PY0iTaPucqY2+Z4nycyFP98 Gi9dwr5xvP6M58VnXdLnSS7NxssrcR865kDJ3RtZ3NvOnJy1St3+dgW9lbmI28ijmALmhPEF3fLv D8pbXpiKmJM1F3T7tT/oVYGKzG3DcmrG9pTbznFCbrntc8dvT7nssgy3TcxyiV7svHK7PWXbGk7b ZStGegQQQAABBBAoaQGCp5LufhqPAAIIIIAAAtkKEDxlK0Z6BBBAAAEEEChpgSymnlTKG+yQt6S5 XNT4cq+CPfRm8XqU7al49sUqmT4vlrxVbrk3KHZ7lobTH4u7PXHkyenjx1H1n6a66uly9KCrq1aV oxvgqAFDZccVcMH2NG77snyTbTNLMJJPRSCLX9tNpRjWRQABBBBAAAEE3CHAd2h39COtQAABBBBA AIECCRA8FQiaYhBAAAEEEEDAHQIET+7oR1qBAAIIIIAAAgUSIHgqEDTFIIAAAggggIA7BAieUvvR vMx/vV+hyGDqO7xGwNkCjG1n9x+1RwAB2whkETyZ95EJODCoMOvtl8fjGfqvD0V02jb8RayI+UHq CykCRuadkFMzp25PmXMVLqW1jdcrEH6tcMVmXVJu+9y8T5uP/dlwL2S4bWKW9aBlhTEEsgiexsih mIujA4qEQwrUDgdGHn+rOiL79UTgdoUHrKjAvJBWtwzD0KmeNs2cqL7mxSP7ugt08+Pc7kwnatrk 349qsHe3QgGfFm8/pOgkM2LHNUm4tKtZAUNs7Me+HHhqAwrt6VXa46YFHdtpKz16YYYfeqNXTFxi buN71N95beJCniMwSQGn7Jcn2bxSWy0n+5jRaA4Ono4rsvG7OnjRF9XRbwwFR8be2/Wxnz+i23a8 M7qlLJmcwGCv9oRuVcOKLs26bZd+umyusy9yOTkFG65lBQxr1Nz56vD4NwwZ/RvlP3i/1oSPTDrI tWFjqRICCCBgKwHHBk/R3rDuO/ZJXT93xghoWY3mrblL37wqi7vOWGub0Wm99S1+rDlP72ngQPvI kS5Prfyt29XVe8LKRRoIK2AeBQg8od5DHfG0tYF2HRh4L57OPApT76mSr2WHWnxV8dOKHs9YZcdX LdCT9zQQeUytS9bq2VmrFNm7QQFvDYFTgfQnX8xMedfeq8u3b9O+E7FjhBmNbSk6cEAdrYtjY9Ec 2+vU6v9S7CiudaSrXoEn9uvAQwHVxo521QZCCkcGEoI1c+w8pe1JeX1P/5CUJpZfhU8tkRb5Kqxt zyNPferpZOvI5yUJddui7a3LR08jOP6CwvFyF6u144AGkg6VZrAN67QGwitjZa1U+OhrinS0yj/U 3sW6u+toQlsn31OsiQACzhVwaPB0Wr/51f/TH83/EyWETsO9UDZXy3Z/R001WQZQQ6c0zCNYJ9XT dn6aHo1qMNKuW9qlVZF3Y9/0X9eu5efp+Q3rFD4aC4xqmtTR36nmvnatWPOKAkNpf6euTz2vmx7+ J1lhlnmPpb6hsprV1nNy5MiBUahThmmaGFs0/CG6RN5Nb+qKrY9rQ2Ceahw6UsZupYvfKfuwLl14 RM//+++HGznh2DaTval9D2/Ui/M36qR5BMswx/bHEpDMI1271NM2R33tj+jJ6lWKnBk+4tvffq20 c50ejByPpT9L59Z+RB+/fdfIdnLrWQrfuHkkoFPsdPqpHrV529RzKnb02Cy7LyhvwuYbPfqk1qx+ Thfe84tYfv3ae/sl+t2xtxLqZz59RzuWb9QvY2040/9Vze66Vw/vezOWLsNtWOWqadoiw3hVnc2H tfnzn1bwxYsV6n9XxsnNukJvKyabUj4vEUCgVAT4SMy4p9/SgZ2HdeM9yzWv5qzYWmWqbFista0X 6ZndLyd/G/2PP9Xq7XepcSjtDM29+hpdfuy43s64vOIkjPZu19W183XLsRWKdNyhKxtGhaexillH IhKOGFjzbuJHz5LTVPhaFGnxqcJKN+oIQ3HaTKmmwB90/FhiSGCO7SZt6B79RaTy5rv0zcSAunKu rlt+mfbtfD7+5aCs5mJ9PHE7mduoz1z+ex1/O+kwUAb0g/rXv/t7ndO6Vk0JY7Gs5nLd0fHjlLmJ 5bpq20atb5qrSkllNfP12c98TMeO/yFWTpbb8NBaM/WJe3+mvRtultdsT2WDGhsbhvLPoPIkcYpA 0tHZ0WcE4j80SkqXsu9L2J8Nn1lIeT+234vnpeT9o/WjpuHHhDMQRSjTVfUfdXQ7wXYK49PBwdNp HTv+dnLAMgWIiVc1P1ye1fKPvj/hFNvwxjHto7do63Mv6jeJmVzZqE+cZwVZiW/Y+3lZwzL9tP+X enT2VnkDD2lP4inJpKrHjhwMHaVIOGow9No6epacxpyw723r0SlrnZQjDEnZ86LAAufpqntuljY3 qsoKbv2t2t6VOvm8QrNnjr65c1nVTP1R/MuBedourFDAOs1mbifna+mk5iL+l468UKv5H5vwpx6S ytPWbQQyy214aMUL5PvYuZyuHkF057P40VlzX2aefUg+I9AX9GroYGhSupT9XsL+bPjMQsr7sf1e PC/r6Ku1P0x6tPah5rA2f8SUPq/Eo7S5LDOXeRW9/qOObifYTmE0OzR4Kte58xv14fA/qy/bL7KT xpqliz91k7Yd/kPCKbaEAd3RpJpJ522vFctq5imwYZcit52jZ1c0KvDQL1LmjdirvtQmRSD6ug7u u0CX/ckHUt4Y76V1pKk/Nr7fVX9ovt7qWK1vdFmnvcz1T6X90hI9eVy/nT1T0yVFe3+gL2w6okvj p9nM7cQ8BXb2eBUY4733a+bsPv3yJeuU4FFTx0UAABeoSURBVBjJMlpcOttwRhwkQgCBSQs4NHiS ys67Vt9cO6B1d4XVO2hFUCfU2/VDhQKfUyg+/2LSNikrnq36qz+pV7Y9kjI59oR6w3drcWtX/JRF yooTvDyhFw6+MvzT8vilF1YmXGphgtXz9vZZqvHerA27Htfnz3xX3kXmZSASJwXnrWAynopAdEAH Nn5HB5Yt18IZmW/e5unaxf67FY4faTTnLZ2raWnqMvjYen0lcSL24CE9+egrarrVNzQHMXryLR0p v0AX1cdO+Q72quuJH+of9ozxK9h3X9LBvuHZgNGBiMKhgGoDYQ0MlX2OFt62TG9ueDChbuYE8n16 IrRc12Z16Yx8bcNpkFiEAALuFjAy/jtp9LQ1G209JzNeI/8J3zX6ezqNtuaLDUmGVGMsvHObsffw 7+JFn+ppM+YMvWe+n/w/p63HODWU0mzbwlHvD6dfmNTmM/09Rmdbs1Fj5VXTbLR19hj9Z2JF9nca zdZ7c9qMnlOGkVSH2DKrgmf6/8l4cJz6W+ly/niqx2jzDtdv4rzPGCcP/8xoa77KuHPvGxMnHyOF 6eCNm4+RyM6LszKbqCFT3Z7GGLPmeHzmsDGylY6RbmiMjoztM4e3Gdc0txl/nzq2R+V1jdHc+YJx uPMuY2FsnNc0P2g8k7DNGWf6jV8+mLCNLLzT2Lb3Z8a25jmGNFLmsNC7Rv8vv2M011jb5lXGndv2 GodPWhuUmcoaf9Z2LqOmuc340V6rnYltnGM0d75qGEbiMhkj27phTLgNG68anUN1tepkPVp5T9S3 Y71v1il3+1DHb09jMU1meYbbZmZmue2nyTSHdXIokOHYyLZEj7lCZuGhObltlbr97SmTNDNbm1Q2 EzAnIS7oln9/8i+bbFZLe1Unp2ZO3J7MOn9Wmy58RB1NdfbqG0fUJrd9bk7qXdDt135rPo4jDPJU yQy3Tczy5F+C2WZ+XH8I50Oqrkr4DXEJgrmqyXXVqspyBLiq/ZNpTE7N2J4m0wXOXieXfT5NddWj J+8722cKtc9o28RsCsKsmiCQxZGnhLV4igACJSZgHjVZIl/Lvli756i5s5sjUCU2CmguAggMCxA8 MRIQQAABBBBAAIEsBDhpkwUWSRFAAAEEEEAAAYInxgACCCCAAAIIIJCFAMFTFlgkRQABBBBAAAEE CJ4YAwgggAACCCCAQBYCBE9ZYJEUAQQQQAABBBDIIngyf6ocUCgyiJobBMyLyvlCipx2Q2Oc2Aa2 Jyf22tTqTJ9PzW/qa5sXyfSFIhp/t0c/TV3aRjnk6bMui+DJRhhUpcAC5r3EdisU8GlxVvcSK3A1 i1bcaQ2EV6o20K4DA+8VrRYU7DaBE+rd85ACtTdoe+8Y9wV0W5Ozas9rCgcuL5Ebl1tjwSOPxyNP bUChPbu1PXC7De6DmlWnuSYxwZNrujJPDRns1Z7QrWpY0aVZt+3ST5fNFYMm1bpcNU2bFFkltXuX qDXxprmpSXmNwIQC1peVRq149hzdFvmBljWcPeFapZegTk3ff0Kr5PYblx9XJPQ3WvfalWrvN2Te Uc3o/75W1h3Tc2PdbLv0BkPBW8znYMHJnVLgexqIPKbWJWv17KxViuzdoIC3hsBpzO47SzXzVqmj d7OueKNd3kWt6ogMKDpmet5AII1AdECRjru0JPZlZe+Gm+WtOStNQhYNCZTVaN4d31fv1ka9sWmJ FrU+pojLjv5Ge8O676WleuCWi1UZ7/YyVc4NqKN/i5pqYrdMGwgrYB6V8tQrEP718P7bXyuPp1b+ u/doIL4ziu3bh94z01+iQGi3egdjCczTXPXm8pXxo1rm6c76obytZeapTf9wWU/s14GHAqodet+j 2kBI4RLY9xE8xQcjTyyB6MABdbQukXfTm7pi6+PaEJinGkaKxTP+Y2WDrgy6e2c+PgDvTk4g9oG2 aIk2vdGorbvW82UlY8gyVTYsVrCjS1uveFObXHX097R+86vnderyiybeB9c0qcM4pf7O/6W+zc3y Bn+li0IRnTEOaesVZ+vk783gKKrByBZ9uXO2bt/bP3wUy3hB3/9cmR5d9R1FzACq3Ktg36vqbB45 2lnuDarPSFxWKW9wl3ra5qiv/RE9Wb1KkTPDR8X626+Vdq7Tg5HjGfegExPykejEXstjnaO923V1 7XzdcmyFIh136MqGGWOUZn3ziJ2Dj33rGDof7/HHf1gw8o1ldLr6+MTNzPJS/BvR6Lw89SOT34tR ZjKStTP/sVYfu18+71qFjzIXKtmIVyMC76h3++dV67tfx1b/WB3BxWqoTL9rLsbYLnyZGe4PRgBj z2ao4co71BFZoWO3zJf3C2EdjR9tGZXYQQvKNXtmdjeAPusTX0s4WzBDDY2fHB5T0V7tvO9NBb68 KCkYK6vxa/Vnjmrngbeydqm8+S59M/ELduVcXbf8Mu3b+bxOZJ2bc1aIHe9zToWpaX4FyhqW6af9 F+uxh++VN3BEHfcsHyOAMr95dMsIjl+f4W8sEyRSZnkNfyMyNFFuxSgzWcGcs7JHW9bdo6dn36ee yI2cekkG4lWSwNlqWPYD9V/6Qz0c/CsFXl6ne1ZemTaAKsbYLnyZGe4PkgzNF+ak6m1aF/iZZj/6 S0VuduMRc/PHKV9S7dKtI61v7lR/R5Nq4kvKdb5vblJwFH8r+rbeOjZDl34gNTgv16wLZmlv9xGd bjxHmQcGFWkDu7KqmfqjY8f1tqSxvn7H6+TQJ6mCDm0G1c6lQFnNPAU27FLktnP07IrGEvk1S44E UybYM2clR66uz+Ys1Xhv1oa9u3TbrC6taLhVDx1gzlxm3Z46wX6Xi6YalOvci/9Mv/3lv8eO4pg/ TtkSO91mnkZbo85v/WVC4DSBWNl0Vc8+od8NncJLTPuOXj7Yp0WXXTB24BR9W8ePpV7k4ZSOHX97 1NzO6Mnj+u3smZqeWITLnhM8uaxDc9ec2M581+P6/Bm3/5olF2rvaeBAuwINq5lgnwvOUs2jrEbe wHrt2neTzrS7cwJ0Trs2OqADD438GtiNX1bKGpp0/6yw1oUPKekqi2mDmQl0yxp0w/3nqGPdkyMT xM15UL3/qG3PXaQb5lXHMni/Zs5+Qz0v/UbRofd3K3TrX2v5M6nBkzT42Hp9JfEXxoOH9OSjr6jp Vp9rjzqZSARPE4y1kn87aQL0Lbqr682SJxkNMDxnxdsurYq46Vvv6JaypBAC1py52AToT35NXSdc MXknt3jRQ9p+9RK164sJ83tyW4Q9cpspb/ABLdcOLUmYW1p761Oa+cA9um7o13bD15rzeCpUu3Sj diw9f/h6UGb6QFgD8YaUqdK7Ut+64W1tW/LhWJpLteon07W8/UvyxufaVWve8qU6843/oWmeaaoa +vXn9/Sj5me1tPZL8V/hSRWqX92iW6qe1E3Thuei1q76qapuCWrZXLeesBvGzPzUZhyfJ6UnYO3M F5de0zNqsTlnZaf6l2WUmEQIZCgQmwDdl2HyUktWNlfLdveoNDa7GWpoekDdxgNj9LJ1Om/LGO8n Lo6dVei+WRsSFyc9N/f5TdrQ3ZScpqNPRkdSQkkfnKBuqend8TrLI08fUnUV8ZY7ul5SXbWqshwB rmm7LRrC9mSLbihoJejzgnKPKmya6qoz+eUa/TSKzskL8vBZ5zHMy5XyhwACCCCAAAIIZCRgXk5i iXwt+2Kp56i5s1sdTXUZre2GRARPbuhF2oAAAggggAACBRPgpE3BqCkIAQQQQAABBNwgQPDkhl6k DQgggAACCCBQMAGCp4JRUxACCCCAAAIIuEGA4MkNvUgbEEAAAQQQQKBgAgRPBaOmIMcLmDcm9o3c gNjx7aEBjhYwb9jri99c29FNsVnlzV+SBeI3N7dZ5SZfnfiN1VcmXORy8tk5Zs087bezCJ5cOqAc MwJyXNE8Dagc19LF2bE9ubhzx2gafT4GTMEWl3TAWe5V8FCP2uYUjNvVBWURPLnagcYhgAACCCCA AAIZCRA8ZcREIgQQQAABBHIkYJ1Cqw3oW98KqNZziQLbI+rtul9+8350/vvVNfBevLDowC/0UOCS kfvV+Vu1vat3+EbBWeY1lOnJQwq3Lo7ld4kCod0JNwo2U8RudF47fL86j6dW/tbt6uo9Ea+TZN1P z0yzUuGjrynS0Tpcf89i3d11VPE7MkYHEt4z2/e/FWr9KwXCryXk56ynBE/O6i9qiwACCCDgdAHr FNoH9mj3ic8rcupH+tQPl2hhx0f0yMnfqueaf1PHv/xmuJWDB/TgLdulVc/ojGHIvCmIsWu56p7f pGD4iKLZ5DWUY482r/6Ojix9NJbfL3TPpS9q3dKNigya4U5Ug5F23TJ0o/N3h8szXteu5efp+Q3r FD5qBXXW/fReVWfzYW3+/KcVfPFihfrflXFys67Q2/r9UHlRndj3iO5+cb62njwTq/8XdKHT+9C8 PcuYf6d6jLY5Mm/fkvZ/TluPccpcebx0c9qMnqFEZrI2Y85EeRknjZ62hWnLkxYabT0nh6tbhDLd XP8k2zEHRIm/YY4578h4zlpjvDErGcXcnpw+touxD8rILNM+z3owDe9PvdY+eBLrl8Yq432eyFDC 59OIh7lO88hnzcgbuX2WtD9JLPOU0d+5xmjufNUwjDPG7/bea1yz7SXjTGrpZ14ytq141DhsvpFR XtZn9TVGW89/peT2B+PwthXGnXvfMAzjDWPvnSuMbYf/kJLGMM4cftRYMaourxqdzdcZd+19fXQd h3Iw27PKWHhnp3H45KhWjCoj5wuSbHKXuxkFZviX2LkZrkIy+wrkaUDZt8E5qFlOzdiectAjDssi t31uBm8ET9kNgczMcttPY9YwaX+SWGZi8GQ+XzHGwQTzoMYKo7P/VJbBU2ydpIollmkGQ3PGLrO5 0+hPWtdMv2a4HknLE16cfMnovPOqhDyvMu7ctrcwwVSSc0KdpviU03ZOP3RI/RFAAAEEXCpQrnMv /oRWbHtp5JSddepu6HGLmmrKs2z763q5fzBlndM6efwdzZ75fkmzdPGnbtK2w3+InbKLnSq0yu1o Uk3K2hO+rJyrpg274/md6X9A89/q0Ke/sU+Js6gmzMdGCQiebNQZVAUBBBBAAIFEgbL6K3TDKzv0 YDiigZEZ2BrsDat18VfVdSK+MHG1cZ4f09N3f1kPHRgYntA9NJn7Pq1+7hO6dV61pLNVf/Un9cq2 RxSOxNIM5XZCveG7tbi1K7uAJ3pI2xdfq9bwoeEJ7pLKzq3Vh6eNU0UHvEXw5IBOoooIIIAAAi4S MH8hN9enlkiLfBXWRStfVYtvSezinO9ox9LzVW9eBLXsPDV+bbX86taXP2z9+u1SrfqJdMOjX1Hj B/41s7zWhbTOLPPXPq3e/CVd0HmLppm/7Jt2lTa90ajN7TdrbuVwSFBWc6W+dvtfSN1f1ofNNOZ/ 7Wr9REv16PpGzRjqitcUDtTL4zlfS3ds1NLaitiv9+pH/4qu4lzNOvWUVlm/3pt2ldrP3KR/vHdh LC/n9a3HPO3nvGpTYwSKIGDu8BZ0y78/KG+2R8qLUF2KdLeAecHHBd1+7Q96xXDMZV+bFzNdpW5/ u4LeylxmTF7FEMjTfpsjT8XoTMp0rkBdtarYapzbf66q+TTVVU8XwzEfnfohVVcRkuZDtih55mG/ zZGnovQkhSKAAAIIIICAUwX40uLUnqPeCCCAAAIIIFAUAYKnorBTKAIIIIAAAgg4VYDgyak9R70R QAABBBBAoCgCBE9FYadQBBBAAAEEEHCqAMGTk3pu8NeKJN3V2kmVp64IIIAAAo4T4HMnbZcRPKVl seHC6BGF11wn34ptsTtf27CObq+Seb0QX0iR025vKO1zgoB5nSefeRFFJ1SWOjpTgM+dMfuN4GlM Gju98Z6OPtmmO3WX/mXVr3Xjmid1NNsr8tupOdQFAQQQsK2AeZHMQOxK37atZAEq5pLPnTx96SV4 KsAQnFoRUQ1G2vX5zXP0w42f1YKmu/Tdc/9edz/6q/h9gqaWP2sjgAACCCCQKMDnTqJGuucET+lU 7LQs2qud9x3WzY8sl9e875B5n6O7g7rksfXa2fuOnWpKXRBAAAEE3CDA586Evcj15yckKnKCsrla 9tSW5EpUzlOw+2+Tl/EKAQQQQACBXAjwuTOhIkeeJiQiAQIIIICAqwXMeTH1Hnk85n+VfC071OKr ir32qN6amJ+Uzkofe6wf+TGJOZm/fiivlDSehLxkzq3yx8sYLttK7x+Zc1WMMjPqbPvWP8m/wqeW SIt8FWlsM2pn+kTc2y69C0sRGC1g7sQWdMu/Pygvx2xH+7CkoALmB8SCbr/2B71iOOaS3gwKVqnb 366gtzKXGZNXMQTytN/myFMxOpMyEUAAAQQQQMCxAgRPju06Ko4AAggggAACxRAgeCqGOmUigAAC CCCAgGMFOFXu2K6j4ggggAACuReolDfYIW/uMybHYgiUexXsyX1vcuSpGJ1Jmc4VqKtWFVuNc/vP VTWfprrq6WI4uqpTaYxDBPi1nUM6imoigAACCCCAgD0E+NJij36gFggggAACCCDgEAGCJ4d0FNVE AAEEEEAAAXsIEDzZox+oBQIIIIAAAgg4RIDgySEdRTURQAABBBBAwB4CBE/26AdqgQACCCCAAAIO ESB4ckhHmdU072Xls25Q6aB6U1UEEEAAAWcK8LmTvt8IntK7sBSB0QLmDSZ9I3dOH52AJQgUToAP tcJZUxICqQIET6kivEYAAQQQQAABBMYRIHgaB4e3EEAAAQQQQACBVAGCp1QRXiOAAAIIIIAAAuMI EDyNg8NbCJjzSuo9HnnM/wqfWiIt8lXEXnv8CkUGh5CS0lnpY4/18Un+g4qE/MN5paTxJOQlc25V vVVGymP9yJyrXJaZy7yKUf9ilFl4s+TxU+FrUaTFpwprLCWMDbZcBBDIrwD3tsuvb05zN3fWC7r9 2h/0qjynOZNZRgJmULOgW/79QXnpgIzISJQ/AfYH+bMl5xEBxtmIReIzjjwlavAcAQQQQAABBBCY QIDgaQIg3kYAAQQQQAABBBIFCJ4SNXiOAAIIIIAAAghMIMDMjQmAeBuBuEC5V8Eeb/wlTxAopkC5 NyiGYzF7gLJLWYAjT47q/Wmqq54uOs1RnUZlEUAAAQcL8LmTrvP4tV06FZYhgAACCCCAAAJjCHAQ YwwYFiOAAAIIIIAAAukECJ7SqbAMAQQQQAABBBAYQ4DgaQwYFiOAAAIIIIAAAukECJ7SqbAMAQQQ QAABBBAYQ4DgaQwYFiOAAAIIIIAAAukECJ7SqbAMAQQQQAABBBAYQ4DgaQwYOy42b9DoC0V02o6V o04IIIAAAq4T4HMnfZcSPKV3YSkCCCCAAAIIIJBWgOApLQsLEUAAAQQQQACB9AIET+ldWIoAAggg gAACCKQXMPizscBJo6dtoSEp/f+cNqPnlFn98dItNNp6Tg638VSP0TZnorwM41RPmzFnjDLntPUY Q0VmWGYu8zKKUH/7lmnfPsdMRrbbiX3NMtwfsG0aiu+PnW423r5FSe208Ydn3qvGve3Sx5S2XGpO 3FvQ7df+oFfltqwhlUIAAQQQcJMAnzvpe5PTduldWIoAAggggAACCKQVIHhKy8JCBBBAAAEEEEAg vQDBU3oXliKAAAIIIIAAAmkFmPOUloWFCCCAAAIIIIBAegGOPKV3YSkCCCCAAAIIIJBWgOApLQsL EUAAAQQQQACB9AIET+ldWIoAAggggAACCKQVIHhKy8JCBBBAAAEEEEAgvQDBU3oXliKAAAIIIIAA AmkFCJ7SsrAQAQQQQAABBBBIL0DwlN6FpQgggAACCCCAQFoBgqe0LCxEAAEEEEAAAQTSCxA8pXdh KQIIIIAAAgggkFaA4CktCwsRQAABBBBAAIH0AgRP6V1YigACCCCAAAIIpBUgeErLwkIEEEAAAQQQ QCC9AMFTeheWIoAAAggggAACaQUIntKysBABBBBAAAEEEEgvQPCU3oWlCCCAAAIIIIBAWgGCp7Qs LEQAAQQQQAABBNILEDyld2EpAggggAACCCCQVoDgKS0LCxFAAAEEEEAAgfQC/x+tkJyrYkjHyAAA AABJRU5ErkJgggA= --_005_1AE4350ADF5349AEA209A04CB488215Cericssoncom_-- From nobody Mon Oct 29 07:45:11 2018 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 DD31F130E29 for ; Mon, 29 Oct 2018 07:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 dbi8w03Xn33U for ; Mon, 29 Oct 2018 07:45:05 -0700 (PDT) Received: from smtp-out10.electric.net (smtp-out10.electric.net [185.38.180.36]) (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 61A1112F18C for ; Mon, 29 Oct 2018 07:45:05 -0700 (PDT) Received: from 1gH8mq-000TC2-UX by out10a.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1gH8mq-000TDK-VR for ace@ietf.org; Mon, 29 Oct 2018 07:45:00 -0700 Received: by emcmailer; Mon, 29 Oct 2018 07:45:00 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out10a.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1gH8mq-000TC2-UX for ace@ietf.org; Mon, 29 Oct 2018 07:45:00 -0700 Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Mon, 29 Oct 2018 15:45:00 +0100 To: References: <065d01d45f4e$bc227690$346763b0$@augustcellars.com> From: Ludwig Seitz Message-ID: <8b5d13a3-6d04-650e-0f05-d72d33937d50@ri.se> Date: Mon, 29 Oct 2018 15:44:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) X-PolicySMART: 14510320 Archived-At: Subject: Re: [Ace] WGLC for 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: Mon, 29 Oct 2018 14:45:09 -0000 On 24/10/2018 22:49, Mike Jones wrote: > 3.1, 3.2, and 4.1, parameter definitions: None of these parameter > definitions specify the syntax of the parameters defined, making > understanding these quite confusing. Yes, this is talked about later in > the doc but there are not even forward references to where the > definitions are completed in most cases. Please fully specify the > parameters when they are defined. > > 3.1 req_aud: Doesnt this duplicate the resource parameter defined by > https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-01? If > so, please delete this parameter. If not, say how it is different and > why the differences are necessary. > > 5 cnf in the introspection response: Which token is being referred to by > the phrase bound to the token. The access token? The refresh token? > Another kind of token? Please make this more specific. > > 6 CBOR Mappings. The table contains the magic numbers 8, 17, 18, and > 19. From what space are these numbers being allocated and what registry > are they in? Per my earlier reviews of the ace-authz spec, I believe > that the ACE OAuth parameters should all be registered in the CWT Claims > registry because of the possibility of them being used in signed > requests in a manner analogous to > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17. The parameters > need to be registered to avoid claim number conflicts. > > Missing Examples: The best thing you could do to help developers > understand what these values are and how they use them is to add > examples, just as was done in RFC 7800. Please add examples of each of > the parameters using the JSON representations of them. Optionally, also > add CBOR examples if you believe that they will convey important > information to developers that the JSON examples dont. > > Thank you, > > -- Mike Hello Mike, thank you for your review. I've added issues to the tracker here: https://github.com/ace-wg/ace-oauth-params and will address your comments. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 From nobody Tue Oct 30 03:19:58 2018 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 C389C12F1AB; Tue, 30 Oct 2018 03:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 UIBoPW5PdVsG; Tue, 30 Oct 2018 03:19:53 -0700 (PDT) Received: from smtp-out11.electric.net (smtp-out11.electric.net [185.38.181.42]) (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 9FC48130DC1; Tue, 30 Oct 2018 03:19:53 -0700 (PDT) Received: from 1gHR7l-000MiF-Vh by out11b.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1gHR7m-000Mjz-Tj; Tue, 30 Oct 2018 03:19:50 -0700 Received: by emcmailer; Tue, 30 Oct 2018 03:19:50 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out11b.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1gHR7l-000MiF-Vh; Tue, 30 Oct 2018 03:19:49 -0700 Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Tue, 30 Oct 2018 11:19:49 +0100 To: Jim Schaad , CC: References: <065b01d45f4e$b8d372a0$2a7a57e0$@augustcellars.com> <028d01d46a3a$bc6414f0$352c3ed0$@augustcellars.com> From: Ludwig Seitz Message-ID: Date: Tue, 30 Oct 2018 11:19:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <028d01d46a3a$bc6414f0$352c3ed0$@augustcellars.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) X-PolicySMART: 14510320 Archived-At: Subject: Re: [Ace] WGLC for draft-ietf-ace-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 10:19:57 -0000 On 22/10/2018 21:09, Jim Schaad wrote: > > * Registries - I am wondering if we should think about re-writing a couple > of the registries. As things stand it appears that the application/ace+cbor > content type is being used in 5 or 6 places. It might make more sense to > have a registry for all of the CBOR abbreviations that are being used in a > single table and have multiple columns for each of the different places were > the content format is being used. This would make it easier to keep > everything constant and can make re-use of integer values easier to see. > Yes in the light of the ensuing discussion with Mike, Carsten and Olaf it is clear that the whole registry process needs a second (third, n-th) go-over. I'd very much like to have all abbreviations in a single table, however some of them are in the new draft-ietf-ace-oauth-params, so I'm not sure on where to do the table, since I'd like to have the parameters from there in it. > * Comments on protection of CWT/Token: I am wondering if there needs to be > any comments on how a CWT is going to be protected. While it is ok to use > either a symmetric key or a direct key agreement operation for a single > recipient without forcing a signature operation to occur. If the token is > going to be targeted a single audience hosted on multiple RSs then a > signature operation would be required for the purposes of authentication. > In the light of your and Steffi's comments, this seems to merit a section in the security considerations. > * I am not sure where this issue should be raised so I am putting it here. > Both of the profiles have as their last security consideration a statement > that the use of multiple access tokens is a bad idea. Both of them also > devote a large section of text to how to deal with multiple access tokens as > does this document. More methods of having multiple access tokens seem to > be coming down the path from the OAuth group. This appears to be a distinct > contradiction within the set of documents that should be resolved. > I'd like to have the view of our OAuth experts here: How is OAuth typically used, when a client needs to get more permissions than initially granted? Is the old token invalidated and a new token issued, or is there something like "add-on" scopes in additional tokens? Given the amount of trouble the handling of multiple tokens for one client-RS pair can raise, I'm not disinclined to forbid them or at least recommend against their use. However with audiences possibly addressing overlapping sets of RSs this might be more difficult than it looks. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 From nobody Tue Oct 30 04:17:22 2018 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 72EDD129385 for ; Tue, 30 Oct 2018 04:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.848 X-Spam-Level: X-Spam-Status: No, score=-0.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_IMAGE_SPAM_HTML=0.81, DC_IMAGE_SPAM_TEXT=0.242, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 4TrqXShgCY2L for ; Tue, 30 Oct 2018 04:17:18 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0229.hostedemail.com [216.40.44.229]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48F4A128B14 for ; Tue, 30 Oct 2018 04:17:17 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay02.hostedemail.com (Postfix) with ESMTP id D152C5B41; Tue, 30 Oct 2018 11:17:16 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::, RULES_HIT:41:152:327:355:379:582:599:871:962:967:973:988:989:1000:1152:1189:1260:1313:1314:1345:1359:1436:1437:1516:1517:1518:1541:1575:1588:1589:1592:1594:1711:1730:1764:1777:1792:2198:2199:2527:2528:2559:2562:3138:3139:3140:3141:3142:3352:3622:3865:3866:3867:3868:3870:3871:3873:3874:4321:4511:4513:6117:6119:6261:6353:6506:6657:6659:6678:6747:6748:7281:7398:7774:7875:7903:8603:8957:9912:10004:10215:10400:10848:11232:11604:11658:11914:12114:12295:12663:12740:12895:13071:13139:13210:13229:13439:14096:14180:14721:21060:21063:21080:21324:21433:21451:21627:21703:30054, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:28, LUA_SUMMARY:none X-HE-Tag: join36_22699c0c89344 X-Filterd-Recvd-Size: 49330 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf17.hostedemail.com (Postfix) with ESMTPA; Tue, 30 Oct 2018 11:17:16 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_4f04cbe54118ed73363d65f02627f6d1" Date: Tue, 30 Oct 2018 12:17:15 +0100 From: Peter van der Stok To: Francesca Palombini Cc: consultancy@vanderstok.org, ace@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <1AE4350A-DF53-49AE-A209-A04CB488215C@ericsson.com> References: <23af2ffc9ec791bec0653d4a5baab467@bbhmail.nl> <1AE4350A-DF53-49AE-A209-A04CB488215C@ericsson.com> Message-ID: <49b815a4b1f939190fa681d1c3fa7239@bbhmail.nl> X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [5.206.216.229] Archived-At: Subject: Re: [Ace] Fwd: review of palombini-ace-key-groupcomm 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, 30 Oct 2018 11:17:21 -0000 --=_4f04cbe54118ed73363d65f02627f6d1 Content-Type: multipart/alternative; boundary="=_7a07b135adf8b0a5aaf09b4175183059" --=_7a07b135adf8b0a5aaf09b4175183059 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII HI FP, Answering below. section 1.1 does not mention groupcomm draft for the terms: group identifier and role identifier. group identifier is described in groupcomm document role identifier is not; hence difficult to know what to do in the implementation Francesca Palombini schreef op 2018-10-29 11:32: > At the end of section 2, I suggest some text on group identifier and role identifier, such that these terms can be used independent of the application profiles specified in other documents. > > FP: I am not sure why do you think these terms (which appear first in section 3.1) are not independent of the application profiles specified in other documents. Could you please expand on that? --=_7a07b135adf8b0a5aaf09b4175183059 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 HI FP,

Answering below.
section 1.1 does not mention groupc= omm draft for the terms: group identifier and role identifier.
group i= dentifier is described in groupcomm document
role identifier is not; h= ence difficult to know what to do in the implementation

Francesca Palombini schreef op 2018-10-29 11:32:



At the end of section 2, I suggest some text on= group identifier and role identifier, such that these terms can be used in= dependent of the application profiles specified in other documents.

FP: I am not sure why do you think these terms (which appear first= in section 3.1) are not independent of the application profiles specified = in other documents. Could you please expand on that?


--=_7a07b135adf8b0a5aaf09b4175183059-- --=_4f04cbe54118ed73363d65f02627f6d1 Content-Transfer-Encoding: base64 Content-Type: image/png; name=image001.png Content-Disposition: attachment; filename=image001.png; size=18643 iVBORw0KGgoAAAANSUhEUgAAAkQAAAEyCAYAAAAbc88bAAAgAElEQVR4Ae3dD3xT9b0//ldC5aK0 pVZ6JUGEB+0qOLhutL+6DXdpi8J3A/98i+LviiYTHndlY/y9hfJnzi+boJg8QECmzG8rgckdaHJR dBtgC2w6pb+EjYsCzToeApLWC2JpiyJt8/k9TnKSnLRpSdr8z4vHg0dOz/mcz5/n5+Scd875JB+V EEKA/yhAAQpQgAIUoEAKC6hTuO1sOgUoQAEKUIACFHAJMCDigUABClCAAhSgQMoLMCBK+UOAABSg AAUoQAEKMCDiMUABClCAAhSgQMoLMCBK+UOAABSgAAUoQAEKMCDiMUABClCAAhSgQMoLMCBK+UOA ABSgAAUoQAEKMCDiMUABClCAAhSgQMoLMCBK+UOAABSgAAUoQAEKMCDiMUABClCAAhSgQMoLMCBK +UOAABSgAAUoQAEKMCDiMUABClCAAhSgQMoLMCBK+UOAABSgAAUoQAEKMCDiMUABClCAAhSgQMoL MCBK+UOAABSgAAUoQAEKMCDiMUABClCAAhSgQMoLMCBK+UOAABSgAAUoQAEKMCDiMUABClCAAhSg QMoLMCBK+UOAABSgAAUoQAEKMCDiMUABClCAAhSgQMoLMCBK+UOAABSgAAUoQAEKMCDiMUABClCA AhSgQMoLMCBK+UOAABSgAAUoQAEKMCDiMUABClCAAhSgQMoLMCBK+UOAABSgAAUoQAEKMCDiMUAB ClCAAhSgQMoLMCBK+UOAABSgAAUoQAEKMCBK9GOgwwZjngoq1VxYGjui0poOmxF5KhVUegsao1Ii C6EABShAAQpEViAtstkz94gLpBWg4pQVGPNKxIvyFJBWUAFXkZs8a/hKAQpQgAIUSGwB3iFK7P5j 7SlAAQpQgAIUCIMAA6IwIIaahe+R007Y6rZAr5Ueeamg0uphtNjQ6HTn6EvneTTVBpuxxJ020OOq 1lOwVE51b1eNh964D/Y2OTO5ks7GOpi8abQoqVyDypKfeR+3hVamE612CypLtL76H7CjLVQQpqcA BShAgagI+F8DVNDqN+CAvaVL2dfQaNvhO7erpqLS+B8o6XbdaYH9wAbfNUxKV/0yKqdvgE0xguP6 ZUrlvY1qv2vTK3jT1gjPFcx3ber9utmlISH9yYAoJK7wJHY/cjIgt8GETXsyscD2NYQQEI7NeABv Yvn6OldQIaVrcJih8xabjoKKgxB+6zwbrdg8/0WcmbENnVJe4n2suusE1szYCJs3KLqIQy9sxIm7 N6LVleZT7J0z1pOB6zWkMhu2YP66RszY+Ym7/vZVuOvYOswwuuvvlzH/oAAFKECB2Aq01WH98gMY sWiv+5wtBByvzsSAbSthtDX76tbyHl5YeRJ3bz0lp3sdc0b/k2+7a+kazlt+gfnvjsQqe6ecbi8W jetE05lOX9qgyhyIW7Wj8G1vvT7F3icHwvLoZhxqcYdEwV43fQWHvsSAKHSz8O2R/ihWPfMECjQD 5Twzkf/QY5h06G3UyQdB8IUNw7S1z2FxkQbuTs1E/n0/wapH67G77pKczVdobvpSkaUa6fllWHfw RZRp+jCcbOADWLvxJyjy1D89H/ctWYpH+1R/RbW4SAEKUIACYRa4CvvualzQl6PUc86WSlAPR+n8 UpzcfRTe+0RXmtF0TVl8JvLL1uKgqQwaz+qO4/jPp29C5aqHkJ/uCSUGQlM0D6bjFShwXVKCL1Ot GYdve+ulRvqYUjw48Us0X/HcI5ILDut109MY96unFf5r+Vd0BIZlIaNrD6gHI+uWlu4HwXVrdBtG a9O7pEpDRtYgNDV/Ja8fjimrngA2lyJDekQn/S+pRHVtHx9z3T4SWu8bQS6iz/XvUnX+SQEKUIAC YRToQOulr5AzZFD3PHNGYmzNUfzd85hLcy9WzQc23zFEHoIhDa+oRq3y0dqFMzg+oRBjM7texJTZ B1um9MjMAqN+vFyedH26HTO2X1Vm5l4O63XTP/veWuKfkn+FX6CpGa1dgl84r6D580xkDe65a5yt zWjqVptPcdrRdfROB1qbr2JY1o1yas8dIYd8e/NrOIx345JpPn5Ve7FbjsoVAcs8ewYO7+M4OXUQ 9Vfmy2UKUIACFIiGQBoysm/Ehcvdgwzn6WM4NHkCvuF9UCDfEXINrRAQnTYY774E0w+fQ63n6cXg LAx734qTnr8DNiG4Mp323+LfN53BXave9z7KE+IszLoAwVsfr5sBq9dlZc9X3S4J+WcEBNp2Yc3P d8DW6Lk32QL7HjPqy2aiyBN1Swdd03GcdKVxD2B7sngO9nerThPeWbkcG+rkQWjORthMT2P+4e/i yaJsV2qnvRpTS1bC4o3ypee2t2JA17yCLfPaW1i58CXUyfV3DZxb8QscVta/a978mwIUoAAFYiAw CPkzZyPHtElxDQDQdgp7qo6ieOYEZLpqdRX26lkoqbT4vpSjvgXa2zwfrOWqZ96DBc9/iXVr9vjS oQX22l0w6ueg2i4FXsGV6Wy9hDNpI3FnnrsGaLOj9o1dePNA9+ANwVw3+6or+C8mAu1Wg8jVvS7q 681iWbFGABDQ6IRhf71o9avRZVFvXiGKpe3QiOJl24XV+prQSX/rzMLRbhWGXGlbuTDXHxfmZVPc eWGc0Bn+KOpbO725ddZXiWk6g/idQSc0rvz6VuZZqe6u8oOpv7d4LlCAAhSgQIwFOh1HxDbvdQJC o1sv9tdfVtTqK1FfNVvoDFXCoBsnX08CpZN2uSzq968XOo10DZL+S9ed34kav/yEuG6ZnQ5xZL3i ulS8TFTV/FFU6XIFUCwMVvdVMfjrpqI5ISyqpLR9Daa4X98FpK8Qjtk0Gn9WDlLre3bckwIUoAAF KJDUApG+bvKRWVIfPmwcBShAAQpQgALBCPAOUTBKYU7jinILl+Ifnnx1Zjh4p8ijwVcKUIACFKCA n0A0rpsMiPzI+QcFKEABClCAAqkowEdmqdjrbDMFKEABClCAAn4CDIj8OPgHBShAAQpQgAKpKMCA KBV7nW2mAAUoQAEKUMBPgAGRHwf/8BPosMGYVwKjresvYPul4h8UoAAFKJBoAmE8v0sDnvPyjH4z 3Ccah1RfBkSJ2Gv9rvM1NNZtgV4rz2fmmtNsA2xdp+HotZw22Iwl3nln8ow2eKbB6XU3bqQABShA AQrEoQC/ZRaHnRLxKrXUonLCa7jj7Q2YPUb+qfR+FCp9OvjOwRJ8WFEA71Q4/ciPu1KAAhSgAAWi LcA7RNEWj4fyrjSjaeI0/CAMwVA8NId1oAAFKEABCvRXgAFRfwX7sL/reav0mEq/EzbloyutHkaL DY1OT6YdaLTMlR9LzYXl/DnYTJUokfZVTcXK2vPwJnVN5urZpoJKyuuAHX6jf1zPjKVtM7B9+wxo XflIeXUZJ+RJ59reZZunasG+OhtRt0GvKGsqKqtrFZMBBpsR01GAAhSgQH8EvNce77lfBVXAsT/X 0GjbgcoSrXz9GQ+9cV+387ZffgHzOQeLPg8q1VxY7H9FtX68Oz+t3jcReX8aFOZ9GRCFGTSY7NIK KnDKakBugwmb9mRige1rSFPKCcdmPIA3sXx9nRzIpEFT9jKEOAuzrh6bH/8hKk6Mg9HxNUTrZtyL K/jSVWAzbOvXwDxiAWqkfFx5vYJZA17HPKMnLwBpBahokMoxQyf9OrYnrTiIioJ0X9U96UQrrIbb fetDXpLqVYEt+DFsnXK9xOuYM+IY1lXswXlvNBdyxtyBAhSgAAVCFJCuPQ3e8758LeiWhxNttpex 3DwMi2oc7uuJOI5XZ6mxbd6LfmNNvfm1W2HI6pYRgBEoMx10X7/Kf4kG/R/RKTrRWluKvz22GYda 4usiwIAoUB9Ga136o1j1zBMo0AyUS8xE/kOPYdKht1HX7UDJwnef+iNq1snp0/NRWpoPKYxx2i14 +kIZlpcOV4ySHwhNqQ4PnvxDgLyi1MCWo9h9aDJWLZwIjfdIy0T+fT9BZdHfsK/hapQqwmIoQAEK UCAoAacdu5++CP3yyYrzNqDWlGD+g+exu+5SUNn4J7qG0fNfwDOua5Qa6WNK8eDEL9F8hQGRv1Mq /zUsCxneQEGGUA9G1i0tAQ6UkSgce6si4PHBOVsvoSlnCG7yrZKXbsbIsadx9O/u+0jdNkd6hTRW 6Z05uGOA4ttsrlu1N+KOOTtx+KMLka4B86cABShAgVAEnFdwqSkTQ27qenFKQ87IHNQcPdOHbxT/ P5j2XeUH9lAqFL20XVscvZJZEtDUjNauAbLzCpo/z0TW4OC7Rp2RjWEXLsuPzxSwzk9x7NBITPhG 91BJkSpyi7feiUnl21DvfVzmeWwmvTbAVDYicmUzZwpQgAIUCF1APRjZw1pw+cuuF6erOH2sAZMn jEzabxMHf9UNnZV7XE+gbRfW/HwHbI3X5JQtsO8xo75sJooyg+8adX4ZVudYsMZySjGIWsprJw4X Tw8pr+tVOaTt6tH4wcwLqFpvUbQRQNspWCpnobL2YkjZMTEFKEABCkRYQJ2PmauHwrRmj2IQtRNt 9t+j6vCdmFmUHeEKxDB7wX8xEWi3GkSu7nVRX28Wy4o1AoCARicM++tFq7dGZ4VZl+veJm33/s8V OvNZbyrXQqdDWLctE8WeNN3yEkI4zELn2e73Wi7MjnY5v1ZhNRQrylKWWywMVnftXPX3y8OXLtdg FZ7chPhaOKxmYdCN8+ap0RmE2eoQnf4t4F8UoAAFKBBNAemakGsQVt8JWy5dOm9v912bME7oDH8U 9a2Ks3a7VRhyfed93/UJAt48ldcw+frht5/vmhLNZvdUFn+YMUbBqPR1xTGbRuPPpjJoYlQHFksB ClCAAiksIP3EyiPH8IB5NvKDfyiRtGAkSNquZcMoQAEKUIACPQlcQ+Of3saB/FEYxkjAhUSGno6V CK533R0qXIp/eH4cUW9BYwTLY9YUoAAFKEABvx9SVI3CY/tGY+2ie9D/CZySw5aPzJKjH9kKClCA AhSgAAX6IcA7RP3A464UoAAFKEABCiSHAAOi5OhHtoICFKAABShAgX4IMCDqBx53pQAFKEABClAg OQQYECVHP7IVFKAABShAAQr0Q4ABUT/wortrG2xGPYy2tigWG4syo9g8FkUBClCAAr0IhPcaIH3L rdBo68NcaL1UMYybGBCFEZNZUYACFKAABSiQmAIMiBKz31hrClCAAhSgAAXCKMCAKIyYzIoCFKAA BShAgcQUYECUmP3GWlOAAhSgAAUoEEYBBkRhxGRWFKAABShAAQokpgADosTsN9aaAhSgAAUoQIEw CjAgCiMms6IABShAAQpQIDEFGBAlZr+x1hSgAAUoQAEKhFGAAVEYMZkVBShAAQpQgAKJKcCAKDH7 jbWmAAUoQAEKUCCMAgyIwogZ+axuRnZGWuSL8SshFmX6VYB/UIACFKBAzATCeQ0YgBHZgxGvgYdK CCFi5syCKUABClCAAhSgQBwIxGugFgc0rAIFKEABClCAAqkiwIAoVXqa7aQABShAAQpQoEcBBkQ9 0nADBShAAQpQgAKpIsCAKFV6mu2kAAUoQAEKUKBHAQZEPdJwAwUoQAEKUIACqSLAgChheroNNqMe RltbwtSYFaVAtAQ6bEbkqVRQ5Rlh64hWqSyHAhQIRUB6nxYabYjXtygDolB6M+XSMghLuS6PWoPP waKfCP2G99Ho7H+haQUVaHCYoet/VvGTQ5sdB4x6aKdWwx4Go/hpGGuSOAKpdQ1gQJQ4RyZrSoEk EhiBslffwDz8BgWTK2GyNYLXfE/3tsB+YAP0+fPxbs482P4wG/k8U3tw+EqBiAnwbRYxWmZMAQr0 KqDWoGjxq7BvLcWFTfdjcuUO2Bqv9bpLsBu9j9Ckx2iqEt+jZmcj6jbooXWtl7ZNRWV1LextnnBM unOVB1XX/Rot0LvW5UFvORdsNUJO52ysg6nyMZS/OxQLbHuxTl8EDc/SITtyBwr0RYBvtb6ocR8K UCBMAmqk509FhakWW++9iE0F96PSVNfPx2hOXM0YjRm6p2CuvwwhDqKiIB1AM2zrK7AFP4atU0D6 kX4hXsecEcewrmIPzrtiIunO1duomvI9LKt5Xd4PgOYhbLGux5Rlv8HmshFharsiG2cjbKZKTC7Y ggv3rsfedU+gQDNQkYCLFKBAxAWkqTv4LxEEWoXVoBMGa2tkK9tuFYZcSNO5BPyfa7CKdiFEu9Ug cq+TRgipzsUB8wGKfW3prcxcg7BKBaZMmali1sNh7DALHSA0s83i084e0vS0Wto3d4mo+t0KMUX3 ojji+No/5eUasWxalajvlu9Xor7qKVFV/5WcvlNcrlkhNFMUaTs/EebZsxVp/LPu11+dJ0XVFI0A yoXZIR/sATNM9GMj0esfi/NeDMx6Ox8DwnMNCHiIXmeldN0okK8h10kak83SpyT+SwgB6Y0RhYDI zyIWZfpVgH+kjMBlUb9/vdBppohl244IR7egJQgIVzA1Tjyme0RMWbG/ex5ysBU42M8VOvNZXyGu IOV7YlnNBSFEp2i1bhQ6wxERsY8jnQ5h3bZMFGt0wrC/PnLl+FrIJQoEIRDea0C8B0R8ZBbxe3As gAIU6FnAiTb7Phj1peEZN5Orx5Kq/4uNeWb86OcH/B+93XonJpVvQ733cZnnsZn02gCT8lGYOh8P V07CjnVvwd5xDvtfOY8H/+1bkB68ReSfWoMC/TrU2OYh5935yNdvQV2YxlNFpL7MlAJJKMCAKAk7 lU2iQEIIuAY4P4n88lrkLNiLmrCNm8nEmNnPY2PeO/j5to/g/eUu9Wj8YOYFVK23+A/ebjsFS+Us VNZeVLCpkVmswzP4Ndas2oA382ZgyvDIj+lRa4qgX/c6Dj1+DVvCMp5K0SQuUoACvQowIOqVhxsp QIGICDhPofoH97sHONesg75Ag/6cjFzfKtPOwHZvZS/jxOG3UT1nPDJUnm+GDYSmdAEWlQAHlxfI 3yRTQTvvbWCmEc+WDvXu7VpQ52Pm2lk4u6MjsneH/EsFkIn8+xbDZN+Mey9swfdX1KKlWxquoAAF wi2gkh4ihjtT5hcJAekHsubhYMkW3zdfIlEM86QABWQBJ9psL2Lewe9gS0VR5B6X0ZsCKSIgfXD5 zsESfFhRgLQ4bHN/PpTFYXOSvUo3IzsjHg+jZHdn+1JSwBmFsUMpCctGp67AAIzIHtyvu8GRtOMd okjqMm8KUCDBBDrQaPkZtDO2KupdDIN1L+/MKkS4SIFkFGBAlIy9yjZRgAIUoAAFKBCSAB+ZhcTF xBSgAAUoQAEKJKMAA6Jk7FW2iQIUoAAFKECBkAQYEIXExcQUoAAFKEABCiSjAAOiZOxVtokCFKAA BShAgZAEGBCFxBXLxNLvEOlhtHl/dzeWlWHZFKAABShAgZAEpN8hKjTa0BHSXtFLzIAoetYJWBKD sATsNFaZAhSgAAX6IMCAqA9o3IUCFKAABShAgeQSYECUXP3J1lAgcQScjbCZKlGiUrnmFdNKM7zb dkIv/Z1nhM11X/0cLPo897xjegvON9bBVDnV/XfJatR6Z4S/hkbbDlSWaOU5ysZDb9wHe5tT9pDu dpZA5Z3XDECHDcY8qWzPXGfSKiPypPL1O2Gr2wK91l03lVYPo8WGRk92rlydaLPvg1E/Xi5Ti5LK l1FdOcf/0XaXdrryOmCXJ5311Gs89M+tdpWn1Ztwwr4PK11tmYqVtefh9NRVq8dzz+mhVY2HvtoG e+1qt5+fReIcAqwpBeJJgAFRPPUG60KBlBFowalt6/DrSw9gZ6eANKXip899C+9vehbbdWY4GipQ 4JqlZgTKTA0QDjN0DZvxeMFTOHHnr+Do7ETr1lKg9SoAac6xl7HcPAyLahyuvIQ4jldnqbFt3ouw uYKidBRUHIDDPN0nnFaAioZ2v3VpBRU4ZTUgt8GETXsyscD2tTs/x2Y8gDexfH2dHMgAzvN7sHD+ YYxe9b5cpgM1i8bjctMlXxlohm39GphHLECNcLdTOF7BrAGvY55Rykuq115YDUOxfR+gt13GoUnv 4JvFu5H30gm0Wv8XPjAdwWdSXU9ZYbjpAPa1PA5b++uYtOt+FJtG4aXWz2Gd9jFMH3ymKJeLFKBA qAIMiEIVS/b0nk+irk/tGShcuh1LCzPkT8Aq5MXxgLhk75qkal+LFa9a/gWVCydCI5+F1JqJWLhq Mab01NCBxXjKthfr9EXQqNVIz/8+SvMzAacdu5++CP3yyd68pCzUmhLMf/A8dtcpA5SeMu+yPv1R rHrmCRRoBsobMpH/0GOYdOht1LVIt4na8Nf//B2GVi5BmVQH+Z/UhsWm//JO8+G0W/D0hTIsLx2u mL9pIDSlOjx48g9yXtLOt8Ng/A+UajIx+q4iFCz5KXRjspCuHYnbPZlLr1lLYPzlfdCk3Ya77rsP SxbMwJj0TGhHa5WpuEwBCvRBgAFRH9CSehfXp2b5k6xohdWgg8HaKn8CFmiI01mKk7pPkrFxV5rR dEsWMrqcgdQZWRjWU3tvH4+x3gBFkch5BZeaMjHkpi6ZIQ05I3NQc/RM6N9qGda9blAPRtYtLWi+ IgVEX+DMcS3uHpulqEj3RWfrJTTlDMFN3TbdjJFjT+Po37/stoUrKECB2Ah0PYPEphYslQIUSC2B wVkY9nkzWruOyXGcwdlQJdSDkT2sBZe/9MsMwFWcPtaAyRNGwvX0LWC+HWht/qL7lqaudZOezF1B 8+eZyBosnTZvRNawBhw52dx9X8UadUY2hl24jG5hj/NTHDs0EhO+0T1UUuzORQpQIIoCDIiiiJ2U RbXVwega/DkdRltPFwdpjMcGefDnBnlMRyCNZtiM06FSaVHiGl8RKI30tCIVykwCsx66z7U6sxBP lv031m18Xx6oLA1Q3oNfVRhwqLf9Am1T52Pm6qEwrdmjGEQt5fd7VB2+EzOLsuW91BiclYkm6yl3 mW12HDCWo3jO+91zbduFNT/fAZt30HYL7HvMqC+biaJM6bQ5FMULZuPiuvWw2Fvk/aUyD+EN4xxM rz4FKTxT55dhdY4FayynvGOPACmvnThcPF3Oq3vxXEMBCkRfgAFR9M1ZIgUogEyMmf1LVI58B48N kL7JNQD5axoxw2iETqnTaHF/60w7A9u3z4BW/kaaSjUXlkbPz7upkV4wF8/NvIKq+2+Tx7vdhXlv DcacLT9DQbrnNKdGZtFjKO80QiuVmTEf7+b8GHtfvxfbZ5RAbznnKznv37HqR4Ox+7FR7vy08/FW xiN4avY4pMup1MMfwsbNk3B6zUS5TKkNVmBCJX43e4w8ZigLBUtWYWbrq7jfU3dXXo9jS0UR0iF9 y+x+eazet7x1aF5aiDGe8Xqedt9QiKW2pSi8wdP2s1haeL/8jbar2D7jdo7x8/UglygQsoBKSF/v 4L8EEJBOnPNwsGSLd8BmAlSaVaRAaAJSALQceM5UBk1oe4YttfTV+zGbRuPPMaxD2BrDjCgQRwLS e+s7B0vwYZyORfV8dIojMlalZ4GbkZ3R82iInvfjFgokgIDzPGo3V+Ps+NuQkQDVZRUpQIFQBQZg RPZgxTcuQ90/sul5hyiyvsydAhToUaADjZafQTtjq5xiHHTrX8Zziq/i97hrhDa47g4VLsU/PPlL v4nEO0UeDb5SIKkFGBAldfeycRSgAAUoQAEKBCPAR2bBKDENBShAAQpQgAJJLcCAKKm7l42jAAUo QAEKUCAYAQZEwSgxDQUoQAEKUIACSS3AgCipu5eNo0CqCUg/jnhM8QONqdZ+tpcCFOirAAOivspF fT/pd4j08o+wRb1wFkiBhBBwzUBf/AOUv2xV/DJ0QlSdlaRA0gtI3+Is9PzgaBy2lgFRHHYKq0QB CvRBwHkGe36xGdj0W8w7WYmFljOu6TP6kBN3oQAFUlCAv/KXgp3OJlMg+QSaYVu/CJvHrsPeh4tw 08ROHP3Rs9h25/OYPSYz+ZrLFlGAAmEX4B2isJMmS4bBTi6aLO1lOxJZwGm34OnjD+GluYWuucbU mslYufYO7Fj4BuzSLKv8RwEKUOA6ArxDdB0gbqYABeJfQJ0/G2+blPWUJnxdjIP7lOu4TAEKUKBn AQZEPduk+Bb5giIWp7gDm08BClCAAqkgwEdmqdDLbCMFKEABClCAAr0KMCDqlYcbKUABClCAAhRI BQEGRKnQy31qIwdV94mNO1GAAhSgQEIKMCBKyG5jpSlAAQpQgAIUCKcAB1WHUzOp8uKg6qTqTjaG AhSgAAV6FeAdol554m3jzcjOYAwbb73C+lCAAhSgQDACAzAiezDiNfBQCSFEMM1gGgpQgAIUoAAF KJCsAvEaqCWrN9tFAQpQgAIUoEAcCjAgisNOYZUoQAEKUIACFIiuAAOi6HqzNApQgAIUoAAF4lCA AVEcdgqrRAEKUIACFKBAdAUYEEXXm6VRgAIUoAAFKBCHAgyI4rBTWCUKUIACFKAABaIrwIAout79 KK0NNqMeRltbP/LgrhSgAAUoQAEKBBJgQBRIhesoQAEKxLUAPyDFdfewcgEFOmxGFBpt6Ai4NfYr GRDFvg9YAwpQgAIUoAAFYizAgCjGHRC/xXO2+/jtG9YssACP2cAuXEsBCgQjwIAoGCWmoQAFKEAB ClAgqQUYECV19/ancZ7Z7gXEwcUoSOeh0h9N7hsNgSQ/ZjtsMOapoFJJ/zNQuHQ7lhZmyH+rkOcZ m+GXzpNefs0zwiYP4JDGc+S58uqSRqXIC9JYpRJvGe6yPelLfF/yCKrMcOYFRL/+sSgz0c38639D 4VLYlhbiBs9xpzgeo3GGuF4ZnNz1ekJxs106sObhYMkWVBSkx02tWBEKUCAWAjwfxEKdZfZPQApi v3OwBB9WFCCtf1lFZG9+7I8IKzOlAAUoQAEKUCCRBBgQJVJvRbWuHKAaVW4WFgYBHrNhQGQWFEhZ AQZEKdv1bDgFKEABClCAAh4BjiHySMT9KxbfNPcAACAASURBVMcMxH0XsYIUoAAFKJCwArxDlFBd dzOyM+JxKFpCIbKyFKAABShAgW4CvEPUjYQrKEABClCAAhRINQHeIUq1Hmd7KUABClCAAhToJsCA qBsJV1CAAhSgAAUokGoCDIhSrcfZXgpQgAIUoAAFugkwIOpGwhUUoAAFKEABCqSaAAOiVOtxtpcC FKAABShAgW4CDIi6kcTrCul3iPS+yRTjtZqsFwUoEAUBng+igMwiwiwgzWVW6JmEOMx5hyM7tXv2 Yi1KjHVoC5SjsxE2ixF6rTzDcUklTLYP8YZ+ESyNHdL0v4oZmD2zIHte86C3nAuUK9dRgAIUoAAF KECBuBFQf2pehvLXf4PHDr2NuhZnl4o1w7bxNzh2549hcggIISBqFmHsn17Cgu1X3WnTClDRcBZm 3UKYHe3uNFI60Q6HeXqX/PgnBShAAQpQgAIUiD8B9b7qf8LMKaWYVPY/2Ge95FdDp92Cp5u+j4fH ZPrWqzUoWrgCz0zhLyb7UJJxiRNlJmOvJnebeMwmd/+ydRSIrIDa8s1iFGbehPyHZ2LA7j/hvPcm UQc+++i/ccvd34AiHHLXRj0Gs/e9iDJNoKDoHCyux2mApuwFmMpGRLYFzJ0CFKAABShAAQr0U0Bd Nud77oAn819w75D92NcgPwoLOeO3MUN7A1Sq2zHD8zgt5Dy4Q/wIqJFesBgHpcefBxejIJ3j7+On b1iTwAI8ZgO7cC0FKBCMgHrOHTfCPbA6B5Offwu73vsE3ptE6EBT8xXF371lOV0eQySNJxrUW0Ju owAFKEABClCAAnEloO50DYCWB0x31uJRy04ccg2uTsOtd5fiNstf0OCLkIKo/AiUmV6QH6edw5vV f0ZLEHsxCQUoQAEKUIACFIiVgNrvQYh6FO5RDK5WD5+OZ5Y0Ys0KC+xtnqioBfbaXTDqZ8Foa+69 3o3/Hyxrj+DvHb0n49Z4FOAA1XjsFdapNwEes73pcBsFKNC7gDrP8yNJrt8TuhF3zNmK5yfnwL1+ IDSlS/HcTOCteXfJj9bGoHzfFUxY9RIqCrLk3yGSxg1tlMcQeX6DSAWVdga2914+t1KAAhSgAAUo QIGYC6iE9ONC/JcAAtIv087DwZItqChIT4D6sooUoEDkBHg+iJwtc46UgPRL1d85WIIPKwoQ6Dvq kSo32Hz9npgFuxPTxUrgZmRnxONhFCsPlkuBVBbg+SCVez8x2z4AI7IHI14DD94hSsyjirWmAAUo QAEKUCCMAvEaqIWxicyKAhSgAAUoQAEK9C7AgKh3H26lAAUoQAEKUCAFBBgQpUAns4kUoAAFKEAB CvQuwICodx9upQAFKEABClAgBQQYEKVAJ7OJFKAABShAAQr0LsCAqHefONoq/e6IHkZbWxzViVWh AAViI8DzQWzcWWp/BKTfISr0/Bh0fzKK0L4MiCIEy2wpQAEKUIACFEgcAQZEidNXrCkFKEABClCA AhESYEAUIdjEz5YTZSZ+H6ZaC3jMplqPs70UCKcAA6JwajIvClCAAhSgAAUSUoATYyVkt0Wj0mqk FyzGQbE4GoWxDAqEQYDHbBgQmQUFUlaAd4hStuvZcApQgAIUoAAFPAIMiDwSfKUABShAAQpQIGUF GBClbNdfr+EcoHo9IW6PNwEes/HWI6wPBRJJgAFRIvUW60oBClCAAhSgQEQEOKg6IqzJkCkHqCZD L6ZWG3jMplZ/s7UUCK8A7xCF1zPCud2M7AzGsBFGZvYUSBABng8SpKNYTa/AAIzIHox4DTxUQgjh rSsXKEABClCAAhSgQIoKSAER/8ebQa5BWNulcLW3f+3CYS4PW9/lGqziukWKs8Ksyw1bmTz2+N7r 3zFQLAzW1t7eJEKI8L5P+lffPvZ3DM4HMWlnvJ2HWZ9+nOtj8N7MfUToHun79Yl3iFI0CmazKUAB ClCAAhTwCcTrozxfDblEAQpQgAIUoAAFIizAgCjCwMyeAhSgAAUoQIH4F2BAFP99xBpSgAIUoAAF KBBhAQZEEQYOX/ZtsBn1MNrawpclc6IABRJUgOeDBO24lK52h82IQqMNHXGqwIAoTjuG1aIABShA AQpQIHoCDIiiZ82SKEABClCAAhSIUwEGRHHaMbGvFifKjH0fsAahCfCYDc2LqSlAAaUAAyKlBpcp QAEKUIACFEhJAU6MlZLdHkyjOVFmMEpME08CPGbjqTdYFwokmgDvECVaj7G+FKAABShAAQqEXYAB UdhJmSEFKEABClCAAokmwIAo0XosavXlANWoUbOgMAnwmA0TJLOhQEoKMCBKyW5noylAAQpQgAIU UApwULVSg8sKAQ5QVWBwMSEEeMwmRDexkhSIUwHeIYrTjglcrZuRncEYNrAN11Ig1QR4Pki1Hk/8 9g7AiOzBiNfAQyWEEImPzBZQgAIUoAAFKECBvgvEa6DW9xZxTwpQgAIUoAAFKBCiAAOiEMGYnAIU oAAFKECB5BNgQJR8fcoWUYACFKAABSgQogADohDBmJwCFKAABShAgeQTYECUfH3KFlGAAhSgAAUo EKIAA6IQwWKXvA02ox5GW1vsqsCSKUCBOBHg+SBOOoLVCEGgw2ZEodGGjhD2iWZSBkTR1GZZFKAA BShAAQrEpQADorjsFlaKAhSgAAUoQIFoCjAgiqZ2QpXFiTITqrtYWQA8ZnkYUIACfRdgQNR3O+5J AQpQgAIUoECSCHBirCTpyPA3gxNlht+UOUZWgMdsZH2ZOwWSW4B3iJK7f9k6ClCAAhSgAAWCEGBA FAQSk1CAAhSgAAUokNwCDIiSu3/70ToOUO0HHneNiQCP2Ziws1AKJIkAA6Ik6Ug2gwIUoAAFKECB vgtwUHXf7ZJ8Tw5QTfIOTsLm8ZhNwk5lkygQNQHeIYoadTgKuhnZGYxhwyHJPCiQ+AI8HyR+H6Za CwZgRPZgxGvgoRJCiFTrEraXAhSgAAUoQAEKKAXiNVBT1pHLFKAABShAAQpQIKICDIgiysvMKUAB ClCAAhRIBAEGRInQS6wjBShAAQpQgAIRFWBAFFFeZk4BClCAAhSgQCIIMCBKhF5iHSlAAQpQgAIU iKgAA6KI8jJzClCAAhSgAAUSQYABUSL0EutIAQpQgAIUoEBEBdRG/XioVCqoVFNRaXoftjcWQW85 5yvU2QibxQi9Vkqjgkqrh/GAHW2eFI0W6F37y9s9yyWVMNka4ZTTddiMyPNs6/Y6F5bGDk+OfKUA BShAAQpQgAJRFVDPNR2H9NuMQuzForF/w6YFbysq0Azb+p+i4sitWGD72pWu0/ZjDPjtY7jfWOcO ijRlMLVbYcgth9nRLuf1NRzGcThRUYFt9quu/NIKKtDgMEOnM8PhKk8qU/p/FmbdIEWZXKQABShA AQpQgALRFVCne8sbCE3RHKx6ZqK8Rpo5+lWsPPkEfvvsEyjQDHStV2smYvGWX2PaOxuxWw52vFl4 FwZCU/AI5jyRhsMfXfCu5UIoAm2wGUvku3cqqPKMsHV0oNEy17dOVQKjzXuvLpTMe0gbizJ7qApX UyBkgWSe7Z7vzZAPB+4QcwH/J0Py9arLU6U8ow1x83xImroj8L+vRH1VuVhWcyHA5nbhMM8TU6pO ik5pa7tVGHLLhdnRLqe9LOr3rxe6Kf9H1Di+9u3vMAudziwc0hrlsi8Fl/wEOkWrdb2YsqxGXFas 7/zULGZPqxL1LnzFhrAsxqLMsFScmaS8gPvYLQYEitcLa2tE3iAxVOZ7M4b4LLqvAq1HhGHKU6Lm suL92PmJMM+eLarqv+prrhHZr5dB1R1ovfQVcoYEepyVhpyRo/D5pSveMULAVszQ3iDfvZiINcdG YsG2FSiV7yx5Q9XtM6CVxhBpZ2C7dyUXAguokf7tMpRffA1veO/GXUXDvv0YuuQB5PfSe4HzC2Zt LMoMpl5MQ4HrCXhmuxcQBxejID0ib5DrVSKC2/nejCAus46UQPq38G/lLVj/ht0bLzgbalA9dBYe zg8UX0SqItfPt5czRhoysm/EhcvuMUD+WXXgwplPcIvfrLWeMUSdaK1fjWEH9uNYoH09Y4ik8UT+ mfKvQALqEbh31nDseuu/3WO2Wv6Cql13YGZRdqDU4VkXizLDU3PmQoHkFuB7M7n7NylbNxDD730A 39z1B/y1Tfqa1UUcqjqM4pkTkBln7e0lIBqEvHuK8PFrf8J5z1fFPJVvO4rXNn+BR+8Zhe4ZqJGe X4Znq6fg/YUbUNt4zbOX/6s0GNtUBo20tnEfqmsv+m/nX7KAGpnFj+HRQzux/3wL7G+8hovlZfh2 RD/9xqJMdjgFKHB9Ab43r2/EFHEnkPk9zHn0I/x6/zl02N/C+osP4t++nRV31VRb7C1ypZxosx/C G8Y5mCp/g0ydX4bVY3fg8RU7YJMDG2fj+9gw76d4Z9pCzOzldpd6+HT8svwCfvzCe/CUELj1HWj8 4L+w9uiZ+BlYFbiisVurzsfDSzJR/Z87Ydk1HLPuHREgEA1z9WJRZpibwOxSTSCZB1Ur+pLvTQUG FxNDYBDyH56FodW/xXbLYXxz1r9iePe7KTFvihpvzXeP6VENQEb5H9AyoRLmiiK4v32WhYIKE7be exGbCv7JNT5oQMFv0Pn4Tuz1pJFGjN9QiKX/kMcQ6S1odDVrIIY/9DOs/NvjGJJnxIcfGpEnjRvy jCHy/hbRDdDO2BpziPiugBqZRdNR/I4RBx99DMWZ0TiSYlFmfPcCa0eB+BDgezM++oG1CEkgcwJm Fn+AOQcnYU7x0JB2jVZilTRUO1qFsRwKUIACFKAABSgQjwLRuNUQj+1mnShAAQpQgAIUoIBXgAGR l4ILFKAABShAAQqkqgADolTtebabAhSgAAUoQAGvAAMiLwUXKEABClCAAhRIVQEGRKna82w3BShA AQpQgAJeAQZEXgouUIACFKAABSiQqgIMiFK159luClCAAhSgAAW8AgyIvBRcoAAFKEABClAgVQUY EKVqz7PdFKBAdAScjbBZjNBrVa5f+1dp9TAesLsna1bWoO0ULJVT3WlUWpRUVqO6chaMtjZFqmto tFlg1I+X001Fpel92N5YBL3lnC/d9cqUZhjwzhYg10v6u6QSJlujPCt5G2zGErkcRRrPft5ZCXzF cokCiSzAgCiRe491pwAF4lygGbb1P0XFkVuxwPY1pIkBOm0/xoDfPob75TkjXQ1wnoFl4S9gnVqN TiEgxClsvbsBO553KNonzdVWjReO5WOu6bgrLyH2YtHYv2HTgrcV6YIoU5pcu90KQ245zI52Oa+v 4TCOw4mKCmyzXwWQjoKKA3CYF0JnPiunkeomIBxm6BQlcpECySDAgCiWvdhmxwGjXp5Lzv3prLq6 EtONNsVEt9Inwh2oLNHKn9TGQ2/cB3ubU1Hzc7Do89zb9Racb6yDyfNJs2Q1auWJeYFraKzb4vuk Kn8KrfVO8KvIkosUSDiBeJvcVarPq1h58gn89tknUKAZ6BJVayZi8ZZfY9o7G7HbFXgAcF7E6WNF mPGvw+WJmzORX7YETy3L8fWC047dTzsw9eE75bkmpU0DoSmag1XPTJTThVCmL2d5aSA0BY9gzhNp OPzRhW5buYICyS7AgChWPez6RPhzvDt6BeyuT4QComYRxl1uwhlvnaST28tYbh6GRTUO+RPacbw6 S41t816EzRsUjUCZqcH9qa1hMx4veAon7vwVHJ2daN1aCrRKn/akvLbgR1uAefInVSE+xd45w3F0 3RpYzl/zlsoFClAgHALX4DhWj28Fmtk7fQJmzb8Zu977xP14Sj0Uo+96B5teUH7YGYrSdbtRUeCe ahufncDhW76Fsd0mdx6E/NkmmMpGQPrQE3SZ3ZrYAvuBl7Bm12jov3trt61ABxot8qM56Q6TqQya AKm4igKJKsCAKEY91/HX1/H00LlYVTbG92lPrUHRYhOOVxQgTaqX6xPhReiXT4ZG0VNqTQnmP3ge u+suda/9wGI8ZduLdfoiaNRqpOd/H6X5mQAuoW53PR5dNQdF8idVQNo+FUsq78T+faflcQPds+Qa CiSGgBrpBYtxUPqAcXAxCtIVb5qYNKADrZe+Qs6QQQFKT0POyFH4/NIVOSAaibKNW6EfdRxr8gdA 5bp7+wostQHGGgXIzbcqhDJdO23FDO0N8t3niVhzbCQWbFuBUu85Qkp0Fdtn3A6V6gZoZygfzflK 5RIFkkEg1meMZDDsQxs6cOHMp5hw9zcghSo9/nNewaWmTAy5qWs3SSfTHNQcPaN4tCbncvt4jPU7 mXly/wrNTe9izh03dhskOeCOH2Hr4RP4zJOUrxSgQBgE0pCRfSMuXJbu0Hb9J50DPsEt2YPlR2TS kJ18lD5cAZNDGqcj3b29HadN5VhoOeP7sNLUjFbl0/Ku2SLEMuEZQ9SJ1vrVGHZgP451q+8geQxR Oxzm6d1K5AoKJItA1yttsrQrztuhxuCsm/D+kb+jpbeaqgcje1gLLn/Z9Qx4FaePNWDyhJHuO0m9 5eHdloNxkx5DVf1X/oMjPY/rePvbK8UFCoRHYBDy7inCx6/9Cee7voXbjuK1zV/g0XtGQQ0nWmp/ genVp3yBj3z3dtGCaTh2+qJ7/a0FePC29/FeQ6AAy1PjYMv0pPe8SneLy/Bs9RS8v3CDYtyhZ7v0 mgZN2Qvyo7kONL65E7UtXRumTM9lCiSWAAOimPSXGpnF5Xj+4stYYznl+/ptmx21bxihn14Nu3Se Uedj5uqhMK3ZoxhE7USb/feoOnwnZhZlh1D7Qcj7wffxSdVLsHi/Vivt3gK7ZSWmVtb2HpyFUBKT UiA2AtI4uQ0ocX19fINijF1saiOVqs4vw+qxO/D4ih2wyV9ucDa+jw3zfop3pi3EzHzpcZoTV5r/ B+/8/Fms9/s6fjOOHTzu++CjHomHnvl/0bBmLSzeL0JI54NDeMM4B1Plb60FV2ZgE/Xw6fhl+QX8 +IX3rnM+aMQHlp04+vcvA2fEtRRIRAHBf7ETaK0X+w06oQEEpP8anTC8flDUt3Yq6vS1cFi3i2XF GncajBM6wx/90zjMQufJw++1XJgd7Yq8hOh0WIW5a5lmq3Aoi/Tbg39QIFEEOkWrdb0olt4DxeuF 1e99FMs2XBb1+9cLnUbxPt9fL1q9VeoUl2ueEtMMr4s/Kt+bxctEVY0ynXuHbu/hgOmuU2bXc4bO LBye+nSeFFVTNAK5y4ThmWL5vCPX3e/8UiwMVl8rPLvzlQKJKqCSKp6IgRzrTAEKUIACFKAABcIl wEdm4ZJkPhSgAAUoQAEKJKwAA6KE7TpWnAIUoAAFKECBcAkwIAqXJPOhAAUoQAEKUCBhBRgQJWzX seIUoAAFKEABCoRLgAFRuCSZDwUoQAEKUIACCSvAgChhu44VpwAFKEABClAgXAIMiMIlyXwoQAEK UIACFEhYAQZEcdt1bbAZS6BS5UFvORelWsaizCg1jcVQgAIUoAAFehFgQNQLTmw3paOgYi+shjFR rEYsyoxi81hUCghIQb0eRltbFNoqTZuxD0b9eHnC5PHQG99GbfXPovghpn/NdDbaYDHqoZWmO1Fp UVK5AzbbTuj1FjT2L2vuHRaBDjRa5kKr34I6eeqX/mbr3+cqaPUbcMA7FYwnd+nYtqCyRCsf21NR uesVVBYaYevwpJFmnWmEzWKEXisdPyqoSiphsn2IN/SLYGn0Jey9THcbXfu7jkM5L8/x6G235wO7 Z3uX1zAcswyIFH3LRQpQgALBCUjzpm3EjDVNmL7lmDxh8nGY5o7CJ4f/GlwWsU7VVoeNL5zAnXNf hcM1ybMDNYtG40+bnsX2WNeN5csC0oS6m2CbB2wpuB+Vpjo09mc+3bY6rH/saRzJmQdbp4AQX8M2 byB+W/wYjLZmr7rz/B4snH8cU3d+4j62Wzfi7qNv4HlfEgDNsG38DY7d+WOYHFJeAqJmEcb+6SUs 2K6YgPi6ZUptfBntVgNydWb5WBQQnTYY7/wIFT/6rXtuT0gf2A/AYV4Infms/yTlDjN03tr3fYEB Ud/tuu/ZYYMxT4pa5+IN2yFs8PvkaPFO7ghFOk8U3WEzIs8VHc/1i6zdhVx2TcDqmrRS1UNEL0Xq pkr3xJauSP0/YKz8375PqpEos7sA11AgNQScdux++gzK1/4bxqQrTqPp4zDb9L48I7xEcQ4WfZ77 07PegvONdTBVTpU/Ta/2m1XeqdwW4H3uPUd4PwkrPjF71ine572eg3AV9t3VaJr6A7/6qzUTsXDV YkxR9mLXc4tWD6N3ElpPHcZD/9xq150Crd6EE/Z9WOm6uzAVK2vPw+mpl1aP556T7kiNh77aBnvt ankyXn8LZfFcHghN0TyY7Jtx74UtKJgs3YVpROhxUTNsL2/Eyflb8Ky+CBrXYSvl/RNs2TsZ76y0 yIEH4Gw6jWP3Tce/aga6+dPHoGxVJZbd6OsNp92Cp5u+j4fHZPpWqjUoWrgCz0xJk9cFX6YvE3lJ rUHBE0/iCRzFR5/57jZ1SxfGFYp3chhzTdWs0gpQccoKQ64VWzbVInvBfnS6Pnkdw5YHgN3LX3bP wC2lazgLs06a6dr9L62gAg3Cf517SzsaNi/HujPTsNMV0XfCvupOHFvzE0VE70TLoZew8sTd2Nra 6Y6c9/47Rnsyl17DXqYycy5TIMUEPjuBw+3/gnGeC0aPzR+BMlMDhPQJtmEzHi94Cifu/BUcnZ1o 3VoKtMqfpKVP0csPYMSivd5Pvo5XZ2LAtpXe97nrHOH3SVj6xHzQnben/GDPQbiAjw4Pwt1jszx7 el/V+bOxz1QGjWtNM2zr18A8YgFqXOcyAeF4BbMGvI55xjq0uT61S4/2h2L7PkBvu4xDk97BN4t3 I++lE2i1/i98YDqCzzz1uukA9rU8Dlv765i0634Um0bhpdbPYZ32MUwffOatAxcCCKTn476KV2Hf WooLm+7HZOnxpvdxUoD0XVc5m3DsUC5m3TsC/hd+NdILHsb8YYfxXoP7eFQPG427Xt6EF7yBL4DM Uqw7XoECV6zTgc8++m/ccvc3oAiH3CWqx2D2vhdRpkmTIqugy+xaXbTZcWC9AbsKHsR3b/UEWMpU 0qO2Re4P/ZoymLzHrDJNaMv+LqHty9Q9CozGE6tWQl+gkQ88NdLzf4g5k05gd92lHvfqacPAab/A xsUT5YheymsqlqyajEO7j6LFtZMTV5ov4ZoyAymiX/dfik+qyo3XX75+mdfPgykoEBUBz90H1x3W DBQu3Y6lhRny2AcV8ow2ROTz5bAsZIRyBh1YjKdse7HO9elceh9/H6X50uXEfbfmgr4cpcoASz0c pfNLcdL7Pg9FMzznINddgAtlWF46XHERHQhNqQ4PnvwD6lo89yluh8H4HyjVZGL0XUUoWPJT6MZk IV07Ercrq521BMZf3gdN2m246777sGTBDIxJz4R2tFaZKqhl7x0zv3En7nElvj733MHqMt7EtU+J b6yZ3zHUJW2eb9xMLMr0x3Cf/ytM/4X5TatRWLAElvN+Z37/5Mq/nFdwqSkTQ24KdNDejJHjgUut 7neKevhD2Pj7JzHq2Brku6ymorLagtpuY42UBQRYDqFM197bZ8jj2VRQ5a/BsdE/xbZn7pOvfZ78 r2L7jNuhUt0A7Yy3PSvD8hpIJiwZp3Ym2cjK6BrRpiEjaxCamr8KkeYG3D5ag/Que6kzsnBLUzOu uNanQTPlZ5iPrbgjY4B8IZAO4FrY2zwnrC4Z9PpnMGX2mgE3UiB6Aq67n/IYBtEKq0EHg7XVe6el oaIAXd+NYa9cowV6vwtzgEfft4/HWGXA461EB1ovfYWcIb47xt5NOSMxtuYo/h5yRBfMOegLNMsX QG95XRacrZfQlDMEN3VZD9yMkWNP4+jfv+y2JVor3HfVPf3u/+rrc/kumufult/rQVQUyGdWv2PI Py/R4LkrIt1ol+7kd9ku/x2pMv09PQP5/zc2D3saVtt6lA2XH2v5J+z+l3owsoe14PKXga4JX+DM cSDbe92SAq9iPFxhksf0vI45I87A9MOVigCsA03NV3p/dBdSmQC8Y4guo/7F4Tjw5kcB6jtIHkPU Dod5evd29mMNA6J+4PW866UAJ5oOtDZfxbAsxUPYrhk4r6C5qeuZrx1nTzei63dmnK3N+HxYFgZ7 8nDdEdrnvQh0Otbi7ksm/PBXh+S7SJ6EXV77U2aXrPgnBVJG4NY7Menzv+Gk5w6JdMvedWGUTtLS oM9V7kcGQYGkISP7Rly4rBiIKu/nPH0MhyZPwDd6ieikc0FTt3Kudw66FXc/eDMs733S6wVNnZGN YRcuo1vY4/wUxw6NxIRvdA+VulWFK8IjID1CMj6J/PJa5CzYi5p1T6AgYIDdQ3HqUbin7Dxee/dc lz6XviDwBjY3TcI9eVJQfhG1lXNRbVcej5nIv+/fsWBuK043SXek0nDr3aW4zfIXNASKrzxVCLpM zw6e10zkl/0fVD/4VyxcW9PDQHJpMPYL8lOQDjS+uRO1nvejJ5sQXxkQhQgWXPLT2LFmrWLgmxTV /x7b6ifiyaJsOYsbkTXsAqwnP4MTctT/5COYs79rQARce+eXWLjhffmguIZG2w6smF+HsicL3c9v nadQPXU6Ki2nvIGT+lYtbhvQtbZhLLNr1vybAgkj0Aybcbr7a+aucTA9VLytDkbXwODp3nE83pTq fMxcPRSmNXu63IWVPvh84U0W3MIg5M+cjRzTJliUjyTaTmFP1VEUz5zgG6cxOAvDmo7jpGvsSAvs BzbgyeI52N+toOudgwZi+ENLsaThBaxQnDekcRu1bxihn7rBNd5RnV+G1TkWrFGmQQvse3bicPF0 FGXyEtKNPuwrrqGxbgv0+fPxrvTtsJp1iuEYoRQmHWflGLt5HlZ4v60m5f0S5t1fg2lry5Dv6s6v 0Nz0Ln6+5iX/r+O3ncDBA74gWD18Z57XZQAACIFJREFUOp5Z0og1KyyK90AL7LW7YNTPkt8zwZYZ qB3SMboY5Z8Z8cKhi4ESKNY14gPLzv7fsRT8F16Bdqsw5JYLc/1xYV42RQAQwDihM/xR1Ld2Ksrq FK31ZrGsWONOU7xMbLN+IF7X5QqgXJgdXwiroVgAuUJnPi7qzStEsSsvCI1uvdhff9mXV+dJUTVt tjD8ziB0Gqm8KJTpK51LFIgjgVZhNeiEwdraS52k99Y0AWhEseGI6DFl6xFhcL0/pwmD9YsA+XV5 D0vvO41OGMxW4fC81R1moZPft+73pef9Kb3H2/3y7HQcEdu854wA73NX6suKc4FGFC/bLqzW19xl 6MzCIaUJ+hwkhOh0CKtZed6YIpZV1fifq6Q025Z5zz+uNu6vl90kb+k8JbVLOledFe1Wg8gFRK7B KtoDtl95fit22TrM5a48XPv4qaT6H1+J+qpHhEb3ojji+Do8GK31Yr9BJzTycdnteiIuiJpls4XB bBYG3Ti5b6VjrUrUKK87rtp8LRzWINL1Wma78PS/8jjyNLazvkpMcR1PNeID77HmeR8pX6Vjqcd3 sye7Xl9V0lZFmMXF/gpIg/PGvILRf5ZH2fc3P+5PAQpQIBQBnoNC0WJaCngFeL/TS8EFClCAAhSg AAVSVYB3iMLZ865PZoVY+g9PpuUwO3inyKPBVwpQIMICPAdFGJjZJ7MAA6Jk7l22jQIUoAAFKECB oAT4yCwoJiaiAAUoQAEKUCCZBRgQJXPvsm0UoAAFKEABCgQlwIAoKCYmogAFKEABClAgmQUYECVz 77JtFKAABShAAQoEJcCAKCimyCZSThjom5QwMmVGs6zItIC5UiC5BaL5Ho1mWcnda8naOuXkuIrJ cCPS3GiWFbgBDIgCu0R9bZbBinYh4J0gUPr6bJ5i1mXXjMsdaLTM9c7irVLlQW85J9fV/TP+eq28 j1YP44F9qNYvgqXRNx2IZ3LCdqsBWVFvJQukAAWCEeD5IBglpomOwO3yZMm+yXCVgbRKpYL7g/w5 WPR5iuuTYoJj1zxseu9M9lr9BhyofQV6vQWN3kZ4JuKVJmi+3bs2mgsMiKKpHUpZ0uzLfzZD55n9 1zXjsjSZ3cuuCVw766swbdlvsLlsBABpbqafYM25+7DFIc/E7HgVc0c04fAB5QR9oVSAaSlAgbgR 4PkgbrqCFQHSChbhz65JjM+6rkfuD/IjUGZqgBBfob6qHMtqnnFPcCzNCThjPc5N3wyHawJkAYdp DkZ88iEOxBkmA6I46xC/6kgTOR49DYd0g8c1gasW2spatEiTwX7agDM5QyDNNe20W/D0yRlY+6Nx SPdmoEb6GD1MjpdDmHXbuzMXKECBeBPg+SDeeiSF66PG4KybcPT0/8B1ebJXY6qqEJW10iSsbfi0 /hJyhgwCcBX23VtxsnwFfjQmU+GViTGzq+AwlUGjWBvrRQZEse6B3sq/aQhycAmXv3TC2fAXWIbe h5KPP0GT04krzV9iwuh/Rho68NlHR9E+8U5o2Ju9aXIbBRJbgOeDxO6/pKq9GjcNyQYuXMaXuIqG 997HUN1ofPzJRTjxFZqbtBitlQKiC/jocAcmjrsViXB5SoQ6JtVhFFJj0v4Zoyd8ieYrX6LhvcO4 ZcYCzPlmHd5raIbj9BcYP/JmObs0DMsanBAHXEjtZ2IKUMAnwPOBz4JLMRdI047GhKZmXHF+gvd2 3YgZK+bgm5a/oOHa/+D0x7dhZE6aXMebkZXhWY55tXutAAOiXnlivfFmjBz/BU6fO4H3dnVg0rhc 3HZHK3a99xEuXbgR2QEPsq4Dr1VQ+Q1ci3WbWD4FKNA3AZ4P+ubGvSIikDMS4z8+jXOn/oJdmIBx eSNxR3sN3vtbIy4My0ZGwOii68Br5ReDIlLLkDINWOWQcmDiCAqkISMbOH7sKOpvmIx78rKQd89k 3PDxh7B9/M8YNWwggDTcOu5f8PmRv6PFVRPfwGshzsKsWwjzcw/E1XPaCIIxawoksQDPB0ncuYnX NPVgZN/SgGMf1uOGR7+HvLRRuOfRDHz8pzp8/M1RGOaKLnIwbtJVHDnZLLfPM/BaQDikLw09j+dc XwyKj+YzIIqPfuihFgMxbNRInN25Cx+XfQ95akCd9z2UfbQJK05lYshN7u5T55dhdY4Fayyn0KbM yXkFzU2+r9wrN3GZAhRINAGeDxKtx5K6vuqhGPWtT7FzRxPK7hkFNQYh754ifLT0Vzglf+EHGIT8 mbORY9oEi939kd1j4mxtRpPnjzh5ZUAUJx0RuBrSwLVMnDsEFN91m3uMkPo23HXfHcDE0dB6H8tm oaBiLeZgO+5X+X67SPvk28hauwoPabwJAxfDtRSgQAII8HyQAJ2UQlUchCE5V3Do3HjcNVoaQA2o R9+F+3JzMdH1hR+ZIr0IFVseA6oeUfxG0Xg8+VYW1j43Pa6eXvBKGeeHr/uHFCsUtZR/vEqxxr2Y ifyytTgo1nbbwhUUoEByCPB8kBz9mBytkK9FysuT9HtZDQ3dm5c+BmXr9kGs674pntbwDlGc9Ebz 0kLc4P3Fz8hVyvMLozcULoXnqW7kSmPOFKBAXwR4PuiLGveJjMBZLC3MgEoVrak7MlC49GxkmnKd XFVCCHGdNNxMAQpQgAIUoAAFklqAd4iSunvZOApQgAIUoAAFghFgQBSMEtNQgAIUoAAFKJDUAgyI krp72TgKUIACFKAABYIRYEAUjBLTUIACFKAABSiQ1AIMiJK6e9k4ClCAAhSgAAWCEWBAFIwS01CA AhSgAAUokNQCDIiSunvZOApQgAIUoAAFghFgQBSMEtNQgAIUoAAFKJDUAgyIkrp72TgKUIACFKAA BYIRYEAUjBLTUIACFKAABSiQ1AIMiJK6e9k4ClCAAhSgAAWCEfj/AbvKtQCuJ3z2AAAAAElFTkSu QmCCAA== --=_4f04cbe54118ed73363d65f02627f6d1 Content-Transfer-Encoding: base64 Content-Type: image/png; name=image002.png Content-Disposition: attachment; filename=image002.png; size=14318 iVBORw0KGgoAAAANSUhEUgAAAk8AAAEjCAYAAAArGeXSAAAgAElEQVR4Ae3dD3RU9Z338c+ExNqS UJqVlcRG+0g2pa6uT515gD5ut0xQeayydYOrPbZmFE4LeyiiPBNTtdbaFinNPCrQHKE9UINdd0vN 1C26LSIJ9mx3KSfjPjx2FbKpKyoJXa1LIbYqMPc5N5k7mZlMkplk/tx7551zcmbmzu/+/rx+v3vn O/f+5l6PYRiG+EMAAQQQQAABBBDISKAso1QkQgABBBBAAAEEEBgSIHhiICCAAAIIIIAAAlkIEDxl gUVSBBBAAAEEEECA4IkxgAACCCCAAAIIZCFA8JQFFkkRQAABBBBAAAGCJ8YAAggggAACCCCQhQDB UxZYJEUAAQQQQAABBAieGAMIIIAAAggggEAWAgRPWWCRtMQFTkcU8oUUOV3iDjTfFgKnIyH5QhEx HG3RHVSixAQInkqsw2kuAggggAACCExNgOBpan6sjQACCCCAAAIlJkDwVGIdTnMRQAABBBBAYGoC BE9T82NtlwuY80rqPR55zP8Kn1oiLfJVxF57/ApFBocEktJZ6WOP9fF5KYOKhPzDeaWk8STkJXNu Vb1VRspj/cicq1yWmcu8ilH/YpRZeLPk8VPha1GkxacKaywljA2Xb5Y0D4GiC3gMwzCKXgsqgIAT BMygZkG3/PuD8pY7ocLU0c0CZvC2oNuv/UGvGI5u7mnaZkcBjjzZsVeoEwIIIIAAAgjYVoDgybZd Q8UQQAABBBBAwI4CBE927BXqhAACCCCAAAK2FWDOk227hoohgAACCCCAgB0FOPJkx16hTggggAAC CCBgWwGCJ9t2DRVDAAEEEEAAATsKEDzZsVeoEwIIIIAAAgjYVoDgybZdQ8UQQAABBBBAwI4CBE92 7BXqhAACCCCAAAK2FSB4sm3XUDEEEEAAAQQQsKMAwZMde4U6IYAAAggggIBtBQiebNs1VMx2Aua9 7XwjN+a1Xf2oUEkJmPe288VvOl1STaexCBRdIIvgybyjdyB+F/mi15wKTE2AQGBqflNem+1pyoQ2 yoBAxkadQVUQKIBAFsFTAWpDEQgggAACCCCAgM0FCJ5s3kFUDwEEEEAAAQTsJUDwZK/+oDYIIIAA AgggYHOB8YMnc15MvUcej/lfJV/LDrX4qmKvPaq3JismpbPSxx7rRybYmvMC6ofySknjSchL5lwQ f7yM4bKt9P6ROVdFKNNV9a/wqSXSIl9FGlubD1rHVi9pzNpre3L62FaSrTWmY4952Qcl76cqfC2K tPhUYe3fEsp07Hil4gggMKaAxzAMY8x3k94wdxar1O1vV9BbmfQOLxwoYH7YLOiWf39Q3nIH1r8Y Vc6pGdtTMbowX2WaweeCbr/2B70q1OZUjDLz5Ue+CDhNYPwjT05rDfVFAAEEEEAAAQTyLEDwlGdg skcAAQQQQAABdwkQPLmrP2kNAggggAACCORZIIs5T3muCdkjYHeBnM55sntjqZ/dBZjzZPceon5u FuDIk5t7l7blXqCuWlVsNbl3JcdJCExTXfV0MRwnQccqCExRgCNPUwRkdQQQQAABBBAoLQG+tJRW f9NaBBBAAAEEEJiiAMHTFAFZHQEEEEAAAQRKS4DgqbT6m9YigAACCCCAwBQFCJ6mCMjqCCCAAAII IFBaAgRPpdXftBYBBBBAAAEEpiiQRfBk3osrMHJj3ikWzOpFFjCvWeQbuWlzkWvjjOJzasb25IxO z6yW5jWXfNaN0jNbZcqpilHmlCtNBgi4RCCL4MklLU7bjNMaCK+Ux7ojuqdW/tABDaZLO3hI4dbF sbS18rdu1/bWzxFUprNimYsEUreRegXC/5G83QTCGpBkfqjXx7clT2xbuUSB0G71DkaTTKIDEYVD AdUOpTe3p8cUiTyuQCyvpMS8QAABBGwiQPA01BHlqmnaIsN4V6933qkVP/qubtr3lA6cSN7RK3pE 4TVfVc/i7TpjGDKMQ9o6v0+PfbvfJt1JNRDIl0BsG+nvVHNzp/qNPnU0/TfVXPUlbWteqOZtL+hk R5NqJJV7g+qLpzO3E/P/oNr9L2r1mid11NqsBg9o48Mv6qKV31f/UJp+7b39Qv1803rtyFczyBcB BBDIgQDBUyJi9GXt3v4+3XBVoz7V9J/a3fNW4rtS9E29fHCelv7FebGr+s5QQ9Na3XvnrOR0vEKg BASiA3t099KH9LtVj+v7yy5W5bhtLlOl92+0+fJntGnfm5LeUe/O7Tq2+GrNrRzZDZXVXK4199yh q8bNizcRQACB4gqM7LWKWw9blB7t+2eF/3ShfDM+oIbrb9C0nT8f+ZZs1rDsHF146dPa9HDi6Ydz 1Lhhp4Le8T86bNFAKoFATgTeUf+Bdt3q3ajqB/6P7phXk+EtQs7WhZfWa+/zR3Rab+hXz52t+R+b OapGZQ3LtDt2FGvUmyxAAAEEbCBA8BTvhOP6158cVtPy/6kZ5rIZf6YrPviMdve9E0+hsgvUtHGr Ah95Qesapsljzo1q/Z7CXb3p50eNrMkzBNwjsONzWtL+By35zk3Spi/q7q6jss7EuaeRtAQBBBAY W4DgybI58bx2PvhtLf/o+2MTXGdp0bd/oh/+0yvJHwyVDWq8PqiOfnMex+vatfx8vdyxQmvCR5LT WfnyiIDbBBY+qF3ta3V9000KtgdVvaFNTx59bxKt/C8dP3l6EuuxCgIIIFBcAYKnIf+oTvTs0799 86XYRPDYJNczXbox/Lj2DU0cj+pE11d17fZDCUFSmSobFuv2267RwZffTFhe3E6ldATyKnD+Baq1 5ilV+vTF1hnavvvlDMb/O3r5YJ8WXXaBynWu5n/mQwqnfjnJa8XJHAEEEMiNAMGT6Rh9Tc/ufFfL Fl+YPHej7CP68/jE8ajePv6fevor6/XgnsTTdMd1sPuF2AdCbjqFXBBwjkCZZsy7Vgt/aH3JGKvm 72ngwDZtOHCVblt4jqSzdN51LVrb97DuCh8aOe092KuuJ0IKLH5IkZTLGoyVM8sRQACBQgsQPJkX Pmz4iJZu/baWfvh9qrcudGcur3+/Prp8q769aJbqQ8/rfTP/WNesXaJLDq5Tg3UdG/96HbzsHt3b aH4g8IeAWwVi13mqXaodO5aq1mNe5+m14cZW/pn+8sZDWvTBhqFlQ9d5iqezrvPk1Zd/Xq/W0HU6 z9rrlJ2nxm/epxv0lFbVxtJVrdbuE5fpns418lpHt9xKSrsQQMCxAuWOrXmuKl7uVbDPUDA1v7TL 5+mpRjPh9eoPdqSuwWsEXCxgXQttS5o2nq2GZTtlLLPeCqrPGLVFWW8mP5bVyNsUVIf5n/wOrxBA AAHbCljfATOs4IdUXUW8lSGW/ZPVVasqyxFg/0bluYY5NWN7ynNvFTD7aaqrnp582j/vpRejzLw3 igIQcISAxzAv/8sfAggggAACCCCAQEYCHHfIiIlECCCAAAIIIIDAsADBEyMBAQQQQAABBBDIQoDg KQsskiKAAAIIIIAAAgRPjAEEEEAAAQQQQCALAYKnLLBIigACCCCAAAIIZBE8DSoSCigUGUTNDQLm RUB9IUW4tViRepPtqUjweSnWvDCoz7rAbl5KGJ1pMcocXQuWIFCaAlkET6UJRKtzJ+Denf3w1bdr A+06MDCZG+TmzpicEEAAAQTyL0DwlH9jSnC9gHn17U2KrJLavUvU2nFAA1HXN5oGIoAAAiUrQPBU sl1Pw3MrcJZq5q1SR+9mXfFGu7yLWtURGRAxVG6VyQ0BBBCwgwDBkx16gTq4R6CyQVcGv6/erY16 Y9MSLWp9TBFO5bmnf2kJAgggIBX4VkyQl5iAOSnaL4/HM/Rf4WtRpMWnithrT701YT05nZV++NE/ 8iMFc5J7/XBeyWk8GslLMudW1VtlpDzWxyf15rbM5I4tU2XDYgU7fqzVx+6Xz7tW4aPMhUo24hUC CCDgXAHu8uvcvnNAzSvlDXbLCA5X1QxqFnT7tT/oVfLAS043ZsPKvQr2GYplN06yoPqsQsdMldsy k4uJarB3j7asu0dPz75PPZEb5a05KzkJrxBAAAEEHCuQ/Bnm2GZQcQRsIjDYqz1b1inw9GytD+3S Xm8Nh3dt0jVUAwEEEMiVAMFTriTJp8QF3tPAge/py9f9RLPXf0ORvfNUw4zCEh8TNB8BBNwqQPDk 1p6lXQUUeEe925u18LlP6cnILs3jFF0B7SkKAQQQKLwAwVPhzUu2xHJvUD1eNzb/bDUs26n+ZW5s G21CAAEEEEgVyPLEwodUXUW8lYro2Nd11arKcgQ4tq22rDjbky27ZVKVmqa66ukFnt9WjDInhcNK CLhOwGMYhuG6VtEgBBBAAAEEEEAgTwIcd8gTLNkigAACCCCAgDsFCJ7c2a+0CgEEEEAAAQTyJEDw lCdYskUAAQQQQAABdwoQPLmzX2kVAggggAACCORJgOApT7BkiwACCCCAAALuFCB4cme/0ioEEEAA AQQQyJMAwVOeYMl2tIB5Y2BfKKLTo99yxpLTEYV8IUUc2wBnMFPLzAQcvz1l1kxSIWBLgSyCp0FF QgGFIoO2bAiVylKAQCBLsFwnZ3vKtWgx8yOQKaY+ZSNQeIEsgqfCV44SEUAAAQQQQAABuwkQPNmt R6gPAggggAACCNhagODJ1t1D5RBAAAEEEEDAbgLjB0/mvJh6jzwe879KvpYdavFVxV57VG9N/k1K Z6WPPdaPTLA15wXUD+WVksaTkJfMuSD+eBnDZVvp/SNzropQpqvqX+FTS6RFvoo0tnYbpW6pT9KY tdf25PSxrSRba0zHHvOyD0reT1X4WhRp8anC2r8llOmW4Us7EEBgRCCLGwObO4tV6va3K+itHMmB Z84UMD9sFnTLvz8ob3lhmmB+QC/o9mt/0KsCFZnbhuXUjO0pt51T3NyKMbaLUWZxlSkdAfsIjH/k yT71pCYIIIAAAggggIAtBAiebNENVAIBBBBAAAEEnCJA8OSUnqKeCCCAAAIIIGALgSymnlTKG+yQ 1xbVphJTFij3KthDb07ZcdIZsD1Nms6GK5Z7g2JzsmHHUCUE8iTAkac8wZJtOoFpqqueLkcPurpq VTm6Aen6hWXOFHDB9uRMeGqNgLL4tR1aCCCAAAIIIIAAAnyHZgwggAACCCCAAAJZCBA8ZYFFUgQQ QAABBBBAgOCJMYAAAggggAACCGQhQPCUBRZJEUAAAQQQQAABgqdRYyCqwd6D6h2MjnqHBQgggAAC CCCAAMFTyhiIHn1SaxZerRVbejSY8h4vpyZg3ovLZ91MempZFWdt8952vpEbXRenEpSKwLCA47cn OhIBBwsQPCV2XvSInvzqZmnTD7TqpVatCR8Rx58SgXiOAAIIIIAAAllcYdztWMcVefB2bf7YBu26 fp4+cPkZPX/Lej160be1bO4Mtzee9iGAAAIIIIBAhgIceYpBRXvDuu+F6/TISp8qJZXVLNLdD3xU j615Qr0cfspwOJEMAQQQQAAB9wtw5CnWx2UNy/RUR2KHl6nSe4e6dycu4zkCCCCAAAIIlLoAR55K fQTQfgQQQAABBBDISoDgKSsuEiOAAAIIIIBAqQsQPJX6CKD9CCCAAAIIIJCVAMFTVlwkRgABBBBA AIFSFyB4KvURQPsRQAABBBBAICsBgqesuEiMAAIIIIAAAqUuQPBU6iOgoO2fprrq6XL0oKurVpWj G1DQDqewvAq4YHvKqw+ZI5A/AY9hGEb+sidnBBBAAAEEEEDAXQJ8h3ZXf9IaBBBAAAEEEMizAMFT noHJHgEEEEAAAQTcJUDw5K7+pDUIIIAAAgggkGcBgqc8A5M9AggggAACCLhLgODJXf1JaxBAAAEE EEAgzwIET6OABxUJBRSKDI56hwVTEzgdCckXiuj01LIp3tqnIwr5Qoo4tgHFo6Pk3As4fnvKPQk5 IlAwAYKnglFTEAKlIPCawoF6eTyelP/Fau04oIFoisHgIYVbF8fS1srful3bWz/Hl5cUJl4igIC9 BAie7NUf1AYBhwvUqanj/6qn7Ro1d74q8zJy5v+Z/m/oohe/rlsePaR4/BQ9ovCar6pn8XadGUp3 SFvn9+mxb/c73IDqI4CA2wUIntzew7QPARsIlNXM083Lm6TnXtRvrPpE39TLB+dp6V+cF7vq/Aw1 NK3VvXfOslLwiAACCNhSgODJlt1CpRBwk0BUg7279eC6n8kbmK9zraaVnaMLL31amx7erd5B63jU OWrcsFNBb6WVikcEEEDAdgIET7brEiqEgBsE3taOpefH5jJNU8O6F3ThbRv1zUbrKJOksgvUtHGr Ah95QesapsnjMec8fU/hrl7xcw03jAHagIB7BQie3Nu3tAyBIgpMH5nzdPIlfWf2Af3Dwd/q96k1 qmxQ4/VBdfSbc6Ne167l5+vljhVaEz4yMjcqdR1eI4AAAkUWIHgqcgdQPAKuF6icq6b1bfrML76u B7qOxoKiqE50fVXXbk+YQK4yVTYs1u23XaODL79J8OT6gUEDEXCuAMGTc/uOmiPgHIGyC3Td1z+r 33yxXftOmPObonr7+H/q6a+s14N7Ek/THdfB7he06LILVO6c1lFTBBAoMQGCpxLrcJqLQH4FzOs8 /Xf5Wp6OzXlaqfDA8FVFy877tFrv7tOiDy5SKPJ7TZ/5x7pm7RJdcnCdGqzrQvnX6+Bl9+jexnPy W01yRwABBKYgwJe7KeCxKgIIpAqY13nqk9GRutx8fbYalu2Uscx67+t6qtF8fr36g2lXsBLyiAAC CNhKgCNPabvjQ6quIq5MSzOlhdNUVz09dk2fKWVUvJXrqlXFVlM8f0pOEHDB9pTQGp4i4CQBj2Fe /pc/BBBAAAEEEEAAgYwE+A6dEROJEEAAAQQQQACBYQGCJ0YCAggggAACCCCQhQDBUxZYJEUAAQQQ QAABBAieGAMIIIAAAggggEAWAgRPWWCRFAEEEEAAAQQQIHhiDBRM4HQkJF8oouFLJhas2NwVdDqi kC+kiGMbkDsKciq+gOO3p+ITUgMEJi1A8DRpOlZEAAEEELCFAF9sbNENuaqEE74YEDzlqrfJBwEE EEAAAQRKQoDgSYOKhPzyWPfWqjdPy5zWQHjlyDKPX6HIYEkMCBqJAAIIIIAAAuMLcA8SVcob3KuT /o1auvNS/WhDo2aYZk1bdOb1q/SFFcfV+pNlaiDMHH8k8S4CCCCAAAIlIkBIMNTRZar8eJNWvPm3 eqL3nVjXv6O+3c/onLV/SeBUIhsDzUQAAecImPNi6q0zBhU+tURa5KvwxM4YjJwtSEpnpY891sd/ wJJyBiIp3UheMudW1VtlpDwOnbUY9nN6mYWvf7J/ha9FkRafKqx+SLC1ywjl3nbxnojqRNfX9NfP X6vO4DxVnuhS618f1A2da+StJMaMM03hiblBLuj2a3/QK0ce8jR3nAu65d8flNeRDZhC57Gq7QQc vz3lUpRtM5eaRc/LCWObqCA+TMo0Y+FNunHf43rm6An1PvG3enNFkz5O4BQX4gkCCCCAAAIIyJkH APLWcWUNun7tDN30d4/rz/ecp8/9qE5El3nTJmMEEEAAAQQcKUBskNRtZZox71otfDqk7htv0sIZ 8CTx8AIBBBBAAAEEOPI0agxUzlOwu0/BUW+wAAEEEEDAlgLlXgV7vLasGpXKXqDcG5Tdu5NDK9n3 K2tMWmCa6qqnO/tUaF21qthqJj0CWDGXAi7YnnLJQV4IFFCAX9sVEJuiEEAAAQQQQMD5AnyHdn4f 0gIEEEAAAQQQKKAAwVMBsSkKAQQQQAABBJwvQPDk/D6kBQgggAACCCBQQAGCpwJiUxQCCCCAAAII OF+A4Mn5fUgLEEAAAQQQQKCAAgRPBcQu9aLM+xX54jfidKCGef8sX0iR0w6sO1V2nYDjt6dc9gjb Zi41ySsDgSyCJ/OuxwGFIoMZZEsS2wuwsylyF7E9FbkDilA8fV4E9KQiCTiTOBz+orjbUxbBk8Od qT4CCCCAAAIIIJADAYKnHCCSBQIIIIAAAgiUjgDBU+n0NS1FAAEEEEAAgVwIGOP9neox2ubIkNL/ z2nrMU6Z64+Xbk6b0TOUyEzWZsyZKC/jpNHTtnCMMhcabT0nh2tchDLdXH8pwXa8MTGF90w/rzVm ppBP0VY1x5x3ZDxnXY/xxqxkFHN7cvrYLsY+KCOzTPs868E0vD919PY0iTaPucqY2+Z4nycyFP98 Gi9dwr5xvP6M58VnXdLnSS7NxssrcR865kDJ3RtZ3NvOnJy1St3+dgW9lbmI28ijmALmhPEF3fLv D8pbXpiKmJM1F3T7tT/oVYGKzG3DcmrG9pTbznFCbrntc8dvT7nssgy3TcxyiV7svHK7PWXbGk7b ZStGegQQQAABBBAoaQGCp5LufhqPAAIIIIAAAtkKEDxlK0Z6BBBAAAEEEChpgSymnlTKG+yQt6S5 XNT4cq+CPfRm8XqU7al49sUqmT4vlrxVbrk3KHZ7lobTH4u7PXHkyenjx1H1n6a66uly9KCrq1aV oxvgqAFDZccVcMH2NG77snyTbTNLMJJPRSCLX9tNpRjWRQABBBBAAAEE3CHAd2h39COtQAABBBBA AIECCRA8FQiaYhBAAAEEEEDAHQIET+7oR1qBAAIIIIAAAgUSIHgqEDTFIIAAAggggIA7BAieUvvR vMx/vV+hyGDqO7xGwNkCjG1n9x+1RwAB2whkETyZ95EJODCoMOvtl8fjGfqvD0V02jb8RayI+UHq CykCRuadkFMzp25PmXMVLqW1jdcrEH6tcMVmXVJu+9y8T5uP/dlwL2S4bWKW9aBlhTEEsgiexsih mIujA4qEQwrUDgdGHn+rOiL79UTgdoUHrKjAvJBWtwzD0KmeNs2cqL7mxSP7ugt08+Pc7kwnatrk 349qsHe3QgGfFm8/pOgkM2LHNUm4tKtZAUNs7Me+HHhqAwrt6VXa46YFHdtpKz16YYYfeqNXTFxi buN71N95beJCniMwSQGn7Jcn2bxSWy0n+5jRaA4Ono4rsvG7OnjRF9XRbwwFR8be2/Wxnz+i23a8 M7qlLJmcwGCv9oRuVcOKLs26bZd+umyusy9yOTkFG65lBQxr1Nz56vD4NwwZ/RvlP3i/1oSPTDrI tWFjqRICCCBgKwHHBk/R3rDuO/ZJXT93xghoWY3mrblL37wqi7vOWGub0Wm99S1+rDlP72ngQPvI kS5Prfyt29XVe8LKRRoIK2AeBQg8od5DHfG0tYF2HRh4L57OPApT76mSr2WHWnxV8dOKHs9YZcdX LdCT9zQQeUytS9bq2VmrFNm7QQFvDYFTgfQnX8xMedfeq8u3b9O+E7FjhBmNbSk6cEAdrYtjY9Ec 2+vU6v9S7CiudaSrXoEn9uvAQwHVxo521QZCCkcGEoI1c+w8pe1JeX1P/5CUJpZfhU8tkRb5Kqxt zyNPferpZOvI5yUJddui7a3LR08jOP6CwvFyF6u144AGkg6VZrAN67QGwitjZa1U+OhrinS0yj/U 3sW6u+toQlsn31OsiQACzhVwaPB0Wr/51f/TH83/EyWETsO9UDZXy3Z/R001WQZQQ6c0zCNYJ9XT dn6aHo1qMNKuW9qlVZF3Y9/0X9eu5efp+Q3rFD4aC4xqmtTR36nmvnatWPOKAkNpf6euTz2vmx7+ J1lhlnmPpb6hsprV1nNy5MiBUahThmmaGFs0/CG6RN5Nb+qKrY9rQ2Ceahw6UsZupYvfKfuwLl14 RM//+++HGznh2DaTval9D2/Ui/M36qR5BMswx/bHEpDMI1271NM2R33tj+jJ6lWKnBk+4tvffq20 c50ejByPpT9L59Z+RB+/fdfIdnLrWQrfuHkkoFPsdPqpHrV529RzKnb02Cy7LyhvwuYbPfqk1qx+ Thfe84tYfv3ae/sl+t2xtxLqZz59RzuWb9QvY2040/9Vze66Vw/vezOWLsNtWOWqadoiw3hVnc2H tfnzn1bwxYsV6n9XxsnNukJvKyabUj4vEUCgVAT4SMy4p9/SgZ2HdeM9yzWv5qzYWmWqbFista0X 6ZndLyd/G/2PP9Xq7XepcSjtDM29+hpdfuy43s64vOIkjPZu19W183XLsRWKdNyhKxtGhaexillH IhKOGFjzbuJHz5LTVPhaFGnxqcJKN+oIQ3HaTKmmwB90/FhiSGCO7SZt6B79RaTy5rv0zcSAunKu rlt+mfbtfD7+5aCs5mJ9PHE7mduoz1z+ex1/O+kwUAb0g/rXv/t7ndO6Vk0JY7Gs5nLd0fHjlLmJ 5bpq20atb5qrSkllNfP12c98TMeO/yFWTpbb8NBaM/WJe3+mvRtultdsT2WDGhsbhvLPoPIkcYpA 0tHZ0WcE4j80SkqXsu9L2J8Nn1lIeT+234vnpeT9o/WjpuHHhDMQRSjTVfUfdXQ7wXYK49PBwdNp HTv+dnLAMgWIiVc1P1ye1fKPvj/hFNvwxjHto7do63Mv6jeJmVzZqE+cZwVZiW/Y+3lZwzL9tP+X enT2VnkDD2lP4inJpKrHjhwMHaVIOGow9No6epacxpyw723r0SlrnZQjDEnZ86LAAufpqntuljY3 qsoKbv2t2t6VOvm8QrNnjr65c1nVTP1R/MuBedourFDAOs1mbifna+mk5iL+l468UKv5H5vwpx6S ytPWbQQyy214aMUL5PvYuZyuHkF057P40VlzX2aefUg+I9AX9GroYGhSupT9XsL+bPjMQsr7sf1e PC/r6Ku1P0x6tPah5rA2f8SUPq/Eo7S5LDOXeRW9/qOObifYTmE0OzR4Kte58xv14fA/qy/bL7KT xpqliz91k7Yd/kPCKbaEAd3RpJpJ522vFctq5imwYZcit52jZ1c0KvDQL1LmjdirvtQmRSD6ug7u u0CX/ckHUt4Y76V1pKk/Nr7fVX9ovt7qWK1vdFmnvcz1T6X90hI9eVy/nT1T0yVFe3+gL2w6okvj p9nM7cQ8BXb2eBUY4733a+bsPv3yJeuU4FFTx0UAABeoSURBVBjJMlpcOttwRhwkQgCBSQs4NHiS ys67Vt9cO6B1d4XVO2hFUCfU2/VDhQKfUyg+/2LSNikrnq36qz+pV7Y9kjI59oR6w3drcWtX/JRF yooTvDyhFw6+MvzT8vilF1YmXGphgtXz9vZZqvHerA27Htfnz3xX3kXmZSASJwXnrWAynopAdEAH Nn5HB5Yt18IZmW/e5unaxf67FY4faTTnLZ2raWnqMvjYen0lcSL24CE9+egrarrVNzQHMXryLR0p v0AX1cdO+Q72quuJH+of9ozxK9h3X9LBvuHZgNGBiMKhgGoDYQ0MlX2OFt62TG9ueDChbuYE8n16 IrRc12Z16Yx8bcNpkFiEAALuFjAy/jtp9LQ1G209JzNeI/8J3zX6ezqNtuaLDUmGVGMsvHObsffw 7+JFn+ppM+YMvWe+n/w/p63HODWU0mzbwlHvD6dfmNTmM/09Rmdbs1Fj5VXTbLR19hj9Z2JF9nca zdZ7c9qMnlOGkVSH2DKrgmf6/8l4cJz6W+ly/niqx2jzDtdv4rzPGCcP/8xoa77KuHPvGxMnHyOF 6eCNm4+RyM6LszKbqCFT3Z7GGLPmeHzmsDGylY6RbmiMjoztM4e3Gdc0txl/nzq2R+V1jdHc+YJx uPMuY2FsnNc0P2g8k7DNGWf6jV8+mLCNLLzT2Lb3Z8a25jmGNFLmsNC7Rv8vv2M011jb5lXGndv2 GodPWhuUmcoaf9Z2LqOmuc340V6rnYltnGM0d75qGEbiMhkj27phTLgNG68anUN1tepkPVp5T9S3 Y71v1il3+1DHb09jMU1meYbbZmZmue2nyTSHdXIokOHYyLZEj7lCZuGhObltlbr97SmTNDNbm1Q2 EzAnIS7oln9/8i+bbFZLe1Unp2ZO3J7MOn9Wmy58RB1NdfbqG0fUJrd9bk7qXdDt135rPo4jDPJU yQy3Tczy5F+C2WZ+XH8I50Oqrkr4DXEJgrmqyXXVqspyBLiq/ZNpTE7N2J4m0wXOXieXfT5NddWj J+8722cKtc9o28RsCsKsmiCQxZGnhLV4igACJSZgHjVZIl/Lvli756i5s5sjUCU2CmguAggMCxA8 MRIQQAABBBBAAIEsBDhpkwUWSRFAAAEEEEAAAYInxgACCCCAAAIIIJCFAMFTFlgkRQABBBBAAAEE CJ4YAwgggAACCCCAQBYCBE9ZYJEUAQQQQAABBBDIIngyf6ocUCgyiJobBMyLyvlCipx2Q2Oc2Aa2 Jyf22tTqTJ9PzW/qa5sXyfSFIhp/t0c/TV3aRjnk6bMui+DJRhhUpcAC5r3EdisU8GlxVvcSK3A1 i1bcaQ2EV6o20K4DA+8VrRYU7DaBE+rd85ACtTdoe+8Y9wV0W5Ozas9rCgcuL5Ebl1tjwSOPxyNP bUChPbu1PXC7De6DmlWnuSYxwZNrujJPDRns1Z7QrWpY0aVZt+3ST5fNFYMm1bpcNU2bFFkltXuX qDXxprmpSXmNwIQC1peVRq149hzdFvmBljWcPeFapZegTk3ff0Kr5PYblx9XJPQ3WvfalWrvN2Te Uc3o/75W1h3Tc2PdbLv0BkPBW8znYMHJnVLgexqIPKbWJWv17KxViuzdoIC3hsBpzO47SzXzVqmj d7OueKNd3kWt6ogMKDpmet5AII1AdECRjru0JPZlZe+Gm+WtOStNQhYNCZTVaN4d31fv1ka9sWmJ FrU+pojLjv5Ge8O676WleuCWi1UZ7/YyVc4NqKN/i5pqYrdMGwgrYB6V8tQrEP718P7bXyuPp1b+ u/doIL4ziu3bh94z01+iQGi3egdjCczTXPXm8pXxo1rm6c76obytZeapTf9wWU/s14GHAqodet+j 2kBI4RLY9xE8xQcjTyyB6MABdbQukXfTm7pi6+PaEJinGkaKxTP+Y2WDrgy6e2c+PgDvTk4g9oG2 aIk2vdGorbvW82UlY8gyVTYsVrCjS1uveFObXHX097R+86vnderyiybeB9c0qcM4pf7O/6W+zc3y Bn+li0IRnTEOaesVZ+vk783gKKrByBZ9uXO2bt/bP3wUy3hB3/9cmR5d9R1FzACq3Ktg36vqbB45 2lnuDarPSFxWKW9wl3ra5qiv/RE9Wb1KkTPDR8X626+Vdq7Tg5HjGfegExPykejEXstjnaO923V1 7XzdcmyFIh136MqGGWOUZn3ziJ2Dj33rGDof7/HHf1gw8o1ldLr6+MTNzPJS/BvR6Lw89SOT34tR ZjKStTP/sVYfu18+71qFjzIXKtmIVyMC76h3++dV67tfx1b/WB3BxWqoTL9rLsbYLnyZGe4PRgBj z2ao4co71BFZoWO3zJf3C2EdjR9tGZXYQQvKNXtmdjeAPusTX0s4WzBDDY2fHB5T0V7tvO9NBb68 KCkYK6vxa/Vnjmrngbeydqm8+S59M/ELduVcXbf8Mu3b+bxOZJ2bc1aIHe9zToWpaX4FyhqW6af9 F+uxh++VN3BEHfcsHyOAMr95dMsIjl+f4W8sEyRSZnkNfyMyNFFuxSgzWcGcs7JHW9bdo6dn36ee yI2cekkG4lWSwNlqWPYD9V/6Qz0c/CsFXl6ne1ZemTaAKsbYLnyZGe4PkgzNF+ak6m1aF/iZZj/6 S0VuduMRc/PHKV9S7dKtI61v7lR/R5Nq4kvKdb5vblJwFH8r+rbeOjZDl34gNTgv16wLZmlv9xGd bjxHmQcGFWkDu7KqmfqjY8f1tqSxvn7H6+TQJ6mCDm0G1c6lQFnNPAU27FLktnP07IrGEvk1S44E UybYM2clR66uz+Ys1Xhv1oa9u3TbrC6taLhVDx1gzlxm3Z46wX6Xi6YalOvci/9Mv/3lv8eO4pg/ TtkSO91mnkZbo85v/WVC4DSBWNl0Vc8+od8NncJLTPuOXj7Yp0WXXTB24BR9W8ePpV7k4ZSOHX97 1NzO6Mnj+u3smZqeWITLnhM8uaxDc9ec2M581+P6/Bm3/5olF2rvaeBAuwINq5lgnwvOUs2jrEbe wHrt2neTzrS7cwJ0Trs2OqADD438GtiNX1bKGpp0/6yw1oUPKekqi2mDmQl0yxp0w/3nqGPdkyMT xM15UL3/qG3PXaQb5lXHMni/Zs5+Qz0v/UbRofd3K3TrX2v5M6nBkzT42Hp9JfEXxoOH9OSjr6jp Vp9rjzqZSARPE4y1kn87aQL0Lbqr682SJxkNMDxnxdsurYq46Vvv6JaypBAC1py52AToT35NXSdc MXknt3jRQ9p+9RK164sJ83tyW4Q9cpspb/ABLdcOLUmYW1p761Oa+cA9um7o13bD15rzeCpUu3Sj diw9f/h6UGb6QFgD8YaUqdK7Ut+64W1tW/LhWJpLteon07W8/UvyxufaVWve8qU6843/oWmeaaoa +vXn9/Sj5me1tPZL8V/hSRWqX92iW6qe1E3Thuei1q76qapuCWrZXLeesBvGzPzUZhyfJ6UnYO3M F5de0zNqsTlnZaf6l2WUmEQIZCgQmwDdl2HyUktWNlfLdveoNDa7GWpoekDdxgNj9LJ1Om/LGO8n Lo6dVei+WRsSFyc9N/f5TdrQ3ZScpqNPRkdSQkkfnKBuqend8TrLI08fUnUV8ZY7ul5SXbWqshwB rmm7LRrC9mSLbihoJejzgnKPKmya6qoz+eUa/TSKzskL8vBZ5zHMy5XyhwACCCCAAAIIZCRgXk5i iXwt+2Kp56i5s1sdTXUZre2GRARPbuhF2oAAAggggAACBRPgpE3BqCkIAQQQQAABBNwgQPDkhl6k DQgggAACCCBQMAGCp4JRUxACCCCAAAIIuEGA4MkNvUgbEEAAAQQQQKBgAgRPBaOmIMcLmDcm9o3c gNjx7aEBjhYwb9jri99c29FNsVnlzV+SBeI3N7dZ5SZfnfiN1VcmXORy8tk5Zs087bezCJ5cOqAc MwJyXNE8Dagc19LF2bE9ubhzx2gafT4GTMEWl3TAWe5V8FCP2uYUjNvVBWURPLnagcYhgAACCCCA AAIZCRA8ZcREIgQQQAABBHIkYJ1Cqw3oW98KqNZziQLbI+rtul9+8350/vvVNfBevLDowC/0UOCS kfvV+Vu1vat3+EbBWeY1lOnJQwq3Lo7ld4kCod0JNwo2U8RudF47fL86j6dW/tbt6uo9Ea+TZN1P z0yzUuGjrynS0Tpcf89i3d11VPE7MkYHEt4z2/e/FWr9KwXCryXk56ynBE/O6i9qiwACCCDgdAHr FNoH9mj3ic8rcupH+tQPl2hhx0f0yMnfqueaf1PHv/xmuJWDB/TgLdulVc/ojGHIvCmIsWu56p7f pGD4iKLZ5DWUY482r/6Ojix9NJbfL3TPpS9q3dKNigya4U5Ug5F23TJ0o/N3h8szXteu5efp+Q3r FD5qBXXW/fReVWfzYW3+/KcVfPFihfrflXFys67Q2/r9UHlRndj3iO5+cb62njwTq/8XdKHT+9C8 PcuYf6d6jLY5Mm/fkvZ/TluPccpcebx0c9qMnqFEZrI2Y85EeRknjZ62hWnLkxYabT0nh6tbhDLd XP8k2zEHRIm/YY4578h4zlpjvDErGcXcnpw+touxD8rILNM+z3owDe9PvdY+eBLrl8Yq432eyFDC 59OIh7lO88hnzcgbuX2WtD9JLPOU0d+5xmjufNUwjDPG7/bea1yz7SXjTGrpZ14ytq141DhsvpFR XtZn9TVGW89/peT2B+PwthXGnXvfMAzjDWPvnSuMbYf/kJLGMM4cftRYMaourxqdzdcZd+19fXQd h3Iw27PKWHhnp3H45KhWjCoj5wuSbHKXuxkFZviX2LkZrkIy+wrkaUDZt8E5qFlOzdiectAjDssi t31uBm8ET9kNgczMcttPY9YwaX+SWGZi8GQ+XzHGwQTzoMYKo7P/VJbBU2ydpIollmkGQ3PGLrO5 0+hPWtdMv2a4HknLE16cfMnovPOqhDyvMu7ctrcwwVSSc0KdpviU03ZOP3RI/RFAAAEEXCpQrnMv /oRWbHtp5JSddepu6HGLmmrKs2z763q5fzBlndM6efwdzZ75fkmzdPGnbtK2w3+InbKLnSq0yu1o Uk3K2hO+rJyrpg274/md6X9A89/q0Ke/sU+Js6gmzMdGCQiebNQZVAUBBBBAAIFEgbL6K3TDKzv0 YDiigZEZ2BrsDat18VfVdSK+MHG1cZ4f09N3f1kPHRgYntA9NJn7Pq1+7hO6dV61pLNVf/Un9cq2 RxSOxNIM5XZCveG7tbi1K7uAJ3pI2xdfq9bwoeEJ7pLKzq3Vh6eNU0UHvEXw5IBOoooIIIAAAi4S MH8hN9enlkiLfBXWRStfVYtvSezinO9ox9LzVW9eBLXsPDV+bbX86taXP2z9+u1SrfqJdMOjX1Hj B/41s7zWhbTOLPPXPq3e/CVd0HmLppm/7Jt2lTa90ajN7TdrbuVwSFBWc6W+dvtfSN1f1ofNNOZ/ 7Wr9REv16PpGzRjqitcUDtTL4zlfS3ds1NLaitiv9+pH/4qu4lzNOvWUVlm/3pt2ldrP3KR/vHdh LC/n9a3HPO3nvGpTYwSKIGDu8BZ0y78/KG+2R8qLUF2KdLeAecHHBd1+7Q96xXDMZV+bFzNdpW5/ u4LeylxmTF7FEMjTfpsjT8XoTMp0rkBdtarYapzbf66q+TTVVU8XwzEfnfohVVcRkuZDtih55mG/ zZGnovQkhSKAAAIIIICAUwX40uLUnqPeCCCAAAIIIFAUAYKnorBTKAIIIIAAAgg4VYDgyak9R70R QAABBBBAoCgCBE9FYadQBBBAAAEEEHCqAMGTk3pu8NeKJN3V2kmVp64IIIAAAo4T4HMnbZcRPKVl seHC6BGF11wn34ptsTtf27CObq+Seb0QX0iR025vKO1zgoB5nSefeRFFJ1SWOjpTgM+dMfuN4GlM Gju98Z6OPtmmO3WX/mXVr3Xjmid1NNsr8tupOdQFAQQQsK2AeZHMQOxK37atZAEq5pLPnTx96SV4 KsAQnFoRUQ1G2vX5zXP0w42f1YKmu/Tdc/9edz/6q/h9gqaWP2sjgAACCCCQKMDnTqJGuucET+lU 7LQs2qud9x3WzY8sl9e875B5n6O7g7rksfXa2fuOnWpKXRBAAAEE3CDA586Evcj15yckKnKCsrla 9tSW5EpUzlOw+2+Tl/EKAQQQQACBXAjwuTOhIkeeJiQiAQIIIICAqwXMeTH1Hnk85n+VfC071OKr ir32qN6amJ+Uzkofe6wf+TGJOZm/fiivlDSehLxkzq3yx8sYLttK7x+Zc1WMMjPqbPvWP8m/wqeW SIt8FWlsM2pn+kTc2y69C0sRGC1g7sQWdMu/Pygvx2xH+7CkoALmB8SCbr/2B71iOOaS3gwKVqnb 366gtzKXGZNXMQTytN/myFMxOpMyEUAAAQQQQMCxAgRPju06Ko4AAggggAACxRAgeCqGOmUigAAC CCCAgGMFOFXu2K6j4ggggAACuReolDfYIW/uMybHYgiUexXsyX1vcuSpGJ1Jmc4VqKtWFVuNc/vP VTWfprrq6WI4uqpTaYxDBPi1nUM6imoigAACCCCAgD0E+NJij36gFggggAACCCDgEAGCJ4d0FNVE AAEEEEAAAXsIEDzZox+oBQIIIIAAAgg4RIDgySEdRTURQAABBBBAwB4CBE/26AdqgQACCCCAAAIO ESB4ckhHmdU072Xls25Q6aB6U1UEEEAAAWcK8LmTvt8IntK7sBSB0QLmDSZ9I3dOH52AJQgUToAP tcJZUxICqQIET6kivEYAAQQQQAABBMYRIHgaB4e3EEAAAQQQQACBVAGCp1QRXiOAAAIIIIAAAuMI EDyNg8NbCJjzSuo9HnnM/wqfWiIt8lXEXnv8CkUGh5CS0lnpY4/18Un+g4qE/MN5paTxJOQlc25V vVVGymP9yJyrXJaZy7yKUf9ilFl4s+TxU+FrUaTFpwprLCWMDbZcBBDIrwD3tsuvb05zN3fWC7r9 2h/0qjynOZNZRgJmULOgW/79QXnpgIzISJQ/AfYH+bMl5xEBxtmIReIzjjwlavAcAQQQQAABBBCY QIDgaQIg3kYAAQQQQAABBBIFCJ4SNXiOAAIIIIAAAghMIMDMjQmAeBuBuEC5V8Eeb/wlTxAopkC5 NyiGYzF7gLJLWYAjT47q/Wmqq54uOs1RnUZlEUAAAQcL8LmTrvP4tV06FZYhgAACCCCAAAJjCHAQ YwwYFiOAAAIIIIAAAukECJ7SqbAMAQQQQAABBBAYQ4DgaQwYFiOAAAIIIIAAAukECJ7SqbAMAQQQ QAABBBAYQ4DgaQwYFiOAAAIIIIAAAukECJ7SqbAMAQQQQAABBBAYQ4DgaQwYOy42b9DoC0V02o6V o04IIIAAAq4T4HMnfZcSPKV3YSkCCCCAAAIIIJBWgOApLQsLEUAAAQQQQACB9AIET+ldWIoAAggg gAACCKQXMPizscBJo6dtoSEp/f+cNqPnlFn98dItNNp6Tg638VSP0TZnorwM41RPmzFnjDLntPUY Q0VmWGYu8zKKUH/7lmnfPsdMRrbbiX3NMtwfsG0aiu+PnW423r5FSe208Ydn3qvGve3Sx5S2XGpO 3FvQ7df+oFfltqwhlUIAAQQQcJMAnzvpe5PTduldWIoAAggggAACCKQVIHhKy8JCBBBAAAEEEEAg vQDBU3oXliKAAAIIIIAAAmkFmPOUloWFCCCAAAIIIIBAegGOPKV3YSkCCCCAAAIIIJBWgOApLQsL EUAAAQQQQACB9AIET+ldWIoAAggggAACCKQVIHhKy8JCBBBAAAEEEEAgvQDBU3oXliKAAAIIIIAA AmkFCJ7SsrAQAQQQQAABBBBIL0DwlN6FpQgggAACCCCAQFoBgqe0LCxEAAEEEEAAAQTSCxA8pXdh KQIIIIAAAgggkFaA4CktCwsRQAABBBBAAIH0AgRP6V1YigACCCCAAAIIpBUgeErLwkIEEEAAAQQQ QCC9AMFTeheWIoAAAggggAACaQUIntKysBABBBBAAAEEEEgvQPCU3oWlCCCAAAIIIIBAWgGCp7Qs LEQAAQQQQAABBNILEDyld2EpAggggAACCCCQVoDgKS0LCxFAAAEEEEAAgfQC/x+tkJyrYkjHyAAA AABJRU5ErkJgggA= --=_4f04cbe54118ed73363d65f02627f6d1-- From nobody Tue Oct 30 05:13:44 2018 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 17999128D68 for ; Tue, 30 Oct 2018 05:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 BfH3XChk7fM9 for ; Tue, 30 Oct 2018 05:13:33 -0700 (PDT) Received: from smtp-out10.electric.net (smtp-out10.electric.net [185.38.180.41]) (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 4FC1C128B14 for ; Tue, 30 Oct 2018 05:13:33 -0700 (PDT) Received: from 1gHStl-0003R4-V7 by out10b.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1gHStl-0003Rh-W4 for ace@ietf.org; Tue, 30 Oct 2018 05:13:29 -0700 Received: by emcmailer; Tue, 30 Oct 2018 05:13:29 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out10b.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1gHStl-0003R4-V7 for ace@ietf.org; Tue, 30 Oct 2018 05:13:29 -0700 Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Tue, 30 Oct 2018 13:13:29 +0100 To: References: <065b01d45f4e$b8d372a0$2a7a57e0$@augustcellars.com> From: Ludwig Seitz Message-ID: <5eb071c6-1a9e-e86a-a7d1-cc0fb8cbac42@ri.se> Date: Tue, 30 Oct 2018 13:13:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) X-PolicySMART: 14510320 Archived-At: Subject: Re: [Ace] WGLC for draft-ietf-ace-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 12:13:42 -0000 On 25/10/2018 02:58, Mike Jones wrote: > IT CAN'T BE A COINCIDENCE: There's clearly a relationship between > many of the CBOR numeric values used in this this specification and > corresponding CBOR Web Token (CWT) claim identifiers, but oddly, the > relationship is currently unspecified and the goals behind it are > undefined. The spec should be augmented to make the nature and goals > of this relationship explicit. I infer that there's such a > relationship because the Mapping Parameters to CBOR in Section 5.6.5 > apparently carefully do not overlap with the values registered in the > IANA CWT Claims registry at > https://www.iana.org/assignments/cwt/cwt.xhtml. The Introspection > mappings in Section 5.7.4 apparently carefully use the same values as > CWT for the same things, but then adds additional values. And some > of these values are the same as values proposed for the CWT Claims > registry in 8.13. This has to be more than a coincidence but the > spec doesn't currently say why. For example in "5.6.5 Mapping Parameters to CBOR" there is this: "Note that we have aligned these abbreviations with the claim abbreviations defined in [RFC8392]." I can add some text to explain that this makes it easier to manage the abbreviations in code (no need to handle complex namespace issues, when you just use one abbreviation space). Would that address the "to make the nature and goals of this relationship explicit." part of your comment? > > Per my earlier reviews of the ace-authz spec, I believe that the ACE > OAuth parameters should all be registered in the CWT Claims registry > because of the possibility of them being used in signed requests in a > manner analogous to > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17. The > parameters need to be registered to avoid future claim number > conflicts. While conflicts have clearly been carefully avoided to > date, they will inevitably occur in the future unless the values are > actually registered. Please do so. > I have avoided doing this so far, since there was no precedent from OAuth on doing so (registering OAuth req/resp parameters as JWT claims) and I was trying to align with OAuth in that respect. For example draft-ietf-oauth-jwsreq-17 doesn't seem to register any of the classical OAuth req/resp parameters as JWT claims ("This specification requests no actions by IANA.") How is the position of the OAuth WG on this? > DON'T SQUAT ON NUMERIC REGISTRY VALUES: Please change all instances > of numbers to be assigned by designated experts in existing > registries from specific values to "TBD". For instance, all the > values for the CWT Claims Registry in Section 8.13 (currently 12, 16, > and 17) should be changed to TBD. Our chair, Jim Schaad has been a > vigorous advocate of not squatting in my past interactions with him > as a Designated Expert and I believe would support this request. > Likewise, the "19" in the CoAP Content-Format Registration in Section > 8.15 should become TBD. > I get your point. Any hints on how one usually do that while still providing provisory numbers for interop tests? > req_aud: Several examples use the "req_aud" parameter without > defining it. Doesn't this duplicate the "resource" parameter defined > by > https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-01? > If so, please delete this parameter and use "resource". If not, say > how it is different and why the differences are necessary. > > rs_cnf: There isn't a clear normative definition of this parameter. > It's mentioned obliquely but its purpose, syntax, and semantics > should be plainly stated (as with each other newly defined > parameter). > This is probably heritage from the document split. Note however that the framework (draft-ietf-ace-oauth-authz) defines some of these a CWT claims, while the params draft (draft-ietf-ace-oauth-params) only defines request/response parameters (which happen to have the same name, abbreviation and semantics). I'll go over those sections and see if there are artifacts left that need to be adjusted. > The proposed numbers in Figures 12 and 16 contain mismatches. For > instance, token_type is "14" in Figure 12 in Section 5.6.5 and "13" > in Figure 16 in Section 5.7.4. > Sorry for that. Errors when trying to make the alignment. > There's too much alignment for it to > be a coincidence but if you intend alignment, please say so > explicitly and fix the alignment. The proposed ongoing alignment > should also be described in the registration instructions for the > Designated Experts. "5.7.4. Mapping Introspection parameters to CBOR [...] Note that we have aligned these abbreviations with the claim abbreviations defined in [RFC8392]. " (so yes, we do already say so explicitly) I will add the requested instructions for Designated Experts (good catch!) > -- Mike > > P.S. Per my earlier reviews of this specification, in my view as a > Designated Expert for the CWT Claims registry, I believe that it's > not appropriate to use up rare single-byte identifiers for most of > the OAuth parameter encodings specified in 5.6.5. I could be > persuaded that "scope" merits one of these rare numbers, but > "profile", "error", "grant_type", "access_token", and "token_type" > probably do not, as they are application-specific and not of general > applicability. I also believe that some of the other Designated > Experts for this registry agree with me. > I would argue that the rare single-byte identifiers should be used for the parameters typically used in constrained applications. Since "error", "grant_type", "access_token", and "token_type" are all mandatory to use, they are bound to appear in constrained cases. If we made "grant_type" and "token_type" non-mandatory in ACE (as opposed to how it is in OAuth) and define defaults I'd agree to move those into the two-byte space. "profile" is arguably going to be used in less constrained scenarios where more than one profile could be supported, so I'd agree to move that to the two-byte space as well. "error" and "access_token" are used in every OAuth/ACE interaction, so I would need some really good arguments why they shouldn't have a one-byte abbreviation. Can we reach some compromise based on these observations Mike? /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 From nobody Tue Oct 30 05:20:45 2018 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 9FB7212D4EF; Tue, 30 Oct 2018 05:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 ygM_ogy4RKFL; Tue, 30 Oct 2018 05:20:39 -0700 (PDT) Received: from smtp-out10.electric.net (smtp-out10.electric.net [185.38.180.33]) (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 A6C3912D4EC; Tue, 30 Oct 2018 05:20:39 -0700 (PDT) Received: from 1gHT0d-000HPA-Vb by out10a.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1gHT0e-000HRm-Tu; Tue, 30 Oct 2018 05:20:36 -0700 Received: by emcmailer; Tue, 30 Oct 2018 05:20:36 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out10a.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1gHT0d-000HPA-Vb; Tue, 30 Oct 2018 05:20:35 -0700 Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Tue, 30 Oct 2018 13:20:35 +0100 To: Jim Schaad , CC: References: <065b01d45f4e$b8d372a0$2a7a57e0$@augustcellars.com> <028d01d46a3a$bc6414f0$352c3ed0$@augustcellars.com> <038001d46b00$767a8520$636f8f60$@augustcellars.com> From: Ludwig Seitz Message-ID: <6ed644e4-0d41-661e-c717-1dabaedbf574@ri.se> Date: Tue, 30 Oct 2018 13:20:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <038001d46b00$767a8520$636f8f60$@augustcellars.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) X-PolicySMART: 14510320 Archived-At: Subject: Re: [Ace] WGLC for draft-ietf-ace-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 12:20:44 -0000 On 23/10/2018 20:44, Jim Schaad wrote: > > >> -----Original Message----- From: Ludwig Seitz >> Sent: Tuesday, October 23, 2018 7:43 AM To: Jim Schaad >> ; draft-ietf-ace-oauth- authz@ietf.org Cc: >> ace@ietf.org Subject: Re: [Ace] WGLC for draft-ietf-ace-authz >> >> Hallo Jim, >> >> thank you for the review! Comments inline. >> >> /Ludwig >> >> On 22/10/2018 21:09, Jim Schaad wrote: > > >>> * Section 5.8.1 - What is the purpose of creating an identifier >>> for a token? Is this supposed to be used rather than the one from >>> the AS for something like shared secret TLS? Note that this is >>> an unprotected value. >>> >> AFAIK cti is not a mandatory claim of an access token, thus a RS >> might want to create an identifier for tokens that do not have a >> cti. > > Ok - so the client has this cti - what could it use it for? You might want to treat the token as a RESTful resource under /authz-info that the client can GET or DELETE using the cti as part of the URI. I admit this is never explicitly stated and would need to be worked out quite a bit (as Steffi remarked, there would need to be access control on the tokens), so I wouldn't argue against removing the comment from the draft altogether. >>> * Section 5.8.1 - If the token is "not valid" is the RS required >>> (i.e. MUST) to try introspection before returning a response if >>> the RS does introspection? The text currently says MAY. If this >>> is really MAY then the text should say that the token is always >>> successfully accepted by the RS. >>> >> I'm not sure I understand the issue. Introspection is optional in >> general, and may be required in specific use cases. If the RS >> determines that the token is not valid on its own, why would it >> want to do introspection on top of this? > > The RS has just received a token. The RS wants to validate said > token. It can do it on its own or it can do it with introspection. > If it is going to do it with introspection can it defer this > validation until first use or does it need to do it immediately so it > is not going to store an invalid token? It is possible that an RS is > going to both support some tokens and require introspection on > others. In that case it would decide the token was not valid, but > would not necessarily know if it was a legal introspection token. > I'm not convinced we need to REQUIRE a certain behavior here. I would however agree to put some text in the draft outlining these options and analyzing the resulting security implications. Would that address your comment sufficiently? /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 From nobody Tue Oct 30 05:27:43 2018 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 4720D129385 for ; Tue, 30 Oct 2018 05:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 7QX0DEBFyLxp for ; Tue, 30 Oct 2018 05:27:39 -0700 (PDT) Received: from smtp-out10.electric.net (smtp-out10.electric.net [185.38.180.39]) (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 594DA128D68 for ; Tue, 30 Oct 2018 05:27:39 -0700 (PDT) Received: from 1gHT7P-00040e-Vi by out10c.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1gHT7Q-00046W-TU for ace@ietf.org; Tue, 30 Oct 2018 05:27:36 -0700 Received: by emcmailer; Tue, 30 Oct 2018 05:27:36 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out10c.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1gHT7P-00040e-Vi for ace@ietf.org; Tue, 30 Oct 2018 05:27:35 -0700 Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Tue, 30 Oct 2018 13:27:35 +0100 To: References: <065b01d45f4e$b8d372a0$2a7a57e0$@augustcellars.com> <3B32C31E-11C3-4808-82DC-3C75C949A0E9@tzi.org> From: Ludwig Seitz Message-ID: <416e9dd0-cddf-c64c-9563-d8c99c46e849@ri.se> Date: Tue, 30 Oct 2018 13:27:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <3B32C31E-11C3-4808-82DC-3C75C949A0E9@tzi.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) X-PolicySMART: 14510320 Archived-At: Subject: Re: [Ace] WGLC for draft-ietf-ace-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 12:27:41 -0000 On 25/10/2018 07:33, Carsten Bormann wrote: > +1 for making all the CWT-like structures into real CWTs. > A discussion of what we consider to be CWT-like structures and what not would be helpful as a follow-up here. If draft-ietf-oauth-jwsreq is any indication the OAuth WG seems to consider that all requests to the AS can be passed as JWTs. I'm unsure what their position on the AS responses is. FYI my current reasoning and use of terms: If a key/value pair is part of a CWT I call it a "claim". If it is part of a request/response to the AS or RS I call it a "parameter". I've been registering (or at least trying to) claims separately from parameters, leading to several double-registrations, when certain key/value definitions are used both as claims and parameters (such as scope, cnf etc). /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 From nobody Tue Oct 30 11:52:29 2018 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 2C3E3130DCD for ; Tue, 30 Oct 2018 11:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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=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 sI8yONuESuoI for ; Tue, 30 Oct 2018 11:52:24 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640113.outbound.protection.outlook.com [40.107.64.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9E49127333 for ; Tue, 30 Oct 2018 11:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fpXQf/ojfKq7D8RBC6oTo0RLnvy+L0IMwSpubBFG2PY=; b=BSCBlku1je0yEJz1fvM3DQQXQPEc+soXZZjSjwtbSpN01pxaaS308FUdfllGcS06JDr9oVf4KtcbaNDKLHHIHhal4rXXtq7hLF4AlyTox7dH1cYevfQkHUbsQuQ2cni9Bqg5uWvc0qJR+INtvxFk44ydGvoEgQ5IubFS4t4rL/0= Received: from SN6PR00MB0301.namprd00.prod.outlook.com (52.132.117.155) by SN6PR00MB0333.namprd00.prod.outlook.com (52.132.118.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1331.0; Tue, 30 Oct 2018 18:52:21 +0000 Received: from SN6PR00MB0301.namprd00.prod.outlook.com ([fe80::a519:cc84:ebe4:5f51]) by SN6PR00MB0301.namprd00.prod.outlook.com ([fe80::a519:cc84:ebe4:5f51%10]) with mapi id 15.20.1334.000; Tue, 30 Oct 2018 18:52:21 +0000 From: Mike Jones To: Ludwig Seitz , "ace@ietf.org" Thread-Topic: [Ace] WGLC for draft-ietf-ace-authz Thread-Index: AdRfTbZXRdy06+geSTKJtOzYofxg+gMqrfqQARRiMgAADUwxsA== Date: Tue, 30 Oct 2018 18:52:21 +0000 Message-ID: References: <065b01d45f4e$b8d372a0$2a7a57e0$@augustcellars.com> <5eb071c6-1a9e-e86a-a7d1-cc0fb8cbac42@ri.se> In-Reply-To: <5eb071c6-1a9e-e86a-a7d1-cc0fb8cbac42@ri.se> 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_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-10-30T18:52:18.8805122Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:1:d9ff:cc80:74c2:9c4b] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR00MB0333; 6:1tTNj0RV6eZp6igoc4qW3lpk6okjI87jm6uNQkTgt4rubfAsrlH8VC0AFCTNCz4LoucYUZ2rrqFqFPE8l1BHA2IUyrnYIOEvjq9Ut/ndmVUVU5MsS2H9RD3Lp/aVFhzyJZfXlmxwIWgw7914xRbxFQJh7KHda79fFAAqltE8mPy0OI9y59T/e5DS1hier9GwvX4Na6HMbnp+YdLUpJeZ2YOZ/KASIUFELCiXoL0mZsVImz3H28/lKToZvcT2IQo8eTYom1JQJPPbTkGd90+hVYVzSaOOH/0wyrxu3btjLZduxWn17L9E0YCrXqbh5csiqvcsWAYHL7XWA3zm2Lu/8nxAUnMvu88atAqDATKMNsj8VoZ4hvv3Zy1g2oAtwgZe7gb2xS1+V8DR+t67r0b1+DcwI8Xqh316puB1IRNmDYVMmUHkrHNLIS9P6eZNWDk/HwpEofXqOezntw9Ld3pL8Q==; 5:tu5+1j0fWpliznAysZZrWpUH39DszJqkczkkjN8vzHGVOBbyuSm4BCdUz5Vye6uKyxOtsQbj1niAXABsgRPD+QVkGWuayrwFsyO8i/Q6obCqb4dKupe5Cec2uqws2BAymV3rcOAxjTT387zpeihwG7pqX2lfyxE7z4/maR9XDMg=; 7:3zqGW1m4N+477+4+dLhCuwHwPUMU0By6Tnds2tR2ytbqZzuXB2OXvZcBncIph+KSBmI/B4hfPaYjm+rb867NmTMJWDggo5KJZRjhiHa7lL4Pcpt7yrAKHrWzQvF2Zp3s6Bx8zTWh/vYBk1+OM9aDjQ== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 723678d4-b981-4a47-07c3-08d63e98d2e2 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7193020); SRVR:SN6PR00MB0333; x-ms-traffictypediagnostic: SN6PR00MB0333: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(8220027)(2401047)(5005006)(8121501046)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(93006095)(93001095)(3231382)(944501410)(52105095)(2018427008)(10201501046)(3002001)(6055026)(148016)(149066)(150057)(6041310)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:SN6PR00MB0333; BCL:0; PCL:0; RULEID:; SRVR:SN6PR00MB0333; x-forefront-prvs: 08417837C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(136003)(396003)(39860400002)(346002)(13464003)(189003)(199004)(6506007)(256004)(33656002)(53546011)(102836004)(76176011)(14444005)(229853002)(74316002)(25786009)(14454004)(6246003)(305945005)(2501003)(5250100002)(9686003)(6306002)(10090500001)(186003)(72206003)(7736002)(110136005)(11346002)(316002)(446003)(86362001)(486006)(7696005)(46003)(71190400001)(71200400001)(53936002)(86612001)(5660300001)(22452003)(106356001)(68736007)(8936002)(81156014)(81166006)(8676002)(10290500003)(2906002)(476003)(105586002)(478600001)(6116002)(99286004)(966005)(97736004)(55016002)(6436002)(2900100001)(8990500004); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR00MB0333; H:SN6PR00MB0301.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: jr5M/8dmJVG7fLETvTLttuc0/vHx56jdvRnRiXzqZgQ2CIUDKev/yPuIcXieWp2P6eG2YZk0Gd+KWZmHeatiH5XM/lT/d6X3qYC12SaisMqtuNeUVGxYAaT/iuEcF0p23dTGwbRenBLR8otdMtM4czxd5gTE99bFbebqGoQ+ikgXpZWMKOqNXPZb+FDTgqrwGTV1qRbgfajxbHW7czVVOStmVu51pE7QvwevQPRnpuyXRV3XLPYLPkdZv2AzWxL9ktHB+7G6ucV8wMVND+aHpqG+JaHhvj53txCs2jlqNPLp2WmlN4z40QuUN1lMiBRtOMggGbV0LQgjJcPAJ/Hndqhr+xR9A7IN9i+Q1VO0aqs= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 723678d4-b981-4a47-07c3-08d63e98d2e2 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2018 18:52:21.2042 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR00MB0333 Archived-At: Subject: Re: [Ace] WGLC for draft-ietf-ace-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 18:52:28 -0000 Thanks for your responses, Ludwig. Responding to your point about "Note that we have aligned these abbreviatio= ns with the claim abbreviations defined in [RFC8392]." The point of the al= ignment was to enable signed requests to be expressed as CWTs - just as OAu= th signed requests are expressed as JWTs. But given the high likelihood of= numeric CWT claim collisions with unregistered OAuth request number values= assigned by the spec, this won't actually work in the long term unless the= request parameters are registered as CWT claims. Collision-free alignment= without IANA registration is a fleeting situation. Please make the alignm= ent permanent by registering the needed claims. I get Jim's point that there are other ways to do signed requests. If this= working group wants to define a different signed request syntax for ACE OA= uth requests than CWTs, that's fine, but if so, please do so before this dr= aft finishes. If a different signed request format is used, I'll note that= there's no need for claim alignment with CWT [RFC8392] - in which case the= draft should probably abandon it up front. I'll note that abandoning the = current alignment is more work and would be more confusing to implementers = than simply using CWTs but multiple choices are possible. The most importa= nt thing is to pick one now. Industries such as banking are REQUIRING sign= ed requests. Since you asked about signed responses, those are also in the works for OAu= th, for the same reasons - including requirements from the banking industry= . See https://openid.net/specs/openid-financial-api-jarm.html. (Just as t= he OpenID Foundation standardized signed requests in 2014 in https://openid= .net/specs/openid-connect-core-1_0.html#JWTRequests in 2014 and then an IET= F version was created, signed responses are currently on a similar trajecto= ry.) Per your question about values in IANA registries to be assigned by designa= ted experts being TBD, the normal way of providing short-term values for in= terop purposes is to say "TBD (maybe ). For instance, you'll = see that usage at https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-p= ossession-03#section-7.1.1. I could live with "access_token" having a single-byte representation, since= as you point out, it is needed for every ACE OAuth interaction. An "error= " value is only needed when something goes wrong, so that doesn't seem like= a case that needs to be optimized for space. A two-byte "error" represent= ation will only be used when errors have occurred, so shouldn't be a proble= m. -- Mike -----Original Message----- From: Ace On Behalf Of Ludwig Seitz Sent: Tuesday, October 30, 2018 5:13 AM To: ace@ietf.org Subject: Re: [Ace] WGLC for draft-ietf-ace-authz On 25/10/2018 02:58, Mike Jones wrote: > IT CAN'T BE A COINCIDENCE: There's clearly a relationship between=20 > many of the CBOR numeric values used in this this specification and=20 > corresponding CBOR Web Token (CWT) claim identifiers, but oddly, the=20 > relationship is currently unspecified and the goals behind it are=20 > undefined. The spec should be augmented to make the nature and goals=20 > of this relationship explicit. I infer that there's such a=20 > relationship because the Mapping Parameters to CBOR in Section 5.6.5=20 > apparently carefully do not overlap with the values registered in the=20 > IANA CWT Claims registry at=20 > https://www.iana.org/assignments/cwt/cwt.xhtml. The Introspection=20 > mappings in Section 5.7.4 apparently carefully use the same values as=20 > CWT for the same things, but then adds additional values. And some of=20 > these values are the same as values proposed for the CWT Claims=20 > registry in 8.13. This has to be more than a coincidence but the spec=20 > doesn't currently say why. For example in "5.6.5 Mapping Parameters to CBOR" there is this: "Note that we have aligned these abbreviations with the claim abbreviations defined in [RFC8392]." I can add some text to explain that this makes it easier to manage the abbr= eviations in code (no need to handle complex namespace issues, when you jus= t use one abbreviation space). Would that address the "to make the nature a= nd goals of this relationship explicit." part of your comment? >=20 > Per my earlier reviews of the ace-authz spec, I believe that the ACE > OAuth parameters should all be registered in the CWT Claims registry > because of the possibility of them being used in signed requests in a > manner analogous to > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17. The > parameters need to be registered to avoid future claim number > conflicts. While conflicts have clearly been carefully avoided to > date, they will inevitably occur in the future unless the values are > actually registered. Please do so. >=20 I have avoided doing this so far, since there was no precedent from=20 OAuth on doing so (registering OAuth req/resp parameters as JWT claims)=20 and I was trying to align with OAuth in that respect. For example draft-ietf-oauth-jwsreq-17 doesn't seem to register any of=20 the classical OAuth req/resp parameters as JWT claims ("This=20 specification requests no actions by IANA.") How is the position of the OAuth WG on this? > DON'T SQUAT ON NUMERIC REGISTRY VALUES: Please change all instances > of numbers to be assigned by designated experts in existing > registries from specific values to "TBD". For instance, all the > values for the CWT Claims Registry in Section 8.13 (currently 12, 16, > and 17) should be changed to TBD. Our chair, Jim Schaad has been a > vigorous advocate of not squatting in my past interactions with him > as a Designated Expert and I believe would support this request. > Likewise, the "19" in the CoAP Content-Format Registration in Section > 8.15 should become TBD. >=20 I get your point. Any hints on how one usually do that while still providing provisory=20 numbers for interop tests? > req_aud: Several examples use the "req_aud" parameter without > defining it. Doesn't this duplicate the "resource" parameter defined > by > https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-01? > If so, please delete this parameter and use "resource". If not, say > how it is different and why the differences are necessary. >=20 > rs_cnf: There isn't a clear normative definition of this parameter. > It's mentioned obliquely but its purpose, syntax, and semantics > should be plainly stated (as with each other newly defined > parameter). >=20 This is probably heritage from the document split. Note however that the framework (draft-ietf-ace-oauth-authz) defines=20 some of these a CWT claims, while the params draft=20 (draft-ietf-ace-oauth-params) only defines request/response parameters=20 (which happen to have the same name, abbreviation and semantics). I'll go over those sections and see if there are artifacts left that=20 need to be adjusted. > The proposed numbers in Figures 12 and 16 contain mismatches. For > instance, token_type is "14" in Figure 12 in Section 5.6.5 and "13" > in Figure 16 in Section 5.7.4.=20 >=20 Sorry for that. Errors when trying to make the alignment. > There's too much alignment for it to > be a coincidence but if you intend alignment, please say so > explicitly and fix the alignment. The proposed ongoing alignment > should also be described in the registration instructions for the > Designated Experts. "5.7.4. Mapping Introspection parameters to CBOR [...] Note that we have aligned these abbreviations with the claim abbreviations defined in [RFC8392]. " (so yes, we do already say so explicitly) I will add the requested instructions for Designated Experts (good catch!) > -- Mike >=20 > P.S. Per my earlier reviews of this specification, in my view as a > Designated Expert for the CWT Claims registry, I believe that it's > not appropriate to use up rare single-byte identifiers for most of > the OAuth parameter encodings specified in 5.6.5. I could be > persuaded that "scope" merits one of these rare numbers, but > "profile", "error", "grant_type", "access_token", and "token_type" > probably do not, as they are application-specific and not of general > applicability. I also believe that some of the other Designated > Experts for this registry agree with me. >=20 I would argue that the rare single-byte identifiers should be used for=20 the parameters typically used in constrained applications. Since "error", "grant_type", "access_token", and "token_type" are all=20 mandatory to use, they are bound to appear in constrained cases. If we made "grant_type" and "token_type" non-mandatory in ACE (as=20 opposed to how it is in OAuth) and define defaults I'd agree to move=20 those into the two-byte space. "profile" is arguably going to be used in less constrained scenarios=20 where more than one profile could be supported, so I'd agree to move=20 that to the two-byte space as well. "error" and "access_token" are used in every OAuth/ACE interaction, so I=20 would need some really good arguments why they shouldn't have a one-byte=20 abbreviation. Can we reach some compromise based on these observations Mike? /Ludwig --=20 Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Wed Oct 31 02:08:35 2018 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 4052F129AB8 for ; Wed, 31 Oct 2018 02:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 OH5kRIIagRzJ for ; Wed, 31 Oct 2018 02:08:31 -0700 (PDT) Received: from smtp-out10.electric.net (smtp-out10.electric.net [185.38.180.32]) (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 B2A5D129619 for ; Wed, 31 Oct 2018 02:08:31 -0700 (PDT) Received: from 1gHmUG-0002Dn-VX by out10d.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1gHmUH-0002Gd-Te; Wed, 31 Oct 2018 02:08:29 -0700 Received: by emcmailer; Wed, 31 Oct 2018 02:08:29 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out10d.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1gHmUG-0002Dn-VX; Wed, 31 Oct 2018 02:08:28 -0700 Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Wed, 31 Oct 2018 10:08:28 +0100 To: Mike Jones , "ace@ietf.org" References: <065b01d45f4e$b8d372a0$2a7a57e0$@augustcellars.com> <5eb071c6-1a9e-e86a-a7d1-cc0fb8cbac42@ri.se> From: Ludwig Seitz Message-ID: <0f81494a-de97-791b-789b-bdbade52aa3b@ri.se> Date: Wed, 31 Oct 2018 10:08:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-1.sp.se (10.100.0.161) To sp-mail-2.sp.se (10.100.0.162) X-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-PolicySMART: 14510320 X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) Archived-At: Subject: Re: [Ace] WGLC for draft-ietf-ace-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2018 09:08:34 -0000 On 30/10/2018 19:52, Mike Jones wrote: > Thanks for your responses, Ludwig. > ... > > I could live with "access_token" having a single-byte > representation, since as you point out, it is needed for every ACE > OAuth interaction. An "error" value is only needed when something > goes wrong, so that doesn't seem like a case that needs to be > optimized for space. A two-byte "error" representation will only be > used when errors have occurred, so shouldn't be a problem. > > -- Mike > > -----Original Message----- From: Ace On Behalf Thank you for the quick and comprehensive answer Mike! I conclude the following: We are in agreement about giving "profile", "error", "token_type" and "grant_type" two-byte abbreviations in CBOR. "scope" and "access_token" will get a one-byte abbreviation aligned with the unused numbers from CWT claims. At IETF 103 I will propose the solution of registering all parameter abbreviations in the CWT claim registry in order to align abbreviations and avoid duplicate assignments. If a signed request (and response) format is needed I am all for using CWT in the context of ACE access token requests, responses and introspection requests and responses. I will take up that discussion at IETF 103. I will propose to make "token_type" and "grant_type" OPTIONAL, deviating from the OAuth 2.0 specs and defining the default token type to be "PoP" and the default grant_type to be "client_credentials". This will avoid having to send grant_type with every access token request and token_type with every successful access token response. Regards, Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 From salvador.p.f@um.es Wed Oct 31 02:12:56 2018 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 8FE13129619 for ; Wed, 31 Oct 2018 02:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 0OEbYZl0v-5U for ; Wed, 31 Oct 2018 02:12:54 -0700 (PDT) Received: from xenon42.um.es (xenon42.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 40674128D0C for ; Wed, 31 Oct 2018 02:12:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon42.um.es (Postfix) with ESMTP id 5B8CF200FF for ; Wed, 31 Oct 2018 10:12:53 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon42.um.es Received: from xenon42.um.es ([127.0.0.1]) by localhost (xenon42.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id gpdc3W74hhmW for ; Wed, 31 Oct 2018 10:12:53 +0100 (CET) Received: from macbook-pro.home (unknown [81.0.20.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: salvador.p.f@um.es) by xenon42.um.es (Postfix) with ESMTPSA id 3C2B81FE5C for ; Wed, 31 Oct 2018 10:12:53 +0100 (CET) From: =?utf-8?Q?Salvador_P=C3=A9rez?= Content-Type: multipart/alternative; boundary="Apple-Mail=_C3FAA25C-D1E2-4307-AB0C-E4CD27043238" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Message-Id: Date: Wed, 31 Oct 2018 10:12:54 +0100 To: ace@ietf.org X-Mailer: Apple Mail (2.3445.100.39) Archived-At: X-Mailman-Approved-At: Wed, 31 Oct 2018 02:42:42 -0700 Subject: [Ace] EDHOC standardization 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, 31 Oct 2018 09:17:19 -0000 --Apple-Mail=_C3FAA25C-D1E2-4307-AB0C-E4CD27043238 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello authors of EDHOC, =20 we have implemented a previous version of EDHOC = (draft-selander-ace-cose-ecdhe) and want to share some experiences. =20 Our work so far has focused on implementation and evaluation of version = -08 of EDHOC over CoAP using real IoT hardware. The obtained results = show a significant performance improvement compared to other key = establishment protocols, such as DTLS handshake (version 1.2), = especially with respect to length and number of exchanged messages. =20 We have reviewed version -10 and noted the reduction of message length. = Based on our experience, we propose that also removing the overhead due = to security parameter negotiation could be an important optimization, = and relevant in many use cases where these parameters are available = through an out-of-band process. =20 Accordingly and taking into account that EDHOC provides a basic security = functionality for any context where security needs to be enabled, we are = currently considering the application of this protocol in different IoT = deployments, such as LoRaWAN networks, OSCORE-enabled scenarios or its = integration with capabilities. We therefore would like to see the = progress of EDHOC in standardization. Kind regards, -------------------- Salvador P=C3=A9rez PhD student in "Future Internet Networks: Infrastructure and Security=E2=80= =9D Faculty of Computer Science - University of Murcia Email: salvador.p.f@um.es Skype: salva.pf --Apple-Mail=_C3FAA25C-D1E2-4307-AB0C-E4CD27043238 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hello authors of EDHOC,
 
= we have implemented a previous version of EDHOC (draft-selander-ace-cose-ecdhe) and want to share some = experiences.
 
Our work = so far has focused on implementation and evaluation of version -08 of EDHOC over CoAP using real IoT hardware. The = obtained results show a significant performance improvement compared to = other key establishment protocols, such as DTLS handshake (version 1.2), = especially with respect to length and number of exchanged = messages.
 
We have = reviewed version -10 and noted the reduction of = message length. Based on our experience, we propose that also removing = the overhead due to security parameter negotiation could be an important = optimization, and relevant in many use cases where these parameters are = available through an out-of-band process.
 
Accordingly and taking into = account that EDHOC provides a basic security functionality for any = context where security needs to be enabled, we are currently considering = the application of this protocol in different IoT deployments, such as = LoRaWAN networks, OSCORE-enabled scenarios or its integration with = capabilities. We therefore would like to see the progress of EDHOC in = standardization.

Kind regards,

--------------------
Salvador P=C3=A9rez
PhD student in "Future Internet Networks: Infrastructure = and Security=E2=80=9D
Faculty of Computer Science - = University of Murcia
Email: salvador.p.f@um.es
Skype: = salva.pf

= --Apple-Mail=_C3FAA25C-D1E2-4307-AB0C-E4CD27043238-- From nobody Wed Oct 31 04:06:15 2018 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 BC364130DF9 for ; Wed, 31 Oct 2018 04:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 7ak9Wso9VnlB for ; Wed, 31 Oct 2018 04:06:10 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A05F12D4EA for ; Wed, 31 Oct 2018 04:06:10 -0700 (PDT) Received: from Jude (65.158.186.241) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 31 Oct 2018 04:01:19 -0700 From: Jim Schaad To: 'Mike Jones' , 'Ludwig Seitz' , References: <065b01d45f4e$b8d372a0$2a7a57e0$@augustcellars.com> <5eb071c6-1a9e-e86a-a7d1-cc0fb8cbac42@ri.se> In-Reply-To: Date: Wed, 31 Oct 2018 04:05:57 -0700 Message-ID: <049901d47109$b72d9850$2588c8f0$@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: AQJ+t/TOEyNDXiHpy0JlO2vTIlTnzAMjXR8HAlXem/oCw/01UqOiuS+w Content-Language: en-us X-Originating-IP: [65.158.186.241] Archived-At: Subject: Re: [Ace] WGLC for draft-ietf-ace-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2018 11:06:14 -0000 Mike, Writing a document to do this is easy. I am not clear that there is anybody that is going to implement this. Are industries such as banking going to abandon JWT for CWT? Jim > -----Original Message----- > From: Ace On Behalf Of Mike Jones > Sent: Tuesday, October 30, 2018 11:52 AM > To: Ludwig Seitz ; ace@ietf.org > Subject: Re: [Ace] WGLC for draft-ietf-ace-authz > > Thanks for your responses, Ludwig. > > Responding to your point about "Note that we have aligned these > abbreviations with the claim abbreviations defined in [RFC8392]." The point > of the alignment was to enable signed requests to be expressed as CWTs - > just as OAuth signed requests are expressed as JWTs. But given the high > likelihood of numeric CWT claim collisions with unregistered OAuth request > number values assigned by the spec, this won't actually work in the long term > unless the request parameters are registered as CWT claims. Collision-free > alignment without IANA registration is a fleeting situation. Please make the > alignment permanent by registering the needed claims. > > I get Jim's point that there are other ways to do signed requests. If this > working group wants to define a different signed request syntax for ACE > OAuth requests than CWTs, that's fine, but if so, please do so before this > draft finishes. If a different signed request format is used, I'll note that > there's no need for claim alignment with CWT [RFC8392] - in which case the > draft should probably abandon it up front. I'll note that abandoning the > current alignment is more work and would be more confusing to > implementers than simply using CWTs but multiple choices are possible. The > most important thing is to pick one now. Industries such as banking are > REQUIRING signed requests. > > Since you asked about signed responses, those are also in the works for > OAuth, for the same reasons - including requirements from the banking > industry. See https://openid.net/specs/openid-financial-api-jarm.html. (Just > as the OpenID Foundation standardized signed requests in 2014 in > https://openid.net/specs/openid-connect-core-1_0.html#JWTRequests in > 2014 and then an IETF version was created, signed responses are currently > on a similar trajectory.) > > Per your question about values in IANA registries to be assigned by > designated experts being TBD, the normal way of providing short-term > values for interop purposes is to say "TBD (maybe ). For > instance, you'll see that usage at https://tools.ietf.org/html/draft-ietf-ace- > cwt-proof-of-possession-03#section-7.1.1. > > I could live with "access_token" having a single-byte representation, since as > you point out, it is needed for every ACE OAuth interaction. An "error" value > is only needed when something goes wrong, so that doesn't seem like a case > that needs to be optimized for space. A two-byte "error" representation will > only be used when errors have occurred, so shouldn't be a problem. > > -- Mike > > -----Original Message----- > From: Ace On Behalf Of Ludwig Seitz > Sent: Tuesday, October 30, 2018 5:13 AM > To: ace@ietf.org > Subject: Re: [Ace] WGLC for draft-ietf-ace-authz > > On 25/10/2018 02:58, Mike Jones wrote: > > IT CAN'T BE A COINCIDENCE: There's clearly a relationship between > > many of the CBOR numeric values used in this this specification and > > corresponding CBOR Web Token (CWT) claim identifiers, but oddly, the > > relationship is currently unspecified and the goals behind it are > > undefined. The spec should be augmented to make the nature and goals > > of this relationship explicit. I infer that there's such a > > relationship because the Mapping Parameters to CBOR in Section 5.6.5 > > apparently carefully do not overlap with the values registered in the > > IANA CWT Claims registry at > > https://www.iana.org/assignments/cwt/cwt.xhtml. The Introspection > > mappings in Section 5.7.4 apparently carefully use the same values as > > CWT for the same things, but then adds additional values. And some of > > these values are the same as values proposed for the CWT Claims > > registry in 8.13. This has to be more than a coincidence but the spec > > doesn't currently say why. > > For example in "5.6.5 Mapping Parameters to CBOR" there is this: > > "Note that we have aligned these abbreviations with the claim > abbreviations defined in [RFC8392]." > > I can add some text to explain that this makes it easier to manage the > abbreviations in code (no need to handle complex namespace issues, when > you just use one abbreviation space). Would that address the "to make the > nature and goals of this relationship explicit." part of your comment? > > > > > Per my earlier reviews of the ace-authz spec, I believe that the ACE > > OAuth parameters should all be registered in the CWT Claims registry > > because of the possibility of them being used in signed requests in a > > manner analogous to > > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17. The > > parameters need to be registered to avoid future claim number > > conflicts. While conflicts have clearly been carefully avoided to > > date, they will inevitably occur in the future unless the values are > > actually registered. Please do so. > > > > I have avoided doing this so far, since there was no precedent from OAuth on > doing so (registering OAuth req/resp parameters as JWT claims) and I was > trying to align with OAuth in that respect. > For example draft-ietf-oauth-jwsreq-17 doesn't seem to register any of the > classical OAuth req/resp parameters as JWT claims ("This specification > requests no actions by IANA.") > > How is the position of the OAuth WG on this? > > > DON'T SQUAT ON NUMERIC REGISTRY VALUES: Please change all > instances > > of numbers to be assigned by designated experts in existing registries > > from specific values to "TBD". For instance, all the values for the > > CWT Claims Registry in Section 8.13 (currently 12, 16, and 17) should > > be changed to TBD. Our chair, Jim Schaad has been a vigorous advocate > > of not squatting in my past interactions with him as a Designated > > Expert and I believe would support this request. > > Likewise, the "19" in the CoAP Content-Format Registration in Section > > 8.15 should become TBD. > > > I get your point. > > Any hints on how one usually do that while still providing provisory numbers > for interop tests? > > > req_aud: Several examples use the "req_aud" parameter without defining > > it. Doesn't this duplicate the "resource" parameter defined by > > https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-01? > > If so, please delete this parameter and use "resource". If not, say > > how it is different and why the differences are necessary. > > > > rs_cnf: There isn't a clear normative definition of this parameter. > > It's mentioned obliquely but its purpose, syntax, and semantics should > > be plainly stated (as with each other newly defined parameter). > > > > This is probably heritage from the document split. > Note however that the framework (draft-ietf-ace-oauth-authz) defines > some of these a CWT claims, while the params draft > (draft-ietf-ace-oauth-params) only defines request/response parameters > (which happen to have the same name, abbreviation and semantics). > > I'll go over those sections and see if there are artifacts left that > need to be adjusted. > > > > The proposed numbers in Figures 12 and 16 contain mismatches. For > > instance, token_type is "14" in Figure 12 in Section 5.6.5 and "13" > > in Figure 16 in Section 5.7.4. > > > Sorry for that. Errors when trying to make the alignment. > > > There's too much alignment for it to > > be a coincidence but if you intend alignment, please say so > > explicitly and fix the alignment. The proposed ongoing alignment > > should also be described in the registration instructions for the > > Designated Experts. > > "5.7.4. Mapping Introspection parameters to CBOR > [...] > Note that we have aligned these abbreviations with the claim > abbreviations defined in [RFC8392]. > " > > (so yes, we do already say so explicitly) > > I will add the requested instructions for Designated Experts (good catch!) > > > > -- Mike > > > > P.S. Per my earlier reviews of this specification, in my view as a > > Designated Expert for the CWT Claims registry, I believe that it's > > not appropriate to use up rare single-byte identifiers for most of > > the OAuth parameter encodings specified in 5.6.5. I could be > > persuaded that "scope" merits one of these rare numbers, but > > "profile", "error", "grant_type", "access_token", and "token_type" > > probably do not, as they are application-specific and not of general > > applicability. I also believe that some of the other Designated > > Experts for this registry agree with me. > > > > I would argue that the rare single-byte identifiers should be used for > the parameters typically used in constrained applications. > > Since "error", "grant_type", "access_token", and "token_type" are all > mandatory to use, they are bound to appear in constrained cases. > > If we made "grant_type" and "token_type" non-mandatory in ACE (as > opposed to how it is in OAuth) and define defaults I'd agree to move > those into the two-byte space. > > "profile" is arguably going to be used in less constrained scenarios > where more than one profile could be supported, so I'd agree to move > that to the two-byte space as well. > > > "error" and "access_token" are used in every OAuth/ACE interaction, so I > would need some really good arguments why they shouldn't have a one-byte > abbreviation. > > Can we reach some compromise based on these observations Mike? > > > /Ludwig > > -- > Ludwig Seitz, PhD > Security Lab, RISE > Phone +46(0)70-349 92 51 > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Wed Oct 31 04:07:24 2018 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 C00F712785F for ; Wed, 31 Oct 2018 04:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 yc5EQ0pIeOjs for ; Wed, 31 Oct 2018 04:07:18 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60D2B130DE4 for ; Wed, 31 Oct 2018 04:07:17 -0700 (PDT) Received: from Jude (65.158.186.241) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 31 Oct 2018 04:01:26 -0700 From: Jim Schaad To: 'Ludwig Seitz' , References: <065b01d45f4e$b8d372a0$2a7a57e0$@augustcellars.com> <5eb071c6-1a9e-e86a-a7d1-cc0fb8cbac42@ri.se> In-Reply-To: <5eb071c6-1a9e-e86a-a7d1-cc0fb8cbac42@ri.se> Date: Wed, 31 Oct 2018 04:05:57 -0700 Message-ID: <049c01d47109$bbaa6de0$32ff49a0$@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: AQJ+t/TOEyNDXiHpy0JlO2vTIlTnzAMjXR8HAlXem/qjuNcVYA== Content-Language: en-us X-Originating-IP: [65.158.186.241] Archived-At: Subject: Re: [Ace] WGLC for draft-ietf-ace-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2018 11:07:21 -0000 > -----Original Message----- > From: Ace On Behalf Of Ludwig Seitz > Sent: Tuesday, October 30, 2018 5:13 AM > To: ace@ietf.org > Subject: Re: [Ace] WGLC for draft-ietf-ace-authz > > On 25/10/2018 02:58, Mike Jones wrote: > > IT CAN'T BE A COINCIDENCE: There's clearly a relationship between > > many of the CBOR numeric values used in this this specification and > > corresponding CBOR Web Token (CWT) claim identifiers, but oddly, the > > relationship is currently unspecified and the goals behind it are > > undefined. The spec should be augmented to make the nature and goals > > of this relationship explicit. I infer that there's such a > > relationship because the Mapping Parameters to CBOR in Section 5.6.5 > > apparently carefully do not overlap with the values registered in the > > IANA CWT Claims registry at > > https://www.iana.org/assignments/cwt/cwt.xhtml. The Introspection > > mappings in Section 5.7.4 apparently carefully use the same values as > > CWT for the same things, but then adds additional values. And some of > > these values are the same as values proposed for the CWT Claims > > registry in 8.13. This has to be more than a coincidence but the spec > > doesn't currently say why. > > For example in "5.6.5 Mapping Parameters to CBOR" there is this: > > "Note that we have aligned these abbreviations with the claim > abbreviations defined in [RFC8392]." > > I can add some text to explain that this makes it easier to manage the > abbreviations in code (no need to handle complex namespace issues, when > you just use one abbreviation space). Would that address the "to make the > nature and goals of this relationship explicit." part of your comment? I think that this should be lost as a requirement in the document. I don't think it makes it any easier to deal with things by having the abbreviations from two different things line up to be the same. They need to be dealt with on their own in code anyway. > > > > > Per my earlier reviews of the ace-authz spec, I believe that the ACE > > OAuth parameters should all be registered in the CWT Claims registry > > because of the possibility of them being used in signed requests in a > > manner analogous to > > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17. The > > parameters need to be registered to avoid future claim number > > conflicts. While conflicts have clearly been carefully avoided to > > date, they will inevitably occur in the future unless the values are > > actually registered. Please do so. > > > > I have avoided doing this so far, since there was no precedent from > OAuth on doing so (registering OAuth req/resp parameters as JWT claims) > and I was trying to align with OAuth in that respect. > For example draft-ietf-oauth-jwsreq-17 doesn't seem to register any of > the classical OAuth req/resp parameters as JWT claims ("This > specification requests no actions by IANA.") > > How is the position of the OAuth WG on this? > > > DON'T SQUAT ON NUMERIC REGISTRY VALUES: Please change all > instances > > of numbers to be assigned by designated experts in existing > > registries from specific values to "TBD". For instance, all the > > values for the CWT Claims Registry in Section 8.13 (currently 12, 16, > > and 17) should be changed to TBD. Our chair, Jim Schaad has been a > > vigorous advocate of not squatting in my past interactions with him > > as a Designated Expert and I believe would support this request. > > Likewise, the "19" in the CoAP Content-Format Registration in Section > > 8.15 should become TBD. > > > I get your point. > > Any hints on how one usually do that while still providing provisory > numbers for interop tests? Generally this is done by assigning temp numbers from a private number space that are then changed at the time of registration. Additionally one can ask for early registrations to occur. This is done at the discretion of the chairs. > > > req_aud: Several examples use the "req_aud" parameter without > > defining it. Doesn't this duplicate the "resource" parameter defined > > by > > https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-01? > > If so, please delete this parameter and use "resource". If not, say > > how it is different and why the differences are necessary. > > > > rs_cnf: There isn't a clear normative definition of this parameter. > > It's mentioned obliquely but its purpose, syntax, and semantics > > should be plainly stated (as with each other newly defined > > parameter). > > > > This is probably heritage from the document split. > Note however that the framework (draft-ietf-ace-oauth-authz) defines > some of these a CWT claims, while the params draft > (draft-ietf-ace-oauth-params) only defines request/response parameters > (which happen to have the same name, abbreviation and semantics). > > I'll go over those sections and see if there are artifacts left that > need to be adjusted. > > > > The proposed numbers in Figures 12 and 16 contain mismatches. For > > instance, token_type is "14" in Figure 12 in Section 5.6.5 and "13" > > in Figure 16 in Section 5.7.4. > > > Sorry for that. Errors when trying to make the alignment. > > > There's too much alignment for it to > > be a coincidence but if you intend alignment, please say so > > explicitly and fix the alignment. The proposed ongoing alignment > > should also be described in the registration instructions for the > > Designated Experts. > > "5.7.4. Mapping Introspection parameters to CBOR > [...] > Note that we have aligned these abbreviations with the claim > abbreviations defined in [RFC8392]. > " > > (so yes, we do already say so explicitly) > > I will add the requested instructions for Designated Experts (good catch!) > > > > -- Mike > > > > P.S. Per my earlier reviews of this specification, in my view as a > > Designated Expert for the CWT Claims registry, I believe that it's > > not appropriate to use up rare single-byte identifiers for most of > > the OAuth parameter encodings specified in 5.6.5. I could be > > persuaded that "scope" merits one of these rare numbers, but > > "profile", "error", "grant_type", "access_token", and "token_type" > > probably do not, as they are application-specific and not of general > > applicability. I also believe that some of the other Designated > > Experts for this registry agree with me. > > > > I would argue that the rare single-byte identifiers should be used for > the parameters typically used in constrained applications. > > Since "error", "grant_type", "access_token", and "token_type" are all > mandatory to use, they are bound to appear in constrained cases. > > If we made "grant_type" and "token_type" non-mandatory in ACE (as > opposed to how it is in OAuth) and define defaults I'd agree to move > those into the two-byte space. > > "profile" is arguably going to be used in less constrained scenarios > where more than one profile could be supported, so I'd agree to move > that to the two-byte space as well. > > > "error" and "access_token" are used in every OAuth/ACE interaction, so I > would need some really good arguments why they shouldn't have a one-byte > abbreviation. > > Can we reach some compromise based on these observations Mike? > > > /Ludwig > > -- > Ludwig Seitz, PhD > Security Lab, RISE > Phone +46(0)70-349 92 51 > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Wed Oct 31 04:07:30 2018 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 B94E112785F; Wed, 31 Oct 2018 04:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 sghJJFWSUpoZ; Wed, 31 Oct 2018 04:07:19 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37101130DF7; Wed, 31 Oct 2018 04:07:18 -0700 (PDT) Received: from Jude (65.158.186.241) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 31 Oct 2018 04:01:30 -0700 From: Jim Schaad To: 'Ludwig Seitz' , CC: References: <065b01d45f4e$b8d372a0$2a7a57e0$@augustcellars.com> <028d01d46a3a$bc6414f0$352c3ed0$@augustcellars.com> In-Reply-To: Date: Wed, 31 Oct 2018 04:05:57 -0700 Message-ID: <049d01d47109$bdbafe60$3930fb20$@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: AQJ+t/TOEyNDXiHpy0JlO2vTIlTnzAJjpp42ArgWG7Kju8I5AA== Content-Language: en-us X-Originating-IP: [65.158.186.241] Archived-At: Subject: Re: [Ace] WGLC for draft-ietf-ace-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2018 11:07:22 -0000 > -----Original Message----- > From: Ludwig Seitz > Sent: Tuesday, October 30, 2018 3:20 AM > To: Jim Schaad ; draft-ietf-ace-oauth- > authz@ietf.org > Cc: ace@ietf.org > Subject: Re: [Ace] WGLC for draft-ietf-ace-authz >=20 > On 22/10/2018 21:09, Jim Schaad wrote: >=20 > > > > * Registries - I am wondering if we should think about re-writing a > > couple of the registries. As things stand it appears that the > > application/ace+cbor content type is being used in 5 or 6 places. = It > > might make more sense to have a registry for all of the CBOR > > abbreviations that are being used in a single table and have = multiple > > columns for each of the different places were the content format is > > being used. This would make it easier to keep everything constant = and can > make re-use of integer values easier to see. > > >=20 > Yes in the light of the ensuing discussion with Mike, Carsten and Olaf = it is > clear that the whole registry process needs a second (third, n-th) = go-over. >=20 > I'd very much like to have all abbreviations in a single table, = however some of > them are in the new draft-ietf-ace-oauth-params, so I'm not sure on = where > to do the table, since I'd like to have the parameters from there in = it. While it has some "goodness" to have all of the abbreviations in a = single table, in the end that single table is going to be a registry = that is maintained by IANA. This allows multiple documents to create = the abbreviations and not have any overlap. I would just leave the = items in oauth-params there and let them be registered on their own. Jim \>=20 >=20 > /Ludwig >=20 >=20 > -- > Ludwig Seitz, PhD > Security Lab, RISE > Phone +46(0)70-349 92 51 From nobody Wed Oct 31 08:43:18 2018 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 A753F130DDF for ; Wed, 31 Oct 2018 08:43:16 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...] 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, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 gdvfrGjypqSH for ; Wed, 31 Oct 2018 08:43:14 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 4BDC6130DE5 for ; Wed, 31 Oct 2018 08:43:12 -0700 (PDT) X-AuditID: 12074422-de7ff700000025ff-8c-5bd9cd8aaae9 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 87.73.09727.A8DC9DB5; Wed, 31 Oct 2018 11:43:07 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.14.7/8.9.2) with ESMTP id w9VFh5LK028906; Wed, 31 Oct 2018 11:43:05 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id w9VFh114013495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 31 Oct 2018 11:43:03 -0400 Date: Wed, 31 Oct 2018 10:43:01 -0500 From: Benjamin Kaduk To: Salvador =?iso-8859-1?Q?P=E9rez?= Cc: ace@ietf.org Message-ID: <20181031154300.GK45914@kduck.kaduk.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgleLIzCtJLcpLzFFi42IR4hRV1u0+ezPa4Pk3EYvv33qYLZpXXWV3 YPJYsuQnk8e5l20sAUxRXDYpqTmZZalF+nYJXBlPHuxhK5grUPFp4W6mBsY1vF2MnBwSAiYS vzrus4HYQgJrmCS2HQroYuQCsjcySjxe/IEdwrnLJDHl6zN2kCoWAVWJw1t+gNlsAioSDd2X mUFsEQEribPzj7B2MXJwMAsISHy4ngQSFhbQkNjYtRWsnBdoWf+VaWwgJUICFhLL9+RAhAUl Ts58wgJiMwuoS/yZd4kZYoq0xPJ/HBBheYnmrbPBFnEKWErsejEDzBYVUJbY23eIfQKj4Cwk k2YhmTQLYdIsJJMWMLKsYpRNya3SzU3MzClOTdYtTk7My0st0jXVy80s0UtNKd3ECApodhel HYwT/3kdYhTgYFTi4X2QfCNaiDWxrLgy9xCjJAeTkijvybqb0UJ8SfkplRmJxRnxRaU5qcWH GCU4mJVEeL8fBcrxpiRWVqUW5cOkpDlYlMR5J7YsjhYSSE8sSc1OTS1ILYLJynBwKEnwHjoD 1ChYlJqeWpGWmVOCkGbi4AQZzgM0/DpIDW9xQWJucWY6RP4Uo6KUOK8NSEIAJJFRmgfXC0o4 Etn7a14xigO9IszrC1LFA0xWcN2vgAYzAQ3mYr8BMrgkESEl1cCYHhAw0/rKlHz1QtG7lzfb tcgZlM48//lPv8JLowmZnPPXyl9rV9Q0d5n6b3Hv7+ApPl5bp2+rcz9Y89qz482tJ09LFRTn Jt4u8Trk5SXzsKLVW2hNdLBzDU9y+qxrfev7uKd8mix4NSv68OPJj9fsXeLNV/3q0y1GJd2n Qtc0taJvzrXcJHxRiaU4I9FQi7moOBEA2gUECBMDAAA= Archived-At: Subject: Re: [Ace] EDHOC standardization 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, 31 Oct 2018 15:43:17 -0000 Hi Salvador, On Wed, Oct 31, 2018 at 10:12:54AM +0100, Salvador Pérez wrote: > Hello authors of EDHOC, > > we have implemented a previous version of EDHOC (draft-selander-ace-cose-ecdhe) and want to share some experiences. > > Our work so far has focused on implementation and evaluation of version -08 of EDHOC over CoAP using real IoT hardware. The obtained results show a significant performance improvement compared to other key establishment protocols, such as DTLS handshake (version 1.2), especially with respect to length and number of exchanged messages. Are your results written up anywhere? It would be great to see more details of the comparison and the actual numbers. Unfortunately, I don't think that DTLS 1.2 is the best comparison -- DTLS 1.3 should be seen as the current "state of the art" for DTLS, and is expected to itself be leaner than DTLS 1.2, which might wash out some of the results you've seen here. Thanks, Ben > We have reviewed version -10 and noted the reduction of message length. Based on our experience, we propose that also removing the overhead due to security parameter negotiation could be an important optimization, and relevant in many use cases where these parameters are available through an out-of-band process. > > Accordingly and taking into account that EDHOC provides a basic security functionality for any context where security needs to be enabled, we are currently considering the application of this protocol in different IoT deployments, such as LoRaWAN networks, OSCORE-enabled scenarios or its integration with capabilities. We therefore would like to see the progress of EDHOC in standardization. > > Kind regards, > > -------------------- > Salvador Pérez > PhD student in "Future Internet Networks: Infrastructure and Security” > Faculty of Computer Science - University of Murcia > Email: salvador.p.f@um.es > Skype: salva.pf > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Wed Oct 31 09:07:57 2018 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 1E96A130DC2 for ; Wed, 31 Oct 2018 09:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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 RhsVt2_HLwJ2 for ; Wed, 31 Oct 2018 09:07:54 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640109.outbound.protection.outlook.com [40.107.64.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5FE71293FB for ; Wed, 31 Oct 2018 09:07:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=F+gKN0JiWT+06KvG/dUY05/dbe+BTMekncoKvQcYlYk=; b=YUw6+7WN9/mWkAqBL5c6hedcCxEk/wtn25xs/5/YvYCVYUhrWANWz23Vx2mgGi3WaI0PyNi304RKJjTvOGKzOhg4DSY7XOii6TIfyT/RRpESt7y6f8oIFljPFvLyMCLN9UzxGOlCR39t5xmks1PW6g6AIePPbxJr9brSfWLS808= Received: from MW2PR00MB0298.namprd00.prod.outlook.com (52.132.148.29) by MW2PR00MB0331.namprd00.prod.outlook.com (52.132.148.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1336.0; Wed, 31 Oct 2018 16:07:51 +0000 Received: from MW2PR00MB0298.namprd00.prod.outlook.com ([fe80::adfd:292e:1b8e:cbd]) by MW2PR00MB0298.namprd00.prod.outlook.com ([fe80::adfd:292e:1b8e:cbd%6]) with mapi id 15.20.1336.000; Wed, 31 Oct 2018 16:07:51 +0000 From: Mike Jones To: Ludwig Seitz , "ace@ietf.org" Thread-Topic: [Ace] WGLC for draft-ietf-ace-authz Thread-Index: AdRfTbZXRdy06+geSTKJtOzYofxg+gMqrfqQARRiMgAADUwxsAAeiGIAAA6hK8A= Date: Wed, 31 Oct 2018 16:07:51 +0000 Message-ID: References: <065b01d45f4e$b8d372a0$2a7a57e0$@augustcellars.com> <5eb071c6-1a9e-e86a-a7d1-cc0fb8cbac42@ri.se> <0f81494a-de97-791b-789b-bdbade52aa3b@ri.se> In-Reply-To: <0f81494a-de97-791b-789b-bdbade52aa3b@ri.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.47.95.50] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MW2PR00MB0331; 6:5AtTfk+2sljUdfXTdsMeu/jUAkXVNeqOAgVno7S17i0D8vdGSlVv0DAySlvdBJQ8jztH/utUwJl/IS533Z56kfl6u63YL2vL+NoTQfP40ARQT28KNYZQQxCOqPKZuijJuNdkE7tbpdHol2vtzXqY10HzyqMvW6NTE/OyEBQS1ySOz659bRSj99NglxHSS/jsCg0NIaos17r05gL3l3jmvrTOMe5xvQtR2eob1ptn/e+cPXKahXt4U8dxuHEG+VYLhtGZZnDHrnZ+sBgK1WGjuAYgph367QCHX5y8g+XeMNnLFbBZocdKHMADnbJmiAOTITW3fSfRxjY0+NTX2R4Ubnq4rs7lemTBatIenjJ/DVohCMWEib2MinMIM8KyUiW94i7HyMyyDOF2gWcROeE1aTenEFTE9BZlyV1lZPCyNSLMB/g1h7WBgeFr3LXQN8B7nWhbeTwyG3oWhiIcorxRQA==; 5:OntilyiLY6soAqoZV1LRWKazY5jberaTbK9vaHg/HvIob6POON2YABwBm6aQjVnk6mQjQiBLaQ0jtPbh4ofmY2jshRxnLzj0oanRQcTmp0Pi3hUUeYIBQlQPCIv5g24X02aTzB1qA7wPIy+56kiMpvqqxFyqmjxpJaJUvKWTK+c=; 7:U150ZmLLldtbF5/b9ehKKhBPJfAr6rkLvTUxKlTd6SPI+03nmVuol6ztfO6pGQ8tIvux6v/eKcKxO5Mxy6sMxsHYB0lckeKr8WyOHE7r/xfWYXP7wopaJ7KRYmNiBPYGjkKfPBVHCZCctgRZKxumcQ== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: c010c134-f754-4339-b27a-08d63f4b0260 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7193020); SRVR:MW2PR00MB0331; x-ms-traffictypediagnostic: MW2PR00MB0331: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(8220035)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(93006095)(93001095)(3231382)(944501410)(52105102)(2018427008)(10201501046)(3002001)(6055026)(148016)(149066)(150057)(6041310)(20161123558120)(20161123564045)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:MW2PR00MB0331; BCL:0; PCL:0; RULEID:; SRVR:MW2PR00MB0331; x-forefront-prvs: 084285FC5C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(376002)(366004)(396003)(136003)(51914003)(13464003)(199004)(189003)(478600001)(9686003)(72206003)(97736004)(55016002)(106356001)(105586002)(53936002)(10290500003)(5660300001)(8990500004)(6246003)(229853002)(2501003)(2900100001)(76176011)(110136005)(7696005)(8676002)(7736002)(99286004)(8936002)(305945005)(81156014)(81166006)(22452003)(33656002)(74316002)(14454004)(316002)(5250100002)(102836004)(93886005)(66066001)(26005)(68736007)(14444005)(53546011)(6506007)(25786009)(10090500001)(256004)(6436002)(71190400001)(486006)(186003)(86362001)(71200400001)(6116002)(3846002)(2906002)(345774005)(446003)(86612001)(11346002)(476003); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR00MB0331; H:MW2PR00MB0298.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-microsoft-antispam-message-info: dsx4EgQbtg3h8a1jt21qqPloh0JClOGrm4XI8EQKJ1vkR17FCeHSrSPBgsymWDXKPkO4f5gaHIdqDEEwNfKZUxa7c14kfNhp+94V6HmYtiztfR9JGZXGvXHooBCRbyS/iKyTIj4aMNunr4fOuJNwEU72sQ6zOZOG6sG2wM+1nMrZrMvx/8UdqgPw15kHoUEWc1GchDs4jwMRGssWv+nWcJNcTy2OrzQ0Rc47J1Kc28Tnf1SdwFjp7xTTNM3Ft490k/c71VS268HhvwmpPuFLRP7e4deQESbhnnx6I/QMp+6gpjGp0F4PAw9P0qnBBFbASy67Zouo6rHk74XeUpg2/r6uMO06i8EZgNNuy7iSND4= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM 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: c010c134-f754-4339-b27a-08d63f4b0260 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2018 16:07:51.3341 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR00MB0331 Archived-At: Subject: Re: [Ace] WGLC for draft-ietf-ace-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2018 16:07:56 -0000 VGhpcyBzb3VuZHMgbGlrZSBhIGdvb2Qgc29sdXRpb24sIEx1ZHdpZy4gIFRoYW5rcyBmb3IgdGhl IHByb2R1Y3RpdmUgY29udmVyc2F0aW9uLg0KDQoJCQkJLS0gTWlrZQ0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogTHVkd2lnIFNlaXR6IDxsdWR3aWcuc2VpdHpAcmkuc2U+IA0K U2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDMxLCAyMDE4IDI6MDggQU0NClRvOiBNaWtlIEpvbmVz IDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+OyBhY2VAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbQWNlXSBXR0xDIGZvciBkcmFmdC1pZXRmLWFjZS1hdXRoeg0KDQpPbiAzMC8xMC8yMDE4IDE5 OjUyLCBNaWtlIEpvbmVzIHdyb3RlOg0KPiBUaGFua3MgZm9yIHlvdXIgcmVzcG9uc2VzLCBMdWR3 aWcuDQo+IA0KLi4uDQo+DQo+ICBJIGNvdWxkIGxpdmUgd2l0aCAiYWNjZXNzX3Rva2VuIiBoYXZp bmcgYSBzaW5nbGUtYnl0ZSByZXByZXNlbnRhdGlvbiwgDQo+IHNpbmNlIGFzIHlvdSBwb2ludCBv dXQsIGl0IGlzIG5lZWRlZCBmb3IgZXZlcnkgQUNFIE9BdXRoIGludGVyYWN0aW9uLiAgDQo+IEFu ICJlcnJvciIgdmFsdWUgaXMgb25seSBuZWVkZWQgd2hlbiBzb21ldGhpbmcgZ29lcyB3cm9uZywg c28gdGhhdCANCj4gZG9lc24ndCBzZWVtIGxpa2UgYSBjYXNlIHRoYXQgbmVlZHMgdG8gYmUgb3B0 aW1pemVkIGZvciBzcGFjZS4gIEEgDQo+IHR3by1ieXRlICJlcnJvciIgcmVwcmVzZW50YXRpb24g d2lsbCBvbmx5IGJlIHVzZWQgd2hlbiBlcnJvcnMgaGF2ZSANCj4gb2NjdXJyZWQsIHNvIHNob3Vs ZG4ndCBiZSBhIHByb2JsZW0uDQo+IA0KPiAtLSBNaWtlDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLSBGcm9tOiBBY2UgPGFjZS1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYNCg0K DQpUaGFuayB5b3UgZm9yIHRoZSBxdWljayBhbmQgY29tcHJlaGVuc2l2ZSBhbnN3ZXIgTWlrZSEN Cg0KSSBjb25jbHVkZSB0aGUgZm9sbG93aW5nOg0KDQpXZSBhcmUgaW4gYWdyZWVtZW50IGFib3V0 IGdpdmluZyAicHJvZmlsZSIsICJlcnJvciIsICJ0b2tlbl90eXBlIiBhbmQgImdyYW50X3R5cGUi IHR3by1ieXRlIGFiYnJldmlhdGlvbnMgaW4gQ0JPUi4NCg0KInNjb3BlIiBhbmQgImFjY2Vzc190 b2tlbiIgd2lsbCBnZXQgYSBvbmUtYnl0ZSBhYmJyZXZpYXRpb24gYWxpZ25lZCB3aXRoIHRoZSB1 bnVzZWQgbnVtYmVycyBmcm9tIENXVCBjbGFpbXMuDQoNCkF0IElFVEYgMTAzIEkgd2lsbCBwcm9w b3NlIHRoZSBzb2x1dGlvbiBvZiByZWdpc3RlcmluZyBhbGwgcGFyYW1ldGVyIGFiYnJldmlhdGlv bnMgaW4gdGhlIENXVCBjbGFpbSByZWdpc3RyeSBpbiBvcmRlciB0byBhbGlnbiBhYmJyZXZpYXRp b25zIGFuZCBhdm9pZCBkdXBsaWNhdGUgYXNzaWdubWVudHMuDQoNCklmIGEgc2lnbmVkIHJlcXVl c3QgKGFuZCByZXNwb25zZSkgZm9ybWF0IGlzIG5lZWRlZCBJIGFtIGFsbCBmb3IgdXNpbmcgQ1dU IGluIHRoZSBjb250ZXh0IG9mIEFDRSBhY2Nlc3MgdG9rZW4gcmVxdWVzdHMsIHJlc3BvbnNlcyBh bmQgaW50cm9zcGVjdGlvbiByZXF1ZXN0cyBhbmQgcmVzcG9uc2VzLiBJIHdpbGwgdGFrZSB1cCB0 aGF0IGRpc2N1c3Npb24gYXQgSUVURiAxMDMuDQoNCkkgd2lsbCBwcm9wb3NlIHRvIG1ha2UgInRv a2VuX3R5cGUiIGFuZCAiZ3JhbnRfdHlwZSIgT1BUSU9OQUwsIGRldmlhdGluZyBmcm9tIHRoZSBP QXV0aCAyLjAgc3BlY3MgYW5kIGRlZmluaW5nIHRoZSBkZWZhdWx0IHRva2VuIHR5cGUgdG8gYmUg IlBvUCIgDQphbmQgdGhlIGRlZmF1bHQgZ3JhbnRfdHlwZSB0byBiZSAiY2xpZW50X2NyZWRlbnRp YWxzIi4NClRoaXMgd2lsbCBhdm9pZCBoYXZpbmcgdG8gc2VuZCBncmFudF90eXBlIHdpdGggZXZl cnkgYWNjZXNzIHRva2VuIHJlcXVlc3QgYW5kIHRva2VuX3R5cGUgd2l0aCBldmVyeSBzdWNjZXNz ZnVsIGFjY2VzcyB0b2tlbiByZXNwb25zZS4NCg0KDQpSZWdhcmRzLA0KDQpMdWR3aWcNCg0KDQot LQ0KTHVkd2lnIFNlaXR6LCBQaEQNClNlY3VyaXR5IExhYiwgUklTRQ0KUGhvbmUgKzQ2KDApNzAt MzQ5IDkyIDUxDQo= From nobody Wed Oct 31 11:27:19 2018 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 BC4FB130E5D for ; Wed, 31 Oct 2018 11:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 V2x-vZQi9bQ7 for ; Wed, 31 Oct 2018 11:27:11 -0700 (PDT) Received: from xenon41.um.es (xenon41.um.es [IPv6:2001:720:1710:601::41]) by ietfa.amsl.com (Postfix) with ESMTP id EE21F130DC9 for ; Wed, 31 Oct 2018 11:27:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon41.um.es (Postfix) with ESMTP id E9ED8205EC; Wed, 31 Oct 2018 19:27:07 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon41.um.es Received: from xenon41.um.es ([127.0.0.1]) by localhost (xenon41.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id N3Eglg0p-zxA; Wed, 31 Oct 2018 19:27:07 +0100 (CET) Received: from macbook-pro.home (static.134.20.0.81.ibercom.com [81.0.20.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: salvador.p.f@um.es) by xenon41.um.es (Postfix) with ESMTPSA id 4FB37204FA; Wed, 31 Oct 2018 19:27:07 +0100 (CET) From: =?utf-8?Q?Salvador_P=C3=A9rez?= Message-Id: <16DF6657-B39C-49C5-A584-19D0932CCB91@um.es> Content-Type: multipart/alternative; boundary="Apple-Mail=_AEAB3B1C-24B6-40D2-8FB6-0987D5A915A8" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Wed, 31 Oct 2018 19:27:08 +0100 In-Reply-To: <20181031154300.GK45914@kduck.kaduk.org> Cc: ace@ietf.org To: Benjamin Kaduk References: <20181031154300.GK45914@kduck.kaduk.org> X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [Ace] EDHOC standardization 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, 31 Oct 2018 18:27:17 -0000 --Apple-Mail=_AEAB3B1C-24B6-40D2-8FB6-0987D5A915A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Benjamin, our results are included in a paper, which is under review for = its publication. Regarding the comparison between EDHOC and DTLS, we have employed the = tinydtls library [1] since it is widely used to deploy DTLS in different = IoT scenarios. Note that, at the moment in which the paper was written, = such library did not offer support for version 1.3. Anyway, DTLS 1.3 is = essentially using the same handshake as TLS 1.3 ("DTLS 1.3 re-uses the = TLS 1.3 handshake messages and flows=E2=80=9D [2]). Moreover, authors of = EDHOC state that the message overhead of TLS 1.3 is much higher than = EDHOC ("Compared to the TLS 1.3 handshake with ECDH, the number of bytes = in EDHOC is less than 1/3 when PSK authentication is used and less than = 1/2 when RPK authentication is used, see Appendix E=E2=80=9D [3-4]). = Accordingly, we can claim that it is expected that DTLS 1.3 performs = worse than EDHOC (at least, regarding message overhead) for the type of = constrained implementations we are looking at. [1] https://projects.eclipse.org/projects/iot.tinydtls = [2] https://tools.ietf.org/html/draft-ietf-tls-dtls13-29#section-5 = [3] = https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-10#section-1 = [4] = https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-10#appendix-E.4 = Kind regards, -------------------- Salvador P=C3=A9rez PhD student in "Future Internet Networks: Infrastructure and Security=E2=80= =9D Faculty of Computer Science - University of Murcia Email: salvador.p.f@um.es Skype: salva.pf > On 31 Oct 2018, at 16:43, Benjamin Kaduk wrote: >=20 > Hi Salvador, >=20 > On Wed, Oct 31, 2018 at 10:12:54AM +0100, Salvador P=C3=A9rez wrote: >> Hello authors of EDHOC, >>=20 >> we have implemented a previous version of EDHOC = (draft-selander-ace-cose-ecdhe) and want to share some experiences. >>=20 >> Our work so far has focused on implementation and evaluation of = version -08 of EDHOC over CoAP using real IoT hardware. The obtained = results show a significant performance improvement compared to other key = establishment protocols, such as DTLS handshake (version 1.2), = especially with respect to length and number of exchanged messages. >=20 > Are your results written up anywhere? It would be great to see more > details of the comparison and the actual numbers. > Unfortunately, I don't think that DTLS 1.2 is the best comparison -- = DTLS > 1.3 should be seen as the current "state of the art" for DTLS, and is > expected to itself be leaner than DTLS 1.2, which might wash out some = of > the results you've seen here. >=20 > Thanks, >=20 > Ben >=20 >> We have reviewed version -10 and noted the reduction of message = length. Based on our experience, we propose that also removing the = overhead due to security parameter negotiation could be an important = optimization, and relevant in many use cases where these parameters are = available through an out-of-band process. >>=20 >> Accordingly and taking into account that EDHOC provides a basic = security functionality for any context where security needs to be = enabled, we are currently considering the application of this protocol = in different IoT deployments, such as LoRaWAN networks, OSCORE-enabled = scenarios or its integration with capabilities. We therefore would like = to see the progress of EDHOC in standardization. >>=20 >> Kind regards, >>=20 >> -------------------- >> Salvador P=C3=A9rez >> PhD student in "Future Internet Networks: Infrastructure and = Security=E2=80=9D >> Faculty of Computer Science - University of Murcia >> Email: salvador.p.f@um.es >> Skype: salva.pf >>=20 >=20 >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >=20 --Apple-Mail=_AEAB3B1C-24B6-40D2-8FB6-0987D5A915A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Benjamin,

= our results are included in a paper, which is under review for = its publication.

Regarding the comparison between EDHOC and DTLS, we have = employed the tinydtls library [1] since it is widely used to deploy DTLS = in different IoT scenarios. Note that, at the moment in which the paper = was written, such library did not offer support for version 1.3. Anyway, = DTLS 1.3 is essentially using the same handshake as TLS 1.3 ("DTLS 1.3 = re-uses the TLS 1.3 handshake messages and flows=E2=80=9D [2]). = Moreover, authors of EDHOC state that the message overhead of TLS 1.3 is = much higher than EDHOC ("Compared to the TLS 1.3 handshake with ECDH, = the number of bytes in EDHOC is less than 1/3 when PSK authentication is = used and less than 1/2 when RPK authentication is used, see Appendix = E=E2=80=9D [3-4]). Accordingly, we can claim that it is expected that = DTLS 1.3 performs worse than EDHOC (at least, regarding message = overhead) for the type of constrained implementations we are looking = at.

[1] https://projects.eclipse.org/projects/iot.tinydtls
[2] https://tools.ietf.org/html/draft-ietf-tls-dtls13-29#section-5<= /a>
[3] https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-10#se= ction-1
[4] https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-10#ap= pendix-E.4

Kind regards,

--------------------
Salvador P=C3=A9rez
PhD student in "Future Internet Networks: Infrastructure = and Security=E2=80=9D
Faculty of Computer Science - = University of Murcia
Email: salvador.p.f@um.es
Skype: = salva.pf

On 31 Oct 2018, at 16:43, Benjamin Kaduk <kaduk@mit.edu> = wrote:

Hi Salvador,

On Wed, Oct 31, = 2018 at 10:12:54AM +0100, Salvador P=C3=A9rez wrote:
Hello authors of = EDHOC,

we have implemented a previous = version of EDHOC (draft-selander-ace-cose-ecdhe) and want to share some = experiences.

Our work so far has focused on = implementation and evaluation of version -08 of EDHOC over CoAP using = real IoT hardware. The obtained results show a significant performance = improvement compared to other key establishment protocols, such as DTLS = handshake (version 1.2), especially with respect to length and number of = exchanged messages.

Are your = results written up anywhere?  It would be great to see more
details of the comparison and the actual numbers.
Unfortunately, I don't think that DTLS 1.2 is the best = comparison -- DTLS
1.3 should be seen as the current = "state of the art" for DTLS, and is
expected to itself be = leaner than DTLS 1.2, which might wash out some of
the = results you've seen here.

Thanks,

Ben

We have reviewed version -10 and noted the = reduction of message length. Based on our experience, we propose that = also removing the overhead due to security parameter negotiation could = be an important optimization, and relevant in many use cases where these = parameters are available through an out-of-band process.
Accordingly and taking into account that EDHOC provides a = basic security functionality for any context where security needs to be = enabled, we are currently considering the application of this protocol = in different IoT deployments, such as LoRaWAN networks, OSCORE-enabled = scenarios or its integration with capabilities. We therefore would like = to see the progress of EDHOC in standardization.

Kind regards,

--------------------
Salvador P=C3=A9rez
PhD student in "Future Internet Networks: Infrastructure and = Security=E2=80=9D
Faculty of Computer Science - University = of Murcia
Email: salvador.p.f@um.es
Skype: = salva.pf


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


= --Apple-Mail=_AEAB3B1C-24B6-40D2-8FB6-0987D5A915A8-- From nobody Wed Oct 31 11:52:36 2018 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 8F68F130E62 for ; Wed, 31 Oct 2018 11:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 (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 UpRvUrPbcYlV for ; Wed, 31 Oct 2018 11:52:24 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 0B3A1130E4B for ; Wed, 31 Oct 2018 11:52:24 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id c6-v6so10457390iob.11 for ; Wed, 31 Oct 2018 11:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=G4BYMj621WlGL/qe9jqFtsKWA52QhlJbFMtpJVY4TNM=; b=IKG/4chPJtz+aqodNU/3eDd85uPf69SBL+tFAQd93QTImR1YzSnx8i82t0Z0gJJ2rf rZZqhN64wWJgQczEtzrOFu7hGlGpOZFk+KkIToVZW+mcJKzuKyBDGRxhLiMfVAg2INAW nmW4KyEqQPo0JTdLww+/bb3xWys70XuYD1pAPw6hpADRgmFAvXGR0EKE9203Pr1xHuDW fczGxgxRYDt3qouLSa2ANuxXVWAxKl6uIK2v4aE+zaO6O8fUL+veDShBbpRpehPH5s2B HBWX/OkVmE3+uo+NYFgdXKMccMnO69W4h1H0QaK3mTpcM4Vv3g0fQ+bmrzQX9zgfRlXE Lhxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=G4BYMj621WlGL/qe9jqFtsKWA52QhlJbFMtpJVY4TNM=; b=OP+3+MG1kQi5MQ9epDAPTE94GgzRoScrsCotpsT92j7n/Gv1i6CQJFoJI+bIBXD8jc 2N7grWHU0L81JW2mEhXcU7KwPMfKUVhNk7IfIkJZH4/le6zqukgofgDO4ZpaeoehrzRB zG57YPvjIniP20kcANKB4cYAq9jwXFnD2D1IMz3HOhGpsrWSGcwNzufqEIxlzl15Bcoh vUNU20O89UZ9pL9MfxN+WO+ui//Y6SDoo5kyzqLF4CHIo748TxeFB/YTvDXsvXlOOKob eY8shXfu437ZCaFzZT3vuUTjLULg7JZQW4yHaT0LT6qvnUdLjtHYlgAOKNCFKhPU2PkX gS3w== X-Gm-Message-State: AGRZ1gJS0UxogIBBo26YWW4fWUnY+XUaT7FD16sH4iIRojInlKodmC7q 7CgSc4Ln6haV5V9lvCQ0cEbfBTId X-Google-Smtp-Source: AJdET5f1uCn39+xrQNaI7AHQ5pC2bqIsuU8l3reC0YJKr3TX3DsLoyS2A7YnwGrkRG6C8x9ZiuXWRQ== X-Received: by 2002:a6b:2d7:: with SMTP id 206-v6mr2813363ioc.297.1541011943010; Wed, 31 Oct 2018 11:52:23 -0700 (PDT) Received: from ?IPv6:2607:fea8:69f:f5eb:fc5f:12b:d173:619a? ([2607:fea8:69f:f5eb:fc5f:12b:d173:619a]) by smtp.gmail.com with ESMTPSA id f18-v6sm7791072ioc.69.2018.10.31.11.52.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 Oct 2018 11:52:22 -0700 (PDT) To: =?UTF-8?Q?Salvador_P=c3=a9rez?= , Benjamin Kaduk Cc: ace@ietf.org References: <20181031154300.GK45914@kduck.kaduk.org> <16DF6657-B39C-49C5-A584-19D0932CCB91@um.es> From: Rene Struik Message-ID: <3a7159e4-8c22-977d-fe75-bf3b2d33e7b1@gmail.com> Date: Wed, 31 Oct 2018 14:52:21 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <16DF6657-B39C-49C5-A584-19D0932CCB91@um.es> Content-Type: multipart/alternative; boundary="------------727811DAE4EE40A92AF5A786" Content-Language: en-US Archived-At: Subject: Re: [Ace] EDHOC standardization 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, 31 Oct 2018 18:52:34 -0000 This is a multi-part message in MIME format. --------------727811DAE4EE40A92AF5A786 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Salvador: It would be interesting to explore what the impact is of lossless compression (with side information, in terms of maintained state by either protocol party) on sizes of message flows. This could shed some light on the question as to how much, e.g., TLS1.3 message flows (or any other flows) can be squeezed and un-squeezed "over the wire", thereby allowing a comparison of the degree to which performance metrics are mainly due to formatting schemes, such as [1]. I can imagine a breakdown as to how presumably more favorable average compression ratio contribute to the mix vs. different crypto schemes and security attributes. This would be a useful exercise. Rene [1] RFC 8152 - CBOR Object Signing and Encryption (COSE)(July 2017) On 10/31/2018 2:27 PM, Salvador Pérez wrote: > Hi Benjamin, > > our results are included in a paper, which is under review for its > publication. > > Regarding the comparison between EDHOC and DTLS, we have employed the > tinydtls library [1] since it is widely used to deploy DTLS in > different IoT scenarios. Note that, at the moment in which the paper > was written, such library did not offer support for version 1.3. > Anyway, DTLS 1.3 is essentially using the same handshake as TLS 1.3 > ("DTLS 1.3 re-uses the TLS 1.3 handshake messages and flows” [2]). > Moreover, authors of EDHOC state that the message overhead of TLS 1.3 > is much higher than EDHOC ("Compared to the TLS 1.3 handshake with > ECDH, the number of bytes in EDHOC is less than 1/3 when PSK > authentication is used and less than 1/2 when RPK authentication is > used, see Appendix E” [3-4]). Accordingly, we can claim that it is > expected that DTLS 1.3 performs worse than EDHOC (at least, regarding > message overhead) for the type of constrained implementations we are > looking at. > > [1] https://projects.eclipse.org/projects/iot.tinydtls > [2] https://tools.ietf.org/html/draft-ietf-tls-dtls13-29#section-5 > [3] https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-10#section-1 > [4] > https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-10#appendix-E.4 > > Kind regards, > > -------------------- > Salvador Pérez > PhD student in "Future Internet Networks: Infrastructure and Security” > Faculty of Computer Science - University of Murcia > Email: salvador.p.f@um.es > Skype: salva.pf > >> On 31 Oct 2018, at 16:43, Benjamin Kaduk > > wrote: >> >> Hi Salvador, >> >> On Wed, Oct 31, 2018 at 10:12:54AM +0100, Salvador Pérez wrote: >>> Hello authors of EDHOC, >>> >>> we have implemented a previous version of EDHOC >>> (draft-selander-ace-cose-ecdhe) and want to share some experiences. >>> >>> Our work so far has focused on implementation and evaluation of >>> version -08 of EDHOC over CoAP using real IoT hardware. The obtained >>> results show a significant performance improvement compared to other >>> key establishment protocols, such as DTLS handshake (version 1.2), >>> especially with respect to length and number of exchanged messages. >> >> Are your results written up anywhere?  It would be great to see more >> details of the comparison and the actual numbers. >> Unfortunately, I don't think that DTLS 1.2 is the best comparison -- DTLS >> 1.3 should be seen as the current "state of the art" for DTLS, and is >> expected to itself be leaner than DTLS 1.2, which might wash out some of >> the results you've seen here. >> >> Thanks, >> >> Ben >> >>> We have reviewed version -10 and noted the reduction of message >>> length. Based on our experience, we propose that also removing the >>> overhead due to security parameter negotiation could be an important >>> optimization, and relevant in many use cases where these parameters >>> are available through an out-of-band process. >>> >>> Accordingly and taking into account that EDHOC provides a basic >>> security functionality for any context where security needs to be >>> enabled, we are currently considering the application of this >>> protocol in different IoT deployments, such as LoRaWAN networks, >>> OSCORE-enabled scenarios or its integration with capabilities. We >>> therefore would like to see the progress of EDHOC in standardization. >>> >>> Kind regards, >>> >>> -------------------- >>> Salvador Pérez >>> PhD student in "Future Internet Networks: Infrastructure and Security” >>> Faculty of Computer Science - University of Murcia >>> Email: salvador.p.f@um.es >>> Skype: salva.pf >>> >> >>> _______________________________________________ >>> Ace mailing list >>> Ace@ietf.org >>> https://www.ietf.org/mailman/listinfo/ace >> > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------727811DAE4EE40A92AF5A786 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Salvador:

It would be interesting to explore what the impact is of lossless compression (with side information, in terms of maintained state by either protocol party) on sizes of message flows.
This could shed some light on the question as to how much, e.g., TLS1.3 message flows (or any other flows) can be squeezed and un-squeezed "over the wire", thereby allowing a comparison of the degree to which performance metrics are mainly due to formatting schemes, such as [1]. I can imagine a breakdown as to how presumably more favorable average compression ratio contribute to the mix vs. different crypto schemes and security attributes. This would be a useful exercise.

Rene

[1] RFC 8152 - CBOR Object Signing and Encryption (COSE)(July 2017)


On 10/31/2018 2:27 PM, Salvador Pérez wrote:
Hi Benjamin,

our results are included in a paper, which is under review for its publication.

Regarding the comparison between EDHOC and DTLS, we have employed the tinydtls library [1] since it is widely used to deploy DTLS in different IoT scenarios. Note that, at the moment in which the paper was written, such library did not offer support for version 1.3. Anyway, DTLS 1.3 is essentially using the same handshake as TLS 1.3 ("DTLS 1.3 re-uses the TLS 1.3 handshake messages and flows” [2]). Moreover, authors of EDHOC state that the message overhead of TLS 1.3 is much higher than EDHOC ("Compared to the TLS 1.3 handshake with ECDH, the number of bytes in EDHOC is less than 1/3 when PSK authentication is used and less than 1/2 when RPK authentication is used, see Appendix E” [3-4]). Accordingly, we can claim that it is expected that DTLS 1.3 performs worse than EDHOC (at least, regarding message overhead) for the type of constrained implementations we are looking at.


Kind regards,

--------------------
Salvador Pérez
PhD student in "Future Internet Networks: Infrastructure and Security”
Faculty of Computer Science - University of Murcia
Email: salvador.p.f@um.es
Skype: salva.pf

On 31 Oct 2018, at 16:43, Benjamin Kaduk <kaduk@mit.edu> wrote:

Hi Salvador,

On Wed, Oct 31, 2018 at 10:12:54AM +0100, Salvador Pérez wrote:
Hello authors of EDHOC,

we have implemented a previous version of EDHOC (draft-selander-ace-cose-ecdhe) and want to share some experiences.

Our work so far has focused on implementation and evaluation of version -08 of EDHOC over CoAP using real IoT hardware. The obtained results show a significant performance improvement compared to other key establishment protocols, such as DTLS handshake (version 1.2), especially with respect to length and number of exchanged messages.

Are your results written up anywhere?  It would be great to see more
details of the comparison and the actual numbers.
Unfortunately, I don't think that DTLS 1.2 is the best comparison -- DTLS
1.3 should be seen as the current "state of the art" for DTLS, and is
expected to itself be leaner than DTLS 1.2, which might wash out some of
the results you've seen here.

Thanks,

Ben

We have reviewed version -10 and noted the reduction of message length. Based on our experience, we propose that also removing the overhead due to security parameter negotiation could be an important optimization, and relevant in many use cases where these parameters are available through an out-of-band process.

Accordingly and taking into account that EDHOC provides a basic security functionality for any context where security needs to be enabled, we are currently considering the application of this protocol in different IoT deployments, such as LoRaWAN networks, OSCORE-enabled scenarios or its integration with capabilities. We therefore would like to see the progress of EDHOC in standardization.

Kind regards,

--------------------
Salvador Pérez
PhD student in "Future Internet Networks: Infrastructure and Security”
Faculty of Computer Science - University of Murcia
Email: salvador.p.f@um.es
Skype: salva.pf


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




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



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------727811DAE4EE40A92AF5A786-- From nobody Wed Oct 31 12:42:01 2018 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 208181277C8 for ; Wed, 31 Oct 2018 12:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_REMOTE_IMAGE=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 Z7S1NB7-cBdw for ; Wed, 31 Oct 2018 12:41:56 -0700 (PDT) Received: from xenon42.um.es (xenon42.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 288FA128766 for ; Wed, 31 Oct 2018 12:41:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon42.um.es (Postfix) with ESMTP id C916F218AA for ; Wed, 31 Oct 2018 20:41:52 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon42.um.es Received: from xenon42.um.es ([127.0.0.1]) by localhost (xenon42.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id IqyEAy2fZi7w for ; Wed, 31 Oct 2018 20:41:52 +0100 (CET) Received: from [192.168.0.28] (62.175.47.223.dyn.user.ono.com [62.175.47.223]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: skarmeta) by xenon42.um.es (Postfix) with ESMTPSA id 6329C218EE for ; Wed, 31 Oct 2018 20:41:51 +0100 (CET) To: ace@ietf.org References: <20181031154300.GK45914@kduck.kaduk.org> <16DF6657-B39C-49C5-A584-19D0932CCB91@um.es> <3a7159e4-8c22-977d-fe75-bf3b2d33e7b1@gmail.com> From: Antonio Skarmeta Message-ID: <5198d09a-73a8-6fca-a467-705041f30385@um.es> Date: Wed, 31 Oct 2018 20:41:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <3a7159e4-8c22-977d-fe75-bf3b2d33e7b1@gmail.com> Content-Type: multipart/alternative; boundary="------------33ADE9B8C09B9F89298938BE" Content-Language: es-ES X-Antivirus: Avast (VPS 181031-4, 31/10/2018), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [Ace] EDHOC standardization 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, 31 Oct 2018 19:42:00 -0000 This is a multi-part message in MIME format. --------------33ADE9B8C09B9F89298938BE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Rene Just to mention that I worked with Salvador and that the work he mention it is part of a more general analysis we are doing with different compression approaches for IoT deployment considering different networks in EU projects like ANASTACIA and IoTCrawler and als for our spin-off www.odins.es Indeed your suggestion it is quite relevant as we are also interested on these aspects and testing regards El 31/10/2018 a las 19:52, Rene Struik escribió: > Hi Salvador: > > It would be interesting to explore what the impact is of lossless > compression (with side information, in terms of maintained state by > either protocol party) on sizes of message flows. > This could shed some light on the question as to how much, e.g., > TLS1.3 message flows (or any other flows) can be squeezed and > un-squeezed "over the wire", thereby allowing a comparison of the > degree to which performance metrics are mainly due to formatting > schemes, such as [1]. I can imagine a breakdown as to how presumably > more favorable average compression ratio contribute to the mix vs. > different crypto schemes and security attributes. This would be a > useful exercise. > > Rene > > [1] RFC 8152 - CBOR Object Signing and Encryption (COSE)(July 2017) > > > On 10/31/2018 2:27 PM, Salvador Pérez wrote: >> Hi Benjamin, >> >> our results are included in a paper, which is under review for its >> publication. >> >> Regarding the comparison between EDHOC and DTLS, we have employed the >> tinydtls library [1] since it is widely used to deploy DTLS in >> different IoT scenarios. Note that, at the moment in which the paper >> was written, such library did not offer support for version 1.3. >> Anyway, DTLS 1.3 is essentially using the same handshake as TLS 1.3 >> ("DTLS 1.3 re-uses the TLS 1.3 handshake messages and flows” [2]). >> Moreover, authors of EDHOC state that the message overhead of TLS 1.3 >> is much higher than EDHOC ("Compared to the TLS 1.3 handshake with >> ECDH, the number of bytes in EDHOC is less than 1/3 when PSK >> authentication is used and less than 1/2 when RPK authentication is >> used, see Appendix E” [3-4]). Accordingly, we can claim that it is >> expected that DTLS 1.3 performs worse than EDHOC (at least, regarding >> message overhead) for the type of constrained implementations we are >> looking at. >> >> [1] https://projects.eclipse.org/projects/iot.tinydtls >> [2] https://tools.ietf.org/html/draft-ietf-tls-dtls13-29#section-5 >> [3] >> https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-10#section-1 >> [4] >> https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-10#appendix-E.4 >> >> Kind regards, >> >> -------------------- >> Salvador Pérez >> PhD student in "Future Internet Networks: Infrastructure and Security” >> Faculty of Computer Science - University of Murcia >> Email: salvador.p.f@um.es >> Skype: salva.pf >> >>> On 31 Oct 2018, at 16:43, Benjamin Kaduk >> > wrote: >>> >>> Hi Salvador, >>> >>> On Wed, Oct 31, 2018 at 10:12:54AM +0100, Salvador Pérez wrote: >>>> Hello authors of EDHOC, >>>> >>>> we have implemented a previous version of EDHOC >>>> (draft-selander-ace-cose-ecdhe) and want to share some experiences. >>>> >>>> Our work so far has focused on implementation and evaluation of >>>> version -08 of EDHOC over CoAP using real IoT hardware. The >>>> obtained results show a significant performance improvement >>>> compared to other key establishment protocols, such as DTLS >>>> handshake (version 1.2), especially with respect to length and >>>> number of exchanged messages. >>> >>> Are your results written up anywhere?  It would be great to see more >>> details of the comparison and the actual numbers. >>> Unfortunately, I don't think that DTLS 1.2 is the best comparison -- >>> DTLS >>> 1.3 should be seen as the current "state of the art" for DTLS, and is >>> expected to itself be leaner than DTLS 1.2, which might wash out some of >>> the results you've seen here. >>> >>> Thanks, >>> >>> Ben >>> >>>> We have reviewed version -10 and noted the reduction of message >>>> length. Based on our experience, we propose that also removing the >>>> overhead due to security parameter negotiation could be an >>>> important optimization, and relevant in many use cases where these >>>> parameters are available through an out-of-band process. >>>> >>>> Accordingly and taking into account that EDHOC provides a basic >>>> security functionality for any context where security needs to be >>>> enabled, we are currently considering the application of this >>>> protocol in different IoT deployments, such as LoRaWAN networks, >>>> OSCORE-enabled scenarios or its integration with capabilities. We >>>> therefore would like to see the progress of EDHOC in standardization. >>>> >>>> Kind regards, >>>> >>>> -------------------- >>>> Salvador Pérez >>>> PhD student in "Future Internet Networks: Infrastructure and Security” >>>> Faculty of Computer Science - University of Murcia >>>> Email: salvador.p.f@um.es >>>> Skype: salva.pf >>>> >>> >>>> _______________________________________________ >>>> Ace mailing list >>>> Ace@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ace >>> >> >> >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace > > > -- > email:rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace -- ------------------------------------------------------------ Antonio F. Skarmeta Gómez Dept. Ingeniería de la Información y las Comunicaciones Facultad de Informática Universidad de Murcia 30100 Murcia e-mail: skarmeta@um.es Telf: +34-868-884607 fax: +34-868-884151 --- El software de antivirus Avast ha analizado este correo electrónico en busca de virus. https://www.avast.com/antivirus --------------33ADE9B8C09B9F89298938BE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Rene

Just to mention that I worked with Salvador and that the work he mention it is part of a more general analysis we are doing with different compression approaches for IoT deployment considering different networks in EU projects like ANASTACIA and IoTCrawler and als for our spin-off www.odins.es

Indeed your suggestion it is quite relevant as we are also interested on these aspects and testing

regards


El 31/10/2018 a las 19:52, Rene Struik escribió:
Hi Salvador:

It would be interesting to explore what the impact is of lossless compression (with side information, in terms of maintained state by either protocol party) on sizes of message flows.
This could shed some light on the question as to how much, e.g., TLS1.3 message flows (or any other flows) can be squeezed and un-squeezed "over the wire", thereby allowing a comparison of the degree to which performance metrics are mainly due to formatting schemes, such as [1]. I can imagine a breakdown as to how presumably more favorable average compression ratio contribute to the mix vs. different crypto schemes and security attributes. This would be a useful exercise.

Rene

[1] RFC 8152 - CBOR Object Signing and Encryption (COSE)(July 2017)


On 10/31/2018 2:27 PM, Salvador Pérez wrote:
Hi Benjamin,

our results are included in a paper, which is under review for its publication.

Regarding the comparison between EDHOC and DTLS, we have employed the tinydtls library [1] since it is widely used to deploy DTLS in different IoT scenarios. Note that, at the moment in which the paper was written, such library did not offer support for version 1.3. Anyway, DTLS 1.3 is essentially using the same handshake as TLS 1.3 ("DTLS 1.3 re-uses the TLS 1.3 handshake messages and flows” [2]). Moreover, authors of EDHOC state that the message overhead of TLS 1.3 is much higher than EDHOC ("Compared to the TLS 1.3 handshake with ECDH, the number of bytes in EDHOC is less than 1/3 when PSK authentication is used and less than 1/2 when RPK authentication is used, see Appendix E” [3-4]). Accordingly, we can claim that it is expected that DTLS 1.3 performs worse than EDHOC (at least, regarding message overhead) for the type of constrained implementations we are looking at.


Kind regards,

--------------------
Salvador Pérez
PhD student in "Future Internet Networks: Infrastructure and Security”
Faculty of Computer Science - University of Murcia
Email: salvador.p.f@um.es
Skype: salva.pf

On 31 Oct 2018, at 16:43, Benjamin Kaduk <kaduk@mit.edu> wrote:

Hi Salvador,

On Wed, Oct 31, 2018 at 10:12:54AM +0100, Salvador Pérez wrote:
Hello authors of EDHOC,

we have implemented a previous version of EDHOC (draft-selander-ace-cose-ecdhe) and want to share some experiences.

Our work so far has focused on implementation and evaluation of version -08 of EDHOC over CoAP using real IoT hardware. The obtained results show a significant performance improvement compared to other key establishment protocols, such as DTLS handshake (version 1.2), especially with respect to length and number of exchanged messages.

Are your results written up anywhere?  It would be great to see more
details of the comparison and the actual numbers.
Unfortunately, I don't think that DTLS 1.2 is the best comparison -- DTLS
1.3 should be seen as the current "state of the art" for DTLS, and is
expected to itself be leaner than DTLS 1.2, which might wash out some of
the results you've seen here.

Thanks,

Ben

We have reviewed version -10 and noted the reduction of message length. Based on our experience, we propose that also removing the overhead due to security parameter negotiation could be an important optimization, and relevant in many use cases where these parameters are available through an out-of-band process.

Accordingly and taking into account that EDHOC provides a basic security functionality for any context where security needs to be enabled, we are currently considering the application of this protocol in different IoT deployments, such as LoRaWAN networks, OSCORE-enabled scenarios or its integration with capabilities. We therefore would like to see the progress of EDHOC in standardization.

Kind regards,

--------------------
Salvador Pérez
PhD student in "Future Internet Networks: Infrastructure and Security”
Faculty of Computer Science - University of Murcia
Email: salvador.p.f@um.es
Skype: salva.pf


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




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



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


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


-- 
------------------------------------------------------------
Antonio F. Skarmeta Gómez
Dept. Ingeniería de la Información y las Comunicaciones
Facultad de Informática
Universidad de Murcia
30100 Murcia
e-mail: skarmeta@um.es
Telf: +34-868-884607
fax: +34-868-884151

Libre de virus. www.avast.com
--------------33ADE9B8C09B9F89298938BE-- From nobody Wed Oct 31 20:52:04 2018 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 CAEF1130E0E for ; Wed, 31 Oct 2018 20:52:01 -0700 (PDT) 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, 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 bWo9dzMY04Hk for ; Wed, 31 Oct 2018 20:51:59 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43C4C130E07 for ; Wed, 31 Oct 2018 20:51:59 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [IPv6:2401:4900:16e3:794c:7862:56ef:35b3:3]) by relay.sandelman.ca (Postfix) with ESMTPS id 6F8A51F42E; Thu, 1 Nov 2018 03:51:57 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id F19BC179E; Thu, 1 Nov 2018 09:21:08 +0530 (IST) From: Michael Richardson To: =?us-ascii?Q?=3D=3Futf-8=3FQ=3FSalvador=5FP=3DC3=3DA9rez=3F=3D?= cc: ace@ietf.org In-reply-to: References: Comments: In-reply-to =?us-ascii?Q?=3D=3Futf-8=3FQ=3FSalvador=5FP=3DC3=3DA?= =?us-ascii?Q?9rez=3F=3D?= message dated "Wed, 31 Oct 2018 10:12:54 +0100." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Thu, 01 Nov 2018 09:21:08 +0530 Message-ID: <30535.1541044268@dooku.sandelman.ca> Archived-At: Subject: Re: [Ace] EDHOC standardization 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, 01 Nov 2018 03:52:02 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Salvador P=C3=A9rez wrote: > we have implemented a previous version of EDHOC > (draft-selander-ace-cose-ecdhe) and want to share some experiences. That's very cool. Some questions for you! > Our work so far has focused on implementation and evaluation of versi= on > -08 of EDHOC over CoAP using real IoT hardware. The obtained results > show a significant performance improvement compared to other key > establishment protocols, such as DTLS handshake (version 1.2), > especially with respect to length and number of exchanged messages. What did you use for authentication? RSA? ECDSA? EDDSA? PSK? Were they raw public keys, or was it in a certificate? Did you try a certificate in one direction and a raw public key in the othe= r? Did you offer more than 1 algorithm when you negotiated? > We have reviewed version -10 and noted the reduction of message > length. Based on our experience, we propose that also removing the > overhead due to security parameter negotiation could be an important > optimization, and relevant in many use cases where these parameters a= re > available through an out-of-band process. If the list of valid algorithms is available securely by out-of-band processes, then couldn't use this mechanism to do key agreement instead, saving 100% of the bytes on the wire? :-) We need to do security parameter negotiation in order to be agile against future algorithm attacks, and there will be algorithm attacks in the 20 to 40 year lifespans that we expect... and we need to leave space for replacing the DH process with some QMDH process. The CBOR encoding is really really very nice for this, and I wish we had CBOR when we did IKEv2. > Accordingly and taking into account that EDHOC provides a basic > security functionality for any context where security needs to be > enabled, we are currently considering the application of this protocol > in different IoT deployments, such as LoRaWAN networks, OSCORE-enabled > scenarios or its integration with capabilities. We therefore would li= ke > to see the progress of EDHOC in standardization. I don't see how LORaWAN has enough bytes available for even EDHOC. I think that LoRaWAN needs a key agreement protocol that can be run once while the sensor is attached to the installer's smartphone. The important thing is that one is able to use the key agrement protocol over IPs A<->B, in order to setup a context that can be used between IPs C<-->D. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAlvaeCwACgkQlUzhVv38 QpD2mQgAo2wU+8tqQE2Tn3snEegfy3ExstqwS2sZxxJ27gFm0/fStf3U8W5o65b5 noqGGOr3rZvINM+t0BgbgTuMCtanG3TRQCs4qAfdI07c0oRa06udwdB50Ba5HeEf Qe/5JIkh0E2OPEoWfn8ggfwlcz5xKWVP+PqWYLRONjTiCHCfPdnSz+2FLzzXcMLL MqGPKht0l87N2zXo0PxwgYkiqqWOMztnzwA8MLTTS48YsQU+s4wiHGFlpjvnVYa8 mDRzacKBFgPD+T6zHEDMKsArxg1vfj38w6cCtbsgf7n+y7b5XjJW5/LxhWNx++Hs fpQSCMwMUpdeU/eBmmRMMU70RuuzeQ== =Hpt7 -----END PGP SIGNATURE----- --=-=-=--