From nobody Sun Jul 1 06:33: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 8DF0A1277CC; Sun, 1 Jul 2018 06:33:49 -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 O1jQN9ysnRpr; Sun, 1 Jul 2018 06:33:47 -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 35107130DFA; Sun, 1 Jul 2018 06:33:47 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sun, 1 Jul 2018 06:30:36 -0700 From: Jim Schaad To: CC: 'ace' Date: Sun, 1 Jul 2018 06:33:38 -0700 Message-ID: <032f01d41140$20027c80$60077580$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AdQQomo17j3U+ofJS2Sv3RAe718IaA== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Ace] Review draft-ietf-ace-coap-est X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2018 13:33:50 -0000 * In section 4.1 I have a question about what you are using for payload content encoding. Part of this might just be a question of how you plan to move from ASN.1 to CBOR at some point in the future. I think that it would necessitate doing new media-types in that event. You appear to be doing a CBOR bstr wrapping on the ASN.1 encoding payload. I don't believe that there is any reason for doing this. I would expect that the payload would be the ASN.1 w/o any ASN.1. It is highly possible that I am just mis-reading what the text says and this is what you say. * In section 5.0 - As written, the example of doing a query against /.well-known/core does not match my understanding of what would be return. It should only return those resources which have the rt field set on them. I do not understand why you believe that the following lines MAY be returned. Clarification of why you think this is true would be appreciated. * Section 6 - Is there a need to have all of this description around TLS-unique? Do you have a reason to believe that people are going get this implemented wrong? * Section 7 - I think the figure has an error associated w/ it. The CA should be tied to the EST Server and not to the Registrar * Section 7 - Your language is a bit sloppy around the terms of POP and POP linking. Unless it is really badly behaved, POP should never be broken by an RA. The POP is the signature on the request and not tied to the TLS channel. The POP linking is tied to the TLS channel and is broken by the changing of the TLS sessions (client <-> RA, RA <-> CA) * Section 7 - It is not clear to me that the SHOULD on reassembly of fragmentation is not a MUST. I doubt that any EST server is going to be able to deal with getting fragments of requests from a registrar in separate messages. This would be compounded if the proxy is handling multiple sessions at the same time. * Section 7 - It should be possible that when doing key generation for the protection of the private key to be end-to-end and it should not be necessary for the Proxy to decrypt and then re-encrypt the private key. It should not matter for this if one does either symmetric or asymmetric encryption of the private key. * Section 7 - It is very possible that the private key generation function would be hosted on the proxy and not at the CA. I think that you might want to describe this as a normal configuration. (Just spotted this in the Security considerations. I think it should be here as well.) * Section 9.1 - application/multipart-core should not be in the table of items for IANA to register. This is being done in a different document. If you want this table as a whole then it needs to be moved out of IANA considerations. * Section 9.2 - please expand this text some. You might want to look at https://tools.ietf.org/html/rfc7390#section-6.1 for a template. Jim From nobody Sun Jul 1 10:47: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 2A548130E71; Sun, 1 Jul 2018 10:47:28 -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 HG4tJh6ydfzO; Sun, 1 Jul 2018 10:47:25 -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 F4220130E6D; Sun, 1 Jul 2018 10:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w61HlJED022461; Sun, 1 Jul 2018 19:47:19 +0200 (CEST) Received: from [192.168.217.114] (p5DC7FF04.dip0.t-ipconnect.de [93.199.255.4]) (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 41JdBH3zGCzDXdR; Sun, 1 Jul 2018 19:47:19 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 552160036.771-3560f32e67c21b99b06b4537d19f474c Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Sun, 1 Jul 2018 19:47:18 +0200 Message-Id: <19B520A9-2C13-44CA-AA76-AE8325320CBA@tzi.org> To: ace , Core , cose , cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [Ace] Constrained Node/Network Cluster @ IETF102: FINAL AGENDA X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2018 17:47:29 -0000 I forgot to send the update of my usual eclectic condensed agenda based on the "FINAL" AGENDA for IETF102. Remember that "FINAL" means this will be the basis for printed agenda sheets, there is still some potential for changes after that. The only change from the previous draft agenda (apart from different room assignments) seems to be the move of SECDISPATCH on top of the first CORE slot and of SUIT into what previously was the SECDISPATCH slot. The conflicts ACE vs. DISPATCH as well as CBOR vs. 6LO vs. TEEP remain. All times are EDT (UTC-0400). (You can get pure UTC times on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten SATURDAY/SUNDAY -- Hackathon (including various interops) (Centre Ville) -- Sun 1800-2000: HotRFC (Viger) MONDAY, July 16, 2018 0930-1200 Morning Session I Duluth ART dispatch Dispatch WG - Joint with ARTAREA Laurier INT 6man IPv6 Maintenance WG Place du Canada RTG detnet Deterministic Networking WG Viger SEC *** ace Authentication and Authorization for = Constrained Environments WG 1330-1530 Afternoon Session I Laurier INT ipwave IP Wireless Access in Vehicular = Environments WG Place du Canada SEC tls Transport Layer Security WG 1550-1750 Afternoon Session II Duluth ART *** core Constrained RESTful Environments WG Laurier INT intarea Internet Area Working Group WG Viger SEC secdispatch Security Dispatch WG 1810-1940 Afternoon Session III Laurier GEN rfcplusplus The label "RFC" BOF TUESDAY, July 17, 2018 0930-1200 Morning Session I Place du Canada IRTF irtfopen IRTF Open Meeting St-Paul/St-Cath RTG babel Babel routing protocol WG Duluth RTG *** roll Routing Over Low power and Lossy = networks WG 1330-1530 Afternoon Session I Van Horne ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Duluth INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Laurier RTG rtgarea Routing Area Open Meeting Viger SEC *** teep Trusted Execution Environment = Provisioning WG 1550-1820 Afternoon Session II Place du Canada ART httpbis Hypertext Transfer Protocol WG Viger IRTF cfrg Crypto Forum - 1720 - 1820 Centre Ville IRTF icnrg Information-Centric Networking Van Horne SEC acme Automated Certificate Management = Environment WG - 1720 - 1820 Van Horne SEC oauth Web Authorization Protocol WG - 1550 - = 1720 Duluth TSV taps Transport Services WG WEDNESDAY, July 18, 2018 0930-1200 Morning Session I Van Horne OPS anima Autonomic Networking Integrated Model = and Approach WG St-Paul/St-Cath RTG bier Bit Indexed Explicit Replication WG Duluth SEC *** suit Software Updates for Internet of Things = WG Place du Canada TSV quic QUIC WG 1330-1500 Afternoon Session I Laurier ART httpbis Hypertext Transfer Protocol WG Duluth INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG 1520-1650 Afternoon Session II Centre Ville INT homenet Home Networking WG Viger TSV tsvarea Transport Area Open Meeting THURSDAY, July 19, 2018 0930-1200 Morning Session I Duluth INT dnssd Extensions for Scalable DNS Service = Discovery WG Centre Ville INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Place du Canada IRTF maprg Measurement and Analysis for Protocols Viger SEC mls Messaging Layer Security WG Van Horne SEC oauth Web Authorization Protocol WG - 0930 - = 1100 1330-1530 Afternoon Session I Laurier OPS v6ops IPv6 Operations WG Centre Ville RTG rift Routing In Fat Trees WG Place du Canada SEC saag Security Area Open Meeting 1550-1750 Afternoon Session II Laurier IRTF*** t2trg Thing-to-Thing Viger OPS driu DNS Resolver Identification and Use BOF Centre Ville TSV tsvwg Transport Area Working Group WG 1810-1910 Afternoon Session III Van Horne ART *** core Constrained RESTful Environments WG Laurier SEC tls Transport Layer Security WG Centre Ville TSV tsvwg Transport Area Working Group WG FRIDAY, July 20, 2018 0930-1130 Morning Session I Centre Ville IRTF*** dinrg Decentralized Internet Infrastructure = Proposed RG Place du Canada OPS v6ops IPv6 Operations WG St-Paul/St-Cath TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1150-1320 Afternoon Session I Duluth INT *** lwig Light-Weight Implementation Guidance WG Laurier IRTF panrg Path Aware Networking Proposed RG Centre Ville SEC tokbind Token Binding WG From nobody Mon Jul 2 06:14:23 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 99B72130DE5; Mon, 2 Jul 2018 06:14:15 -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.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153053725558.27978.14968176954413679706@ietfa.amsl.com> Date: Mon, 02 Jul 2018 06:14:15 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-oauth-authz-13.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 13:14:17 -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-13.txt Pages : 69 Date : 2018-07-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-13 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-13 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 Jul 2 06:20: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 6CC28127AC2 for ; Mon, 2 Jul 2018 06:20:40 -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 fL2lo-IbD-vV for ; Mon, 2 Jul 2018 06:20:32 -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 7B482130F47 for ; Mon, 2 Jul 2018 06:20:32 -0700 (PDT) Received: from 1fZyko-000An9-VA by out10d.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1fZyko-000Ao5-Vl for ace@ietf.org; Mon, 02 Jul 2018 06:20:30 -0700 Received: by emcmailer; Mon, 02 Jul 2018 06:20:30 -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 1fZyko-000An9-VA for ace@ietf.org; Mon, 02 Jul 2018 06:20:30 -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; Mon, 2 Jul 2018 15:20:30 +0200 References: <153053725580.27978.4314540479236300546.idtracker@ietfa.amsl.com> To: "ace@ietf.org" From: Ludwig Seitz X-Forwarded-Message-Id: <153053725580.27978.4314540479236300546.idtracker@ietfa.amsl.com> Message-ID: <30e72124-6ccb-5d4c-cf71-8503cbae35f8@ri.se> Date: Mon, 2 Jul 2018 15:20:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <153053725580.27978.4314540479236300546.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-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: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-13.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 13:20:48 -0000 Hello ACE, we have published a new version of draft-ietf-ace-oauth-authz. It contains some clarifications and editorial changes as follows: * Replaced the term "RS Information" with "Access Information" (based on review comments by Jim Schaad) * Replaced reference to resource directory (RD) for AS lookup with generic text, since no AS attribute for RD is defined. (based on review comments by Jim Schaad) * Removed comment about "ongoing discussion" about time measurement on constrained devices, discussion is no longer ongoing (based on review comments by Jim Schaad) * Various editorial corrections by Hannes Tschofenig /Ludwig -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-ace-oauth-authz-13.txt Date: Mon, 2 Jul 2018 06:14:15 -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-13.txt has been successfully submitted by Ludwig Seitz and posted to the IETF repository. Name: draft-ietf-ace-oauth-authz Revision: 13 Title: Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) Document date: 2018-07-02 Group: ace Pages: 69 URL: https://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-authz-13.txt Status: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ Htmlized: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-13 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-13 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 Mon Jul 2 09:41: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 1305B130DFC; Mon, 2 Jul 2018 09:41:33 -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.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153054969303.16295.17587072211699460698@ietfa.amsl.com> Date: Mon, 02 Jul 2018 09:41:33 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-04.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 16:41: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 : 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-04.txt Pages : 39 Date : 2018-07-02 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-04 https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-est-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-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 Tue Jul 3 02:32: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 2E0A6130E36 for ; Tue, 3 Jul 2018 02:32: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, 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 bDdphYU12Zia for ; Tue, 3 Jul 2018 02:32:05 -0700 (PDT) Received: from smtp-out11.electric.net (smtp-out11.electric.net [185.38.181.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 DEF22131208 for ; Tue, 3 Jul 2018 02:32:04 -0700 (PDT) Received: from 1faHfE-000T2i-VU by out11b.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1faHfF-000T3k-TC for ace@ietf.org; Tue, 03 Jul 2018 02:32:01 -0700 Received: by emcmailer; Tue, 03 Jul 2018 02:32:01 -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 1faHfE-000T2i-VU for ace@ietf.org; Tue, 03 Jul 2018 02:32: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.1466.3; Tue, 3 Jul 2018 11:32:00 +0200 To: 'ace' References: <20180622204344.GP64617@kduck.kaduk.org> <20180623212956.GE99689@kduck.kaduk.org> <027401d40b93$6b73b470$425b1d50$@augustcellars.com> <00e701d40d6e$c09b3db0$41d1b910$@augustcellars.com> <013301d40de7$39660220$ac320660$@augustcellars.com> <027e01d40f6e$01e326b0$05a97410$@augustcellars.com> From: Ludwig Seitz Message-ID: <2bbc8011-ccac-b2ed-12cf-921ee6f3a672@ri.se> Date: Tue, 3 Jul 2018 11:31:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <027e01d40f6e$01e326b0$05a97410$@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-PolicySMART: 14510320 X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) Archived-At: Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 09:32:09 -0000 I've finally had the time to think about that Key ID issue for ACE. Here is what I got: The case Jim is worried about is the following: * Client A has key K1 with KID = "A" * RS also has key K1 with KID = "A" * Client A has the right to token T1 on RS * Client B has the right to token T2 on RS 1. Client A gets T1 from AS bound via the cnf claim to KID="A" 2. Client A transfers T1 to RS 3. Client A performs the proof-of-possession with key K1 and gets access to RS according to T1 4. Malicious Client B learns of the KID = "A" for T1 (but not of K1). 5. Client B chooses K2 and assigns it KID = "A" 6. Client B gets 2 from AS bound via the cnf claim to KID="A" 7. Client B transfers T2 to RS 8. ? 9. Client B performs the proof-of-possession for K2 and gets access to both T1 and T2 Now I'm claiming there is no step 8 that makes step 9 work, unless B can get RS to accept a new key (K2) with a duplicate KID. Thus I'd say, we need to Security Considerations about handling key Ids at the recipient of a CWT containing a cnf claim. Something along the lines of: "If a recipient receives a CWT with the a confirmation claim, the recipient MUST make sure that keys that may be contained in that claim do not have a key identifier that duplicates one of a different key that the recipient already recognizes." Or shorter: "Recipients MUST make sure that they do not accept identical key identifiers for different keys" /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Tue Jul 3 02:33:10 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 CAD62130F84 for ; Tue, 3 Jul 2018 02:33:07 -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 W97JWzZweJul for ; Tue, 3 Jul 2018 02:33:06 -0700 (PDT) Received: from smtp-out11.electric.net (smtp-out11.electric.net [185.38.181.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 6EF29130E36 for ; Tue, 3 Jul 2018 02:33:06 -0700 (PDT) Received: from 1faHgG-000Vpo-U8 by out11b.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1faHgG-000Vqm-VC for ace@ietf.org; Tue, 03 Jul 2018 02:33:04 -0700 Received: by emcmailer; Tue, 03 Jul 2018 02:33:04 -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 1faHgG-000Vpo-U8 for ace@ietf.org; Tue, 03 Jul 2018 02:33: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; Tue, 3 Jul 2018 11:33:04 +0200 From: Ludwig Seitz To: 'ace' References: <20180622204344.GP64617@kduck.kaduk.org> <20180623212956.GE99689@kduck.kaduk.org> <027401d40b93$6b73b470$425b1d50$@augustcellars.com> <00e701d40d6e$c09b3db0$41d1b910$@augustcellars.com> <013301d40de7$39660220$ac320660$@augustcellars.com> <027e01d40f6e$01e326b0$05a97410$@augustcellars.com> <2bbc8011-ccac-b2ed-12cf-921ee6f3a672@ri.se> Message-ID: Date: Tue, 3 Jul 2018 11:33:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <2bbc8011-ccac-b2ed-12cf-921ee6f3a672@ri.se> 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] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 09:33:08 -0000 On 2018-07-03 11:31, Ludwig Seitz wrote: > > 6. Client B gets 2 from AS bound via the cnf claim to KID="A" > This should of course read: Client B gets T2 from AS ... /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Tue Jul 3 09:07:07 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 0A044131048; Tue, 3 Jul 2018 09:00:28 -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.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153063362803.4893.5921231919587466670.idtracker@ietfa.amsl.com> Date: Tue, 03 Jul 2018 09:00:28 -0700 Archived-At: Subject: [Ace] ace - Requested session has been scheduled for IETF 102 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 16:00:39 -0000 Dear Roman Danyliw, 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) Monday, 16 July 2018, Morning Session I 0930-1200 Room Name: Viger size: 200 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/102/sessions/ace.ics Request Information: --------------------------------------------------------- Working Group Name: Authentication and Authorization for Constrained Environments Area Name: Security Area Session Requester: Roman Danyliw 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: A session in the first half of the week (Mon-Wed) would be preferred. --------------------------------------------------------- From nobody Tue Jul 3 09:21: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 2808613112F for ; Tue, 3 Jul 2018 09:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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, T_DKIMWL_WL_HIGH=-0.01] 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 AqFpMwjn-pBL for ; Tue, 3 Jul 2018 09:21:04 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640094.outbound.protection.outlook.com [40.107.64.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47D131310C2 for ; Tue, 3 Jul 2018 09:15: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=wdvJor7LTZzslkc+fFrhup4BpFYWnWLKAhpXE2QgTww=; b=AXsKqCtU6MtuUQ8456zgxFv1dwXeYnxRI+oP+jmW5EnjVJyQHpSQp6HpXldEMDvkrT/O8SXu3xmOoqEYFshoFznRdHi6C9B8u7yH6CQZ07FE6LP5DSeoc4uoRqIBEO4uf7AOb82V/jdGQzt0xuUtrbRkcKdAI0FtBEdNZcQoxTo= Received: from DM5PR00MB0293.namprd00.prod.outlook.com (52.132.128.34) by DM5PR00MB0293.namprd00.prod.outlook.com (52.132.128.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.967.0; Tue, 3 Jul 2018 16:15:50 +0000 Received: from DM5PR00MB0293.namprd00.prod.outlook.com ([fe80::4585:e342:2207:ca93]) by DM5PR00MB0293.namprd00.prod.outlook.com ([fe80::4585:e342:2207:ca93%4]) with mapi id 15.20.0967.000; Tue, 3 Jul 2018 16:15:50 +0000 From: Mike Jones To: Ludwig Seitz , 'ace' Thread-Topic: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 Thread-Index: AQHUCmm+QBbDlvIEiEKYiqnkeWTVYaRsv4gggAGeToCAALQmgIADqRiAgAANlYCAAN+nAIAAEUqAgAIeFQCAAO96AIAGhVmAgAAAWICAAG5L8A== Date: Tue, 3 Jul 2018 16:15:50 +0000 Message-ID: References: <20180622204344.GP64617@kduck.kaduk.org> <20180623212956.GE99689@kduck.kaduk.org> <027401d40b93$6b73b470$425b1d50$@augustcellars.com> <00e701d40d6e$c09b3db0$41d1b910$@augustcellars.com> <013301d40de7$39660220$ac320660$@augustcellars.com> <027e01d40f6e$01e326b0$05a97410$@augustcellars.com> <2bbc8011-ccac-b2ed-12cf-921ee6f3a672@ri.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.47.80.188] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR00MB0293; 6:mzevd6GUEaWxNsDa0yNkw1pRPHEU1SX69nom4mqBenjrTG2RxeYhThvaDJ/tjwRoy9Z3Ur2s8abecD7+DP8EuRZOlt2isEFLSljLeQRSIhUfgyUg5Wq48ojeXynxQgd7Y/0RluvciEFYOTsrswfQns/dHvjq/xDTuzGcTvGhboMemJpWDXUI3dXEOyDzgtjz820uo35RPeaf6uQOfPG5kkqdPgDAmsxtZvGHDdTz11XGudALs/HODpv7ZbN9VZnpHJP+81dqnQEAVrkh4QREUEh8XB0UcMBHBio1p6j3STSoQ+lbIPOVZkHFuc+h7vYS5FM3rLfEGAJh6rJUvQpG92PhJq1LQZw54J9tI34FPPUh0YHPjbB0+NmOwGYaQuLyjvQ/4JWtn+ZOsww626TpbskoX1Q4Kzs0TA2pN9A3P2sm/IwpA1rMgHzwe/RA2s7TGXLSURgVu+zvVeCqonLqSQ==; 5:yUDe8+ZI0J9OslKWDSm+lIO+24o8cK0dMNK0dGXGZ1yJgirIy3vstRInCXp8LVdEwar6wt2zFVcqFDsmoCwTMn8d3YKSge3gyRrrfH+QB1+XCxv4owD2iXXONDt4ZxlpecAbFlCCEi2grUXBWmZioSGH3YutkbVcDHjtBU0ILWs=; 7:y54qX+hGIFwchEfXAaK5PZ1b16AOaS/MDoo3OYTEs61PMzpklZEghWI1LfKw0DZ9J37IkTNGkje7k20hGMvAbd91HW4wDsxpZx8kCO3iKv899BZpPGhS+6vynGEXcjon/q685BZXMrwg085rYWXT9heeW42OGTc7cSMO6iXleR2m7jtdKYfctWzR+8E4JQXzJHAGRMoXkQzfEG91VMOaobCFOUw8mb6gvkatC+we2v2xXEIqm2nlnKcLv486cnvA x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 61e69393-30f4-43e7-0ce9-08d5e1003e3d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7193020); SRVR:DM5PR00MB0293; x-ms-traffictypediagnostic: DM5PR00MB0293: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(3002001)(10201501046)(93006095)(93001095)(3231280)(2018427008)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:DM5PR00MB0293; BCL:0; PCL:0; RULEID:; SRVR:DM5PR00MB0293; x-forefront-prvs: 0722981D2A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(366004)(136003)(346002)(376002)(199004)(189003)(13464003)(14454004)(229853002)(68736007)(25786009)(22452003)(486006)(14444005)(478600001)(10090500001)(7696005)(966005)(6246003)(76176011)(316002)(72206003)(74316002)(7736002)(6306002)(55016002)(5250100002)(305945005)(86362001)(6436002)(86612001)(2906002)(256004)(9686003)(26005)(8936002)(6116002)(3846002)(106356001)(2900100001)(186003)(110136005)(93886005)(66066001)(33656002)(8990500004)(5660300001)(97736004)(446003)(11346002)(6506007)(53546011)(105586002)(8676002)(81156014)(81166006)(10290500003)(102836004)(99286004)(53936002)(476003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR00MB0293; H:DM5PR00MB0293.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: 5NYp/SyQId0Gj9h58m+A/cbKs9o9xNGVVRXP0lUWB6Ha5F6tmj9ojIxItto1eXy50oJR76F4+IqEjl/NDwT64QKnJzh7pMdToCfrErgcpE1ESBJJ15bBrIMYOwKVpG7j5PK9yzuAvMKuJydc4hNLrnisLPhLBc/GBQOyQ9Hf3bXK+7HPYhlFNjB4rVdsM0UVEhP63ebzPZ0nBb9nQT8lhWSKBk5ZMEGz7tvOBFWrLj0eluPAM3LZBYaooEtBT1dv+EODeJovylddGC8jOeptbi97+is+//cvoLSjfaKTrvNowaovWfgDLKbs8lvKKmjqZKmu9BWfqn+ygV731HnNfqcLhd40HywSTvK7FojN19M= 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: 61e69393-30f4-43e7-0ce9-08d5e1003e3d X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2018 16:15:50.1580 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0293 Archived-At: Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 16:21:20 -0000 Thanks, Ludwig. Note that last paragraph of the new Operational Considerat= ions section at https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-pos= session-03#section-6 addresses this issue. In particular, the last sentenc= e of the section talks about the need to keep keys used in different contex= ts separate if there is otherwise any chance of confusion. I'll also note that for the constrained environments that ACE is addressing= , I expect that deployments with exactly one PoP key to be predominant use = case. In this use case, such confusion is impossible in the first place. -- Mike -----Original Message----- From: Ace On Behalf Of Ludwig Seitz Sent: Tuesday, July 3, 2018 2:33 AM To: 'ace' Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-poss= ession-02 On 2018-07-03 11:31, Ludwig Seitz wrote: >=20 > 6. Client B gets 2 from AS bound via the cnf claim to KID=3D"A" >=20 This should of course read: Client B gets T2 from AS ... /Ludwig --=20 Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Tue Jul 3 12:47: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 557C0130DFB for ; Tue, 3 Jul 2018 12:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 o-BTmatHBT8l for ; Tue, 3 Jul 2018 12:47:08 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10062.outbound.protection.outlook.com [40.107.1.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 222DF130DF6 for ; Tue, 3 Jul 2018 12:47:07 -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=dJvVi4dMtKyXSBtgdwLu2bskGBI/jAArLBc/QLbzCeM=; b=ipnoJ34mH1Bq53hx4jHjp+0bn5nUc3HEUBY/OyZQRtyLaSOEQsXWWY/q/TWLopRWSWQzW48a9X4n9CNa5HhXLMznuRFWt8jCOkTItmzJ45t5fY5YnUkPTCVnJON5daOC6JBxzMtLCiXmC2yJhiIwgeNoYkroYGUShP+CR+KhWpE= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1518.eurprd08.prod.outlook.com (10.167.210.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.906.26; Tue, 3 Jul 2018 19:47:05 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db%10]) with mapi id 15.20.0906.026; Tue, 3 Jul 2018 19:47:05 +0000 From: Hannes Tschofenig To: "ace@ietf.org" Thread-Topic: PoP Key Distribution Thread-Index: AdQTBj47ZlOcOW2pSHSpIBiWadk6FgAAD6QA Date: Tue, 3 Jul 2018 19:47:05 +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: [80.92.118.234] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1518; 7:FojNwI0/5oYVIPU7R+VUzv1Np214TDWt8g+cS2jGe7WeJXmHc6PlW4UFTA27lBA22Mfx3XliDBx5SF5oYOyobEeadnJi0JivEIjYiptyVfBegDawjAkEz0YaiHXQJNYKgg0v920cApbh6QK/PnEVf024o8HglWJs2k0UdFwzXAANKzYR1iSXpYmI6dY4J+68TpkU4zm68Yc1PPW3XRkI4qrGUEY/14Lxu/ViKW5YvEnDgBPKxspiFTpBFGrC/hAQ x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: d498ed70-158a-4959-d326-08d5e11dc13d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1518; x-ms-traffictypediagnostic: VI1PR0801MB1518: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(223705240517415); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1518; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1518; x-forefront-prvs: 0722981D2A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(39860400002)(346002)(366004)(396003)(199004)(40434004)(53754006)(189003)(7696005)(72206003)(26005)(2906002)(6916009)(53546011)(478600001)(2351001)(186003)(6506007)(81156014)(68736007)(5630700001)(55016002)(86362001)(966005)(5250100002)(54896002)(14454004)(229853002)(6306002)(2473003)(476003)(236005)(6436002)(102836004)(9686003)(8676002)(486006)(99286004)(8936002)(1730700003)(3846002)(5640700003)(33656002)(790700001)(74316002)(105586002)(2501003)(106356001)(7736002)(97736004)(606006)(5660300001)(6116002)(66066001)(2900100001)(25786009)(81166006)(316002)(7116003)(14444005)(5024004)(256004)(53936002)(11634002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1518; 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: XkyI2DeqZHIwxolYJ3GBiYQBgtNVV1gCODjeKfXchmiCO9OwgDTda6vMzOG1z3/IUttW4ASvaW4opTVPN5rI4SYCDN5R0/pgCLdKLxv+Gm4JLUOhcV4VRNH+hEmEoOMkBlzu1B76jn/HzkSf6832Bz7HNpgbQ6B4ZAt56VKivT/kP+kHoJHS5bJjhZVBHsYQTi22/hR4+tXLmo7nAusXk2BXioslLldwvKzTOrrDNZ7GMn4s4xn3LOV0R9CMIR1NRTMposvivT8jkYTlp17ECotUnyJbIZqK6FIIBYIEeSYre9HdqLhSNy90bbPk/uQmuhr+H5NdLwJkHjHmtaQKtkmlt2N4SpnrP203zPrMHxQ= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB21129BCC73AB78D6B06B1044FA420VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: d498ed70-158a-4959-d326-08d5e11dc13d X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2018 19:47:05.3297 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1518 Archived-At: Subject: [Ace] FW: PoP Key Distribution X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 19:47:12 -0000 --_000_VI1PR0801MB21129BCC73AB78D6B06B1044FA420VI1PR0801MB2112_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Note that I posted a mail to the OAuth list about the PoP key distribution,= which also relates to the work on ACE-OAuth. If you are interested in this topic please feel free to join the discussion= on the OAuth mailing list. From: Hannes Tschofenig Sent: 03 July 2018 21:46 To: oauth@ietf.org Subject: PoP Key Distribution Hi all, we have been working on an update for the draft-ietf-oauth-pop-key-distribu= tion document in time for the deadline but we noticed several issues that a= re worthwhile to bring to your attention. draft-ietf-oauth-pop-key-distribution defines a mechanism that allows the c= lient to talk to the AS to request a PoP access token and associated keying= material. There are two other groups in the IETF where this concept is used. =B7 The guys working on RTCWEB is the first. Misi (M=E9sz=E1ros Mih= =E1ly) has been helping us to understand their needs. They have defined the= ir own token format, which has been posted on the OAuth group a while ago f= or review. =B7 The other group is ACE with their work on an OAuth-based profil= e for IoT. Where should the parameters needed for PoP key distribution should be defin= ed? Currently, they are defined in two places -- in https://tools.ietf.org/= html/draft-ietf-ace-oauth-authz-13 and also in https://tools.ietf.org/html/= draft-ietf-oauth-pop-key-distribution-03. In particular, the audience and t= he token_type parameters are defined in both specs. IMHO it appears that OAuth would be the best place to define the HTTP-based= parameters. ACE could define the IoT-based protocols, such as CoAP, MQTT, = and alike. Of course, this is subject for discussion, particularly if there= is no interest in doing so in the OAuth working group. There is also a misalignment in terms of the content. draft-ietf-oauth-pop-= key-distribution defined an 'alg' parameter, which does not exist in the dr= aft-ietf-ace-oauth-authz document. The draft-ietf-ace-oauth-authz document = does, however, have a profile parameter, which does not exist in draft-ietf= -oauth-pop-key-distribution. Some alignment is therefore needed. In the mea= nwhile the work on OAuth meta has been finalized and could potentially be r= e-used. When the work on draft-ietf-oauth-pop-key-distribution was initially starte= d there was only a single, standardized token format, namely the JWT. Hence= , it appeared reasonable to use the JWT keying structure for delivering key= ing material from the AS to the client. In the meanwhile two other formats have been standardized, namely RFC 7635 = and the CWT. For use with those specs it appears less ideal to transport ke= ys from the AS to the client using the JSON/JOSE-based format. It would be = more appropriate to use whatever PoP token format is used instead. Currentl= y, this hasn't been considered yet. 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_VI1PR0801MB21129BCC73AB78D6B06B1044FA420VI1PR0801MB2112_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Note that I posted a m= ail to the OAuth list about the PoP key distribution, which also relates to= the work on ACE-OAuth.

If you are interested = in this topic please feel free to join the discussion on the OAuth mailing = list.

 

From: Hannes Tschofenig
Sent: 03 July 2018 21:46
To: oauth@ietf.org
Subject: PoP Key Distribution

 

Hi all,

 

we have been working on an update for the draft-ietf= -oauth-pop-key-distribution document in time for the deadline but we notice= d several issues that are worthwhile to bring to your attention.

 

draft-ietf-oauth-pop-key-distribution defines a mech= anism that allows the client to talk to the AS to request a PoP access toke= n and associated keying material.

 

There are two other groups in the IETF where this co= ncept is used.

 

=B7         The guys working on RTCWEB is the first. Mis= i (M=E9sz=E1ros Mih=E1ly) has been helping us to understand their needs. Th= ey have defined their own token format, which has been posted on the OAuth = group a while ago for review.

 

=B7         The other group is ACE with their work on an= OAuth-based profile for IoT.

 

Where should the parameters needed for PoP key distr= ibution should be defined? Currently, they are defined in two places -- in https= ://tools.ietf.org/html/draft-ietf-ace-oauth-authz-13 and also in https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03<= /a>. In particular, the audience and the token_type parameters are defined = in both specs.

 

IMHO it appears that OAuth would be the best place t= o define the HTTP-based parameters. ACE could define the IoT-based protocol= s, such as CoAP, MQTT, and alike. Of course, this is subject for discussion= , particularly if there is no interest in doing so in the OAuth working group.

 

There is also a misalignment in terms of the content= . draft-ietf-oauth-pop-key-distribution defined an 'alg' parameter, which d= oes not exist in the draft-ietf-ace-oauth-authz document. The draft-ietf-ac= e-oauth-authz document does, however, have a profile parameter, which does not exist in draft-ietf-oauth-pop-key= -distribution. Some alignment is therefore needed. In the meanwhile the wor= k on OAuth meta has been finalized and could potentially be re-used.

 

When the work on draft-ietf-oauth-pop-key-distributi= on was initially started there was only a single, standardized token format= , namely the JWT. Hence, it appeared reasonable to use the JWT keying struc= ture for delivering keying material from the AS to the client.

 

In the meanwhile two other formats have been standar= dized, namely RFC 7635 and the CWT. For use with those specs it appears les= s ideal to transport keys from the AS to the client using the JSON/JOSE-bas= ed format. It would be more appropriate to use whatever PoP token format is used instead. Currently, this hasn't b= een considered yet.

 

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_VI1PR0801MB21129BCC73AB78D6B06B1044FA420VI1PR0801MB2112_-- From nobody Tue Jul 3 13:13: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 1F7A4130DFB for ; Tue, 3 Jul 2018 13:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 mqtpzGeOaTZg for ; Tue, 3 Jul 2018 13:13:27 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640139.outbound.protection.outlook.com [40.107.64.139]) (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 D1DAA130DF6 for ; Tue, 3 Jul 2018 13:13:26 -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=lQJ+0qnu0wDkq+SNTmeVJEHemsdVzFFzzuhRW3f4ogg=; b=fLYgpIBnS6KPn1jgRH1oZfI6rz9YncCs/s3ZvW6mE9Og9efJQzm/aG/4LMmHm6Rr1C+uU6VJDlYgzgOgbg45eS6RVlL2NO6HeUuGwkrD1SZB/A2f6ezdIuPomKElrYD0HcTOq4X8UtBAjkxrikzRk2wbNjRFvOqTSe9o8LRM3Dw= Received: from DM5PR00MB0293.namprd00.prod.outlook.com (52.132.128.34) by DM5PR00MB0373.namprd00.prod.outlook.com (52.132.129.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.965.0; Tue, 3 Jul 2018 20:13:06 +0000 Received: from DM5PR00MB0293.namprd00.prod.outlook.com ([fe80::4585:e342:2207:ca93]) by DM5PR00MB0293.namprd00.prod.outlook.com ([fe80::4585:e342:2207:ca93%4]) with mapi id 15.20.0967.000; Tue, 3 Jul 2018 20:13:06 +0000 From: Mike Jones To: Hannes Tschofenig , "ace@ietf.org" Thread-Topic: PoP Key Distribution Thread-Index: AdQTBj47ZlOcOW2pSHSpIBiWadk6FgAAD6QAAADejbA= Date: Tue, 3 Jul 2018 20:13:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.47.80.188] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR00MB0373; 6:A93erWDWyq1bulmkH8y97PTmnOgojQdYYJjhS57SXIXaKWkygYw3iNVtIT7wFHeJo4pnm523rFuGhcs5jnzuJWPUuwYMSC9cbTmv1jJp+g1vBQ+2tb8C0118dRHOnXYZDOmbo4Y7QfhXDIQRKf4uNGu56dzxys++IwLXTl4t2PhUAAQMpydFPXusVkffawCmXotUBjmBgnZkLrcmDHU/qis5nABH66t3pFlEu9QbIMCUYwtIgz1Qf/Tyr97jGDKCpquailBzunhcy/DaiJLLXBR/+12WGPu4oyK8pZlsiWGsYLOHVrkURDQyJY65uigww1Jkpm2J71+HvnF2hQAxB1st0BYFo0ib18ui60eGUEVHakOuGPMOFsVaQ9jui3puGDAr70UeKLYpqswhDLOqJa2JRa/1610Bl4nFdtHP9nYtE99YFVhJ91jJD4sHZj0ocC41lp0E6b73tYZYyKuMqA==; 5:7trHq8F2eJJYMfK/H+zFwuY9hm92yBAe9+8G6G7hrk/dZMHhowp0P1xIKyZFc7MZYp6pJ52t8U1vT5p4C/o3gwg0+jxBm42K4w/xKEdAqL3VeuMSikE6nwx+pL2jx78x7Y3lnb+RxkKrFwRv1P3SnUp2+UUGX0yJ97IeUncbKLE=; 7:G84ir6ne1eah7VdpljvNr27pLWcoKDGV4nx98JDXfCB7UihQVVOhjxRcz1ug6123qsc5DbPLW/zM+VFfnm3bqMW72V3L1qRCTodWO0IAc6yd8/M9hN9v/Peg4krmYlAulSJt8fy16risgUb/d2inj0e7Ol752MoyibqvpdxYqWjmSX3eYGxQ4zZS3VpAXaHh3sFHOiaoc6RuSMk3eJq1N5zMXWiswck/9CL+raSscH7So0AcjexsDbe2eypluCPP x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 4828390c-d7d4-4d85-0c48-08d5e12163c4 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:(223705240517415); BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7193020); SRVR:DM5PR00MB0373; x-ms-traffictypediagnostic: DM5PR00MB0373: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(223705240517415)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(10201501046)(3231280)(2018427008)(944501410)(52105095)(93006095)(93001095)(3002001)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:DM5PR00MB0373; BCL:0; PCL:0; RULEID:; SRVR:DM5PR00MB0373; x-forefront-prvs: 0722981D2A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(376002)(366004)(39860400002)(396003)(346002)(189003)(199004)(40434004)(53754006)(54896002)(99286004)(97736004)(8990500004)(3846002)(790700001)(74316002)(7116003)(6116002)(2900100001)(6246003)(2906002)(5660300001)(110136005)(33656002)(7736002)(25786009)(3480700004)(66066001)(19609705001)(6436002)(476003)(486006)(966005)(72206003)(10090500001)(22452003)(102836004)(14454004)(106356001)(2501003)(81156014)(68736007)(606006)(256004)(14444005)(5250100002)(105586002)(5024004)(81166006)(53936002)(229853002)(9686003)(26005)(8676002)(8936002)(55016002)(7696005)(86612001)(316002)(6506007)(186003)(86362001)(53546011)(76176011)(6306002)(10290500003)(236005)(11346002)(478600001)(446003)(11634002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR00MB0373; H:DM5PR00MB0293.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: vh9OoiNrsPDXGtNQiwtgV86sRzkAf8Y+PW9PYcgJNIpcqGL30N6hPuHTtOqi9TbF8j+hbks6/A7Z2wIACdQX1tpau8FF9v0WudWNZC7o3XHZiJlEl+J0i0yPo39RClL/c/wvi7CSXrFQSlBVQaC7wcLvUSZ4d+PGZ8/Ehcx5Gki6SajYqtrvE3JKGvtGXIr9XD6ZShrPxVBeRcn26HDEJ7us87q9j+fujrLKfM94Ej1hvObzVnNEpJHBQn+ONRa7EV9WKfRRihry8/L9+n9ECpAQu7xH5W+YPVLghIzGgjNKvr9OLEJZL6UEyrnG+9DlQXrjsKCNSAy3jr5WudARHuRAPC5OMlkDcJWoUiQ3wIA= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR00MB0293974A86883904605A2875F5420DM5PR00MB0293namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4828390c-d7d4-4d85-0c48-08d5e12163c4 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2018 20:13:06.5175 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0373 Archived-At: Subject: Re: [Ace] PoP Key Distribution X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 20:13:29 -0000 --_000_DM5PR00MB0293974A86883904605A2875F5420DM5PR00MB0293namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I've replied on the OAuth mailing list. You can join it at https://www.iet= f.org/mailman/listinfo/oauth to participate in the discussion. From: Ace On Behalf Of Hannes Tschofenig Sent: Tuesday, July 3, 2018 12:47 PM To: ace@ietf.org Subject: [Ace] FW: PoP Key Distribution Note that I posted a mail to the OAuth list about the PoP key distribution,= which also relates to the work on ACE-OAuth. If you are interested in this topic please feel free to join the discussion= on the OAuth mailing list. From: Hannes Tschofenig Sent: 03 July 2018 21:46 To: oauth@ietf.org Subject: PoP Key Distribution Hi all, we have been working on an update for the draft-ietf-oauth-pop-key-distribu= tion document in time for the deadline but we noticed several issues that a= re worthwhile to bring to your attention. draft-ietf-oauth-pop-key-distribution defines a mechanism that allows the c= lient to talk to the AS to request a PoP access token and associated keying= material. There are two other groups in the IETF where this concept is used. * The guys working on RTCWEB is the first. Misi (M=E9sz=E1ros Mih=E1ly)= has been helping us to understand their needs. They have defined their own= token format, which has been posted on the OAuth group a while ago for rev= iew. * The other group is ACE with their work on an OAuth-based profile for = IoT. Where should the parameters needed for PoP key distribution should be defin= ed? Currently, they are defined in two places -- in https://tools.ietf.org/= html/draft-ietf-ace-oauth-authz-13 and also in https://tools.ietf.org/html/= draft-ietf-oauth-pop-key-distribution-03. In particular, the audience and t= he token_type parameters are defined in both specs. IMHO it appears that OAuth would be the best place to define the HTTP-based= parameters. ACE could define the IoT-based protocols, such as CoAP, MQTT, = and alike. Of course, this is subject for discussion, particularly if there= is no interest in doing so in the OAuth working group. There is also a misalignment in terms of the content.. draft-ietf-oauth-pop= -key-distribution defined an 'alg' parameter, which does not exist in the d= raft-ietf-ace-oauth-authz document. The draft-ietf-ace-oauth-authz document= does, however, have a profile parameter, which does not exist in draft-iet= f-oauth-pop-key-distribution. Some alignment is therefore needed. In the me= anwhile the work on OAuth meta has been finalized and could potentially be = re-used. When the work on draft-ietf-oauth-pop-key-distribution was initially starte= d there was only a single, standardized token format, namely the JWT. Hence= , it appeared reasonable to use the JWT keying structure for delivering key= ing material from the AS to the client. In the meanwhile two other formats have been standardized, namely RFC 7635 = and the CWT. For use with those specs it appears less ideal to transport ke= ys from the AS to the client using the JSON/JOSE-based format. It would be = more appropriate to use whatever PoP token format is used instead. Currentl= y, this hasn't been considered yet. 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_DM5PR00MB0293974A86883904605A2875F5420DM5PR00MB0293namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I’ve replied on = the OAuth mailing list.  You can join it at https://www.ietf.or= g/mailman/listinfo/oauth to participate in the discussion.

 

From: Ace <ace-bounces@ietf.org> On = Behalf Of Hannes Tschofenig
Sent: Tuesday, July 3, 2018 12:47 PM
To: ace@ietf.org
Subject: [Ace] FW: PoP Key Distribution

 

Note th= at I posted a mail to the OAuth list about the PoP key distribution, which = also relates to the work on ACE-OAuth.

If you = are interested in this topic please feel free to join the discussion on the= OAuth mailing list.

 <= /span>

From: Hannes Tschofenig
Sent: 03 July 2018 21:46
To: oauth@ietf.org
Subject: PoP Key Distribution=

 

Hi all,

 

we have been working on an upda= te for the draft-ietf-oauth-pop-key-distribution document in time for the d= eadline but we noticed several issues that are worthwhile to bring to your = attention.

 

draft-ietf-oauth-pop-key-distri= bution defines a mechanism that allows the client to talk to the AS to requ= est a PoP access token and associated keying material.

 

There are two other groups in t= he IETF where this concept is used.

 

  • The guys working on RTCWEB is the first. Misi (M= =E9sz=E1ros Mih=E1ly) has been helping us to understand their needs. They h= ave defined their own token format, which has been posted on the OAuth group a while ago for review. <= /li>

 

  • The other group is ACE with their work on an OAu= th-based profile for IoT.

 

Where should the parameters nee= ded for PoP key distribution should be defined? Currently, they are defined= in two places -- in https= ://tools.ietf.org/html/draft-ietf-ace-oauth-authz-13 and also in https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03<= /a>. In particular, the audience and the token_type parameters are defined = in both specs.

 

IMHO it appears that OAuth woul= d be the best place to define the HTTP-based parameters. ACE could define t= he IoT-based protocols, such as CoAP, MQTT, and alike. Of course, this is s= ubject for discussion, particularly if there is no interest in doing so in the OAuth working group.

 

There is also a misalignment in= terms of the content.. draft-ietf-oauth-pop-key-distribution defined an 'a= lg' parameter, which does not exist in the draft-ietf-ace-oauth-authz docum= ent. The draft-ietf-ace-oauth-authz document does, however, have a profile parameter, which does not exist in = draft-ietf-oauth-pop-key-distribution. Some alignment is therefore needed. = In the meanwhile the work on OAuth meta has been finalized and could potent= ially be re-used.

 

When the work on draft-ietf-oau= th-pop-key-distribution was initially started there was only a single, stan= dardized token format, namely the JWT. Hence, it appeared reasonable to use= the JWT keying structure for delivering keying material from the AS to the client.

 

In the meanwhile two other form= ats have been standardized, namely RFC 7635 and the CWT. For use with those= specs it appears less ideal to transport keys from the AS to the client us= ing the JSON/JOSE-based format. It would be more appropriate to use whatever PoP token format is used instead. Curr= ently, this hasn't been considered yet.

 

Ciao

Hannes

 

IMPORTANT NOTICE: The contents = of this email and any attachments are confidential and may also be privileg= ed. If you are not the intended recipient, please notify the sender immedia= tely and do not disclose the contents to any other person, use it for any purpose, or store or copy the informat= ion in any medium. Thank you.

--_000_DM5PR00MB0293974A86883904605A2875F5420DM5PR00MB0293namp_-- From nobody Wed Jul 4 01:53: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 4074D130ED7; Wed, 4 Jul 2018 01:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 t3pVa8xCJXcM; Wed, 4 Jul 2018 01:53:12 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0199.hostedemail.com [216.40.44.199]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3FA4130EFF; Wed, 4 Jul 2018 01:53:11 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay06.hostedemail.com (Postfix) with ESMTP id D7CF21821F424; Wed, 4 Jul 2018 08:53:10 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::, RULES_HIT:1:2:41:72:152:355:379:582:599:960:962:967:968:973:982:983:988:989:1152:1189:1208:1212:1221:1260:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1575:1588:1589:1592:1594:1605:1606:1712:1730:1776:1792:2068:2069:2198:2199:2525:2527:2528:2553:2559:2564:2682:2685:2689:2691:2692:2693:2734:2736:2859:2894:2897:2911:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3308:3622:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:4321:4362:4425:5007:6117:6119:6261:6657:6678:7875:7903:8603:8985:9025:10004:10848:11657:11658:11854:11914:12043:12109:12114:12257:12295:12663:12679:12740:12895:13137:13138:13139:13149:13150:13161:13229:13230:13231:13439:13972:13991:14096:14149:21060:21063:21080:21324:21433:21451:21627:30003:30012:30041:30054:30090, 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, Netc X-HE-Tag: group79_38d246c284d59 X-Filterd-Recvd-Size: 12135 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf13.hostedemail.com (Postfix) with ESMTPA; Wed, 4 Jul 2018 08:53:10 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_47c04602636eba4035f80f0e6fd8c98b" Date: Wed, 04 Jul 2018 10:53:09 +0200 From: Peter van der Stok To: Jim Schaad Cc: draft-ietf-ace-coap-est@ietf.org, 'ace' Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <032f01d41140$20027c80$60077580$@augustcellars.com> References: <032f01d41140$20027c80$60077580$@augustcellars.com> Message-ID: <58f0553599ed74abd4b97db321cb5f1f@bbhmail.nl> X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [82.95.140.48] Archived-At: Subject: Re: [Ace] Review draft-ietf-ace-coap-est X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 08:53:27 -0000 --=_47c04602636eba4035f80f0e6fd8c98b Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Hi Jim, Many thanks for the review. See our answers below. * In section 4.1 I have a question about what you are using for payload content encoding. Part of this might just be a question of how you plan to move from ASN.1 to CBOR at some point in the future. I think that it would necessitate doing new media-types in that event. You appear to be doing a CBOR bstr wrapping on the ASN.1 encoding payload. I don't believe that there is any reason for doing this. I would expect that the payload would be the ASN.1 w/o any ASN.1. It is highly possible that I am just mis-reading what the text says and this is what you say. What I wanted to do, and did not express very well. Keep the ASN.1 structure of the payload; (re-using code) Use straight binary coding instead of the base64-encoded (30% payload reduction) Wrap the binary in a CBOR major type 2 h'xxx' notation. (compatibility with multipart) Not sure if this needs a new media type, the http content-coding and transfer-coding registries were not very helpful. * In section 5.0 - As written, the example of doing a query against /.well-known/core does not match my understanding of what would be return. It should only return those resources which have the rt field set on them. I do not understand why you believe that the following lines MAY be returned. Clarification of why you think this is true would be appreciated. Thanks for your reaction, I hesitated between two choices. * Provide every line with another rt=ace.est.crts; rt=ace.est.sen; etc. * Make them all ace.est. There are no structure guidelines on rt= value, which complicates things. Looking forward to your (and others) opinion. * Section 6 - Is there a need to have all of this description around TLS-unique? Do you have a reason to believe that people are going get this implemented wrong? This come from experience. The implementation we had done in the past did not implement it correctly, that is why we expanded on the TLS-unique. We will see about shrinking the text in the draft. * Section 7 - I think the figure has an error associated w/ it. The CA should be tied to the EST Server and not to the Registrar Thank you, we will fix that in the next iteration. * Section 7 - Your language is a bit sloppy around the terms of POP and POP linking. Unless it is really badly behaved, POP should never be broken by an RA. The POP is the signature on the request and not tied to the TLS channel. The POP linking is tied to the TLS channel and is broken by the changing of the TLS sessions (client <-> RA, RA <-> CA) Very good catch. We will tighten the language in the next iteration. * Section 7 - It is not clear to me that the SHOULD on reassembly of fragmentation is not a MUST. I doubt that any EST server is going to be able to deal with getting fragments of requests from a registrar in separate messages. This would be compounded if the proxy is handling multiple sessions at the same time. I think that is reasonable. We will address it. * Section 7 - It should be possible that when doing key generation for the protection of the private key to be end-to-end and it should not be necessary for the Proxy to decrypt and then re-encrypt the private key. It should not matter for this if one does either symmetric or asymmetric encryption of the private key. Proxy: you mean Registrar. The wish is understood, we'll look into it. * Section 7 - It is very possible that the private key generation function would be hosted on the proxy and not at the CA. I think that you might want to describe this as a normal configuration. (Just spotted this in the Security considerations. I think it should be here as well.) Yes, right. We need to be crisper on the document that end to end or proxy can provide this functionality. We will make sure it is clear in the text. * Section 9.1 - application/multipart-core should not be in the table of items for IANA to register. This is being done in a different document. If you want this table as a whole then it needs to be moved out of IANA considerations. Absolutely right. Content-format is also specified I multipart-ct; did not see that. Will remove the entry. * Section 9.2 - please expand this text some. You might want to look at https://tools.ietf.org/html/rfc7390#section-6.1 for a template. Will do Thanks Jim, This really helps to improve the document Peter, Panos Jim Schaad schreef op 2018-07-01 15:33: > --=_47c04602636eba4035f80f0e6fd8c98b Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi Jim,

Many thanks for the review. See our answers below.

* In section 4.1 I have a question about what you are using for payload = content encoding.  Part of this might just be a question of how you pl= an to move from ASN.1 to CBOR at some point in the future.  I think th= at it would necessitate doing new media-types in that event.  You appe= ar to be doing a CBOR bstr wrapping on the ASN.1 encoding payload.  I = don't believe that there is any reason for doing this.  I would expect= that the payload would be the ASN.1 w/o any ASN.1.  It is highly poss= ible that I am just mis-reading what the text says and this is what you say= =2E

<pvds>

What I wanted to do, and did not express very well.

Keep the ASN.1 structure of the payload; (re-using code)

Use straight binary coding instead of the base64-encoded (30% payload re= duction)

Wrap the binary in a CBOR major type 2 h’xxx’ notation. (com= patibility with multipart)

Not sure if this needs a new media type, the http content-coding and tra= nsfer-coding registries were not very helpful.

</pvds>

* In section 5.0 - As written, the example of= doing a query against /.well-known/core does not match my understanding of= what would be return.
It should only return those resources which ha= ve the rt field set on them.
I do not understand why you believe that= the following lines MAY be returned.  Clarification of why you think = this is true would be appreciated.

<pvds>

Thanks for your reaction, I hesitated between two choices.

  • Provide every line with another rt=3Dace.est.crts; rt=3Dace.est.sen; et= c.
  • Make them all ace.est.

There are no structure guidelines on rt=3D value, which complicates thin= gs.

Looking forward to your (and others) opinion.

</pvds>

* Section 6 - Is there a need to have all of = this description around TLS-unique?  Do you have a reason to believe t= hat people are going get this implemented wrong?

<pan>
This come from experience. The implementation we had d= one in the past did not implement it correctly, that is why we expanded on = the TLS-unique. We will see about shrinking the text in the draft. 

</pan>

* Section 7 - I think the figure has an error = associated w/ it.  The CA should be tied to the EST Server and not to = the Registrar

<pan>
Thank you, we will fix that in the next iteration.

</pan>

* Section 7 - Your language is a bit sloppy ar= ound the terms of POP and POP linking.  Unless it is really badly beha= ved, POP should never be broken by an RA.  The POP is the signature on= the request and not tied to the TLS channel.  The POP linking is tied= to the TLS channel and is broken by the changing of the TLS sessions (clie= nt <-> RA,  RA <-> CA) 

<pan>
Very good catch. We will tighten the language in the n= ext iteration.

</pan>

* Section 7 - It is not clear to me that the S= HOULD on reassembly of fragmentation is not a MUST.  I doubt that any = EST server is going to be able to deal with getting fragments of requests f= rom a registrar in separate messages.  This would be compounded if the= proxy is handling multiple sessions at the same time. 

<pan>
I think that is reasonable. We will address it. <= /p>

</pan>

* Section 7 - It should be possible that when = doing key generation for the protection of the private key to be end-to-end= and it should not be necessary for the Proxy to decrypt and then re-encryp= t the private key.  It should not matter for this if one does either s= ymmetric or asymmetric encryption of the private key.

<pvds>

Proxy: you mean Registrar.

The wish is understood, we’ll look into it.

</pvds>

* Section 7 - It is very possible that the pr= ivate key generation function would be hosted on the proxy and not at the C= A.  I think that you might want to describe this as a normal configura= tion.  (Just spotted this in the Security considerations.  I thin= k it should be here as well.)

<pan>
Yes, right. We need to be crisper on the document that= end to end or proxy can provide this functionality. We will make sure it i= s clear in the text. 

</pan>

* Section 9.1 - application/multipart-core sho= uld not be in the table of items for IANA to register.  This is being = done in a different document.  If you want this table as a whole then = it needs to be moved out of IANA considerations.

<pvds>

Absolutely right. Content-format is also specified I multipart-ct; did n= ot see that. Will remove the entry.

</pvds>

* Section 9.2 - please expand this text some= =2E  You might want to look at
https://tools.ietf.org/html/rfc7390#sectio= n-6.1 for a template.

<pvds>

Will do

</pvds>

Thanks Jim, This really helps to improve the document


Peter, Panos


Jim Schaad schreef op 2018-07-01 15:33:

=  
--=_47c04602636eba4035f80f0e6fd8c98b-- From nobody Wed Jul 4 06:30: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 86375130F50; Wed, 4 Jul 2018 06:30:17 -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 J_IkCBmr75ut; Wed, 4 Jul 2018 06:30:14 -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 CDB59130F1E; Wed, 4 Jul 2018 06:30:13 -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; Wed, 4 Jul 2018 06:26:39 -0700 From: Jim Schaad To: CC: , 'ace' References: <032f01d41140$20027c80$60077580$@augustcellars.com> <58f0553599ed74abd4b97db321cb5f1f@bbhmail.nl> In-Reply-To: <58f0553599ed74abd4b97db321cb5f1f@bbhmail.nl> Date: Wed, 4 Jul 2018 06:29:42 -0700 Message-ID: <000a01d4139b$12a0be50$37e23af0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01D41360.6642F7C0" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQKjE10J+6girvZOsYQUQD5x+QOohAJu3Jrlos2WpeA= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] Review draft-ietf-ace-coap-est X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 13:30:18 -0000 ------=_NextPart_000_000B_01D41360.6642F7C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Peter van der Stok =20 Sent: Wednesday, July 4, 2018 1:53 AM To: Jim Schaad Cc: draft-ietf-ace-coap-est@ietf.org; 'ace' Subject: Re: [Ace] Review draft-ietf-ace-coap-est =20 Hi Jim, Many thanks for the review. See our answers below. * In section 4.1 I have a question about what you are using for payload = content encoding. Part of this might just be a question of how you plan = to move from ASN.1 to CBOR at some point in the future. I think that it = would necessitate doing new media-types in that event. You appear to be = doing a CBOR bstr wrapping on the ASN.1 encoding payload. I don't = believe that there is any reason for doing this. I would expect that = the payload would be the ASN.1 w/o any ASN.1. It is highly possible = that I am just mis-reading what the text says and this is what you say. What I wanted to do, and did not express very well. Keep the ASN.1 structure of the payload; (re-using code) Use straight binary coding instead of the base64-encoded (30% payload = reduction) Wrap the binary in a CBOR major type 2 h=E2=80=99xxx=E2=80=99 notation. = (compatibility with multipart) Not sure if this needs a new media type, the http content-coding and = transfer-coding registries were not very helpful. [JLS] I do not believe that the wrapping of content with the CBOR = binary text wrapping is needed at this point. If that is needed for the = multi-part wrapping, then it is the job of the multi-part wrapping to = deal with this problem. Multipart needs to be able to say I have a = multipart of neither of which are CBOR objects. = Therefor there is no reason for you to use a CBOR wrapper for this and = not just use the binary value. * In section 5.0 - As written, the example of doing a query against = /.well-known/core does not match my understanding of what would be = return. It should only return those resources which have the rt field set on = them. I do not understand why you believe that the following lines MAY be = returned. Clarification of why you think this is true would be = appreciated. Thanks for your reaction, I hesitated between two choices. * Provide every line with another rt=3Dace.est.crts; rt=3Dace.est.sen; = etc. * Make them all ace.est. There are no structure guidelines on rt=3D value, which complicates = things. Looking forward to your (and others) opinion. [JLS] This is probably a don=E2=80=99t ask me question because I am not = a deployer of IoT objects. I don=E2=80=99t know that there is a good = answer for this. This is probably a good question to toss at the CORE = WG. * Section 6 - Is there a need to have all of this description around = TLS-unique? Do you have a reason to believe that people are going get = this implemented wrong? This come from experience. The implementation we had done in the past = did not implement it correctly, that is why we expanded on the = TLS-unique. We will see about shrinking the text in the draft.=20 * Section 7 - I think the figure has an error associated w/ it. The CA = should be tied to the EST Server and not to the Registrar Thank you, we will fix that in the next iteration. * Section 7 - Your language is a bit sloppy around the terms of POP and = POP linking. Unless it is really badly behaved, POP should never be = broken by an RA. The POP is the signature on the request and not tied = to the TLS channel. The POP linking is tied to the TLS channel and is = broken by the changing of the TLS sessions (client <-> RA, RA <-> CA)=20 Very good catch. We will tighten the language in the next iteration. * Section 7 - It is not clear to me that the SHOULD on reassembly of = fragmentation is not a MUST. I doubt that any EST server is going to be = able to deal with getting fragments of requests from a registrar in = separate messages. This would be compounded if the proxy is handling = multiple sessions at the same time.=20 I think that is reasonable. We will address it.=20 * Section 7 - It should be possible that when doing key generation for = the protection of the private key to be end-to-end and it should not be = necessary for the Proxy to decrypt and then re-encrypt the private key. = It should not matter for this if one does either symmetric or asymmetric = encryption of the private key. Proxy: you mean Registrar. [JLS] Yes I meant Registrar. The wish is understood, we=E2=80=99ll look into it. * Section 7 - It is very possible that the private key generation = function would be hosted on the proxy and not at the CA. I think that = you might want to describe this as a normal configuration. (Just = spotted this in the Security considerations. I think it should be here = as well.) Yes, right. We need to be crisper on the document that end to end or = proxy can provide this functionality. We will make sure it is clear in = the text.=20 * Section 9.1 - application/multipart-core should not be in the table of = items for IANA to register. This is being done in a different document. = If you want this table as a whole then it needs to be moved out of IANA = considerations. Absolutely right. Content-format is also specified I multipart-ct; did = not see that. Will remove the entry. * Section 9.2 - please expand this text some. You might want to look at https://tools.ietf.org/html/rfc7390#section-6.1 for a template. Will do Thanks Jim, This really helps to improve the document =20 Peter, Panos =20 Jim Schaad schreef op 2018-07-01 15:33: =20 ------=_NextPart_000_000B_01D41360.6642F7C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From: Peter = van der Stok <stokcons@bbhmail.nl>
Sent: Wednesday, = July 4, 2018 1:53 AM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: = draft-ietf-ace-coap-est@ietf.org; 'ace' = <ace@ietf.org>
Subject: Re: [Ace] Review = draft-ietf-ace-coap-est

 

Hi = Jim,

Many thanks = for the review. See our answers below.

* In section = 4.1 I have a question about what you are using for payload content = encoding.  Part of this might just be a question of how you plan to = move from ASN.1 to CBOR at some point in the future.  I think that = it would necessitate doing new media-types in that event.  You = appear to be doing a CBOR bstr wrapping on the ASN.1 encoding payload. =  I don't believe that there is any reason for doing this.  I = would expect that the payload would be the ASN.1 w/o any ASN.1.  It = is highly possible that I am just mis-reading what the text says and = this is what you say.

<pvds><= o:p>

What I = wanted to do, and did not express very = well.

Keep the = ASN.1 structure of the payload; (re-using = code)

Use straight = binary coding instead of the base64-encoded (30% payload = reduction)

Wrap the = binary in a CBOR major type 2 h=E2=80=99xxx=E2=80=99 notation. = (compatibility with multipart)

Not sure if = this needs a new media type, the http content-coding and transfer-coding = registries were not very helpful.

</pvds>=

[JLS]=C2=A0 I do not believe that the wrapping = of content with the CBOR binary text wrapping is needed at this = point.=C2=A0 If that is needed for the multi-part wrapping, then it is = the job of the multi-part wrapping to deal with this problem.=C2=A0 = Multipart needs to be able to say I have a multipart of <plain text, = json> neither of which are CBOR objects.=C2=A0 Therefor there is no = reason for you to use a CBOR wrapper for this and not just use the = binary value.



* In = section 5.0 - As written, the example of doing a query against = /.well-known/core does not match my understanding of what would be = return.
It should only return those resources which have the rt field = set on them.
I do not understand why you believe that the following = lines MAY be returned.  Clarification of why you think this is true = would be appreciated.

<pvds><= o:p>

Thanks for = your reaction, I hesitated between two choices.

  • Provide = every line with another rt=3Dace.est.crts; rt=3Dace.est.sen; = etc.
  • Make them = all ace.est.

There are no = structure guidelines on rt=3D value, which complicates = things.

Looking = forward to your (and others) opinion.

</pvds>=

[JLS] This is probably a don=E2=80=99t ask me = question because I am not a deployer of IoT objects.=C2=A0 I = don=E2=80=99t know that there is a good answer for this.=C2=A0 This is = probably a good question to toss at the CORE WG.


* = Section 6 - Is there a need to have all of this description around = TLS-unique?  Do you have a reason to believe that people are going = get this implemented wrong?

<pan>This come from experience. The implementation we had done in the past = did not implement it correctly, that is why we expanded on the = TLS-unique. We will see about shrinking the text in the = draft. 

</pan><= br>
* Section 7 - I think the figure has an error associated w/ it. =  The CA should be tied to the EST Server and not to the = Registrar

<pan>Thank you, we will fix that in the next = iteration.

</pan><= br>
* Section 7 - Your language is a bit sloppy around the terms of = POP and POP linking.  Unless it is really badly behaved, POP should = never be broken by an RA.  The POP is the signature on the request = and not tied to the TLS channel.  The POP linking is tied to the = TLS channel and is broken by the changing of the TLS sessions (client = <-> RA,  RA <-> CA) 

<pan>Very good catch. We will tighten the language in the next = iteration.

</pan><= br>
* Section 7 - It is not clear to me that the SHOULD on reassembly = of fragmentation is not a MUST.  I doubt that any EST server is = going to be able to deal with getting fragments of requests from a = registrar in separate messages.  This would be compounded if the = proxy is handling multiple sessions at the same = time. 

<pan>I think that is reasonable. We will address = it. 

</pan><= br>
* Section 7 - It should be possible that when doing key = generation for the protection of the private key to be end-to-end and it = should not be necessary for the Proxy to decrypt and then re-encrypt the = private key.  It should not matter for this if one does either = symmetric or asymmetric encryption of the private = key.

<pvds><= o:p>

Proxy: you = mean Registrar.

[JLS] Yes I meant = Registrar.

The wish is = understood, we=E2=80=99ll look into it.

</pvds>=

* Section 7 - It is very possible that the private key = generation function would be hosted on the proxy and not at the CA. =  I think that you might want to describe this as a normal = configuration.  (Just spotted this in the Security considerations. =  I think it should be here as well.)

<pan>Yes, right. We need to be crisper on the document that end to end or = proxy can provide this functionality. We will make sure it is clear in = the text. 

</pan><= br>
* Section 9.1 - application/multipart-core should not be in the = table of items for IANA to register.  This is being done in a = different document.  If you want this table as a whole then it = needs to be moved out of IANA = considerations.

<pvds><= o:p>

Absolutely = right. Content-format is also specified I multipart-ct; did not see = that. Will remove the entry.

</pvds>=

* Section 9.2 - please expand this text some.  You might = want to look at
https://tools.ie= tf.org/html/rfc7390#section-6.1 for a = template.

<pvds><= o:p>

Will = do

</pvds>=

Thanks Jim, = This really helps to improve the document

 

Peter, = Panos

 

Jim Schaad = schreef op 2018-07-01 15:33:

 

<= /html> ------=_NextPart_000_000B_01D41360.6642F7C0-- From nobody Mon Jul 9 01:00: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 208B0130E12; Mon, 9 Jul 2018 01:00:40 -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] 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 em8mVbYkNurY; Mon, 9 Jul 2018 01:00:38 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0056.hostedemail.com [216.40.44.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 834A31277CC; Mon, 9 Jul 2018 01:00:38 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay07.hostedemail.com (Postfix) with ESMTP id 976F1181D3368; Mon, 9 Jul 2018 08:00:37 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::::, RULES_HIT:41:152:355:379:582:599:960:962:967:973:988:989:1152:1189:1221:1260:1313:1314:1345:1359:1436:1437:1516:1517:1518:1535:1543:1575:1588:1589:1592:1594:1711:1712:1730:1776:1792:2198:2199:2527:2528:2559:2562:2689:2691:2734:2736:3138:3139:3140:3141:3142:3308:3353:3586:3865:3866:3867:3868:3870:3871:3872:3873:3874:4117:4250:5007:6117:6261:6657:6678:7903:8583:8603:8957:10004:10400:10848:11232:11658:11854:11914:12043:12109:12114:12663:12895:13139:13149:13230:13439:13618:13972:14096:14721:21063:21080:21433:21451:21627:21740:30012:30041: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:25, LUA_SUMMARY:none X-HE-Tag: knee21_2282fd0ca4406 X-Filterd-Recvd-Size: 6597 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf12.hostedemail.com (Postfix) with ESMTPA; Mon, 9 Jul 2018 08:00:37 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_a69cb3c3c9f39b7afc56dfa0eec34088" Date: Mon, 09 Jul 2018 10:00:36 +0200 From: Peter van der Stok To: Jim Schaad Cc: consultancy@vanderstok.org, draft-ietf-ace-coap-est@ietf.org, 'ace' Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <000a01d4139b$12a0be50$37e23af0$@augustcellars.com> References: <032f01d41140$20027c80$60077580$@augustcellars.com> <58f0553599ed74abd4b97db321cb5f1f@bbhmail.nl> <000a01d4139b$12a0be50$37e23af0$@augustcellars.com> Message-ID: <96c584403058b520874889c881cd8665@bbhmail.nl> X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [82.95.140.48] Archived-At: Subject: Re: [Ace] Review draft-ietf-ace-coap-est X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 08:00:41 -0000 --=_a69cb3c3c9f39b7afc56dfa0eec34088 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII > * In section 4.1 I have a question about what you are using for payload content encoding. Part of this might just be a question of how you plan to move from ASN.1 to CBOR at some point in the future. I think that it would necessitate doing new media-types in that event. You appear to be doing a CBOR bstr wrapping on the ASN.1 encoding payload. I don't believe that there is any reason for doing this. I would expect that the payload would be the ASN.1 w/o any ASN.1. It is highly possible that I am just mis-reading what the text says and this is what you say. > > > > What I wanted to do, and did not express very well. > > Keep the ASN.1 structure of the payload; (re-using code) > > Use straight binary coding instead of the base64-encoded (30% payload reduction) > > Wrap the binary in a CBOR major type 2 h'xxx' notation. (compatibility with multipart) > > Not sure if this needs a new media type, the http content-coding and transfer-coding registries were not very helpful. > > > > [JLS] I do not believe that the wrapping of content with the CBOR binary text wrapping is needed at this point. If that is needed for the multi-part wrapping, then it is the job of the multi-part wrapping to deal with this problem. Multipart needs to be able to say I have a multipart of neither of which are CBOR objects. Therefor there is no reason for you to use a CBOR wrapper for this and not just use the binary value. > > > You are right of course, the CBOR wrapping is not needed outside the multipart media type. > However, CBOR wrapping for all payloads, reduces the choices when decoding the payload; They all start the same. > And it adds 2-3 bytes on many. > --=_a69cb3c3c9f39b7afc56dfa0eec34088 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8


* = In section 4.1 I have a question about what you are using for payload conte= nt encoding.  Part of this might just be a question of how you plan to= move from ASN.1 to CBOR at some point in the future.  I think that it= would necessitate doing new media-types in that event.  You appear to= be doing a CBOR bstr wrapping on the ASN.1 encoding payload.  I don't= believe that there is any reason for doing this.  I would expect that= the payload would be the ASN.1 w/o any ASN.1.  It is highly possible = that I am just mis-reading what the text says and this is what you say.

&l= t;pvds>

Wh= at I wanted to do, and did not express very well.<= /p>

Ke= ep the ASN.1 structure of the payload; (re-using code)

Us= e straight binary coding instead of the base64-encoded (30% payload reducti= on)

Wr= ap the binary in a CBOR major type 2 h'xxx' notation. (compatibility with m= ultipart)

No= t sure if this needs a new media type, the http content-coding and transfer= -coding registries were not very helpful.

&l= t;/pvds>

[JLS]  I do not believe that the wrapping of content with the CBOR = binary text wrapping is needed at this point.  If that is needed for t= he multi-part wrapping, then it is the job of the multi-part wrapping to de= al with this problem.  Multipart needs to be able to say I have a mult= ipart of <plain text, json> neither of which are CBOR objects.  = Therefor there is no reason for you to use a CBOR wrapper for this and not = just use the binary value.



<pvds>
You are right of course, the CBOR wrapping is not n= eeded outside the multipart media type.
However, CBOR wrapping for all= payloads, reduces the choices when decoding the payload; They all start th= e same.
And it adds 2-3 bytes on many.
</pvds>

<= /blockquote> --=_a69cb3c3c9f39b7afc56dfa0eec34088-- From nobody Mon Jul 9 05:20: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 11981130E3E; Mon, 9 Jul 2018 05:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, 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 gXNe9HV6yfGA; Mon, 9 Jul 2018 05:20: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 8EAAC130EE7; Mon, 9 Jul 2018 05:20: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; Mon, 9 Jul 2018 05:16:44 -0700 From: Jim Schaad To: CC: , 'ace' References: <032f01d41140$20027c80$60077580$@augustcellars.com> <58f0553599ed74abd4b97db321cb5f1f@bbhmail.nl> <000a01d4139b$12a0be50$37e23af0$@augustcellars.com> <96c584403058b520874889c881cd8665@bbhmail.nl> In-Reply-To: <96c584403058b520874889c881cd8665@bbhmail.nl> Date: Mon, 9 Jul 2018 05:20:02 -0700 Message-ID: <02f701d4177f$2d1dcc40$875964c0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02F8_01D41744.80C0F010" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQKjE10J+6girvZOsYQUQD5x+QOohAJu3JrlAVJ6lF8CfFx/jKK26OZw X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] Review draft-ietf-ace-coap-est X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 12:20:41 -0000 ------=_NextPart_000_02F8_01D41744.80C0F010 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Peter van der Stok =20 Sent: Monday, July 9, 2018 1:01 AM To: Jim Schaad Cc: consultancy@vanderstok.org; draft-ietf-ace-coap-est@ietf.org; 'ace' = Subject: Re: [Ace] Review draft-ietf-ace-coap-est =20 =20 * In section 4.1 I have a question about what you are using for payload = content encoding. Part of this might just be a question of how you plan = to move from ASN.1 to CBOR at some point in the future. I think that it = would necessitate doing new media-types in that event. You appear to be = doing a CBOR bstr wrapping on the ASN.1 encoding payload. I don't = believe that there is any reason for doing this. I would expect that = the payload would be the ASN.1 w/o any ASN.1. It is highly possible = that I am just mis-reading what the text says and this is what you say. What I wanted to do, and did not express very well. Keep the ASN.1 structure of the payload; (re-using code) Use straight binary coding instead of the base64-encoded (30% payload = reduction) Wrap the binary in a CBOR major type 2 h'xxx' notation. (compatibility = with multipart) Not sure if this needs a new media type, the http content-coding and = transfer-coding registries were not very helpful. [JLS] I do not believe that the wrapping of content with the CBOR = binary text wrapping is needed at this point. If that is needed for the = multi-part wrapping, then it is the job of the multi-part wrapping to = deal with this problem. Multipart needs to be able to say I have a = multipart of neither of which are CBOR objects. = Therefor there is no reason for you to use a CBOR wrapper for this and = not just use the binary value. =20 You are right of course, the CBOR wrapping is not needed outside the = multipart media type. However, CBOR wrapping for all payloads, reduces the choices when = decoding the payload; They all start the same. And it adds 2-3 bytes on many. [JLS] I don=E2=80=99t follow this at all. How I read this statement is I have a binary value and I need to look at the content type to figure = out what ASN.1 structure it is and decode it. This is very hard. So I = am going to change this to I need to look at the content type to figure out that I have a CBOR = bstring value. It is easy to remove the CBOR bstring value. I now have = a binary value and I need to look at the content type to figure out what = ASN.1 structure it is and decode it. This is somehow easier. =20 ------=_NextPart_000_02F8_01D41744.80C0F010 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From: Peter = van der Stok <stokcons@bbhmail.nl>
Sent: Monday, July = 9, 2018 1:01 AM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: consultancy@vanderstok.org; = draft-ietf-ace-coap-est@ietf.org; 'ace' = <ace@ietf.org>
Subject: Re: [Ace] Review = draft-ietf-ace-coap-est

 

 

* In section = 4.1 I have a question about what you are using for payload content = encoding.  Part of this might just be a question of how you plan to = move from ASN.1 to CBOR at some point in the future.  I think that = it would necessitate doing new media-types in that event.  You = appear to be doing a CBOR bstr wrapping on the ASN.1 encoding payload. =  I don't believe that there is any reason for doing this.  I = would expect that the payload would be the ASN.1 w/o any ASN.1.  It = is highly possible that I am just mis-reading what the text says and = this is what you say.

<pvds><= o:p>

What I = wanted to do, and did not express very = well.

Keep the = ASN.1 structure of the payload; (re-using = code)

Use straight = binary coding instead of the base64-encoded (30% payload = reduction)

Wrap the = binary in a CBOR major type 2 h'xxx' notation. (compatibility with = multipart)

Not sure if = this needs a new media type, the http content-coding and transfer-coding = registries were not very helpful.

</pvds>=

[JLS]  = I do not believe that the wrapping of content with the CBOR binary text = wrapping is needed at this point.  If that is needed for the = multi-part wrapping, then it is the job of the multi-part wrapping to = deal with this problem.  Multipart needs to be able to say I have a = multipart of <plain text, json> neither of which are CBOR = objects.  Therefor there is no reason for you to use a CBOR wrapper = for this and not just use the binary = value.

 


<pvds&= gt;
You are right of course, the CBOR wrapping is not needed outside = the multipart media type.
However, CBOR wrapping for all payloads, = reduces the choices when decoding the payload; They all start the = same.
And it adds 2-3 bytes on = many.
</pvds>

[JLS]=C2=A0 I don=E2=80=99t follow this = at all.=C2=A0 How I read this statement is

I have a binary value = and I need to look at the content type to figure out what ASN.1 = structure it is and decode it.=C2=A0 This is very hard.=C2=A0 So I am = going to change this to

I need to look at the content type to = figure out that I have a CBOR bstring value.=C2=A0 It is easy to remove = the CBOR bstring value.=C2=A0 I now have a binary value and I need to = look at the content type to figure out what ASN.1 structure it is and = decode it.=C2=A0 This is somehow easier.

 

------=_NextPart_000_02F8_01D41744.80C0F010-- From nobody Thu Jul 12 01:11: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 9E027130ED3 for ; Thu, 12 Jul 2018 01:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.331 X-Spam-Level: X-Spam-Status: No, score=-3.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nyrS_LATw55 for ; Thu, 12 Jul 2018 01:11:21 -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 B6B94130ECE for ; Thu, 12 Jul 2018 01:11:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1531383078; 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=gevvIK+dcj85aVsyJ2DNVbKKwpJX2sRYxb9uo5E9rU0=; b=YfIpuUbOC3eGmfS7jxfBkGeNZifXyu+mhh6V7GmNWxNBrlIGKPf0v+5VIfNL8JqQ za9arHYFsU+QM4VLqTLtndrwDojYgNYCoxhd218fmw6YWLhzpSC6xyGJTZhaN2My Gt9uOqCn2m2JdFZCx5EXoFzt2N8NYlQl3XNVeqmBjk0=; X-AuditID: c1b4fb30-d12a19c000000a77-dc-5b470d26e47c Received: from ESESBMB501.ericsson.se (Unknown_Domain [153.88.183.114]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id BE.96.02679.62D074B5; Thu, 12 Jul 2018 10:11:18 +0200 (CEST) Received: from ESESSMB504.ericsson.se (153.88.183.165) 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; Thu, 12 Jul 2018 10:11:12 +0200 Received: from ESESSMB504.ericsson.se ([153.88.183.192]) by ESESSMB504.ericsson.se ([153.88.183.192]) with mapi id 15.01.1466.003; Thu, 12 Jul 2018 10:11:12 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "ace@ietf.org" CC: Jim Schaad , Roman Danyliw Thread-Topic: New Version Notification for draft-selander-ace-cose-ecdhe-09.txt Thread-Index: AQHUEllAKLhrqwVc+0Wzjp9EkPPXqaSLS32A Date: Thu, 12 Jul 2018 08:11:12 +0000 Message-ID: References: <153057276248.16456.8519243611794804996.idtracker@ietfa.amsl.com> In-Reply-To: <153057276248.16456.8519243611794804996.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [153.88.183.153] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAIsWRmVeSWpSXmKPExsUyM2J7ka4ar3u0wdr7Fhbfv/UwW6ye/p3N 4nMbmwOzx8Y509k8Zmzw8Viy5CdTAHMUl01Kak5mWWqRvl0CV8bFBwkFn4QrGh98ZWtg3CDc xcjJISFgInHnbQdbFyMXh5DAUUaJhsaPzBDON0aJYyc/QDnLGCWuLH7CCtLCJuAi8aDhEVMX IweHiICixPVHiSBhZgFXiYMt+8BKhAX8JN4fWQpmiwgESjx8cwnKNpJYMANkDAcHi4CqxPeD diBhXgELiVOrDrKBhIUEfCXWHzUGCXMCTfn2bgo7iM0oICbx/dQaJohN4hK3nsxngrhfQGLJ nvPMELaoxMvH/8A2iQroSeztaWeDiCtJ7D12nQVkPLOApsT6XfoQY6wl3nb8ZYawFSWmdD9k h7hGUOLkzCcsExglZiHZNguhexaS7llIumch6V7AyLqKUbQ4tTgpN93ISC+1KDO5uDg/Ty8v tWQTIzAeD275bbCD8eVzx0OMAhyMSjy8t/+6RQuxJpYVV+YeYpTgYFYS4b00BSjEm5JYWZVa lB9fVJqTWnyIUZqDRUmc18Jvc5SQQHpiSWp2ampBahFMlomDU6qBUbrQ4my82Eu7P4rmfZ5T A7s8+efGOdaY6Oy8HRsg9u6P0AKTRzovv2ZO7Fx2bFXLyYmN3dmnbffemRvodarGv3jhtAO9 jzmzpQ5Y3P7CKdg89+rEvQL9/IcCTD/PUfzP5Zlt+3uv8nTNnfv/mQWqdNhefb5FMLHcfM2x f+FPwnde8zCf3OF1XYmlOCPRUIu5qDgRAAhLM33DAgAA Archived-At: Subject: [Ace] FW: New Version Notification for draft-selander-ace-cose-ecdhe-09.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 08:11:23 -0000 DQpEZWFyIEFDRSBXRywNCg0KV2Ugc3VibWl0dGVkIGFuIHVwZGF0ZSBvZiBFREhPQyBiZWZvcmUg dGhlIGN1dG9mZi4gQXQgdGhlIHN1cmZhY2UgdGhlcmUNCmFyZSB0d28gbWFpbiBjaGFuZ2VzIGlu IHRoZSBuZXcgdmVyc2lvbjoNCg0KLSBGdXJ0aGVyIHJlZHVjaW5nIHRoZSBtZXNzYWdlIHNpemVz IHN1YnN0YW50aWFsbHkuIEFuIGV4YW1wbGUNCmlsbHVzdHJhdGluZyB0aGlzIGlzIGdpdmVuIGFz IEFwcGVuZGl4IEQuDQoNCi0gTWlub3IgY2hhbmdlcyBmb2xsb3dpbmcgYSBmb3JtYWwgdmVyaWZp Y2F0aW9uIG9mIC0wOCBtYWRlIGJ5IHRoZSBJVA0KVW5pdmVyc2l0eSBvZiBDb3BlbmhhZ2VuLg0K DQpDb21tZW50cyBhcmUgbW9zdCB3ZWxjb21lLiBJZiB0aGVyZSBpcyB0aW1lIG9uIHRoZSBBQ0Ug V0cgYWdlbmRhIHdlIHdvdWxkDQpsaWtlIHRvIGdpdmUgYW4gdXBkYXRlLg0KDQoNCkfDtnJhbg0K DQoNCg0KDQpPbiAyMDE4LTA3LTAzLCAwMTowNiwgImludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIN CjxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KDQo+DQo+QSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LXNlbGFuZGVyLWFjZS1jb3NlLWVjZGhlLTA5LnR4dA0KPmhhcyBiZWVuIHN1 Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSm9obiBNYXR0c3NvbiBhbmQgcG9zdGVkIHRvIHRoZQ0K PklFVEYgcmVwb3NpdG9yeS4NCj4NCj5OYW1lOgkJZHJhZnQtc2VsYW5kZXItYWNlLWNvc2UtZWNk aGUNCj5SZXZpc2lvbjoJMDkNCj5UaXRsZToJCUVwaGVtZXJhbCBEaWZmaWUtSGVsbG1hbiBPdmVy IENPU0UgKEVESE9DKQ0KPkRvY3VtZW50IGRhdGU6CTIwMTgtMDctMDINCj5Hcm91cDoJCUluZGl2 aWR1YWwgU3VibWlzc2lvbg0KPlBhZ2VzOgkJMzANCj5VUkw6ICAgICAgICAgICAgDQo+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXNlbGFuZGVyLWFjZS1jb3NlLWVj ZGhlLTA5LnR4dA0KPlN0YXR1czogICAgICAgICANCj5odHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1zZWxhbmRlci1hY2UtY29zZS1lY2RoZS8NCj5IdG1saXplZDogICAgICAg DQo+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNlbGFuZGVyLWFjZS1jb3NlLWVj ZGhlLTA5DQo+SHRtbGl6ZWQ6ICAgICAgIA0KPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2h0bWwvZHJhZnQtc2VsYW5kZXItYWNlLWNvc2UtZWNkaGUNCj5EaWZmOiAgICAgICAgICAg DQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXNlbGFuZGVyLWFjZS1j b3NlLWVjZGhlLTA5DQo+DQo+QWJzdHJhY3Q6DQo+ICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMg RXBoZW1lcmFsIERpZmZpZS1IZWxsbWFuIE92ZXIgQ09TRSAoRURIT0MpLCBhDQo+ICAgY29tcGFj dCwgYW5kIGxpZ2h0d2VpZ2h0IGF1dGhlbnRpY2F0ZWQgRGlmZmllLUhlbGxtYW4ga2V5IGV4Y2hh bmdlDQo+ICAgd2l0aCBlcGhlbWVyYWwga2V5cyB0aGF0IGNhbiBiZSB1c2VkIG92ZXIgYW55IGxh eWVyLiAgRURIT0MgbWVzc2FnZXMNCj4gICBhcmUgZW5jb2RlZCB3aXRoIENCT1IgYW5kIENPU0Us IGFsbG93aW5nIHJldXNlIG9mIGV4aXN0aW5nIGxpYnJhcmllcy4NCj4NCj4gICAgICAgICAgICAg ICAgICANCj4gICAgICAgIA0KPg0KPg0KPlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+c3VibWlzc2lvbg0KPnVudGlsIHRo ZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5v cmcuDQo+DQo+VGhlIElFVEYgU2VjcmV0YXJpYXQNCj4NCg0K From nobody Thu Jul 12 10:55: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 650C8130E58 for ; Thu, 12 Jul 2018 10:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 5yK37qTh4Dm5 for ; Thu, 12 Jul 2018 10:55:47 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 BE1BA12F295 for ; Thu, 12 Jul 2018 10:55:47 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w6CHtild040543 for ; Thu, 12 Jul 2018 13:55:44 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu w6CHtild040543 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1531418144; bh=1zTTPGtPrgfKWASWfcaVUg/Vdl5U23d5pdVTW2KXGnM=; h=From:To:Subject:Date:From; b=K+DT6kPFLTaltolei3FGlrrOMdcXp0a/uDU1sFmVWG93clMuUJZUaquuGfdTa1HKM udYx1Fmuu9xgcnF51qWQ8Yhk2CicriAOsxACXRZUCJEQOrBjDJ2FMwZtMDGF5IWZLC cQRADVV/RNJlXaqHFKQZd6T634lFLD9GLPXJFdAw= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w6CHthAP013603 for ; Thu, 12 Jul 2018 13:55:43 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0399.000; Thu, 12 Jul 2018 13:55:43 -0400 From: Roman Danyliw To: "ace@ietf.org" Thread-Topic: Summarizing WGLC discussion of draft-ietf-ace-cwt-proof-of-possession Thread-Index: AdQaB+pCJ/tP7Ud0T+GY5Fn6FrAcuA== Date: Thu, 12 Jul 2018 17:55:42 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC014C3FEDA1@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] Summarizing WGLC discussion of draft-ietf-ace-cwt-proof-of-possession X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 17:55:51 -0000 Hello! This email is intended to summarize the outcome of the WGLC on draft-ietf-a= ce-cwt-proof-of-possession-02 to date. This call was started on May 8 [1] = and discussion occurred around two reviews of this -02 draft: ** Jim Schaad [Schaad], per https://www.ietf.org/mail-archive/web/ace/curre= nt/msg02747.html ** Roman Danyliw [Danyliw], per https://www.ietf.org/mail-archive/web/ace/c= urrent/msg02793.html After discussion on the mailing list, -03 of the draft was produced. =20 Synthesizing the robust mailing list discussion, I see the following previo= usly identified issues as still needing closure. The nature of the resolut= ion varies. Given the volume of the discussion threads, I may have missed = a response or failed to line up a text change in -03 to an issue. Please c= orrect the status of any given point of feedback below. =3D=3D[ -03 contains changes, but ML discussion doesn't indicate closure ]= =3D=3D The following feedback was made about the -02 draft; changes to the relevan= t text was made in -03; but follow-up discussions on the mailing list doesn= 't indicate closure of the issue. If the originator of the feedback (it lo= oks like only Jim for this section) feels the issue is closed, please speak= up. [Schaad #6] Under what circumstances would a 'sub' claim be present and it= is not the presenter? I can see that a holder of the key may be implicitl= y (or anonymously) named, but putting something in the subject field which= is not identifying the presenter is something that I would reject without = a good presentation of why in the document. [Schaad #7] I would disagree with the claim that if the 'sub' claim is mis= sing then it would normally be the issuer. For the world of IoT, I would e= xpect that the subject would not be present because there is no need to ide= ntify the subject to the recipient. I.e. it is an anonymous subject. [Schaad #8] It is not clear to me that either of the sub and iss claims wo= uld normally be present. They might be present but neither is needed. The= subject can be anonymous and the issuer is identified by the key used to v= alidate the security on the CWT. [Schaad #9] In section 3.1 the first two sentences appear to be contradict= ory. Members are used to identify the POP key. Other things than a POP ke= y can be used than a POP key. If they are used to identify the POP key- wh= y would they not deal with the POP key? I think that you should do a separ= ation and define the 'cnf' file which can hold any number of confirmation m= ethods and then have a section on defining some POP cnf method field holder= s. [Schaad #10] In section 3.1 P1 - I am not sure why you have something here= about confirming the authenticity of the token as oppose to confirming the= identity of the presenter. Why would that type of information be placed h= ere where it is not useful.] =3D=3D[ change was proposed, but not made ]=3D=3D The draft editors proposed a changes on the mailing list to address the iss= ue but it did not appear in the -03 draft. =20 See the inline text of https://www.ietf.org/mail-archive/web/ace/current/ms= g02788.html for the proposed changes for [Schaad #12, 13, 16, 21]. [Schaad #12] I am unclear why there should be a restriction on the number o= f POP keys that can be in a 'cnf' object. If there are multiple keys, then= any or all of them are of equal value in doing the confirmation. Just lik= e there can be multiple confirmation methods and an application could choos= e to use any one of them. [Schaad #13] Not sure which section this belongs in, but the use of an COS= E_Encrypt0 would be one way to combat tracking of identities based on the k= ey value being used. Different encrypted values could be sent to different= servers and they would not necessarily know about use w/o internal collusi= on between them. Similar effect by using an encrypted CWT. Potentially re= quires use of TLS1.3 to protect the RPKs. YMMV [Schaad #16] Section 4 - Are audience restrictions not done in CWT? -- sam= e issues as [Danyliw #12] [Schaad #21] Section 6.2.2 - the value type is not an array for COSE_Encryp= t or COSE_Encyrpt0, these are the values. As written I could put in an arr= ay which is not one of those two structures and be valid. Ditto for COSE_= Key, although w/ slightly less justification.=20 See the inline text of https://www.ietf.org/mail-archive/web/ace/current/ms= g02802.html for the proposed change for [Danyliw #7]. [Danyliw #7] Page 6, Section 3.3, The sentence "The COSE_Key could, for ins= tance, be encrypted using a COSE_Encrypt0 representation using the AES-CCM-= 16-64-128 algorithm" seems out of place. What is this text explaining rela= tive to the examples? =3D=3D[ face to face discussion required ]=3D=3D Certain issues were deemed sufficiently complex to required face-to-face di= scussion at IETF 102. [Schaad #14] I have real problems w/ the use of a KID for POP identificati= on. It may identify the wrong key or, if used for granting access, may hav= e problems w/ identity collisions. These need to be spelt out someplace to= help people tracking down questions of why can't I verify w/ this CWT, I k= now it's right. -- See https://www.ietf.org/mail-archive/web/ace/current/ms= g02853.html for more detailed discussion -- related issue to [Danyliw #8]. Regards, Roman [1] https://www.ietf.org/mail-archive/web/ace/current/msg02744.html From nobody Fri Jul 13 11:38: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 D416E130F1E; Fri, 13 Jul 2018 11:38:41 -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 4aH_DR_WTjOK; Fri, 13 Jul 2018 11:38:39 -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 6F981130E6A; Fri, 13 Jul 2018 11:38:39 -0700 (PDT) Received: from Jude (107.18.132.214) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 13 Jul 2018 11:35:06 -0700 From: Jim Schaad To: CC: 'ace' Date: Fri, 13 Jul 2018 14:38:28 -0400 Message-ID: <013e01d41ad8$b2ce7540$186b5fc0$@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: AdQaKsDewY+WehuqT9eenvy1Jp1rRw== Content-Language: en-us X-Originating-IP: [107.18.132.214] Archived-At: Subject: [Ace] Comments on ace key groupcomm -01 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2018 18:38:42 -0000 * Section 2 - client - write rights and/or read rights. Unless you think that write implies read in which case you should state that * Section 2 - KDC - should also say what it does in the later parts - * Section 2 - Dispatcher - If this is a bus, then you are not really communicating with it securely. Anybody can write on it, but people will just ignore what comes out the other end. * Section 3- A brief description of all of the operations would be appreciated. * Section 3.1 - Can I get authorization for multiple items at a single time? * Section 3.1 - Does it make sense to allow for multiple audiences to be on a single KDC? * Section 4.x - cnf - text does not allow for key identifier * Section X.X - Define a new cnf method to hold the OSCORE context parameters - should it be a normal COSE_Key or something new just to makes sure that it is different. * Section 3.X - I am not sure if write or POST is a better answer for what the role being requested is. * Section 4 - Should one talk about the ability to use OBSERVE as part of key distribution? * Section 4.x - I am having a hard time trying to figure out the difference between a group and a topic. The text does not always seem to distinguish these well. * Seciton 4.1 - POP on client key esp if bound to an identity (Note using it to access the KDC is one POP) * Section 4.2 - why not use the exp field from OAUTH in the response * Question - does somebody talk about doing key derivation for a new kid showing up and by the way where is the gid * Seciton 4.2 - if you are using profile, then you should return it * Introduction - introduce the concept of a key management protocol and point to some. Give some basic properties expected from one. * Section 5.2 - What is the message to leave - can I leave one scope but not another? Can I just give up a role? * Seciton 6.1 - assumes scopes are unique across all audiences. Or assumes that I look up the correct token - should have an argument about why this is possible so that people can implement it right * Comment somewhere about getting strike zones setup correctly for a newly seen sender of messages. Ptr to OSCORE? Jim From nobody Sun Jul 15 14:44: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 6972A130E52 for ; Sun, 15 Jul 2018 14:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.92 X-Spam-Level: X-Spam-Status: No, score=-5.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] 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 buQUFDxgCz9J for ; Sun, 15 Jul 2018 14:44:16 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 84D3C130E4A for ; Sun, 15 Jul 2018 14:44:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.51,358,1526335200"; d="scan'208,217";a="273045631" Received: from mail-oi0-f43.google.com ([209.85.218.43]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 15 Jul 2018 23:44:12 +0200 Received: by mail-oi0-f43.google.com with SMTP id d189-v6so71312652oib.6 for ; Sun, 15 Jul 2018 14:44:12 -0700 (PDT) X-Gm-Message-State: AOUpUlFDWjUrppk5gtQ1qhtg/ZgVCQEFxx3/8UZIHbQnCpwrSHY37CRa O1iAgaOv94oMQIvCNyyutjzWQTb0jTC/0I4BUH0= X-Google-Smtp-Source: AAOMgpdHaRJhcIGjyodK41pgxjKWUhfYrLeNiSeFwVpZVWXynq8cor8rrTn0MHUeDjfV0LM+AkEgmuEo1m3C/Vfh7Wk= X-Received: by 2002:aca:3954:: with SMTP id g81-v6mr16848592oia.215.1531691051319; Sun, 15 Jul 2018 14:44:11 -0700 (PDT) MIME-Version: 1.0 From: =?UTF-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= Date: Sun, 15 Jul 2018 23:43:59 +0200 X-Gmail-Original-Message-ID: Message-ID: To: "ace@ietf.org" Content-Type: multipart/alternative; boundary="00000000000005082c0571109df3" Archived-At: Subject: [Ace] Message overhead of the OSCORE profile and ACE specs X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.27 Precedence: 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, 15 Jul 2018 21:44:21 -0000 --00000000000005082c0571109df3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ludwig, all, I am in the process of implementing draft-ietf-ace-oscore-profile-02 for openwsn.org. For now, I have a first implementation of AS available, and will be going to the firmware part in the next weeks. I have to say that I was quite frustrated with the number of drafts that I had to go through in order to understand what should be implemented. Maybe this is implied knowledge for people actively working on ACE, but I believe a guide somewhere pointing to different specs one needs to follow in order to instantiate a profile would be quite beneficial. Here, I'd like to share my comments about the message overhead found when implementing the OSCORE profile and give some optimization proposals. I am mostly concerned with the response from AS to C, where C is in a constrained network. Please bear with me that my understanding of the specs is correct and that my implementation generated correct outputs. Assumptions used in the implementation: - OSCORE channel between AS and C, AS and RS. - AS and RS share an additional key, derived from the OSCORE Master Secret using HKDF label 'ACE' and RS's unique identifier. Explicit monotonically increasing counter kept to generate nonce, incremented for each Encrypt0 object generated towards a given RS. - Profile is implicitly known by all the parties - Scope is implicitly known by all the parties - Audience is implicitly known by all the parties - Default values of OSCORE KDF, salt, id_context To save bytes, I use the following optimizations: - Sending single byte for PIV in COSE Encrypt0 of CWT, the actual AEAD nonce is PIV prepended with zeros - Using single byte for OSCORE IDs in the security context generated by AS With this, I got the CoAP payload from AC to C down to 82 bytes. This overflows 802.15.4 + 6LoWPAN + UDP packet by 29 bytes, assuming the latest OpenWSN implementation implementing most of the cross layer optimizations available and not supporting fragmentation. I copy here output of the payload that I generated: A2 # map(2) 18 19 # unsigned(25) # cnf label A1 # map(1) # cnf 01 # unsigned(1) # COSE_Key label A4 # map(4) # COSE_Key 01 # unsigned(1) # type label 04 # unsigned(4) # symmetric 20 # negative(0) # key value label 50 # bytes(16) # key value 6F92418A5CAA7C639255A1AF0C7B832C # "o\x92A\x8A\\\xAA|c\x92U\xA1\xAF\f{\x83," 06 # unsigned(6) # OSCORE sender id label 41 # bytes(1) # OSCORE sender id value 00 # "\x00" 07 # unsigned(7) # OSCORE recipient id label 41 # bytes(1) # OSCORE recipient id value 01 # "\x01" 13 # unsigned(19) # access_token 58 2F # bytes(47) 8340A106015828E72233134093261AB93634B3413BB46D1273AB98DBE95C4E7E332C754B348= FBC70EC9C921133E8AE where the access token decodes to: 83 # array(3) # COSE_Encrypt0 40 # bytes(0) # protected bucket # "" A1 # map(1) # unprotected bucket 06 # unsigned(6) # PIV label 01 # unsigned(1) # PIV value 58 28 # bytes(40) # ciphertext E72233134093261AB93634B3413BB46D1273AB98DBE95C4E7E332C754B348FBC70EC9C9211= 33E8AE where the corresponding plaintext is: A1 # map(1) 18 19 # unsigned(25) # cnf label A1 # map(1) # cnf 01 # unsigned(1) # COSE_Key label A4 # map(4) # COSE_Key 01 # unsigned(1) # type label 04 # unsigned(4) # symmetric 20 # negative(0) # key value label 50 # bytes(16) # key value 6F92418A5CAA7C639255A1AF0C7B832C # "o\x92A\x8A\\\xAA|c\x92U\xA1\xAF\f{\x83," 06 # unsigned(6) # OSCORE sender id label 41 # bytes(1) # OSCORE sender id value 00 # "\x00" 07 # unsigned(7) # OSCORE recipient id label 41 # bytes(1) # OSCORE recipient id value 01 # "\x01" To this, there is an additional tag of 8 bytes for AES-CCM-16-64-128 that was used. Some points where we could save bytes: - Does cnf label really need to fall into the 2-byte integers space? having the label encoded as a single integer would result in 2 bytes savings, since cnf is present twice - To save bytes, could we not define a specific structure to carry OSCORE context params instead of COSE_Key? For example: [ sender_id : bstr recipient_id : bstr master_secret : bstr ? ( master_salt : bstr / nil, id_context : bstr / nil), ? ( hkdf : uint, alg : uint ) ] In the use case from above with sender_id : h'00', recipient_id : h'01' and master_secret a random 16-byte string, this encodes to 22 bytes. COSE_Key carrying the same thing encodes to 27 bytes, resulting in 5 bytes savings per COSE_Key object, or total of 10 bytes saved in the payload from AS to C= . - Can we not define some sort of a compressed structure using arrays in the OSCORE profile for the cnf claim? Or something like OSCORE's compression flag byte omitting some of these labels? With the current numbers, having a constrained client in OpenWSN simply does not work... Mali=C5=A1a --00000000000005082c0571109df3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ludw= ig, all,

=
I am in t= he process of implementing draft-ietf-ace-oscore-profile-02 for openwsn.org. For now, I have a first implementatio= n of AS available, and will be going to the firmware part in the next weeks= .=C2=A0

I have to say that I was quite frustrated with the numb= er of drafts that I had to go through in order to understand what should be= implemented.=C2=A0Maybe this is impl= ied knowledge for people actively working on ACE, but I believe a guide som= ewhere pointing to different specs one needs to follow in order to instanti= ate a profile would be quite beneficial.

Here, I'd like to share my comments about the mess= age overhead found when implementing the OSCORE profile and give some optim= ization proposals. I am mostly concerned with the response from AS to C, wh= ere C is in a constrained network.
=
Please bear with me that my un= derstanding of the specs is correct and that my implementation generated co= rrect outputs.

Assumptions used in the implementation:=C2=A0
- OSCORE channel between AS and C, AS a= nd RS.
- AS and RS share an additio= nal key, derived from the OSCORE Master Secret using HKDF label 'ACE= 9; and RS's unique identifier. Explicit monotonically increasing counte= r kept to generate nonce, incremented for each Encrypt0 object generated to= wards a given RS.
- Profile is impl= icitly known by all the parties
- S= cope is implicitly known by all the parties
- Audience is implicitly known by all the parties
- Default values of=C2=A0OSCORE KDF, salt, id_context

To save bytes, I use th= e following optimizations:
- Sending single byte for PIV in COSE Encrypt0 of CWT, the actual AE= AD nonce is PIV prepended with zeros
- Using single byte for OSCORE IDs in the security context= generated by AS
With this, I got t= he CoAP payload from AC to C down to 82 bytes. This overflows 802.15.4=C2= =A0+ 6LoWPAN=C2=A0+ UDP packet by 29 bytes, assuming the latest OpenWSN imp= lementation implementing most of the cross layer optimizations available an= d not supporting fragmentation.

I c= opy here output of the payload that I generated:

A2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0# map(2)
=C2=A0 =C2=A018 19 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0# unsigned(25) # cnf label
=C2=A0 =C2=A0A1 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # map(1) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= # cnf =C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0 01 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0# unsigned(1) =C2=A0 =C2=A0# COSE_Key label
=C2= =A0 =C2=A0 =C2=A0 A4 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0# map(4) =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 # COSE_Key
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A001 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # unsigned(1) =C2=A0 =C2=A0# type label=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A004 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # un= signed(4) =C2=A0 # symmetric
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A020= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 # negative(0) =C2=A0 =C2=A0# key value label
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A050 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # bytes(= 16) =C2=A0 =C2=A0 =C2=A0 # key value
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 6F92418A5CAA7C639255A1AF0C7B832C # "o\x92A\x8A\\\xAA|c\x= 92U\xA1\xAF\f{\x83,"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A006 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 # unsigned(6) =C2=A0 # OSCORE sender id label
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A041 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # bytes(= 1) =C2=A0 =C2=A0 =C2=A0 =C2=A0 # OSCORE sender id value
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 00 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0# "\x00" = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A007 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # unsigned(7) =C2=A0# OSCORE recipie= nt id label
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A041 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 # bytes(1) =C2=A0 =C2=A0 =C2=A0 =C2=A0# OSCORE recipient id valu= e
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 01 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0# = "\x01"
=C2=A0 =C2=A013 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 # unsigned(19) # access_token
=C2=A0 =C2=A058 2F = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0# bytes(47) =C2=A0 =C2=A0=C2=A0
= =C2=A0 =C2=A0 =C2=A0 8340A106015828E72233134093261AB93634B3413BB46D1273AB98= DBE95C4E7E332C754B348FBC70EC9C921133E8AE=C2=A0

where the access token decodes to:

83 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0# array(3) # COSE_Encrypt0
=C2=A0 =C2=A040 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # bytes(0) # protected bucket
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # "= "
=C2=A0 =C2=A0A1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 # map(1) # unprotected bucket
=C2=A0 =C2=A0 =C2=A0 06 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0# unsigned(6) # PIV label
=C2=A0 = =C2=A0 =C2=A0 01 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0# unsigned(1) # PIV = value
=C2=A0 =C2=A058 28 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0# = bytes(40) =C2=A0# ciphertext
=C2=A0 =C2=A0E72233134093261AB93634B= 3413BB46D1273AB98DBE95C4E7E332C754B348FBC70EC9C921133E8AE

where the corresponding plaintext is:

A1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0# map(1)
=C2=A0 =C2=A018 19 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0# unsigned(25) # cnf label
=C2=A0 =C2=A0A= 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # map(1) =C2=A0# cnf
=C2=A0 =C2=A0 =C2=A0 01 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0# unsigned(1)= # COSE_Key label
=C2=A0 =C2=A0 =C2=A0 A4 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0# map(4) # COSE_Key
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A001 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # unsigned(1) # type label
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A004 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # unsigned(4) # sym= metric
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A020 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 # negative(0) # key value label
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A050 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # bytes(16) =C2=A0 # key value
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6F92418A5CAA7C639255A1AF0C7B832C = # "o\x92A\x8A\\\xAA|c\x92U\xA1\xAF\f{\x83,"
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A006 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # unsigned(6) # OSCORE se= nder id label
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A041 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 # bytes(1) =C2=A0 =C2=A0 # OSCORE sender id value
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 00 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0# "\x00&quo= t; =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= 07 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 # unsigned(7) # OSCORE recipient id label
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A041 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # bytes(= 1) =C2=A0 =C2=A0 =C2=A0 # OSCORE recipient id value
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 01 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0# "\x01"

To this, there is an additional tag= of 8 bytes for AES-CCM-16-64-128 that was used.

Some points where we could save bytes:
- Does cnf label really need to fall into = the 2-byte integers space? having the label encoded as a single integer wou= ld result in 2 bytes savings, since cnf is present twice

- =C2=A0To save bytes, could we not define a specific= structure to carry OSCORE context params instead of COSE_Key?=C2=A0 For ex= ample:

[
sender_id : bstr
recipient_id : bstr
master_secret : bstr
? ( master_salt : bstr / nil,
=C2=A0 =C2=A0 =C2=A0id_context : bstr = / nil),
? ( hkdf : u= int,
=C2=A0 =C2=A0 = =C2=A0alg : uint )
]=

In the use case from above with se= nder_id : h'00', recipient_id : h'01' and master_secret =C2= =A0a random 16-byte string, this encodes to 22 bytes. COSE_Key carrying the= same thing encodes to 27 bytes, resulting in 5 bytes savings per COSE_Key = object, or total of 10 bytes saved in the payload from AS to C.

- Can we not define some sort of a compressed = structure using arrays in the OSCORE profile for the cnf claim? Or somethin= g like OSCORE's compression flag byte omitting some of these labels?

With the current numbers, having a = constrained client in OpenWSN simply does not work...

Mali=C5=A1a


=
--00000000000005082c0571109df3-- From nobody Sun Jul 15 17:48: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 1B4291277BB; Sun, 15 Jul 2018 17:48:46 -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 ZY7R9oNkj_4g; Sun, 15 Jul 2018 17:48:44 -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 BDD95130E29; Sun, 15 Jul 2018 17:48:43 -0700 (PDT) Received: from Jude (107.18.132.214) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sun, 15 Jul 2018 17:44:48 -0700 From: Jim Schaad To: CC: 'ace' Date: Sun, 15 Jul 2018 20:48:14 -0400 Message-ID: <00dc01d41c9e$af8ad9b0$0ea08d10$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AdQcN4poJY1RKiVKR52cYpkG7kvz5A== X-Originating-IP: [107.18.132.214] Archived-At: Subject: [Ace] Review Comments on -03 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 00:48:46 -0000 Note - the OSCORE profile people should scan these comments for relevancy as well. Meta Question - Is there a check list that I can run through which says that these are the things that a profile needs to cover. Part of this question about how the document is structured. I was of the opinion that a profile was going to need to cover one or both of the following issues: How does this profile deal with communications between the C and the RS? How does this profile deal with communications between the C and the AS? How does this profile deal with communications between the RS and the AS? * If the document discusses how to do communications between the client and the AS, I do not believe that you can rule how mutual authentication between those two entities as being out of scope. You don't need to specific how the initial configuration is done, but the fact that you are using DTLS with pre-configured credentials needs to be in scope. * It is too bad that we don't have the generic coap schemas defined yet so that we can use that as part of the URL returned with an access denied response. * Point to Authz document for the details of getting the AS URL back in section 2 p 3 * Update section 2 to talk about the use of the rs_cnf parameter. For RPK no cnf parameter would be expected to be returned. * Deal with RPK and PSK in separate paragraphs. Yes you may have some duplication of text but the details are sufficiently different that it would read better. Section 2 * Section 2.1 - PSK is not a session key. The session key is inside of TLS. This means that the session key is not the identity. * Section 2.2 - Is there an intent in this paragraph that if the kid does not match the current DTLS session that the CWT would be rejected? That appears to me to be what the text says but I am not sure. Next paragraph appears to say any active DTLS session rather than just the current one. * Section 2.3 p 3 - How is a check done for the PSK being the same if one has deleted all of the CWTs and then get an update over the secure channel. Just having the kid be the same should not be sufficient. * Section 2.3 - Is the kid parameter still needing to be defined given the CWT POP key id option? (Assuming that it does not disappear.) * Section 3 - YEAH you are doing POP on the RPK as part of the request. I like this!!!!!!! * Section 3 - The last 2 sentences in this section are giving me problems. I don't understand when and where you are putting kids and why. * Section 4 - if the token is already secure then no secure channel would be needed. Hard to have a secure channel if you have not setup anything yet. * Section 4 - Are we really using MAX-AGE and not expires in for duration. * Section 4 - Update the pointer to a PoP token description * Section 4.1 - I think that this is not what the COSE_Encrypt structure is defined in the POP structure for. Revisit this. * Section 4.2 - Remove everything to do with renegotiation of TLS - It is no longer present in 1.3 s/Is also adds/It also adds/ jim From nobody Mon Jul 16 04:14: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 791AE130E7C; Mon, 16 Jul 2018 04:14:39 -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 oz60OLCNciPq; Mon, 16 Jul 2018 04:14:37 -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 89F52130E2D; Mon, 16 Jul 2018 04:14:37 -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 w6GBESP7028324; Mon, 16 Jul 2018 13:14:28 +0200 (CEST) Received: from [IPv6:2001:67c:1232:144:a00d:4bc5:558:3b26] (unknown [IPv6:2001:67c:1232:144:a00d:4bc5:558:3b26]) (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 41Tgm35tCVzDXR9; Mon, 16 Jul 2018 13:14:27 +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: <00dc01d41c9e$af8ad9b0$0ea08d10$@augustcellars.com> Date: Mon, 16 Jul 2018 07:14:26 -0400 Cc: draft-ietf-ace-dtls-authorize@ietf.org, ace X-Mao-Original-Outgoing-Id: 553432464.747075-d2d8d0fcba1549a72abdaa8b95d8bea2 Content-Transfer-Encoding: quoted-printable Message-Id: <36CFDA3E-528E-4921-A433-850A99283FA2@tzi.org> References: <00dc01d41c9e$af8ad9b0$0ea08d10$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Ace] Review Comments on -03 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 11:14:40 -0000 Hi Jim, > On Jul 15, 2018, at 20:48, Jim Schaad wrote: >=20 > * It is too bad that we don't have the generic coap schemas defined = yet so > that we can use that as part of the URL returned with an access denied > response. Can you expand on that? What should we have defined? Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jul 16 05:26:46 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 8E8CE13103F; Mon, 16 Jul 2018 05:26:38 -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 hZecIqWtmMV4; Mon, 16 Jul 2018 05:26: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 5FB96131053; Mon, 16 Jul 2018 05:26:33 -0700 (PDT) Received: from Jude (31.133.140.188) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 16 Jul 2018 05:22:38 -0700 From: Jim Schaad To: 'Carsten Bormann' CC: , 'ace' References: <00dc01d41c9e$af8ad9b0$0ea08d10$@augustcellars.com> <36CFDA3E-528E-4921-A433-850A99283FA2@tzi.org> In-Reply-To: <36CFDA3E-528E-4921-A433-850A99283FA2@tzi.org> Date: Mon, 16 Jul 2018 08:26:04 -0400 Message-ID: <011301d41d00$2bdc9970$8395cc50$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQISnfGbyY4/fVbcu1WJoEsmubpuZwFA2NvQpAq8vEA= X-Originating-IP: [31.133.140.188] Archived-At: Subject: Re: [Ace] Review Comments on -03 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 12:26:39 -0000 In the event of an unauthorized, the RS has the ability to return a URL = to the AS it knows about. If it returns coaps://AS/token, then this = might be thought of implying that one needs to use dtls to talk to the = AS rather than using OSCORE. The same might be true if you just = returned coap://AS/token. Once upon a time, I thought there was some = work being done in the core group that would help clean this up. It has = not finished, nor have I seen much about it recently. Jim =20 > -----Original Message----- > From: Carsten Bormann > Sent: Monday, July 16, 2018 7:14 AM > To: Jim Schaad > Cc: draft-ietf-ace-dtls-authorize@ietf.org; ace > Subject: Re: Review Comments on -03 >=20 > Hi Jim, >=20 > > On Jul 15, 2018, at 20:48, Jim Schaad = wrote: > > > > * It is too bad that we don't have the generic coap schemas defined > > yet so that we can use that as part of the URL returned with an = access > > denied response. >=20 > Can you expand on that? What should we have defined? >=20 > Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jul 16 05:32: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 E7662130E3D; Mon, 16 Jul 2018 05:32:12 -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 WN1150pEw5ME; Mon, 16 Jul 2018 05:32:11 -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 4A5AF12F1A2; Mon, 16 Jul 2018 05:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w6GCVWvf027909; Mon, 16 Jul 2018 14:31:33 +0200 (CEST) Received: from [IPv6:2001:67c:1232:144:a00d:4bc5:558:3b26] (unknown [IPv6:2001:67c:1232:144:a00d:4bc5:558:3b26]) (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 41TjT02hFczDXS3; Mon, 16 Jul 2018 14:31:32 +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: <011301d41d00$2bdc9970$8395cc50$@augustcellars.com> Date: Mon, 16 Jul 2018 08:31:30 -0400 Cc: draft-ietf-ace-dtls-authorize@ietf.org, ace X-Mao-Original-Outgoing-Id: 553437089.207402-2ff3d2892214c5e47528ba167c02d992 Content-Transfer-Encoding: quoted-printable Message-Id: References: <00dc01d41c9e$af8ad9b0$0ea08d10$@augustcellars.com> <36CFDA3E-528E-4921-A433-850A99283FA2@tzi.org> <011301d41d00$2bdc9970$8395cc50$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Ace] Review Comments on -03 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 12:32:13 -0000 On Jul 16, 2018, at 08:26, Jim Schaad wrote: >=20 > In the event of an unauthorized, the RS has the ability to return a = URL to the AS it knows about. If it returns coaps://AS/token, then this = might be thought of implying that one needs to use dtls to talk to the = AS rather than using OSCORE. The same might be true if you just = returned coap://AS/token. Once upon a time, I thought there was some = work being done in the core group that would help clean this up. It has = not finished, nor have I seen much about it recently. Right. We have no way to indicate with a coaps:// URI which kind of = security parameters are expected (with https://, there is a default, but = that is not always right either; I am not aware of any activity to solve = that problem there). We could define a format for URI + security = parameters. The question here was always what would be good, actionable = hints that don=E2=80=99t also provide too much information disclosure. = This is maybe a question that ACE and CoRE have in common. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jul 16 07:16: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 5B4C8130EA4 for ; Mon, 16 Jul 2018 07:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 10yMs18xI3rj for ; Mon, 16 Jul 2018 07:16:25 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80079.outbound.protection.outlook.com [40.107.8.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C9AD130E9E for ; Mon, 16 Jul 2018 07:16:24 -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=lNb3irE0NlJk3BcV7FVPtu8mBD/PlX4/+1Gj+/SsvcQ=; b=GZia6KaMbF/yayB9BpfpRsdDuj/0BcUpbmwJcuCVKZ8EqIW2ximY11/c0qfXAXVTa9vUhg9hMdSJ2ivJuIl+JNA0kMnnnl8Egl6/V4HpOjtL599tOe1+8Xl39br0UaN1zb7WXRPxp8vT2CTGtvqj0KRdNw1Qqedw26+3WCOXDFM= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1646.eurprd08.prod.outlook.com (10.168.66.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.17; Mon, 16 Jul 2018 14:16:22 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db%10]) with mapi id 15.20.0952.021; Mon, 16 Jul 2018 14:16:22 +0000 From: Hannes Tschofenig To: "ace@ietf.org" Thread-Topic: RNG functionality Thread-Index: AdQdDtCsiUI0Y8zZS/y8EtS4ZtROAQ== Date: Mon, 16 Jul 2018 14:16:21 +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: [31.133.157.45] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1646; 7:TjsEhALeUCELWFmsBQUFmhKSYqIFPYedz/MnbMQ8qTjsVhWNI942yb7u3hgWmpm20BIDyip1eYGzQ/Ud8CHY/jDo+86ftSzp87+YKUjfkY8OX8bN2/1lRXLA+7CjJwJtsR8XP6XGraxR3S+b2ynHCyMLbWGpxw19WUPu/2qbLixqSZAS1MU7YYaJHZXELkf5hY4MWrIM/tz5kuy8rw0IKQRSqAH9EClRi5EZagmV+8luchL9Hqb2o1xQavJ2Itw3 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 8ae3cf9e-3a8a-4cb3-7ebc-08d5eb26b4f8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(48565401081)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1646; x-ms-traffictypediagnostic: VI1PR0801MB1646: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(223705240517415)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231311)(944501410)(52105095)(10201501046)(93006095)(93001095)(3002001)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1646; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1646; x-forefront-prvs: 073515755F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(376002)(396003)(39860400002)(136003)(40434004)(53754006)(189003)(199004)(66066001)(3846002)(8676002)(102836004)(7116003)(19273905006)(316002)(2351001)(790700001)(6116002)(6506007)(2906002)(8936002)(33656002)(97736004)(1730700003)(7696005)(53936002)(81156014)(81166006)(256004)(221733001)(478600001)(14444005)(105586002)(106356001)(6916009)(236005)(5660300001)(5250100002)(86362001)(2501003)(6436002)(7736002)(26005)(25786009)(186003)(14454004)(55016002)(5630700001)(6306002)(54896002)(9686003)(72206003)(5640700003)(74316002)(606006)(68736007)(476003)(99286004)(966005)(3480700004)(486006)(5024004)(2900100001)(563064011); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1646; 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: n3Nq/+n6hjgYVr0k1Kg3k3PWobDSFZsmKDt2uc4J5Je6KA8B/Np07FxvpuvqSv+yDTYIZ+8dfp2ifzSLHH5lkQdVgA63PHV9fCD3SjXzS0kPnG7/RuFwhd4UaZlXreI6w+n4ctDRyFMjb6tNNmUHY7e7coiw91AnAc6d0fb3slrb4y7XD6t72MiCxBwDl+RtWW0me+r2IJoNs9q/lfHD5YXKjPBumdDa2nG2tK2LSE8TUgKWTsXrCfLwERQespYNoOSShxj04xSVGX9QRD7sM7coVrqF7ZdmqwThVncy9EI7LiINrXoDhEIWmZVqUxyeTWuhgXUaL7FfJaPb2/RMbPUEBAii8DdCjJy9cCQz7pU= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB211261ABC9959EA13DFCFB13FA5D0VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8ae3cf9e-3a8a-4cb3-7ebc-08d5eb26b4f8 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2018 14:16:21.9241 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1646 Archived-At: Subject: [Ace] RNG functionality X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 14:16:29 -0000 --_000_VI1PR0801MB211261ABC9959EA13DFCFB13FA5D0VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, As mentioned at the ACE meeting today in the context of "can IoT devices ge= nerate random number" I promised to send a pointer to a recent webinar abou= t the use of hardware-based RNG functionality. The webinar recording can be= found at http://www2.keil.com/mbed/mbedtls (look for part 3). 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_VI1PR0801MB211261ABC9959EA13DFCFB13FA5D0VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

As mentioned at the ACE meeting today in the context= of “can IoT devices generate random number” I promised to send= a pointer to a recent webinar about the use of hardware-based RNG function= ality. The webinar recording can be found at http://www2.keil.com/mbed/mbe= dtls (look for part 3).

 

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_VI1PR0801MB211261ABC9959EA13DFCFB13FA5D0VI1PR0801MB2112_-- From nobody Mon Jul 16 08:37: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 2794313112B for ; Mon, 16 Jul 2018 08:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 H_oDh8Z4Kbi7 for ; Mon, 16 Jul 2018 08:36:54 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0076.outbound.protection.outlook.com [104.47.0.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EEC31310C5 for ; Mon, 16 Jul 2018 08:36:54 -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=XpV9Wp1l/Ayb3NjsoPO3IMpAOwDfks/ThvFN8IziE7A=; b=YFNt6kQay2rL3Icf50MeNdKPKMUNIgK7Dw618M5GDZoDeIgiCCueg0kuA3Z5113Ps+0tXXKMYmtJCtiatxsjikzZxPh/oakCrl9S31AyiaLwbxwaxD1DEnhnr/HC0jm5VVl52c8EYcJNiEsqZzyYTbpneied10+pUOBZW/FANQw= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB2128.eurprd08.prod.outlook.com (10.168.68.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.22; Mon, 16 Jul 2018 15:36:51 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db%10]) with mapi id 15.20.0952.021; Mon, 16 Jul 2018 15:36:51 +0000 From: Hannes Tschofenig To: "ace@ietf.org" Thread-Topic: EAT Bar BOF Meeting Room -- Square Dorchester Thread-Index: AdQbswtZxeVDX2vtTkKi2ch6BAnangBZ1G4A Date: Mon, 16 Jul 2018 15:36:51 +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: [31.133.157.45] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB2128; 7:FgNnLWs2AbRRRXjeH0WTRDm7UzYV/BtqgcT56al5NNozaSEFv9q6LFk7j30Y0AMAUxWb6AwMC646jbk2fVSZSwpimyK19CtZhL/Qmxlu5tWZMYdkQDit3BK8WtVDvOEAD13I764lbRKpPlFkCtv/+Zz4cJiOS1hK7g8UJ5vVgRZEJ16IDtp2iBBeAszDpPSZCqE78EuayX26Zjah6lSrXoI3Lp+R40FjLkhHFMSFB+nHKm0JEa1R+anywvtjQd63 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 4bf1e18d-5d96-44c9-ea86-08d5eb31f383 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB2128; x-ms-traffictypediagnostic: VI1PR0801MB2128: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(120809045254105)(223705240517415)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231311)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB2128; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB2128; x-forefront-prvs: 073515755F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(39860400002)(136003)(376002)(346002)(53754006)(189003)(199004)(40434004)(14444005)(6436002)(53936002)(4743002)(2900100001)(25786009)(86362001)(5630700001)(606006)(74316002)(790700001)(6116002)(6916009)(7696005)(9686003)(236005)(229853002)(55016002)(5250100002)(99286004)(2473003)(66066001)(316002)(3846002)(256004)(2351001)(2501003)(5024004)(5640700003)(186003)(68736007)(7736002)(8936002)(33656002)(102836004)(53546011)(6506007)(76176011)(5660300001)(26005)(1730700003)(2906002)(486006)(81166006)(81156014)(11346002)(476003)(446003)(6306002)(478600001)(105586002)(106356001)(72206003)(14454004)(97736004)(8676002)(54896002)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB2128; 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: XQbE4Iczk2JKMeVq6yMHMnLopR1Q8Vk7ToxIEmPUwClXThRHUCa1/E3zs7bEERNYTWwu3pJAOweBFrWLpCCbfJh38XUSF2tF1nMSxBe0l+FD+gGL3VopdLTvLeKJiRVkaH8zvmtmlFyMwPZBsv/VqTXUIRRgb1wRyWD2Qap6pXIhiLsI2EnS+4VzplvX0WKJh4M7snorcNXkt+sKEO4rY07XtRJp8h71KV4kKaF3laNlhWA4ji/Tp77i79iM7VMrBVJX+BRXYhdU8ScSo7TZb47vQMxIcAJT6DiHRQigcoY/NTJwU0Klwzif7ehRzzkp+2Evm5XxalbcyzMwWKB4fOXPpnlGYvlBCNW5r3IMsPk= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB211220444DEB798C5AE2F21FFA5D0VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4bf1e18d-5d96-44c9-ea86-08d5eb31f383 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2018 15:36:51.2545 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB2128 Archived-At: Subject: [Ace] FW: EAT Bar BOF Meeting Room -- Square Dorchester X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 15:37:01 -0000 --_000_VI1PR0801MB211220444DEB798C5AE2F21FFA5D0VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In context of the presentation Carsten gave at the ACE meeting today (see h= ttps://datatracker.ietf.org/meeting/102/materials/slides-102-ace-resource-d= irectory-permissions-part-2-00) I pointed the group to a Bar BOF about the = work on attestation, as described in https://tools.ietf.org/html/draft-mand= yam-eat-00. The meeting will take place later today, as described below, in= the Square Dorchester room. Ciao Hannes From: Hannes Tschofenig Sent: 14 July 2018 17:09 To: eat@ietf.org Subject: EAT Bar BOF Meeting Room -- Square Dorchester Hi all, the meeting room for our Bar BOF, which starts at 18:00 after the afternoon= session and ends at 19:30, will be "Square Dorchester" 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_VI1PR0801MB211220444DEB798C5AE2F21FFA5D0VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In context of the pres= entation Carsten gave at the ACE meeting today (see https://datatracker.ietf.org/meeting/102/materials/slides-102-ace-resource-= directory-permissions-part-2-00) I pointed the group to a Bar BOF about= the work on attestation, as described in https://tools.= ietf.org/html/draft-mandyam-eat-00. The meeting will take place later t= oday, as described below, in the Square Dorchester room.<= /p>

 

Ciao=

Hannes

 

From:= Hannes Tschofenig
Sent: 14 July 2018 17:09
To: eat@ietf.org
Subject: EAT Bar BOF Meeting Room -- Square Dorchester

 

Hi all,=

&n= bsp;

the mee= ting room for our Bar BOF, which starts at 18:00 after the afternoon sessio= n and ends at 19:30, will be “Square Dorchester”

&n= bsp;

Ciao

Hannes<= o:p>

 

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_VI1PR0801MB211220444DEB798C5AE2F21FFA5D0VI1PR0801MB2112_-- From nobody Mon Jul 16 09:31: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 510F9131122 for ; Mon, 16 Jul 2018 09:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.593 X-Spam-Level: X-Spam-Status: No, score=-0.593 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, TRACKER_ID=1.306, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCuV7VFTUQen for ; Mon, 16 Jul 2018 09:31:08 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D1D213111B for ; Mon, 16 Jul 2018 09:31:05 -0700 (PDT) Received: from Jude (31.133.140.188) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 16 Jul 2018 09:27:10 -0700 From: Jim Schaad To: =?utf-8?B?J01hbGnFoWEgVnXEjWluacSHJw==?= , References: In-Reply-To: Date: Mon, 16 Jul 2018 12:30:36 -0400 Message-ID: <013d01d41d22$54fc2010$fef46030$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_013E_01D41D00.CDECF110" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQJtBBENPdVz06UI0n7KTJGDaKse2aNgO0rg X-Originating-IP: [31.133.140.188] Archived-At: Subject: Re: [Ace] Message overhead of the OSCORE profile and ACE specs X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 16:31:10 -0000 ------=_NextPart_000_013E_01D41D00.CDECF110 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Ace On Behalf Of Mali=C5=A1a Vucinic Sent: Sunday, July 15, 2018 5:44 PM To: ace@ietf.org Subject: [Ace] Message overhead of the OSCORE profile and ACE specs =20 Hi Ludwig, all, =20 I am in the process of implementing draft-ietf-ace-oscore-profile-02 for = openwsn.org . For now, I have a first = implementation of AS available, and will be going to the firmware part = in the next weeks..=20 =20 I have to say that I was quite frustrated with the number of drafts that = I had to go through in order to understand what should be implemented. = Maybe this is implied knowledge for people actively working on ACE, but = I believe a guide somewhere pointing to different specs one needs to = follow in order to instantiate a profile would be quite beneficial. =20 Here, I'd like to share my comments about the message overhead found = when implementing the OSCORE profile and give some optimization = proposals. I am mostly concerned with the response from AS to C, where C = is in a constrained network. =20 Please bear with me that my understanding of the specs is correct and = that my implementation generated correct outputs. =20 Assumptions used in the implementation:=20 - OSCORE channel between AS and C, AS and RS. - AS and RS share an additional key, derived from the OSCORE Master = Secret using HKDF label 'ACE' and RS's unique identifier. Explicit = monotonically increasing counter kept to generate nonce, incremented for = each Encrypt0 object generated towards a given RS. - Profile is implicitly known by all the parties - Scope is implicitly known by all the parties - Audience is implicitly known by all the parties - Default values of OSCORE KDF, salt, id_context =20 To save bytes, I use the following optimizations: - Sending single byte for PIV in COSE Encrypt0 of CWT, the actual AEAD = nonce is PIV prepended with zeros - Using single byte for OSCORE IDs in the security context generated by = AS =20 [JLS] Both of these optimizations are ones that I would expect to be = used. =20 With this, I got the CoAP payload from AC to C down to 82 bytes. This = overflows 802.15.4 + 6LoWPAN + UDP packet by 29 bytes, assuming the = latest OpenWSN implementation implementing most of the cross layer = optimizations available and not supporting fragmentation. [JLS] From the computations that I thought existed, I was under the = impression that 82 bytes of COAP payload should fit. This is slightly = disappointing. =20 I copy here output of the payload that I generated: =20 A2 # map(2) 18 19 # unsigned(25) # cnf label A1 # map(1) # cnf =20 01 # unsigned(1) # COSE_Key = label A4 # map(4) # COSE_Key 01 # unsigned(1) # type label 04 # unsigned(4) # symmetric 20 # negative(0) # key value = label 50 # bytes(16) # key value 6F92418A5CAA7C639255A1AF0C7B832C # = "o\x92A\x8A\\\xAA|c\x92U\xA1\xAF\f{\x83," 06 # unsigned(6) # OSCORE sender = id label 41 # bytes(1) # OSCORE = sender id value 00 # "\x00" =20 07 # unsigned(7) # OSCORE = recipient id label 41 # bytes(1) # OSCORE = recipient id value 01 # "\x01" 13 # unsigned(19) # access_token 58 2F # bytes(47) =20 = 8340A106015828E72233134093261AB93634B3413BB46D1273AB98DBE95C4E7E332C754B3= 48FBC70EC9C921133E8AE=20 =20 where the access token decodes to: =20 83 # array(3) # COSE_Encrypt0 40 # bytes(0) # protected bucket # "" A1 # map(1) # unprotected bucket 06 # unsigned(6) # PIV label 01 # unsigned(1) # PIV value 58 28 # bytes(40) # ciphertext = E72233134093261AB93634B3413BB46D1273AB98DBE95C4E7E332C754B348FBC70EC9C921= 133E8AE =20 where the corresponding plaintext is: =20 A1 # map(1) 18 19 # unsigned(25) # cnf label A1 # map(1) # cnf 01 # unsigned(1) # COSE_Key label A4 # map(4) # COSE_Key 01 # unsigned(1) # type label 04 # unsigned(4) # symmetric 20 # negative(0) # key value label 50 # bytes(16) # key value 6F92418A5CAA7C639255A1AF0C7B832C # = "o\x92A\x8A\\\xAA|c\x92U\xA1\xAF\f{\x83," 06 # unsigned(6) # OSCORE sender id = label 41 # bytes(1) # OSCORE sender = id value 00 # "\x00" =20 07 # unsigned(7) # OSCORE recipient = id label 41 # bytes(1) # OSCORE = recipient id value 01 # "\x01" =20 To this, there is an additional tag of 8 bytes for AES-CCM-16-64-128 = that was used. =20 Some points where we could save bytes: - Does cnf label really need to fall into the 2-byte integers space? = having the label encoded as a single integer would result in 2 bytes = savings, since cnf is present twice [JLS] That seems to me to be a reasonable request =E2=80=93 this is = going to be a high frequency field. =20 - To save bytes, could we not define a specific structure to carry = OSCORE context params instead of COSE_Key? For example: [JLS] I was thinking that this would be a reasonable thing to do in = terms of defining a new Confirmation method to carry this. It is not = really a COSE_Key so putting it there seems to be an odd choice. = Defining a new confirmation structure for this sounds like a good idea. =20 Jim =20 [ sender_id : bstr recipient_id : bstr master_secret : bstr ? ( master_salt : bstr / nil, id_context : bstr / nil), ? ( hkdf : uint, alg : uint ) ] =20 In the use case from above with sender_id : h'00', recipient_id : h'01' = and master_secret a random 16-byte string, this encodes to 22 bytes. = COSE_Key carrying the same thing encodes to 27 bytes, resulting in 5 = bytes savings per COSE_Key object, or total of 10 bytes saved in the = payload from AS to C. =20 - Can we not define some sort of a compressed structure using arrays in = the OSCORE profile for the cnf claim? Or something like OSCORE's = compression flag byte omitting some of these labels? =20 With the current numbers, having a constrained client in OpenWSN simply = does not work... =20 Mali=C5=A1a =20 =20 ------=_NextPart_000_013E_01D41D00.CDECF110 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From: Ace = <ace-bounces@ietf.org> On Behalf Of Mali=C5=A1a = Vucinic
Sent: Sunday, July 15, 2018 5:44 PM
To: = ace@ietf.org
Subject: [Ace] Message overhead of the OSCORE = profile and ACE specs

 

Hi Ludwig, = all,

 

I am in the process of = implementing draft-ietf-ace-oscore-profile-02 for openwsn.org. For now, I have a first = implementation of AS available, and will be going to the firmware part = in the next weeks.. 

 

I have = to say that I was quite frustrated with the number of drafts that I had = to go through in order to understand what should be = implemented. Maybe this is implied knowledge for people actively = working on ACE, but I believe a guide somewhere pointing to different = specs one needs to follow in order to instantiate a profile would be = quite beneficial.

 

Here, I'd like to share = my comments about the message overhead found when implementing the = OSCORE profile and give some optimization proposals. I am mostly = concerned with the response from AS to C, where C is in a constrained = network.

 

Please bear with me that = my understanding of the specs is correct and that my implementation = generated correct outputs.

 

Assumptions used in the = implementation: 

- OSCORE channel between = AS and C, AS and RS.

- AS and RS share an = additional key, derived from the OSCORE Master Secret using HKDF label = 'ACE' and RS's unique identifier. Explicit monotonically increasing = counter kept to generate nonce, incremented for each Encrypt0 object = generated towards a given RS.

- Profile is implicitly = known by all the parties

- Scope is implicitly = known by all the parties

- Audience is implicitly = known by all the parties

- Default values = of OSCORE = KDF, salt, id_context

 

To save bytes, I use the = following optimizations:

- = Sending single byte for PIV in COSE Encrypt0 of CWT, the actual AEAD = nonce is PIV prepended with zeros

- Using = single byte for OSCORE IDs in the security context generated by = AS

 

[JLS] Both of these = optimizations are ones that I would expect to be = used.

 

With this, I got the CoAP = payload from AC to C down to 82 bytes. This overflows 802.15.4 + = 6LoWPAN + UDP packet by 29 bytes, assuming the latest OpenWSN = implementation implementing most of the cross layer optimizations = available and not supporting = fragmentation.

[JLS] = >From the computations that I thought existed, I was under the impression = that 82 bytes of COAP payload should fit.=C2=A0 This is slightly = disappointing.

 

I copy = here output of the payload that I = generated:

 

A2         =                     =          # = map(2)

   18 19   =                     =          # unsigned(25) # cnf = label

   A1     =                     =           # map(1)         =  # cnf   

  =     01                 =                # unsigned(1) =    # COSE_Key label

  =     A4                 =                # map(4)   =         # = COSE_Key

        =  01                   =           # unsigned(1)    # type = label

        =  04                   =           # unsigned(4)   # = symmetric

        =  20                   =           # negative(0)    # key = value label

        =  50                   =           # bytes(16)       # = key value

        =     6F92418A5CAA7C639255A1AF0C7B832C # = "o\x92A\x8A\\\xAA|c\x92U\xA1\xAF\f{\x83,"

=

        =  06                   =           # unsigned(6)   # OSCORE sender = id label

        =  41                   =           # bytes(1)       =   # OSCORE sender id value

  =           00           =                # = "\x00"           =  

        =  07                   =           # unsigned(7)  # OSCORE = recipient id label

  =        41             =                 # bytes(1) =        # OSCORE recipient id = value

        =     01                 =          # = "\x01"

  =  13                   =                 # unsigned(19) # = access_token

   58 2F   =                     =        # bytes(47)   =   

      = 8340A106015828E72233134093261AB93634B3413BB46D1273AB98DBE95C4E7E332C754B3= 48FBC70EC9C921133E8AE 

 

where the access token decodes = to:

 

83         =                     =          # array(3) # = COSE_Encrypt0

   40     =                     =           # bytes(0) # protected = bucket

        =                     =             # = ""

   A1     =                     =           # map(1) # unprotected = bucket

      06   =                     =          # unsigned(6) # PIV = label

      01   =                     =          # unsigned(1) # PIV = value

   58 28   =                     =          # bytes(40)  # = ciphertext

  =  E72233134093261AB93634B3413BB46D1273AB98DBE95C4E7E332C754B348FBC70E= C9C921133E8AE

 

where the corresponding = plaintext is:

 

A1         =                     =          # = map(1)

   18 19   =                     =          # unsigned(25) # cnf = label

   A1     =                     =           # map(1)  # = cnf

      01   =                     =          # unsigned(1) # COSE_Key = label

      A4   =                     =          # map(4) # = COSE_Key

        =  01                   =           # unsigned(1) # type = label

        =  04                   =           # unsigned(4) # = symmetric

        =  20                   =           # negative(0) # key value = label

        =  50                   =           # bytes(16)   # key = value

        =     6F92418A5CAA7C639255A1AF0C7B832C # = "o\x92A\x8A\\\xAA|c\x92U\xA1\xAF\f{\x83,"

=

        =  06                   =           # unsigned(6) # OSCORE sender id = label

        =  41                   =           # bytes(1)     # OSCORE = sender id value

  =           00           =                # = "\x00"       =  

        =  07                   =           # unsigned(7) # OSCORE recipient id = label

        =  41                   =           # bytes(1)       # = OSCORE recipient id value

  =           01           =                # = "\x01"

 

To this, there is an additional = tag of 8 bytes for AES-CCM-16-64-128 that was = used.

 

Some points where we could save = bytes:

- Does cnf label really need to = fall into the 2-byte integers space? having the label encoded as a = single integer would result in 2 bytes savings, since cnf is present = twice

[JLS] That seems to me to be a reasonable = request =E2=80=93 this is going to be a high frequency = field.

 

-  To save bytes, could we = not define a specific structure to carry OSCORE context params instead = of COSE_Key?  For example:

[JLS] I = was thinking that this would be a reasonable thing to do in terms of = defining a new Confirmation method to carry this.=C2=A0 It is not really = a COSE_Key so putting it there seems to be an odd choice.=C2=A0 Defining = a new confirmation structure for this sounds like a good = idea.

 

Jim

 

[

sender_id : = bstr

recipient_id : = bstr

master_secret : = bstr

? ( master_salt : bstr / = nil,

     id_context = : bstr / nil),

? ( = hkdf : uint,

     alg : uint = )

]

 

In the use case from above with = sender_id : h'00', recipient_id : h'01' and master_secret  a random = 16-byte string, this encodes to 22 bytes. COSE_Key carrying the same = thing encodes to 27 bytes, resulting in 5 bytes savings per COSE_Key = object, or total of 10 bytes saved in the payload from AS to = C.

 

- Can we not define some sort = of a compressed structure using arrays in the OSCORE profile for the cnf = claim? Or something like OSCORE's compression flag byte omitting some of = these labels?

 

With the current numbers, = having a constrained client in OpenWSN simply does not = work...

 

Mali=C5=A1a

 

 

------=_NextPart_000_013E_01D41D00.CDECF110-- From nobody Wed Jul 18 06:35:17 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 68661126F72; Wed, 18 Jul 2018 06:35:10 -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.82.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <153192091040.2926.3724842842900886076@ietfa.amsl.com> Date: Wed, 18 Jul 2018 06:35:10 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-05.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.27 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 13:35:11 -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-05.txt Pages : 39 Date : 2018-07-18 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-05 https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-est-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-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 Wed Jul 18 15:12: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 D23A8130E60 for ; Wed, 18 Jul 2018 15:12:42 -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 3uw6mdA0883O for ; Wed, 18 Jul 2018 15:12:41 -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 B4393130E03 for ; Wed, 18 Jul 2018 15:12:40 -0700 (PDT) Received: from Jude (107.18.132.214) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 18 Jul 2018 15:09:05 -0700 From: Jim Schaad To: Date: Wed, 18 Jul 2018 18:12:31 -0400 Message-ID: <03d401d41ee4$6db06300$49112900$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AdQd0QK/iLYbTbeuSmSaTB1BUTd9wA== X-Originating-IP: [107.18.132.214] Archived-At: Subject: [Ace] Text for KID in POP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 22:12:43 -0000 Add the following text to section 3.4. WARNING: The use of a Key ID in a POP CWT needs to be carefully circumcised. Where the Key ID is not a cryptographic value derived from the key or where all of the parties involved are not validating the cryptographic derivation, it is possible to get into situations where the same Key ID is being used for multiple keys. The implication of this, is that an RS may have multiple keys registered with it that have the same Key ID and thus it does not know which key the new CWT is to be associated with In the world of constrained IoT devices, there is frequently a restriction on the size that a key id can be either because of table constraints or a desire to keep message sizes small. These restrictions are going to protocol dependent. For example, DTLS can use a key id of any size. However, if the key is being used with COSE encrypted message then the length of the key needs to be minimized and may have a limit as small as one byte. The value of a key id is not always the same for both parties. When sending a COSE encrypted message with a shared key, the key id may be different on both sides of the conversation with the appropriate one being included in the message based on the recipient of the message. For symmetric keys, the key ID is normally going to be generated by the CWT issuer. This means that enforcing a rule that key ID values only match if CWTs have the same issuer works for matching key ids between CWTs. In this case the issuer can ensure that there are no collisions between currently active symmetric keys for all CWTs that it has issued. This allows for an RS to use the pair of issuer and key id for matching with existing keys. For asymmetric keys, the key ID value is normally going to be generated by the client and thus the possibility of collisions is going to greatly increase. It would be normal for all clients to start by assigning a key id of 0 given that key ids are frequently only needed to be unique and meaningful to the client. This problem can be addressed in a couple of different ways depending on how the key id value is going to be used. * The issuer can assign a new unique key id the first time it sees the key, depending on the protocol being used the new value may then need to be transported to the presenter by the protocol used to issue CWTs. In this case the rule of requiring that the issuer, key id pair be used for matching works. * The issuer can use a different confirmation method if a collision is unavoidable. * Clients may decide not to use a CWT based on a created key identifier if it does not fit the clients requirements. * If an issuer is going to issue confirmations of Key ID and is not going to guarantee that serial number uniqueness is going to be preserved, the relying party needs to have that information configured into it so that appropriate action is going to be taken. Jim From nobody Wed Jul 18 17:07: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 773111311F5 for ; Wed, 18 Jul 2018 17:07: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 b8wYe7SOIOYC for ; Wed, 18 Jul 2018 17:07: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 746461310D1 for ; Wed, 18 Jul 2018 17:07:10 -0700 (PDT) Received: from Jude (107.18.132.214) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 18 Jul 2018 17:03:35 -0700 From: Jim Schaad To: References: <03d401d41ee4$6db06300$49112900$@augustcellars.com> In-Reply-To: <03d401d41ee4$6db06300$49112900$@augustcellars.com> Date: Wed, 18 Jul 2018 20:07:01 -0400 Message-ID: <03fa01d41ef4$6c8cb040$45a610c0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQF7wd9kqDkalgiQlyGo6BYQltNQLKVGZOpQ X-Originating-IP: [107.18.132.214] Archived-At: Subject: Re: [Ace] Text for KID in POP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 00:07:13 -0000 Should be circumscribed not circumcised although the first does echo my personal feelings. Jim > -----Original Message----- > From: Ace On Behalf Of Jim Schaad > Sent: Wednesday, July 18, 2018 6:13 PM > To: ace@ietf.org > Subject: [Ace] Text for KID in POP > > Add the following text to section 3.4. > > WARNING: The use of a Key ID in a POP CWT needs to be carefully circumcised. > Where the Key ID is not a cryptographic value derived from the key or where > all of the parties involved are not validating the cryptographic derivation, it is > possible to get into situations where the same Key ID is being used for multiple > keys. The implication of this, is that an RS may have multiple keys registered > with it that have the same Key ID and thus it does not know which key the new > CWT is to be associated with > > In the world of constrained IoT devices, there is frequently a restriction on the > size that a key id can be either because of table constraints or a desire to keep > message sizes small. These restrictions are going to protocol dependent. For > example, DTLS can use a key id of any size. > However, if the key is being used with COSE encrypted message then the length > of the key needs to be minimized and may have a limit as small as one byte. > The value of a key id is not always the same for both parties. When sending a > COSE encrypted message with a shared key, the key id may be different on > both sides of the conversation with the appropriate one being included in the > message based on the recipient of the message. > > For symmetric keys, the key ID is normally going to be generated by the CWT > issuer. This means that enforcing a rule that key ID values only match if CWTs > have the same issuer works for matching key ids between CWTs. In this case > the issuer can ensure that there are no collisions between currently active > symmetric keys for all CWTs that it has issued. This allows for an RS to use the > pair of issuer and key id for matching with existing keys. > > For asymmetric keys, the key ID value is normally going to be generated by the > client and thus the possibility of collisions is going to greatly increase. It would > be normal for all clients to start by assigning a key id of 0 given that key ids are > frequently only needed to be unique and meaningful to the client. This > problem can be addressed in a couple of different ways depending on how the > key id value is going to be used. > > * The issuer can assign a new unique key id the first time it sees the key, > depending on the protocol being used the new value may then need to be > transported to the presenter by the protocol used to issue CWTs. In this case > the rule of requiring that the issuer, key id pair be used for matching works. > > * The issuer can use a different confirmation method if a collision is > unavoidable. > > * Clients may decide not to use a CWT based on a created key identifier if it > does not fit the clients requirements. > > * If an issuer is going to issue confirmations of Key ID and is not going to > guarantee that serial number uniqueness is going to be preserved, the relying > party needs to have that information configured into it so that appropriate > action is going to be taken. > > > Jim > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Thu Jul 19 07:34: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 7018E1310C1; Thu, 19 Jul 2018 07:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 cjFcfHsqIlzt; Thu, 19 Jul 2018 07:34:30 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00082.outbound.protection.outlook.com [40.107.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0F3A1310C2; Thu, 19 Jul 2018 07:34:29 -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=CGgvxuLhCtMahOPAqoPASkf7fGLud62OPATYuaIEgiA=; b=olVU0OcBPI7Go5KcRy0UGB2Juy4tZyh9O3EXUYuWYhWTFpAnAUpGNcKUo4gQfCosAATvUScge9Vr9hvaw0bselSf+3yNYos9wdUBES4ZZkFp6TqDMkeghFZk7PvbrEEX1/nbmu0FpHVyRhyU8CALaRWWrEWZJbaKeWZdWc/LaA8= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1616.eurprd08.prod.outlook.com (10.167.211.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.20; Thu, 19 Jul 2018 14:34:26 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db%10]) with mapi id 15.20.0952.021; Thu, 19 Jul 2018 14:34:26 +0000 From: Hannes Tschofenig To: Benjamin Kaduk , Eric Rescorla CC: "ace@ietf.org" , "oauth@ietf.org" Thread-Topic: ACE - OAuth Synchronization Thread-Index: AdQfbMNLxMX6hvBdRCO/rve3G6chAg== Date: Thu, 19 Jul 2018 14:34:26 +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: [31.133.157.45] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1616; 6:Naa8ODf9TnV0XeAvDsjCEKmU7RAoeTEGuf+OIYhDUbSimo6WZSW/o6ako8sgJSVfQG9TK8BZGk8n7ifSFo7BosCrf9JlUELkTALgDWb7Vf2WOaYhu4dO+QIn/BCGjFAdkXYTi8oGapni//V7GnTAr7lzGOdnxZVPSyt8Ji4XK93FxrIXi3DLuj40OG7XG2c9Gv8e0x7JQDtoTZe1kMQ5L1f7oj94dnUVsNtqOaxV0wH/9MfHxd3Nr7q4NNOgeEYN8IhvIiv6V6RJiRxN/jNvULPlKusoqIbzngHWf3ypx0Kqb2UgKNyVVeiEdAeDwEQcyjvsFBFzF5sLu5dceVIj8Izo0L98mcePlnR04Mr2PTyW7qi/URXfeKGBh23aeiHo3CGSOmqNmseNQN5WpxY48ezDDW8uJfhXzZejOTnhgsPGRW9nUIuMN0ma4QipfnUqGPP3b0RIfqBFBWOA4WTMkg==; 5:vDfdHdZaL2yWjlPuLiMIvKtxkQW/xn7FRxc+3igjRPNewzUdQGAw2uI16B/AtcWQfx/FIGj16Sr4NZdQm1wIuGNmH4VmPdlGtqmAr+ex+TUDcUltnAoOQhbXoPjmsyfaOvX4D3YNKr2fzBQttQYphyebA9pJ48Qm7xYT8DCkins=; 7:xqv7JihLru9qm5RGJ99N1XGgh8iRORPEHr4JnH3mxkRGjME8eYMYc6OCkJbTMACDXZ0xvM8ecMIw5wOUZ6egPnIFhFf/5jOSJKHJOeVO8Gxzi+g0i5q+g9QhWajGS17qrcYCs8LYrOt0n4R7gPUyUGIqo5xhoWfrizOOHFBW9Lm1c4td476RTKzWT203ET1USBZnOUw4fbeucFcBffPyRAhIWS9xwiKD540pD08MOrpzzec+FgMbYhdCajAl6aKd x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 796685cc-2e51-4adc-9013-08d5ed84baa2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(48565401081)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1616; x-ms-traffictypediagnostic: VI1PR0801MB1616: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(223705240517415)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231311)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1616; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1616; x-forefront-prvs: 0738AF4208 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(366004)(136003)(396003)(39860400002)(40434004)(189003)(199004)(81166006)(81156014)(25786009)(14454004)(33656002)(72206003)(478600001)(486006)(2171002)(476003)(4326008)(53936002)(8676002)(2900100001)(97736004)(106356001)(105586002)(2906002)(66066001)(99286004)(5250100002)(8936002)(68736007)(9686003)(6436002)(110136005)(316002)(54906003)(55016002)(54896002)(74316002)(3846002)(186003)(790700001)(5024004)(102836004)(6306002)(256004)(26005)(5660300001)(14444005)(6116002)(7736002)(6506007)(86362001)(7696005); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1616; 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: s/bkTQF3EyG16IdDnQIhkXsGyct0LIwQbtovz0OmUAfU5PM5jp92hmL+CKNuLodHqX7cgC7OXcxscV8Z1IRqGbZQBeid53J3IPfztWN8nvUBiq5dM8W12Todlyn+bJR2SoEVMvBxavsDdc9yxB95l3FULle9HWoteBMZgzeAHvkNs7NjrRVs3uuO2Vttkzox/ivHWsFjLZRLgpRnkloYk4S7iIUeQb7lsf83x9crbF4ELAqy1nbFWcibrXVKxszTBsfWep+NllTb3KCill1kn9/vfxFeSYLcr/L1d8zesFM3as/wE4h8z81csd8hlihIDfJJr2Vs+W+Ox2Ljh+8hV9jpDdsM8yLOtjvvCZWUh0I= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB21122B372DBC82EFF5BD98AFFA520VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 796685cc-2e51-4adc-9013-08d5ed84baa2 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2018 14:34:26.3713 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1616 Archived-At: Subject: [Ace] ACE - OAuth Synchronization X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 14:34:43 -0000 --_000_VI1PR0801MB21122B372DBC82EFF5BD98AFFA520VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ben, Hi Ekr, We tried to find an agreement of which group defines parameters needed for = ACE to support the PoP token functionality. Unfortunately, we didn't manage to find an agreement in which group the wor= k should be done. The ACE working group wants to start a working group last call on draft-iet= f-ace-oauth-authz in September. Hence, there is some urgency in making a de= cision. We need your guidance to avoid having the topic bounce back and forth betwe= en the two groups. 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_VI1PR0801MB21122B372DBC82EFF5BD98AFFA520VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ben, Hi Ekr,

 

We tried to find an agreement of which group defines= parameters needed for ACE to support the PoP token functionality.

Unfortunately, we didn’t manage to find an agr= eement in which group the work should be done.

 

The ACE working group wants to start a working group= last call on draft-ietf-ace-oauth-authz in September. Hence, there is some= urgency in making a decision.

 

We need your guidance to avoid having the topic boun= ce back and forth between the two groups.

 

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_VI1PR0801MB21122B372DBC82EFF5BD98AFFA520VI1PR0801MB2112_-- From nobody Thu Jul 19 08:51: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 102F1130EAB; Thu, 19 Jul 2018 08:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 flBFaXWZnaLd; Thu, 19 Jul 2018 08:51:21 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 8DFD21310DB; Thu, 19 Jul 2018 08:51:21 -0700 (PDT) X-AuditID: 1209190e-33bff700000068b9-f8-5b50b378cd95 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id D6.82.26809.873B05B5; Thu, 19 Jul 2018 11:51:20 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w6JFpJQD005291; Thu, 19 Jul 2018 11:51:19 -0400 Received: from mit.edu (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.13.8/8.12.4) with ESMTP id w6JFpEEn020497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Jul 2018 11:51:17 -0400 Date: Thu, 19 Jul 2018 10:51:14 -0500 From: Benjamin Kaduk To: Hannes Tschofenig Cc: Eric Rescorla , "ace@ietf.org" , "oauth@ietf.org" Message-ID: <20180719155114.GN79497@mit.edu> References: 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+NgFupileLIzCtJLcpLzFFi42IRYrdT163YHBBt8GKelMX3bz3MFiten2O3 uDnjFJPFybev2BxYPNbMW8PosWTJTyaPyY/bmAOYo7hsUlJzMstSi/TtErgyphy9ylrwk6Pi 9UbOBsYp7F2MnBwSAiYSy18tZO5i5OIQEljMJHFh/hpGCGcjo0TTnIlQmbNMEv8urWAEaWER UJW4+mU9WDubgIpEQ/dlZhBbRMBQYm/zIVYQm1kgW2Lzw59MXYwcHMICGhJvH1aBhHkFdCSm PngBViIkkCBx7W0zO0RcUOLkzCcsEK1aEjf+vQRrZRaQllj+jwMkzCmQKLF4xlOwTaICyhJ7 +w6xT2AUmIWkexaS7lkI3QsYmVcxyqbkVunmJmbmFKcm6xYnJ+blpRbpGuvlZpbopaaUbmIE BTCnJN8OxkkN3ocYBTgYlXh4VzgFRAuxJpYVV+YeYpTkYFIS5a067xctxJeUn1KZkVicEV9U mpNafIhRgoNZSYS3YANQOW9KYmVValE+TEqag0VJnDd7EWO0kEB6YklqdmpqQWoRTFaGg0NJ gvf/RqBGwaLU9NSKtMycEoQ0EwcnyHAeoOEnQWp4iwsSc4sz0yHypxiNOeYdnTqJmePPeyAp xJKXn5cqJc7LsgmoVACkNKM0D24aKAlJZO+vecUoDvScMK86SBUPMIHBzXsFtIoJaJV0tS/I qpJEhJRUAyPjA9fLRSwtaRtezNf4bVgrvvTjltwmzd+Tv32UYjjsFGVs5TT7SfKR7YnGjFfO Bl2Z2CUyb8P+BWyzvVZc1F91eDO/uWdaZXnXu9N3KiQqPrwuK56z9/eVK3Zvjlx8ymX5z1+Y LY17Wre7nYDQq2qlhaumnNm6/VPOS82E9/19qy/vUjJ20o9QYinOSDTUYi4qTgQARd4DmR0D AAA= Archived-At: Subject: Re: [Ace] ACE - OAuth Synchronization X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 15:51:25 -0000 Hi Hannes, Can you remind me which parameters are being problematic in this regard? I mostly only remember the ace discussions of keyid, recently, so I probably lost track of some relevant bits. Thanks, Ben On Thu, Jul 19, 2018 at 02:34:26PM +0000, Hannes Tschofenig wrote: > Hi Ben, Hi Ekr, > > We tried to find an agreement of which group defines parameters needed for ACE to support the PoP token functionality. > Unfortunately, we didn't manage to find an agreement in which group the work should be done. > > The ACE working group wants to start a working group last call on draft-ietf-ace-oauth-authz in September. Hence, there is some urgency in making a decision. > > We need your guidance to avoid having the topic bounce back and forth between the two groups. > > Ciao > Hannes > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. From nobody Fri Jul 20 10:47:07 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 7F0C213121B; Fri, 20 Jul 2018 10:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 hsgVMPQCZOXe; Fri, 20 Jul 2018 10:46:52 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70088.outbound.protection.outlook.com [40.107.7.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83A0B131206; Fri, 20 Jul 2018 10:46: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=Kb3BmnW2S+UYOPzj0ibtUfOR+/bvpi+KXZKsXC5cAZc=; b=FCMYLzsJOXkV0kV5v/DU+Io2ivFaukStz1ynyEB19mvMPI+sesdgGywZvOjvutSzx+BHmFhBk67iHnlRvQ8QIwRs1NiZwle+2P3ycvIu5oklyA+eC7NTQ+4thkN7YeDsS+9rEBWUgnj0K0ZDyRQBOJp+AFsPbBDOIwFeg6vUX0w= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB2734.eurprd08.prod.outlook.com (10.166.198.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.16; Fri, 20 Jul 2018 17:46:47 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db%10]) with mapi id 15.20.0952.021; Fri, 20 Jul 2018 17:46:47 +0000 From: Hannes Tschofenig To: oauth , "ace@ietf.org" Thread-Topic: Progressing the HTTP parameter encoding for OAuth PoP Key Distribution Thread-Index: AdQgUXSupVvWyMaDROO8wlEEZAEOPA== Date: Fri, 20 Jul 2018 17:46:47 +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: [31.133.157.45] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB2734; 6:Y2AZyeokipQ4BNAGspOu9ex3njbPBb60KUFjuKybxcK8lCGDVtv1KnGp91yOW6Ff0ERARKfAdS1NGRF3Xgd7P0YLHwXwm7PN1TvOYFYlXKkffdkwP2CPOf3pCHSnKSEDK0adcGkTcqY0Hfr2cm9gXHV5nw+rSBNjQhSjE35RhIMYagLM/mtKk+MVOTkSrMN4+gyZhcFVGAxFp162vFoEeYlJVySxwb4Eu9HzxYD8fIZNaY6XE4V2uY2+FKMdJUhgoBPligcr3PM3upWsrSNDzHVYDn9Is+89SbmxNrAq/dfpXC+Na01/WE3bp4BM8abvtjGUcUeiIjGdBdQ8EFVjVg2tTwbkDre4r+ImL/QiTBDTZbBgafG1964bKLt/4yxis3/qn0j8DeVveUV7qn1vBfYwNztps//SYHzIN6EL5p/GW9dggwVdlsLfCC9ZvVJE5ZbtbyBC7x1UDYeEkxUH8w==; 5:bDZjFNakF53FhOJGQr/SlqdC0H9u0v3vGuagh0iXUWqLJ4FE5Wa2PC2ahOzQP0PBmyZOiyKc1G5Xj5tDIdQuHuG8wFA0DBHZaRW4xMuNZmZ0ZnpICb51fuDZODk5mnoDPrfdflffrIs6tndIqAqNKjq7xQ1tP7iD3KUFpDbzrxY=; 7:QCJdpE/83F5k2/vE5lEAwxssC2QxPn5uBBLIferzNd4Tsi3+pXtdfMMtQ8YvKatqjn+EEUnIp9K3V7DeUA59EZgPWv17owlaUfKUnHMLZetp6QWNzt6K88xyw+HT2n1eYvEEjQntcdsU1OQesgU4YqFPlF/JLYF6gSJsj4ZxhCIHoqWJUOOfSnQWheDH2b63m0e+T/2RPcVf2652mJg/pkSeObIUZGXaaWdMYta0UL0lnrGFx0NI0AbYqK+fylsZ x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 1380c09d-9c89-4c97-2908-08d5ee68c434 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600067)(711020)(4618075)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB2734; x-ms-traffictypediagnostic: VI1PR0801MB2734: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(223705240517415)(788757137089)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231311)(944501410)(52105095)(10201501046)(3002001)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB2734; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB2734; x-forefront-prvs: 073966E86B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(376002)(396003)(136003)(346002)(189003)(199004)(40434004)(53754006)(790700001)(256004)(5024004)(14444005)(26005)(81156014)(3846002)(81166006)(8676002)(6506007)(2501003)(25786009)(6116002)(450100002)(8936002)(5250100002)(102836004)(33656002)(105586002)(106356001)(486006)(2906002)(53936002)(561944003)(66066001)(74316002)(476003)(186003)(2900100001)(7736002)(316002)(5660300001)(68736007)(110136005)(14454004)(97736004)(9686003)(55016002)(99286004)(54896002)(478600001)(6306002)(6436002)(72206003)(7696005)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB2734; 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: 70uBVtYLMiDU437B6u9Y8yZn6rPiWd3qFt5DxeX9BsTf271qp9aghas84kmrzf4Jq7VslG9+dxxzNRCpQta6nDKvpu8F1MniEO8kYWaJRskc6uCJctBIs31GYaaUifzx7b4L7gvMQfezGiXjvtibFhx9krjUwCl3Q4+8ei4ZnrC8oPaes0sk2pxew7e+6c2VG+LvMY+tuFi1YyKqaxMpyTOsGQhnT8CMytv1eHsC6tiRimV+l8Z4WmWggx/w3fFzQV7YMKPFa0A8jKL7tahlsY8iTEhJ3SM6l2QqnGTOHhEboUWDjNPIl2YKSwbMAVbkRQ18Fejsd2A2FF/I/X3QGOJYh+iP9zCJv5p0i9vxlCQ= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB21120EA478D0783F9FCDDC0DFA510VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1380c09d-9c89-4c97-2908-08d5ee68c434 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2018 17:46:47.7594 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB2734 Archived-At: Subject: [Ace] Progressing the HTTP parameter encoding for OAuth PoP Key Distribution X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.27 Precedence: 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, 20 Jul 2018 17:47:06 -0000 --_000_VI1PR0801MB21120EA478D0783F9FCDDC0DFA510VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, after several discussions we believe that we now have a proposal for moving= forward on this topic. We plan to update the expired draft and (1) remove the audience parameter and replace it with a separately-specifie= d resource parameter, (2) remove the alg parameter, (3) update the procedures for requesting and obtaining keying material, (4) Synchronize with the ACE and WebRTC work to make sure that their use ca= ses are appropriately covered. Regarding (1): The meeting participants have decided to standardize an audi= ence-alike parameter (in the form of a requested resource identifier) at th= is weeks IETF OAuth meeting. For that purpose, working group adoption of dr= aft-campbell-oauth-resource-indicators is under way. Only a reference to t= hat document will be needed. Regarding (2): Removal of the alg parameter will simplify the document and = does not appear to be necessary for the currently investigated use cases. T= his assumption will have to be verified. Regarding (3): Currently, the ACE-OAuth document and the use different parameter names. Furthermore, those = parameter names may be in conflict with other, already standardized paramet= er names. Hence, some parameters may need to be renamed. The plan is to foc= us on the following, minimal functionality only: server-side symmetric key = generation and client-side public key registration to the AS. Furthermore, = the encoding of the key transport will have to take the different token for= mats and protocols into account. This approach will allow the ACE and WebRTC work to reference the generic P= oP key distribution document without having to specify their own duplicate = functionality. We are planning to update next w= eek to have something to review. Ciao Hannes & Rifaat 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_VI1PR0801MB21120EA478D0783F9FCDDC0DFA510VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

after several discussions we believe that we now hav= e a proposal for moving forward on this topic.

We plan to update the expired draft <draft-ietf-o= auth-pop-key-distribution-03> and

(1) remove the audience parameter and replace it wit= h a separately-specified resource parameter,

(2) remove the alg parameter,

(3) update the procedures for requesting and obtaini= ng keying material,

(4) Synchronize with the ACE and WebRTC work to make= sure that their use cases are appropriately covered.

 

Regarding (1): The meeting participants have decided= to standardize an audience-alike parameter (in the form of a requested res= ource identifier) at this weeks IETF OAuth meeting. For that purpose, worki= ng group adoption of draft-campbell-oauth-resource-indicators is under way.  Only a reference to that document will be needed. = ;

 

Regarding (2): Removal of the alg parameter will sim= plify the document and does not appear to be necessary for the currently in= vestigated use cases. This assumption will have to be verified.

 

Regarding (3): Currently, the ACE-OAuth document and= the <draft-ietf-oauth-pop-key-distribution-03> use different paramet= er names. Furthermore, those parameter names may be in conflict with other,= already standardized parameter names. Hence, some parameters may need to be renamed. The plan is to focus on the follow= ing, minimal functionality only: server-side symmetric key generation and c= lient-side public key registration to the AS. Furthermore, the encoding of = the key transport will have to take the different token formats and protocols into account.

 

This approach will allow the ACE and WebRTC work to = reference the generic PoP key distribution document without having to speci= fy their own duplicate functionality.

 

We are planning to update <draft-ietf-oauth-pop-k= ey-distribution-03> next week to have something to review.

 

Ciao

Hannes & Rifaat

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_VI1PR0801MB21120EA478D0783F9FCDDC0DFA510VI1PR0801MB2112_-- From nobody Tue Jul 31 01:51: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 3D9C8130E6A for ; Tue, 31 Jul 2018 01:51:53 -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] 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 Eq3qNdWeS0Al for ; Tue, 31 Jul 2018 01:51:50 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0066.hostedemail.com [216.40.44.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 948EF130E26 for ; Tue, 31 Jul 2018 01:51:50 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay07.hostedemail.com (Postfix) with ESMTP id 765A9181D028E for ; Tue, 31 Jul 2018 08:51:49 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 50, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :, RULES_HIT:2:41:72:152:355:379:582:602:800:871:960:962:967:968:973:983:988:989:1000:1152:1189:1208:1221:1260:1263:1313:1314:1345:1359:1381:1431:1432:1436:1437:1516:1517:1518:1573:1575:1588:1589:1592:1594:1605:1617:1730:1776:1792:2196:2198:2199:2200:2525:2553:2561:2564:2682:2685:2692:2737:2829:2859:2892:2897:2901:2911:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3366:3586:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4050:4250:4321:4419:4425:4511:4513:4557:4641:4659:4860:6117:6119:6261:6298:6353:6354:6506:6659:6678:6747:6748:7281:7398:7464:7774:7802:7875:7903:7904:7974:8526:8603:9015:9025:9177:9388:9912:10004:10376:10848:10945:11026:11232:11604:11657:11658:11914:12043:12114:12291:12295:12296:12438:12555:12663:12679:12683:12895:12986:13139:13144:13161:13181:13199:13200:13229:13230:13236:13439:13846:13870:14096:14149:21060:21080:21324:21433:21451:21625: X-HE-Tag: play64_fdf50f0acf05 X-Filterd-Recvd-Size: 60596 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf05.hostedemail.com (Postfix) with ESMTPA for ; Tue, 31 Jul 2018 08:51:49 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_03f9bb93538c1f1d59d29e7c100bec26" Date: Tue, 31 Jul 2018 10:51:48 +0200 From: Peter van der Stok To: ace@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <23af2ffc9ec791bec0653d4a5baab467@bbhmail.nl> References: <23af2ffc9ec791bec0653d4a5baab467@bbhmail.nl> Message-ID: X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [5.206.216.229] Archived-At: Subject: [Ace] Fwd: review of palombini-ace-key-groupcomm X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.27 Precedence: 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, 31 Jul 2018 08:51:53 -0000 --=_03f9bb93538c1f1d59d29e7c100bec26 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Hi key-groupcomm authors, To start the review I have looked at the dependencies between the different involved drafts and came up with the figure below. The arrows indicate that a draft references another draft. The dots reference arrow means Informative reference. According to me, this means that the work on CORE can proceed independently of the work in ACE. The oscoap-join and key-groupcomm can proceed together to their conclusion without other dependencies. That guarantees that we can develop the group communication drafts in ACE without unwanted dependencies on pubsub. The pubsub-profile depends on core-pusub and key-groupcomm, which does not bother me too much. Keeping this in mind, I have reviewed the key-groupcomm draft. BTW, it might be helpful to include a similar overview in the oscoap-join draft. ________________________________________________________________ Abstract OLD:This document defines a message format for distributing keying material in group communication scenarios (such as based on multicast or publisher-subscriber model) using the ACE framework. NEW:This document defines a message format for distributing keying material to groups to protect the communication between group members using the ACE framework. Introduction OLD: Profiles that use group communication can build on this document to specify exactly which of the message parameters defined in this documents are used, and what are their values. NEW: Profiles that use group communication can build on this document to specify a selection of the message parameters defined in this document and their values. At the end of section 1: .... [RFC8152], like Authorization Server (AS) and Resource Server (RS). Figure 1 is not referenced in the text. I suggest a slightly different figure where dispatcher and KDC are endpoints of the RS, and for multicast the communication is directly between Client and group members without passing through the RS. Key Distribution Center (KDC): Maintains the keying material to protect group communications, and provides keys to clients authorized to join the group. It corresponds to an endpoint of the RS in the ACE Framework. Dispatcher: this is the entity the Client wants to securely communicate with and is responsible for distribution of group messages. Example dispatchers are the Broker in a pub-sub setting or the generator of unicast messages to all group members for group communication. Alternatively, Group communication is done by transmitting to a multicast IP address, and entrusting message delivery to the transport channels between Client and Group members. What is the difference between "adding node to group" and "distribution of keying material". I find the phrase difficult to understand. Figure 2 : I suggest to add Group Member (GM) as communication entity. 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. Section 3. Remove: "where the RDC takes the role of RS". Suggest to add the message exchange before section 3.1 POST --- Authorization Request (application/CBOR) ----> <-- Authorization Response (???? ) ----- It would be nice if here the use of DTLS (or not) and the content format is specified: application/cbor or application/Cose+cbor section 3.1 scope: with as values the group identifier and optionally the role .... "The encoding of the group identifier and the role(s) is application specific." cnf: Optionally, the public key or the certificate of the client Question: is this a certificate identifier, or the public key extracted from the certificate, or a hash????? section 3.2: 0 access token containing all the parameters defined below; This is very confusing. I understood that access token parameter is at same level as cnf, rs_cnf, and exp. And here you write that they are contained in access token. If that is true, I suggest to make the other three parameter sub-bullets of access-token bullet. For topic and role see section 3.1 section 3.3: same request response figure as suggested in section 3 before section 3.1 "a different endpoint" is very vague. Please explain. section 4: /The same types of messages can also be/the same set of messages is/ just before section 4.1 same figure and information as requested in section 3 before section 3.1 section 4.1 "....request to the endpoint in the KDC associated..." Not clear what is meant: - one endpoint for all groups? - one endpoint per group? - one endpoint per subset of groups? scope: remove topic; what resource is referred to? get_pub_keys: Instead of empty CBOR array, an empty payload is also possible? client_cred: same question on certificate as for section 3.1 below figure 3 /additionally/Optionally/ The parameters group_policies and mgt_key_material are not specified in pubsub-profile draft. Do you ever use them? Section 5.2 "NOte that .... leaving node" It is not clear if the client has left the group in this case, and what that means. The actions look quite contradictory to me. section 6 /not able to participate to/not able to receive or decrypt/ section 6.1 scope: same remarks about topic and group identifier. "In some cases ... same KDC". Suggest to remove. In a fast changing environment, this may lead to many error messages if not wrong behavior; Imagine group GA is the only group. C is member of GA. GA is removed and GB is entered as the only group. C wants to leave/join GA, and accesses GB. Section 7 Again suggest to add figure with request before section 7.1 scope: same comment on group identifier and topic. _____________________________________________________ Hope this helps, greetings, Peter -- Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org, stokcons@bbhmail.nl www: www.vanderstok.org [1] tel NL: +31(0)492474673 F: +33(0)966015248 Links: ------ [1] http://www.vanderstok.org --=_03f9bb93538c1f1d59d29e7c100bec26 Content-Type: multipart/related; boundary="=_1e6bda92233143347371ef809ce00d3f" --=_1e6bda92233143347371ef809ce00d3f Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi key-groupcomm authors,


To start the review I have looked at the dependencies between the dif= ferent involved drafts and came up with the figure below.


The arrows i= ndicate that a draft references another draft. The dots reference arrow mea= ns Informative reference. According to me, this means that the work on CORE= can proceed independently of the work in ACE. The oscoap-join and key-grou= pcomm can proceed together to their conclusion without other dependencies= =2E That guarantees that we can develop the group communication drafts in A= CE without unwanted dependencies on pubsub. The pubsub-profile depends on c= ore-pusub and key-groupcomm, which does not bother me too much.

= Keeping this in mind, I have reviewed the key-groupcomm draft.

B= TW, it might be helpful to include a similar overview in the oscoap-join dr= aft.

___________________________________________________________= _____

Abstract
OLD:This document defines a message format f= or distributing keying
material in group communication scenarios (such= as based on multicast
or publisher-subscriber model) using the ACE fr= amework.

NEW:This document defines a message format for distribu= ting keying
material to groups to protect the communication between gr= oup members using the ACE framework.

Introduction
OLD: Prof= iles that use group communication can build on this document to specify exa= ctly which of the message parameters defined in this documents are used, an= d what are their values.

NEW: Profiles that use group communicat= ion can build on this document to specify a selection of the message parame= ters defined in this document and their values.

At the end of se= ction 1: .... [RFC8152], like Authorization Server (AS) and Resource Server= (RS).


Figure 1 is not referenced in the text. I suggest a slightly= different figure where dispatcher and KDC are endpoints of the RS, and for= multicast the communication is directly between Client and group members w= ithout passing through the RS.

Key Distribution Center (KDC): Ma= intains the keying material to protect group communications, and provides k= eys to clients authorized to join the group. It corresponds to an endpoint = of the RS in the ACE Framework.

Dispatcher: this is the entity t= he Client wants to securely
communicate with and is responsible for di= stribution of group
messages. Example dispatchers are the Broker in a = pub-sub setting or the generator of unicast messages to all group members f= or group communication.
Alternatively, Group communication is done by = transmitting to a multicast IP address, and entrusting message delivery to = the transport channels between Client and Group members.

What is= the difference between "adding node to group" and "distribution of keying = material". I find the phrase difficult to understand.

Figure 2 := I suggest to add Group Member (GM) as communication entity.

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

Section 3.

Remov= e: "where the RDC takes the role of RS".
Suggest to add the message ex= change before section 3.1

POST --- Authorization Request (applic= ation/CBOR) ---->
<-- Authorization Response (???? ) -----

It would be nice if here the use of DTLS (or not) and the content fo= rmat is specified: application/cbor or application/Cose+cbor

sec= tion 3.1
scope: with as values the group identifier and optionally th= e role ....

"The encoding of the group identifier and the role(s= ) is application specific."

cnf: Optionally, the public key or t= he certificate of the client

Question: is this a certificate ide= ntifier, or the public key extracted from the certificate, or a hash?????
section 3.2:
0 access token containing all the parameters de= fined below; This is very confusing. I understood that access token paramet= er is at same level as cnf, rs_cnf, and exp. And here you write that they a= re contained in access token. If that is true, I suggest to make the other = three parameter sub-bullets of access-token bullet.

For topic an= d role see section 3.1

section 3.3:
same request response = figure as suggested in section 3 before section 3.1
"a different endpo= int" is very vague. Please explain.

section 4:

/The s= ame types of messages can also be/the same set of messages is/

j= ust before section 4.1 same figure and information as requested in section = 3 before section 3.1

section 4.1
"....request to the endpoi= nt in the KDC associated..." Not clear what is meant:
- one endpoint f= or all groups?
- one endpoint per group?
- one endpoint per subse= t of groups?

scope: remove topic; what resource is referred to?<= br />
get_pub_keys: Instead of empty CBOR array, an empty payload is a= lso possible?

client_cred: same question on certificate as for s= ection 3.1

below figure 3
/additionally/Optionally/
The parameters group_policies and mgt_key_material are not specified in= pubsub-profile draft. Do you ever use them?

Section 5.2
"N= Ote that .... leaving node" It is not clear if the client has left the grou= p in this case, and what that means. The actions look quite contradictory t= o me.

section 6
/not able to participate to/not able to rec= eive or decrypt/

section 6.1
scope: same remarks about top= ic and group identifier.

"In some cases ... same KDC". Suggest t= o remove. In a fast changing environment, this may lead to many error messa= ges if not wrong behavior; Imagine group GA is the only group. C is member = of GA. GA is removed and GB is entered as the only group. C wants to leave/= join GA, and accesses GB.

Section 7
Again suggest to add fi= gure with request before section 7.1

scope: same comment on grou= p identifier and topic.

________________________________________= _____________

Hope this helps,

greetings,

= Peter


--
Peter van der Stok
vanderstok consultancy
mailto: consultancy@vanderstok= =2Eorg, stokc= ons@bbhmail.nl
www: www.vanderstok.org
tel NL: +31(0)4= 92474673     F: +33(0)966015248
--=_1e6bda92233143347371ef809ce00d3f Content-Transfer-Encoding: base64 Content-ID: <15330271085b60232491128797824427@bbhmail.nl> Content-Type: image/png; name=352daccb.png Content-Disposition: inline; filename=352daccb.png; size=18642 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 QmCC --=_1e6bda92233143347371ef809ce00d3f Content-Transfer-Encoding: base64 Content-ID: <15330271085b602324913fd396336200@bbhmail.nl> Content-Type: image/png; name=f5a62dc7.png Content-Disposition: inline; filename=f5a62dc7.png; size=14317 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 AABJRU5ErkJggg== --=_1e6bda92233143347371ef809ce00d3f-- --=_03f9bb93538c1f1d59d29e7c100bec26-- From nobody Tue Jul 31 05:01: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 8DF54130DC2; Tue, 31 Jul 2018 05:01: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] 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 oKnyKAgJjYNf; Tue, 31 Jul 2018 05:01:30 -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 69DDA128BAC; Tue, 31 Jul 2018 05:01:30 -0700 (PDT) Received: from wangari.tzi.org (dynamic-218-7.informatik.uni-bremen.de [134.102.218.237]) (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 913BE2073F; Tue, 31 Jul 2018 14:01:28 +0200 (CEST) From: Olaf Bergmann To: Jim Schaad Cc: , "'ace'" References: <00dc01d41c9e$af8ad9b0$0ea08d10$@augustcellars.com> Date: Tue, 31 Jul 2018 14:01:28 +0200 In-Reply-To: <00dc01d41c9e$af8ad9b0$0ea08d10$@augustcellars.com> (Jim Schaad's message of "Sun, 15 Jul 2018 20:48:14 -0400") Message-ID: <87va8vfwbr.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] Review Comments on -03 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.27 Precedence: 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, 31 Jul 2018 12:01:34 -0000 Hi Jim, Thank you for your detailed review and good comments. I will come up with proposed changes within the next days. One thing is not clear to me, see below: Jim Schaad writes: > * Section 4.2 - Remove everything to do with renegotiation of TLS - It is= no > longer present in 1.3 I understand that you want a protocol that works immediately with TLS 1.3, and everybody would like every version prior 1.3 to vanish immediately. But does this mean that we do not address TLS1.2 in this protocol at all? Gr=C3=BC=C3=9Fe Olaf From nobody Tue Jul 31 07:38: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 7778A130FF4; Tue, 31 Jul 2018 07:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[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 iriE3AN0XA9I; Tue, 31 Jul 2018 07:38:45 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A960F130FB5; Tue, 31 Jul 2018 07:38:43 -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; Tue, 31 Jul 2018 07:35:02 -0700 From: Jim Schaad To: 'Olaf Bergmann' CC: , 'ace' References: <00dc01d41c9e$af8ad9b0$0ea08d10$@augustcellars.com> <87va8vfwbr.fsf@tzi.org> In-Reply-To: <87va8vfwbr.fsf@tzi.org> Date: Tue, 31 Jul 2018 07:38:34 -0700 Message-ID: <05e801d428dc$2ae2cd90$80a868b0$@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: AQISnfGbyY4/fVbcu1WJoEsmubpuZwGgCwxIpB972eA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] Review Comments on -03 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.27 Precedence: 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, 31 Jul 2018 14:38:51 -0000 No, I do not believe that you should disallow TLS 1.2 as it is going to = be here for quite a while still. I don't believe that we should be = documenting how to use TLS 1.2 features that are not being carried = forward. Jim > -----Original Message----- > From: Olaf Bergmann > Sent: Tuesday, July 31, 2018 5:01 AM > To: Jim Schaad > Cc: draft-ietf-ace-dtls-authorize@ietf.org; 'ace' > Subject: Re: [Ace] Review Comments on -03 >=20 > Hi Jim, >=20 > Thank you for your detailed review and good comments. I will come up = with > proposed changes within the next days. >=20 > One thing is not clear to me, see below: >=20 > Jim Schaad writes: >=20 > > * Section 4.2 - Remove everything to do with renegotiation of TLS - = It > > is no longer present in 1.3 >=20 > I understand that you want a protocol that works immediately with TLS = 1.3, and > everybody would like every version prior 1.3 to vanish immediately. > But does this mean that we do not address TLS1.2 in this protocol at = all? >=20 > Gr=C3=BC=C3=9Fe > Olaf