From nobody Tue Dec 1 14:10:51 2020 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 588F83A0114; Tue, 1 Dec 2020 14:10:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joerg Ott via Datatracker To: Cc: draft-ietf-core-echo-request-tag.all@ietf.org, last-call@ietf.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160686064132.16683.9970897893331887294@ietfa.amsl.com> Reply-To: Joerg Ott Date: Tue, 01 Dec 2020 14:10:41 -0800 Archived-At: Subject: [core] Tsvart last call review of draft-ietf-core-echo-request-tag-11 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2020 22:10:42 -0000 Reviewer: Joerg Ott Review result: Ready with Nits This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. The draft reads well and is essentially ready to go from a transport perspective. One question that arises is why these three quite distinct mechanisms fixing different parts of the RFC 7252 are compiled into a single document. Efficiency, yes, but otherwise, they don't seem to have much in common. p9, 2nd para, line 5: may -> MAY ? A question out of curiosity: in section 3.4, could a client easily exhaust server resources if just sent many blocks and changed the Request-Tag on each of them? Should sections 3.6 and 3.7 move to an appendix? They discuss design alternatives. Nits: "can not" -> "cannot" The last sentence in the second to last paragraph of section 1.1 has nested brackets, which may or may not be intentional. From nobody Wed Dec 2 10:17:11 2020 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8B13A1573; Wed, 2 Dec 2020 10:16:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ines Robles via Datatracker To: Cc: core@ietf.org, draft-ietf-core-echo-request-tag.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160693301574.8084.12485735068228324677@ietfa.amsl.com> Reply-To: Ines Robles Date: Wed, 02 Dec 2020 10:16:55 -0800 Archived-At: Subject: [core] Genart last call review of draft-ietf-core-echo-request-tag-11 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2020 18:17:02 -0000 Reviewer: Ines Robles Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-core-echo-request-tag-11 Reviewer: Ines Robles Review Date: 2020-12-02 IETF LC End Date: 2020-12-02 IESG Telechat date: Not scheduled for a telechat Summary: This document specifies the Echo option that enables a CoAP server to verify the freshness of a request or to force a client to demonstrate reachability at its claimed network address, and specifies also the Request-Tag that allows the CoAP server to match block-wise message fragments belonging to the same request. Also, this document updates RFC7252 with respect to the client Token processing requirements. The document is well written, I have some minor questions/comments below. Major issues: None. Minor issues: None. Nits/editorial comments: 1.- It would be nice to have the definition of Freshness into the terminology section. 2.- Figure 1 and Figure 4 have two columns named "U" (Unsafe), is that Ok?, or should one of these columns be deleted/renamed? 3- Page 26: Please expand IV. Thank you for this document, Ines. From nobody Thu Dec 3 05:20:20 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E343A09E7; Thu, 3 Dec 2020 05:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 5zpptS4UiFva; Thu, 3 Dec 2020 05:20:13 -0800 (PST) Received: from NAM04-DM6-obe.outbound.protection.outlook.com (mail-dm6nam08on2083.outbound.protection.outlook.com [40.107.102.83]) (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 917813A09D7; Thu, 3 Dec 2020 05:20:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FrhT0Iqm8JwY4eRYw1GcyLXeh7AyrXO+jqEkorfbVd0pMqqhIMXpkHxuQdiLyCld87d3kgTj65ZSrL8kLLNIKPUbicPXGa/ZL5LJ2WVzDFWU423dL8Rr7nknKCgTNZIlYfF1mHPyIrvhkR91q9V4AQaWvsFMjWIWoA29UIATFvUrzxQg/HUBakTp4onCgNsFOPt1mzvDhUde/Hc35suwi+xESws8mE3o13DOEq2X2AgmAz27iep/Pasy+gW03duVdSSQ+aJnGbd5KJJOJ5ZkWzgTqG3Jtbwj4uEEUZLwCu8d/ewgZbUigLYq9ZX/sgvedw3G4cDIHuThV5Q8gQBZug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=x0wCGmqQJhvij7m+ceMz/SbrexStwRFhYYYbpXX55AU=; b=oHYq1paJwGULSD8TIPSfpNrBNOw2PU0mU2zdFiTGTQTMArMVfRv7zi0vrmtcf2omwCVi5Me9ujrPoZJ6dEUKU6lZxbYIZTaTn4weCOw4DY89SVw04C4UBtHlfj3N9YhyVmwy1zjzQ2o86uc6pdO9qEEFYNbhM7mqiUZ+DpT8nbTOnRZbKurx1GQIrJc+c+wXdlfvPKPyoxbOk6Z48jd7S+LCVJLSY06pRWQHYC8xivbvilyiIun9NazwWrrxBDLv7By9hm7wTTiGN9LWVyJrSiLcRyBDDGSd0831BQdX2dSoiMA4UDPmfqhdVJdmcTMJ8RCOus3HKmsas7vDghK3hA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=x0wCGmqQJhvij7m+ceMz/SbrexStwRFhYYYbpXX55AU=; b=ZnpOx6YHhW85Pdl+DmXVcPzsI0bBfEUpp1PxGid9O8z7OUbAiD88M8ZRJeRgBh4LwIeZDCzLwlMjgLuwJfp9dg9MiQJ8tpUUg9AyoPm/7e0kyFQ9mELCunRZQ8NGTFt9lV6LM61uWu/SmBF957g0a4XeF7PwMJl42X9lxaahMRY= Received: from DM6PR15MB2379.namprd15.prod.outlook.com (2603:10b6:5:8a::16) by DM6PR15MB3847.namprd15.prod.outlook.com (2603:10b6:5:2bb::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.25; Thu, 3 Dec 2020 13:20:08 +0000 Received: from DM6PR15MB2379.namprd15.prod.outlook.com ([fe80::b9ed:d237:de1a:adc0]) by DM6PR15MB2379.namprd15.prod.outlook.com ([fe80::b9ed:d237:de1a:adc0%6]) with mapi id 15.20.3611.034; Thu, 3 Dec 2020 13:20:08 +0000 From: Daniel Migault To: Dan Garcia , "ace@ietf.org" CC: EMU WG , "core@ietf.org WG (core@ietf.org)" Thread-Topic: [Ace] Proposed charter for ACE (EAP over CoAP?) Thread-Index: AQHWyWUZNJB+ahHZ90WKorfx1h39X6nlWNof Date: Thu, 3 Dec 2020 13:20:08 +0000 Message-ID: References: <20201117234700.GR39170@kduck.mit.edu> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: um.es; dkim=none (message not signed) header.d=none;um.es; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [96.22.11.129] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8a359f0c-02f4-4e1a-d974-08d8978e280f x-ms-traffictypediagnostic: DM6PR15MB3847: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: h729uzorzyIBf7KjrPf0INEQUunyOs6wKnHUovVFAEjhvaJHWvd0heEOWhNxPEhXnvQOdhvywp1ycFE8DCFlvDCeGJuFGgFKA3HOGhEXwqobPzjFGWI2NK4cnCqg5so3x+y+ELE2AlMuIBpav/FW1gXA+2hHzBULqxCOYKnntiFhK+OmX23p0S6EKvphK7ntpCXCGfkqI/5KodtoIJs4N02UTpEjYDPlvPe/u7pKeDWW8h06cKyyEM4rk/xREYwWdnB2sDU19byRY19iPLE+glq08iWSTQWXywNTq5Kvkqii3JMRV+t3qdsfre4zr6EsC2E7HxQiI8n97rZga5SFbqAPDtRzNEmUtV2UIw3APrYqzxYwJLK35ccXQBU7a/nPu1JvZdrrgB4/wQZUfK56Cw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR15MB2379.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(366004)(346002)(376002)(136003)(396003)(44832011)(4001150100001)(8936002)(9686003)(7696005)(83380400001)(66574015)(166002)(19627405001)(6506007)(8676002)(4326008)(91956017)(26005)(30864003)(86362001)(64756008)(66556008)(54906003)(52536014)(2906002)(478600001)(66946007)(966005)(33656002)(71200400001)(5660300002)(53546011)(66446008)(76116006)(316002)(66476007)(110136005)(55016002)(186003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?Windows-1252?Q?EIsVaQy8uIvL3HslRWoCDeRijetdNmOoUCieiBgAUyH5MIhvzxqt3V+L?= =?Windows-1252?Q?gxO6UfibaBB9LwqayaXoH/UVJnouSsuGZYrnYXa/B3dmYN75Y8cFEB0Q?= =?Windows-1252?Q?5qIG3lPNnYlm9HPRJ/DMFeC5iknHEBdiSSRB2P7qGCD8O1gFNFmPpOn7?= =?Windows-1252?Q?N0YhjRyrWG9ExK89xRa9hzP50h8CX+LW8UOYnHi5wUGqslJIl8Uc4H/+?= =?Windows-1252?Q?e+lh2ATQ4nlY/EW+yw0FKkNMvyznA/4nd4a3l26HYQGeiWhpw+ONH2uZ?= =?Windows-1252?Q?q9YoRahqolHRDVJ2Eng++UDVlBX7AjFPlFDXh5soGa8a6HUP+5uep/H/?= =?Windows-1252?Q?flxyVXhUm09Ih6mGZYsh5UohVpPet6ineQWKZtnvP+ls1uZd+ZhcU+0w?= =?Windows-1252?Q?eUmLrSLSR9xPvGnjCDD+FUc6c8h/gPRi3wrsFhngHGilSxMYkro1QCL1?= =?Windows-1252?Q?YODWt4Jyuj2lcCjeS0GR0sks2dCpQfmPtJRzKQDcjDXlco+5k1Lepff5?= =?Windows-1252?Q?/Tm703JMSXLEaeWlB7vDNIkA54UH6yP+UZGmi+XuYobyM9/o5hypPnjY?= =?Windows-1252?Q?7db2xixZTYcww2RbJrLibh9SlwQY5pTrJnvyaEUkU2AeZWN9BcQeO/n0?= =?Windows-1252?Q?UybeL+gFHPH2o8WmlUKpLZBjdwdYAyur6yTgWRfBGMHlFeERTUCd2QYb?= =?Windows-1252?Q?ZX5TsFAd3I6jzESgGTiBa2k961wLV/8uIp8N+P6+esiGq+SrDXzZRCk9?= =?Windows-1252?Q?xHQi61T/uVaWL25RtcahVbasFH1ZeYWhOwHtS3Hw1Yp9x05Iqphv03dT?= =?Windows-1252?Q?8G0j+J394ruTGGP24snQnD8YxhEUWrr7dy+W+C+fFXAhkCuS8R16WP/J?= =?Windows-1252?Q?8Up6g5XB2EdPSaYUNkzpyTmu9AkM+OcebRnl+YodCOS69cGtxhtqHDxr?= =?Windows-1252?Q?yv2q+NHgIVClMNFl+niVrsAKRMsWJjn2n28k/p++Bqu9h49u0dFzAlrI?= =?Windows-1252?Q?V56qjL4s+5obD+kFR61vBxnPEI0dKySbLX49HRsiMOOdW0xHl+E=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR15MB2379308BD779061F6F46233EE3F20DM6PR15MB2379namp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR15MB2379.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8a359f0c-02f4-4e1a-d974-08d8978e280f X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2020 13:20:08.4653 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: +Hlh48JxDiAby/LVZOEZPVxNQNiAY9lMXhVkgVWbej/MPdQZsOCcz/LqoyClkhulaisugPFkD4+g0LGaMn1/QYzUguWq8HGOv+uEDuS1N64= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR15MB3847 Archived-At: Subject: Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 13:20:16 -0000 --_000_DM6PR15MB2379308BD779061F6F46233EE3F20DM6PR15MB2379namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable CCing emu, core It seems ACE to me that ACE could be home for such a document. I am wonderi= ng if emu core or any other WG believe there is a better place for it. Regarding ACE I am wondering what is the WG opinion about adding this item = to the ACE charter. Yours, Daniel ________________________________ From: Ace on behalf of Dan Garcia Sent: Thursday, December 3, 2020 6:10 AM To: ace@ietf.org Subject: [Ace] Proposed charter for ACE (EAP over CoAP?) Dear all: Regarding the new charter, since ACE is considering the definition of CoAP = transport for CMPv2 (https://tools.ietf.org/html/draft-msahni-ace-cmpv2-coa= p-transport-00), we were wondering whethere it could also consider specifyi= ng EAP (Extensible Authentication Protocol) over CoAP. In this sense, we proposed this some time ago and we have implementations a= bout this. https://datatracker.ietf.org/doc/html/draft-marin-ace-wg-coap-eap-06 https://www.mdpi.com/1424-8220/16/3/358 https://www.mdpi.com/1424-8220/17/11/2646 The usage of CoAP can provide a very light and link-layer independent (we e= ven tested in LoRa networks) EAP lower-layer (transport for EAP) suitable f= or IoT enviroment. We believe this would be really useful since EAP provide= s flexibility for the authentication and it is a well-known protocol. Therefore, we would like to propose the following modification to the chart= er: "The Working Group will examine how to use Constrained Application Protocol= (CoAP) as a transport medium for certificate enrollment protocols, such as= EST and CMPv2, as well as a transport for authentication protocols such as= EAP, and standardize them as needed." This modification does not necessarily mean the adoption of our draft. Afte= r all, we completely understand that this would happen only if there is an = interest in the WG. Nevertheless, we would like to avoid that the charter i= s a barrier later if there is interest in the WG to work in this transport = of EAP over CoAP: Any opinion about this? Best Regards. El 18/11/2020 a las 8:08, Daniel Migault escribi=F3: Hi, Please find the proposed charter we agreed on during the interim meeting. I= f you would like to propose any change, please use the following URL by Nov= ember 25: https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoD= iptY/edit?usp=3Dsharing Yours, Daniel The Authentication and Authorization for Constrained Environments (ace) WG = has defined a standardized solution framework for authentication and author= ization to enable authorized access to resources identified by a URI and ho= sted on a resource server in constrained environments. The access to the resource is mediated by an authorization server, which is= not considered to be constrained. Profiles of this framework for application to security protocols commonly u= sed in constrained environments, including CoAP+DTLS and CoAP+OSCORE, have = also been standardized. The Working Group is charged with maintenance of t= he framework and existing profiles thereof, and may undertake work to speci= fy profiles of the framework for additional secure communications protocols= and for additional support services providing authorized access to crypto = keys (that are not necessarily limited to constrained endpoints, though the= focus remains on deployment in ecosystems with a substantial portion of co= nstrained devices). In addition to the ongoing maintenance work, the Working Group will extend = the framework as needed for applicability to group communications, with ini= tial focus on (D)TLS and (Group) OSCORE as the underlying group communicati= on security protocols. The Working Group will standardize procedures for re= questing and distributing group keying material using the ACE framework as = well as appropriated management interfaces. The Working Group will standardize a format for expressing authorization in= formation for a given authenticated principal as received from an authoriza= tion manager. The Working Group will examine how to use Constrained Application Protocol = (CoAP) as a transport medium for certificate enrollment protocols, such as = EST and CMPv2, and standardize as needed. On Tue, Nov 17, 2020 at 6:47 PM Benjamin Kaduk > wrote: Thanks for updating the draft charter at [1], Daniel! I note that Michael raised the question of whether some other group might also be interested in working on CMP-over-coap, so the IESG will be sure to discuss that if CMP is still in the draft ACE charter when it goes to the IESG for review. -Ben On Tue, Nov 17, 2020 at 06:16:48PM -0500, Daniel Migault wrote: > Thank you all for the feed backs. For the purpose of driving the charter > discussion at the IETf 109, I have added the comments into the proposed > text [1]. > > My current understanding is that it seems beneficial to add CMPv2 over Co= AP > in the charter. I am happy to be contradicted. > * I have not seen a clear cut to do one or the other. > * EST and CMPv2 are two protocols that can be used for enrollment or cert > management while addressing different cases / needs / situations -- maybe > we can clarify that point. I can see leveraging the existing CMP > infrastructure, but it seems that is not the only one. > * I am not convinced that not having CMP over CoAP will not prevent its > deployment and as such I prefer to have it standardized - this might be a > personal thought. > * Adding any piece of work require cycles, but it seems to me that CPM wi= ll > not have a major impact on the WG progress. The work will probably includ= e > other WG such a LAMPS. > > Yours, > Daniel > > [1] > https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXh= oDiptY/edit?usp=3Dsharing > > On Tue, Nov 17, 2020 at 6:02 PM Daniel Migault > wrote: > > > Hi Goran, > > > > I added the text to the charter we will discuss later. > > > > Yours, > > Daniel > > > > On Fri, Nov 13, 2020 at 10:26 AM G=F6ran Selander < > > goran.selander@ericsson.com> wrote: > > > >> Hi Daniel, > >> > >> > >> > >> Here=92s another input to the charter. > >> > >> > >> > >> The current group key management solutions addresses the problem of > >> authorized access to group keys and public keys of group members. > >> > >> > >> > >> A related problem is authorized access of public keys of other devices > >> not necessarily part of a security group, in the sense of sharing a > >> symmetric key used to protect group messages. > >> > >> > >> > >> Authorized access to raw public keys serves an important function in > >> constrained settings where public key certificates may not be feasible= due > >> to the incurred overhead, e.g. for when authenticating using EDHOC > >> (draft-ietf-lake-edhoc). > >> > >> This functionality is thus a subset of what is already supported, but > >> since the current solution is geared towards groups a different soluti= on > >> may be needed (although it is probably possible to reuse parts from th= e > >> existing schemes for provisioning and requesting public keys). > >> > >> > >> > >> With this in mind, I propose the following change (highlighted in > >> boldface below): > >> > >> > >> > >> OLD > >> > >> The Working Group is charged with maintenance of the framework and > >> existing profiles thereof, and may undertake work to specify profiles = of > >> the framework for additional secure communications protocols (that are= not > >> necessarily limited to constrained endpoints, though the focus remains= on > >> deployment ecosystems with a substantial portion of constrained device= s). > >> > >> > >> > >> NEW > >> > >> The Working Group is charged with maintenance of the framework and > >> existing profiles thereof, and may undertake work to specify profiles = of > >> the framework for additional secure communications protocols *and **fo= r > >> additional **support services **providing* *authorized access to crypt= o* *keys > >> *(that are not necessarily limited to constrained endpoints, though th= e > >> focus remains on deployment ecosystems with a substantial portion of > >> constrained devices). > >> > >> > >> > >> G=F6ran > >> > >> > >> > >> > >> > >> > >> > >> On 2020-10-15, 19:50, "Ace" > wrote: > >> > >> Hi, > >> > >> I would like to start the charter discussion. Here is a draft of a > >> proposed charter [1]. > >> > >> > >> > >> It seems to be that additional discussion is needed with regard to the > >> last paragraph related certificate management. In particular the discu= ssion > >> might revive a discussion that happened in 2017 [2] - when I was not > >> co-chair of ACE -and considered other expired work such as [3]. Please= make > >> this discussion constructive on this thread. > >> > >> > >> > >> The fundamental question is whether we need certificate management at > >> this stage. If the answer is yes, and we have multiple proposals, it w= ould > >> be good to clarify the position of the different proposals and evaluat= e > >> whether a selection is needed or not before validating the charter. > >> > >> > >> > >> Please provide your inputs on the mailing list before October 30. Of > >> course for minor edits, you may suggest them directly on the google do= c. > >> > >> > >> > >> Yours, > >> > >> Daniel > >> > >> > >> > >> [1] > >> https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2Bn= BXhoDiptY/edit?usp=3Dsharing > >> < > >> https://protect2.fireeye.com/v1/url?k=3D4f3d9c3b-118c475b-4f3ddca0-86e= 2237f51fb-627e48b069462d70&q=3D1&e=3D6924b2a6-e7e5-4ec1-a1af-c94637953dc5&u= =3Dhttps%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR= 8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing> > >> > >> > >> [2] > >> https://datatracker.ietf.org/doc/minutes-interim-2017-ace-03-201710191= 300/ > >> > >> [3] https://datatracker.ietf.org/doc/draft-selander-ace-eals/ > >> > >> > >> > >> -- > >> > >> Daniel Migault > >> > >> > >> > >> Ericsson > >> > > > > > > -- > > Daniel Migault > > Ericsson > > > > > -- > Daniel Migault > Ericsson > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace -- Daniel Migault Ericsson _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace --_000_DM6PR15MB2379308BD779061F6F46233EE3F20DM6PR15MB2379namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
CCing emu, core

It seems ACE to me that ACE could be home for such a document. I am wonderi= ng if emu core or any other WG believe there is a better place for it. = ;

Regarding ACE I am wondering what is the WG opinion about adding this item = to the ACE charter. 

Yours, 
Daniel
From: Ace <ace-bounces@i= etf.org> on behalf of Dan Garcia <dan.garcia@um.es>
Sent: Thursday, December 3, 2020 6:10 AM
To: ace@ietf.org <ace@ietf.org>
Subject: [Ace] Proposed charter for ACE (EAP over CoAP?)
 

Dear all:

Regarding the new charter, since ACE is considering the definition of CoAP = transport for CMPv2 (https://tools.= ietf.org/html/draft-msahni-ace-cmpv2-coap-transport-00), we were wondering whethere it could also consider specifying EAP (Extensib= le Authentication Protocol) over CoAP.

In this sense, we proposed this some time ago and we have implementations a= bout this.

https://datatracker.ietf.org/doc/ht= ml/draft-marin-ace-wg-coap-eap-06
https://www.mdpi.com/1424-8220/16/3/358
https://www.mdpi.com/1424-8220/17/11/2646

The usage of CoAP can provide a very light and link-layer independent (we e= ven tested in LoRa networks) EAP lower-layer (transport for EAP) suitable f= or IoT enviroment. We believe this would be really useful since EAP provide= s flexibility for the authentication and it is a well-known protocol.

Therefore, we would like to propose the following modification to the chart= er:

"The Working Group will examine how to use Constrained Application Pro= tocol (CoAP) as a transport medium for certificate enrollment protocols, su= ch as EST and CMPv2, as well as a transport for authentication protocols such as EAP, and= standardize them as needed."

This modification does not necessarily mean the adoption of our draft. Afte= r all, we completely understand that this would happen only if there is an = interest in the WG. Nevertheless, we would like to avoid that the charter i= s a barrier later if there is interest in the WG to work in this transport of EAP over CoAP:

Any opinion about this?

Best Regards.

El 18/11/2020 a las 8:08, Daniel Migault e= scribi=F3:
Hi, 

Please find the proposed charter we agreed on during the interim meeti= ng. If you would like to propose any change, please use the following URL b= y November 25:


Yours, 
Daniel

The Authentication and Authorization for Constrained Environments (ace) WG has= defined a standardized solution framework for authentication and authoriza= tion to enable authorized access to resources identified by a URI and hoste= d on a resource server in constrained environments. 

The access to the resource is mediated by an authorization server, which is no= t considered to be constrained.


Profiles of this framework for application to security protocols commonly used in c= onstrained environments, including CoAP+DTLS and CoAP+OSCORE, have also bee= n standardized.  The Working Group is charged with maintenance of the = framework and existing profiles thereof, and may undertake work to specify profiles of the framework for additional= secure communications protocols and for additional support services provid= ing authorized access to crypto keys (that are not necessarily limited to constrained endpoints, though the foc= us remains on deployment in ecosystems with a substantial portion of constr= ained devices).


In addition to the ongoing maintenance work, the Working Group will extend th= e framework as needed for applicability to group communications, with initi= al focus on (D)TLS and (Group) OSCORE as the underlying group communication= security protocols. The Working Group will standardize procedures for requesting and distributing group ke= ying material using the ACE framework as well as appropriated management in= terfaces. 


The Working Group will standardize a format for expressing authorization infor= mation for a given authenticated principal as received from an authorizatio= n manager. 


The Working Group will examine how to use Constrained Application Protocol (Co= AP) as a transport medium for certificate enrollment protocols, such as EST= and CMPv2, and standardize as needed.



On Tue, Nov 17, 2020 at 6:47 PM Ben= jamin Kaduk <kaduk@mit.edu> wrot= e:
Thanks for updating the draft charter at [1], Daniel!

I note that Michael raised the question of whether some other group might also be interested in working on CMP-over-coap, so the IESG will be sure to=
discuss that if CMP is still in the draft ACE charter when it goes to the IESG for review.

-Ben

On Tue, Nov 17, 2020 at 06:16:48PM -0500, Daniel Migault wrote:
> Thank you all for the feed backs. For the purpose of driving the chart= er
> discussion at the IETf 109, I have added the comments into the propose= d
> text [1].
>
> My current understanding is that it seems beneficial to add CMPv2 over= CoAP
> in the charter. I am happy to be contradicted.
> * I have not seen a clear cut to do one or the other.
> * EST and CMPv2 are two protocols that can be used for enrollment or c= ert
> management while addressing different cases / needs / situations -- ma= ybe
> we can clarify that point. I can see leveraging the existing CMP
> infrastructure, but it seems that is not the only one.
> * I am not convinced that not having CMP over CoAP will not prevent it= s
> deployment and as such I prefer to have it standardized - this might b= e a
> personal thought.
> * Adding any piece of work require cycles, but it seems to me that CPM= will
> not have a major impact on the WG progress. The work will probably inc= lude
> other WG such a LAMPS.
>
> Yours,
> Daniel
>
> [1]
> https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoD= iptY/edit?usp=3Dsharing
>
> On Tue, Nov 17, 2020 at 6:02 PM Daniel Migault <mglt.ietf@gmail.com> wrote: >
> > Hi Goran,
> >
> > I added the text to the charter we will discuss later.
> >
> > Yours,
> > Daniel
> >
> > On Fri, Nov 13, 2020 at 10:26 AM G=F6ran Selander <
> > = goran.selander@ericsson.com> wrote:
> >
> >> Hi Daniel,
> >>
> >>
> >>
> >> Here=92s another input to the charter.
> >>
> >>
> >>
> >> The current group key management solutions addresses the prob= lem of
> >> authorized access to group keys and public keys of group memb= ers.
> >>
> >>
> >>
> >> A related problem is authorized access of public keys of othe= r devices
> >> not necessarily part of a security group, in the sense of sha= ring a
> >> symmetric key used to protect group messages.
> >>
> >>
> >>
> >> Authorized access to raw public keys serves an important func= tion in
> >> constrained settings where public key certificates may not be= feasible due
> >> to the incurred overhead, e.g. for when authenticating using = EDHOC
> >> (draft-ietf-lake-edhoc).
> >>
> >> This functionality is thus a subset of what is already suppor= ted, but
> >> since the current solution is geared towards groups a differe= nt solution
> >> may be needed (although it is probably possible to reuse part= s from the
> >> existing schemes for provisioning and requesting public keys)= .
> >>
> >>
> >>
> >> With this in mind, I propose the following change (highlighte= d in
> >> boldface below):
> >>
> >>
> >>
> >> OLD
> >>
> >> The Working Group is charged with maintenance of the framewor= k and
> >> existing profiles thereof, and may undertake work to specify = profiles of
> >> the framework for additional secure communications protocols = (that are not
> >> necessarily limited to constrained endpoints, though the focu= s remains on
> >> deployment ecosystems with a substantial portion of constrain= ed devices).
> >>
> >>
> >>
> >> NEW
> >>
> >> The Working Group is charged with maintenance of the framewor= k and
> >> existing profiles thereof, and may undertake work to specify = profiles of
> >> the framework for additional secure communications protocols = *and **for
> >> additional **support services **providing* *authorized access= to crypto* *keys
> >> *(that are not necessarily limited to constrained endpoints, = though the
> >> focus remains on deployment ecosystems with a substantial por= tion of
> >> constrained devices).
> >>
> >>
> >>
> >> G=F6ran
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On 2020-10-15, 19:50, "Ace" <ace-bounces@ietf.org> wrote:<= br> > >>
> >> Hi,
> >>
> >> I would like to start the charter discussion. Here is a draft= of a
> >> proposed charter [1].
> >>
> >>
> >>
> >> It seems to be that additional discussion is needed with rega= rd to the
> >> last paragraph related certificate management. In particular = the discussion
> >> might revive a discussion that happened in 2017 [2] - when I = was not
> >> co-chair of ACE -and considered other expired work such as [3= ]. Please make
> >> this discussion constructive on this thread.
> >>
> >>
> >>
> >> The fundamental question is whether we need certificate manag= ement at
> >> this stage. If the answer is yes, and we have multiple propos= als, it would
> >> be good to clarify the position of the different proposals an= d evaluate
> >> whether a selection is needed or not before validating the ch= arter.
> >>
> >>
> >>
> >> Please provide your inputs on the mailing list before October= 30. Of
> >> course for minor edits, you may suggest them directly on the = google doc.
> >>
> >>
> >>
> >> Yours,
> >>
> >> Daniel
> >>
> >>
> >>
> >> [1]
> >> https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoD= iptY/edit?usp=3Dsharing
> >> <
> >> https://protect2.fireeye.com/v1/url?k=3D4f3d9c3b-118c475b-4f3ddca0-86e2237f= 51fb-627e48b069462d70&q=3D1&e=3D6924b2a6-e7e5-4ec1-a1af-c94637953dc= 5&u=3Dhttps%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjS= j2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing>
> >>
> >>
> >> [2]
> >> https://datatracker.ietf.org/doc/minutes-interim-2017-ace-03-201710191300/<= /a>
> >>
> >> [3] https://datatracker.ietf.org/doc/draft-selander-ace-eals/
> >>
> >>
> >>
> >> --
> >>
> >> Daniel Migault
> >>
> >>
> >>
> >> Ericsson
> >>
> >
> >
> > --
> > Daniel Migault
> > Ericsson
> >
>
>
> --
> Daniel Migault
> Ericsson

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

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


--
Daniel Migault
Ericsson

____________________________________________=
___
Ace mailing list
Ace@ie=
tf.org
https://www.ietf.org/mailman/listinfo/ace
--_000_DM6PR15MB2379308BD779061F6F46233EE3F20DM6PR15MB2379namp_-- From nobody Thu Dec 3 11:01:39 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF703A067A; Thu, 3 Dec 2020 11:01:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.076 X-Spam-Level: X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SPF_PERMERROR=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=telecom-bretagne.eu 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 vC46gYcX0NzB; Thu, 3 Dec 2020 11:01:29 -0800 (PST) Received: from zproxy120.enst.fr (zproxy120.enst.fr [IPv6:2001:660:330f:2::c1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89A8F3A064B; Thu, 3 Dec 2020 11:01:27 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by zproxy120.enst.fr (Postfix) with ESMTP id 37ACD80D57; Thu, 3 Dec 2020 20:01:25 +0100 (CET) Received: from zproxy120.enst.fr ([IPv6:::1]) by localhost (zproxy120.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id hbqJ2crASlQQ; Thu, 3 Dec 2020 20:01:24 +0100 (CET) Received: from localhost (localhost [IPv6:::1]) by zproxy120.enst.fr (Postfix) with ESMTP id 363378080D; Thu, 3 Dec 2020 20:01:24 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy120.enst.fr 363378080D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecom-bretagne.eu; s=CFDC2CFA-4654-11E5-AACD-7BCC68B6580D; t=1607022084; bh=PwiDt1aSyP6yxRqp7KLM/IdAF58HYfKpGOPJ5cyhe4I=; h=MIME-Version:From:Date:Message-ID:To; b=TuvQp6zcL8BvBrDHmT6BM62YCTOcjpQpaODjcqZdzowt5UNkIdEhgCgNCz300TGWK Q+iA0/KF8OIKIbUgo3w+yTiGI+CN2jqR4Pv0lUGjD7KBC1AWLY5qS+CdgCUN1ct+sE FEjeN5is5GXjo0F3q88rr9TEqqcywez/eeEOVLoU= X-Virus-Scanned: amavisd-new at zproxy120.enst.fr Received: from zproxy120.enst.fr ([IPv6:::1]) by localhost (zproxy120.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id IoFMnGYxcV6E; Thu, 3 Dec 2020 20:01:24 +0100 (CET) Received: from mail-io1-f41.google.com (mail-io1-f41.google.com [209.85.166.41]) by zproxy120.enst.fr (Postfix) with ESMTPSA id B675980D57; Thu, 3 Dec 2020 20:01:23 +0100 (CET) Received: by mail-io1-f41.google.com with SMTP id q137so3173903iod.9; Thu, 03 Dec 2020 11:01:23 -0800 (PST) X-Gm-Message-State: AOAM533fW5iEPD/sAyYRW35Kr3739DF/xblqwHftPoFo65xbTZdUvcv+ 4QXM3yGCo+RV+UIIDfejxUS8e1T5qWt0HAwedO8= X-Google-Smtp-Source: ABdhPJy5mefNbUhkstUmgpWiWp6Lp1f4PHQAUEsrCY3F55voNZLYdoQ/TfHj5B9ieJkIZR2PAM6SXhU7QGgHqZb/zDA= X-Received: by 2002:a5d:9a8e:: with SMTP id c14mr807929iom.178.1607022082534; Thu, 03 Dec 2020 11:01:22 -0800 (PST) MIME-Version: 1.0 References: <20201117234700.GR39170@kduck.mit.edu> In-Reply-To: From: Laurent Toutain Date: Thu, 3 Dec 2020 20:00:44 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Daniel Migault Cc: Dan Garcia , "ace@ietf.org" , EMU WG , "core@ietf.org WG (core@ietf.org)" Content-Type: multipart/alternative; boundary="00000000000060341a05b593fca0" Archived-At: Subject: Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 19:01:34 -0000 --00000000000060341a05b593fca0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I think it is important to have EAP on top of CoAP, as Dan said it fit well with the last charter item. Laurent On Thu, Dec 3, 2020 at 2:20 PM Daniel Migault wrote: > CCing emu, core > > It seems ACE to me that ACE could be home for such a document. I am > wondering if emu core or any other WG believe there is a better place for > it. > > Regarding ACE I am wondering what is the WG opinion about adding this ite= m > to the ACE charter. > > Yours, > Daniel > ------------------------------ > *From:* Ace on behalf of Dan Garcia < > dan.garcia@um.es> > *Sent:* Thursday, December 3, 2020 6:10 AM > *To:* ace@ietf.org > *Subject:* [Ace] Proposed charter for ACE (EAP over CoAP?) > > > Dear all: > > Regarding the new charter, since ACE is considering the definition of CoA= P > transport for CMPv2 ( > https://tools.ietf.org/html/draft-msahni-ace-cmpv2-coap-transport-00), we > were wondering whethere it could also consider specifying EAP (Extensible > Authentication Protocol) over CoAP. > > In this sense, we proposed this some time ago and we have implementations > about this. > > https://datatracker.ietf.org/doc/html/draft-marin-ace-wg-coap-eap-06 > https://www.mdpi.com/1424-8220/16/3/358 > https://www.mdpi.com/1424-8220/17/11/2646 > > The usage of CoAP can provide a very light and link-layer independent (we > even tested in LoRa networks) EAP lower-layer (transport for EAP) suitabl= e > for IoT enviroment. We believe this would be really useful since EAP > provides flexibility for the authentication and it is a well-known protoc= ol. > > Therefore, we would like to propose the following modification to the > charter: > > "The Working Group will examine how to use Constrained Application > Protocol (CoAP) as a transport medium for certificate enrollment protocol= s, > such as EST and CMPv2, *as well as a transport for authentication > protocols such as EAP*, and standardize them as needed." > > This modification does not necessarily mean the adoption of our draft. > After all, we completely understand that this would happen only if there = is > an interest in the WG. Nevertheless, we would like to avoid that the > charter is a barrier later if there is interest in the WG to work in this > transport of EAP over CoAP: > > Any opinion about this? > > Best Regards. > El 18/11/2020 a las 8:08, Daniel Migault escribi=C3=B3: > > Hi, > > Please find the proposed charter we agreed on during the interim meeting. > If you would like to propose any change, please use the following URL by > November 25: > > > https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXh= oDiptY/edit?usp=3Dsharing > > > Yours, > Daniel > > The Authentication and Authorization for Constrained Environments (ace) W= G > has defined a standardized solution framework for authentication and > authorization to enable authorized access to resources identified by a UR= I > and hosted on a resource server in constrained environments. > > The access to the resource is mediated by an authorization server, which > is not considered to be constrained. > > Profiles of this framework for application to security protocols commonly > used in constrained environments, including CoAP+DTLS and CoAP+OSCORE, ha= ve > also been standardized. The Working Group is charged with maintenance of > the framework and existing profiles thereof, and may undertake work to > specify profiles of the framework for additional secure communications > protocols and for additional support services providing authorized access > to crypto keys (that are not necessarily limited to constrained > endpoints, though the focus remains on deployment in ecosystems with a > substantial portion of constrained devices). > > In addition to the ongoing maintenance work, the Working Group will exten= d > the framework as needed for applicability to group communications, with > initial focus on (D)TLS and (Group) OSCORE as the underlying group > communication security protocols. The Working Group will standardize > procedures for requesting and distributing group keying material using th= e > ACE framework as well as appropriated management interfaces. > > The Working Group will standardize a format for expressing authorization > information for a given authenticated principal as received from an > authorization manager. > > The Working Group will examine how to use Constrained Application Protoco= l > (CoAP) as a transport medium for certificate enrollment protocols, such a= s > EST and CMPv2, and standardize as needed. > > > On Tue, Nov 17, 2020 at 6:47 PM Benjamin Kaduk wrote: > > Thanks for updating the draft charter at [1], Daniel! > > I note that Michael raised the question of whether some other group might > also be interested in working on CMP-over-coap, so the IESG will be sure = to > discuss that if CMP is still in the draft ACE charter when it goes to the > IESG for review. > > -Ben > > On Tue, Nov 17, 2020 at 06:16:48PM -0500, Daniel Migault wrote: > > Thank you all for the feed backs. For the purpose of driving the charte= r > > discussion at the IETf 109, I have added the comments into the proposed > > text [1]. > > > > My current understanding is that it seems beneficial to add CMPv2 over > CoAP > > in the charter. I am happy to be contradicted. > > * I have not seen a clear cut to do one or the other. > > * EST and CMPv2 are two protocols that can be used for enrollment or ce= rt > > management while addressing different cases / needs / situations -- may= be > > we can clarify that point. I can see leveraging the existing CMP > > infrastructure, but it seems that is not the only one. > > * I am not convinced that not having CMP over CoAP will not prevent its > > deployment and as such I prefer to have it standardized - this might be= a > > personal thought. > > * Adding any piece of work require cycles, but it seems to me that CPM > will > > not have a major impact on the WG progress. The work will probably > include > > other WG such a LAMPS. > > > > Yours, > > Daniel > > > > [1] > > > https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXh= oDiptY/edit?usp=3Dsharing > > > > > On Tue, Nov 17, 2020 at 6:02 PM Daniel Migault > wrote: > > > > > Hi Goran, > > > > > > I added the text to the charter we will discuss later. > > > > > > Yours, > > > Daniel > > > > > > On Fri, Nov 13, 2020 at 10:26 AM G=C3=B6ran Selander < > > > goran.selander@ericsson.com> wrote: > > > > > >> Hi Daniel, > > >> > > >> > > >> > > >> Here=E2=80=99s another input to the charter. > > >> > > >> > > >> > > >> The current group key management solutions addresses the problem of > > >> authorized access to group keys and public keys of group members. > > >> > > >> > > >> > > >> A related problem is authorized access of public keys of other devic= es > > >> not necessarily part of a security group, in the sense of sharing a > > >> symmetric key used to protect group messages. > > >> > > >> > > >> > > >> Authorized access to raw public keys serves an important function in > > >> constrained settings where public key certificates may not be > feasible due > > >> to the incurred overhead, e.g. for when authenticating using EDHOC > > >> (draft-ietf-lake-edhoc). > > >> > > >> This functionality is thus a subset of what is already supported, bu= t > > >> since the current solution is geared towards groups a different > solution > > >> may be needed (although it is probably possible to reuse parts from > the > > >> existing schemes for provisioning and requesting public keys). > > >> > > >> > > >> > > >> With this in mind, I propose the following change (highlighted in > > >> boldface below): > > >> > > >> > > >> > > >> OLD > > >> > > >> The Working Group is charged with maintenance of the framework and > > >> existing profiles thereof, and may undertake work to specify profile= s > of > > >> the framework for additional secure communications protocols (that > are not > > >> necessarily limited to constrained endpoints, though the focus > remains on > > >> deployment ecosystems with a substantial portion of constrained > devices). > > >> > > >> > > >> > > >> NEW > > >> > > >> The Working Group is charged with maintenance of the framework and > > >> existing profiles thereof, and may undertake work to specify profile= s > of > > >> the framework for additional secure communications protocols *and > **for > > >> additional **support services **providing* *authorized access to > crypto* *keys > > >> *(that are not necessarily limited to constrained endpoints, though > the > > >> focus remains on deployment ecosystems with a substantial portion of > > >> constrained devices). > > >> > > >> > > >> > > >> G=C3=B6ran > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> On 2020-10-15, 19:50, "Ace" wrote: > > >> > > >> Hi, > > >> > > >> I would like to start the charter discussion. Here is a draft of a > > >> proposed charter [1]. > > >> > > >> > > >> > > >> It seems to be that additional discussion is needed with regard to t= he > > >> last paragraph related certificate management. In particular the > discussion > > >> might revive a discussion that happened in 2017 [2] - when I was not > > >> co-chair of ACE -and considered other expired work such as [3]. > Please make > > >> this discussion constructive on this thread. > > >> > > >> > > >> > > >> The fundamental question is whether we need certificate management a= t > > >> this stage. If the answer is yes, and we have multiple proposals, it > would > > >> be good to clarify the position of the different proposals and > evaluate > > >> whether a selection is needed or not before validating the charter. > > >> > > >> > > >> > > >> Please provide your inputs on the mailing list before October 30. Of > > >> course for minor edits, you may suggest them directly on the google > doc. > > >> > > >> > > >> > > >> Yours, > > >> > > >> Daniel > > >> > > >> > > >> > > >> [1] > > >> > https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXh= oDiptY/edit?usp=3Dsharing > > > >> < > > >> > https://protect2.fireeye.com/v1/url?k=3D4f3d9c3b-118c475b-4f3ddca0-86e223= 7f51fb-627e48b069462d70&q=3D1&e=3D6924b2a6-e7e5-4ec1-a1af-c94637953dc5&u=3D= https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8Du= BwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing > > > > >> > > >> > > >> [2] > > >> > https://datatracker.ietf.org/doc/minutes-interim-2017-ace-03-201710191300= / > > >> > > >> [3] https://datatracker.ietf.org/doc/draft-selander-ace-eals/ > > >> > > >> > > >> > > >> -- > > >> > > >> Daniel Migault > > >> > > >> > > >> > > >> Ericsson > > >> > > > > > > > > > -- > > > Daniel Migault > > > Ericsson > > > > > > > > > -- > > Daniel Migault > > Ericsson > > > _______________________________________________ > > Ace mailing list > > Ace@ietf.org > > https://www.ietf.org/mailman/listinfo/ace > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > > > -- > Daniel Migault > Ericsson > > _______________________________________________ > Ace mailing listAce@ietf.orghttps://www.ietf.org/mailman/listinfo/ace > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --=20 Laurent Toutain +--- VoIP (recommended) ---+----------- T=C3=A9l=C3=A9com Bretagne --------= ---+ | Tel: +33 2 22 06 8156 | Tel: + 33 2 99 12 7026 | Visit : | Mob: +33 6 800 75 900 | | | Fax: +33 2 22 06 8445 | Fax: +33 2 99 12 7030 | http://class.touta.in | Laurent@Touta.in | Laurent.Toutain@Telecom-Bretagne.eu | +--------------------------+----------------------------------------+ --00000000000060341a05b593fca0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I think it is important to have EAP= on top of CoAP, as Dan said it fit well with the last charter item.
<= div>
Laurent

On Thu, Dec 3, 2020 at 2:20 PM Daniel Migau= lt <daniel.migault=3D40ericsson.com@dmarc.ietf.org> wrote:
CCing emu, core

It seems ACE to me that ACE could be home for such a document. I am wonderi= ng if emu core or any other WG believe there is a better place for it.=C2= =A0

Regarding ACE I am wondering what is the WG opinion about adding this item = to the ACE charter.=C2=A0

Yours,=C2=A0
Daniel
From: Ace <ace-bounces@ietf.org> on behalf of Dan Garc= ia <dan.garcia@um.= es>
Sent: Thursday, December 3, 2020 6:10 AM
To: ace@ietf.org <ace@ietf.org&g= t;
Subject: [Ace] Proposed charter for ACE (EAP over CoAP?)
=C2=A0

Dear all:

Regarding the new charter, since ACE is considering the definition of CoAP = transport for CMPv2 (https://tools.ietf.org/html/dr= aft-msahni-ace-cmpv2-coap-transport-00), we were wondering whethere it could also consider specifying EAP (Extensib= le Authentication Protocol) over CoAP.

In this sense, we proposed this some time ago and we have implementations a= bout this.

https://datatracker.ietf.org/doc/html/draft-marin-a= ce-wg-coap-eap-06
https= ://www.mdpi.com/1424-8220/16/3/358
htt= ps://www.mdpi.com/1424-8220/17/11/2646

The usage of CoAP can provide a very light and link-layer independent (we e= ven tested in LoRa networks) EAP lower-layer (transport for EAP) suitable f= or IoT enviroment. We believe this would be really useful since EAP provide= s flexibility for the authentication and it is a well-known protocol.

Therefore, we would like to propose the following modification to the chart= er:

"The Working Group will examine how to use Constrained Application Pro= tocol (CoAP) as a transport medium for certificate enrollment protocols, su= ch as EST and CMPv2, as well as a transport for authentication protocols such as EAP, and= standardize them as needed."

This modification does not necessarily mean the adoption of our draft. Afte= r all, we completely understand that this would happen only if there is an = interest in the WG. Nevertheless, we would like to avoid that the charter i= s a barrier later if there is interest in the WG to work in this transport of EAP over CoAP:

Any opinion about this?

Best Regards.

El 18/11/2020 a las 8:08, Daniel Migault escribi=C3=B3:
Hi,=C2=A0

Please find the proposed charter we agreed on during the interim meeti= ng. If you would like to propose any change, please use the following URL b= y November 25:


Yours,=C2=A0
Daniel

= The Authentication and Authorization for Constrained Environments (ace) WG has= defined a standardized solution framework for authentication and authoriza= tion to enable authorized access to resources identified by a URI and hoste= d on a resource server in constrained environments.=C2=A0

= The access to the resource is mediated by an authorization server, which is no= t considered to be constrained.


= Profiles of this framework for application to security protocols commonly used in c= onstrained environments, including CoAP+DTLS and CoAP+OSCORE, have also bee= n standardized.=C2=A0 The Working Group is charged with maintenance of the = framework and existing profiles thereof, and may undertake work to specify profiles of the framework for additional= secure communications protocols and for additional support services providing a= uthorized access to crypto keys (that are not necessarily limited to constrained endpoints, though the foc= us remains on deployment in ecosystems with a substantial portion of constr= ained devices).


= In addition to the ongoing maintenance work, the Working Group will extend th= e framework as needed for applicability to group communications, with initi= al focus on (D)TLS and (Group) OSCORE as the underlying group communication= security protocols. The Working Group will standardize procedures for requesting and distributing group ke= ying material using the ACE framework as well as appropriated management in= terfaces.=C2=A0


= The Working Group will standardize a format for expressing authorization infor= mation for a given authenticated principal as received from an authorizatio= n manager.=C2=A0


= The Working Group will examine how to use Constrained Application Protocol (Co= AP) as a transport medium for certificate enrollment protocols, such as EST= and CMPv2, and standardize as needed.



On Tue, Nov 17, 2020 at 6:47 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
Thanks for updating the draft charter at [1], Daniel!

I note that Michael raised the question of whether some other group might also be interested in working on CMP-over-coap, so the IESG will be sure to=
discuss that if CMP is still in the draft ACE charter when it goes to the IESG for review.

-Ben

On Tue, Nov 17, 2020 at 06:16:48PM -0500, Daniel Migault wrote:
> Thank you all for the feed backs. For the purpose of driving the chart= er
> discussion at the IETf 109, I have added the comments into the propose= d
> text [1].
>
> My current understanding is that it seems beneficial to add CMPv2 over= CoAP
> in the charter. I am happy to be contradicted.
> * I have not seen a clear cut to do one or the other.
> * EST and CMPv2 are two protocols that can be used for enrollment or c= ert
> management while addressing different cases / needs / situations -- ma= ybe
> we can clarify that point. I can see leveraging the existing CMP
> infrastructure, but it seems that is not the only one.
> * I am not convinced that not having CMP over CoAP will not prevent it= s
> deployment and as such I prefer to have it standardized - this might b= e a
> personal thought.
> * Adding any piece of work require cycles, but it seems to me that CPM= will
> not have a major impact on the WG progress. The work will probably inc= lude
> other WG such a LAMPS.
>
> Yours,
> Daniel
>
> [1]
> https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoD= iptY/edit?usp=3Dsharing
>
> On Tue, Nov 17, 2020 at 6:02 PM Daniel Migault <mglt.ietf@gmail.com> wrote: >
> > Hi Goran,
> >
> > I added the text to the charter we will discuss later.
> >
> > Yours,
> > Daniel
> >
> > On Fri, Nov 13, 2020 at 10:26 AM G=C3=B6ran Selander <
> > = goran.selander@ericsson.com> wrote:
> >
> >> Hi Daniel,
> >>
> >>
> >>
> >> Here=E2=80=99s another input to the charter.
> >>
> >>
> >>
> >> The current group key management solutions addresses the prob= lem of
> >> authorized access to group keys and public keys of group memb= ers.
> >>
> >>
> >>
> >> A related problem is authorized access of public keys of othe= r devices
> >> not necessarily part of a security group, in the sense of sha= ring a
> >> symmetric key used to protect group messages.
> >>
> >>
> >>
> >> Authorized access to raw public keys serves an important func= tion in
> >> constrained settings where public key certificates may not be= feasible due
> >> to the incurred overhead, e.g. for when authenticating using = EDHOC
> >> (draft-ietf-lake-edhoc).
> >>
> >> This functionality is thus a subset of what is already suppor= ted, but
> >> since the current solution is geared towards groups a differe= nt solution
> >> may be needed (although it is probably possible to reuse part= s from the
> >> existing schemes for provisioning and requesting public keys)= .
> >>
> >>
> >>
> >> With this in mind, I propose the following change (highlighte= d in
> >> boldface below):
> >>
> >>
> >>
> >> OLD
> >>
> >> The Working Group is charged with maintenance of the framewor= k and
> >> existing profiles thereof, and may undertake work to specify = profiles of
> >> the framework for additional secure communications protocols = (that are not
> >> necessarily limited to constrained endpoints, though the focu= s remains on
> >> deployment ecosystems with a substantial portion of constrain= ed devices).
> >>
> >>
> >>
> >> NEW
> >>
> >> The Working Group is charged with maintenance of the framewor= k and
> >> existing profiles thereof, and may undertake work to specify = profiles of
> >> the framework for additional secure communications protocols = *and **for
> >> additional **support services **providing* *authorized access= to crypto* *keys
> >> *(that are not necessarily limited to constrained endpoints, = though the
> >> focus remains on deployment ecosystems with a substantial por= tion of
> >> constrained devices).
> >>
> >>
> >>
> >> G=C3=B6ran
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On 2020-10-15, 19:50, "Ace" <ace-bounces@ietf.org> wrote:<= br> > >>
> >> Hi,
> >>
> >> I would like to start the charter discussion. Here is a draft= of a
> >> proposed charter [1].
> >>
> >>
> >>
> >> It seems to be that additional discussion is needed with rega= rd to the
> >> last paragraph related certificate management. In particular = the discussion
> >> might revive a discussion that happened in 2017 [2] - when I = was not
> >> co-chair of ACE -and considered other expired work such as [3= ]. Please make
> >> this discussion constructive on this thread.
> >>
> >>
> >>
> >> The fundamental question is whether we need certificate manag= ement at
> >> this stage. If the answer is yes, and we have multiple propos= als, it would
> >> be good to clarify the position of the different proposals an= d evaluate
> >> whether a selection is needed or not before validating the ch= arter.
> >>
> >>
> >>
> >> Please provide your inputs on the mailing list before October= 30. Of
> >> course for minor edits, you may suggest them directly on the = google doc.
> >>
> >>
> >>
> >> Yours,
> >>
> >> Daniel
> >>
> >>
> >>
> >> [1]
> >> https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoD= iptY/edit?usp=3Dsharing
> >> <
> >> https://protect2.fireeye.com/v1/url?k=3D4f3d9c3b-118c475b-4f3ddca0-86e2237f= 51fb-627e48b069462d70&q=3D1&e=3D6924b2a6-e7e5-4ec1-a1af-c94637953dc= 5&u=3Dhttps%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjS= j2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing>
> >>
> >>
> >> [2]
> >> https://datatracker.ietf.org/doc/minutes-interim-2017-ace-03-201710191300/<= /a>
> >>
> >> [3] https://datatracker.ietf.org/doc/draft-selander-ace-eals/
> >>
> >>
> >>
> >> --
> >>
> >> Daniel Migault
> >>
> >>
> >>
> >> Ericsson
> >>
> >
> >
> > --
> > Daniel Migault
> > Ericsson
> >
>
>
> --
> Daniel Migault
> Ericsson

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

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


--
Daniel Migault
Ericsson

_______________________________________________
Ace mailing list
Ace@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/ace
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core


--
Laurent Toutain=C2=A0
+---= VoIP (recommended) ---+----------- T=C3=A9l=C3=A9com Bretagne -----------+=
| Tel: +33 2 22 06 8156 =C2=A0 =C2=A0| Tel: + 33 2 99 12 7026 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Visit :
| Mob: +33 6 800 75 900 =C2=A0 = =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<= /font>
| Fax: +33= 2 22 06 8445 =C2=A0 =C2=A0| Fax: +33 2 99 12 7030 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0http://class.touta.in
| Laurent@Touta.in =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | Laurent.Toutain@Telecom-Bretagne.eu =C2=A0 =C2= =A0|
+--------------------------+---------------------------------------= -+
--00000000000060341a05b593fca0-- From nobody Thu Dec 3 11:57:51 2020 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2D03A0983; Thu, 3 Dec 2020 11:57:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Brian Weis via Datatracker To: Cc: last-call@ietf.org, draft-ietf-core-dev-urn.all@ietf.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160702546541.14061.15940689920006174458@ietfa.amsl.com> Reply-To: Brian Weis Date: Thu, 03 Dec 2020 11:57:45 -0800 Archived-At: Subject: [core] Secdir last call review of draft-ietf-core-dev-urn-08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 19:57:46 -0000 Reviewer: Brian Weis Review result: Serious Issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready with nits. This document generally defines a new URN namespace for hardware device identifiers, and then further defines the URN body layout for several types of devices, where devices are identified by a global identity (e.g., a MAC address, organizational-specific serial number, etc.). Long-term identifiers have privacy considerations, and these are well documented here. Here are some things that ought to be thought about: (1) The Security Considerations section seems to focus on concerns around devices not allowing the device identifiers to be modified, and gives rather broad advice about a DEV URN implementation faithfully representing the device. It would be good for this section to also warn implementors of the risks of a DEV URN being transmitted without integrity protection. That is, if the device faithfully represents itself, a man in the middle changing the DEV URN in a protocol may cause the system using the device to not manage the device properly, or in some manner inappropriately adjust the privileges allowed by the device within that system. (2) Section 1 says about privacy “Note that long-term stable unique identifiers are problematic for privacy reasons and should be used with care or avoided as described in [RFC7721].†Given the later guidance that “The DEV URN type SHOULD only be used for persistent identifiersâ€, I think the “or avoided†portion of that sentence is inappropriate for this document. (3) Section 5 begins with “The following three examples provide examples of MAC-based, 1-Wire, and Cryptographic identifiersâ€. There are now more than three examples provided (thanks for that!), and it appears that cryptographic identifiers have ben removed in an earlier draft. From nobody Thu Dec 3 12:04:16 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557EF3A0A71; Thu, 3 Dec 2020 12:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUS3cAhI0F7I; Thu, 3 Dec 2020 12:04:06 -0800 (PST) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEEBF3A0A26; Thu, 3 Dec 2020 12:04:03 -0800 (PST) Received: by mail-pf1-x430.google.com with SMTP id t8so2026863pfg.8; Thu, 03 Dec 2020 12:04:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=O7LOZBcv5AUbyL1hB+zamToePkHY6bTqGg2rBeTzKd8=; b=hwwigHKdbdkZA+BdOm9rTgbcr3Ijgypw8X9ORLTyYJ9PTK+otOkRPqO6vqkeBg8fLr dPcdDnrtEpdDM4kBIND4TlGL7O7lYnw+Jf2REEaRF2eBpA45J73VgXrrM4PYFbkn/d2Q y07xRjx5qSdE/vjf3fg6u3hacdc9+A2nxO7Y5V6De+hT/6oRsM0JKo+pQcZSA2HiIa2A zFcp5sFMyvstnGVjiTb7WPM74xNcyWHLs1+BRjo5WaKrR2Z9PZk+xfJShBFDnwoWBinL pmdf0b6qegCftDoX2iTBQo2TX3tXxFWEFtLdW14Ljwhgt7MM8leNbQRR05gtQLkoyNA2 OE9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=O7LOZBcv5AUbyL1hB+zamToePkHY6bTqGg2rBeTzKd8=; b=EE8Y5pTPu9DUZKzZ4gw1/jT3Qqz2+9LIPReMNFzb8Zx/Zr2giEYG0mlQydQhOPMtTH QQNlIMYkxyhndjoQ7dJSO87UbxeVvaGt21HxGsLJJRovdQs/MjLaWnR4LvkbCJ8YBE9d 1jD1+xJGUAO3vHxwrNR+YVXZ7CZnMrsvyEv8QLrHFH3xTabP7CTQfMjMHgIIJTtaEvzq jvbadUmaef7yv0LkSadb28gc9x00X1a/HmVRTbjv7XZSrL3eyaTEpQlgkP59Qtx0ZeMI 95st5NZfu+pJhkD0Xye2ghk3vX/HdVgjftSaqejavqh9iKYPZIKs9FaOqxIISH6TjWUv kTyA== X-Gm-Message-State: AOAM5331YMWzERqfe2WlmhdY3u1neC2BxtgqBGeUQphErIABmlutJy/J 5GS2+ax62KwiZrap5M6+VJtrwQ8dU3E= X-Google-Smtp-Source: ABdhPJwvBHQ3HZHVFze8OdHtIj+85ig0fygQv9w8VvFFhbb02g+aKF31r5Nn2hfvPcGt7u/NsOu0Dg== X-Received: by 2002:aa7:864b:0:b029:18e:fc45:f2a1 with SMTP id a11-20020aa7864b0000b029018efc45f2a1mr603848pfo.58.1607025842762; Thu, 03 Dec 2020 12:04:02 -0800 (PST) Received: from ?IPv6:2603:3024:151c:c200:545f:374a:e165:7255? ([2603:3024:151c:c200:545f:374a:e165:7255]) by smtp.gmail.com with ESMTPSA id x10sm1305593pff.214.2020.12.03.12.04.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Dec 2020 12:04:02 -0800 (PST) From: Brian Weis Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 3 Dec 2020 12:04:01 -0800 References: <160702546541.14061.15940689920006174458@ietfa.amsl.com> To: secdir@ietf.org, last-call@ietf.org, draft-ietf-core-dev-urn.all@ietf.org, core@ietf.org In-Reply-To: <160702546541.14061.15940689920006174458@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [core] [secdir] Secdir last call review of draft-ietf-core-dev-urn-08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 20:04:09 -0000 Oops: this review is marked =E2=80=9CSerious Issues=E2=80=9D, where (as = mentioned in the comments)=20 I intended it to be =E2=80=9CReady with nits=E2=80=9D. Sorry for the = confusion. Brian > On Dec 3, 2020, at 11:57 AM, Brian Weis via Datatracker = wrote: >=20 > Reviewer: Brian Weis > Review result: Serious Issues >=20 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should > treat these comments just like any other last call comments. >=20 > The summary of the review is Ready with nits. >=20 > This document generally defines a new URN namespace for hardware > device identifiers, and then further defines the URN body layout > for several types of devices, where devices are identified by a > global identity (e.g., a MAC address, organizational-specific serial > number, etc.). >=20 > Long-term identifiers have privacy considerations, and these are > well documented here. >=20 > Here are some things that ought to be thought about: >=20 > (1) The Security Considerations section seems to focus on concerns > around devices not allowing the device identifiers to be modified, > and gives rather broad advice about a DEV URN implementation > faithfully representing the device. It would be good for this section > to also warn implementors of the risks of a DEV URN being transmitted > without integrity protection. That is, if the device faithfully > represents itself, a man in the middle changing the DEV URN in a > protocol may cause the system using the device to not manage the > device properly, or in some manner inappropriately adjust the = privileges > allowed by the device within that system. >=20 > (2) Section 1 says about privacy =E2=80=9CNote that long-term stable = unique > identifiers are problematic for privacy reasons and should be used > with care or avoided as described in [RFC7721].=E2=80=9D Given the = later > guidance that =E2=80=9CThe DEV URN type SHOULD only be used for = persistent > identifiers=E2=80=9D, I think the =E2=80=9Cor avoided=E2=80=9D portion = of that sentence is > inappropriate for this document. >=20 > (3) Section 5 begins with =E2=80=9CThe following three examples = provide > examples of MAC-based, 1-Wire, and Cryptographic identifiers=E2=80=9D. = There=20 > are now more than three examples provided (thanks for that!), and=20 > it appears that cryptographic identifiers have ben removed in an > earlier draft. >=20 >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Thu Dec 3 23:09:46 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA083A13CE; Thu, 3 Dec 2020 23:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 KHo4buFy3Sku; Thu, 3 Dec 2020 23:09:43 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A34F93A13DD; Thu, 3 Dec 2020 23:09:39 -0800 (PST) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 4CnP3625t5zFqBQ; Fri, 4 Dec 2020 08:09:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1607065778; bh=E/i9/alpKPCTK7An5EqCK6aGVKhu50dbgzkSaHKJu2o=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=qtuwJ9zyDYFgq0mY7cTwvTizjc1WQ/k5VBo1u6rI60JyVKm/LqdVkh4JISdmkr4Gy /7bLWDCqMM7xu+MX9ZBKho4drHnlM9WeqpXW1k6EsMaAoJlFLIeC419c0s8n5qvdqF pSFFAk+Ggmm3F9Fl5fnm18iwM2wSPAq2OpAyjhXPbZb7yu9v1EgIy1V6xw8MUunNtB +tV081jghUNMFfISBbzUSYzPfO9JdiiEI1vS4JdMtxhulylvM2olAnCwTO+1C+DWoM 03Cw807NYZarL61Z2eMw9G5c6M4QkWJ6m2zUc8BceLYz3ZneDOHwxDa8CK0cFsvzOV PFDebqXr7Wneg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.32]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 4CnP361H8yzBrLH; Fri, 4 Dec 2020 08:09:38 +0100 (CET) From: To: "core@ietf.org" CC: "draft-ietf-core-new-block@ietf.org" Thread-Topic: [core] I-D Action: draft-ietf-core-new-block-02.txt Thread-Index: AQHWrdIa8yVLED9E30qpUa9+hbqji6muSJ2ggDhpSDA= Date: Fri, 4 Dec 2020 07:09:36 +0000 Message-ID: <14502_1607065778_5FC9E0B2_14502_140_1_787AE7BB302AE849A7480A190F8B93303159665A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160396208446.12555.831863472742513@ietfa.amsl.com> <8668_1603963155_5F9A8913_8668_225_1_787AE7BB302AE849A7480A190F8B933031568F6C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <8668_1603963155_5F9A8913_8668_225_1_787AE7BB302AE849A7480A190F8B933031568F6C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-new-block-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2020 07:09:45 -0000 Hi all,=20 We raised during the IETF#109 whether (and if so how) it is worth to suppor= t an: optimization when MAX_PAYLOADS are exhausted but the network/peer can= still handle more blocks without being congested.=20 We understood from the discussion that this is left to the authors and the = use case that triggered this draft: DDoS case. Here is our assessment from = DOTS perspective:=20 * Q-Block1: It is likely that these blocks will make it through as the DDoS= traffic is in the other direction. No-Response option can be sufficient he= re, but we are not comfortable to use a normative language for No-Response = as this is an ISE and will create a downref. A document in the standards tr= ack would be appropriate it.=20 * The situation is different for Q-Block2 as the pipe is likely to be satur= ated. The turnaround to avoid ack-timeout is of less importance. Telemetry = data can still fly from the client to the server (Q-Block1) but the one fro= m the server to the client will be subject to losses.=20 So, our plan is to leave the note that records the issue without adding any= mention to No-Response. Solutions can be considered in the future when the= WG reconsiders a replacement of current blocks:=20=20=20=20=20=20=20 Note: A delay of ACK_TIMEOUT after every transmission of MAX_PAYLOADS blocks may be observed even if the peer agent is able to handle more blocks without experiencing an overload. This delay can be reduced by using CON for the MAX_PAYLOADS packet to trigger sending the next set of data when the ACK is received. Nevertheless, this behavior is likely to create other timeout issues in a lossy environment (e.g., unidirectional loss as in DDoS pipe flooding). The use of NON is thus superior but requires an additional signal in the MAX_PAYLOADS packet to seek for a 2.31 (Continue) from the peer if it is ready to receive the next set of blocks. As this was the only pending issue we identified, and unless there is an ob= jection or other proposals, we request a WGLC on -02. Thank you.=20 Cheers, Med > -----Message d'origine----- > De=A0: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Envoy=E9=A0: jeudi 29 octobre 2020 10:19 > =C0=A0: core@ietf.org > Cc=A0: draft-ietf-core-new-block@ietf.org > Objet=A0: RE: [core] I-D Action: draft-ietf-core-new-block-02.txt >=20 > Hi all, >=20 > We published the -02 as per the plan presented in the interim. The > main changes are to reflect the outcomes of the interim: > (1) Add a statement that either both or neither options can be > supported. > (2) Add an implementation note about how tokens are handled. > (3) Change the name of the options. > (4) Add a clarification about the behaviour when multiple instances > of Q-Block2 are included. > (5) Remove the "MUST NOT" restriction on 2.31 (Continue) as a > provision to (9). > (6) Clarify what is meant by "repeat request". Marco, please check > if the NEW wording is better. > (7) Overflow discussion. Michael, please check and let us know if we > need to say more. > (8) Update the CDDL and add an implementation note to suggest the > use of indefinite-length arrays. > (9) Add a note about the ACK_TIMEOUT delay after MAX_PAYLOADS. >=20 > We are waiting for the feedback from the WG whether (9) is worth to > be solved at the CoAP level. This is the main pending issue that we > would like to fix before asking for the WGLC > (https://mailarchive.ietf.org/arch/msg/core/uoXMI8vcsGoto6fa1GpgftXS > -cU/). >=20 > Please review and share your comments. >=20 > Cheers, > Jon & Med >=20 > > -----Message d'origine----- > > De=A0: core [mailto:core-bounces@ietf.org] De la part de internet- > > drafts@ietf.org Envoy=E9=A0: jeudi 29 octobre 2020 10:01 =C0=A0: > > i-d-announce@ietf.org Cc=A0: core@ietf.org Objet=A0: [core] I-D > Action: > > draft-ietf-core-new-block-02.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Constrained RESTful Environments > WG > > of the IETF. > > > > Title : Constrained Application Protocol (CoAP) > > Block-Wise Transfer Options for Faster Transmission > > Authors : Mohamed Boucadair > > Jon Shallow > > Filename : draft-ietf-core-new-block-02.txt > > Pages : 25 > > Date : 2020-10-29 > > > > Abstract: > > This document specifies alternative Constrained Application > > Protocol > > (CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2 > Options. > > > > These options are similar to the CoAP Block1 and Block2 > Options, > > not > > a replacement for them, but do enable faster transmission rates > for > > large amounts of data with less packet interchanges as well as > > supporting faster recovery should any of the blocks get lost in > > transmission. > > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Fri Dec 4 00:13:10 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0AD3A145B for ; Fri, 4 Dec 2020 00:13:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SLnmcrolkQt for ; Fri, 4 Dec 2020 00:13:05 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80047.outbound.protection.outlook.com [40.107.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7612A3A1486 for ; Fri, 4 Dec 2020 00:13:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TY3kbmj4KhiC/rZ9iCmo3Rfw1zduMWa7JlbPRUbRLlu3jDEWc2u2uSmf+ApaFt2DlO+ItMq+qvjmf6l+oDWBc26dt93J/cgh3KVma15/t64HvnUHZfCpM3DqbmXOFkD6i6RXkoDzK5w2WMjxsweoYkEnWFaSWq5OnDelqBbCh013d2f9xyFF1dQpZEqqb+Zr4cqCxaIgoNnIl5sDK34KJs2o38FWgQoo0l8KkH94cemp3CGadX9aC7iHMOMEz4yeQ1/zs9Rm4YtdsY0ouJct0KJSGNu0NoYMdCHxuQGOud1F69f3hYpQIcS8VsdzaFooYD3hRkQdXHuj0GnGJH1Mzw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=A131Dol1uXbf0SuEMrMvLPA4RRBQCmmd7l3NHGVl/rY=; b=SSCoh8kDNBAW0bTllFbUpfcdbwJup4ZfBn7VlErxBevOzhHGGtp1PZlHdS/pu3CWrNjjDxa7eX2SodfTCtjPOBxH0q0hgPxgATtIFjr6+GTCsXLXV7ypmRxqZxHrr5yYkcremLSbnKImGIHYQYWLvwKkuunYs20HCbTcDh4iOAX6dX6kLWS/buNHFlYytx7UA/B65qltWl/oR8k30+5yz3/9s0H6k/i/u4hKqFqMHJp10sPqHKfoaXfRoAujklEwrkH5sZdNGXbJIRCHhpq9XfocWqDxIf8kReuAm1vnGlRBMSTFNA3JNXf7N8YeXh8bCkwhmKykCrusi5Oo7B9x+g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=A131Dol1uXbf0SuEMrMvLPA4RRBQCmmd7l3NHGVl/rY=; b=K5nn3R5EZecRcr3/UXtYIKuDyUotXeo+Pp/w0RbZxuNwQF6JQUE00pnLZEvRnBrYycJCHsNenWh8CzZwoqN3lIuaa0B8uy86VTn9JkyuilwJvYEeuNeWS00dyk5qj9FkPW9VnCg6gcYE7MGFN86rHtgaU4pTGJ+Szm2tSvqM9Gk= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB8P189MB0998.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:165::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.19; Fri, 4 Dec 2020 08:13:02 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::c906:d500:5041:56fd]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::c906:d500:5041:56fd%9]) with mapi id 15.20.3632.021; Fri, 4 Dec 2020 08:13:01 +0000 To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: <524bd9f3-e062-26ad-a5d0-93de7098ac39@ri.se> Date: Fri, 4 Dec 2020 09:12:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="AQsPVECVZwsxe2qhEb77wmyNj2sDamBVQ" X-Originating-IP: [84.17.36.151] X-ClientProxiedBy: HE1PR05CA0259.eurprd05.prod.outlook.com (2603:10a6:3:fc::11) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.3.14] (84.17.36.151) by HE1PR05CA0259.eurprd05.prod.outlook.com (2603:10a6:3:fc::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.17 via Frontend Transport; Fri, 4 Dec 2020 08:13:01 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8c1838c2-3684-4b26-e7b3-08d8982c6b24 X-MS-TrafficTypeDiagnostic: DB8P189MB0998: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6790; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: CU3VYVtUL79tXjDt+Rz1J48MwbwNyCnuFSm+ugRYZ+Ce6YofRk+z63Rww6vRHtjwR6/iupkDf0xgz3lpmEDfFychLkvm4E3teKszOv7sHpPbkfaT8ckwE3GsMKhmawnuqy+TH8nVSd+UtEnbunHWsYz6VLywN0gwHmS3Q2dANvzavmO+k2mG0ltG5LHdz7MDAImSlpdnTFcyEJZWPbBukxZBVsZHHAARNqX+/l19+DPgEsl04KU9La+BB/4zU9AtcaR6bJFxnC8fdQaCJASEGl6hy5St20zes89z5yWfm9LpmiA7Gh2AAzpMYCyhnTfXZECW2snm7aeO+Qn4/n1/aO0Pix7wUtYyBv8dzpoXOVOUmZfn08+Fos3SAIdtdRYxtuJexTQ1QCE46HuvDD+nfyDKtD17Q8pa1f0h0ozbxOf6ejfN0twhGIKIiSxUJ79lkBIurTdMJLtVUqYsjrWNsyatSLRYs7uzrkV0aseqMXrqZeARkyJxOib+Vn1T6kYS X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(396003)(376002)(39850400004)(346002)(136003)(366004)(21480400003)(6916009)(86362001)(16576012)(966005)(478600001)(26005)(5660300002)(33964004)(235185007)(956004)(52116002)(2616005)(8676002)(83380400001)(6486002)(16526019)(44832011)(31686004)(8936002)(186003)(2906002)(316002)(36756003)(66476007)(31696002)(66946007)(6666004)(66556008)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?K1YwVy9xRFo4ZHVKa1I5aTRiTmo5enROV0V6K2xjVE9iZ2IrVXFwMlFralNL?= =?utf-8?B?WU9mMkxFWmRwZHc3ZmhxWHl2ZGUrUG1XNlBjbVlEbW4ySVdXVUdLRmtOTFc5?= =?utf-8?B?cGhSRDlxQ0tYb3pnSHVnMFBNeUcrWFoyMjBidnJTNzNKbVRRQUZHS3RCQzhG?= =?utf-8?B?K2htOUZEOGZwcEJQSDlLU2dCOWk4QXpOZ3RwSE1VOWxwdVF3Ky9HM0dSdktj?= =?utf-8?B?S1Z0MGcvdUh2TWppQmdJTW1vbEpkSlhiWEU5US8vbmVuZW5rRjFpNUVMRTBV?= =?utf-8?B?NG9Ub1Q3R3lHRlIxVmZ2dW91cmJLUXM3WVI4eU9XdStTNUw1SmFyNk9ab0F1?= =?utf-8?B?MytscjlUWVU2SXFodTdXSkN6ODRXdENvOEZyVzU5ZGdZeXRPeGxuTVFKZ20x?= =?utf-8?B?VUhhTVdVNDltQkRrTTU2YnZpWENlM1RJMGxvYUQzK3NuRlRaM3BFRG5yZHdi?= =?utf-8?B?UE4yR1kxeTNoMnA4MkgxbU9wU0ZBcXB1SEV0Tnd4U0JUZVZ4eXlDTnVYb215?= =?utf-8?B?MnM4RDQ2UnJhQ00xVDVwRUtjTHFzYm9mQW02V2RmcmYxUGwrMXlxcHFTS0JY?= =?utf-8?B?Um8zMnQ5cEE1bWhKUG1sUFFyNExCK1hoVjFFWThuWDVQYkNGT0pyck9yV2M4?= =?utf-8?B?OFlMd3hJZlR6bmUwRTFOcnFCN1VUMkxoNW9mZzkzbjFLTXU3cnRUK1ptZ3ZN?= =?utf-8?B?UndheWZycUJzWXhrY3dwcWJjT0RKSnlIUnJaMEZzd3FjNndoYjUvSEppM1po?= =?utf-8?B?K2sxbElyd091cUpjWXVKZS94dzA2WVBsaExhdTArYnU1cm8xZGVzYm9rN0hI?= =?utf-8?B?L2JGTFBvOGxOTThYNU5BbXlnUzlLblRBYWV6L293TnFoeGV1SVhkVzRxWURj?= =?utf-8?B?VUgrcjZTRDFRTHFQcER6enZIWGErejRaOG9Rcm4vMmxCMVBZUE1paEMveU1U?= =?utf-8?B?RkdKRVg1Y1V4UmxCVWlnQVdMZ1NvTFN1ckJOSUxvTktXTHplYnlKampZMDRx?= =?utf-8?B?algxR3FlZ3BDTTZwa0RZRDNDbHlXSTRaZFJYME5KbE9SRDJqT1o0VmxiVVlF?= =?utf-8?B?SEIxa1NnNlNYVnNrUHFEdGE1YldVL3N2SkZ0OE5PbERRMW1LVGx5Rk4vcGxT?= =?utf-8?B?eWFkZE1BeUYvNUI4MnQ3UmZWcmYyY2htQi9aSDFxV01MLy9xdkdLM3Ywam14?= =?utf-8?B?cnM1RUo4VUNtUk9xc3EvMDRGV0VYckZjdGZjT3RITitkNlR3OXZuQURwZEND?= =?utf-8?B?MWVBUGtYVm0yNXVza0Rib0FvQkVGSWxMaE00M2VtZ0pxZFpXc0R5TkFRQjZz?= =?utf-8?Q?LlN04/cbeLCrkV4E/f+i6gk+zb3XbIQAQ5?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 8c1838c2-3684-4b26-e7b3-08d8982c6b24 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Dec 2020 08:13:01.7882 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: zE+hj4vMWcAxFy2685cSQL+kM+nF1bFa4Ktu8BPut7PRF6aIxaZp4jPSjryYy6vi5+MCuYWsSXV/GaH48nKkxw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB0998 Archived-At: Subject: [core] Doodle for CoRE interim meetings X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2020 08:13:09 -0000 --AQsPVECVZwsxe2qhEb77wmyNj2sDamBVQ Content-Type: multipart/mixed; boundary="ytXVN4ef2yZM4WP4c2KuLtwFHJqQ587Q7" --ytXVN4ef2yZM4WP4c2KuLtwFHJqQ587Q7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, We are planning to have regular virtual interim meetings, recurring every other week, starting from the week 18-22 of January until the IETF 110 cut-off. As usual, we will alternate with the CBOR interim meetings. Please, cast your preferences at the Doodle poll below, by the 14th of December EOB. https://doodle.com/poll/tku4y89rtdmmrq4t The options in the Doodle refer to the week of the first interim meeting. The following meetings will occur every other week on the same weekday and time, until the end of February. Best, Marco and Jaime --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --ytXVN4ef2yZM4WP4c2KuLtwFHJqQ587Q7-- --AQsPVECVZwsxe2qhEb77wmyNj2sDamBVQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl/J74sACgkQ7iZktA5Y 2kMSJAgAhZwTzn6t8saV1F2I/ig5bKs1Hl9EMi0r/ha3ttsX3K05WP4pD7yJB3xC JfCBB3ZW9J0trLOI8Yu3CPpEephlUmmR0sDRnk9dJVq0mHf+GzStwaxFBMi2i+7f jP1Okpi9/dOkoNuF6tJ0J7FfOMLLFQTi7OEOjR+ce2PPzWtVnsTLvvLomUoshOQb H1xfWfuAULgcw6obqmJG4Uolgyviw5nrDMy9cTnV5tGBCXCe5v15Ucoa6og3+JqZ fe64B0Cmr8oGWjLiQPy71nIMT2NECL3Opt+LKw3MolOsLxiza9tlE67ehXcAW5Yq v4hvybIJEr9v8aLyOLrhpo62HH5yig== =N50l -----END PGP SIGNATURE----- --AQsPVECVZwsxe2qhEb77wmyNj2sDamBVQ-- From nobody Fri Dec 4 02:26:20 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62753A0644; Fri, 4 Dec 2020 02:26:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.092 X-Spam-Level: X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 DDRrCKVXLAwD; Fri, 4 Dec 2020 02:26:16 -0800 (PST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2059.outbound.protection.outlook.com [40.107.22.59]) (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 CB1B73A05F8; Fri, 4 Dec 2020 02:26:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=C+qOfSF/upKCjkbxg39VPgFuYuAowN06bgEw9YdUfLknlDodLz4SEAh56qrVhe+IjRHa2YBTdNslDVgBb411DKC2SN4IUgALsHehNLS1WJEXCcacSNABczNDoy8UMpNe8Rr2Sgq4Q+Cz/flcCXitb8Bi/96G4fVaMwftpd+8xymvLPy4FKtp7pT76yzVJQ5mh5Hbfsxvm9U0E+ZwgK3Jh+eVbkAXzD566Mnjy8hOhDGnTRJBKYdBuJsTz/mxPQv7mI9M/LYjbql3rtAiL1jJHPYYj/LaTzHwAewTkX6JBZUoE4LNlN0x08o1xS3qLAfovO/x6lBf4n5IqlUB2PbHvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RETc61wXAjt316TIoLTo8Gs4JSRrcq7x05+6/wh+ews=; b=XSrmnBWEUJUlL+YN3twvnvhaYxyrNDu/x2IkOK3qN6Je8uBWdcxZFDUcjtZN0pbeMP5L751TJdFlX5IWJrobIvyJYmvDwbpg4c9EewO/Z2bXLvMENdiUk9XDFUoNcKvxakoDvxIhyS3A4CqwLspXigTObnvRhA56ok0dlHVc4MP1YvOKY8H8vLQIuNlgIx1QjyEbSu3lolfDoq7PF6ceBx2kUPhxiLltkQwYLjN54Owwlw/Bdh3TBkwzBRX/no4jbycHl//JitTJkby1TfGHkPAKSF5nRM3BDdG48PcZSRFOMqGkQXb7sh6ebYvFq5cFEY3uBLSsQG6AAmAAlo3QrA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RETc61wXAjt316TIoLTo8Gs4JSRrcq7x05+6/wh+ews=; b=bP+9jQXQ6dHIxHkyzzhSyL5vCUKzuYTmYmsqTAxw1lepFYuasq93FpEGw/LuUDSL7doKJ5u8Si/tv/0hhDpVgNWKnrUm57fzr5aD4wEje3047XJPTfHhBIW7rvVsfzK1Hn4HPU9T3rhzWtKD/IdHVUx2pChipQpiD/9PUVfXrEc= Received: from HE1PR0701MB2185.eurprd07.prod.outlook.com (2603:10a6:3:2a::21) by HE1PR07MB4201.eurprd07.prod.outlook.com (2603:10a6:7:98::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.15; Fri, 4 Dec 2020 10:26:13 +0000 Received: from HE1PR0701MB2185.eurprd07.prod.outlook.com ([fe80::9923:403e:592f:d8eb]) by HE1PR0701MB2185.eurprd07.prod.outlook.com ([fe80::9923:403e:592f:d8eb%10]) with mapi id 15.20.3654.009; Fri, 4 Dec 2020 10:26:13 +0000 From: Mohit Sethi M To: Daniel Migault , Dan Garcia , "ace@ietf.org" CC: EMU WG , "core@ietf.org WG (core@ietf.org)" Thread-Topic: [Emu] [Ace] Proposed charter for ACE (EAP over CoAP?) Thread-Index: AQHWyifjYCmuD4WkfEaX3bQfrc+gxA== Date: Fri, 4 Dec 2020 10:26:12 +0000 Message-ID: <037f8fae-e663-0f68-01db-f8c36e0fe25f@ericsson.com> References: <20201117234700.GR39170@kduck.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:14bb:1a3:54b1::1a4f:ee01] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7fcba3ba-9f85-4982-deaa-08d8983f066a x-ms-traffictypediagnostic: HE1PR07MB4201: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xiH6eRudVw5oma/KtbbmGLmnprfWwWEQuURmNjVcpiagQBA+l07kh+xvkUoHH1kI60ho4J1+HnzLPu8a0zjjOCYMOaJpwT2O6QNYsbpahSeRYapIARGTsnPfK9+ggzDOyL/C1nd5Ob1+1ppdeBmpbZHMnW68dWwGEXjHNFwGvSYuzf7jRkb1IX+6+uLFi79GFNOILVI7+a584R6rgs0TeBHe9Yqwpb2OenANZDSBOAVRd5Dfi3llZhiiFG0t0MQQwFfqysci0eANRtolmeP+CmU0XGXFyO/XDkKmz3ccv5vu1q+3RXdzXgglSUgu1h1ooy6c/dGQZL4T9Q7UZl1knHzhG8sgG+7ymVeTPHZ/zps4YBc4Aj3aYH+LEhYepQJUUl8oA7p7fZQfteEF8HheLUiBAh3xpwZk8+hEfne5Mnm9pvCDDm/IxUDcfYWDkmoSIyz2fQS4JzmAysDaZZ7oLzd6mToIBWoyS2fpQvLMkjU= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB2185.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(346002)(39860400002)(376002)(366004)(136003)(110136005)(31686004)(8936002)(966005)(54906003)(71200400001)(66446008)(66476007)(5660300002)(66556008)(36756003)(76116006)(478600001)(19627405001)(316002)(30864003)(6512007)(66574015)(31696002)(66946007)(6486002)(83380400001)(166002)(53546011)(4326008)(2906002)(6506007)(64756008)(4001150100001)(86362001)(8676002)(2616005)(186003)(45980500001)(43740500002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?Windows-1252?Q?TqE9N0aZZj1D10xRPza2FEBDXzdyuqWR8i3cAwyAyNp+T07JSVCcOUTa?= =?Windows-1252?Q?Nv2cbs4UvxBlVhsEmajFMypm6crJrQV8aYguBhPDAlremvHdljlH7lJK?= =?Windows-1252?Q?jDEjeXsW8D4SpJJ//s2uX+LJyWj8sFlEc6gFhZpebzmob6QWAcSgikVp?= =?Windows-1252?Q?m+TkAWxhtpq9pdWYnrHfn1XXrc5Yv3XLNHVUQSQ62db4RWolW99pZedY?= =?Windows-1252?Q?837PzfWhuUzTmlNCIkQqOBuJ70haxGCYQi0VYlr4KiZmzAcuXjZ8MKcB?= =?Windows-1252?Q?wtBK5BnB7OXWbkjPmd3W6uQqU2pbEhRT+kUPRE8uiv82AIYQiidEy1zj?= =?Windows-1252?Q?NoKmyNKeqX+nvNrgbYaTmElb+BDS8+D1hDSK6JAbfxhNMqbGcbD9NYX6?= =?Windows-1252?Q?5e3RQjzawMXGYvf0qjGPzFmLa3GlM1dLyiBBIYAGCXImLWo84hOYbEDf?= =?Windows-1252?Q?M1h1e7GEM5Twkhdwt260n8k4MeVElJIFf0E6cggHqzl0wAKlvVaoynaC?= =?Windows-1252?Q?AnOJwim6WvW8L7byw403WMFJL9salYnLPzZcSsbnBG71PSe2UESXVlb2?= =?Windows-1252?Q?ZbKvaH72PjF2acI6x4bzqauR8nHZz1St8S5OAmgTo6aj8m7I5RAV7Phz?= =?Windows-1252?Q?zqCEsGOCNtSSFIGkZjTOPo1TItuXUvP4Y5XocfqVun02FDfgIGqLV/mx?= =?Windows-1252?Q?PvbY7MUwIv6ltqKJDjZY5En/WMnNN3roBU36scBER8fwUBK2xFtYPXD+?= =?Windows-1252?Q?UKIp++WDgQb9R8BvFAkuZjPOuWSNePyc+UhokTQAP30ClLw5U7LYRaAI?= =?Windows-1252?Q?jnfBFRd/+ad1EQp5P/lvaRmrGPuc+eZIBfADaXljakmoezqUnNZwxeyU?= =?Windows-1252?Q?bVLaaqWsVSyUs4iGDF5NspGCC6YMMsUpqoIo/6gza3nzuR6dssVFMW3e?= =?Windows-1252?Q?NTybb91wUKDSKU8IfhbP/8wzSIfM81YBJ/UfK+okqttpKG6LZPzhWkRb?= =?Windows-1252?Q?X5vEVxMjpnsnCmoaLsMmV90cvRPbXwpJ+FtUX6xjcDXcDoJRnDGhvEdc?= =?Windows-1252?Q?3nY5hMQdFjaXAzEWmYSh47zIPfzUxWCL+Pv2xg=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_037f8faee6630f6801dbf8c36e0fe25fericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB2185.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7fcba3ba-9f85-4982-deaa-08d8983f066a X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Dec 2020 10:26:13.0064 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 7PFpGZqROF5oBOLsrCCGP0BkWcbgKOkqsJxdI+eHtz83PkX/cFz/IlDAtLAQa+SbPszLZ3yr7ewgleANhf9BHDR7wDE5l/Ltn+AO7uU4TOg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4201 Archived-At: Subject: Re: [core] [Emu] [Ace] Proposed charter for ACE (EAP over CoAP?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2020 10:26:20 -0000 --_000_037f8faee6630f6801dbf8c36e0fe25fericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi ACE, I guess EMU is happy to see new deployments and uses of EAP. I think ACE is= better suited for taking on this work if there is interest. EMU primarily = deals with the base EAP protocol and various EAP authentication methods. We= can obviously help with reviewing the document later on. I would note that EAP-over-foo is generally defined by the lower-layer. So = for example, EAP over LAN (EAPOL) is specified by IEEE. In this case, the l= ower-layer is CoAP so we at the IETF are responsible for specifying it (if = there is a desire to do so). A draft for HTTP authentication with EAP was s= ubmitted a couple of decades ago: https://tools.ietf.org/html/draft-torvine= n-http-eap-01. That was unfortunately never finished. But maybe CoAP will b= e different and ACE can finish this work item if it chooses to adopt it. --Mohit On 12/3/20 3:20 PM, Daniel Migault wrote: CCing emu, core It seems ACE to me that ACE could be home for such a document. I am wonderi= ng if emu core or any other WG believe there is a better place for it. Regarding ACE I am wondering what is the WG opinion about adding this item = to the ACE charter. Yours, Daniel ________________________________ From: Ace on behalf of = Dan Garcia Sent: Thursday, December 3, 2020 6:10 AM To: ace@ietf.org Subject: [Ace] Proposed charter for ACE (EAP over CoAP?) Dear all: Regarding the new charter, since ACE is considering the definition of CoAP = transport for CMPv2 (https://tools.ietf.org/html/draft-msahni-ace-cmpv2-coa= p-transport-00), we were wondering whethere it could also consider specifyi= ng EAP (Extensible Authentication Protocol) over CoAP. In this sense, we proposed this some time ago and we have implementations a= bout this. https://datatracker.ietf.org/doc/html/draft-marin-ace-wg-coap-eap-06 https://www.mdpi.com/1424-8220/16/3/358 https://www.mdpi.com/1424-8220/17/11/2646 The usage of CoAP can provide a very light and link-layer independent (we e= ven tested in LoRa networks) EAP lower-layer (transport for EAP) suitable f= or IoT enviroment. We believe this would be really useful since EAP provide= s flexibility for the authentication and it is a well-known protocol. Therefore, we would like to propose the following modification to the chart= er: "The Working Group will examine how to use Constrained Application Protocol= (CoAP) as a transport medium for certificate enrollment protocols, such as= EST and CMPv2, as well as a transport for authentication protocols such as= EAP, and standardize them as needed." This modification does not necessarily mean the adoption of our draft. Afte= r all, we completely understand that this would happen only if there is an = interest in the WG. Nevertheless, we would like to avoid that the charter i= s a barrier later if there is interest in the WG to work in this transport = of EAP over CoAP: Any opinion about this? Best Regards. El 18/11/2020 a las 8:08, Daniel Migault escribi=F3: Hi, Please find the proposed charter we agreed on during the interim meeting. I= f you would like to propose any change, please use the following URL by Nov= ember 25: https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoD= iptY/edit?usp=3Dsharing Yours, Daniel The Authentication and Authorization for Constrained Environments (ace) WG = has defined a standardized solution framework for authentication and author= ization to enable authorized access to resources identified by a URI and ho= sted on a resource server in constrained environments. The access to the resource is mediated by an authorization server, which is= not considered to be constrained. Profiles of this framework for application to security protocols commonly u= sed in constrained environments, including CoAP+DTLS and CoAP+OSCORE, have = also been standardized. The Working Group is charged with maintenance of t= he framework and existing profiles thereof, and may undertake work to speci= fy profiles of the framework for additional secure communications protocols= and for additional support services providing authorized access to crypto = keys (that are not necessarily limited to constrained endpoints, though the= focus remains on deployment in ecosystems with a substantial portion of co= nstrained devices). In addition to the ongoing maintenance work, the Working Group will extend = the framework as needed for applicability to group communications, with ini= tial focus on (D)TLS and (Group) OSCORE as the underlying group communicati= on security protocols. The Working Group will standardize procedures for re= questing and distributing group keying material using the ACE framework as = well as appropriated management interfaces. The Working Group will standardize a format for expressing authorization in= formation for a given authenticated principal as received from an authoriza= tion manager. The Working Group will examine how to use Constrained Application Protocol = (CoAP) as a transport medium for certificate enrollment protocols, such as = EST and CMPv2, and standardize as needed. On Tue, Nov 17, 2020 at 6:47 PM Benjamin Kaduk > wrote: Thanks for updating the draft charter at [1], Daniel! I note that Michael raised the question of whether some other group might also be interested in working on CMP-over-coap, so the IESG will be sure to discuss that if CMP is still in the draft ACE charter when it goes to the IESG for review. -Ben On Tue, Nov 17, 2020 at 06:16:48PM -0500, Daniel Migault wrote: > Thank you all for the feed backs. For the purpose of driving the charter > discussion at the IETf 109, I have added the comments into the proposed > text [1]. > > My current understanding is that it seems beneficial to add CMPv2 over Co= AP > in the charter. I am happy to be contradicted. > * I have not seen a clear cut to do one or the other. > * EST and CMPv2 are two protocols that can be used for enrollment or cert > management while addressing different cases / needs / situations -- maybe > we can clarify that point. I can see leveraging the existing CMP > infrastructure, but it seems that is not the only one. > * I am not convinced that not having CMP over CoAP will not prevent its > deployment and as such I prefer to have it standardized - this might be a > personal thought. > * Adding any piece of work require cycles, but it seems to me that CPM wi= ll > not have a major impact on the WG progress. The work will probably includ= e > other WG such a LAMPS. > > Yours, > Daniel > > [1] > https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXh= oDiptY/edit?usp=3Dsharing > > On Tue, Nov 17, 2020 at 6:02 PM Daniel Migault > wrote: > > > Hi Goran, > > > > I added the text to the charter we will discuss later. > > > > Yours, > > Daniel > > > > On Fri, Nov 13, 2020 at 10:26 AM G=F6ran Selander < > > goran.selander@ericsson.com> wrote: > > > >> Hi Daniel, > >> > >> > >> > >> Here=92s another input to the charter. > >> > >> > >> > >> The current group key management solutions addresses the problem of > >> authorized access to group keys and public keys of group members. > >> > >> > >> > >> A related problem is authorized access of public keys of other devices > >> not necessarily part of a security group, in the sense of sharing a > >> symmetric key used to protect group messages. > >> > >> > >> > >> Authorized access to raw public keys serves an important function in > >> constrained settings where public key certificates may not be feasible= due > >> to the incurred overhead, e.g. for when authenticating using EDHOC > >> (draft-ietf-lake-edhoc). > >> > >> This functionality is thus a subset of what is already supported, but > >> since the current solution is geared towards groups a different soluti= on > >> may be needed (although it is probably possible to reuse parts from th= e > >> existing schemes for provisioning and requesting public keys). > >> > >> > >> > >> With this in mind, I propose the following change (highlighted in > >> boldface below): > >> > >> > >> > >> OLD > >> > >> The Working Group is charged with maintenance of the framework and > >> existing profiles thereof, and may undertake work to specify profiles = of > >> the framework for additional secure communications protocols (that are= not > >> necessarily limited to constrained endpoints, though the focus remains= on > >> deployment ecosystems with a substantial portion of constrained device= s). > >> > >> > >> > >> NEW > >> > >> The Working Group is charged with maintenance of the framework and > >> existing profiles thereof, and may undertake work to specify profiles = of > >> the framework for additional secure communications protocols *and **fo= r > >> additional **support services **providing* *authorized access to crypt= o* *keys > >> *(that are not necessarily limited to constrained endpoints, though th= e > >> focus remains on deployment ecosystems with a substantial portion of > >> constrained devices). > >> > >> > >> > >> G=F6ran > >> > >> > >> > >> > >> > >> > >> > >> On 2020-10-15, 19:50, "Ace" > wrote: > >> > >> Hi, > >> > >> I would like to start the charter discussion. Here is a draft of a > >> proposed charter [1]. > >> > >> > >> > >> It seems to be that additional discussion is needed with regard to the > >> last paragraph related certificate management. In particular the discu= ssion > >> might revive a discussion that happened in 2017 [2] - when I was not > >> co-chair of ACE -and considered other expired work such as [3]. Please= make > >> this discussion constructive on this thread. > >> > >> > >> > >> The fundamental question is whether we need certificate management at > >> this stage. If the answer is yes, and we have multiple proposals, it w= ould > >> be good to clarify the position of the different proposals and evaluat= e > >> whether a selection is needed or not before validating the charter. > >> > >> > >> > >> Please provide your inputs on the mailing list before October 30. Of > >> course for minor edits, you may suggest them directly on the google do= c. > >> > >> > >> > >> Yours, > >> > >> Daniel > >> > >> > >> > >> [1] > >> https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2Bn= BXhoDiptY/edit?usp=3Dsharing > >> < > >> https://protect2.fireeye.com/v1/url?k=3D4f3d9c3b-118c475b-4f3ddca0-86e= 2237f51fb-627e48b069462d70&q=3D1&e=3D6924b2a6-e7e5-4ec1-a1af-c94637953dc5&u= =3Dhttps%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR= 8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing> > >> > >> > >> [2] > >> https://datatracker.ietf.org/doc/minutes-interim-2017-ace-03-201710191= 300/ > >> > >> [3] https://datatracker.ietf.org/doc/draft-selander-ace-eals/ > >> > >> > >> > >> -- > >> > >> Daniel Migault > >> > >> > >> > >> Ericsson > >> > > > > > > -- > > Daniel Migault > > Ericsson > > > > > -- > Daniel Migault > Ericsson > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace -- Daniel Migault Ericsson _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu --_000_037f8faee6630f6801dbf8c36e0fe25fericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7A7D2D832A5CF64D83B63134D3C9BC3E@eurprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

Hi ACE,

I guess EMU is happy to see new deployments and uses of EAP. I think ACE is= better suited for taking on this work if there is interest. EMU primarily = deals with the base EAP protocol and various EAP authentication methods. We= can obviously help with reviewing the document later on.

I would note that EAP-over-foo is generally defined by the lower-layer. So = for example, EAP over LAN (EAPOL) is specified by IEEE. In this case, the l= ower-layer is CoAP so we at the IETF are responsible for specifying it (if = there is a desire to do so). A draft for HTTP authentication with EAP was submitted a couple of decades ago: https://tools.ietf.org/html/draft-torvinen-http-eap-01. That was unfort= unately never finished. But maybe CoAP will be different and ACE can finish= this work item if it chooses to adopt it. 


--Mohit

On 12/3/20 3:20 PM, Daniel Migault wrote:
CCing emu, core

It seems ACE to me that ACE could be home for such a document. I am wonderi= ng if emu core or any other WG believe there is a better place for it. = ;

Regarding ACE I am wondering what is the WG opinion about adding this item = to the ACE charter. 

Yours, 
Daniel
From: Ace <= ;ace-bounces@ietf.org> on behalf of Dan Garcia <dan= .garcia@um.es>
Sent: Thursday, December 3, 2020 6:10 AM
To: ace@ietf.org <ace@iet= f.org>
Subject: [Ace] Proposed charter for ACE (EAP over CoAP?)
 

Dear all:

Regarding the new charter, since ACE is considering the definition of CoAP = transport for CMPv2 (https://tools.ietf.org/html/draft-msahni-ace-cmpv2-coap-transpor= t-00), we were wondering whethere it could also consider specifying EAP (Extensib= le Authentication Protocol) over CoAP.

In this sense, we proposed this some time ago and we have implementations a= bout this.

https://da= tatracker.ietf.org/doc/html/draft-marin-ace-wg-coap-eap-06
https://www.mdpi.com/1424-8220/16/3/358=
https://www.mdpi.com/1424-8220/17/11/= 2646

The usage of CoAP can provide a very light and link-layer independent (we e= ven tested in LoRa networks) EAP lower-layer (transport for EAP) suitable f= or IoT enviroment. We believe this would be really useful since EAP provide= s flexibility for the authentication and it is a well-known protocol.

Therefore, we would like to propose the following modification to the chart= er:

"The Working Group will examine how to use Constrained Application Pro= tocol (CoAP) as a transport medium for certificate enrollment protocols, su= ch as EST and CMPv2, as well as a transport for authentication protocols such as EAP, and= standardize them as needed."

This modification does not necessarily mean the adoption of our draft. Afte= r all, we completely understand that this would happen only if there is an = interest in the WG. Nevertheless, we would like to avoid that the charter i= s a barrier later if there is interest in the WG to work in this transport of EAP over CoAP:

Any opinion about this?

Best Regards.

El 18/11/2020 a las 8:08, Daniel Migault e= scribi=F3:
Hi, 

Please find the proposed charter we agreed on during the interim meeti= ng. If you would like to propose any change, please use the following URL b= y November 25:


Yours, 
Daniel

The Authentication = and Authorization for Constrained Environments (ace) WG has defined a standardized solution framework for authentication = and authorization to enable authorized access to resources identified by a = URI and hosted on a resource server in constrained environments. 

The access to the r= esource is mediated by an authorization server, which is not considered to be constrained.


Profiles of this fr= amework for application to security protocols commonly used in constrained environments, including CoAP+DTLS and CoAP+OS= CORE, have also been standardized.  The Working Group is charged with = maintenance of the framework and existing profiles thereof, and may underta= ke work to specify profiles of the framework for additional secure communications protocols and for additional support services providing authorized access to crypto keys (that are not necessarily limited to constrained endpoints, though the focus remains on deployment i= n ecosystems with a substantial portion of constrained devices).


In addition to the = ongoing maintenance work, the Working Group will extend the framework as needed for applicability to group communicati= ons, with initial focus on (D)TLS and (Group) OSCORE as the underlying grou= p communication security protocols. The Working Group will standardize proc= edures for requesting and distributing group keying material using the ACE framework as well as appropriated mana= gement interfaces. 


The Working Group w= ill standardize a format for expressing authorization information for a given authenticated principal as received from an author= ization manager. 


The Working Group w= ill examine how to use Constrained Application Protocol (CoAP) as a transport medium for certificate enrollment protocols= , such as EST and CMPv2, and standardize as needed.



On Tue, Nov 17, 2020 at 6:47 PM Ben= jamin Kaduk <k= aduk@mit.edu> wrote:
Thanks for updating the draft charter at [1], Daniel!

I note that Michael raised the question of whether some other group might also be interested in working on CMP-over-coap, so the IESG will be sure to=
discuss that if CMP is still in the draft ACE charter when it goes to the IESG for review.

-Ben

On Tue, Nov 17, 2020 at 06:16:48PM -0500, Daniel Migault wrote:
> Thank you all for the feed backs. For the purpose of driving the chart= er
> discussion at the IETf 109, I have added the comments into the propose= d
> text [1].
>
> My current understanding is that it seems beneficial to add CMPv2 over= CoAP
> in the charter. I am happy to be contradicted.
> * I have not seen a clear cut to do one or the other.
> * EST and CMPv2 are two protocols that can be used for enrollment or c= ert
> management while addressing different cases / needs / situations -- ma= ybe
> we can clarify that point. I can see leveraging the existing CMP
> infrastructure, but it seems that is not the only one.
> * I am not convinced that not having CMP over CoAP will not prevent it= s
> deployment and as such I prefer to have it standardized - this might b= e a
> personal thought.
> * Adding any piece of work require cycles, but it seems to me that CPM= will
> not have a major impact on the WG progress. The work will probably inc= lude
> other WG such a LAMPS.
>
> Yours,
> Daniel
>
> [1]
> https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoD= iptY/edit?usp=3Dsharing
>
> On Tue, Nov 17, 2020 at 6:02 PM Daniel Migault <mglt.ietf@gm= ail.com> wrote:
>
> > Hi Goran,
> >
> > I added the text to the charter we will discuss later.
> >
> > Yours,
> > Daniel
> >
> > On Fri, Nov 13, 2020 at 10:26 AM G=F6ran Selander <
> > goran.selander@ericsson.com> wrote:
> >
> >> Hi Daniel,
> >>
> >>
> >>
> >> Here=92s another input to the charter.
> >>
> >>
> >>
> >> The current group key management solutions addresses the prob= lem of
> >> authorized access to group keys and public keys of group memb= ers.
> >>
> >>
> >>
> >> A related problem is authorized access of public keys of othe= r devices
> >> not necessarily part of a security group, in the sense of sha= ring a
> >> symmetric key used to protect group messages.
> >>
> >>
> >>
> >> Authorized access to raw public keys serves an important func= tion in
> >> constrained settings where public key certificates may not be= feasible due
> >> to the incurred overhead, e.g. for when authenticating using = EDHOC
> >> (draft-ietf-lake-edhoc).
> >>
> >> This functionality is thus a subset of what is already suppor= ted, but
> >> since the current solution is geared towards groups a differe= nt solution
> >> may be needed (although it is probably possible to reuse part= s from the
> >> existing schemes for provisioning and requesting public keys)= .
> >>
> >>
> >>
> >> With this in mind, I propose the following change (highlighte= d in
> >> boldface below):
> >>
> >>
> >>
> >> OLD
> >>
> >> The Working Group is charged with maintenance of the framewor= k and
> >> existing profiles thereof, and may undertake work to specify = profiles of
> >> the framework for additional secure communications protocols = (that are not
> >> necessarily limited to constrained endpoints, though the focu= s remains on
> >> deployment ecosystems with a substantial portion of constrain= ed devices).
> >>
> >>
> >>
> >> NEW
> >>
> >> The Working Group is charged with maintenance of the framewor= k and
> >> existing profiles thereof, and may undertake work to specify = profiles of
> >> the framework for additional secure communications protocols = *and **for
> >> additional **support services **providing* *authorized access= to crypto* *keys
> >> *(that are not necessarily limited to constrained endpoints, = though the
> >> focus remains on deployment ecosystems with a substantial por= tion of
> >> constrained devices).
> >>
> >>
> >>
> >> G=F6ran
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On 2020-10-15, 19:50, "Ace" <ace-bounces= @ietf.org> wrote:
> >>
> >> Hi,
> >>
> >> I would like to start the charter discussion. Here is a draft= of a
> >> proposed charter [1].
> >>
> >>
> >>
> >> It seems to be that additional discussion is needed with rega= rd to the
> >> last paragraph related certificate management. In particular = the discussion
> >> might revive a discussion that happened in 2017 [2] - when I = was not
> >> co-chair of ACE -and considered other expired work such as [3= ]. Please make
> >> this discussion constructive on this thread.
> >>
> >>
> >>
> >> The fundamental question is whether we need certificate manag= ement at
> >> this stage. If the answer is yes, and we have multiple propos= als, it would
> >> be good to clarify the position of the different proposals an= d evaluate
> >> whether a selection is needed or not before validating the ch= arter.
> >>
> >>
> >>
> >> Please provide your inputs on the mailing list before October= 30. Of
> >> course for minor edits, you may suggest them directly on the = google doc.
> >>
> >>
> >>
> >> Yours,
> >>
> >> Daniel
> >>
> >>
> >>
> >> [1]
> >> https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoD= iptY/edit?usp=3Dsharing
> >> <
> >> https://protect2.fireeye.com/v1/url?k=3D4f3d9c3b-118c475b-4f3ddca0-86e2237f= 51fb-627e48b069462d70&q=3D1&e=3D6924b2a6-e7e5-4ec1-a1af-c94637953dc= 5&u=3Dhttps%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjS= j2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing>
> >>
> >>
> >> [2]
> >> https://datatracker.ietf.org/doc/minutes-interim-2017-ace-03-201710191300/<= /a>
> >>
> >> [3] https://datatracker.ietf.org/doc/draft-selander-ace-eals/
> >>
> >>
> >>
> >> --
> >>
> >> Daniel Migault
> >>
> >>
> >>
> >> Ericsson
> >>
> >
> >
> > --
> > Daniel Migault
> > Ericsson
> >
>
>
> --
> Daniel Migault
> Ericsson

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

_______________________________________________
Ace mailing list
= Ace@ietf.org
https://www.ietf.org/mailman/listi= nfo/ace


--
Daniel Migault
Ericsson

____________________________________________=
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo=
/ace


____________________________________=
___________
Emu mailing list
Emu@ietf=
.org
https://www.ietf.org/mailman/listinfo/emu
--_000_037f8faee6630f6801dbf8c36e0fe25fericssoncom_-- From nobody Mon Dec 7 06:07:54 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E223C3A13E9; Mon, 7 Dec 2020 06:07:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 sOgjNwR0yv0b; Mon, 7 Dec 2020 06:07:45 -0800 (PST) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2056.outbound.protection.outlook.com [40.107.20.56]) (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 E7DE73A0D78; Mon, 7 Dec 2020 06:07:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=N2ZmbjPLPPpJKIH4CSgOSXR44cWI72xPNwUeFu7rR5vdZiKGGgFBeoUS6VL4JZqvZYzrK+DuPy6oNZMD3fDzH/iiSlt0aqB9wrQh4tXxPper3GNMfSdG7sovZOzmcOET5cWR5VZQYf5gM6Tl6z9g864eZScdSoxaqstTEL6MMBmUNtQze7dJmEqRYgMalDPsbMywErLi2WdcTK2joiOPmTsyQ4B0kebx2tcYU18sYMUKc63FLIHUkTxHjAxdxa873tuPAA8rw1roBiWLMrcVi8iToOIperha294ypTg3io8pg/486Bs3t5QM74itln6T+sYLDOTCYGPpE4Vm+xwRyQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X7UM25wtKf5P7+jbujTijJ1z5/fw2uCXLkQBgD9DIDY=; b=ZNmMJ3tlb/bdebiAe1u4oDRzBvzLQgtvHZnfZRED9/qX/vp3AYAocYbeE76YKS2V02KsLfFLq6xP0ChKydd7lgHO/Ch9mTDXfp5OtPg6aa1gs4T31Z4Ibh/u+vJpMr2ii+6Qb09oD2w90ncTGiwJUg0ue03JonebVGDXNYjK0ZFbplkrW8IbZVPRVqjrVHDpX3drXV90EFSUw2EwAZB3cPYVqcBv0cVj1xKBUNqnDNrIr95PS5l9EDt3Qi9OBqkacmwx4A+oBnhY2tzmMRurD9yINH167zS1Xnil9itrKvc2c28pFYaFNScw3EONmy+QcSU5PgosddCA+RZKfKjAcg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X7UM25wtKf5P7+jbujTijJ1z5/fw2uCXLkQBgD9DIDY=; b=NFE3aPHR5KZlRO5wi+dr5+wk82iV3tn3zOMHQaiumA4XXU6Pv2xSzWOohfqXwLdQA/fLa/fkZRgUMqt7sHrE4ocjiGdbIkcfmGcM5LEAl9tbZOIMvyEOBZgU7DL62dXrBscu7lVxD2Lz7pPsr4Z26qKI60TMBHd23Ap+Neju4d8= Received: from HE1PR0702MB3674.eurprd07.prod.outlook.com (2603:10a6:7:82::14) by HE1PR0702MB3673.eurprd07.prod.outlook.com (2603:10a6:7:81::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.11; Mon, 7 Dec 2020 14:07:40 +0000 Received: from HE1PR0702MB3674.eurprd07.prod.outlook.com ([fe80::fd09:b8f4:2698:e86]) by HE1PR0702MB3674.eurprd07.prod.outlook.com ([fe80::fd09:b8f4:2698:e86%6]) with mapi id 15.20.3654.006; Mon, 7 Dec 2020 14:07:40 +0000 From: =?Windows-1252?Q?G=F6ran_Selander?= To: Laurent Toutain , Daniel Migault CC: "core@ietf.org WG (core@ietf.org)" , EMU WG , "ace@ietf.org" Thread-Topic: [core] [Ace] Proposed charter for ACE (EAP over CoAP?) Thread-Index: AQHWyWUY8FZyqW9rGEq1RKImqUzE1qnlW0AAgABfKQCABfZHuQ== Date: Mon, 7 Dec 2020 14:07:40 +0000 Message-ID: References: <20201117234700.GR39170@kduck.mit.edu> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: telecom-bretagne.eu; dkim=none (message not signed) header.d=none;telecom-bretagne.eu; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [83.251.145.232] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 29d1003c-d61c-45fb-bff8-08d89ab97582 x-ms-traffictypediagnostic: HE1PR0702MB3673: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Mw3y7qO5+1dYO7pfBxV4gV/6HuMjdZozvv/BZ9AupTib0r7gUwHHxnZCgmmBV3BA3SNLj+JbY29Yize7EKKDUdfxhzXg4GtztILdF0MhEGFYRkfuSeEYSIgHsjD4JbTjZFhLv1MhmqRcPfqgU6mawV+aX3ablfGipOuHu1hhzYyyk7MQcOnufULo/R17m9S7CebUJM9lB5xZK0PcXPKnwfWkwedRAfaVRL8uR7hxAUM8mGHV9/g/8hWSfJPe2QA2U0FxotA0nwW0XDfEVCHPix2Iq9zExtNkVktEKPsmIDx+TkhWmZBoH9VbyvQDefdTefd+8tdrJEnnpsZmRENZ3u4DtA2tcduTmgbCWv/A7ATv2W9THPyQ6teKQUndmbmweRf+3EnX/VH7jYsH5nykfgZEMT+g9+3NBMuBOzbfhzQQIjFo/XakjG5BYrGBCKwZ8iWwou83w5xvAfyX9/3yzg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3674.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(39860400002)(346002)(376002)(136003)(110136005)(66574015)(478600001)(52536014)(4001150100001)(9686003)(33656002)(8936002)(66556008)(186003)(55016002)(66946007)(54906003)(64756008)(8676002)(316002)(66476007)(4326008)(2906002)(86362001)(166002)(7696005)(71200400001)(5660300002)(76116006)(66446008)(30864003)(966005)(53546011)(6506007)(26005)(83380400001)(579004)(15940465004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?Windows-1252?Q?S6pKRXEwdHDJouJJSoh26nfvKSR0tiq7Hy4rEi2lTHTexD8nPSpGAzZL?= =?Windows-1252?Q?WwAN/54maXj8ccIC1dZMqFYyVLUf6fiy3xgfxoBPy8V6sr+JZih7iUyo?= =?Windows-1252?Q?dYtdxyAv1nnUTf1f0xE85Cj10BDXEq0Olyi+Z+Phu2O4e3Zq5CC6+UyD?= =?Windows-1252?Q?0oOLjX5KGUEJWecsZePL4+Wid5XfiLqoVuqkd2oy8zTrujiIyUyFDBE/?= =?Windows-1252?Q?etm6c/Xo/bRxJD+ar/tznrUkZkGZ/zsjQ6/qKxm7a//zCfhmk2RrHbYI?= =?Windows-1252?Q?l7X6D3Trm/k0twIN+uHpN7YD/T/VekinIpGiL0vBn/V5hlqgyZYTqm1q?= =?Windows-1252?Q?3lyWvp8rCTjvu0ck5LFJZ2t+zbOvoRi243pgy1m8nPQrNETfPi/A6Be+?= =?Windows-1252?Q?EYYxRNgBBEDxlN/6jj+hgr/VVUgdiDVj/TEGOM0sV40iNKNkR49WIeGt?= =?Windows-1252?Q?sL1F78V1Io815BQrq+UhuopRcymggCNA7873PCQMv4lKQLeWbjW1OB+3?= =?Windows-1252?Q?R5+vbAzUTg0qm5rRX/c4VXKYzQRfHYRTy2K0CUXDRLFsgevI06Erm8x4?= =?Windows-1252?Q?NZYH2aliotlmAEuD0jBgC67cj1x7T7ukO3yjL/ILgBYJ2Vc45b1/mrd8?= =?Windows-1252?Q?I5rWtpeDGuctvJkuKD2R0LsDUnh1ZOpj0+KNrWlbg4dDF77xO7EB+hie?= =?Windows-1252?Q?cvK8g4WbglXw7uiKWPElp66xu6QEyGfSwIG2BALohF8cf7DfXdy7Ick7?= =?Windows-1252?Q?rNSJsQUpKzu1jBYW2NCLT+soxgDbpWAsN0TlWbTOF/8+mhLuGLvYuwor?= =?Windows-1252?Q?QvmeiCgu9NDJm9QDkwzWiuKyRECIajg0LxJCOH8i8njcXba/gL+8lISZ?= =?Windows-1252?Q?71137gtfViWPyys0MpZsfmDLpx55JrtFEfXxxLE4xNeXUIzjj0fadThl?= =?Windows-1252?Q?qoXfG4o8mjOwEXm5G5M+WwK4TvAEPkPxCrvWIG58PpuJMSZuHVEd2K28?= =?Windows-1252?Q?C3NWIS8dnKWPyQOE0L2jN5fhwjTxEFWJFuf/fjv/5duaMuUb+8TAUBsY?= =?Windows-1252?Q?iyKK7M/Vra22twE8SmgoLBiGB6ZNyGu2PQnM/Q=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_HE1PR0702MB367429A9C8921A5252133523F4CE0HE1PR0702MB3674_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3674.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 29d1003c-d61c-45fb-bff8-08d89ab97582 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Dec 2020 14:07:40.3096 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: YGKsIxty2BmXjd1CXGLRddMguJi4NsChc5Nyqc3nqpqaXKxNWaTuZeuiB9Krgt6QnUSihaKgeUE8MXQVYsH2IFBHOuwUfT6AKNl8VtaGQR8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3673 Archived-At: Subject: Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 14:07:50 -0000 --_000_HE1PR0702MB367429A9C8921A5252133523F4CE0HE1PR0702MB3674_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1. (The recently updated ACE charter should cover this work.) G=F6ran On 2020-12-03, 20:03, "core" wrote: Hi, I think it is important to have EAP on top of CoAP, as Dan said it fit well= with the last charter item. Laurent On Thu, Dec 3, 2020 at 2:20 PM Daniel Migault > = wrote: CCing emu, core It seems ACE to me that ACE could be home for such a document. I am wonderi= ng if emu core or any other WG believe there is a better place for it. Regarding ACE I am wondering what is the WG opinion about adding this item = to the ACE charter. Yours, Daniel ________________________________________ From: Ace > on behalf of = Dan Garcia > Sent: Thursday, December 3, 2020 6:10 AM To: ace@ietf.org > Subject: [Ace] Proposed charter for ACE (EAP over CoAP?) Dear all: Regarding the new charter, since ACE is considering the definition of CoAP = transport for CMPv2 (https://tools.ietf.org/html/draft-msahni-ace-cmpv2-coa= p-transport-00), we were wondering whethere it could also consider specifyi= ng EAP (Extensible Authentication Protocol) over CoAP. In this sense, we proposed this some time ago and we have implementations a= bout this. https://datatracker.ietf.org/doc/html/draft-marin-ace-wg-coap-eap-06 https://www.mdpi.com/1424-8220/16/3/358 https://www.mdpi.com/1424-8220/17/11/2646 The usage of CoAP can provide a very light and link-layer independent (we e= ven tested in LoRa networks) EAP lower-layer (transport for EAP) suitable f= or IoT enviroment. We believe this would be really useful since EAP provide= s flexibility for the authentication and it is a well-known protocol. Therefore, we would like to propose the following modification to the chart= er: "The Working Group will examine how to use Constrained Application Protocol= (CoAP) as a transport medium for certificate enrollment protocols, such as= EST and CMPv2, as well as a transport for authentication protocols such as= EAP, and standardize them as needed." This modification does not necessarily mean the adoption of our draft. Afte= r all, we completely understand that this would happen only if there is an = interest in the WG. Nevertheless, we would like to avoid that the charter i= s a barrier later if there is interest in the WG to work in this transport = of EAP over CoAP: Any opinion about this? Best Regards. El 18/11/2020 a las 8:08, Daniel Migault escribi=F3: Hi, Please find the proposed charter we agreed on during the interim meeting. I= f you would like to propose any change, please use the following URL by Nov= ember 25: https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoD= iptY/edit?usp=3Dsharing Yours, Daniel The Authentication and Authorization for Constrained Environments (ace) WG = has defined a standardized solution framework for authentication and author= ization to enable authorized access to resources identified by a URI and ho= sted on a resource server in constrained environments. The access to the resource is mediated by an authorization server, which is= not considered to be constrained. Profiles of this framework for application to security protocols commonly u= sed in constrained environments, including CoAP+DTLS and CoAP+OSCORE, have = also been standardized. The Working Group is charged with maintenance of t= he framework and existing profiles thereof, and may undertake work to speci= fy profiles of the framework for additional secure communications protocols= and for additional support services providing authorized access to crypto = keys (that are not necessarily limited to constrained endpoints, though the= focus remains on deployment in ecosystems with a substantial portion of co= nstrained devices). In addition to the ongoing maintenance work, the Working Group will extend = the framework as needed for applicability to group communications, with ini= tial focus on (D)TLS and (Group) OSCORE as the underlying group communicati= on security protocols. The Working Group will standardize procedures for re= questing and distributing group keying material using the ACE framework as = well as appropriated management interfaces. The Working Group will standardize a format for expressing authorization in= formation for a given authenticated principal as received from an authoriza= tion manager. The Working Group will examine how to use Constrained Application Protocol = (CoAP) as a transport medium for certificate enrollment protocols, such as = EST and CMPv2, and standardize as needed. On Tue, Nov 17, 2020 at 6:47 PM Benjamin Kaduk > wrote: Thanks for updating the draft charter at [1], Daniel! I note that Michael raised the question of whether some other group might also be interested in working on CMP-over-coap, so the IESG will be sure to discuss that if CMP is still in the draft ACE charter when it goes to the IESG for review. -Ben On Tue, Nov 17, 2020 at 06:16:48PM -0500, Daniel Migault wrote: > Thank you all for the feed backs. For the purpose of driving the charter > discussion at the IETf 109, I have added the comments into the proposed > text [1]. > > My current understanding is that it seems beneficial to add CMPv2 over Co= AP > in the charter. I am happy to be contradicted. > * I have not seen a clear cut to do one or the other. > * EST and CMPv2 are two protocols that can be used for enrollment or cert > management while addressing different cases / needs / situations -- maybe > we can clarify that point. I can see leveraging the existing CMP > infrastructure, but it seems that is not the only one. > * I am not convinced that not having CMP over CoAP will not prevent its > deployment and as such I prefer to have it standardized - this might be a > personal thought. > * Adding any piece of work require cycles, but it seems to me that CPM wi= ll > not have a major impact on the WG progress. The work will probably includ= e > other WG such a LAMPS. > > Yours, > Daniel > > [1] > https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXh= oDiptY/edit?usp=3Dsharing > > On Tue, Nov 17, 2020 at 6:02 PM Daniel Migault > wrote: > > > Hi Goran, > > > > I added the text to the charter we will discuss later. > > > > Yours, > > Daniel > > > > On Fri, Nov 13, 2020 at 10:26 AM G=F6ran Selander < > > goran.selander@ericsson.com> wrote: > > > >> Hi Daniel, > >> > >> > >> > >> Here=92s another input to the charter. > >> > >> > >> > >> The current group key management solutions addresses the problem of > >> authorized access to group keys and public keys of group members. > >> > >> > >> > >> A related problem is authorized access of public keys of other devices > >> not necessarily part of a security group, in the sense of sharing a > >> symmetric key used to protect group messages. > >> > >> > >> > >> Authorized access to raw public keys serves an important function in > >> constrained settings where public key certificates may not be feasible= due > >> to the incurred overhead, e.g. for when authenticating using EDHOC > >> (draft-ietf-lake-edhoc). > >> > >> This functionality is thus a subset of what is already supported, but > >> since the current solution is geared towards groups a different soluti= on > >> may be needed (although it is probably possible to reuse parts from th= e > >> existing schemes for provisioning and requesting public keys). > >> > >> > >> > >> With this in mind, I propose the following change (highlighted in > >> boldface below): > >> > >> > >> > >> OLD > >> > >> The Working Group is charged with maintenance of the framework and > >> existing profiles thereof, and may undertake work to specify profiles = of > >> the framework for additional secure communications protocols (that are= not > >> necessarily limited to constrained endpoints, though the focus remains= on > >> deployment ecosystems with a substantial portion of constrained device= s). > >> > >> > >> > >> NEW > >> > >> The Working Group is charged with maintenance of the framework and > >> existing profiles thereof, and may undertake work to specify profiles = of > >> the framework for additional secure communications protocols *and **fo= r > >> additional **support services **providing* *authorized access to crypt= o* *keys > >> *(that are not necessarily limited to constrained endpoints, though th= e > >> focus remains on deployment ecosystems with a substantial portion of > >> constrained devices). > >> > >> > >> > >> G=F6ran > >> > >> > >> > >> > >> > >> > >> > >> On 2020-10-15, 19:50, "Ace" > wrote: > >> > >> Hi, > >> > >> I would like to start the charter discussion. Here is a draft of a > >> proposed charter [1]. > >> > >> > >> > >> It seems to be that additional discussion is needed with regard to the > >> last paragraph related certificate management. In particular the discu= ssion > >> might revive a discussion that happened in 2017 [2] - when I was not > >> co-chair of ACE -and considered other expired work such as [3]. Please= make > >> this discussion constructive on this thread. > >> > >> > >> > >> The fundamental question is whether we need certificate management at > >> this stage. If the answer is yes, and we have multiple proposals, it w= ould > >> be good to clarify the position of the different proposals and evaluat= e > >> whether a selection is needed or not before validating the charter. > >> > >> > >> > >> Please provide your inputs on the mailing list before October 30. Of > >> course for minor edits, you may suggest them directly on the google do= c. > >> > >> > >> > >> Yours, > >> > >> Daniel > >> > >> > >> > >> [1] > >> https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2Bn= BXhoDiptY/edit?usp=3Dsharing > >> < > >> https://protect2.fireeye.com/v1/url?k=3D4f3d9c3b-118c475b-4f3ddca0-86e= 2237f51fb-627e48b069462d70&q=3D1&e=3D6924b2a6-e7e5-4ec1-a1af-c94637953dc5&u= =3Dhttps%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR= 8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing> > >> > >> > >> [2] > >> https://datatracker.ietf.org/doc/minutes-interim-2017-ace-03-201710191= 300/ > >> > >> [3] https://datatracker.ietf.org/doc/draft-selander-ace-eals/ > >> > >> > >> > >> -- > >> > >> Daniel Migault > >> > >> > >> > >> Ericsson > >> > > > > > > -- > > Daniel Migault > > Ericsson > > > > > -- > Daniel Migault > Ericsson > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace -- Daniel Migault Ericsson _______________________________________________ Ace mailing list Ace@ietf.orghttps://www.ietf.org/mailman/listinfo= /ace _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core -- Laurent Toutain +--- VoIP (recommended) ---+----------- T=E9l=E9com Bretagne -----------+ | Tel: +33 2 22 06 8156 | Tel: + 33 2 99 12 7026 | Visit= :| Mob: +33 6 800 75 900 | | | Fax: +33 2 22 06 8445 | Fax: +33 2 99 12 7030 | http= ://class.touta.in | Laurent@Touta.in | Laurent.Toutain@Telec= om-Bretagne.eu | +--------------------------+----------------------------------------+ --_000_HE1PR0702MB367429A9C8921A5252133523F4CE0HE1PR0702MB3674_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

+1.

 

(The recently updated ACE charter should cover this work.)=

 

G=F6ran

&nbs= p;

On 2020-12-03, 20:03, "core" <core-bounces@ietf.org> wrote:=

Hi,

I think it is important= to have EAP on top of CoAP, as Dan said it fit well with the last charter = item.

 

Laurent

 

 

On Thu, Dec 3, 2020 at = 2:20 PM Daniel Migault <daniel.migault=3D40ericsson.com@dmarc.ietf.org> wr= ote:

 

 

CCing emu, core

 

It seems ACE to me that= ACE could be home for such a document. I am wondering if emu core or any o= ther WG believe there is a better place for it.

 

Regarding ACE I am wond= ering what is the WG opinion about adding this item to the ACE charter.

 

Yours,

Daniel

_______________________= _________________

From: Ace <ace-bounces@ietf.org> on behalf of = Dan Garcia <dan.garcia@um.es>=

Sent: Thursday, Decembe= r 3, 2020 6:10 AM

Subject: [Ace] Proposed= charter for ACE (EAP over CoAP?)  

 

Dear all:

 

Regarding the new chart= er, since ACE is considering the definition of CoAP transport for CMPv2 (https://tools.ietf.org/html/draft-msahni-ace-cmpv2-coap-transport-00), we were wondering whethere it could also consider specifying EAP (Extensib= le Authentication Protocol) over CoAP.

 

In this sense, we propo= sed this some time ago and we have implementations about this.

 

 

The usage of CoAP can p= rovide a very light and link-layer independent (we even tested in LoRa netw= orks) EAP lower-layer (transport for EAP) suitable for IoT enviroment. We b= elieve this would be really useful since EAP provides flexibility for the authentication and it is a well-known pro= tocol.

 

Therefore, we would lik= e to propose the following modification to the charter:

 

"The Working Group= will examine how to use Constrained Application Protocol (CoAP) as a trans= port medium for certificate enrollment protocols, such as EST and CMPv2, as= well as a transport for authentication protocols such as EAP, and standardize them as needed."

 

This modification does = not necessarily mean the adoption of our draft. After all, we completely un= derstand that this would happen only if there is an interest in the WG. Nev= ertheless, we would like to avoid that the charter is a barrier later if there is interest in the WG to work in t= his transport of EAP over CoAP:

 

Any opinion about this?=

 

Best Regards.

 

El 18/11/2020 a las 8:0= 8, Daniel Migault escribi=F3:

 

 

Hi,  

Please find the propose= d charter we agreed on during the interim meeting. If you would like to pro= pose any change, please use the following URL by November 25:

 

 

 

Yours,

Daniel

 

The Authentication and = Authorization for Constrained Environments (ace) WG has defined a standardi= zed solution framework for authentication and authorization to enable autho= rized access to resources identified by a URI and hosted on a resource server in constrained environments.

The access to the resou= rce is mediated by an authorization server, which is not considered to be c= onstrained.

 

Profiles of this framew= ork for application to security protocols commonly used in constrained envi= ronments, including CoAP+DTLS and CoAP+OSCORE, have also been standardized.=   The Working Group is charged with maintenance of the framework and existing profiles thereof, and may undert= ake work to specify profiles of the framework for additional secure communi= cations protocols and for additional support services providing authorized = access to crypto keys (that are not necessarily limited to constrained endpoints, though the focus remains= on deployment in ecosystems with a substantial portion of constrained devi= ces).

 

In addition to the ongo= ing maintenance work, the Working Group will extend the framework as needed= for applicability to group communications, with initial focus on (D)TLS an= d (Group) OSCORE as the underlying group communication security protocols. The Working Group will standardize proce= dures for requesting and distributing group keying material using the ACE f= ramework as well as appropriated management interfaces.

 

The Working Group will = standardize a format for expressing authorization information for a given a= uthenticated principal as received from an authorization manager.

 

The Working Group will = examine how to use Constrained Application Protocol (CoAP) as a transport m= edium for certificate enrollment protocols, such as EST and CMPv2, and stan= dardize as needed.

 

 

 

 

On Tue, Nov 17, 2020 at= 6:47 PM Benjamin Kaduk <kaduk@mit.edu<= /a>> wrote:

 

 

Thanks for updating the= draft charter at [1], Daniel!

 

I note that Michael rai= sed the question of whether some other group might

also be interested in w= orking on CMP-over-coap, so the IESG will be sure to

discuss that if CMP is = still in the draft ACE charter when it goes to the

IESG for review.

 

-Ben

 

On Tue, Nov 17, 2020 at= 06:16:48PM -0500, Daniel Migault wrote:

> Thank you all for = the feed backs. For the purpose of driving the charter

> discussion at the = IETf 109, I have added the comments into the proposed

> text [1].

>

> My current underst= anding is that it seems beneficial to add CMPv2 over CoAP

> in the charter. I = am happy to be contradicted.

> * I have not seen = a clear cut to do one or the other.

> * EST and CMPv2 ar= e two protocols that can be used for enrollment or cert

> management while a= ddressing different cases / needs / situations -- maybe

> we can clarify tha= t point. I can see leveraging the existing CMP

> infrastructure, bu= t it seems that is not the only one.

> * I am not convinc= ed that not having CMP over CoAP will not prevent its

> deployment and as = such I prefer to have it standardized - this might be a

> personal thought.<= o:p>

> * Adding any piece= of work require cycles, but it seems to me that CPM will

> not have a major i= mpact on the WG progress. The work will probably include

> other WG such a LA= MPS.

>

> Yours,<= /p>

> Daniel<= /p>

>

> [1]

>

> On Tue, Nov 17, 20= 20 at 6:02 PM Daniel Migault <mgl= t.ietf@gmail.com> wrote:

>

> > Hi Goran,

> >

> > I added the t= ext to the charter we will discuss later.

> >

> > Yours,

> > Daniel

> >

> > On Fri, Nov 1= 3, 2020 at 10:26 AM G=F6ran Selander <

> >

> >> Hi Daniel= ,

> >>

> >>

> >>

> >> Here=92s = another input to the charter.

> >>

> >>

> >>

> >> The curre= nt group key management solutions addresses the problem of

> >> authorize= d access to group keys and public keys of group members.

> >>

> >>

> >>

> >> A related= problem is authorized access of public keys of other devices

> >> not neces= sarily part of a security group, in the sense of sharing a

> >> symmetric= key used to protect group messages.

> >>

> >>

> >>

> >> Authorize= d access to raw public keys serves an important function in

> >> constrain= ed settings where public key certificates may not be feasible due

> >> to the in= curred overhead, e.g. for when authenticating using EDHOC

> >> (draft-ie= tf-lake-edhoc).

> >>

> >> This func= tionality is thus a subset of what is already supported, but

> >> since the= current solution is geared towards groups a different solution<= /p>

> >> may be ne= eded (although it is probably possible to reuse parts from the

> >> existing = schemes for provisioning and requesting public keys).

> >>

> >>

> >>

> >> With this= in mind, I propose the following change (highlighted in

> >> boldface = below):

> >>

> >>

> >>

> >> OLD<= /o:p>

> >>

> >> The Worki= ng Group is charged with maintenance of the framework and

> >> existing = profiles thereof, and may undertake work to specify profiles of<= /p>

> >> the frame= work for additional secure communications protocols (that are not

> >> necessari= ly limited to constrained endpoints, though the focus remains on=

> >> deploymen= t ecosystems with a substantial portion of constrained devices).=

> >>

> >>

> >>

> >> NEW<= /o:p>

> >>

> >> The Worki= ng Group is charged with maintenance of the framework and

> >> existing = profiles thereof, and may undertake work to specify profiles of<= /p>

> >> the frame= work for additional secure communications protocols *and **for

> >> additiona= l **support services **providing* *authorized access to crypto* *keys<= /o:p>

> >> *(that ar= e not necessarily limited to constrained endpoints, though the

> >> focus rem= ains on deployment ecosystems with a substantial portion of

> >> constrain= ed devices).

> >>

> >>

> >>

> >> G=F6ran

> >>

> >>

> >>

> >>

> >>

> >>

> >>

> >> On 2020-1= 0-15, 19:50, "Ace" <ac= e-bounces@ietf.org> wrote:

> >>

> >> Hi,<= /o:p>

> >>

> >> I would l= ike to start the charter discussion. Here is a draft of a

> >> proposed = charter [1].

> >>

> >>

> >>

> >> It seems = to be that additional discussion is needed with regard to the

> >> last para= graph related certificate management. In particular the discussion

> >> might rev= ive a discussion that happened in 2017 [2] - when I was not

> >> co-chair = of ACE -and considered other expired work such as [3]. Please make

> >> this disc= ussion constructive on this thread.

> >>

> >>

> >>

> >> The funda= mental question is whether we need certificate management at

> >> this stag= e. If the answer is yes, and we have multiple proposals, it would

> >> be good t= o clarify the position of the different proposals and evaluate

> >> whether a= selection is needed or not before validating the charter.

> >>

> >>

> >>

> >> Please pr= ovide your inputs on the mailing list before October 30. Of

> >> course fo= r minor edits, you may suggest them directly on the google doc.<= /p>

> >>

> >>

> >>

> >> Yours,

> >>

> >> Daniel

> >>

> >>

> >>

> >> [1]<= /o:p>

> >> <=

> >>

> >>

> >> [2]<= /o:p>

> >>

> >>

> >>

> >>

> >> --

> >>

> >> Daniel Mi= gault

> >>

> >>

> >>

> >> Ericsson<= o:p>

> >>

> >

> >

> > --=

> > Daniel Migaul= t

> > Ericsson=

> >

>

>

> --

> Daniel Migault

> Ericsson

 

> __________________= _____________________________

> Ace mailing list

 

_______________________= ________________________

Ace mailing list

 

 

 

 

 

--

Daniel Migault

 

Ericsson

 

 

 

 

_______________________= ________________________

Ace mailing list

Ace@ietf.orghttps://www.ietf.org/mailman/listinfo/ace

 

 

 

_______________________= ________________________

core mailing list<= /o:p>

 

 

 

 

 

--

Laurent Toutain

+--- VoIP (recommended)= ---+----------- T=E9l=E9com Bretagne -----------+

| Tel: +33 2 22 06 8156=     | Tel: + 33 2 99 12 7026    &nb= sp;            | Vis= it :| Mob: +33 6 800 75 900    |    = ;            &n= bsp;            = ;           |

+----------------------= ----+----------------------------------------+

--_000_HE1PR0702MB367429A9C8921A5252133523F4CE0HE1PR0702MB3674_-- From nobody Mon Dec 7 07:55:57 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAFEB3A1401; Mon, 7 Dec 2020 07:50:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBXCfND5T5So; Mon, 7 Dec 2020 07:50:55 -0800 (PST) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 285AA3A12F2; Mon, 7 Dec 2020 07:50:55 -0800 (PST) Received: by mail-wr1-x42c.google.com with SMTP id u12so13268544wrt.0; Mon, 07 Dec 2020 07:50:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=UjnzJ3EgirBAhVKXDHccTygAUJhRu1B0z1NxSNn1u1A=; b=WfUhg2dX38zkVOINaHcBVCFGIRECqahMuQhUFhc+TIIbEO6J7lLMdummyGTLsrZwYc ZMdcyw+KN+lmfZEIGfxQU0lV4wOGubHYAJY/ZBDThirI+dYRrNpiuBfyzdfquKqHCz1J neU/xGJ1czWU+WnY5aFR/gDl2DK59uwf9aoHMlKkrW85EE/26F1LTfY9IyRpGLxef2z9 jH5kEd74ROXEPfIKFAomgCWSYZDkx0mgbS8an60Pds98uPsiNDQOiAHbO8nGeWaL+7Zw wGLS8LUQPC/1kbUpBI/KvsbAkztRKG+qbY7LMP7xZHBq8s3R+5UIlTJmI1rucMBHC0J6 5E6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=UjnzJ3EgirBAhVKXDHccTygAUJhRu1B0z1NxSNn1u1A=; b=JoNkro6ci3o8Q8kWrbPRsOijE/HPjH2b5VO0jYeAoyDd/++QAHygB6nIXwr2CkwfNy xZBTnrjzMAFEeUmnyI1q49GgVisLYdh+1XcELJ1shtS9orqH9cC/NQcsT1LtT7VTl+X4 dpEcFID+wLBpZ9TEIh5aBoucOndTeSBKLy9V/CVXFS+7s/hQIusCCf5rl3DplcZ0u+lG EvFMOOabrw0y+5fVnlGvYA61160P00WxILZheNJdSCU+9DGH6wz7Tps0ncSREvirII/z 0iyfy0FFN7VaAg/dPg94W3/SH0pjIDvnb5yDe5VxnelkALSfmZjmtEceNbJsgyamThqs 8/zQ== X-Gm-Message-State: AOAM532DzHs7/BGSpz/HmGpcNDYi3NERHNT1hbHDLps8MprC9GtK9SvC mdfZ2l2mPLSnV0/Ii5Z5Bvr+UijtlWDncg== X-Google-Smtp-Source: ABdhPJxmqt5yMwEKJqPmKBycTp+JHrjc82JZ7JGEb2mCLQaB3XigQwJdd/tqORzf5Qrh8uezOuLJ9w== X-Received: by 2002:adf:f5c8:: with SMTP id k8mr21001800wrp.2.1607356253012; Mon, 07 Dec 2020 07:50:53 -0800 (PST) Received: from DESKTOPK60BM4E ([2a00:23c6:fa0d:de00:2527:1c82:ae9a:788a]) by smtp.gmail.com with ESMTPSA id z189sm15231266wme.23.2020.12.07.07.50.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Dec 2020 07:50:52 -0800 (PST) From: To: =?iso-8859-1?Q?'G=F6ran_Selander'?= , "'Laurent Toutain'" , "'Daniel Migault'" Cc: "'EMU WG'" , , References: <20201117234700.GR39170@kduck.mit.edu> , In-Reply-To: Date: Mon, 7 Dec 2020 15:50:50 -0000 Message-ID: <0d6901d6ccb0$bd4c6860$37e53920$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0D6A_01D6CCB0.BD57DA10" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQG6JKv2a7qQBTl33wklZrQSVXysXAH3R+HWAmdvjUcBgvyeOQDQs5O2AgnIf0QBvwP2VgHrXo5BAhRWZ9IB9Ii2dqmhmrQw Content-Language: en-gb Archived-At: X-Mailman-Approved-At: Mon, 07 Dec 2020 07:55:55 -0800 Subject: Re: [core] [Emu] [Ace] Proposed charter for ACE (EAP over CoAP?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 15:50:59 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0D6A_01D6CCB0.BD57DA10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I support this; although I am curious in Dan=92s opinion as to whether = GSS on top of CoAP is also worth considering, as a way of leveraging the GSS = EAP and other mechanisms (such as Kerberos). =20 Josh =20 From: Emu On Behalf Of G=F6ran Selander Sent: 07 December 2020 14:08 To: Laurent Toutain ; Daniel = Migault Cc: EMU WG ; core@ietf.org WG (core@ietf.org) = ; ace@ietf.org Subject: Re: [Emu] [core] [Ace] Proposed charter for ACE (EAP over = CoAP?) =20 +1.=20 =20 (The recently updated ACE charter should cover this work.) =20 G=F6ran =20 On 2020-12-03, 20:03, "core" > wrote: Hi, I think it is important to have EAP on top of CoAP, as Dan said it fit = well with the last charter item. =20 Laurent =20 =20 On Thu, Dec 3, 2020 at 2:20 PM Daniel Migault > wrote: =20 =20 CCing emu, core =20 It seems ACE to me that ACE could be home for such a document. I am wondering if emu core or any other WG believe there is a better place = for it.=20 =20 Regarding ACE I am wondering what is the WG opinion about adding this = item to the ACE charter.=20 =20 Yours,=20 Daniel ________________________________________ From: Ace > on = behalf of Dan Garcia > Sent: Thursday, December 3, 2020 6:10 AM To: ace@ietf.org > Subject: [Ace] Proposed charter for ACE (EAP over CoAP?) =20 =20 Dear all: =20 Regarding the new charter, since ACE is considering the definition of = CoAP transport for CMPv2 (https://tools.ietf.org/html/draft-msahni-ace-cmpv2-coap-transport-00), = we were wondering whethere it could also consider specifying EAP = (Extensible Authentication Protocol) over CoAP. =20 In this sense, we proposed this some time ago and we have = implementations about this. =20 https://datatracker.ietf.org/doc/html/draft-marin-ace-wg-coap-eap-06 https://www.mdpi.com/1424-8220/16/3/358 https://www.mdpi.com/1424-8220/17/11/2646 =20 The usage of CoAP can provide a very light and link-layer independent = (we even tested in LoRa networks) EAP lower-layer (transport for EAP) = suitable for IoT enviroment. We believe this would be really useful since EAP provides flexibility for the authentication and it is a well-known = protocol. =20 Therefore, we would like to propose the following modification to the charter: =20 "The Working Group will examine how to use Constrained Application = Protocol (CoAP) as a transport medium for certificate enrollment protocols, such = as EST and CMPv2, as well as a transport for authentication protocols such = as EAP, and standardize them as needed." =20 This modification does not necessarily mean the adoption of our draft. = After all, we completely understand that this would happen only if there is an interest in the WG. Nevertheless, we would like to avoid that the = charter is a barrier later if there is interest in the WG to work in this transport = of EAP over CoAP: =20 Any opinion about this? =20 Best Regards. =20 El 18/11/2020 a las 8:08, Daniel Migault escribi=F3: =20 =20 Hi, =20 Please find the proposed charter we agreed on during the interim = meeting. If you would like to propose any change, please use the following URL by November 25: =20 https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXh= oDi ptY/edit?usp=3Dsharing &q=3D1&e=3D03ce3af5-6990-40e0-b2b5-255ac5f5dfe0&u=3Dhttps%3A%2F%2Fdocs.go= ogle.com% 2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fus= p%3 Dsharing> =20 =20 Yours,=20 Daniel =20 The Authentication and Authorization for Constrained Environments (ace) = WG has defined a standardized solution framework for authentication and authorization to enable authorized access to resources identified by a = URI and hosted on a resource server in constrained environments.=20 The access to the resource is mediated by an authorization server, which = is not considered to be constrained. =20 Profiles of this framework for application to security protocols = commonly used in constrained environments, including CoAP+DTLS and CoAP+OSCORE, = have also been standardized. The Working Group is charged with maintenance = of the framework and existing profiles thereof, and may undertake work to specify profiles of the framework for additional secure communications protocols and for additional support services providing authorized = access to crypto keys (that are not necessarily limited to constrained endpoints, though the focus remains on deployment in ecosystems with a substantial portion of constrained devices). =20 In addition to the ongoing maintenance work, the Working Group will = extend the framework as needed for applicability to group communications, with initial focus on (D)TLS and (Group) OSCORE as the underlying group communication security protocols. The Working Group will standardize procedures for requesting and distributing group keying material using = the ACE framework as well as appropriated management interfaces.=20 =20 The Working Group will standardize a format for expressing authorization information for a given authenticated principal as received from an authorization manager.=20 =20 The Working Group will examine how to use Constrained Application = Protocol (CoAP) as a transport medium for certificate enrollment protocols, such = as EST and CMPv2, and standardize as needed. =20 =20 =20 =20 On Tue, Nov 17, 2020 at 6:47 PM Benjamin Kaduk > wrote: =20 =20 Thanks for updating the draft charter at [1], Daniel! =20 I note that Michael raised the question of whether some other group = might also be interested in working on CMP-over-coap, so the IESG will be sure = to discuss that if CMP is still in the draft ACE charter when it goes to = the IESG for review. =20 -Ben =20 On Tue, Nov 17, 2020 at 06:16:48PM -0500, Daniel Migault wrote: > Thank you all for the feed backs. For the purpose of driving the = charter > discussion at the IETf 109, I have added the comments into the = proposed > text [1]. >=20 > My current understanding is that it seems beneficial to add CMPv2 over CoAP > in the charter. I am happy to be contradicted. > * I have not seen a clear cut to do one or the other. > * EST and CMPv2 are two protocols that can be used for enrollment or = cert > management while addressing different cases / needs / situations -- = maybe > we can clarify that point. I can see leveraging the existing CMP > infrastructure, but it seems that is not the only one. > * I am not convinced that not having CMP over CoAP will not prevent = its > deployment and as such I prefer to have it standardized - this might = be a > personal thought. > * Adding any piece of work require cycles, but it seems to me that CPM will > not have a major impact on the WG progress. The work will probably = include > other WG such a LAMPS. >=20 > Yours, > Daniel >=20 > [1] > https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXh= oDi ptY/edit?usp=3Dsharing &q=3D1&e=3D03ce3af5-6990-40e0-b2b5-255ac5f5dfe0&u=3Dhttps%3A%2F%2Fdocs.go= ogle.com% 2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fus= p%3 Dsharing> >=20 > On Tue, Nov 17, 2020 at 6:02 PM Daniel Migault > wrote: >=20 > > Hi Goran, > > > > I added the text to the charter we will discuss later. > > > > Yours, > > Daniel > > > > On Fri, Nov 13, 2020 at 10:26 AM G=F6ran Selander < > > goran.selander@ericsson.com > wrote: > > > >> Hi Daniel, > >> > >> > >> > >> Here=92s another input to the charter. > >> > >> > >> > >> The current group key management solutions addresses the problem of > >> authorized access to group keys and public keys of group members. > >> > >> > >> > >> A related problem is authorized access of public keys of other = devices > >> not necessarily part of a security group, in the sense of sharing a > >> symmetric key used to protect group messages. > >> > >> > >> > >> Authorized access to raw public keys serves an important function = in > >> constrained settings where public key certificates may not be = feasible due > >> to the incurred overhead, e.g. for when authenticating using EDHOC > >> (draft-ietf-lake-edhoc). > >> > >> This functionality is thus a subset of what is already supported, = but > >> since the current solution is geared towards groups a different solution > >> may be needed (although it is probably possible to reuse parts from = the > >> existing schemes for provisioning and requesting public keys). > >> > >> > >> > >> With this in mind, I propose the following change (highlighted in > >> boldface below): > >> > >> > >> > >> OLD > >> > >> The Working Group is charged with maintenance of the framework and > >> existing profiles thereof, and may undertake work to specify = profiles of > >> the framework for additional secure communications protocols (that = are not > >> necessarily limited to constrained endpoints, though the focus = remains on > >> deployment ecosystems with a substantial portion of constrained devices). > >> > >> > >> > >> NEW > >> > >> The Working Group is charged with maintenance of the framework and > >> existing profiles thereof, and may undertake work to specify = profiles of > >> the framework for additional secure communications protocols *and = **for > >> additional **support services **providing* *authorized access to crypto* *keys > >> *(that are not necessarily limited to constrained endpoints, though = the > >> focus remains on deployment ecosystems with a substantial portion = of > >> constrained devices). > >> > >> > >> > >> G=F6ran > >> > >> > >> > >> > >> > >> > >> > >> On 2020-10-15, 19:50, "Ace" > wrote: > >> > >> Hi, > >> > >> I would like to start the charter discussion. Here is a draft of a > >> proposed charter [1]. > >> > >> > >> > >> It seems to be that additional discussion is needed with regard to = the > >> last paragraph related certificate management. In particular the discussion > >> might revive a discussion that happened in 2017 [2] - when I was = not > >> co-chair of ACE -and considered other expired work such as [3]. = Please make > >> this discussion constructive on this thread. > >> > >> > >> > >> The fundamental question is whether we need certificate management = at > >> this stage. If the answer is yes, and we have multiple proposals, = it would > >> be good to clarify the position of the different proposals and = evaluate > >> whether a selection is needed or not before validating the charter. > >> > >> > >> > >> Please provide your inputs on the mailing list before October 30. = Of > >> course for minor edits, you may suggest them directly on the google doc. > >> > >> > >> > >> Yours, > >> > >> Daniel > >> > >> > >> > >> [1] > >> https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXh= oDi ptY/edit?usp=3Dsharing &q=3D1&e=3D03ce3af5-6990-40e0-b2b5-255ac5f5dfe0&u=3Dhttps%3A%2F%2Fdocs.go= ogle.com% 2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fus= p%3 Dsharing> > >> < > >> https://protect2.fireeye.com/v1/url?k=3D4f3d9c3b-118c475b-4f3ddca0-86e223= 7f51f b-627e48b069462d70 &q=3D1&e=3D6924b2a6-e7e5-4ec1-a1af-c94637953dc5&u=3Dhttps%3A%2F%2Fdocs.go= ogle.com% 2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fus= p%3 Dsharing> > >> > >> > >> [2] > >> https://datatracker.ietf.org/doc/minutes-interim-2017-ace-03-201710191300= / > >> > >> [3] https://datatracker.ietf.org/doc/draft-selander-ace-eals/ > >> > >> > >> > >> -- > >> > >> Daniel Migault > >> > >> > >> > >> Ericsson > >> > > > > > > -- > > Daniel Migault > > Ericsson > > >=20 >=20 > --=20 > Daniel Migault > Ericsson =20 > _______________________________________________ > Ace mailing list > Ace@ietf.org =20 > https://www.ietf.org/mailman/listinfo/ace =20 _______________________________________________ Ace mailing list Ace@ietf.org =20 https://www.ietf.org/mailman/listinfo/ace =20 =20 =20 =20 =20 --=20 Daniel Migault =20 Ericsson =20 =20 =20 =20 _______________________________________________ Ace mailing list Ace@ietf.orghttps ://www.ietf.org/mailman/listinfo/ace =20 =20 =20 _______________________________________________ core mailing list core@ietf.org =20 https://www.ietf.org/mailman/listinfo/core =20 =20 =20 =20 =20 --=20 Laurent Toutain=20 +--- VoIP (recommended) ---+----------- T=E9l=E9com Bretagne = -----------+ | Tel: +33 2 22 06 8156 | Tel: + 33 2 99 12 7026 | = Visit :| Mob: +33 6 800 75 900 | | | Fax: +33 2 22 06 8445 | Fax: +33 2 99 12 7030 | http://class.touta.in &q=3D1&e=3D4c9aeb6f-f5eb-4229-b6fb-e4c6abb28354&u=3Dhttp%3A%2F%2Fclass.to= uta.in%2F > | Laurent@Touta.in | Laurent.Toutain@Telecom-Bretagne.eu | +--------------------------+----------------------------------------+ ------=_NextPart_000_0D6A_01D6CCB0.BD57DA10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I support this; although I am = curious in Dan’s opinion as to whether GSS on top of CoAP is also = worth considering, as a way of leveraging the GSS EAP and other = mechanisms (such as Kerberos).

 

Josh

 

From: Emu = <emu-bounces@ietf.org> On Behalf Of G=F6ran = Selander
Sent: 07 December 2020 14:08
To: Laurent = Toutain <Laurent.Toutain@telecom-bretagne.eu>; Daniel Migault = <daniel.migault=3D40ericsson.com@dmarc.ietf.org>
Cc: EMU = WG <emu@ietf.org>; core@ietf.org WG (core@ietf.org) = <core@ietf.org>; ace@ietf.org
Subject: Re: [Emu] [core] = [Ace] Proposed charter for ACE (EAP over = CoAP?)

 

+1. =

 

(The recently updated ACE charter = should cover this work.)

 

G=F6ran

 

On 2020-12-03, 20:03, "core" <core-bounces@ietf.org> = wrote:

Hi,

I think it is important = to have EAP on top of CoAP, as Dan said it fit well with the last = charter item.

 

Laurent

 

 

On Thu, Dec 3, 2020 at = 2:20 PM Daniel Migault <daniel.mig= ault=3D40ericsson.com@dmarc.ietf.org> = wrote:

 

 

CCing emu, = core

 

It seems ACE to me that = ACE could be home for such a document. I am wondering if emu core or any = other WG believe there is a better place for it. =

 

Regarding ACE I am = wondering what is the WG opinion about adding this item to the ACE = charter.

 

Yours, =

Daniel

________________________________________

From: Ace <ace-bounces@ietf.org> on = behalf of Dan Garcia <dan.garcia@um.es>

<= /div>

Sent: = Thursday, December 3, 2020 6:10 AM

Subject: [Ace] = Proposed charter for ACE (EAP over = CoAP?)  

 

Dear = all:

 

Regarding the new = charter, since ACE is considering the definition of CoAP transport for = CMPv2 (https://tools.ietf.org/html/draft-msahni-ace-cmpv2-coap-transport-00= ), we were wondering whethere it could also consider specifying EAP = (Extensible Authentication Protocol) over = CoAP.

 

In this sense, we = proposed this some time ago and we have implementations about = this.

 

 

The usage of CoAP can = provide a very light and link-layer independent (we even tested in LoRa = networks) EAP lower-layer (transport for EAP) suitable for IoT = enviroment. We believe this would be really useful since EAP provides = flexibility for the authentication and it is a well-known = protocol.

 

Therefore, we would like = to propose the following modification to the = charter:

 

"The Working Group = will examine how to use Constrained Application Protocol (CoAP) as a = transport medium for certificate enrollment protocols, such as EST and = CMPv2, as well as a transport for authentication protocols such as EAP, = and standardize them as needed."

 

This modification does = not necessarily mean the adoption of our draft. After all, we completely = understand that this would happen only if there is an interest in the = WG. Nevertheless, we would like to avoid that the charter is a barrier = later if there is interest in the WG to work in this transport of EAP = over CoAP:

 

Any opinion about = this?

 

Best = Regards.

 

El 18/11/2020 a las 8:08, = Daniel Migault escribi=F3:

 

 

Hi,  

Please find the proposed = charter we agreed on during the interim meeting. If you would like to = propose any change, please use the following URL by November = 25:

 

https://docs.google.com/document/d/1Rt= xUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=3Dsharing <https://= protect2.fireeye.com/v1/url?k=3Df9dc6551-a6475d83-f9dc25ca-866132fe445e-9= c25a5c257a23470&q=3D1&e=3D03ce3af5-6990-40e0-b2b5-255ac5f5dfe0&am= p;u=3Dhttps%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2= c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing>

 

 

Yours, =

Daniel

 

The Authentication and = Authorization for Constrained Environments (ace) WG has defined a = standardized solution framework for authentication and authorization to = enable authorized access to resources identified by a URI and hosted on = a resource server in constrained environments. =

The access to the resource is mediated by = an authorization server, which is not considered to be = constrained.

 

Profiles of this = framework for application to security protocols commonly used in = constrained environments, including CoAP+DTLS and CoAP+OSCORE, have also = been standardized.  The Working Group is charged with = maintenance of the framework and existing profiles thereof, and may = undertake work to specify profiles of the framework for additional = secure communications protocols and for additional support services = providing authorized access to crypto keys (that are not necessarily = limited to constrained endpoints, though the focus remains on deployment = in ecosystems with a substantial portion of constrained = devices).

 

In addition to the = ongoing maintenance work, the Working Group will extend the framework as = needed for applicability to group communications, with initial focus on = (D)TLS and (Group) OSCORE as the underlying group communication security = protocols. The Working Group will standardize procedures for requesting = and distributing group keying material using the ACE framework as well = as appropriated management interfaces.

 

The Working Group will = standardize a format for expressing authorization information for a = given authenticated principal as received from an authorization manager. =

 

The Working Group will = examine how to use Constrained Application Protocol (CoAP) as a = transport medium for certificate enrollment protocols, such as EST and = CMPv2, and standardize as needed.

 

 

 

 

On Tue, Nov 17, 2020 at = 6:47 PM Benjamin Kaduk <kaduk@mit.edu> = wrote:

 

 

Thanks for updating the = draft charter at [1], Daniel!

 

I note that Michael = raised the question of whether some other group = might

also be interested in working on = CMP-over-coap, so the IESG will be sure to

discuss that if CMP is = still in the draft ACE charter when it goes to = the

IESG for = review.

 

-Ben

 

On Tue, Nov 17, 2020 at = 06:16:48PM -0500, Daniel Migault wrote:

> Thank you all for = the feed backs. For the purpose of driving the = charter

> discussion at the IETf 109, I have = added the comments into the proposed

> text = [1].

>

> My current = understanding is that it seems beneficial to add CMPv2 over = CoAP

> in the charter. I am happy to be = contradicted.

> * I have not seen a clear cut to do = one or the other.

> * EST and CMPv2 are two protocols that = can be used for enrollment or cert

> management while = addressing different cases / needs / situations -- = maybe

> we can clarify that point. I can see = leveraging the existing CMP

> infrastructure, but = it seems that is not the only one.

> * I am not convinced = that not having CMP over CoAP will not prevent = its

> deployment and as such I prefer to = have it standardized - this might be a

> personal = thought.

> * Adding any piece of work require = cycles, but it seems to me that CPM will

> not have a major = impact on the WG progress. The work will probably = include

> other WG such a = LAMPS.

>

> = Yours,

> Daniel

> =

> [1]

> https://docs.google.com/document/d/1Rt= xUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=3Dsharing <https://= protect2.fireeye.com/v1/url?k=3Da01e017d-ff8539af-a01e41e6-866132fe445e-7= 268e18ca0e30ad7&q=3D1&e=3D03ce3af5-6990-40e0-b2b5-255ac5f5dfe0&am= p;u=3Dhttps%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2= c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing>

> =

> On Tue, Nov 17, 2020 at 6:02 PM Daniel = Migault <mglt.ietf@gmail.com> = wrote:

>

> > Hi = Goran,

> >

> > I added the = text to the charter we will discuss later.

> = >

> > = Yours,

> > = Daniel

> >

> > On Fri, Nov 13, = 2020 at 10:26 AM G=F6ran Selander <

> >>

> >> = Hi,

> >>

> >> I would = like to start the charter discussion. Here is a draft of = a

> >> proposed charter = [1].

> >>

> = >>

> >>

> >> It seems to = be that additional discussion is needed with regard to = the

> >> last paragraph related = certificate management. In particular the = discussion

> >> might revive a discussion = that happened in 2017 [2] - when I was not

> >> co-chair of = ACE -and considered other expired work such as [3]. Please = make

> >> this discussion constructive = on this thread.

> >>

> = >>

> >>

> >> The = fundamental question is whether we need certificate management = at

> >> this stage. If the answer is = yes, and we have multiple proposals, it = would

> >> be good to clarify the = position of the different proposals and = evaluate

> >> whether a selection is needed = or not before validating the charter.

> = >>

> >>

> = >>

> >> Please provide your inputs on = the mailing list before October 30. Of

> >> course for = minor edits, you may suggest them directly on the google = doc.

> >>

> = >>

> >>

> >> = Yours,

> >>

> >> = Daniel

> >>

> = >>

> >>

> >> = [1]

> >> https://docs.google.com/document/d/1Rt= xUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=3Dsharing <https://= protect2.fireeye.com/v1/url?k=3D2eaaeb96-7131d344-2eaaab0d-866132fe445e-7= e515f25c81762b8&q=3D1&e=3D03ce3af5-6990-40e0-b2b5-255ac5f5dfe0&am= p;u=3Dhttps%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2= c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing>

> >> = <

> >> https://= protect2.fireeye.com/v1/url?k=3D4f3d9c3b-118c475b-4f3ddca0-86e2237f51fb-6= 27e48b069462d70&q=3D1&e=3D6924b2a6-e7e5-4ec1-a1af-c94637953dc5&am= p;u=3Dhttps%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2= c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing>

> = >>

> >>

> >> = [2]

> >>

> >> [3] https:= //datatracker.ietf.org/doc/draft-selander-ace-eals/

> = >>

> >>

> = >>

> >> = --

> >>

> >> Daniel = Migault

> >>

> = >>

> >>

> >> = Ericsson

> >>

> = >

> >

> > = --

> > Daniel = Migault

> > = Ericsson

> >

> =

>

> -- =

> Daniel = Migault

> Ericsson

 

> = _______________________________________________

=

> Ace mailing = list

 

____________________________________________= ___

Ace mailing = list

 

 

 

 

 

-- =

Daniel Migault

 

Ericsson

 

 

 

 

____________________________________________= ___

Ace mailing = list

Ace@ietf.orghttps://www.ietf.org/ma= ilman/listinfo/ace

 

 

 

____________________________________________= ___

core mailing = list

 

 

 

 

 

-- =

Laurent Toutain =

+--- VoIP (recommended) ---+----------- = T=E9l=E9com Bretagne -----------+

| Tel: +33 2 22 06 = 8156    | Tel: + 33 2 99 12 = 7026           &nb= sp;     | Visit :| Mob: +33 6 800 75 = 900    |       &nb= sp;           &nbs= p;            = ;        |

| Fax: +33 2 22 06 = 8445    | Fax: +33 2 99 12 = 7030           &nb= sp;      |  http://class.touta.in <https://protect2.fi= reeye.com/v1/url?k=3Da3f58437-fc325694-a3f5c4ac-86f373f27850-0daaf502d59f= 9de3&q=3D1&e=3D4c9aeb6f-f5eb-4229-b6fb-e4c6abb28354&u=3Dhttp%= 3A%2F%2Fclass.touta.in%2F>

| Laurent@Touta.in   &n= bsp;     | Laurent.Toutain@Telec= om-Bretagne.eu    |

+--------------------------+----------------= ------------------------+

------=_NextPart_000_0D6A_01D6CCB0.BD57DA10-- From nobody Mon Dec 7 09:35:47 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77B073A1623; Mon, 7 Dec 2020 09:35:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64AjrE6f3mKl; Mon, 7 Dec 2020 09:35:39 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30087.outbound.protection.outlook.com [40.107.3.87]) (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 E72113A1621; Mon, 7 Dec 2020 09:35:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HKCUAi2/5PI7llMsYhmvlIP9lZ3zbfV9qkc9CtpLm8807vr5DynRJ+Mayyb+bvcgs+eqBeaU87DBuCIrW/AxliZiOBQj67763xj1XroreMHN3/nNl91XUy/S0ic/DCwT0MbUciZ0oJOIVy8NJmMh+G26liA/b4RS9NlhaJEs8LptB2s90XmvKXtYXqNpnUBgQyX/L3AGPnw8pcWC/0FfFjLv+Lec4UlK5o1ieslF7DfyUUfzZ+w6zCASX4qyX+fGGYePF/pR2zlXA9IE7SbHG4z5pEoQZYDpcIz2R8GKo7V+dNQHQwMrgn73LHgDZOP4tQCJi77g3xfYM9BinklnRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3f87YWe2fBKo9/43Z9KbdJav/wBrq3TN5EH95qm/TNo=; b=QihNKB6/sYE+lKQOMyr19aHV4UfZHsuzJGBqWK3zo9e3XjRJkqQGuZIb/E5tBMjHLd2i181qYWs/xHr6OreWRR02KqeKq6eZCSxdtR3/zcGVU/A0XytllgpRJlpiYkTZ+UMUbsPatAe8H6KSsPamghBhjappE+C1zXiwyV7TC6NKDk3pveLMqPwKOROvj2TOCPKcCCczV1i0rzOqmCZrZE/jjvfppA00KqpPQliKBPkMzsDRE5iUlz+NbtUYCFlj2rknfPb8ThbaWm5+pT0NDnyIAivNntrGT33RDjtFSctLKI76pD8PLbsdHeO3Q8/483N7wBZb3UnJxjDfu6jbpQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3f87YWe2fBKo9/43Z9KbdJav/wBrq3TN5EH95qm/TNo=; b=U+hXHb0Wp4wwvt0F8kx+/aMQYXbFgEJyFR2cOLUGmiaGr3d92Jdnicj5vZuPXqqCawdT92Owuk7ae/qKjMXd/rH9wFDOnrCcw5m6IzoHb/HnQAGqxmJ7lDWrGO0U6sfJQzbwet0YFMFlOl4UcewvIgjt4HvN/QaJty0dKNHhe6E= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB8P189MB0668.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:fd::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.17; Mon, 7 Dec 2020 17:35:36 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::c906:d500:5041:56fd]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::c906:d500:5041:56fd%9]) with mapi id 15.20.3632.023; Mon, 7 Dec 2020 17:35:36 +0000 To: "core@ietf.org WG (core@ietf.org)" Cc: dots@ietf.org From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: <263d6f84-4a57-2085-288f-068b1d78f7ae@ri.se> Date: Mon, 7 Dec 2020 18:35:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="733nuSFU4JnZFY0A3B6iw1sj3rJGFgSbU" X-Originating-IP: [45.83.91.172] X-ClientProxiedBy: HE1P195CA0012.EURP195.PROD.OUTLOOK.COM (2603:10a6:3:fd::22) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.2.6] (45.83.91.172) by HE1P195CA0012.EURP195.PROD.OUTLOOK.COM (2603:10a6:3:fd::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.17 via Frontend Transport; Mon, 7 Dec 2020 17:35:35 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c152c4d8-6583-40ef-302c-08d89ad6819b X-MS-TrafficTypeDiagnostic: DB8P189MB0668: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:4941; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: eo/kp/O1cVAbczPeqlkgc1XDVyUJHWIc7LZLUrKxZhW/JwbI85P42AB4N9+7tSNjMX9XyCQrTiCv+CUaYvk3OY9A7lgox8DziKoCHqZS/R7jdao5yxYTrWzWNm+OwSk3jhulc8KtgBMC5E77ciQ6/aZm+1NRBs2T407huwBlT7TdPoJKXFWB8iR93LbdUeVXywigsn1x0cu2VwYakK+5Cu7LyoBscr39A6j+3jyFnKDOry9K32XrB/0Vw1xwQwBbP40kztxP5WIIOLd3Ini+pH6uBJuLOVEXYEuKux4Br+NToFpA82BXxuVc/1cZxXS/jDq6TLTM/ufS9eTnnKXSXPJdrnJq9/7gbEayELYs6JEJs1NHbuOV8GP+pSt8o2EXiv2/pUxzpl1rkt1571Kk8EY8QfkNbskXpi2dh9F1ZRc8Cm2me6v415rP6fqf0t7u8YFsOOMFIqZmkPOvYkR9+KB6azrpaX1EDkGCeUkxgqo= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(376002)(366004)(396003)(39860400002)(136003)(346002)(26005)(66946007)(2616005)(478600001)(44832011)(31696002)(8936002)(235185007)(5660300002)(83380400001)(2906002)(8676002)(66556008)(66476007)(966005)(6916009)(956004)(186003)(33964004)(52116002)(21480400003)(31686004)(16526019)(36756003)(16576012)(6486002)(4326008)(450100002)(86362001)(316002)(6666004)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?dkpZUXRObFVkMHk0R0QxWUt6Y2NOTXBKNnhkV1ZId0xjenB6QzYrcW93eUQ4?= =?utf-8?B?WkFXNURrYXN6bTdRb1JIUjJ0NVFFWlk2MXdDWDdrZit6VnVMMzR1RXRadGdT?= =?utf-8?B?M3A5QlBZQnRGSFl3aUQrN3N2dFBPVGpFbDN5V3JwNisxc3dOM2l2Tk1UdEVD?= =?utf-8?B?UHllNzNBVnQyWFVrdDUvcGR0V3JuYlpqd3JsblNuTnYrcmJpZHNmOXAydFZo?= =?utf-8?B?YVI5QXJiTWkwTlhGYnUzY082TC9OZmRieDVsZE9xQVl4Y2dTejcxOFZCUmRU?= =?utf-8?B?Z2NLVEV5cm5zVGJCTzJnZUxuRHNxMjFiSmF5SHFvaHMrR1A0YWF0QTlJeTdU?= =?utf-8?B?dUgyU050WHk4ck5TTDdjRnlUMitkWTVKK3ltSW1vaHpHbzArZ0RETDFONmpY?= =?utf-8?B?bjR3aHQrUE5wTFpCM1YvTDdZTGdqRlR2K3hLQ0Y2MCtFaTIyOCtveWx6UVJl?= =?utf-8?B?bW9FeVU0WCtmRnQwT3JEckNpWHBQc3R6a2ljcHQvZCsvMEF4SEhPd1R3OFJJ?= =?utf-8?B?WXh3S2hzZnduM2Rxakdjd2p3OUV2Rk9XRDhWSk16VlRjUitOT3RJQkV2cGxS?= =?utf-8?B?VWxRdVZlODJvMzc1TS9EU21MdlJNR2t2Wll1LzJUeS9BdnhnZDBiTE9WUFYv?= =?utf-8?B?WU02R2pQR2JnOTNIdE5HYXJlK1FqMmNnWkNEb2xsVkYrOEtqTGNlSldvNDNQ?= =?utf-8?B?UzQxS3FaN0lQWGhRNCtKd2p2TDBrRjNqNTBPRnFVSTRFTWxGdExFRWU1cHpt?= =?utf-8?B?eWZ3ZHFaNTEycVVPL2lXM0ROVW5KdDVaVFB3RFFVK0RJaVVBbG00ZUcwUkRO?= =?utf-8?B?b2xuVUoweWs5ampXU1p0VmhiakVHS2lSOTlraFFjN2dQei9jd2tKVGRKcHZC?= =?utf-8?B?bVJUSUFYZUx1SDVMQ0ZEOUlDbVd2L05UNVp4RWErY2JrVWdUU1p2TjNoSTVZ?= =?utf-8?B?UXdQRFVzKzFvWlFIbzJuZGJjT0tySmpIM3JhenpFWFhsd0I4cE82QWdMQkxE?= =?utf-8?B?UGpNZjJSWnFOcHJkN29wMXV4QUxQYmwzNFZMbEFsQ2lyUXhlYS91TFZSdk8z?= =?utf-8?B?bFhDYVc4aHI2akdiK3pJY1I4NVRuSWJSbU9MWjFtREN0VDVHcCtucm9rVGxR?= =?utf-8?B?WEM2OThEQnlxampiYk5iaHpQc29HM0RwM2prSlNhNjhYYWJndjViczhzalhE?= =?utf-8?B?aER6M3BUWXdlb1lqVWhydlNPUnVhcU13dWdrYVJWQzhTRVhVUTdRM1BXdVpr?= =?utf-8?B?eStyVG03aHR4SHBGWFV1MFFGODMrS0NWRndJMzRvejR6Q0QwTE9xc01IZS9X?= =?utf-8?Q?vjwDqb7nz+6ywXXK18XzNk30rU/FGzvqon?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: c152c4d8-6583-40ef-302c-08d89ad6819b X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Dec 2020 17:35:36.2080 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: HhYWmRz78MTyFTnSbA7NMwqZr+vMAH2ulivs2MlQcOi0yVIdMdonchRyZzhFDKx6D8Tqgmzw1duxB5epfFhLAA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB0668 Archived-At: Subject: [core] WG Last Call on draft-ietf-core-new-block X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 17:35:43 -0000 --733nuSFU4JnZFY0A3B6iw1sj3rJGFgSbU Content-Type: multipart/mixed; boundary="E5Dt77EqPom0sUe5jaq6FcmvQyW8EnuTD" --E5Dt77EqPom0sUe5jaq6FcmvQyW8EnuTD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, Following the recent clarifications from the authors [1], this mail starts a Working Group Last Call on: https://tools.ietf.org/html/draft-ietf-core-new-block-02 This WGLC will end on Tuesday, 22nd of December. This WGLC is also copied to the DOTS WG mailing list. Best, Marco and Jaime [1] https://mailarchive.ietf.org/arch/msg/core/MJRxWldea5EOchYJRBOmkdvjiL= I/ --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --E5Dt77EqPom0sUe5jaq6FcmvQyW8EnuTD-- --733nuSFU4JnZFY0A3B6iw1sj3rJGFgSbU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl/OZ+AACgkQ7iZktA5Y 2kPuXgf/aWufiZvwjVgI+TFEXaA/HQ5R+aWjDkIrjD4IMMo2k/tLdYkqzg4DXI5V S+Gj+63BNae4y0Jc+FxhNFiNWu7fWOlODtSzjFXYfIMSZMI4AafJ7u/yTn2Oz/Vw AAkaZBjJnFYHtTf/nEF6SdSdTo+P2dfRUkXrOutJ5Q5ii3SfOxct3/iT/Mx1N0ip sO8SWNU18+FkhFwUONFgIRcWTihAC/xy+or0rYLBQrxx3krGeG3cOxC6+ocr9MTP 962Q36bKwfOdou2MpaHBwRhe0viawB0Xl1a3sragDoWYSHNzBdZe/i+aJnaFJSYz j7mHyb0pOGBVIuc2tXeBfDub5DyPVg== =UwCw -----END PGP SIGNATURE----- --733nuSFU4JnZFY0A3B6iw1sj3rJGFgSbU-- From nobody Mon Dec 7 14:10:04 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89BAB3A0B6D; Mon, 7 Dec 2020 14:09:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zj5NhsxGbsBf; Mon, 7 Dec 2020 14:09:56 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AD1D3A08A5; Mon, 7 Dec 2020 14:09:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 079B2389AE; Mon, 7 Dec 2020 17:12:02 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id C3tJ6VHbyshp; Mon, 7 Dec 2020 17:12:00 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 6591A389AD; Mon, 7 Dec 2020 17:12:00 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D559F48F; Mon, 7 Dec 2020 17:09:51 -0500 (EST) From: Michael Richardson To: EMU WG , "core\@ietf.org WG \(core\@ietf.org\)" , "ace\@ietf.org" In-Reply-To: References: <20201117234700.GR39170@kduck.mit.edu> , X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 22:09:59 -0000 --=-=-= Content-Type: text/plain Could someone point to a use case for "EAP over CoAP" please? Is the goal to key an OSCORE context, or what? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl/OqC8ACgkQgItw+93Q 3WXnwgf/SG6znSLD0QJqeBtDq+mimLEHlNuASPNBgFFSuZzKVrsm+Ce7uE4sRDcH 6bRnb8IEMJzI8vVxgeSwrlqXR/h8KxCVdQpl+OXW2A324I89NRLdh+5K4Ca71w+L N8GHVDDZpfOBR4H/RCBFe46a6ICGw8vZ88X902ByZRFSP/dCjYZm338IEoTLK5wI wHTlKPHQRBjIAB4BoHJ8gIhNSh+uy8ezPO0yPFWOGEgNl/NqE9QuWWzmZJYSvCEX f81PZl+WIhfhh6Bipi803+51FNTJ+bm/oY82X6NEzHFfSwnfhNLRxh/76Qa2t/Ng 2diDuzQcWZv+uW+23zLu1CaMtJlPaQ== =MZAX -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Dec 9 01:12:41 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4DB3A0F39; Wed, 9 Dec 2020 01:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=um.es 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 fYv96VnNQPAc; Wed, 9 Dec 2020 01:12:33 -0800 (PST) Received: from mx02.puc.rediris.es (outbound6sev.lav.puc.rediris.es [130.206.19.181]) (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 B3BA83A0F0C; Wed, 9 Dec 2020 01:12:32 -0800 (PST) Received: from xenon44.um.es (xenon44.um.es [155.54.212.171]) by mx02.puc.rediris.es with ESMTP id 0B99CPbp021756-0B99CPbq021756; Wed, 9 Dec 2020 10:12:25 +0100 Received: from localhost (localhost [127.0.0.1]) by xenon44.um.es (Postfix) with ESMTP id CCB8120307; Wed, 9 Dec 2020 10:12:25 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon44.um.es Received: from xenon44.um.es ([127.0.0.1]) by localhost (xenon44.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CIi5cFzplWi7; Wed, 9 Dec 2020 10:12:25 +0100 (CET) Received: from MacBook-Pro-de-Dan-2.local (unknown [217.113.247.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: dan.garcia@um.es) by xenon44.um.es (Postfix) with ESMTPSA id 4D8D7200BE; Wed, 9 Dec 2020 10:12:23 +0100 (CET) To: josh.howlett@gmail.com, =?UTF-8?B?J0fDtnJhbiBTZWxhbmRlcic=?= , 'Laurent Toutain' , 'Daniel Migault' Cc: 'EMU WG' , core@ietf.org, ace@ietf.org References: <20201117234700.GR39170@kduck.mit.edu> <0d6901d6ccb0$bd4c6860$37e53920$@gmail.com> From: Dan Garcia Message-ID: <0d537843-9a32-1c5b-daee-fe3491f20f6a@um.es> Date: Wed, 9 Dec 2020 10:12:22 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <0d6901d6ccb0$bd4c6860$37e53920$@gmail.com> Content-Type: multipart/alternative; boundary="------------D13B39E4D9006B8CDFA0DAFA" Content-Language: en-US X-FEAS-SPF: spf-result=pass, ip=155.54.212.171, helo=xenon44.um.es, mailFrom=dan.garcia@um.es Authentication-Results: mx02.puc.rediris.es; spf=pass (rediris.es: domain of dan.garcia@um.es designates 155.54.212.171 as permitted sender) smtp.mailfrom=dan.garcia@um.es X-FE-Policy-ID: 2:15:0:SYSTEM DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=um.es; s=DKIM; c=relaxed/relaxed; h=subject:to:cc:references:from:message-id:date:mime-version:content-type; bh=rGai90grn8HPwXUmb7cAgJ2fi/ZF8hOA5Dy5aKijN+w=; b=BlqofvlpRsnyLtUr/07cdZd1R+e3IZm14O8uMQIAozgOySSIC1il0lfI0UZ+GagQVjdpR93S4W3M oKAbx7a4kYdnETqvQZjCvmD820vkxqAXhkUf+1w0DiM9QOhFVrYTYLN6yFE/6Meau3SUSrgnmO2l trM19Ix96iYxR81oS5S+Q/FmLtxbL6IKY2HX4JnaWFnHQc97/GK8FvsZYzY8gr3bxEVpWATzbLT6 llIUR6202ZUuIRxtVGS/eyslymFPmkyG681m6LbNclc4yJJbMKhGZj2DSNvcptPQ3EHIc+O1wFVZ iHrJc/9TCPiuYHnTnhSF2OtgwHK3L1S7yGMbOw== Archived-At: Subject: Re: [core] [Emu] [Ace] Proposed charter for ACE (EAP over CoAP?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 09:12:37 -0000 This is a multi-part message in MIME format. --------------D13B39E4D9006B8CDFA0DAFA Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Josh, Thanks for the support. At first sight, I would say that, from the perspective of a very constrained devices and networks, it would be better to directly design an EAP lower-layer based on CoAP without introducing any intermediate layer. Best Regards, Dan. On 7/12/20 16:50, josh.howlett@gmail.com wrote: > > I support this; although I am curious in Dan’s opinion as to whether > GSS on top of CoAP is also worth considering, as a way of leveraging > the GSS EAP and other mechanisms (such as Kerberos). > > Josh > > *From:*Emu *On Behalf Of *Göran Selander > *Sent:* 07 December 2020 14:08 > *To:* Laurent Toutain ; Daniel > Migault > *Cc:* EMU WG ; core@ietf.org WG (core@ietf.org) > ; ace@ietf.org > *Subject:* Re: [Emu] [core] [Ace] Proposed charter for ACE (EAP over > CoAP?) > > +1. > > (The recently updated ACE charter should cover this work.) > > Göran > > On 2020-12-03, 20:03, "core" > wrote: > > Hi, > > I think it is important to have EAP on top of CoAP, as Dan said it fit > well with the last charter item. > > Laurent > > On Thu, Dec 3, 2020 at 2:20 PM Daniel Migault > > wrote: > > CCing emu, core > > It seems ACE to me that ACE could be home for such a document. I am > wondering if emu core or any other WG believe there is a better place > for it. > > Regarding ACE I am wondering what is the WG opinion about adding this > item to the ACE charter. > > Yours, > > Daniel > > ________________________________________ > > From: Ace > on > behalf of Dan Garcia > > > Sent: Thursday, December 3, 2020 6:10 AM > > To: ace@ietf.org > > > Subject: [Ace] Proposed charter for ACE (EAP over CoAP?) > > Dear all: > > Regarding the new charter, since ACE is considering the definition of > CoAP transport for CMPv2 > (https://tools.ietf.org/html/draft-msahni-ace-cmpv2-coap-transport-00 > ), > we were wondering whethere it could also consider specifying EAP > (Extensible Authentication Protocol) over CoAP. > > In this sense, we proposed this some time ago and we have > implementations about this. > > https://datatracker.ietf.org/doc/html/draft-marin-ace-wg-coap-eap-06 > > > https://www.mdpi.com/1424-8220/16/3/358 > > > https://www.mdpi.com/1424-8220/17/11/2646 > > > The usage of CoAP can provide a very light and link-layer independent > (we even tested in LoRa networks) EAP lower-layer (transport for EAP) > suitable for IoT enviroment. We believe this would be really useful > since EAP provides flexibility for the authentication and it is a > well-known protocol. > > Therefore, we would like to propose the following modification to the > charter: > > "The Working Group will examine how to use Constrained Application > Protocol (CoAP) as a transport medium for certificate enrollment > protocols, such as EST and CMPv2, as well as a transport for > authentication protocols such as EAP, and standardize them as needed." > > This modification does not necessarily mean the adoption of our draft. > After all, we completely understand that this would happen only if > there is an interest in the WG. Nevertheless, we would like to avoid > that the charter is a barrier later if there is interest in the WG to > work in this transport of EAP over CoAP: > > Any opinion about this? > > Best Regards. > > El 18/11/2020 a las 8:08, Daniel Migault escribió: > > Hi, > > Please find the proposed charter we agreed on during the interim > meeting. If you would like to propose any change, please use the > following URL by November 25: > > https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing > > > > > Yours, > > Daniel > > The Authentication and Authorization for Constrained Environments > (ace) WG has defined a standardized solution framework for > authentication and authorization to enable authorized access to > resources identified by a URI and hosted on a resource server in > constrained environments. > > The access to the resource is mediated by an authorization server, > which is not considered to be constrained. > > Profiles of this framework for application to security protocols > commonly used in constrained environments, including CoAP+DTLS and > CoAP+OSCORE, have also been standardized.  The Working Group is > charged with maintenance of the framework and existing profiles > thereof, and may undertake work to specify profiles of the framework > for additional secure communications protocols and for additional > support services providing authorized access to crypto keys (that are > not necessarily limited to constrained endpoints, though the focus > remains on deployment in ecosystems with a substantial portion of > constrained devices). > > In addition to the ongoing maintenance work, the Working Group will > extend the framework as needed for applicability to group > communications, with initial focus on (D)TLS and (Group) OSCORE as the > underlying group communication security protocols. The Working Group > will standardize procedures for requesting and distributing group > keying material using the ACE framework as well as appropriated > management interfaces. > > The Working Group will standardize a format for expressing > authorization information for a given authenticated principal as > received from an authorization manager. > > The Working Group will examine how to use Constrained Application > Protocol (CoAP) as a transport medium for certificate enrollment > protocols, such as EST and CMPv2, and standardize as needed. > > On Tue, Nov 17, 2020 at 6:47 PM Benjamin Kaduk > wrote: > > Thanks for updating the draft charter at [1], Daniel! > > I note that Michael raised the question of whether some other group might > > also be interested in working on CMP-over-coap, so the IESG will be > sure to > > discuss that if CMP is still in the draft ACE charter when it goes to the > > IESG for review. > > -Ben > > On Tue, Nov 17, 2020 at 06:16:48PM -0500, Daniel Migault wrote: > > > Thank you all for the feed backs. For the purpose of driving the charter > > > discussion at the IETf 109, I have added the comments into the proposed > > > text [1]. > > > > > > My current understanding is that it seems beneficial to add CMPv2 > over CoAP > > > in the charter. I am happy to be contradicted. > > > * I have not seen a clear cut to do one or the other. > > > * EST and CMPv2 are two protocols that can be used for enrollment or > cert > > > management while addressing different cases / needs / situations -- > maybe > > > we can clarify that point. I can see leveraging the existing CMP > > > infrastructure, but it seems that is not the only one. > > > * I am not convinced that not having CMP over CoAP will not prevent its > > > deployment and as such I prefer to have it standardized - this might > be a > > > personal thought. > > > * Adding any piece of work require cycles, but it seems to me that > CPM will > > > not have a major impact on the WG progress. The work will probably > include > > > other WG such a LAMPS. > > > > > > Yours, > > > Daniel > > > > > > [1] > > > > https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing > > > > > > > > > On Tue, Nov 17, 2020 at 6:02 PM Daniel Migault > wrote: > > > > > > > Hi Goran, > > > > > > > > I added the text to the charter we will discuss later. > > > > > > > > Yours, > > > > Daniel > > > > > > > > On Fri, Nov 13, 2020 at 10:26 AM Göran Selander < > > > > goran.selander@ericsson.com > > wrote: > > > > > > > >> Hi Daniel, > > > >> > > > >> > > > >> > > > >> Here’s another input to the charter. > > > >> > > > >> > > > >> > > > >> The current group key management solutions addresses the problem of > > > >> authorized access to group keys and public keys of group members. > > > >> > > > >> > > > >> > > > >> A related problem is authorized access of public keys of other > devices > > > >> not necessarily part of a security group, in the sense of sharing a > > > >> symmetric key used to protect group messages. > > > >> > > > >> > > > >> > > > >> Authorized access to raw public keys serves an important function in > > > >> constrained settings where public key certificates may not be > feasible due > > > >> to the incurred overhead, e.g. for when authenticating using EDHOC > > > >> (draft-ietf-lake-edhoc). > > > >> > > > >> This functionality is thus a subset of what is already supported, but > > > >> since the current solution is geared towards groups a different > solution > > > >> may be needed (although it is probably possible to reuse parts > from the > > > >> existing schemes for provisioning and requesting public keys). > > > >> > > > >> > > > >> > > > >> With this in mind, I propose the following change (highlighted in > > > >> boldface below): > > > >> > > > >> > > > >> > > > >> OLD > > > >> > > > >> The Working Group is charged with maintenance of the framework and > > > >> existing profiles thereof, and may undertake work to specify > profiles of > > > >> the framework for additional secure communications protocols > (that are not > > > >> necessarily limited to constrained endpoints, though the focus > remains on > > > >> deployment ecosystems with a substantial portion of constrained > devices). > > > >> > > > >> > > > >> > > > >> NEW > > > >> > > > >> The Working Group is charged with maintenance of the framework and > > > >> existing profiles thereof, and may undertake work to specify > profiles of > > > >> the framework for additional secure communications protocols *and > **for > > > >> additional **support services **providing* *authorized access to > crypto* *keys > > > >> *(that are not necessarily limited to constrained endpoints, > though the > > > >> focus remains on deployment ecosystems with a substantial portion of > > > >> constrained devices). > > > >> > > > >> > > > >> > > > >> Göran > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> On 2020-10-15, 19:50, "Ace" > wrote: > > > >> > > > >> Hi, > > > >> > > > >> I would like to start the charter discussion. Here is a draft of a > > > >> proposed charter [1]. > > > >> > > > >> > > > >> > > > >> It seems to be that additional discussion is needed with regard > to the > > > >> last paragraph related certificate management. In particular the > discussion > > > >> might revive a discussion that happened in 2017 [2] - when I was not > > > >> co-chair of ACE -and considered other expired work such as [3]. > Please make > > > >> this discussion constructive on this thread. > > > >> > > > >> > > > >> > > > >> The fundamental question is whether we need certificate management at > > > >> this stage. If the answer is yes, and we have multiple proposals, > it would > > > >> be good to clarify the position of the different proposals and > evaluate > > > >> whether a selection is needed or not before validating the charter. > > > >> > > > >> > > > >> > > > >> Please provide your inputs on the mailing list before October 30. Of > > > >> course for minor edits, you may suggest them directly on the > google doc. > > > >> > > > >> > > > >> > > > >> Yours, > > > >> > > > >> Daniel > > > >> > > > >> > > > >> > > > >> [1] > > > >> > https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing > > > > > > >> < > > > >> > https://protect2.fireeye.com/v1/url?k=4f3d9c3b-118c475b-4f3ddca0-86e2237f51fb-627e48b069462d70&q=1&e=6924b2a6-e7e5-4ec1-a1af-c94637953dc5&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing > > > > > >> > > > >> > > > >> [2] > > > >> > https://datatracker.ietf.org/doc/minutes-interim-2017-ace-03-201710191300/ > > > > >> > > > >> [3] https://datatracker.ietf.org/doc/draft-selander-ace-eals/ > > > > >> > > > >> > > > >> > > > >> -- > > > >> > > > >> Daniel Migault > > > >> > > > >> > > > >> > > > >> Ericsson > > > >> > > > > > > > > > > > > -- > > > > Daniel Migault > > > > Ericsson > > > > > > > > > > > > > -- > > > Daniel Migault > > > Ericsson > > > _______________________________________________ > > > Ace mailing list > > > Ace@ietf.org > > > https://www.ietf.org/mailman/listinfo/ace > > > _______________________________________________ > > Ace mailing list > > Ace@ietf.org > > https://www.ietf.org/mailman/listinfo/ace > > > -- > > Daniel Migault > > Ericsson > > _______________________________________________ > > Ace mailing list > > Ace@ietf.orghttps > ://www.ietf.org/mailman/listinfo/ace > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > > -- > > Laurent Toutain > > +--- VoIP (recommended) ---+----------- Télécom Bretagne -----------+ > > | Tel: +33 2 22 06 8156    | Tel: + 33 2 99 12 7026                 | > Visit :| Mob: +33 6 800 75 > 900    |                                        | > > | Fax: +33 2 22 06 8445    | Fax: +33 2 99 12 7030                  | > http://class.touta.in > > > > | Laurent@Touta.in | > Laurent.Toutain@Telecom-Bretagne.eu >     | > > +--------------------------+----------------------------------------+ > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu --------------D13B39E4D9006B8CDFA0DAFA Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi Josh,

Thanks for the support.

At first sight, I would say that, from the perspective of a very constrained devices and networks, it would be better to directly design an EAP lower-layer based on CoAP without introducing any intermediate layer.


Best Regards,
Dan.

On 7/12/20 16:50, josh.howlett@gmail.com wrote:

I support this; although I am curious in Dan’s opinion as to whether GSS on top of CoAP is also worth considering, as a way of leveraging the GSS EAP and other mechanisms (such as Kerberos).

 

Josh

 

From: Emu <emu-bounces@ietf.org> On Behalf Of Göran Selander
Sent: 07 December 2020 14:08
To: Laurent Toutain <Laurent.Toutain@telecom-bretagne.eu>; Daniel Migault <daniel.migault=40ericsson.com@dmarc.ietf.org>
Cc: EMU WG <emu@ietf.org>; core@ietf.org WG (core@ietf.org) <core@ietf.org>; ace@ietf.org
Subject: Re: [Emu] [core] [Ace] Proposed charter for ACE (EAP over CoAP?)

 

+1.

 

(The recently updated ACE charter should cover this work.)

 

Göran

 

On 2020-12-03, 20:03, "core" <core-bounces@ietf.org> wrote:

Hi,

I think it is important to have EAP on top of CoAP, as Dan said it fit well with the last charter item.

 

Laurent

 

 

On Thu, Dec 3, 2020 at 2:20 PM Daniel Migault <daniel.migault=40ericsson.com@dmarc.ietf.org> wrote:

 

 

CCing emu, core

 

It seems ACE to me that ACE could be home for such a document. I am wondering if emu core or any other WG believe there is a better place for it.

 

Regarding ACE I am wondering what is the WG opinion about adding this item to the ACE charter.

 

Yours,

Daniel

________________________________________

From: Ace <ace-bounces@ietf.org> on behalf of Dan Garcia <dan.garcia@um.es>

Sent: Thursday, December 3, 2020 6:10 AM

Subject: [Ace] Proposed charter for ACE (EAP over CoAP?)  

 

Dear all:

 

Regarding the new charter, since ACE is considering the definition of CoAP transport for CMPv2 (https://tools.ietf.org/html/draft-msahni-ace-cmpv2-coap-transport-00), we were wondering whethere it could also consider specifying EAP (Extensible Authentication Protocol) over CoAP.

 

In this sense, we proposed this some time ago and we have implementations about this.

 

 

The usage of CoAP can provide a very light and link-layer independent (we even tested in LoRa networks) EAP lower-layer (transport for EAP) suitable for IoT enviroment. We believe this would be really useful since EAP provides flexibility for the authentication and it is a well-known protocol.

 

Therefore, we would like to propose the following modification to the charter:

 

"The Working Group will examine how to use Constrained Application Protocol (CoAP) as a transport medium for certificate enrollment protocols, such as EST and CMPv2, as well as a transport for authentication protocols such as EAP, and standardize them as needed."

 

This modification does not necessarily mean the adoption of our draft. After all, we completely understand that this would happen only if there is an interest in the WG. Nevertheless, we would like to avoid that the charter is a barrier later if there is interest in the WG to work in this transport of EAP over CoAP:

 

Any opinion about this?

 

Best Regards.

 

El 18/11/2020 a las 8:08, Daniel Migault escribió:

 

 

Hi,  

Please find the proposed charter we agreed on during the interim meeting. If you would like to propose any change, please use the following URL by November 25:

 

 

 

Yours,

Daniel

 

The Authentication and Authorization for Constrained Environments (ace) WG has defined a standardized solution framework for authentication and authorization to enable authorized access to resources identified by a URI and hosted on a resource server in constrained environments.

The access to the resource is mediated by an authorization server, which is not considered to be constrained.

 

Profiles of this framework for application to security protocols commonly used in constrained environments, including CoAP+DTLS and CoAP+OSCORE, have also been standardized.  The Working Group is charged with maintenance of the framework and existing profiles thereof, and may undertake work to specify profiles of the framework for additional secure communications protocols and for additional support services providing authorized access to crypto keys (that are not necessarily limited to constrained endpoints, though the focus remains on deployment in ecosystems with a substantial portion of constrained devices).

 

In addition to the ongoing maintenance work, the Working Group will extend the framework as needed for applicability to group communications, with initial focus on (D)TLS and (Group) OSCORE as the underlying group communication security protocols. The Working Group will standardize procedures for requesting and distributing group keying material using the ACE framework as well as appropriated management interfaces.

 

The Working Group will standardize a format for expressing authorization information for a given authenticated principal as received from an authorization manager.

 

The Working Group will examine how to use Constrained Application Protocol (CoAP) as a transport medium for certificate enrollment protocols, such as EST and CMPv2, and standardize as needed.

 

 

 

 

On Tue, Nov 17, 2020 at 6:47 PM Benjamin Kaduk <kaduk@mit.edu> wrote:

 

 

Thanks for updating the draft charter at [1], Daniel!

 

I note that Michael raised the question of whether some other group might

also be interested in working on CMP-over-coap, so the IESG will be sure to

discuss that if CMP is still in the draft ACE charter when it goes to the

IESG for review.

 

-Ben

 

On Tue, Nov 17, 2020 at 06:16:48PM -0500, Daniel Migault wrote:

> Thank you all for the feed backs. For the purpose of driving the charter

> discussion at the IETf 109, I have added the comments into the proposed

> text [1].

>

> My current understanding is that it seems beneficial to add CMPv2 over CoAP

> in the charter. I am happy to be contradicted.

> * I have not seen a clear cut to do one or the other.

> * EST and CMPv2 are two protocols that can be used for enrollment or cert

> management while addressing different cases / needs / situations -- maybe

> we can clarify that point. I can see leveraging the existing CMP

> infrastructure, but it seems that is not the only one.

> * I am not convinced that not having CMP over CoAP will not prevent its

> deployment and as such I prefer to have it standardized - this might be a

> personal thought.

> * Adding any piece of work require cycles, but it seems to me that CPM will

> not have a major impact on the WG progress. The work will probably include

> other WG such a LAMPS.

>

> Yours,

> Daniel

>

> [1]

>

> On Tue, Nov 17, 2020 at 6:02 PM Daniel Migault <mglt.ietf@gmail.com> wrote:

>

> > Hi Goran,

> >

> > I added the text to the charter we will discuss later.

> >

> > Yours,

> > Daniel

> >

> > On Fri, Nov 13, 2020 at 10:26 AM Göran Selander <

> >

> >> Hi Daniel,

> >>

> >>

> >>

> >> Here’s another input to the charter.

> >>

> >>

> >>

> >> The current group key management solutions addresses the problem of

> >> authorized access to group keys and public keys of group members.

> >>

> >>

> >>

> >> A related problem is authorized access of public keys of other devices

> >> not necessarily part of a security group, in the sense of sharing a

> >> symmetric key used to protect group messages.

> >>

> >>

> >>

> >> Authorized access to raw public keys serves an important function in

> >> constrained settings where public key certificates may not be feasible due

> >> to the incurred overhead, e.g. for when authenticating using EDHOC

> >> (draft-ietf-lake-edhoc).

> >>

> >> This functionality is thus a subset of what is already supported, but

> >> since the current solution is geared towards groups a different solution

> >> may be needed (although it is probably possible to reuse parts from the

> >> existing schemes for provisioning and requesting public keys).

> >>

> >>

> >>

> >> With this in mind, I propose the following change (highlighted in

> >> boldface below):

> >>

> >>

> >>

> >> OLD

> >>

> >> The Working Group is charged with maintenance of the framework and

> >> existing profiles thereof, and may undertake work to specify profiles of

> >> the framework for additional secure communications protocols (that are not

> >> necessarily limited to constrained endpoints, though the focus remains on

> >> deployment ecosystems with a substantial portion of constrained devices).

> >>

> >>

> >>

> >> NEW

> >>

> >> The Working Group is charged with maintenance of the framework and

> >> existing profiles thereof, and may undertake work to specify profiles of

> >> the framework for additional secure communications protocols *and **for

> >> additional **support services **providing* *authorized access to crypto* *keys

> >> *(that are not necessarily limited to constrained endpoints, though the

> >> focus remains on deployment ecosystems with a substantial portion of

> >> constrained devices).

> >>

> >>

> >>

> >> Göran

> >>

> >>

> >>

> >>

> >>

> >>

> >>

> >> On 2020-10-15, 19:50, "Ace" <ace-bounces@ietf.org> wrote:

> >>

> >> Hi,

> >>

> >> I would like to start the charter discussion. Here is a draft of a

> >> proposed charter [1].

> >>

> >>

> >>

> >> It seems to be that additional discussion is needed with regard to the

> >> last paragraph related certificate management. In particular the discussion

> >> might revive a discussion that happened in 2017 [2] - when I was not

> >> co-chair of ACE -and considered other expired work such as [3]. Please make

> >> this discussion constructive on this thread.

> >>

> >>

> >>

> >> The fundamental question is whether we need certificate management at

> >> this stage. If the answer is yes, and we have multiple proposals, it would

> >> be good to clarify the position of the different proposals and evaluate

> >> whether a selection is needed or not before validating the charter.

> >>

> >>

> >>

> >> Please provide your inputs on the mailing list before October 30. Of

> >> course for minor edits, you may suggest them directly on the google doc.

> >>

> >>

> >>

> >> Yours,

> >>

> >> Daniel

> >>

> >>

> >>

> >> [1]

> >> <

> >>

> >>

> >> [2]

> >>

> >>

> >>

> >>

> >> --

> >>

> >> Daniel Migault

> >>

> >>

> >>

> >> Ericsson

> >>

> >

> >

> > --

> > Daniel Migault

> > Ericsson

> >

>

>

> --

> Daniel Migault

> Ericsson

 

> _______________________________________________

> Ace mailing list

 

_______________________________________________

Ace mailing list

 

 

 

 

 

--

Daniel Migault

 

Ericsson

 

 

 

 

_______________________________________________

Ace mailing list

Ace@ietf.orghttps://www.ietf.org/mailman/listinfo/ace

 

 

 

_______________________________________________

core mailing list

 

 

 

 

 

--

Laurent Toutain

+--- VoIP (recommended) ---+----------- Télécom Bretagne -----------+

| Tel: +33 2 22 06 8156    | Tel: + 33 2 99 12 7026                 | Visit :| Mob: +33 6 800 75 900    |                                        |

+--------------------------+----------------------------------------+


_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
--------------D13B39E4D9006B8CDFA0DAFA-- From nobody Wed Dec 9 03:46:23 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 610683A0658; Wed, 9 Dec 2020 03:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=um.es 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 YidiCvJBEEhX; Wed, 9 Dec 2020 03:46:16 -0800 (PST) Received: from mx02.puc.rediris.es (outbound4sev.lav.puc.rediris.es [130.206.19.178]) (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 B3BCE3A074B; Wed, 9 Dec 2020 03:46:02 -0800 (PST) Received: from xenon42.um.es (xenon42.um.es [155.54.212.169]) by mx02.puc.rediris.es with ESMTP id 0B9Bjxm6013240-0B9Bjxm7013240; Wed, 9 Dec 2020 12:45:59 +0100 Received: from localhost (localhost [127.0.0.1]) by xenon42.um.es (Postfix) with ESMTP id 6A55720076; Wed, 9 Dec 2020 12:45:59 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon42.um.es Received: from xenon42.um.es ([127.0.0.1]) by localhost (xenon42.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id oo1HUmQ_W-tB; Wed, 9 Dec 2020 12:45:59 +0100 (CET) Received: from [156.35.171.42] (unknown [156.35.171.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: dan.garcia@um.es) by xenon42.um.es (Postfix) with ESMTPSA id C846720A7D; Wed, 9 Dec 2020 12:45:57 +0100 (CET) To: Michael Richardson , EMU WG , "core@ietf.org WG (core@ietf.org)" , "ace@ietf.org" References: <20201117234700.GR39170@kduck.mit.edu> <24523.1607378991@localhost> From: Dan Garcia Message-ID: <3a4e4b59-3712-7eb9-23b2-8160ad14b6aa@um.es> Date: Wed, 9 Dec 2020 12:45:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <24523.1607378991@localhost> Content-Type: multipart/alternative; boundary="------------90636A2252E88A18749BC547" Content-Language: es-ES X-FEAS-SPF: spf-result=pass, ip=155.54.212.169, helo=xenon42.um.es, mailFrom=dan.garcia@um.es Authentication-Results: mx02.puc.rediris.es; spf=pass (rediris.es: domain of dan.garcia@um.es designates 155.54.212.169 as permitted sender) smtp.mailfrom=dan.garcia@um.es X-FE-Policy-ID: 2:15:0:SYSTEM DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=um.es; s=DKIM; c=relaxed/relaxed; h=subject:to:references:from:message-id:date:mime-version:content-type; bh=tHpbdjHn76FBnGsB0vLS2A1+onJtTV7cLkabrBjyyT0=; b=IBubtEs1ioN8BqhEJRmDy/DWZMUrZ4cSlBswAQ8friuwxEx67hWgylwtpD5T+Ko+0ZvBIL+2HFCx ea/joAuPc2QqPQLdne52YiJ5AE2faD8T7sd8ccL+VgkLwU7D7VWWMjrhstXGJ2BmlAiVfAah/lXK v5kskklaf0eaVJ+QZdxkiTJ1iWX2b66fX3htE73ouXi6hc5/ziQqaj0wIa1jPmd1+JDYx3zXVQo4 YZi2ZSpUmYChReUUrMK4/gHKa4yRJ03/+HPuMy7nDQjzeCbTXENxFDDhcmYZaQodMswEeBMapVpQ OfLaauoKFeyoDnE0W5t8xN9cQYL2MHq7yfujkw== Archived-At: Subject: Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 11:46:19 -0000 This is a multi-part message in MIME format. --------------90636A2252E88A18749BC547 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit  Hi Michael, EAP can be used in the context of IoT for authentication. To transport EAP from the IoT device we need a light EAP lower-layer. This would be CoAP. Morover, according to EAP key management framework, keys are exported to protect the link and the EAP lower-layer itself. So yes, OSCORE could be used for that kind of protection.  Another aspect, it is that the use case we consider is the case where an IoT device is trying to access a security domain under the control of a “controller†that is connected to a backend AAA infrastructure, which acts as EAP authenticator.  Best Regards. El 07/12/2020 a las 23:09, Michael Richardson escribió: > Could someone point to a use case for "EAP over CoAP" please? > Is the goal to key an OSCORE context, or what? > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | IoT architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --------------90636A2252E88A18749BC547 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

 Hi Michael,

EAP can be used in the context of IoT for authentication. To transport EAP from the IoT device we need a light EAP lower-layer. This would be CoAP. Morover, according to EAP key management framework, keys are exported to protect the link and the EAP lower-layer itself. So yes, OSCORE could be used for that kind of protection.

 Another aspect, it is that the use case we consider is the case where an IoT device is trying to access a security domain under the control of a “controller†that is connected to a backend AAA infrastructure, which acts as EAP authenticator.

 Best Regards.

El 07/12/2020 a las 23:09, Michael Richardson escribió:
Could someone point to a use case for "EAP over CoAP" please?
Is the goal to key an OSCORE context, or what?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [



_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
--------------90636A2252E88A18749BC547-- From nobody Wed Dec 9 04:12:23 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 299873A1406 for ; Wed, 9 Dec 2020 04:12:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.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 BKLUO0qDVMFF for ; Wed, 9 Dec 2020 04:12:19 -0800 (PST) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EA3D3A15A7 for ; Wed, 9 Dec 2020 04:12:18 -0800 (PST) Received: by mail-io1-xd36.google.com with SMTP id z136so1418428iof.3 for ; Wed, 09 Dec 2020 04:12:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IdwS2AYxqUbqCTETYcXGfH39TpPXB5KtlYgyptLZ+NU=; b=lbG0wr5WfAKXKli7CENaSBFrnf+KM4POhagUT8vLm2dX2AcXVdEFBxPQsuvPRhzZLT Sov4eCKIAisS1HIK3EfqDSswAgQnOhBdSG2iAFpjGAdjn7K9PjSHRWRhYBZkXYuszpYk r5GJcsdZNlKSn9OL4oDF9LCrd/yPeCvYOAbdNZhA3jD1mDEV4hsPTkqUI61bRcaS+1OA He5JxGKK7a/42nYeJFUIpjxEkdrPvQKHpxgs0Ls220AZOjXfJ0ByzCIuWB4FjuleoYLt yIgRTNLdpgHO9f6Lf1HkZhiVRSrEJCvICeK74v4oIvJ+06K9DZmadMAZVLimNswS5QI+ YCOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IdwS2AYxqUbqCTETYcXGfH39TpPXB5KtlYgyptLZ+NU=; b=P6Rc4WDwixIWWz23YSAdMxzHb4+eohBO2vs0FhtrgYY+DmlUnmzUJrnPwmW30cKWM/ 4xAeR+OlSWksLQdSDqo5M3ya3eONyGwtHC3pq4F3r3NIhPcWUaiXF6uYLFjtdjpOGwT8 hphmLYZS+nrbN+AlsVVBUWfRXrpcHz6T6giFXOaJiG/CKckIkmzZSUBd8PXufWg/9ROk BB18IQkhQHLIetgKBX1FjUOG7HTbYLZb29m+5NO7eHRfLGnXWXEUPx/2BaQpDSsu+qFE lUwHv2IJqpxoY3lsaMBdzSZCpPdSBHB8lal8JowFVm6rNEwrRmKUYn3SQdsWW7AHN5mX /wqg== X-Gm-Message-State: AOAM5317liYNVN6iOLLIPHthT+EwV+nin2DkmZvsUAMh4fRkz3INKkHP sK0MXr2q9ZvNFBbBNR19hK8NWHsvm/JGEI0AghzKTQ== X-Google-Smtp-Source: ABdhPJwJrHlQkjJYxxUoLKGn4EGOVzQt48jprs932YT2YtgMkbmfceMexO2ZMFbFC++SCEzu/xPFnD5y84aSHHPwONs= X-Received: by 2002:a5e:a614:: with SMTP id q20mr2493946ioi.198.1607515938109; Wed, 09 Dec 2020 04:12:18 -0800 (PST) MIME-Version: 1.0 References: <20201117234700.GR39170@kduck.mit.edu> <24523.1607378991@localhost> <3a4e4b59-3712-7eb9-23b2-8160ad14b6aa@um.es> In-Reply-To: <3a4e4b59-3712-7eb9-23b2-8160ad14b6aa@um.es> From: Alexander Pelov Date: Wed, 9 Dec 2020 13:12:06 +0100 Message-ID: To: Dan Garcia Cc: Michael Richardson , EMU WG , "core@ietf.org WG (core@ietf.org)" , "ace@ietf.org" Content-Type: multipart/alternative; boundary="000000000000764e5505b606f89b" Archived-At: Subject: Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 12:12:21 -0000 --000000000000764e5505b606f89b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear all, I support the inclusion of EAP-over-CoAP to the charter. We've done work on this particular item in the past, and we've identified the need for it in many places.. but unfortunately the draft didn't have a proper "home" and things never advanced much. Use-cases we've seen include places where EAP is a MUST, there is support for CoAP, but no support for the specific FOO technology. I am confident that it will bring value to the IOT ecosystem and that ACE is the right home for this draft. Cheers, Alexander On Wed, Dec 9, 2020 at 12:46 PM Dan Garcia wrote: > Hi Michael, > > EAP can be used in the context of IoT for authentication. To transport EA= P > from the IoT device we need a light EAP lower-layer. This would be CoAP. > Morover, according to EAP key management framework, keys are exported to > protect the link and the EAP lower-layer itself. So yes, OSCORE could be > used for that kind of protection. > > Another aspect, it is that the use case we consider is the case where an > IoT device is trying to access a security domain under the control of a > =E2=80=9Ccontroller=E2=80=9D that is connected to a backend AAA infrastru= cture, which acts > as EAP authenticator. > > Best Regards. > El 07/12/2020 a las 23:09, Michael Richardson escribi=C3=B3: > > Could someone point to a use case for "EAP over CoAP" please? > Is the goal to key an OSCORE context, or what? > > -- > ] Never tell me the odds! | ipv6 mesh netwo= rks [ > ] Michael Richardson, Sandelman Software Works | IoT architec= t [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails= [ > > > > _______________________________________________ > Ace mailing listAce@ietf.orghttps://www.ietf.org/mailman/listinfo/ace > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --000000000000764e5505b606f89b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

I support the inclusion of EA= P-over-CoAP to the charter.

We've done work o= n this particular=C2=A0item in the past, and we've identified the need = for it in many places.. but unfortunately the draft didn't have a prope= r "home" and things never advanced much. Use-cases we've seen= include places where EAP is a MUST, there is support for CoAP, but no supp= ort for the specific FOO technology.=C2=A0

I am co= nfident that it will bring value to the IOT ecosystem and that ACE is the r= ight home for this draft.

Cheers,
Alexan= der


On Wed, Dec 9, 2020 at 12:46 PM Dan Garcia <dan.garcia@um.es> wrote:
=20 =20 =20

=C2=A0Hi Michael,

EAP can be used in the context of IoT for authentication. To transport EAP from the IoT device we need a light EAP lower-layer. This would be CoAP. Morover, according to EAP key management framework, keys are exported to protect the link and the EAP lower-layer itself. So yes, OSCORE could be used for that kind of protection.

=C2=A0Another aspect, it is that the use case we consider is the case where an IoT device is trying to access a security domain under the control of a =E2=80=9Ccontroller=E2=80=9D that is connected to a = backend AAA infrastructure, which acts as EAP authenticator.

=C2=A0Best Regards.

El 07/12/2020 a las 23:09, Michael Richardson escribi=C3=B3:
Could someone point to a use case for "EAP over CoAP" =
please?
Is the goal to key an OSCORE context, or what?

--
]               Never tell me the odds!                 | ipv6 mesh network=
s [
]   Michael Richardson, Sandelman Software Works        |    IoT architect =
  [
]     mcr@sandelman.c=
a  http://www.sa=
ndelman.ca/        |   ruby on rails    [



_______________________________________________
Ace mailing list
Ace@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
--000000000000764e5505b606f89b-- From nobody Wed Dec 9 05:29:05 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0263A1662; Wed, 9 Dec 2020 05:28:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuP1SbdYUrh5; Wed, 9 Dec 2020 05:28:58 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F25523A165F; Wed, 9 Dec 2020 05:28:56 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 42040405E4; Wed, 9 Dec 2020 14:28:54 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 222A3AB; Wed, 9 Dec 2020 14:28:49 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:c33c:d942:e648:1b58]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id A74F3121; Wed, 9 Dec 2020 14:28:48 +0100 (CET) Received: (nullmailer pid 3020821 invoked by uid 1000); Wed, 09 Dec 2020 13:28:48 -0000 Date: Wed, 9 Dec 2020 14:28:48 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Daniel Migault Cc: Dan Garcia , "ace@ietf.org" , EMU WG , "core@ietf.org WG (core@ietf.org)" Message-ID: References: <20201117234700.GR39170@kduck.mit.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Qltm+pjmcyrMM91l" Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 13:29:00 -0000 --Qltm+pjmcyrMM91l Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello ACE, On Thu, Dec 03, 2020 at 01:20:08PM +0000, Daniel Migault wrote: > It seems ACE to me that ACE could be home for such a document. I am > wondering if emu core or any other WG believe there is a better place > for it. If nothing else, I'd be curious to see EAP-over-CoAP this sketched out; interactions with NOOB. (The "film a blinking LED to get mutual authentication" sounds particularly promising). Care would need to be taken to follow CoRE best practices (not that we'd have a good set of standard recommendations, but at least on concrete points we usually manage consensus), both because anything built on CoAP coming from the IETF will be seen as something of a reference example, and also to leverage its full optimization potential. CCs to core when this is put on the agenda for ACE interims might be a good idea. Go for it :-) Christian --=20 Es ist nicht deine Schuld, dass die Welt ist, wie sie ist -- es w=E4r' nur deine Schuld, wenn sie so bleibt. (You are not to blame for the state of the world, but you would be if that state persisted.) -- Die =C4rzte --Qltm+pjmcyrMM91l Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl/Q0Q0ACgkQOY0REtOk veH64RAAqrDBPD3rh/Ujl06z8ndBwoMCbAklVaDx+iGUga/P5xJ6QiN133BLNuf6 GnDqgFkYpYM13z0ULDpwMqXQn5hVs4Ra968ewqba91PgM7zRT4FEi5xU1CimAJia A/nF0iMTRComEXjLMP49lxdGFz0K3vWobk0ZcFTS2TImOQw9H7DHJyCpd6hRLIur 7TCnfl/K8TAg6qUEKdhNYdKphfN3YSZ1YFUU17rbtFo2N+ScYexeQtOoLYBcN8/c udhxjzMN5M3Rb0xW3nqElCjHK1YQ3h/05ZU4TrkK+f6s7aclwkjeflHK2ekIeVwG kW90fztJLlP3JwZ5Kfm8TD0u2uV0ivB+oY7AONLk4HdSw8sMB+86ep3kXzNZfcnT 55Cq/Od9MgiM0oNTxyHbjcd3lhWFhSUaYJNjB5YIFgfYJAPB+Bp6iclqtxnDzJT0 IZzzfkOaWeaYE5oOhofN83uLdcgI3vNlTtrM73jSwq3NnRt8YSgjhlqtst/EE8vn U5AilXQcYST/WMdSAaD88Vm90YCae6hIyz5X4hvHOprHWPo4P+xdSPUXZzlLOKDw 4DA/SRvZqepBGoReb3TUYTfrr2eYz7RobX/7bC0WaLvjQPtMtdr11rQDUwz1zxTl IseBmdYekIFDU7r+KZYG84QHHfps0ihxH4qsOt6+91iWUr5dFOI= =Sj7O -----END PGP SIGNATURE----- --Qltm+pjmcyrMM91l-- From nobody Wed Dec 9 05:52:18 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F22E3A15E9; Wed, 9 Dec 2020 05:52:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6xLbY-f1nTv; Wed, 9 Dec 2020 05:52:06 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAFB03A167C; Wed, 9 Dec 2020 05:52:05 -0800 (PST) Received: from [192.168.217.120] (p548dca87.dip0.t-ipconnect.de [84.141.202.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Crdl76FkgzyWv; Wed, 9 Dec 2020 14:52:03 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_0E56D933-F6F9-4C22-BE79-E15E6BAC0107"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: Date: Wed, 9 Dec 2020 14:52:03 +0100 Cc: Daniel Migault , "core@ietf.org WG (core@ietf.org)" , EMU WG , "ace@ietf.org" X-Mao-Original-Outgoing-Id: 629214722.587876-387e36a6e484afc88c7f36bee508ba06 Content-Transfer-Encoding: quoted-printable Message-Id: <09BDBA0F-9D18-4780-BAE5-BA7BE4405AA2@tzi.org> References: <20201117234700.GR39170@kduck.mit.edu> To: =?utf-8?Q?Christian_Ams=C3=BCss?= X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 13:52:11 -0000 --Apple-Mail=_0E56D933-F6F9-4C22-BE79-E15E6BAC0107 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 2020-12-09, at 14:28, Christian Ams=C3=BCss = wrote: >=20 > follow CoRE best practices Indeed; for instance, we =E2=80=9CRESTified=E2=80=9D documents in ACE = before (and they not just became ideologically correct, but also plain = better). Gr=C3=BC=C3=9Fe, Carsten --Apple-Mail=_0E56D933-F6F9-4C22-BE79-E15E6BAC0107 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEcr05t4NZlx5Xee/8VkscnDT509sFAl/Q1oIACgkQVkscnDT5 09vlvA/+L5IkPsKbuOh4pGPFInY2UoW9NPXxUlkw3NfVXuMQhkRPmUt3J+OUwpUv fOn1K5ebH/jjcWtS214ZBGbJWixIWn/2iDkVUUqfKLJ/Fn0GapRWX6KTmL+uMXLv z/NkIsjIP/wulPZbHbqMzw8upyz68T5OcT//SolkdkmJKXdAN0LMFutWem8kCG17 GjxJX47ZW8XfkNmWs6c8Rd/6wD41PjsCCu7nGQHRYeiys/CkY83jR21FMAbid2Gm GVcWY85DWKz9VbOCAkia41Msaj/z86m+i/byZDXcKT4rle+BiB3kmGDubBCWAJtQ FXLdahMgvlXTiE6RBqzTUGphlzdPZbXFzs0/sOWq5HHJJ5AzAlryyc8qimoXr2T3 c2mjKKlH1Sbw05QPPvZzYKcJ0UwRYPKrHm/MwdTr/ZqnRYGAspZFyURu6VdcMDNS bb5YUmlEjr4X/T9O96jyO4xl1Yx/6x9DmzEDuLKfHWyzQ2vd7SqpHhK9rziOWIwl KDxs2owITUWOQU5fSgINU8WmalNYu3MfG1LeuViPmfTRJC1UZVA+M02wPRlQ+Hn7 +w7Z+6R4Mip0xSxR07FR+3pTWxVYwLQkvxDVtIcRlN62KKCAS81HsVIjep2Q3yjU XfUJDyFRlF0HZKdl9qZqYXdlgGd0SxWBFI7YVkw2o8e2veHeVHc= =4EMO -----END PGP SIGNATURE----- --Apple-Mail=_0E56D933-F6F9-4C22-BE79-E15E6BAC0107-- From nobody Wed Dec 9 06:10:38 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C02D93A0D3B; Wed, 9 Dec 2020 06:10:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBuY6kSwsMOM; Wed, 9 Dec 2020 06:10:34 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DF703A0D39; Wed, 9 Dec 2020 06:10:32 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id C7F87405E4; Wed, 9 Dec 2020 15:10:29 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 0B445AB; Wed, 9 Dec 2020 15:10:29 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:c33c:d942:e648:1b58]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 75D8A121; Wed, 9 Dec 2020 15:10:28 +0100 (CET) Received: (nullmailer pid 3031680 invoked by uid 1000); Wed, 09 Dec 2020 14:10:28 -0000 Date: Wed, 9 Dec 2020 15:10:28 +0100 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: Ines Robles Cc: gen-art@ietf.org, core@ietf.org, draft-ietf-core-echo-request-tag.all@ietf.org, last-call@ietf.org Message-ID: References: <160693301574.8084.12485735068228324677@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Z44yBdR86IUfIOnF" Content-Disposition: inline In-Reply-To: <160693301574.8084.12485735068228324677@ietfa.amsl.com> Archived-At: Subject: Re: [core] Genart last call review of draft-ietf-core-echo-request-tag-11 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 14:10:36 -0000 --Z44yBdR86IUfIOnF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Ines, thanks for your comments. The expansions are done or WIP in our version, and will be part of the next editing iteration. > 2.- Figure 1 and Figure 4 have two columns named "U" (Unsafe), is that Ok= ?, or > should one of these columns be deleted/renamed? That's indeed unfortunate; given tables of this format are common in CoRE, I'll be checking back for the best course of action (but either way it's to be fixed). Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --Z44yBdR86IUfIOnF Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl/Q2scACgkQOY0REtOk veGcjRAArFFiH0/rQ1YB7G98prA7ocdqgOdxnUoAsXQXFR0B5xONaLrJFEfRT1pm muXa68UU484ZxtYc+C4GS4PuJJQp40Hg3hEMTefkGY09bj2b1Qn0ehSKzPC9h5a5 92MvDZ0+FecVYKjzm/LRz8ndSlZfVk/PEfGd2uoT4Rf6VK5P6KhCb5UL7Y02roSh iryUYjiOyB7OkeJUXCpl9lraSiU3RX9EXuOx5JIR7R14HiU2hwnHlg76C0obhu/H zr84Kwi5wzj/YpPCnf5g0NzhHZFF3ahyKiFJPe//JLYThtfpPXeV1Iwe8OQtlEvO pVxSJgQ0XxKVSHffoHX4ogoidO7KPulMDleauWemmWK7IHqN7jsOadvGkbaK9NOs b9aYwW5mABqmvdQp1o/ggkpEpGpOJwfxbJJNf6KiGLVsPJ7+8msEMWZenKhmxAZF xHu4it80y7xoKobDXuMaR1giDs7XaNhUS4K+qXJsZPOtmDdBk1NXrSjMA+IP6BOI Y4pgGVvt7ChG5HC9vwuKLnAHjHC3KOqmp5Fc4gyFxFmkwXi1MK3H6rkRNZBDkWLA RP2v3ylwQk4Yfzh7v/3K0Kviyds+zaVJLGIwbWvbJQqf1sy8/7rjCSp9+jsZPljw i61JTLg7GSag1q/Em/5QlQgYJgO5AYu2HSoRSsru1gKp4XAYSGY= =EhuP -----END PGP SIGNATURE----- --Z44yBdR86IUfIOnF-- From nobody Wed Dec 9 06:28:33 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7EDA3A16A1 for ; Wed, 9 Dec 2020 06:28:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9rMvpPBf9Bv for ; Wed, 9 Dec 2020 06:28:28 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B7D93A1663 for ; Wed, 9 Dec 2020 06:28:27 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id C9689405E4 for ; Wed, 9 Dec 2020 15:28:25 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id B239AAB for ; Wed, 9 Dec 2020 15:28:24 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:c33c:d942:e648:1b58]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 63C4F121 for ; Wed, 9 Dec 2020 15:28:24 +0100 (CET) Received: (nullmailer pid 3036685 invoked by uid 1000); Wed, 09 Dec 2020 14:28:23 -0000 Date: Wed, 9 Dec 2020 15:28:23 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Core WG mailing list Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4oNyC6Uz05ln9EP/" Content-Disposition: inline Archived-At: Subject: [core] Updated CoAP option template and OSCORE handling X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 14:28:31 -0000 --4oNyC6Uz05ln9EP/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello CoRE, it is custom so far with all RFCs that introduce CoAP options to summarize their options in a table like=20 +--------+---+---+---+---+-----------+--------+--------+---------+ | Number | C | U | N | R | Name | Format | Length | Default | +=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D+=3D=3D=3D+=3D=3D=3D+=3D=3D=3D+=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D= =3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D+ | 16 | | | | | Hop-Limit | uint | 1 | 16 | +--------+---+---+---+---+-----------+--------+--------+---------+ With OSCORE, its [table 5] introduces two more columns that, when plainly added, but their naming conflicts on "U" as noted in the Genart review[1]. As "how is this handled with object security" is a good thing to have at hand, I propose=20 +--------+---+---+---+---+-----------+--------+--------+---------+---+ | Number | C | U | N | R | Name | Format | Length | Default | O | +=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D+=3D=3D=3D+=3D=3D=3D+=3D=3D=3D+=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D= =3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D+ | 16 | | | | | Hop-Limit | uint | 1 | 16 | U | +--------+---+---+---+---+-----------+--------+--------+---------+---+ annotated as "O: OSCORE classification (U: unprotected)", and intend to use this with echo-request-tag (ERT). The practical alternative is to leave that information out of the table, and only have it present textually; I think that would make it harder for an implementer to grasp at one look how the option is supposed to behave. KR Christian PS. Yeah I know this is not something that needs WG-wide agreement on or would be binding for anyone registering an option, but still we can contribute to a consistent ecosystem here. [table 5]: https://tools.ietf.org/html/rfc8613#page-17 [1]: https://datatracker.ietf.org/doc/review-ietf-core-echo-request-tag-11-= genart-lc-robles-2020-12-02/ --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --4oNyC6Uz05ln9EP/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl/Q3wQACgkQOY0REtOk veEvRxAArJyAIvihXX5Ul8ibj+WFKRdQHv3XY2F5xpA/CjAApVm6Fh5RDjUO4srr BJ0hfVNvBM2m9As5twsrFK20PMO80oOvzBMpQsZk9vzz9r7DcR7Y9iwslrE2Txvp m3VRxVLGcf4wkel3dzNr4rhdonOhpji+V2Y5L7nxZPtYEGleuPl8Dhd2obE/6hEm i9fxZD9jRs6ydLyn+/80XrLHGWFEyb1ZzGeI4uMOvfLEpb09A4hn7jNL4Qnlp5sF xKns4eup+DHHlaoMxweEP+Y1QU0h+Qb6CJQuWn5LcAyV4fkx5K6f2UNXPJkYvH5/ eh/fAsQ+3rncGjFdH49Dble25tdeYNfUGkP6Cc9iy0Rq51GlKAgxEGbOGIL0EZE3 a16a22+9CDryJ4RA1Dc/+7nVwLcn9Iy5ii5JiLB8r4sN6K/3cDVgWmdIWzPPLitE +FCVulcwOqrwIo0j9CXSK34L44uG2a+ehfPPz7Evp6Veu9pkg6XrLu8uPfmycTsI wqJBK4GTnKLUjfneVzLc0Caie2uIZjvg/pdd7QH2Dr6RHurHsskMAhhlwWVYRC88 4D5sA3IILYxYFpdcFFDYvvADCUkdsGo/BnIjVFBT1aHuIQApEzuywHljLO6VQ53a ncSCUJq+aR/B2KraS/YckFnsTQgUTELXLtMUp4ogKBdXraj0bek= =3m5y -----END PGP SIGNATURE----- --4oNyC6Uz05ln9EP/-- From nobody Wed Dec 9 07:09:10 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719983A0DFF; Wed, 9 Dec 2020 07:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y83_ILhuDrnV; Wed, 9 Dec 2020 07:09:06 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81E083A0DEA; Wed, 9 Dec 2020 07:09:04 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id D85324060D; Wed, 9 Dec 2020 16:09:02 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 176ABAB; Wed, 9 Dec 2020 16:09:01 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:c33c:d942:e648:1b58]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id BD4E2121; Wed, 9 Dec 2020 16:09:00 +0100 (CET) Received: (nullmailer pid 3046429 invoked by uid 1000); Wed, 09 Dec 2020 15:09:00 -0000 Date: Wed, 9 Dec 2020 16:09:00 +0100 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: Joerg Ott Cc: tsv-art@ietf.org, draft-ietf-core-echo-request-tag.all@ietf.org, last-call@ietf.org, core@ietf.org Message-ID: References: <160686064132.16683.9970897893331887294@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HLmHlRRi8kfC71p2" Content-Disposition: inline In-Reply-To: <160686064132.16683.9970897893331887294@ietfa.amsl.com> Archived-At: Subject: Re: [core] Tsvart last call review of draft-ietf-core-echo-request-tag-11 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 15:09:09 -0000 --HLmHlRRi8kfC71p2 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello J=F6rg, Thank you for your review and your comments. > One question that arises is why these three quite distinct mechanisms fix= ing > different parts of the RFC 7252 are compiled into a single document. Effi= ciency, > yes, but otherwise, they don't seem to have much in common. The mechanisms also share common patterns in the attacks they prevent, and playing through scenarios of one mechsnism led to a better understanding of the others. It is hoped that the reader can use the mind set built up understanding the necessity for one mechanism leads to a better one on the others. > A question out of curiosity: in section 3.4, could a client easily exhaus= t server > resources if just sent many blocks and changed the Request-Tag on each of= them? No more than it can by addressing them to different resources (where the query parameter is part of the underlying identity) -- or even any made-up uncritical safe-to-forward option. CoAP servers that perform atomic processing typically have limited slots for these operations (either global, per resource or per client), and any later request invalidates the former's state. > Should sections 3.6 and 3.7 move to an appendix? They discuss design alte= rnatives. Question for these came up so frequently in discussions around the document that I think it's better here where it's visible. Happy to move it over if you or other commenters insist, but that should happen in awareness of the underlying questions' occurrence. > The last sentence in the second to last paragraph of section 1.1 has nest= ed brackets, > which may or may not be intentional. It's an unintentional occurrence which I'd -- now aware -- also make consciously to avoid extra prose that'd set aside the defining terms =66rom the accompanying remarks. The remaining nits have been addressed in the editors' copy, and will be part of the next version. Thanks again Christian --=20 You don't become great by trying to be great. You become great by wanting to do something, and then doing it so hard that you become great in the process. -- Marie Curie (as quoted by Randall Munroe) --HLmHlRRi8kfC71p2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIyBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl/Q6IkACgkQOY0REtOk veHD8Q/2Ix11UHurDU7zqDqfUKOB04ZB9IfeF5+prGs9Bd08MJ/RTLGwiAZ/hmns WiVuqW9AZhBDSKlySOrlyCsdMGo6AHULcXhZDn1Qrgn3QWLvv4XtIV+WQ8EUHsug DJHCYNgjzuSnGK6YjNx+qNj+39yiPPeahNbL2tmu7vWw5x9vNJt9Z60LwjuVShlf ruEHTDa8p/DbMpzbsZVjE4lSVel+8jH9g0U6vi4Dd7ehNfQk26awmXBV7zvD1DBv d4SVxfw1rlKdIhXKONEpnVwjYy32aN16aWmMo1bRg06rMM6jSDsFE/pzbiSKyq+m PYh6EIZrLJECzgb3w5AYVVTPLebiQq/8GKEtc7JOtnEnJx/BQDpjaF66cPEQH0md l0EQAksAVdAmrPGJtH3EpF8O2FkoTD69Gq9UjIvfniURgAlDCvJCghvQTRnR+JBT oMO9HulH1c81vpLkz/Th/Cwt3mSV51kfv1dtW5TW0ARIXmJcft5mG0ReSLrW7gB7 oNEuhNUF/FxE2F2rj3qwyPOBYnIlxzq70yjVMOFQGPqJE6vlzBoDvIO1i3P41vNM TpzjBOzSGkm0yLrPi6f5fVkEBoYooOOzOwsQu19IjkLxOBhV/VRpdxpvgMad7WDw ZcAp6PUkMbinUvebz4OhpWlBP5kJB8oS+zRgalvGfiZsfDmVXw== =gLqI -----END PGP SIGNATURE----- --HLmHlRRi8kfC71p2-- From nobody Wed Dec 9 09:42:13 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE1723A117F; Wed, 9 Dec 2020 09:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkYDebbnaPel; Wed, 9 Dec 2020 09:42:05 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.in.tum.de [131.159.0.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A28433A160E; Wed, 9 Dec 2020 09:42:02 -0800 (PST) Received: by mail.in.tum.de (Postfix, from userid 107) id EC9ED1C12CB; Wed, 9 Dec 2020 18:41:58 +0100 (CET) Received: (Authenticated sender: ott) by mail.in.tum.de (Postfix) with ESMTPSA id E357B1C121A; Wed, 9 Dec 2020 18:41:56 +0100 (CET) (Extended-Queue-bit tech_esegn@fff.in.tum.de) To: =?UTF-8?Q?Christian_M=2e_Ams=c3=bcss?= , Joerg Ott Cc: tsv-art@ietf.org, draft-ietf-core-echo-request-tag.all@ietf.org, last-call@ietf.org, core@ietf.org References: <160686064132.16683.9970897893331887294@ietfa.amsl.com> From: Joerg Ott Message-ID: <437bf045-8e8b-9870-d333-f4409d4537d2@in.tum.de> Date: Wed, 9 Dec 2020 18:41:56 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [core] Tsvart last call review of draft-ietf-core-echo-request-tag-11 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 17:42:08 -0000 Hi Christian, quick responses inline, none of my points were critical concerning the draft moving forward anyway. >> One question that arises is why these three quite distinct mechanisms fixing >> different parts of the RFC 7252 are compiled into a single document. Efficiency, >> yes, but otherwise, they don't seem to have much in common. > > The mechanisms also share common patterns in the attacks they prevent, > and playing through scenarios of one mechsnism led to a better > understanding of the others. It is hoped that the reader can use the > mind set built up understanding the necessity for one mechanism leads to > a better one on the others. Didn't build up in my mind, but since this is not really important for the spec I would not want to suggest any extensions for the introduction. Let's just move on. >> A question out of curiosity: in section 3.4, could a client easily exhaust server >> resources if just sent many blocks and changed the Request-Tag on each of them? > > No more than it can by addressing them to different resources (where the > query parameter is part of the underlying identity) -- or even any > made-up uncritical safe-to-forward option. CoAP servers that perform > atomic processing typically have limited slots for these operations > (either global, per resource or per client), and any later request > invalidates the former's state. Ok, thanks for confirming. >> Should sections 3.6 and 3.7 move to an appendix? They discuss design alternatives. > > Question for these came up so frequently in discussions around the > document that I think it's better here where it's visible. Does it require this level of visibility? It feels odd in this place. > Happy to move it over if you or other commenters insist, but that should > happen in awareness of the underlying questions' occurrence. It would make sense to move from the perspective of separating normative from background parts. One way of addressing the issue could also be reconsidering how to group second and third level subsections, so that these two are equal to the others. But, again, I don't feel strongly. >> The last sentence in the second to last paragraph of section 1.1 has nested brackets, >> which may or may not be intentional. > > It's an unintentional occurrence which I'd -- now aware -- also make > consciously to avoid extra prose that'd set aside the defining terms > from the accompanying remarks. > > > The remaining nits have been addressed in the editors' copy, and will be > part of the next version. Sounds good. Best, Jörg From nobody Wed Dec 9 10:55:58 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3648E3A16F9; Wed, 9 Dec 2020 10:55:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ck3Y2vIcFDeB; Wed, 9 Dec 2020 10:55:51 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C68D83A16F8; Wed, 9 Dec 2020 10:55:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 75E76389B6; Wed, 9 Dec 2020 13:58:04 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 63AalG54iDPk; Wed, 9 Dec 2020 13:57:59 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CA4E23897F; Wed, 9 Dec 2020 13:57:59 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 45DEA4CE; Wed, 9 Dec 2020 13:55:44 -0500 (EST) From: Michael Richardson To: Dan Garcia , EMU WG , "core\@ietf.org WG \(core\@ietf.org\)" , "ace\@ietf.org" In-Reply-To: <3a4e4b59-3712-7eb9-23b2-8160ad14b6aa@um.es> References: <20201117234700.GR39170@kduck.mit.edu> <24523.1607378991@localhost> <3a4e4b59-3712-7eb9-23b2-8160ad14b6aa@um.es> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 18:55:53 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dan Garcia wrote: > EAP can be used in the context of IoT for authentication. But, to what end? 1) If it is onboarding a new device, then there is no connectivity until af= ter authentication. so you can't use CoAP, you have to use 802.1x, or some equivalent, or create a system such as draft-ietf-6tisch-minimal-security. Which does use CoAP and OSCORE already. 2) If it for application authentication, then you need to use EAP to setup MSK for later use by a context. We do this in IKEv2, (D)TLS already. So the only left would be OSCORE, yet you write "could", as if it was an af= terthought. Tell me what is your application? What will be impossible if we don't do this work? =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl/RHbAACgkQgItw+93Q 3WUncggAtcaOylWEfd+IfdxcoXv2Lx97ZXXqQnCfrzofphRr/6hTgWymyfAURfbc AB+QQ3FVx7hMeqaGEt+kD0fNKxnZ73/5HyvfIjHajjz08lMc4CToZ41HEke7RN9Q kzeplxiOX64CqE+vzRBtWqAW0yAo7pV32BOHWrr3N9o2h9NVlMhw1zrMnZapArDQ g82zwn5TeUhejSpMkejaPJJlamI+eXrDAMkyZKl4pqK8UWp+lKO5Gbdvrur5ciRr rAN5p8hYwSRx8261FeCTaVcGV10EIc0HZD79wcOMMCVnn3cTbM27Rll9CY2HDNoB MazLl3K5ST5Hk1PyvtTgUq0amSMM3g== =p9mi -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Dec 10 00:09:12 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3AC3A0AC3; Thu, 10 Dec 2020 00:09:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eduYGrwwbvPW; Thu, 10 Dec 2020 00:08:57 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F4123A0A0B; Thu, 10 Dec 2020 00:08:57 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 407E0407D4; Thu, 10 Dec 2020 09:08:55 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id BCFB4AB; Thu, 10 Dec 2020 09:08:53 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:642c:420c:5b14:2e5b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 566CC121; Thu, 10 Dec 2020 09:08:53 +0100 (CET) Received: (nullmailer pid 3219219 invoked by uid 1000); Thu, 10 Dec 2020 08:08:53 -0000 Date: Thu, 10 Dec 2020 09:08:53 +0100 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: =?iso-8859-1?Q?J=FCrgen_Sch=F6nw=E4lder?= Cc: ops-dir@ietf.org, core@ietf.org, last-call@ietf.org, draft-ietf-core-echo-request-tag.all@ietf.org, Carsten Bormann Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DGIKj+bpvlHN5IrI" Content-Disposition: inline In-Reply-To: <03FA6734-BD39-4B6A-AD3A-2910325548D8@tzi.org> <160677720227.31587.6421946105112933351@ietfa.amsl.com> Archived-At: Subject: Re: [core] Opsdir last call review of draft-ietf-core-echo-request-tag-11 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2020 08:09:07 -0000 --DGIKj+bpvlHN5IrI Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello J=C3=BCrgen, On Mon, Nov 30, 2020 at 03:00:02PM -0800, J=C3=BCrgen Sch=C3=B6nw=C3=A4lder= via Datatracker wrote: > - The number of 152 bytes mentioned in section 2.4: >=20 > 3*152 would be 456 octets, I am not sure why this is the "typical > size of a frame on the wire sent across the Internet". Either > explain how you obtained this number of consider removing it in case > it does depend on assumptions that are not guaranteed to be always > true. One option could also be to simply drop this sentence. As Carsten pointed out, this is the derived number from the "three times" part, also accounting for the remainder of the UDP packet. Assuming an attacker wants to maximize the amplification possible by the factor 3, they will send * 14 octets Ethernet header * 40 octets IP header * 8 octets UDP header * 4 octets CoAP header * 8 octets of token allowsing the server to send =CE=A3 * 3 =3D 222 octets. Subtracting everyth= ing in the response including the UDP header, that gives 160 octets of UDP data. Given the token is variable length data of up to 8 octets the server implementer can't easily take into account, that leaves 152 octets. (Granted, that last step doesn't follow from the wording, and I'm looking to sharpen that). Having some hard number there (and I'm happy to use better ways to come up with one) is important because for generic server applications, the transports may not be known and the implementer would have to make assumptions; we can't do much more, but at least ours get solid review. On Tue, Dec 01, 2020 at 01:22:45AM +0100, Carsten Bormann wrote: > The number to be explained is not so much the 152 (the exact value of > which I don=E2=80=99t really understand), but the three. That's the factor that QUIC is accepting[1]: > Prior to validating the client address, servers MUST NOT send more > than three times as many bytes as the number of bytes they have > received. This limits the magnitude of any amplification attack that > can be mounted using spoofed source addresses. [1]: https://tools.ietf.org/html/draft-ietf-quic-transport-32#page-50 I've aked back at the QUIC authors about where they took their three =66rom -- either we can reference that; otherwise, just cite the WIP QUIC as best currently available source. > - The difference between Figure 2 and Figure 3 is rather subtle. >=20 > I actually diffed the figures to find it. My understanding is that > it is really only the labels t0 and t1 and e0 and e1. One could > perhaps change the figures to make it more explicit when t0 (e0) > take place, perhaps also clarifying the text a bit. There is perhaps > some confusion caused by the notion of time t0, t1, the notion of > events e0, e1, and the notion of tag values labeled (t0) and (e0). > The text says "The server verifies freshness by checking that e0 > equals e1, where e0 is the cached value when the Echo option value > was generated, and e1 is the cached value at the reception of the > request." I found this confusing. It think what you are trying to > say is that the tag value cached at event e0 is the same as the tag > value received at event e1, no? That's good input; we're going through a few versions among the authors for the precise visual alignment and wording. Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --DGIKj+bpvlHN5IrI Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl/R15UACgkQOY0REtOk veFJJQ/8Cg2x3mCTXrjJT7zHtdHtu4q1iutMDaJDb5cxeu3S16rhPJ33YqRXHYPJ 7/tEmhqhvfc8N+mcx8lebzWH694GeeawMihUGjTfhMTUE+1m5pKrZ79vxA5Sxhlz Vr3s35u930s6T7ec+PwiNP3HqmtGwhDCpUzAqBP/jVz+fPuO5NXiPNaXMC5Wda6J HW/ogJ0eCGP9nbZamZatvH9iDuuDc0FneGIA8+NZaOQ2oLAVY+xD9TR7ykZ+P11v jDdNJeURJ+MFzOC3BQxR66fxbDnJ7CMjXQlF+Rx9/pqrSJzyTIOnlUHUpPqloVED PygXVkyLhE6mNQUehPr4780nkrUMEUBxB5YygpFTXGvRdGSiBAar9NPV+fNf+SAp saYOFPZUTFMOAPByL/NhhR9Tj7D9pUh+PUm+xa1S4HEBnr55VLb01S6HUf3z4UyC n6CdSkW2WZ/RH+DVSP8ps/bjITMN8A/ORjjFJY4XRL+hJycQFZwAoTETk417n1Qx OCQsiQIT9l4xKXfJAVwyNcYZ1z7+uy1NzTRObqfKvL9JHkNTD6sNPypXdo7/O8Uq hJYV8HItcItYI4WDbnpP2r2zAe3X7R15rgYOW/+tW11v0z/9aVvboFr6SUfKTHk0 OVk5ykG1ng7CkEH6mqPCGKwrm6rQAXWMLSl9qyfPlb+hu0yn0Gc= =b81G -----END PGP SIGNATURE----- --DGIKj+bpvlHN5IrI-- From nobody Thu Dec 10 00:32:56 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423C93A0AC5; Thu, 10 Dec 2020 00:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRkz8oDIxoXa; Thu, 10 Dec 2020 00:32:52 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A91D13A0AC4; Thu, 10 Dec 2020 00:32:51 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 41A0382D; Thu, 10 Dec 2020 09:32:49 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.198]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id zlWwXWGNIQmT; Thu, 10 Dec 2020 09:32:49 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 10 Dec 2020 09:32:48 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id B7B6720156; Thu, 10 Dec 2020 09:32:48 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id pYAKELm2L3s7; Thu, 10 Dec 2020 09:32:48 +0100 (CET) Received: from localhost (anna.jacobs.jacobs-university.de [10.50.218.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by hermes.jacobs-university.de (Postfix) with ESMTPS id 1817220154; Thu, 10 Dec 2020 09:32:48 +0100 (CET) Date: Thu, 10 Dec 2020 09:32:47 +0100 From: Juergen Schoenwaelder To: Christian =?utf-8?Q?M=2E_Ams=C3=BCss?= Cc: ops-dir@ietf.org, core@ietf.org, last-call@ietf.org, draft-ietf-core-echo-request-tag.all@ietf.org, Carsten Bormann Message-ID: <20201210083247.obamjgn7sjcu56r2@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Christian =?utf-8?Q?M=2E_Ams=C3=BCss?= , ops-dir@ietf.org, core@ietf.org, last-call@ietf.org, draft-ietf-core-echo-request-tag.all@ietf.org, Carsten Bormann References: <03FA6734-BD39-4B6A-AD3A-2910325548D8@tzi.org> <160677720227.31587.6421946105112933351@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] Opsdir last call review of draft-ietf-core-echo-request-tag-11 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2020 08:32:54 -0000 Hi, I have no strong opinion whether having a fixed number is good or bad, I can see reaons both ways. But if the WG decides to include an absolute number and you want people to implement that number, you should in my view include the calculation (perhaps in a short appendix) so that people recall how the number was determined. For example, you assume IPv4 (and not IPv6), you assume Ethernet (and not some other link layers or VLANs etc.). This may be OK but I think it is fair to document the assumptions. /js On Thu, Dec 10, 2020 at 09:08:53AM +0100, Christian M. Ams=C3=BCss wrote: > Hello J=C3=BCrgen, >=20 > On Mon, Nov 30, 2020 at 03:00:02PM -0800, J=C3=BCrgen Sch=C3=B6nw=C3=A4= lder via Datatracker wrote: > > - The number of 152 bytes mentioned in section 2.4: > >=20 > > 3*152 would be 456 octets, I am not sure why this is the "typical > > size of a frame on the wire sent across the Internet". Either > > explain how you obtained this number of consider removing it in cas= e > > it does depend on assumptions that are not guaranteed to be always > > true. One option could also be to simply drop this sentence. >=20 > As Carsten pointed out, this is the derived number from the "three > times" part, also accounting for the remainder of the UDP packet. >=20 > Assuming an attacker wants to maximize the amplification possible by th= e > factor 3, they will send >=20 > * 14 octets Ethernet header > * 40 octets IP header > * 8 octets UDP header > * 4 octets CoAP header > * 8 octets of token >=20 > allowsing the server to send =CE=A3 * 3 =3D 222 octets. Subtracting eve= rything > in the response including the UDP header, that gives 160 octets of UDP > data. Given the token is variable length data of up to 8 octets the ser= ver > implementer can't easily take into account, that leaves 152 octets. > (Granted, that last step doesn't follow from the wording, and I'm > looking to sharpen that). >=20 > Having some hard number there (and I'm happy to use better ways to come > up with one) is important because for generic server applications, the > transports may not be known and the implementer would have to make > assumptions; we can't do much more, but at least ours get solid review. >=20 > On Tue, Dec 01, 2020 at 01:22:45AM +0100, Carsten Bormann wrote: > > The number to be explained is not so much the 152 (the exact value of > > which I don=E2=80=99t really understand), but the three. >=20 > That's the factor that QUIC is accepting[1]: >=20 > > Prior to validating the client address, servers MUST NOT send more > > than three times as many bytes as the number of bytes they have > > received. This limits the magnitude of any amplification attack that > > can be mounted using spoofed source addresses. >=20 > [1]: https://tools.ietf.org/html/draft-ietf-quic-transport-32#page-50 >=20 > I've aked back at the QUIC authors about where they took their three > from -- either we can reference that; otherwise, just cite the WIP QUIC > as best currently available source. >=20 > > - The difference between Figure 2 and Figure 3 is rather subtle. > >=20 > > I actually diffed the figures to find it. My understanding is that > > it is really only the labels t0 and t1 and e0 and e1. One could > > perhaps change the figures to make it more explicit when t0 (e0) > > take place, perhaps also clarifying the text a bit. There is perhap= s > > some confusion caused by the notion of time t0, t1, the notion of > > events e0, e1, and the notion of tag values labeled (t0) and (e0). > > The text says "The server verifies freshness by checking that e0 > > equals e1, where e0 is the cached value when the Echo option value > > was generated, and e1 is the cached value at the reception of the > > request." I found this confusing. It think what you are trying to > > say is that the tag value cached at event e0 is the same as the tag > > value received at event e1, no? >=20 > That's good input; we're going through a few versions among the authors > for the precise visual alignment and wording. >=20 > Best regards > Christian >=20 > --=20 > To use raw power is to make yourself infinitely vulnerable to greater p= owers. > -- Bene Gesserit axiom --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Dec 10 01:04:50 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6123A0B5C; Thu, 10 Dec 2020 01:04:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=unioviedo.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 9M3mWrLhlLFZ; Thu, 10 Dec 2020 01:04:41 -0800 (PST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2057.outbound.protection.outlook.com [40.107.22.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 830FE3A0BD4; Thu, 10 Dec 2020 01:04:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lOrH+iC6zsTINTnEGc2R1JLVBKRbbw3fAy8Z+J81CEy5EVB31J+3RxKamqHjg9cVtRTMZPpJwpC+1o9/eD1ANCcQRflz8/cqCI2TLdBZw3G//Ocsakot8Ba0C9dU/cc16Oqkf5lNYTm0gAFCtM47ov9TMZotD394EFmWy9OpZsd/5yscJT2o2U4LRiCiv3g9wwraTotRfqF/N2dgFI0K2T5IW+U7Gkf3+7t9dko9IyFIN1EjBL0oz9g4DTj0jpfdGAcTfDZD8W/lKQBWWK0IbOQMKnwo3U23buVBa86w7+eaaS+KXxTNG9bTx8Sfhm12chGrn5nYltrDTvWCtO5buw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OnfGbTkulmuLihmoksCO/OLgtd+sfEb2/TAQC55Zlu0=; b=OuyHdwAyiKBwNnLpJ7JAxKLqEEsPRe4fHVVvYFiZkvSK4WGHPQ3pMDZFPQTJdOReHQiVDKpUQdVeFcyqTminxhfDYoC5jnRGPFAirdoc11gngUOebUhKefQCvtrJD43XpYMMocrdmXgWl8fX165c6m4TdkBGhPJDay1jehjdH2A3wdDLf3pgXZD0Tj0T2b33KH8y/r786KRXxFjLsMe2ouqknKyGBI/QOF/Gv9ilzdaSf/UnN5XmErk7XNgBAVfJ8WdjDpIAVVWDgFeFcJ+tkmOUXnh8qAkEoglhFhE6AgyGc4+N43oJJdIIh3W6Bk482i1MlzsZsHsBYDoShFWh6A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uniovi.es; dmarc=pass action=none header.from=uniovi.es; dkim=pass header.d=uniovi.es; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unioviedo.onmicrosoft.com; s=selector2-unioviedo-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OnfGbTkulmuLihmoksCO/OLgtd+sfEb2/TAQC55Zlu0=; b=xM7ALbuqMJ4vw9cXMMtB7FgHAg3ZM/VzsD3O+eEFllMFtJqaZ7qyUG8mvKHsnkzmen9XKRAga1DPjgnMhcYIWijsrAfwLUq5jtzFTQrTwpE9FyjJkXCjFu4foqc3s6oEELomLwiWqy1IFPd4MRzptBE6A3bClbN+kjEG2Gi68R4= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=uniovi.es; Received: from AM0PR08MB3940.eurprd08.prod.outlook.com (2603:10a6:208:124::19) by AM0PR08MB3442.eurprd08.prod.outlook.com (2603:10a6:208:d7::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.21; Thu, 10 Dec 2020 09:04:30 +0000 Received: from AM0PR08MB3940.eurprd08.prod.outlook.com ([fe80::9c65:30a3:58fe:e6dd]) by AM0PR08MB3940.eurprd08.prod.outlook.com ([fe80::9c65:30a3:58fe:e6dd%7]) with mapi id 15.20.3654.012; Thu, 10 Dec 2020 09:04:30 +0000 To: Michael Richardson , EMU WG , "core@ietf.org WG (core@ietf.org)" , "ace@ietf.org" References: <20201117234700.GR39170@kduck.mit.edu> <24523.1607378991@localhost> <3a4e4b59-3712-7eb9-23b2-8160ad14b6aa@um.es> <2923.1607540144@localhost> From: Dan Garcia Message-ID: <62dad652-8acd-0890-36cd-f7aacde19de2@uniovi.es> Date: Thu, 10 Dec 2020 10:04:28 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 In-Reply-To: <2923.1607540144@localhost> Content-Type: multipart/alternative; boundary="------------2CC5B6F2F9AC00C1F41295BD" Content-Language: en-US X-Originating-IP: [217.113.247.231] X-ClientProxiedBy: MR2P264CA0038.FRAP264.PROD.OUTLOOK.COM (2603:10a6:500::26) To AM0PR08MB3940.eurprd08.prod.outlook.com (2603:10a6:208:124::19) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from MacBook-Pro-de-Dan-2.local (217.113.247.231) by MR2P264CA0038.FRAP264.PROD.OUTLOOK.COM (2603:10a6:500::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.21 via Frontend Transport; Thu, 10 Dec 2020 09:04:30 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 334aa923-eabf-4ee8-c107-08d89cea9af3 X-MS-TrafficTypeDiagnostic: AM0PR08MB3442: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: S2Yi7b6yueEBsKGHbEb+ce5vUltyn2p3X1QQpEe4sogOUNn2c67CGTb/PSppw6TfZI3FiPlvpkKVhEG6aihoNdhsdUhMf9/qkwhxIWWfPeVFI28j2SaGe7eLfIlPYeVY0YXgaoYnOP36L8VBA9uYs3FVhH8PRwhi578TiCwcvFDlJoGHauVmqZLCtqlad6BhS3y82LAbCylYHtuxijHnsylFqEF1/VlsrGnJYufJBayjmySLw/CFTkwpZpSQCLkmlzLbUWwItf0JDjeU5+CVoSfksI9iaobUTYkDkX//rIq2S6BbKt3dYhDo0SQAzvjZD6QB4ZKv9m7hXx9M97cqgWvmrHUc1s1oucuSigSqjv1A/eXsU+iuBhUu16Oye5iZd6iPfsQt/2h5i/iL3hXjvOl5ihyYFotu4rY6Ez/sTmE= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3940.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(366004)(346002)(136003)(786003)(508600001)(66946007)(8936002)(66556008)(36756003)(956004)(31696002)(66574015)(110136005)(83380400001)(86362001)(66476007)(2616005)(186003)(2906002)(8676002)(16526019)(52116002)(33964004)(26005)(6506007)(53546011)(6486002)(31686004)(6512007)(5660300002)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?SGZBdzZiVHhqRGd5VHNxOW9POWlRU3lUTSs0UUt0dy9uZkNOMVRCc3BBTjZz?= =?utf-8?B?bXBvdndRMkl1V1BQYUJBYjZ3ekdNOXBmYUlUcDI0bmFFRDZhaXloeWl4d3lv?= =?utf-8?B?eEpQUzNheWFKOHE2QmdJVDBEN1QyelJkNTU4T3gza3ByZTRLWmRZVUQyR25R?= =?utf-8?B?YU11eS9XcmRkZlhQeldjTHF6UlB6YUE5a3VMaUdOTFRiVk5xL0VCaHIxTGkz?= =?utf-8?B?ZkRDV0l4MytyZjVZTWNRbllFUWdPNEQ2SU9hUnJQZEMzOFVibEQxZW9yYU5u?= =?utf-8?B?TFpFVEhTVnVZNFFSRDlNVjJLZTd2MTlpanI2YXpLWWFVTTJ2NHpSTUtnVkZD?= =?utf-8?B?SHh6cUpvdk5xQms3RURvN3RxakFoOFhSR2dZZThhV1p4RXFqWEE1WEtmR1ox?= =?utf-8?B?ZVRGeXpMb0JwdWUxeENYTnU1OVZCbGF0eUY2czFBa2s4Njh4WCs5eHF1VVdo?= =?utf-8?B?UzEzZUViVnZVT2UyaUxnL0ZqbGlMQkhhTnZsbi81NUU3emZCWWtHOUVnTC9q?= =?utf-8?B?RGYwcjljc1lNaE1nVzF5VFhsbmtCa3dXNC9TMzRpQWwwaGJtQUZzVkVEeWFk?= =?utf-8?B?SE9zMVhsYTRBaW8xTmdDdHB2cTNRcHFBTGZiSFd4eHFJbVMrck1GdGgyK0po?= =?utf-8?B?MUw0dWxMc2kwQWhGYmRrWWxuc05iSE5qYWYwUkI5TC9UNktibDRtUHoxZ3da?= =?utf-8?B?QWkvSHZwOWRlK0h6aGYyUHpXd25qeFZoOVlqUnU2OUo2Z3h1VFdRRGVDNVBl?= =?utf-8?B?NnBReDFVNEtoS3o0SEJZcDd2M0luYzFLZWZrd2lYaXlORnJ0QW0wclVhQUhT?= =?utf-8?B?dVFHYzVubE5ndGJra2JYWWo3dUhZUFFqdGZNdUdOdGI3ei9pM0p4aXlNTzB0?= =?utf-8?B?alJnL2hrcDdKUUtmcFFCMmZiN1NHTE0ySVBPUXN5akYzQldwK0RhbFoyVlVr?= =?utf-8?B?STdURFdUeExicjc1enRtYjZpdnQvUXVlZ3FxUnNRU2pZakZYUXZBR2pUTzQr?= =?utf-8?B?QkswTEk5aDZvZ1VOTTRQc0h0aEN1ODljNnlibnRwM0RmNjFUSUZzL0wzSVRa?= =?utf-8?B?RGNHYlNuUktSTjREckxxUEg0Z0x5SEtGOEl0QjBoZnJMaHZaWUV5OWptdHZn?= =?utf-8?B?dkhPRFNtL29pN0VwR0ZRZzhpK3RKOHdhUVlkL05YT3AyNVFEN1c5QnF2VDQx?= =?utf-8?B?b0Y4V1dZMEtHS2c2MWdaZ3RVMXkxcGxCeG9Qc0pleFlyRlAyQnlUZmRyWm1o?= =?utf-8?B?Um92Smp4ZTVkQUw2d1JsYktSeGVOTmdscWFNalpQTzJvQnpMenlpMUo5VDhJ?= =?utf-8?Q?4O9mN+TakpnFSlGeNgkGAWHJV3OV99lb85?= X-OriginatorOrg: uniovi.es X-MS-Exchange-CrossTenant-AuthSource: AM0PR08MB3940.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Dec 2020 09:04:30.7752 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 05ea74a3-92c5-4c31-978a-925c3c799cd0 X-MS-Exchange-CrossTenant-Network-Message-Id: 334aa923-eabf-4ee8-c107-08d89cea9af3 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: rcxUgXGXEw3qEBLvXbYQLkHrfxaYmfPcCzA+LugC9B0TMYqCFUE6iFWxXz9BBeUNl87Il3S3vPFLiXxerBctow== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3442 X-MS-Exchange-CrossPremises-AuthSource: AM0PR08MB3940.eurprd08.prod.outlook.com X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 06 X-MS-Exchange-CrossPremises-Mapi-Admin-Submission: X-MS-Exchange-CrossPremises-MessageSource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-OriginalClientIPAddress: 217.113.247.231 X-MS-Exchange-CrossPremises-TransportTrafficType: Email X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-Processed-By-Journaling: Journal Agent X-OrganizationHeadersPreserved: AM0PR08MB3442.eurprd08.prod.outlook.com Archived-At: Subject: Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2020 09:04:44 -0000 --------------2CC5B6F2F9AC00C1F41295BD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit  Hi Michael, "/1) .../" For onboarding a new device, where there is no connectivity after authentication, you propose to use 802.1X, which is an EAP lower layer. EAP over CoAP is in fact a proposal for a application level EAP lower layer that overcomes the limitation that 802.1X works on an inferior layer, hence, giving the possibility to perform the network authentication through nodes. This idea is not new, in fact, you have PANA, another EAP lower layer that works on top of UDP. As you comment , draft-ietf-6tisch-minimal-security - offers minimal security and has several deficiencies that can be solved by using EAP and AAA infrastructures. Regarding your second point "/2) If it for application authentication, then you need to use EAP to setup MSK for later use by a context. We do this in IKEv2, (D)TLS already./" Our proposal is to define an EAP lower layer that is specifically designed for constrained devices and networks. The setup of the MSK for later use, is what the EAP KMF does, and  this key material is used to run a security association protocol, that could be DTLS or OSCORE.  That is why it is not an afterthought as you say. I wrote could, because is one of the possibilities. That is another benefit of using EAP. With respect to do this with IKEv2, EAP already has an EAP method for IKE. Why limit the options when EAP gives you more. What will you do if the specific network does not support running IKEv2 due to severe constrains in the network or any other reason? That is why I believe the flexibility EAP gives you is worth considering. Best Regards, Dan. On 9/12/20 19:55, Michael Richardson wrote: > Dan Garcia wrote: > > EAP can be used in the context of IoT for authentication. > > But, to what end? > > 1) If it is onboarding a new device, then there is no connectivity until after authentication. > so you can't use CoAP, you have to use 802.1x, or some equivalent, or > create a system such as draft-ietf-6tisch-minimal-security. > Which does use CoAP and OSCORE already. > > 2) If it for application authentication, then you need to use EAP to setup > MSK for later use by a context. > We do this in IKEv2, (D)TLS already. > > So the only left would be OSCORE, yet you write "could", as if it was an afterthought. > > Tell me what is your application? What will be impossible if we don't do > this work? > > -- > Michael Richardson . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > --------------2CC5B6F2F9AC00C1F41295BD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

 Hi Michael,


"1) ..."

For onboarding a new device, where there is no connectivity after authentication, you propose to use 802.1X, which is an EAP lower layer. EAP over CoAP is in fact a proposal for a application level EAP lower layer that overcomes the limitation that 802.1X works on an inferior layer, hence, giving the possibility to perform the network authentication through nodes.

This idea is not new, in fact, you have PANA, another EAP lower layer that works on top of UDP.

As you comment , draft-ietf-6tisch-minimal-security - offers minimal security and has several deficiencies that can be solved by using EAP and AAA infrastructures.

Regarding your second point

"2) If it for application authentication, then you need to use EAP to setup MSK for later use by a context. We do this in IKEv2, (D)TLS already."

Our proposal is to define an EAP lower layer that is specifically designed for constrained devices and networks. The setup of the MSK for later use, is what the EAP KMF does, and  this key material is used to run a security association protocol, that could be DTLS or OSCORE.  That is why it is not an afterthought as you say. I wrote could, because is one of the possibilities. That is another benefit of using EAP.

With respect to do this with IKEv2, EAP already has an EAP method for IKE. Why limit the options when EAP gives you more. What will you do if the specific network does not support running IKEv2 due to severe constrains in the network or any other reason?

That is why I believe the flexibility EAP gives you is worth considering.

Best Regards,
Dan.



On 9/12/20 19:55, Michael Richardson wrote:
Dan Garcia <dan.garcia@um.es> wrote:
    > EAP can be used in the context of IoT for authentication.

But, to what end?

1) If it is onboarding a new device, then there is no connectivity until after authentication.
   so you can't use CoAP, you have to use 802.1x, or some equivalent, or
   create a system such as draft-ietf-6tisch-minimal-security.
   Which does use CoAP and OSCORE already.

2) If it for application authentication, then you need to use EAP to setup
   MSK for later use by a context.
   We do this in IKEv2, (D)TLS already.

So the only left would be OSCORE, yet you write "could", as if it was an afterthought.

Tell me what is your application?  What will be impossible if we don't do
this work?

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide
--------------2CC5B6F2F9AC00C1F41295BD-- From nobody Thu Dec 10 01:09:18 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA483A0B5A for ; Thu, 10 Dec 2020 01:09:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 xmRD9zU1Fqhu for ; Thu, 10 Dec 2020 01:09:15 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACB663A0B50 for ; Thu, 10 Dec 2020 01:09:14 -0800 (PST) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 4Cs7QK3F92z7v05; Thu, 10 Dec 2020 10:09:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1607591353; bh=MDGnVyaAiXouQRTgV+ak22bJmYyMt0wTfl8fTN+Vgo0=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=LZoXfRFNW3CmSXJWJnpqrFvczZV57D/NcMfz/jkkVnYOV3L5jT+9SU+UVaRHJADQB /5BQ4a8ZZwH3oECu4UQ1x+h2d+qMqsOmEb0mRhtnkMc07+LEEsesbK3pumwMPpPH+q eeLV0vvE7XMXWCfWRFWy53Gf9AMjy70tqUu/y+PwVtOunxREwmXlUrQGH3rjUFo2Ex YbDB/ekLVyoyw57OXaEwwmfthnbLVwDPhcmfZBOumNzEak5byRfIz61ph4BGP2rogj Xak1oaF31hx69cDsgx4UGmE2wi4WtT8ZLUScN8yOiTLm95VDDc3wFfulB1GKY6GGue fF5HIOPBEoizw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.86]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 4Cs7QK0WKFz3wbh; Thu, 10 Dec 2020 10:09:13 +0100 (CET) From: To: =?iso-8859-1?Q?Christian_Ams=FCss?= , "Core WG mailing list" Thread-Topic: [core] Updated CoAP option template and OSCORE handling Thread-Index: AQHWzjeYYfUF5wL6s0+v84xKVn1C96nwBobA Date: Thu, 10 Dec 2020 09:09:11 +0000 Message-ID: <17546_1607591353_5FD1E5B9_17546_51_1_787AE7BB302AE849A7480A190F8B93303159AF5A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [core] Updated CoAP option template and OSCORE handling X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2020 09:09:17 -0000 Hi Christian,=20 As we need to capture both E ad U for OSCORE and the need for consistent us= e of "x" to tag a given characteristic, another approach would be: +--------+---+---+---+---+-----------+--------+--------+---------+---+ | Number | C | U | N | R | Name | Format | Length | Default | O | | | | | | | | | | +-+-+ | | | | | | | | | |E|U| +=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D+=3D=3D=3D+=3D=3D=3D+=3D=3D=3D+=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+= =3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D+ | 16 | | | | | Hop-Limit | uint | 1 | 16 | |x| +--------+---+---+---+---+-----------+--------+--------+---------+---+ But given the conflict with the already used "Unsafe" column, I tend to pre= fer not overloading the existing table, but have a dedicated table that mim= ics Figure 5 of RFC8613:=20 +------+-----------------+---+---+ | No. | Name | E | U | +------+-----------------+---+---+ | 16 | Hop-Limit | | x | +------+-----------------+---+---+ If this approach is followed, we will update the new-block draft to include= this NEW table: +------+-----------------+---+---+ | No. | Name | E | U | +------+-----------------+---+---+ | TBA1 | Q-Block1 | x | x | | TBA2 | Q-Block2 | x | x | +------+-----------------+---+---+ Table 2: Protection of Q-Block1 and Q-Block2 Options Cheers, Med > -----Message d'origine----- > De=A0: core [mailto:core-bounces@ietf.org] De la part de Christian > Ams=FCss > Envoy=E9=A0: mercredi 9 d=E9cembre 2020 15:28 > =C0=A0: Core WG mailing list > Objet=A0: [core] Updated CoAP option template and OSCORE handling >=20 > Hello CoRE, >=20 > it is custom so far with all RFCs that introduce CoAP options to > summarize their options in a table like >=20 >=20 > +--------+---+---+---+---+-----------+--------+--------+---------+ > | Number | C | U | N | R | Name | Format | Length | Default | > +=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D+=3D=3D=3D+=3D=3D=3D+=3D=3D=3D+=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D= =3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D+ > | 16 | | | | | Hop-Limit | uint | 1 | 16 | > +--------+---+---+---+---+-----------+--------+--------+---------+ >=20 > With OSCORE, its [table 5] introduces two more columns that, when > plainly added, but their naming conflicts on "U" as noted in the > Genart review[1]. >=20 > As "how is this handled with object security" is a good thing to > have at hand, I propose >=20 > +--------+---+---+---+---+-----------+--------+--------+---------+- > --+ > | Number | C | U | N | R | Name | Format | Length | Default | > O | >=20 > +=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D+=3D=3D=3D+=3D=3D=3D+=3D=3D=3D+=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D= =3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D > =3D+ > | 16 | | | | | Hop-Limit | uint | 1 | 16 | > U | > +--------+---+---+---+---+-----------+--------+--------+---------+- > --+ >=20 > annotated as "O: OSCORE classification (U: unprotected)", and intend > to use this with echo-request-tag (ERT). >=20 > The practical alternative is to leave that information out of the > table, and only have it present textually; I think that would make > it harder for an implementer to grasp at one look how the option is > supposed to behave. >=20 >=20 > KR > Christian >=20 > PS. Yeah I know this is not something that needs WG-wide agreement > on or > would be binding for anyone registering an option, but still we > can > contribute to a consistent ecosystem here. >=20 > [table 5]: https://tools.ietf.org/html/rfc8613#page-17 > [1]: https://datatracker.ietf.org/doc/review-ietf-core-echo-request- > tag-11-genart-lc-robles-2020-12-02/ >=20 > -- > To use raw power is to make yourself infinitely vulnerable to > greater powers. > -- Bene Gesserit axiom ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Dec 10 05:31:32 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 427723A0B18 for ; Thu, 10 Dec 2020 05:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGaXE6T3jaIx for ; Thu, 10 Dec 2020 05:31:29 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 0284C3A0DF3 for ; Thu, 10 Dec 2020 05:31:28 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1knM2Y-0006A9-JA; Thu, 10 Dec 2020 13:31:26 +0000 From: To: , =?iso-8859-1?Q?'Christian_Ams=FCss'?= , "'Core WG mailing list'" References: <17546_1607591353_5FD1E5B9_17546_51_1_787AE7BB302AE849A7480A190F8B93303159AF5A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <17546_1607591353_5FD1E5B9_17546_51_1_787AE7BB302AE849A7480A190F8B93303159AF5A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Thu, 10 Dec 2020 13:31:20 -0000 Message-ID: <0ce601d6cef8$bf298970$3d7c9c50$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFCNREOfCAO1F1yAxTC4MquBsQ1FAGhVCaUqwx7DfA= Content-Language: en-gb Archived-At: Subject: Re: [core] Updated CoAP option template and OSCORE handling X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2020 13:31:31 -0000 Hi Christian, Med's suggestion looks good to me - especially as there is potential for lines being too long in the existing table if that was extended. Regards Jon > -----Original Message----- > From: mohamed.boucadair@orange.com = [mailto:mohamed.boucadair@orange.com] > Sent: 10 December 2020 09:09 > To: Christian Ams=FCss; Core WG mailing list > Subject: Re: [core] Updated CoAP option template and OSCORE handling >=20 > Hi Christian, >=20 > As we need to capture both E ad U for OSCORE and the need for = consistent use > of "x" to tag a given characteristic, another approach would be: >=20 > +--------+---+---+---+---+-----------+--------+--------+---------+---+ > | Number | C | U | N | R | Name | Format | Length | Default | O | > | | | | | | | | | +-+-+ > | | | | | | | | | |E|U| > = +=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D+=3D=3D=3D+=3D=3D=3D+=3D=3D=3D+=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D=3D=3D=3D > +=3D=3D=3D+ > | 16 | | | | | Hop-Limit | uint | 1 | 16 | |x| > +--------+---+---+---+---+-----------+--------+--------+---------+---+ >=20 > But given the conflict with the already used "Unsafe" column, I tend = to prefer > not overloading the existing table, but have a dedicated table that = mimics Figure > 5 of RFC8613: >=20 > +------+-----------------+---+---+ > | No. | Name | E | U | > +------+-----------------+---+---+ > | 16 | Hop-Limit | | x | > +------+-----------------+---+---+ >=20 > If this approach is followed, we will update the new-block draft to include this > NEW table: >=20 > +------+-----------------+---+---+ > | No. | Name | E | U | > +------+-----------------+---+---+ > | TBA1 | Q-Block1 | x | x | > | TBA2 | Q-Block2 | x | x | > +------+-----------------+---+---+ > Table 2: Protection of Q-Block1 and Q-Block2 Options >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: core [mailto:core-bounces@ietf.org] De la part de Christian > > Ams=FCss > > Envoy=E9=A0: mercredi 9 d=E9cembre 2020 15:28 > > =C0=A0: Core WG mailing list > > Objet=A0: [core] Updated CoAP option template and OSCORE handling > > > > Hello CoRE, > > > > it is custom so far with all RFCs that introduce CoAP options to > > summarize their options in a table like > > > > > > +--------+---+---+---+---+-----------+--------+--------+---------+ > > | Number | C | U | N | R | Name | Format | Length | Default | > > > = +=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D+=3D=3D=3D+=3D=3D=3D+=3D=3D=3D+=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D=3D=3D=3D > + > > | 16 | | | | | Hop-Limit | uint | 1 | 16 | > > +--------+---+---+---+---+-----------+--------+--------+---------+ > > > > With OSCORE, its [table 5] introduces two more columns that, when > > plainly added, but their naming conflicts on "U" as noted in the > > Genart review[1]. > > > > As "how is this handled with object security" is a good thing to > > have at hand, I propose > > > > +--------+---+---+---+---+-----------+--------+--------+---------+- > > --+ > > | Number | C | U | N | R | Name | Format | Length | Default | > > O | > > > > > = +=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D+=3D=3D=3D+=3D=3D=3D+=3D=3D=3D+=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D=3D=3D=3D > +=3D=3D > > =3D+ > > | 16 | | | | | Hop-Limit | uint | 1 | 16 | > > U | > > +--------+---+---+---+---+-----------+--------+--------+---------+- > > --+ > > > > annotated as "O: OSCORE classification (U: unprotected)", and intend > > to use this with echo-request-tag (ERT). > > > > The practical alternative is to leave that information out of the > > table, and only have it present textually; I think that would make > > it harder for an implementer to grasp at one look how the option is > > supposed to behave. > > > > > > KR > > Christian > > > > PS. Yeah I know this is not something that needs WG-wide agreement > > on or > > would be binding for anyone registering an option, but still we > > can > > contribute to a consistent ecosystem here. > > > > [table 5]: https://tools.ietf.org/html/rfc8613#page-17 > > [1]: https://datatracker.ietf.org/doc/review-ietf-core-echo-request- > > tag-11-genart-lc-robles-2020-12-02/ > > > > -- > > To use raw power is to make yourself infinitely vulnerable to > > greater powers. > > -- Bene Gesserit axiom >=20 > _________________________________________________________________ > ________________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce > message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou > falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this > message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been > modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Thu Dec 10 09:43:55 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8563A1176; Thu, 10 Dec 2020 09:43:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piPLSEqU9LQv; Thu, 10 Dec 2020 09:43:39 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 3A3E53A118B; Thu, 10 Dec 2020 09:43:37 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.78,408,1599516000"; d="scan'208,217";a="482302572" Received: from adsl-bb22-l204.crnagora.net (HELO [192.168.1.86]) ([95.155.22.204]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES256-GCM-SHA384; 10 Dec 2020 18:43:35 +0100 User-Agent: Microsoft-MacOutlook/10.11.0.180909 Date: Thu, 10 Dec 2020 18:43:32 +0100 From: =?UTF-8?B?TWFsacWhYQ==?= =?UTF-8?B?IFZ1xI1pbmnEhw==?= To: Dan Garcia , Michael Richardson , EMU WG , "core@ietf.org WG (core@ietf.org)" , "ace@ietf.org" Message-ID: Thread-Topic: [core] [Ace] Proposed charter for ACE (EAP over CoAP?) References: <20201117234700.GR39170@kduck.mit.edu> <24523.1607378991@localhost> <3a4e4b59-3712-7eb9-23b2-8160ad14b6aa@um.es> <2923.1607540144@localhost> <62dad652-8acd-0890-36cd-f7aacde19de2@uniovi.es> In-Reply-To: <62dad652-8acd-0890-36cd-f7aacde19de2@uniovi.es> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3690470615_868860928" Archived-At: Subject: Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2020 17:43:49 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3690470615_868860928 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Dan, =20 Could you be more specific on the point below, what deficiencies do you hav= e in mind? =20 Mali=C5=A1a=20 =20 From: core on behalf of Dan Garcia Date: Thursday 10 December 2020 at 10:06 To: Michael Richardson , EMU WG , "cor= e@ietf.org WG (core@ietf.org)" , "ace@ietf.org" Subject: Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?) =20 As you comment , draft-ietf-6tisch-minimal-security - offers minimal securi= ty and has several deficiencies that can be solved by using EAP and AAA infr= astructures.=20 --B_3690470615_868860928 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Dan,

 

Could you be more specific on the point below, what= deficiencies do you have in mind?

<= span lang=3DEN-US> 

Mali=C5=A1a

=  

From: core <core-bounce= s@ietf.org> on behalf of Dan Garcia <garciadan@uniovi.es>
Dat= e: Thursday 10 December 2020 at 10:06
To: Michael Richardson <mcr+ietf@sandelman.ca&g= t;, EMU WG <emu@ietf.org>, "core@ietf.org WG (core@ietf.org)"= ; <core@ietf.org>, "ace@ietf.org" <ace@ietf.org>
Subject: Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?)

<= o:p> 

= As you comment , draft-ietf-6tisch-minimal-security - offers minimal securit= y and has several deficiencies that can be solved by using EAP and AAA infra= structures. =

--B_3690470615_868860928-- From nobody Fri Dec 11 09:41:36 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B69FE3A0D39; Fri, 11 Dec 2020 09:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=unioviedo.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 n4ct2Jxz-mpd; Fri, 11 Dec 2020 09:41:32 -0800 (PST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2080.outbound.protection.outlook.com [40.107.22.80]) (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 2A11F3A0D37; Fri, 11 Dec 2020 09:41:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZnYJCUzVFCRzlA/bsk11gp7Ol3V6lYUPV7ORd3tA3kk8QfJUGPSGKiq/JkssfabAab3N5EVQ5RFsritd12vZZqwJtdAsV2r4HvWAcqvQrH4XAoZzHsazi8X00ZDDXhb28B9gR6oZdj4NkGd8czjjh2f2Xnxkq/QQbbthLQvBcOo24P3OflR65uPO8lrHpxUHZtS+vbEdS81SGMpS+f5ii9qm3DLTqlWsdMB6EiyqZHRex2cDCkr/tCZ9LkbnyfvRjSgUckA2PQGDPdvK2YPSBAh2ibzKSltU+/PDNDGwQzBqHXjNoUddV8maFIS46Hjr5ZI5hUuGU4Ws5glKeOA0Rg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vrysoN34OwpEJixfuOsex4iM5AeGJPP6GjEsqrqi4UM=; b=WTt83fMt5k1PrLcsOuxCTnr/pj9DGqAScUdCQWPHFrsQ+N95XP10OWGrvVQUWelBUZS3ptswP0uwhVH7rPSGdwLZvMKLExeAkyN/dsAz4Rsptmj4z/wg41AGjYecJE6D5DXkmQ7ywoahUx4qKcvwSGLre6S3NA5J7gLUCGXwaFvciR38x3VYtfaiXZN6vnNtY+Eg3ZyA9Q3mAl20SoNSXOt8TuMR9XXGVRItWTcHDqyKTrOhIYkguXHU1lvLe6Qql+OU47kl/ZCgHNrYJmJWbMZfZk34HkgRaJRe83ANvzZbwu8n8v39RxD1cib8bhF/D47CyxKiZTCRdEAh4xj79g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uniovi.es; dmarc=pass action=none header.from=uniovi.es; dkim=pass header.d=uniovi.es; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unioviedo.onmicrosoft.com; s=selector2-unioviedo-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vrysoN34OwpEJixfuOsex4iM5AeGJPP6GjEsqrqi4UM=; b=OCNlajE7tYNB4Lza0aCf1YRj/+MdOLlX/8q5fM15fwDwdx/aR/k9J2elzoO6M3ILNIn77ByvJ0G/h8RUZqGy5moOn1WQ3Z92LN6xTwTLSeA7l1eMcCYbkYZ6uvCKcpgbRPAe3FH2a0pXADLhtCcHfXUNC0neqlC8nWOU9mxU7O0= Authentication-Results: uniovi.es; dkim=none (message not signed) header.d=none;uniovi.es; dmarc=none action=none header.from=uniovi.es; Received: from AM0PR08MB3940.eurprd08.prod.outlook.com (2603:10a6:208:124::19) by AM0PR08MB4417.eurprd08.prod.outlook.com (2603:10a6:208:13f::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.20; Fri, 11 Dec 2020 17:41:29 +0000 Received: from AM0PR08MB3940.eurprd08.prod.outlook.com ([fe80::9c65:30a3:58fe:e6dd]) by AM0PR08MB3940.eurprd08.prod.outlook.com ([fe80::9c65:30a3:58fe:e6dd%7]) with mapi id 15.20.3654.012; Fri, 11 Dec 2020 17:41:29 +0000 To: =?UTF-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= , Michael Richardson , EMU WG , "core@ietf.org WG (core@ietf.org)" , "ace@ietf.org" References: <20201117234700.GR39170@kduck.mit.edu> <24523.1607378991@localhost> <3a4e4b59-3712-7eb9-23b2-8160ad14b6aa@um.es> <2923.1607540144@localhost> <62dad652-8acd-0890-36cd-f7aacde19de2@uniovi.es> From: Dan Garcia Carrillo Message-ID: <1fdb134e-54a1-1937-fdd6-3d226c89aea7@uniovi.es> Date: Fri, 11 Dec 2020 18:41:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A06EE6867811146F2926CFCF" Content-Language: es-ES X-Originating-IP: [192.145.124.84] X-ClientProxiedBy: MRXP264CA0040.FRAP264.PROD.OUTLOOK.COM (2603:10a6:500:14::28) To AM0PR08MB3940.eurprd08.prod.outlook.com (2603:10a6:208:124::19) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.5.0.2] (192.145.124.84) by MRXP264CA0040.FRAP264.PROD.OUTLOOK.COM (2603:10a6:500:14::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.21 via Frontend Transport; Fri, 11 Dec 2020 17:41:28 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 333c9aeb-320d-4913-672d-08d89dfbfe0d X-MS-TrafficTypeDiagnostic: AM0PR08MB4417: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 0UkVSidqNgXEgTY0Seyvi38+52fiVOkWHfYK1CU0iX+OLc8HXH1N3/pr34p/FCmRtE7NG+u+hiGaoROKIt35gX+l7Mb64JS0xlMX/Gs9VX5cdNOyCUvFwtGsugN30rB8Tb5l86+u6PuUYevX2hZJZEZTJkveQLv3UTCCc3ni/zGLo1HXAXZPTr3PFqvAtJ1RxEfofAAHPEZxSCSS3Q4anwAeXvAC+mGBZbcfv2a648Agr8UlIBns9/q+waBVKWOq1GMm6DQD4KMlJOpJHNxcevSL5xc/0G7rTjmYfRjFNh534JivbJK2RcE5K5AjdVm4VIM4tZ7JJOKcclTmLtByEyv7B83C55ujnV3wP8Py6RD1vKwUqqPlblpUx9DkuWt13Ws1VVLVBWiOKGtOfOppRJLFwk9i5HzkoxWmMFrTsUY= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3940.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(346002)(396003)(136003)(39860400002)(366004)(66946007)(6486002)(16576012)(66556008)(31686004)(956004)(5660300002)(86362001)(33964004)(31696002)(786003)(66476007)(107886003)(83380400001)(316002)(26005)(4326008)(8676002)(478600001)(186003)(52116002)(36756003)(66574015)(2906002)(2616005)(8936002)(16526019)(110136005)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?Y0cyQlQ1eVJFM1VEWXBwMUtBdUF0MGFWZVh4YzQzbzJiRk14Y0RkMU9VNG5P?= =?utf-8?B?V0g1cEo4ZkR6YnRmQzM4ZTlYUzF3V3dlNkdNSDNOODJlSGJzOFZ2UXNIeDBQ?= =?utf-8?B?WnM0VEY2MWlCWjRpTW5FbmFtWFBYQjdrbThjWDkwMmRqZGN2eEgzbWtoNDlj?= =?utf-8?B?c1VsVTkvS2wxZlpYZFdIOWp6c3ZwMi9RRmk5YmdQTVBQREdBL0pPb1dSSmdC?= =?utf-8?B?dytlQzNoK1ZwK2hxc3dQc2pIQUdqSFVseWVoblQ2V0xPemNvemlTTjlqR1Nz?= =?utf-8?B?Q08yUmkyWDg2bm9XUE1JRUpXT2s3bk1YbDl3NGFFSXRzL3l1VUN6R28wcUgw?= =?utf-8?B?dUFoNStxYVRIL1pwa3gyeGlKWStlTUozUFMxL3J4aDB5RXBmSWJreWVKT3BN?= =?utf-8?B?bHhTTmNQNkt4ZGE3T05ab0pqV0gvTHlVK2svWUZ0YWdUdGNKMzh0Q1BKclNT?= =?utf-8?B?YTFQZ1VEWTBOaHNVd3g1TnZuRWZ0NVBsRE9aeURldFVYVFU0VFU1aWdvc08v?= =?utf-8?B?QU5YNWV3ckhVZ1JyTm1XQkRpN1hpYkpvS0ZyVlVEUG56TWt3RzA4MkpFQzJ5?= =?utf-8?B?WE5tNFZ6NUx1Nm5Ialo1bTBzelUrN05lSEFpQ3hRc2xPb1RJVndXZjlYR21M?= =?utf-8?B?VGduMzhpKzFtaFZiOUlyTE1jaVExWVNXcXZibEx2Rlo4NVFqdWpnTkZqYTA3?= =?utf-8?B?QVBpbGkwWjBndkpnNG5ScWdtOFJBRDZ1TkcxaThwNTZCOGd3V0JMbGxGbE9a?= =?utf-8?B?bkZZMEhLekMrRjNmQjNhVWhtZkhsYkVxQWh3ZktsNlBlRUxvSVIxeDFGUUZJ?= =?utf-8?B?cW81dnRleHV1VDduMFd5anBzaG1GS2ZrczhqYlF0blQ3Y0F2UEhuWDhqWUNp?= =?utf-8?B?di9nRTkwMGZHa3dmb3dNWENoUnJ6Szh0Z2ZmWlpETkxOTElydkpkdEhoRUU1?= =?utf-8?B?YlY5REYrV2tLWHBSUVhrZU53NVEyNlN6Q1RZbFk4L3BpY1BmOHZEV2kxSExo?= =?utf-8?B?ellGMUxpazRTSzM2dk51aEZNVG0xRzJDRkRkd1RibTlhVlcyV1pLUm8rUXpM?= =?utf-8?B?a2htSTFsTnorR3FJZjlWVThYelNJa2tXNTlLd1l6SFRzZ2VtWERmSmJFQWww?= =?utf-8?B?a29NRWI3QXVJNzFzUXFHSzI1YTVLTHkyOWhuTE8zOEV3VTF6Y1BUQkJSWHhr?= =?utf-8?B?TFQ5c1pzYWF4RGpieWh6ZE9oelB6UjhCZWxBR1ptK0Z2ekcwT21IT1Q1bnhr?= =?utf-8?B?Zk55bUlhVmlLNjRVazRJNEU3T0pXSjRpbXVlMUFHblI5b3kxRC84dVlpZnlt?= =?utf-8?Q?tHRGztBiFgHsU9fMP/YKlnx+MfR3ItP4iv?= X-OriginatorOrg: uniovi.es X-MS-Exchange-CrossTenant-AuthSource: AM0PR08MB3940.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Dec 2020 17:41:29.7068 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 05ea74a3-92c5-4c31-978a-925c3c799cd0 X-MS-Exchange-CrossTenant-Network-Message-Id: 333c9aeb-320d-4913-672d-08d89dfbfe0d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: psitBhu88BrlQNBTbC/MULy4HgUC9bs1uDGyT+bigkAmlUjBON9GcE4vkM+ivubYumu5g514HKcCnf+yJDgkNw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4417 X-MS-Exchange-CrossPremises-AuthSource: AM0PR08MB3940.eurprd08.prod.outlook.com X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 06 X-MS-Exchange-CrossPremises-Mapi-Admin-Submission: X-MS-Exchange-CrossPremises-MessageSource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-OriginalClientIPAddress: 192.145.124.84 X-MS-Exchange-CrossPremises-TransportTrafficType: Email X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-Processed-By-Journaling: Journal Agent X-OrganizationHeadersPreserved: AM0PR08MB4417.eurprd08.prod.outlook.com Archived-At: Subject: Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2020 17:41:35 -0000 --------------A06EE6867811146F2926CFCF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi MaliÅ¡a, My intention was not to turn this conversation into a criticism of your work. “deficiencies†was not the most appropriate word. What we had in mind was a way of providing authentication  to the variety of IoT devices with different capabilities, limitations or different types of supported credentials. A way of doing that is to provide different authentication methods. Since in IoT there are different technologies we looked for a link-layer independent solution. Additionally, since some technologies are very constrained, we needed a very constrained protocol to carry out the process. EAP provides flexible authentication, and it has EAP Key Management Framework which is well specified and working for many years, from which you can generate generate a fresh pre-shared key (MSK) dynamically. This is even possible if you do not want to interact with AAA infrastructures running EAP in standalone mode. Having said this, another thing that we looked into was to give support to large scale deployments. We can ease this process with EAP and its interaction with a AAA infrastructure, which gains relevance in Industrial IoT and 5G. All these characteristics can be provided by the use of EAP, if we of course have a lightweight EAP lower layer to transport EAP from the IoT device. Then we considered the usage of CoAP as EAP lower-layer. In this sense, we saw minimal security did not fit our view (no potential interaction with AAA , flexible authentication, fresh generation of PSK).  In fact,  the provisioning of the PSK was out of scope. At some level, we could even consider the work complementary. EAP over CoAP could be a way of providing the PSK for the work of minimal security. Best Regards, Dan. El 10/12/2020 a las 18:43, MaliÅ¡a VuÄinić escribió: > > Hi Dan, > > Could you be more specific on the point below, what deficiencies do > you have in mind? > > MaliÅ¡a > > *From: *core on behalf of Dan Garcia > > *Date: *Thursday 10 December 2020 at 10:06 > *To: *Michael Richardson , EMU WG > , "core@ietf.org WG (core@ietf.org)" , > "ace@ietf.org" > *Subject: *Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?) > > As you comment , draft-ietf-6tisch-minimal-security - offers minimal > security and has several deficiencies that can be solved by using EAP > and AAA infrastructures. > --------------A06EE6867811146F2926CFCF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Mališa,

My intention was not to turn this conversation into a criticism of your work. “deficiencies†was not the most appropriate word.

What we had in mind was a way of providing authentication  to the variety of IoT devices with different capabilities, limitations or different types of supported credentials. A way of doing that is to provide different authentication methods. Since in IoT there are different technologies we looked for a link-layer independent solution. Additionally, since some technologies are very constrained, we needed a very constrained protocol to carry out the process.

EAP provides flexible authentication, and it has EAP Key Management Framework which is well specified and working for many years, from which you can generate generate a fresh pre-shared key (MSK) dynamically. This is even possible if you do not want to interact with AAA infrastructures running EAP in standalone mode.  Having said this, another thing that we looked into was to give support to large scale deployments. We can ease this process with EAP and its interaction with a AAA infrastructure, which gains relevance in Industrial IoT and 5G.

All these characteristics can be provided by the use of EAP, if we of course have a lightweight EAP lower layer to transport EAP from the IoT device. Then we considered the usage of CoAP as EAP lower-layer.

In this sense, we saw minimal security did not fit our view (no potential interaction with AAA , flexible authentication, fresh generation of PSK).  In fact,  the provisioning of the PSK was out of scope.

At some level, we could even consider the work complementary. EAP over CoAP could be a way of providing the PSK for the work of minimal security.


Best Regards,
Dan.

El 10/12/2020 a las 18:43, MaliÅ¡a VuÄinić escribió:

Hi Dan,

 

Could you be more specific on the point below, what deficiencies do you have in mind?

 

Mališa

 

From: core <core-bounces@ietf.org> on behalf of Dan Garcia <garciadan@uniovi.es>
Date: Thursday 10 December 2020 at 10:06
To: Michael Richardson <mcr+ietf@sandelman.ca>, EMU WG <emu@ietf.org>, "core@ietf.org WG (core@ietf.org)" <core@ietf.org>, "ace@ietf.org" <ace@ietf.org>
Subject: Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?)

 

As you comment , draft-ietf-6tisch-minimal-security - offers minimal security and has several deficiencies that can be solved by using EAP and AAA infrastructures. 

--> --------------A06EE6867811146F2926CFCF-- From nobody Fri Dec 11 10:45:36 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A35893A0DD7; Fri, 11 Dec 2020 10:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYLXTXad5Cfe; Fri, 11 Dec 2020 10:45:28 -0800 (PST) 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 222BB3A0DCE; Fri, 11 Dec 2020 10:45:26 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.78,412,1599516000"; d="scan'208,217";a="367395883" Received: from adsl-bb22-l204.crnagora.net (HELO [192.168.1.86]) ([95.155.22.204]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES256-GCM-SHA384; 11 Dec 2020 19:45:24 +0100 User-Agent: Microsoft-MacOutlook/10.11.0.180909 Date: Fri, 11 Dec 2020 19:45:21 +0100 From: =?UTF-8?B?TWFsacWhYQ==?= =?UTF-8?B?IFZ1xI1pbmnEhw==?= To: Dan Garcia Carrillo , Michael Richardson , EMU WG , "core@ietf.org WG (core@ietf.org)" , "ace@ietf.org" Message-ID: <6C717866-759B-4544-BA04-50D623CF9EFE@inria.fr> Thread-Topic: [core] [Ace] Proposed charter for ACE (EAP over CoAP?) References: <20201117234700.GR39170@kduck.mit.edu> <24523.1607378991@localhost> <3a4e4b59-3712-7eb9-23b2-8160ad14b6aa@um.es> <2923.1607540144@localhost> <62dad652-8acd-0890-36cd-f7aacde19de2@uniovi.es> <1fdb134e-54a1-1937-fdd6-3d226c89aea7@uniovi.es> In-Reply-To: <1fdb134e-54a1-1937-fdd6-3d226c89aea7@uniovi.es> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3690560724_1158425664" Archived-At: Subject: Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2020 18:45:31 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3690560724_1158425664 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Dan, =20 Thanks for the clarification regarding minimal-security. The points that yo= u mention below, e.g. flexible authentication or the fresh generation of the= PSK, were never in the design scope of our work.=20 =20 While I fail to understand what exactly do you plan on using EAP-over-CoAP = for, I do not object on this work being done in ACE if you are willing to sp= end cycles on it. I do have reservations on the lightweight aspect of this, = however, considering that the sequence diagram that you depict in Fig. 2 in = draft-marin-ace-wg-coap-eap-06 spans 3 pages and consumes 2 round trips just= to get things started! Surely, we can do better? =20 Mali=C5=A1a =20 From: Dan Garcia Carrillo Date: Friday 11 December 2020 at 18:41 To: Mali=C5=A1a Vu=C4=8Dini=C4=87 , Michael Richardson , EMU WG , "core@ietf.org WG (core@ietf.org)" = , "ace@ietf.org" Cc: Subject: Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?) =20 Hi Mali=C5=A1a,=20 My intention was not to turn this conversation into a criticism of your wor= k. =E2=80=9Cdeficiencies=E2=80=9D was not the most appropriate word. What we had in mind was a way of providing authentication to the variety o= f IoT devices with different capabilities, limitations or different types of= supported credentials. A way of doing that is to provide different authenti= cation methods. Since in IoT there are different technologies we looked for = a link-layer independent solution. Additionally, since some technologies are= very constrained, we needed a very constrained protocol to carry out the pr= ocess. EAP provides flexible authentication, and it has EAP Key Management Framewo= rk which is well specified and working for many years, from which you can ge= nerate generate a fresh pre-shared key (MSK) dynamically. This is even possi= ble if you do not want to interact with AAA infrastructures running EAP in s= tandalone mode. Having said this, another thing that we looked into was to = give support to large scale deployments. We can ease this process with EAP a= nd its interaction with a AAA infrastructure, which gains relevance in Indus= trial IoT and 5G.=20 All these characteristics can be provided by the use of EAP, if we of cours= e have a lightweight EAP lower layer to transport EAP from the IoT device. T= hen we considered the usage of CoAP as EAP lower-layer. In this sense, we saw minimal security did not fit our view (no potential i= nteraction with AAA , flexible authentication, fresh generation of PSK). In= fact, the provisioning of the PSK was out of scope.=20 At some level, we could even consider the work complementary. EAP over CoAP= could be a way of providing the PSK for the work of minimal security.=20 Best Regards, Dan. El 10/12/2020 a las 18:43, Mali=C5=A1a Vu=C4=8Dini=C4=87 escribi=C3=B3: Hi Dan, =20 Could you be more specific on the point below, what deficiencies do you hav= e in mind? =20 Mali=C5=A1a=20 =20 From: core on behalf of Dan Garcia Date: Thursday 10 December 2020 at 10:06 To: Michael Richardson , EMU WG , "cor= e@ietf.org WG (core@ietf.org)" , "ace@ietf.org" Subject: Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?) =20 As you comment , draft-ietf-6tisch-minimal-security - offers minimal securi= ty and has several deficiencies that can be solved by using EAP and AAA infr= astructures.=20 --> --B_3690560724_1158425664 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Dan,

 

Thanks for the clarification regarding minimal-secu= rity. The points that you mention below, e.g. flexible authentication or the= fresh generation of the PSK, were never in the design scope of our work.

 

While I fail to understand what = exactly do you plan on using EAP-over-CoAP for, I do not object on this work= being done in ACE if you are willing to spend cycles on it. I do have reser= vations on the lightweight aspect of this, however, considering that the seq= uence diagram that you depict in Fig. 2 in draft-marin-ace-wg-coap-eap-06 sp= ans 3 pages and consumes 2 round trips just to get things started! Surely, w= e can do better?

 

Mali=C5=A1a

 

From: Dan Garcia Carri= llo <garciadan@uniovi.es>
Date: Friday 11 December 2020 at 1= 8:41
To: Mali=C5=A1a Vu=C4=8Dini=C4=87 <malisa.vucinic@inria.fr>, Michael Richardson <mcr+ietf@= sandelman.ca>, EMU WG <emu@ietf.org>, "core@ietf.org WG (core@= ietf.org)" <core@ietf.org>, "ace@ietf.org" <ace@ietf= .org>
Cc: <garciadan@uniovi.es>
Subject: Re: [c= ore] [Ace] Proposed charter for ACE (EAP over CoAP?)

 

=

Hi Mali=C5=A1a,

My intention was not= to turn this conversation into a criticism of your work. =E2=80=9Cdeficiencies=E2=80=9D= was not the most appropriate word.

What we had in mind was a way of = providing authentication  to the variety of IoT devices with different = capabilities, limitations or different types of supported credentials. A way= of doing that is to provide different authentication methods. Since in IoT = there are different technologies we looked for a link-layer independent solu= tion. Additionally, since some technologies are very constrained, we needed = a very constrained protocol to carry out the process.

EAP provides fl= exible authentication, and it has EAP Key Management Framework which is well= specified and working for many years, from which you can generate generate = a fresh pre-shared key (MSK) dynamically. This is even possible if you do no= t want to interact with AAA infrastructures running EAP in standalone mode.&= nbsp; Having said this, another thing that we looked into was to give suppor= t to large scale deployments. We can ease this process with EAP and its inte= raction with a AAA infrastructure, which gains relevance in Industrial IoT a= nd 5G.

All these characteristics can be provided by the use of EAP, = if we of course have a lightweight EAP lower layer to transport EAP from the= IoT device. Then we considered the usage of CoAP as EAP lower-layer.
In this sense, we saw minimal security did not fit our view (no potential i= nteraction with AAA , flexible authentication, fresh generation of PSK).&nbs= p; In fact,  the provisioning of the PSK was out of scope.

At s= ome level, we could even consider the work complementary. EAP over CoAP coul= d be a way of providing the PSK for the work of minimal security.

Best Regards,
Dan.

El 10/12/2020 a las 18:43, Mali=C5=A1a Vu=C4=8Dini=C4=87 escribi=C3=B3:

Hi Dan,=

&nb= sp;

Could you be more specific on the point below, what deficiencies= do you have in mind?

 

Mali=C5=A1a

 

= From: core = <core-bounces@ietf.org> on = behalf of Dan Garcia <garciadan@unio= vi.es>
Date: Thursday 10 December 2020 at 10:06
To: <= /b>Michael Richardson <mcr+ietf@sandelman.ca>, EMU WG= <emu@ietf.org>, "core@ietf.org WG (core@ietf.org)" <core@ietf.org>, "ace@ietf.org" <= ;ace@ietf.org>
Subject: Re: [core] [Ace] Proposed charter f= or ACE (EAP over CoAP?)

 

As you comment , draft-ietf-6tisch-minimal-securi= ty - offers minimal security and has several deficiencies that can be solved= by using EAP and AAA infrastructures.&nbs= p;

-->

--B_3690560724_1158425664-- From nobody Sat Dec 12 09:37:04 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA0D3A1232; Sat, 12 Dec 2020 09:37:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=unioviedo.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 y78cxsIZpt6s; Sat, 12 Dec 2020 09:36:58 -0800 (PST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2084.outbound.protection.outlook.com [40.107.22.84]) (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 1C6ED3A0D3F; Sat, 12 Dec 2020 09:36:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V5Htx3BetrBIdL+ze9kQpzNhDkccFjEE4Y/1ikpELWug7KTIcbJmwKhyOqfzQKD/RXStMc789Ab0KZwCOiNn8+iAfiXr7/Lu3Sh9ymcX1V68NBKI4PiXz9A/xE0NPojTmkW0KQHPmVJmHU3OtDfksFBRy0yVXViAdu5BGu/ka/eaCur8u4veutJL4cGcJgBlvmlAWKEzTJFTDVz5+3/pk5dSZifGBbTEM9ORRCHKsT6rbtodsJ6889jS7Y/vL4jS9xGp5FRLL9MQ89vR8RLD4G6qBe8pLIVwaaRjrZdL/E7G3qMd3pRSgkw5m5jQSzK5gjpbqyN98GfEvzYqGi5TZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DvMb+P8VVPM+6YHiGWdMi4ZTT8I620GN/HDN//devZM=; b=WMigQAdtH8/gGa6dxe6HbY90lB42364nlrEbxzDemqD1lqIMmZ/76/shH1ECv4j0NO+DzuLfNFW66od91Y8iVVy+vk4wf+gCeeY2PqtGao6MSMLNuCYS5d3wl4YhocnExeIUfflIl1fB8xeML3o5QWv8nc3fBlukvPNAxRYoMdrgqUIHRbSuzJH5aGXaoev1ygeIdDovDzwJ/D3T8dS4LZ4/Wm5gvvtYjMnbaUWzrCLQj9yBMpKkZv58O08FtORvMZ2mLLbCwTQdW0VJrpo8mjmXXgbGvKG9mxyEaFk1uFrCBXxypfZKID7RDukbniQJKZ2hD6VzA2RCU99L/OmwQw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uniovi.es; dmarc=pass action=none header.from=uniovi.es; dkim=pass header.d=uniovi.es; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unioviedo.onmicrosoft.com; s=selector2-unioviedo-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DvMb+P8VVPM+6YHiGWdMi4ZTT8I620GN/HDN//devZM=; b=ExFS6CgVJZEm/aSfP/UmFTV8x5E798tBX/ROJ0m0Z7H/W/xhzaEgljzs7COoIfLfKh7bLZYzXUOPpIyS+RDVzdEzidXtgItwTyexUxE2H9MYcMegV+9g2Yt+vH6PbgCV7BDkjCF+LwCeRWfPnibpiwSOvvrCI6pYM/usrCaBIFY= Authentication-Results: uniovi.es; dkim=none (message not signed) header.d=none;uniovi.es; dmarc=none action=none header.from=uniovi.es; Received: from AM0PR08MB3940.eurprd08.prod.outlook.com (2603:10a6:208:124::19) by AM0PR08MB3748.eurprd08.prod.outlook.com (2603:10a6:208:fb::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.13; Sat, 12 Dec 2020 17:36:55 +0000 Received: from AM0PR08MB3940.eurprd08.prod.outlook.com ([fe80::9c65:30a3:58fe:e6dd]) by AM0PR08MB3940.eurprd08.prod.outlook.com ([fe80::9c65:30a3:58fe:e6dd%7]) with mapi id 15.20.3654.019; Sat, 12 Dec 2020 17:36:55 +0000 To: =?UTF-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= , Michael Richardson , EMU WG , "core@ietf.org WG (core@ietf.org)" , "ace@ietf.org" References: <20201117234700.GR39170@kduck.mit.edu> <24523.1607378991@localhost> <3a4e4b59-3712-7eb9-23b2-8160ad14b6aa@um.es> <2923.1607540144@localhost> <62dad652-8acd-0890-36cd-f7aacde19de2@uniovi.es> <1fdb134e-54a1-1937-fdd6-3d226c89aea7@uniovi.es> <6C717866-759B-4544-BA04-50D623CF9EFE@inria.fr> From: Dan Garcia Carrillo Message-ID: <238e2b03-a9b3-918a-2a9b-fbb66b84ddbf@uniovi.es> Date: Sat, 12 Dec 2020 18:36:53 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 In-Reply-To: <6C717866-759B-4544-BA04-50D623CF9EFE@inria.fr> Content-Type: multipart/alternative; boundary="------------80C24DC785D13739DD6EBAE8" Content-Language: es-ES X-Originating-IP: [156.35.171.42] X-ClientProxiedBy: MRXP264CA0030.FRAP264.PROD.OUTLOOK.COM (2603:10a6:500:14::18) To AM0PR08MB3940.eurprd08.prod.outlook.com (2603:10a6:208:124::19) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [156.35.171.42] (156.35.171.42) by MRXP264CA0030.FRAP264.PROD.OUTLOOK.COM (2603:10a6:500:14::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.17 via Frontend Transport; Sat, 12 Dec 2020 17:36:54 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 978b4392-f75d-419e-a253-08d89ec484cf X-MS-TrafficTypeDiagnostic: AM0PR08MB3748: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:1051; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: y0vzrle3ceEIdhRhHmJCFb/3ovkWZODo8qZQWHWWEysdmpoH5V3yIIS6iGp8DoUcruin1gvNzREem306KNN/lZwxVr3zmhBoHrztJGuZrbYjjRp6+HFPbPnivYUpOQ9PG95iy6zwVjS/1u/v7lfokars7VVDvTzxM8lVAS1i6p/JJQJpBxHELbKK7BxzcX5e9kq+l9+wpM+UHljNALItqBEEMzG0eEkZ8T4+nXjUtiY0gxUBAITWvh1u3eOWkoYsN2iGXB55/+J5duKApVgbN7yrv4GVPLVshBa9Mq+hsu5ndC/3IkO9X6gdv7N1KsxyZ7Fzj2QEdgDYfmxxuSURSW+5RK4anynb4c/3RRWZioLAxSmUA5STXyQMHLKeGu2C69BisqU3Y2eSbjdHC5eA0XwShey0mkXaXUldlmKDup+6KKKMTfDOr19EnCKBSpkI X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3940.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(39850400004)(366004)(376002)(346002)(136003)(396003)(83380400001)(2906002)(36756003)(786003)(956004)(478600001)(16526019)(186003)(8936002)(316002)(31686004)(26005)(86362001)(33964004)(2616005)(8676002)(31696002)(66476007)(107886003)(52116002)(4326008)(66574015)(6486002)(6706004)(66556008)(5660300002)(110136005)(66946007)(16576012)(3940600001)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?eXRQc1MwUk1CTlJKdWpVdkxIaHhzQVRqamhVU0ZWVWE3MG02UXVuRVBLVDdi?= =?utf-8?B?NGovR1VLLzdacHNwYUtrWjQyM29oRjZaK3prcXQwSXRjblBrbnFjalVKRnp5?= =?utf-8?B?UUE0NVZEQkhUUWdjVFlCRkFwNzdjUldROTVWMStPVFd6SG9uWmNwR2h2QkZK?= =?utf-8?B?MHZ1L0ZlRVJudHl5a0ZST0pxMU5kZVZJdWpsSmFjZThDOFdDdjBFb3k3OFpu?= =?utf-8?B?akt3OWhJMkpPR1Y5dndvL21UUGUrdjRpajVaN28wVVBvTk5mMXhCcXg3dWQy?= =?utf-8?B?S3I1QVNoWjIwYjZCcTFZdGVmb0J2cmlXV1JkQWJRUmpyWDZjSmNnaERrVllz?= =?utf-8?B?SGhwUlhnZFE0ZHpsaEpKUnloOUU1NDBiNEtsN0V6RXpPYkVIK2twZTNnbzNn?= =?utf-8?B?UW1kczNyaGFndTY2d1hKdHNCT2s3a3JJRFE1RE13bXowWjgvSlZqcmNRaDZj?= =?utf-8?B?dTN1Z2M0SWZYVndRQUhmWUJsczJMamJac2ExSjhPdExVZ2c4NFRJd2xFQXAw?= =?utf-8?B?dHh5aDlCd1VmNlh0Sm9hcGdTeUxMaTcya2hyT1czRU1mUFgyS1pHeGxZUmsx?= =?utf-8?B?eGRlYlJaZ0FseDZvSTBQZnRjQWdqRTlvdjJnR2Vua1FWaXREN29ER216cktw?= =?utf-8?B?REgwdEVQYml4VGJ6WUdkRzZqdkRLOUp5bkNxdHh2clBxV0Uvbk9IdHQ4bHcy?= =?utf-8?B?NWREdWpJb1FlUGFJTzhSQjJxZFRtUzk3MWlLdHZQYUoybUpXMXZKL3drWGFt?= =?utf-8?B?SE4za2MxSVlicXVEU2JJdFFMZXRpWURuclFGMTg3ZGZwU2YwMEtPd3lSallP?= =?utf-8?B?SjQxd1lWc0k2OHpuSFR5eVRVYjF3TGZkUjFzeDRteWFMK3JuOGZBNmpPMHcv?= =?utf-8?B?VlNzQmFhaGZhMU5xSDhMcXduTUNYbEx5UlhMc3NWeFpwa1phSWRtZkszV1h3?= =?utf-8?B?NTlkbGlVcTE1Y29zb3o3TGtHVEtGTHZaY3oyOWF6NDU5dklCSUx4cEN0UEdB?= =?utf-8?B?cE5KMi9QR3JPeG5pbnNBN0ZTYTgrY2Q4NDdBd2tnSS9WWjFHcG5rMituSnpX?= =?utf-8?B?eDc4TVBvNTVQMmlTWURublRWZFdKQXJzUVhrTGV5Uk1PcnArUG9mdzhuVloz?= =?utf-8?B?cHkrSVZVbFkxMnY1eVZqbmFhUDlKaEVBeVhGb0owYWVIZkp6SWp3L1VSRnEy?= =?utf-8?B?WU5QeUNtQjBteFBVM3FZQTBGaHhsK1VDT1ZDVWVlV0hsck1pdXcwb3p3K05i?= =?utf-8?B?UWFmZnY2aGxEM1RLTzVpRTRnQ1djMk4zOHBjNU9wVXVDREVyaUNxMGprc0w3?= =?utf-8?Q?j+6rJLcRGVjKGQQsIUI565YjbUijulJx0k?= X-OriginatorOrg: uniovi.es X-MS-Exchange-CrossTenant-AuthSource: AM0PR08MB3940.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Dec 2020 17:36:55.0854 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 05ea74a3-92c5-4c31-978a-925c3c799cd0 X-MS-Exchange-CrossTenant-Network-Message-Id: 978b4392-f75d-419e-a253-08d89ec484cf X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: rBPVj4C4rTBXUm+BUCNf4AhPux/i5ndUh+rdTJSrXBxb1Gt8qjHaP0J8WEkXt+/e5KFOc+zEBn7g8tPzqg4gAw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3748 X-MS-Exchange-CrossPremises-AuthSource: AM0PR08MB3940.eurprd08.prod.outlook.com X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 06 X-MS-Exchange-CrossPremises-Mapi-Admin-Submission: X-MS-Exchange-CrossPremises-MessageSource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-OriginalClientIPAddress: 156.35.171.42 X-MS-Exchange-CrossPremises-TransportTrafficType: Email X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-Processed-By-Journaling: Journal Agent X-OrganizationHeadersPreserved: AM0PR08MB3748.eurprd08.prod.outlook.com Archived-At: Subject: Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Dec 2020 17:37:03 -0000 --------------80C24DC785D13739DD6EBAE8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi MaliÅ¡a, El 11/12/2020 a las 19:45, MaliÅ¡a VuÄinić escribió: > > Hi Dan, > > Thanks for the clarification regarding minimal-security. The points > that you mention below, e.g. flexible authentication or the fresh > generation of the PSK, were never in the design scope of our work. > > While I fail to understand what exactly do you plan on using > EAP-over-CoAP for, I do not object on this work being done in ACE if > you are willing to spend cycles on it. I do have reservations on the > lightweight aspect of this, however, considering that the sequence > diagram that you depict in Fig. 2 in draft-marin-ace-wg-coap-eap-06 > spans 3 pages and consumes 2 round trips just to get things started! > Surely, we can do better? > Yes, we will submit an updated version of the draft. Best Regards, Dan > MaliÅ¡a > > *From: *Dan Garcia Carrillo > *Date: *Friday 11 December 2020 at 18:41 > *To: *MaliÅ¡a VuÄinić , Michael Richardson > , EMU WG , "core@ietf.org WG > (core@ietf.org)" , "ace@ietf.org" > *Cc: * > *Subject: *Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?) > > Hi MaliÅ¡a, > > My intention was not to turn this conversation into a criticism of > your work. “deficiencies†was not the most appropriate word. > > What we had in mind was a way of providing authentication  to the > variety of IoT devices with different capabilities, limitations or > different types of supported credentials. A way of doing that is to > provide different authentication methods. Since in IoT there are > different technologies we looked for a link-layer independent > solution. Additionally, since some technologies are very constrained, > we needed a very constrained protocol to carry out the process. > > EAP provides flexible authentication, and it has EAP Key Management > Framework which is well specified and working for many years, from > which you can generate generate a fresh pre-shared key (MSK) > dynamically. This is even possible if you do not want to interact with > AAA infrastructures running EAP in standalone mode.  Having said this, > another thing that we looked into was to give support to large scale > deployments. We can ease this process with EAP and its interaction > with a AAA infrastructure, which gains relevance in Industrial IoT and > 5G. > > All these characteristics can be provided by the use of EAP, if we of > course have a lightweight EAP lower layer to transport EAP from the > IoT device. Then we considered the usage of CoAP as EAP lower-layer. > > In this sense, we saw minimal security did not fit our view (no > potential interaction with AAA , flexible authentication, fresh > generation of PSK).  In fact,  the provisioning of the PSK was out of > scope. > > At some level, we could even consider the work complementary. EAP over > CoAP could be a way of providing the PSK for the work of minimal > security. > > > Best Regards, > Dan. > > El 10/12/2020 a las 18:43, MaliÅ¡a VuÄinić escribió: > > Hi Dan, > > Could you be more specific on the point below, what deficiencies > do you have in mind? > > MaliÅ¡a > > *From: *core > on behalf of Dan Garcia > > *Date: *Thursday 10 December 2020 at 10:06 > *To: *Michael Richardson > , EMU WG > , "core@ietf.org WG (core@ietf.org)" > > , "ace@ietf.org" > > *Subject: *Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?) > > As you comment , draft-ietf-6tisch-minimal-security - offers > minimal security and has several deficiencies that can be solved > by using EAP and AAA infrastructures. > > --> > --------------80C24DC785D13739DD6EBAE8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Mališa,


El 11/12/2020 a las 19:45, MaliÅ¡a VuÄinić escribió:

Hi Dan,

 

Thanks for the clarification regarding minimal-security. The points that you mention below, e.g. flexible authentication or the fresh generation of the PSK, were never in the design scope of our work.

 

While I fail to understand what exactly do you plan on using EAP-over-CoAP for, I do not object on this work being done in ACE if you are willing to spend cycles on it. I do have reservations on the lightweight aspect of this, however, considering that the sequence diagram that you depict in Fig. 2 in draft-marin-ace-wg-coap-eap-06 spans 3 pages and consumes 2 round trips just to get things started! Surely, we can do better?

Yes, we will submit an updated version of the draft.

Best Regards,

Dan

 

Mališa

 

From: Dan Garcia Carrillo <garciadan@uniovi.es>
Date: Friday 11 December 2020 at 18:41
To: MaliÅ¡a VuÄinić <malisa.vucinic@inria.fr>, Michael Richardson <mcr+ietf@sandelman.ca>, EMU WG <emu@ietf.org>, "core@ietf.org WG (core@ietf.org)" <core@ietf.org>, "ace@ietf.org" <ace@ietf.org>
Cc: <garciadan@uniovi.es>
Subject: Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?)

 

Hi Mališa,

My intention was not to turn this conversation into a criticism of your work. “deficiencies†was not the most appropriate word.

What we had in mind was a way of providing authentication  to the variety of IoT devices with different capabilities, limitations or different types of supported credentials. A way of doing that is to provide different authentication methods. Since in IoT there are different technologies we looked for a link-layer independent solution. Additionally, since some technologies are very constrained, we needed a very constrained protocol to carry out the process.

EAP provides flexible authentication, and it has EAP Key Management Framework which is well specified and working for many years, from which you can generate generate a fresh pre-shared key (MSK) dynamically. This is even possible if you do not want to interact with AAA infrastructures running EAP in standalone mode.  Having said this, another thing that we looked into was to give support to large scale deployments. We can ease this process with EAP and its interaction with a AAA infrastructure, which gains relevance in Industrial IoT and 5G.

All these characteristics can be provided by the use of EAP, if we of course have a lightweight EAP lower layer to transport EAP from the IoT device. Then we considered the usage of CoAP as EAP lower-layer.

In this sense, we saw minimal security did not fit our view (no potential interaction with AAA , flexible authentication, fresh generation of PSK).  In fact,  the provisioning of the PSK was out of scope.

At some level, we could even consider the work complementary. EAP over CoAP could be a way of providing the PSK for the work of minimal security.


Best Regards,
Dan.

El 10/12/2020 a las 18:43, MaliÅ¡a VuÄinić escribió:

Hi Dan,

 

Could you be more specific on the point below, what deficiencies do you have in mind?

 

Mališa

 

From: core <core-bounces@ietf.org> on behalf of Dan Garcia <garciadan@uniovi.es>
Date: Thursday 10 December 2020 at 10:06
To: Michael Richardson <mcr+ietf@sandelman.ca>, EMU WG <emu@ietf.org>, "core@ietf.org WG (core@ietf.org)" <core@ietf.org>, "ace@ietf.org" <ace@ietf.org>
Subject: Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?)

 

As you comment , draft-ietf-6tisch-minimal-security - offers minimal security and has several deficiencies that can be solved by using EAP and AAA infrastructures. 

-->

--> --------------80C24DC785D13739DD6EBAE8-- From nobody Tue Dec 15 11:20:01 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228E33A16DA for ; Tue, 15 Dec 2020 11:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JiRtJk_jPCkM for ; Tue, 15 Dec 2020 11:19:57 -0800 (PST) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2074.outbound.protection.outlook.com [40.107.20.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA0F43A16D9 for ; Tue, 15 Dec 2020 11:19:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=G434dwXxU+b0xRYkwjtTGbF7SuunJFvSp97JfjD53yeHiwVf/OR98Cpfpn4c/f1I7o/FJ9uZ28tlU7z8JJdxuF86+aNW9u/lNkiBkmzlLctGktMSgJm/WQVEVDw28abOa1LU2ePb/NlaoD3GqPomxIyy5ws/+z08dt7U2hhAxbGGrD8JORpNtVq3Y2QobBep3VN4V1X+Z7T7mYDh4AWuh802JJg5x8D1n+mUtwZtMpUfUIY3+SwcDFUB6qG/TP9dNse+xKHYO9EtoN3XO3jsztd0RzyX8HcwpsWWdW1Gb1jaF1Z5PGPI/8j3N0002cieeLcYHw3ElKG/wZmy2vI6wg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/n78vjyoaWdphtr839wLM+rpVstVjUWIpOfiIMO9krg=; b=DC4Ev1R9rx4+a78JSDRBAeum2e/y5/kzEksBNe4Hf9ih7xlRId+qPLtrHXqA23cgtugJlcAGKlhCBMlaWAAHa3Jg4G4j78nQxQbwJNOdoy+/pj6xDDrBQ1oB2w1jr5WYW6lzcazC8kJF83BUPELfx1Q/7RnxzrlJ4KnBZv6pyOg/1XplxxHkzoFRL6O4z9YQNhP4PBxOUcklaNb5eom7z/pJwZGDBL3jPkawRIXOBPw2TsexMQ8x2UCl5E3qPJBCqT6E34gN8rW9M73g2GkVac6P46Hmwfz0YfdDPyasZvofXZVt7q2chQC9cXg1M8Bn0tf+ob3khHPeFb7LJio3Dg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/n78vjyoaWdphtr839wLM+rpVstVjUWIpOfiIMO9krg=; b=QLv1WXwRmgwnhaK1Wa6NWUpzuZSS6u/D2DXm+PIi88PoXZJte2W1kdLDXb0PVNYMcdFWP+zRkaH4jmEzMq00I+8UzoGLBDvBYOIyQcxkDCm9GWaacpb8bhNYQ8JBvLLpgRZQJxPqXEMaAyseQU86SGb6oEFbNrKjOXPF0smUtOA= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB6P189MB0581.EURP189.PROD.OUTLOOK.COM (2603:10a6:6:31::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.20; Tue, 15 Dec 2020 19:19:53 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0%7]) with mapi id 15.20.3654.026; Tue, 15 Dec 2020 19:19:53 +0000 From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" References: <524bd9f3-e062-26ad-a5d0-93de7098ac39@ri.se> Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: Date: Tue, 15 Dec 2020 20:19:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <524bd9f3-e062-26ad-a5d0-93de7098ac39@ri.se> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="EVJ6hfECdTVWr9sVjYH1Ktuz8AocqMjxn" X-Originating-IP: [37.120.209.204] X-ClientProxiedBy: HE1PR0401CA0083.eurprd04.prod.outlook.com (2603:10a6:3:19::51) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.3.7] (37.120.209.204) by HE1PR0401CA0083.eurprd04.prod.outlook.com (2603:10a6:3:19::51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12 via Frontend Transport; Tue, 15 Dec 2020 19:19:52 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b9e1ab1d-37e1-4205-923c-08d8a12e6676 X-MS-TrafficTypeDiagnostic: DB6P189MB0581: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6790; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Dow8b19u4XnFn76ubNinEWtFUnm1Yim1lVPDwIaHyPCAVX6KlA633HoKahQlkHvKqDODbjGBs8TI68wOSUlDuXyhZqpEVsETk1jINBL5nyRIHrkans/ymt0Z2EbixMamibXQJM7rYo5RoeDQCdgrZdYKGAHo21ZkdxZ8ErjAuXbZ08Q7XYgXzVfzYqUNx9t/hSA5BFZbJKK2I3BJI/Es/+21rGG1fAlKQHLNvBo2154N4vAOfN+DRVKjPl2vmA/xEsg/z+Sl78qvvgOBDCupaxoWStG+UWuI+5/1psEjb/+wp0tMi9IplkLLYeXiRFu6ANkD9cGuHuhOqPBa6dDsdy6g7wHLS06TFbTu3OZOPBpjhL3lU7k/ImOMUd6m5yOxc0VtAEvGrv5h3XsSOybGBKWeG72GDL1sUPm1b4SW9is753Ln6j9BZqlptePuttyMUHBea1yMDSX1D16aHBdu2yNLTDo+uijdxQOlAJUmK6TbJI469TIODrbHniWrlAYI X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(346002)(376002)(366004)(39860400002)(66946007)(52116002)(16526019)(83380400001)(44832011)(2906002)(33964004)(31696002)(86362001)(235185007)(186003)(16576012)(966005)(8936002)(478600001)(31686004)(5660300002)(36756003)(66556008)(6916009)(21480400003)(8676002)(2616005)(53546011)(6486002)(66476007)(26005)(316002)(6666004)(956004)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?VEZFSGJ3WEVSUDdVWE4yRWdnRlNNL0YvV0dRNmNzbi9lYlZ6VExVRUtacGE2?= =?utf-8?B?RFErM2pKTnkzWG5FN2FZOExGMHl5TlF1aFY0ZldKTzBPTWpZLzNzaUZJcTZY?= =?utf-8?B?NDRRd0pBVkswMTk4aWZWeDlOS3h2allpRzk5dCtRQVE0QjhIbEVZazNua3Yx?= =?utf-8?B?dGlQSE9QN1VlNjhNRlM1U09xSkpXOE8zaW9nOXV1OHpZNXE3aTlIK29oWldP?= =?utf-8?B?THJHK3pNUDRZbGQvOWw0ejNWbFIybXVjb0d6ZHNhbW9PVitsVGJvblg1Y2Jv?= =?utf-8?B?TGtpSGJrc0s2NlhKanRKU2VheXRQbWJMMncyTEZOZHdKaHh4OXBMbnUzby9Z?= =?utf-8?B?dmFxZmxZNGpNdnUvM1BRd2prWWI5VlptU3dHeDNPZEpCZDk5TXNINHh0Ykpa?= =?utf-8?B?VkpaakRXaXFDSlhLeXpzYnpzVmFERFJJLzBvK3VRbGM3RTZ5ZU9KWmdNNWFJ?= =?utf-8?B?Rm85eW05c0FMQkZNakxNemJraG03U2xSbWNXZWNSbDUzVGR4QkRISDJ1WXY3?= =?utf-8?B?RGJiSzRUUWxwM0xXUy9iWXZ6LzZ5UmYxcTJFd0ZnVFZQYzFsbGhvN2U1TmN1?= =?utf-8?B?dHZ5U01oVHkrcWRQbUNMM2M2VWpXUDBFQkxhSVZjRk95d2JuSXR6Z2RQVmdi?= =?utf-8?B?cGduL0tBWnMrUEE5cHM5REJvaTBUcjVNMGFQYTRycTYyeWdxNUlmQ3VBQlpz?= =?utf-8?B?dDdXanVDK05udmQvREU5czc4TWFxQ0hBSk55WVlZQzBnS2FOU3EzOUhpZEM1?= =?utf-8?B?Y2dHaHRjVldGd3YzTi9iV2VjNVZNM1pnQlNrZXRlK1R6ZlA0VkJVeEtMR2lY?= =?utf-8?B?U2t0MzJRRzBDNlpwQ3JsS205U3RDQ1U0TkJZMDVnZmc3QjREUlVoeXo3a3Zy?= =?utf-8?B?aDdlcU9LVlhiaithWkZRSHpSMVh4M2hxRnd1b3JwQmNaeGpxeUN1ZDNYbmpF?= =?utf-8?B?aVcyZjJZZldkSU1PcCtEUW40LzZlZmkwSHNjSXVFMUR1aG9nUFEyOTFGYTJS?= =?utf-8?B?SG4ydGFkRjlydHVldUdMMkMxaWlsZnVUQ1RDdXQwVWYxTUUxRFBVcXBya25q?= =?utf-8?B?R3U2MThORnd4VHhwbk8vc3FsTGdwa3UwM3JBeVpBTGdxMnErWC9LUmhMcnZl?= =?utf-8?B?UDFSMkVLUFIwSjg3RVlwN1dqSVFZSThuakcwUlMwcVE3S1VJeWpzaW1EdFNC?= =?utf-8?B?UXRGOXdwRENXT1dUbDJ4b040RkhiZnVRNXF2UjR4UFZNaWc5ZEFoK1IxbURj?= =?utf-8?B?V1B2K0NqSDJFejJNRUh3MmpBeGIzeU0yb0xJZjlFSnFLRlc5OFZLbzU1WmtL?= =?utf-8?Q?79UBJ72qxCSGXRr5IEB8ydzPnVx62SqeSk?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Dec 2020 19:19:53.1543 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-Network-Message-Id: b9e1ab1d-37e1-4205-923c-08d8a12e6676 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Oqrl27+lWTFWe/j9uEiENSqjHPVvAMIuvwSiTIc/ZP7KA3RPRFH9B4HBu6cJEp02hG9ftEsWcTxzSdnabqcYKg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P189MB0581 Archived-At: Subject: Re: [core] Doodle for CoRE interim meetings X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2020 19:20:00 -0000 --EVJ6hfECdTVWr9sVjYH1Ktuz8AocqMjxn Content-Type: multipart/mixed; boundary="SDfDY3vFYyYc09fmw7f1hnULE7QiEvEuQ" --SDfDY3vFYyYc09fmw7f1hnULE7QiEvEuQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, Based on the Doodle poll, we are going to have our virtual interim meetings at 15:00 - 16:30 UTC every other Thursday, starting from the 21st of January and until the 18th of February included. Best, Marco and Jaime On 2020-12-04 09:12, Marco Tiloca wrote: > Dear all, > > We are planning to have regular virtual interim meetings, recurring > every other week, starting from the week 18-22 of January until the IET= F > 110 cut-off. > > As usual, we will alternate with the CBOR interim meetings. > > Please, cast your preferences at the Doodle poll below, by the 14th of > December EOB. > > https://doodle.com/poll/tku4y89rtdmmrq4t > > The options in the Doodle refer to the week of the first interim > meeting. The following meetings will occur every other week on the same= > weekday and time, until the end of February. > > Best, > Marco and Jaime > --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --SDfDY3vFYyYc09fmw7f1hnULE7QiEvEuQ-- --EVJ6hfECdTVWr9sVjYH1Ktuz8AocqMjxn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl/ZDFAACgkQ7iZktA5Y 2kOlSggApCQfQ76ux2OtVYMLB4u8DgcSbSUFZ3vfKfo8n7pwWA4KRxDF3Bgaejz5 nFW5xWIxLPlilpEn8ozwr6sdm9cuQ2cBqTVVnf5eC702wXC+/C9kzlvPsYtCF4fW DdkRWqmvkRhyLxrptYOGNyrEgb55f2pIfgBBoxc6FCdPkFNFXPHR54L642z9sQwp 1vl5tbtqztv9TwAPQUvNr86OpP4csn8SAsbc7+LZ4kPeklIkC2tzUvyFWFKqPEH7 hW5G6niHtTgZ0TKXQdH2amNA4Kzx1p7O0fLwapuftIXKSVml/0wsqV0+Ic8gp+YC fRdH68ipzUmJq/xR/HQqG+4F4w/aGA== =GNdq -----END PGP SIGNATURE----- --EVJ6hfECdTVWr9sVjYH1Ktuz8AocqMjxn-- From nobody Wed Dec 16 11:02:48 2020 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C1CB43A0B08; Wed, 16 Dec 2020 11:02:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160814536666.30902.8578233949911526811@ietfa.amsl.com> Date: Wed, 16 Dec 2020 11:02:46 -0800 Archived-At: Subject: [core] Constrained RESTful Environments (core) WG Virtual Meeting: 2021-01-21 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2020 19:02:47 -0000 The Constrained RESTful Environments (core) WG will hold a virtual interim meeting on 2021-01-21 from 16:00 to 17:30 Europe/Stockholm (15:00 to 16:30 UTC). Agenda: (No agenda submitted) Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m790e95229319dac1566d4677f2067d56 From nobody Wed Dec 16 11:03:07 2020 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C62F3A0EC3; Wed, 16 Dec 2020 11:02:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160814537934.28453.11555686334094048895@ietfa.amsl.com> Date: Wed, 16 Dec 2020 11:02:59 -0800 Archived-At: Subject: [core] Constrained RESTful Environments (core) WG Virtual Meeting: 2021-02-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2020 19:03:06 -0000 The Constrained RESTful Environments (core) WG will hold a virtual interim meeting on 2021-02-04 from 16:00 to 17:30 Europe/Stockholm (15:00 to 16:30 UTC). Agenda: (No agenda submitted) Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m19b9f925e95745c07e366296aa99a8ed From nobody Wed Dec 16 11:03:17 2020 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B78DA3A0FD1; Wed, 16 Dec 2020 11:03:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160814539173.20251.15673283691956949466@ietfa.amsl.com> Date: Wed, 16 Dec 2020 11:03:11 -0800 Archived-At: Subject: [core] Constrained RESTful Environments (core) WG Virtual Meeting: 2021-02-18 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2020 19:03:16 -0000 The Constrained RESTful Environments (core) WG will hold a virtual interim meeting on 2021-02-18 from 16:00 to 17:30 Europe/Stockholm (15:00 to 16:30 UTC). Agenda: (No agenda submitted) Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=mb6a8494e161c079941cba71c5c26a212 From nobody Sun Dec 20 04:31:47 2020 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3FA3A0FB0; Sun, 20 Dec 2020 04:31:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yoshifumi Nishida via Datatracker To: Cc: core@ietf.org, draft-ietf-core-fasor.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160846750677.2364.7100486944014136268@ietfa.amsl.com> Reply-To: Yoshifumi Nishida Date: Sun, 20 Dec 2020 04:31:46 -0800 Archived-At: Subject: [core] Tsvart early review of draft-ietf-core-fasor-01 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2020 12:31:47 -0000 Reviewer: Yoshifumi Nishida Review result: On the Right Track This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. Summary: This document needs clarifications on some points. I might miss something, but I have concerns on the proposed logic. Because it seems that it doesn't exactly follow exponential backoff requirement in rfc8961 and it's possible to become more aggressive than normal backoff algorithm in some cases. In my understanding, in FAST_SLOW_FAST state, the 3rd or later RTOs can be shorter than 2nd RTO. Similarly, in SLOW_FAST state, 2nd or later RTOs can be shorter than 1st RTO. For example, when slowrto = 4.0 sec and fastrto is 0.25 sec, then RTOs in SLOW_FAST state will be updated 4.0, 0.5, 1.0, 2.0 secs,... on each retransmission. But, I am not very sure if setting shorter RTO on the later retransmissions is a good idea unless we have good knowledge on the congestion status in the network. I would like to see some more discussions and clarifications on this point in the draft. BTW, if RTOs will be updated something like, 4.0, 1.0, 2.0, 4.0 secs in this case, it looks better to me as it'll be conservative than normal backoff algorithm. The algorithm would look setting longer RTOs in some special cases while following backoff algorithm. Some minor comments: 4.1 "We call this normal RTO or FastRTO" -> How about using just one term? It seems that both terms are used in the doc. But, it looks a bit confusing. 4.3 It might be good if there's example diagrams here so that readers can understand how algorithm work easily "First perfom a probe" -> What is 'probe'? Thanks, -- Yoshi From nobody Mon Dec 21 00:10:19 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBE03A0EA0; Mon, 21 Dec 2020 00:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDToPBhkKiXD; Mon, 21 Dec 2020 00:10:13 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80073.outbound.protection.outlook.com [40.107.8.73]) (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 491533A0C0D; Mon, 21 Dec 2020 00:10:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CKiBT8mCbYyqchUW38woi+5jUsTilWN3l3noOt0iXf3LANpeaB4EiNumMwhSJE3D1FAXzMN4GCtUZQ/Xr2oQxUMFVVaxEi4quOwvLo0AqxlqRt9Wt+3bvh/5Lg25TAlO+CdkJR3Azh96ruzEHtfNoXSH6d5XWggoCiC3Us5SyH11vfrQw24Ypp4oS5oPdxPvNZx+xVPKFDBZKmYzwBhi54QWrV0j1NAHXRh2Unj8kPlJG3j00b0quMDv+H7XM0KiEvPIyLfBzf6YxSOPFsExq7CHXKdyHN1E+o36suHPb7vtQ66/2shzWTLL2J0e2KeMiU74M10yrMpjsEuGSnvzkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7GdYByu7o5bRufuk5UNMGoZZWj9C9GCual2Yg6Iubrc=; b=ffDKxgWLSxnZc9Jde//noPkdePHiJLVACGdR9Qksa4KnLIdhTDcRTvw2BM/DMYqv/PI9bYNlhwYVTqBxngzAXgJwWdKg5bGZmEINyMrLQCa52esA7cWqF0HIW4J21Yj75hy90y9WZiBoQCgNjrgg/sQ0rnqUgD1Zs2llOtR1lNQmpZx7qEadxbxcqb69lmkKkgJxqDEEUkHpLTM/vqVi5YvubbVSo5R6yXillE1JJK35aQMWN7M/frKm8fOgopgQ8zpneUY+BhJj/omwtM/FOmil3ZR7y/+f6ibS1iwsJ0pjyCEV3WWUIlgEsHniJ+eKQlwlqPtfWfQuja+sxcDsfw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7GdYByu7o5bRufuk5UNMGoZZWj9C9GCual2Yg6Iubrc=; b=KkF0zPlLK7zBhd/l2LYEFqJVVcKYBE1Bhhjf5nB+ur6enQeEfVQTVJB12A5FMBwhVpI4f6K4P0ORUXyieDPbPjn4B4Ek0Edgx+BkIZYchtr+/Mgt2/hnMfQt/O9ps3qbPEV/m9TcOU/H5dPj9g5CuxPXyvuuD25yV1OKaFlzURQ= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB8P189MB0698.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:127::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3676.29; Mon, 21 Dec 2020 08:10:10 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0%8]) with mapi id 15.20.3676.033; Mon, 21 Dec 2020 08:10:10 +0000 From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Cc: dots@ietf.org References: <263d6f84-4a57-2085-288f-068b1d78f7ae@ri.se> Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: Date: Mon, 21 Dec 2020 09:10:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <263d6f84-4a57-2085-288f-068b1d78f7ae@ri.se> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="eOEMrsvD4dU5YvhOvcvvYZQfVbHbvK1hO" X-Originating-IP: [91.132.138.180] X-ClientProxiedBy: HE1PR08CA0047.eurprd08.prod.outlook.com (2603:10a6:7:2a::18) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.3.6] (91.132.138.180) by HE1PR08CA0047.eurprd08.prod.outlook.com (2603:10a6:7:2a::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3676.29 via Frontend Transport; Mon, 21 Dec 2020 08:10:10 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 3b5821a5-a691-462e-9457-08d8a587d63a X-MS-TrafficTypeDiagnostic: DB8P189MB0698: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:5236; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ugKwGHZHaBrhsljHy4MjpiYDAAJs58hxUSXTOMoEfqBm48opAobMj1v7S0RH4NNbd/Eg6NTP31Wy8PnXkraNYp6pM0ggmtLfE/M+R0O53VWPCXG9qnLbqoNSYf+EmP7GSDM2NzNkQfV41vaR67yEfjq//pO7zlczZ5RrRcKuta8nUOSwcRkKJAciGEkpIVSMk5GzMqe0VAWWeClSy3ipYN9qdSE0Q0abnDLUYbjmDYSglW3KyYoq9kWS9ExBR+VUp52G5T7KuTMVPcXNXkpXLbhFgmTohMUcSrHTGTxU0vSTEax/VlkvgPHrVEPOf203yRY6mfST1pTaRti0A0TANcRsjBjxYjgY00BYTfn7g129BL9exp8UrnFbYrPmcS6HqemrPymfGQMQbtQWQj5OhmBA7Zhy7GHelnNkLK4Wdiz7NVSbqfTPIODHnnANyRWrF4La8zEuQNT2C9RwGazxxHVIfgjTzIcDXLk3MN9icAUPjYOdaNOzqAPiNsceTkm9CCLpKoUemqkAGDu2mBlrzU/duafoEiyyAn987lpV0aBAaq30DFm6PjrHPr9kT19w X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(39850400004)(376002)(346002)(396003)(136003)(366004)(6666004)(16526019)(21480400003)(186003)(83380400001)(478600001)(86362001)(66946007)(36756003)(16576012)(316002)(966005)(66574015)(31696002)(44832011)(5660300002)(4326008)(450100002)(6916009)(6486002)(956004)(26005)(235185007)(33964004)(2616005)(52116002)(8936002)(8676002)(31686004)(66476007)(66556008)(53546011)(2906002)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?U1gxWDBhZjV5M2tqVTFiL1BSUlppUnJjOWtDYVdaVGliN1VxakorcVhYM1Nx?= =?utf-8?B?a01mRDAva0NFeDd2NHR5TmZZazdBOXZmTjZveFdzNEh0ZWVQVkZPdzJlVkxt?= =?utf-8?B?b0xzaVU5VkRSbEVHOElqTHNpWWtpbzZMUnhid3FhTXRaMEpUd1RQVGxuamRV?= =?utf-8?B?S1h1aXdtUlVqMTlQMlpaZ3FmMFhKeE9aODg4SzB4RlN3QlJLWmVqcWI1V1Er?= =?utf-8?B?UkpMdVU0STIrRmtUWFpuTTU0YzgvRjBXbnNlQSthNmw0eXhla0E0TS83YnN5?= =?utf-8?B?dUluWG1TUzNkVlFBc1E1U0l1ZHlUUTYrbW5YRHE0NjRtSlJYMlBNdzZUM2dD?= =?utf-8?B?akpDeWtCK0Rkcit3WXpra2RMUVl0b043U1FUODhXNEF6RE1yU0l1a3lPWEFM?= =?utf-8?B?U3dWNGZBTEhLaW5zRG00eExNR1JGU09hQTNOMElueHh5VHBEd2VUanV6dC85?= =?utf-8?B?TUIrNm1PV2VoQnU3Z3FMSG5qUHJ6M0w4aWtlcFBWSVh6VGUyM2FJRmU5OThx?= =?utf-8?B?UWZ0Y3RrWHphQ3E3NG5LNHcvOXBoNnV5SGUvL2k2L2ZRWHlLb1V0VTNINE5I?= =?utf-8?B?V1EvUE9uTVl0Z3ZDemFPbjdtcHBMTGRVZFgzZ2hRS1ZCMlVVT2dHKzVnLzVX?= =?utf-8?B?ZS9wMFdFRkJKQUNQbCtsWDl1M21WZlBBb1Q5Qk1NbGdvNXhJaXRrL0RRTkpK?= =?utf-8?B?YVFDT0hoWXVVOTcxVmRtd3pKeTRaQTR5Wjd5QmFPLzNnVVZ0NExIZjRtQUx4?= =?utf-8?B?Q1NsUlNOcWUrbUNaMzJPeUVQN014aVVNeWhSQmhJTklPcEVab3ZELzA3M1dl?= =?utf-8?B?NHpZYnA4Mk1iQU41UFJTUGZYMC9GcUhHTzJBTVNpWDFKcnRHNTVqZ3pnQWZl?= =?utf-8?B?ZmZteEVzTnU3ZnJPTXdha2d2VFFEbXdHdjdBYU0xU2U2SWJKb1RrdTJpcnpP?= =?utf-8?B?T24xUWdBMzYzblc2bGJtUUhaU0luN1pjVjFkMjF3QkhaWFZNY3ZlMzNqbXVS?= =?utf-8?B?NTRWc3F1NFp2b2UrYVpyZlF3YTJBK0dmQUJLRUhsRmM0eCtPWU5pdW1sa3hJ?= =?utf-8?B?MmtnVFRMWTRkTm00VVRxbHQrT0gzSlZUTmdFU0ozSDlmMnRLL2tGU0VlaVdN?= =?utf-8?B?TXFXQjNac3g4SHVmZi9TaVIwV2NZRXFFTk44R1RBeVdtdWw5Z0ZTc3NIeFZ6?= =?utf-8?B?L3FQTS9wTFZLckZ6bEU5UmkzUDF4eTh3SklzSklzUThHMEd1TENjRG5DSUg3?= =?utf-8?B?bWhYY1FXSnQyRDVEaTNueVg5dHlLRjU1bFNsakFERzkwcldLSmMybjF2K0xV?= =?utf-8?Q?qUP/LaWqOSzZXPak+Kpe/TJUSHe+lo2hRl?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Dec 2020 08:10:10.5768 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-Network-Message-Id: 3b5821a5-a691-462e-9457-08d8a587d63a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: tX7Ei2TDzrHJKsixZJtICJGRBqYErbsRr8RpbsPzSnR1FK5y7LQlE5yaRmOAb3HZPHgz/6Xk0nPEwR++63CKhw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB0698 Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2020 08:10:17 -0000 --eOEMrsvD4dU5YvhOvcvvYZQfVbHbvK1hO Content-Type: multipart/mixed; boundary="64udCFNJUzVwYHSDGAmrOlwJDpKwn2L8v" --64udCFNJUzVwYHSDGAmrOlwJDpKwn2L8v Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi all, Please, see below some comments for this WGLC. Best, /Marco =C2=A0 [General] * s/CoAP endpoint sender/CoAP sender endpoint * Please, replace the references to RFC 7049 with references to RFC 8949.= * There are six instances of "CoAP session", which is not defined in RFC 7252 or RFC 7959. Do you simply mean "block-wise transfer" ? [Section 1] * I think that the heading of the current Section 1.1 can be removed, so that Section 1 starts simply with "The Constrained Application Protocol .= =2E." * s/and further updated/and was further updated * s/loss; which/loss, which * s/informs the CoAP endpoint sender either successful receipt or/either informs the CoAP sender endpoint of a successful receipt or * s/that have been not yet been received/that have not yet been received * s/will both generally/will both be generally * The last paragraph in Section 1.4 can be expanded to mention OSCORE as an alternative when DTLS is not used. [Section 3.4] * As to "If the server receives multiple requests (implied or otherwise) for the same block ..." , I guess the word "requests" does not mean CoAP requests, since the paragraph is talking about a single actual CoAP request. In fact, it seems to refer to the multiple needed blocks indicated by the multiple Q-Block2 options in a same CoAP request. =C2=A0=C2=A0 If I'm interpreting correctly, this tries to cover a strange= behavior from the client that sends multiple Q-Block2 Options in a same CoAP requests with the M bit set, such as: 2/1/1024 , 3/1/1024, 4/1/1024; but still the server has to send back blocks 2, 3, 4 ... until the last one only once each. =C2=A0=C2=A0 =C2=A0=C2=A0 If this is correct, how about the following rephrasing? =C2=A0=C2=A0 =C2=A0=C2=A0 "If the request includes multiple Q-Block2 Options and asks = for a same block multiple times (e.g., through the M bit set), the server MUST only send back one instance of that block. * s/if this is the case/if this is not the case * s/Option whichever is/Option, whichever is [Section 3.7] * s/and MUST have the same value/and MUST preserve the same value in each of those payloads. (just to avoid reading it as Size1 and Size2 must have the same value) [Section 9] * I suggest to add one more example in the end, where Q-Block2 is used in a request with the M bit set. As a separate continuation of the example in Figure 7, this can be the case where, after observe being triggered one more time, only the first block for a new ET=3D24 reaches the client, which can use a single QB2:1/1/1024. [Section 11] * As mentioned for Section 1, more can be said here for when OSCORE is us= ed. On 2020-12-07 18:35, Marco Tiloca wrote: > Dear all, > > Following the recent clarifications from the authors [1], this mail > starts a Working Group Last Call on: > > https://tools.ietf.org/html/draft-ietf-core-new-block-02 > > This WGLC will end on Tuesday, 22nd of December. > > This WGLC is also copied to the DOTS WG mailing list. > > Best, > Marco and Jaime > > [1] https://mailarchive.ietf.org/arch/msg/core/MJRxWldea5EOchYJRBOmkdvj= iLI/ > --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --64udCFNJUzVwYHSDGAmrOlwJDpKwn2L8v-- --eOEMrsvD4dU5YvhOvcvvYZQfVbHbvK1hO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl/gWGAACgkQ7iZktA5Y 2kP8Ygf9F1wUoMx4gvQNIba9Nqlh3toLQW9KtH7H8uiO/FujvVyO0GT/3Wa+VcRd vl9FrSizV8f2gKcFpU2WbZwvGk7HW9ATQfr8nwMrjM6pFMXqwVeaFetr1u5QJDq5 ljksZJEljw5lXYFq6aOMsCWNnBlXs7LIo5PKYhBn9ZSYeoph+R2L6Kh9RIMMY7wi pjXO3MfUp2wqJzhWGb0cDqMNTh5cShhV1/DbLB00gT5dlgqHaE/rpI0cKWbF1hUp x8Dr4BPaEQyHokjTjMTEvc8cXtRiC8F6He4ItIuf9Zr756pYRTWjTZzEKeyBbX23 YVyDtKPHbOON14wrKDVx+w4WXltHQA== =C/zs -----END PGP SIGNATURE----- --eOEMrsvD4dU5YvhOvcvvYZQfVbHbvK1hO-- From nobody Tue Dec 22 09:58:06 2020 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1427A3A11D6; Tue, 22 Dec 2020 09:58:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <160865988502.15440.5758314384953241555@ietfa.amsl.com> Date: Tue, 22 Dec 2020 09:58:05 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-new-block-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2020 17:58:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : Constrained Application Protocol (CoAP) Block-Wise Transfer Options for Faster Transmission Authors : Mohamed Boucadair Jon Shallow Filename : draft-ietf-core-new-block-03.txt Pages : 27 Date : 2020-12-22 Abstract: This document specifies alternative Constrained Application Protocol (CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2 Options. These options are similar to the CoAP Block1 and Block2 Options, not a replacement for them, but do enable faster transmission rates for large amounts of data with less packet interchanges as well as supporting faster recovery should any of the blocks get lost in transmission. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-new-block/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-new-block-03 https://datatracker.ietf.org/doc/html/draft-ietf-core-new-block-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-new-block-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 22 10:01:36 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 352343A11D6; Tue, 22 Dec 2020 10:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 e8BuP8olZOsP; Tue, 22 Dec 2020 10:01:29 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17B293A11D5; Tue, 22 Dec 2020 10:01:29 -0800 (PST) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 4D0kfv4gTkzFqMB; Tue, 22 Dec 2020 19:01:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1608660087; bh=zmp05u9SivFw0GjfNhWAxGUfkOvEYio/AXuOtHrfSJU=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=bwdVuyyXun+Ane5mg1RKLI1jr2YgA3sw7oXSiS/+yXjNhF3P0THzgbHO8WyS5XsAF T6KtpIvCfOFYSFFozhA4g2yfqUWe4JhXPXas39Q+ozU552wySS4+zdanNvBlssYnnf v07VhcaS3p13esPM/0tk9Fdm6Q1YBF28V7+WM10zUrMhj5WQC/j5x/F8IwY6m4bs1k 1q/C4LcGr2IuBpZiQGwwrDcebdKfV1WyEXUJk+aQjoxHmgBRziECzGpvincpZLzdEH QDI4CJDknYaqMAxbufLZ82TUeTjQlDQyMAdJgOhr2aQ5secYc9kSVj1Mrv2mtEujQg EZUouELNJoIJw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.38]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 4D0kfv3jQfz3wbM; Tue, 22 Dec 2020 19:01:27 +0100 (CET) From: To: Marco Tiloca , "core@ietf.org WG (core@ietf.org)" CC: "dots@ietf.org" Thread-Topic: [core] WG Last Call on draft-ietf-core-new-block Thread-Index: AQHW13C+BUBsnnzenkGee3873+vLMqoDaUOg Date: Tue, 22 Dec 2020 18:01:26 +0000 Message-ID: <12182_1608660087_5FE23477_12182_65_1_787AE7BB302AE849A7480A190F8B9330315A119C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <263d6f84-4a57-2085-288f-068b1d78f7ae@ri.se> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2020 18:01:31 -0000 SGkgTWFyY28sIA0KDQpNYW55IHRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLg0KDQpBbGwgZ29vZCBw b2ludHMuIFdlIHJlbGVhc2VkIGEgbmV3IHZlcnNpb24gdGhhdCBhZGRyZXNzZXMgdGhvc2UuIEEg ZGlmZiB0byB0cmFjayB0aGUgY2hhbmdlcyBjYW4gYmUgc2VlbiBhdDogDQpodHRwczovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1jb3JlLW5ldy1ibG9jay0wMw0KDQpDaGVl cnMsDQpKb24gJiBNZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDog Y29yZSBbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBNYXJjbyBU aWxvY2ENCj4gRW52b3nDqcKgOiBsdW5kaSAyMSBkw6ljZW1icmUgMjAyMCAwOToxMA0KPiDDgMKg OiBjb3JlQGlldGYub3JnIFdHIChjb3JlQGlldGYub3JnKSA8Y29yZUBpZXRmLm9yZz4NCj4gQ2PC oDogZG90c0BpZXRmLm9yZw0KPiBPYmpldMKgOiBSZTogW2NvcmVdIFdHIExhc3QgQ2FsbCBvbiBk cmFmdC1pZXRmLWNvcmUtbmV3LWJsb2NrDQo+IA0KPiBIaSBhbGwsDQo+IA0KPiBQbGVhc2UsIHNl ZSBiZWxvdyBzb21lIGNvbW1lbnRzIGZvciB0aGlzIFdHTEMuDQo+IA0KPiBCZXN0LA0KPiAvTWFy Y28NCj4gDQo+IA0KPiBbR2VuZXJhbF0NCj4gDQo+ICogcy9Db0FQIGVuZHBvaW50IHNlbmRlci9D b0FQIHNlbmRlciBlbmRwb2ludA0KPiANCj4gKiBQbGVhc2UsIHJlcGxhY2UgdGhlIHJlZmVyZW5j ZXMgdG8gUkZDIDcwNDkgd2l0aCByZWZlcmVuY2VzIHRvIFJGQw0KPiA4OTQ5Lg0KPiANCj4gKiBU aGVyZSBhcmUgc2l4IGluc3RhbmNlcyBvZiAiQ29BUCBzZXNzaW9uIiwgd2hpY2ggaXMgbm90IGRl ZmluZWQgaW4NCj4gUkZDDQo+IDcyNTIgb3IgUkZDIDc5NTkuIERvIHlvdSBzaW1wbHkgbWVhbiAi YmxvY2std2lzZSB0cmFuc2ZlciIgPw0KPiANCj4gDQo+IFtTZWN0aW9uIDFdDQo+IA0KPiAqIEkg dGhpbmsgdGhhdCB0aGUgaGVhZGluZyBvZiB0aGUgY3VycmVudCBTZWN0aW9uIDEuMSBjYW4gYmUN Cj4gcmVtb3ZlZCwgc28gdGhhdCBTZWN0aW9uIDEgc3RhcnRzIHNpbXBseSB3aXRoICJUaGUgQ29u c3RyYWluZWQNCj4gQXBwbGljYXRpb24gUHJvdG9jb2wgLi4uIg0KPiANCj4gKiBzL2FuZCBmdXJ0 aGVyIHVwZGF0ZWQvYW5kIHdhcyBmdXJ0aGVyIHVwZGF0ZWQNCj4gDQo+ICogcy9sb3NzOyB3aGlj aC9sb3NzLCB3aGljaA0KPiANCj4gKiBzL2luZm9ybXMgdGhlIENvQVAgZW5kcG9pbnQgc2VuZGVy IGVpdGhlciBzdWNjZXNzZnVsIHJlY2VpcHQNCj4gb3IvZWl0aGVyIGluZm9ybXMgdGhlIENvQVAg c2VuZGVyIGVuZHBvaW50IG9mIGEgc3VjY2Vzc2Z1bCByZWNlaXB0DQo+IG9yDQo+IA0KPiAqIHMv dGhhdCBoYXZlIGJlZW4gbm90IHlldCBiZWVuIHJlY2VpdmVkL3RoYXQgaGF2ZSBub3QgeWV0IGJl ZW4NCj4gcmVjZWl2ZWQNCj4gDQo+ICogcy93aWxsIGJvdGggZ2VuZXJhbGx5L3dpbGwgYm90aCBi ZSBnZW5lcmFsbHkNCj4gDQo+ICogVGhlIGxhc3QgcGFyYWdyYXBoIGluIFNlY3Rpb24gMS40IGNh biBiZSBleHBhbmRlZCB0byBtZW50aW9uDQo+IE9TQ09SRSBhcyBhbiBhbHRlcm5hdGl2ZSB3aGVu IERUTFMgaXMgbm90IHVzZWQuDQo+IA0KPiANCj4gW1NlY3Rpb24gMy40XQ0KPiANCj4gKiBBcyB0 byAiSWYgdGhlIHNlcnZlciByZWNlaXZlcyBtdWx0aXBsZSByZXF1ZXN0cyAoaW1wbGllZCBvcg0K PiBvdGhlcndpc2UpIGZvciB0aGUgc2FtZSBibG9jayAuLi4iICwgSSBndWVzcyB0aGUgd29yZCAi cmVxdWVzdHMiDQo+IGRvZXMgbm90IG1lYW4gQ29BUCByZXF1ZXN0cywgc2luY2UgdGhlIHBhcmFn cmFwaCBpcyB0YWxraW5nIGFib3V0IGENCj4gc2luZ2xlIGFjdHVhbCBDb0FQIHJlcXVlc3QuIElu IGZhY3QsIGl0IHNlZW1zIHRvIHJlZmVyIHRvIHRoZQ0KPiBtdWx0aXBsZSBuZWVkZWQgYmxvY2tz IGluZGljYXRlZCBieSB0aGUgbXVsdGlwbGUgUS1CbG9jazIgb3B0aW9ucyBpbg0KPiBhIHNhbWUg Q29BUCByZXF1ZXN0Lg0KPiANCj4gwqDCoCBJZiBJJ20gaW50ZXJwcmV0aW5nIGNvcnJlY3RseSwg dGhpcyB0cmllcyB0byBjb3ZlciBhIHN0cmFuZ2UNCj4gYmVoYXZpb3IgZnJvbSB0aGUgY2xpZW50 IHRoYXQgc2VuZHMgbXVsdGlwbGUgUS1CbG9jazIgT3B0aW9ucyBpbiBhDQo+IHNhbWUgQ29BUCBy ZXF1ZXN0cyB3aXRoIHRoZSBNIGJpdCBzZXQsIHN1Y2ggYXM6IDIvMS8xMDI0ICwgMy8xLzEwMjQs DQo+IDQvMS8xMDI0OyBidXQgc3RpbGwgdGhlIHNlcnZlciBoYXMgdG8gc2VuZCBiYWNrIGJsb2Nr cyAyLCAzLCA0IC4uLg0KPiB1bnRpbCB0aGUgbGFzdCBvbmUgb25seSBvbmNlIGVhY2guDQo+IA0K PiDCoMKgIElmIHRoaXMgaXMgY29ycmVjdCwgaG93IGFib3V0IHRoZSBmb2xsb3dpbmcgcmVwaHJh c2luZz8NCj4gDQo+IMKgwqAgIklmIHRoZSByZXF1ZXN0IGluY2x1ZGVzIG11bHRpcGxlIFEtQmxv Y2syIE9wdGlvbnMgYW5kIGFza3MgZm9yIGENCj4gc2FtZSBibG9jayBtdWx0aXBsZSB0aW1lcyAo ZS5nLiwgdGhyb3VnaCB0aGUgTSBiaXQgc2V0KSwgdGhlIHNlcnZlcg0KPiBNVVNUIG9ubHkgc2Vu ZCBiYWNrIG9uZSBpbnN0YW5jZSBvZiB0aGF0IGJsb2NrLg0KPiANCj4gKiBzL2lmIHRoaXMgaXMg dGhlIGNhc2UvaWYgdGhpcyBpcyBub3QgdGhlIGNhc2UNCj4gDQo+ICogcy9PcHRpb24gd2hpY2hl dmVyIGlzL09wdGlvbiwgd2hpY2hldmVyIGlzDQo+IA0KPiANCj4gW1NlY3Rpb24gMy43XQ0KPiAN Cj4gKiBzL2FuZCBNVVNUIGhhdmUgdGhlIHNhbWUgdmFsdWUvYW5kIE1VU1QgcHJlc2VydmUgdGhl IHNhbWUgdmFsdWUgaW4NCj4gZWFjaCBvZiB0aG9zZSBwYXlsb2Fkcy4NCj4gDQo+IChqdXN0IHRv IGF2b2lkIHJlYWRpbmcgaXQgYXMgU2l6ZTEgYW5kIFNpemUyIG11c3QgaGF2ZSB0aGUgc2FtZQ0K PiB2YWx1ZSkNCj4gDQo+IA0KPiBbU2VjdGlvbiA5XQ0KPiANCj4gKiBJIHN1Z2dlc3QgdG8gYWRk IG9uZSBtb3JlIGV4YW1wbGUgaW4gdGhlIGVuZCwgd2hlcmUgUS1CbG9jazIgaXMNCj4gdXNlZCBp biBhIHJlcXVlc3Qgd2l0aCB0aGUgTSBiaXQgc2V0LiBBcyBhIHNlcGFyYXRlIGNvbnRpbnVhdGlv biBvZg0KPiB0aGUgZXhhbXBsZSBpbiBGaWd1cmUgNywgdGhpcyBjYW4gYmUgdGhlIGNhc2Ugd2hl cmUsIGFmdGVyIG9ic2VydmUNCj4gYmVpbmcgdHJpZ2dlcmVkIG9uZSBtb3JlIHRpbWUsIG9ubHkg dGhlIGZpcnN0IGJsb2NrIGZvciBhIG5ldyBFVD0yNA0KPiByZWFjaGVzIHRoZSBjbGllbnQsIHdo aWNoIGNhbiB1c2UgYSBzaW5nbGUgUUIyOjEvMS8xMDI0Lg0KPiANCj4gDQo+IFtTZWN0aW9uIDEx XQ0KPiANCj4gKiBBcyBtZW50aW9uZWQgZm9yIFNlY3Rpb24gMSwgbW9yZSBjYW4gYmUgc2FpZCBo ZXJlIGZvciB3aGVuIE9TQ09SRQ0KPiBpcyB1c2VkLg0KPiANCj4gDQo+IA0KPiBPbiAyMDIwLTEy LTA3IDE4OjM1LCBNYXJjbyBUaWxvY2Egd3JvdGU6DQo+ID4gRGVhciBhbGwsDQo+ID4NCj4gPiBG b2xsb3dpbmcgdGhlIHJlY2VudCBjbGFyaWZpY2F0aW9ucyBmcm9tIHRoZSBhdXRob3JzIFsxXSwg dGhpcw0KPiBtYWlsDQo+ID4gc3RhcnRzIGEgV29ya2luZyBHcm91cCBMYXN0IENhbGwgb246DQo+ ID4NCj4gPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLW5ldy1i bG9jay0wMg0KPiA+DQo+ID4gVGhpcyBXR0xDIHdpbGwgZW5kIG9uIFR1ZXNkYXksIDIybmQgb2Yg RGVjZW1iZXIuDQo+ID4NCj4gPiBUaGlzIFdHTEMgaXMgYWxzbyBjb3BpZWQgdG8gdGhlIERPVFMg V0cgbWFpbGluZyBsaXN0Lg0KPiA+DQo+ID4gQmVzdCwNCj4gPiBNYXJjbyBhbmQgSmFpbWUNCj4g Pg0KPiA+IFsxXQ0KPiA+DQo+IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cv Y29yZS9NSlJ4V2xkZWE1RU9jaFlKUkJPbWtkdmppDQo+IExJDQo+ID4gLw0KPiA+DQo+IA0KPiAt LQ0KPiBNYXJjbyBUaWxvY2ENCj4gUGguRC4sIFNlbmlvciBSZXNlYXJjaGVyDQo+IA0KPiBSSVNF IFJlc2VhcmNoIEluc3RpdHV0ZXMgb2YgU3dlZGVuDQo+IERpdmlzaW9uIElDVA0KPiBJc2Fmam9y ZHNnYXRhbiAyMiAvIEtpc3RhZ8OlbmdlbiAxNg0KPiBTRS0xNjQgNDAgS2lzdGEgKFN3ZWRlbikN Cj4gDQo+IFBob25lOiArNDYgKDApNzAgNjAgNDYgNTAxDQo+IGh0dHBzOi8vd3d3LnJpLnNlDQo+ IA0KDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBj b250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMg ZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVz IHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJl dXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFp bnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0 YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3Bv bnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmll LiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNv bmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3Rl ZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQg d2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGlu IGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2Ug YW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMg bm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQg b3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Tue Dec 22 21:01:05 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 841F63A0544; Tue, 22 Dec 2020 21:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTSH03xlNQX5; Tue, 22 Dec 2020 21:01:00 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E31C23A048B; Tue, 22 Dec 2020 21:00:57 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 32021407C1; Wed, 23 Dec 2020 06:00:55 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 7F025AB; Wed, 23 Dec 2020 06:00:47 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:bd73:2e62:80f9:8152]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id BCEDA63; Wed, 23 Dec 2020 06:00:44 +0100 (CET) Received: (nullmailer pid 2758466 invoked by uid 1000); Wed, 23 Dec 2020 05:00:42 -0000 Date: Wed, 23 Dec 2020 06:00:42 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: draft-ietf-core-new-block@ietf.org Cc: "core@ietf.org WG (core@ietf.org)" , dots@ietf.org Message-ID: References: <263d6f84-4a57-2085-288f-068b1d78f7ae@ri.se> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EQlrsLUWml5Hqwie" Content-Disposition: inline In-Reply-To: <263d6f84-4a57-2085-288f-068b1d78f7ae@ri.se> Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2020 05:01:04 -0000 --EQlrsLUWml5Hqwie Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello new-block authors, hello CoRE, I've finally managed to have another look at the document (and it's still the 22nd *somewhere*...). My over-all summary is that while this document has matured quite a bit (and turned out better than I had expected for the special-purpose blocks it is), I think that the topic of response suppression and congestion control sections still have to be sharpened, and the examples could pick a more realistic balance between going all-NON and all-CON (or explain why that's something that wouldn't be done even though the text reads like that's what's expected to be used but maybe it's just me). Except for the first item (which is coming back to the notes for the WGLC), all should be more or less sequential in the document (with forward/back references as needed). * On the downref to No-Response: I don't see the downref as too big an issue. It's a bit odd that that document didn't go through the CoRE WG, but my impression is that it's widely used (on a "when the library I maintain broke it people filed issues" level), and both OSCORE and groupcomm-bis (which is to replace RFC7390) reference it. It's an informative reference because they don't mechanically depend on it, but it shows how well No-Response has been taken up. (Frankly, I'd support a retroactive adoption. I don't suppose we can do that with "adults"?). From how I understand Q-Block to be intended to work, No-Response does not cover all of the behavior (as it's timeout based); still, that document lays good groundwork for what's done here in a rather precise way (see comment on "For Confirmable transmission, the server MUST continue" later on) where this document needs the examples to be fully understood. Based on the later text on MAX_TRANSMIT_SPAN, why not at least acknowledge the equivalence? Maybe like this: > The behavior of endpoints following this draft can equivalently b > described in terms of the No-Response option {{?RFC7967}}: > > For a message with a Q-Block1 option with M=3D1 that is followed by > another message on the same Request-Tag within MAX_TRANSMIT_SPAN [ > or MAX_BLOCK_JITTER, see later ], the default value for No-Response > is 8 (suppressing the 4.xx code that would be returned due to the > incomplete request); an explicitly set No-Response option would > override that." although I'd still advocate just using No-Response for the whole definition even if No-Response is not typically expressed. (I'm not really sure what the correct response would be for an individual non-terminal request if it were to be answered due to an explicit No-Response:0 -- might be 2.31 Continue that's just not used in this specification because it's always suppressed? I'll come back to that -- but then it'd rather be No-Response: 10). * intro: WebSockets (capitalization) * The list of pros and cons (with the cons being almost trivial) does not explain to the reader why these are not a replacement; I suggest to add: * The Q-Block options do not support stateless operation / random access. * Proxying of Q-Block is limited to caching full representations. (The latter might be mitigated by additional text around caching, but I doubt it's worth the effort given it's not part of the use case). * "compromises of": I don't understand that sentence. * "the asymmetrical packet loss is not a benefit here": It never is; what is meant here? * "Updated CoAP Response Code": "This document updates" sounds like a formal update to RFC7959, which it neither is nor needs to be. Phrasing it along the lines of "adds a media type that can be used with 4.08" would ease that. * "Only C and U columns are marked": "The Q-Block1 option is critical, and unsafe for proxies to forward" would be easier to read -- which checkboxes are marked is visible alrady from the table. (Or just leave it for the later paragraphs that say that in more detail). * "Q-Block1 Option is useful with": ... and FETCH. (Also in "Using the Q-Block1 option" first paragraph). * "Is opaque in nature, but it is RECOMMENDED" on being a counter and starting off random: Like other similar suggestions (ETag), this is implementation guidance level and not required for interoperability. Maybe phrase this the same way as the recommendations on tokens? * "For Confirmable transmission, the server MUST continue": This reads like new-block could change anything about that, when all it does is do things on the response level. [1] has a good note on that separation topic. [1]: https://tools.ietf.org/html/rfc7967#section-2 * "If the client transmits a new body of data with a new Request-Tag to": Processing parallel requests is something Request-Tag opens up. I don't see why there's a MUST to that; the server certainly MAY drop the old request, but it may just as well process them in parallel.=20 * "If the server receives a duplicate block with the same Request-Tag": Why? Being silent is the default on nonterminal blocks alredy, but in a situation like figure 5 if the 2.04 is lost, that rule would make it impossible for the client to ever get a successful response. A better rule here may be to say that it processes it all the same (and if the payload is distinct from the first transmission's payload, it should err out.) * "If the server receives multiple requests (implied or otherwise) for the same block, it MUST only send back one instance of that block.": This might be read as "ever" rather than "per incoming request", where probably the latter is meant. * "The ETag Option MUST NOT be used": This is more a factural than a normative statement; it *can* not be used there as the server would respond thusly. It may be used, but then that indicates that the client is trying to verify a freshness. (However, the client should not *start* sending an ETag once it learned the current resource's ETag when still attempting to pull out more blocks, but that's also not a normative requirement but a consequence of those two requests not being matchable any more.) * "then the client SHOULD drop all the payloads for the current body": "Drop" is overly prescriptive; the client may well keep them, but just can't consider them fresh any more. (If the client has ample caching abilities, they might come in handy if the resource goes back to that ETag state). Same for later "the client MUST remove any partially received". * "For Confirmable transmission, the client SHOULD continue to": As above in the other direction, that's not news. * "If there is insufficient space to create a response PDU": I don't understand what that means. (Where are request options reflected back?). * "If the client requests missing blocks, this is treated as a new request.": I don't think the client should even make these follow-up requests Observe, as it already has an ongoing observation. They'd be sent on a different token too, so setting Observe would be opening observation up on that token, which AFAIU is not intended. (Figure 7 example looks good to me in that respect.) (It may make sense to ask the client to keep Observe to make the requests matchable just for the sake of staying in atomic-request mode. Either way, the server should then not accept that observation as it's not for a block 0.) * "First is CBOR encoded Request-Tag": Why? Each 4.08 response can be matched by the token to a unique request that already had a Request-Tag, and the client needs to have kept that token around matched to the transfer to make sense of it. No need to move that value around between subsystems, and just dropping it from here would also remove the need for the "If the client does not recognize the Request-Tag" clause (which would otherwise need clarification as to what it'd mean if it recognizes it but it doesn't match what the request was for). * "limit the array count to 23 (Undefined value)": 23 is the maximum length of a zero-byte length indication, not indefinite-length (31). Both using 23 and 31 here makes sense (up to 23 to have definite length that can be updated in-place, or exceeding that switch to indefinite length if they still fit), but the paragraph seems to be mixing them up. * "Each new request MUST use a unique token": Like above, this is stating something that's not intended to be changed. Congestion Control: * "Each NON 4.08 (Request Entity Incomplete) Response Codes is subjected to PROBING_RATE.": That is unexpected here. At most one such response is sent to each request message, so why is additional congestion control needed? On the other hand, *ever* NON request is subject to PROBING_RATE, so why point out the body of blocks and "GET or similar" particularly? * "a delay is introduced of ACK_TIMEOUT": As I understand MAX_PAYLOADS, this is (rather implicitly) introduced as the package count up to which it is OK to exceed PROBING_RATE temporarily (but after that it kicks in all the harder by requiring to wait until complete-sent-bytes over PROBING_RATE has expired). If that holds, at that time a much larger delay than just ACK_TIMEOUT is needed to get a response from the server: About 3 hours (see later note on parameters). This is the crucial point in the document, and for it a recommendation alone is not good enough. The protocol can be run with a vastly increased PROBING_RATE (however externally determined) and from the point of MAX_PAYLOADS just observe it. Or it has to get feedback from the server; a single 4.08 is probably enough to kick off another vollley of blocks. (How many? MAX_PAYLOADS for every response?). Both can be permitted, but just waiting ACK_TIMEOUT isn't doing any good. * "For NON transmissions": This seems to imply that the full exchange of a body is either NON or CON; I don't see where that'd come from. I'd have expected to read something like "Each individual request can be NON or CON independent of the others. In particular, it can be convenient to send the ultimate payload...". * "If a Confirmable packet is used, then the transmitting peer MUST wait for the ACK": Why? A NSTART > 1 would give it leisure to still transmit. * General on congestion control: It may help implementors if this were split up into newly introduced rules and concepts (that is, MAX_PAYLOADS and the answer to whether you may send MAX_PAYLOADS en block again after having only even one response from the last round, and probably the recommended parameters of the "Also on parameters" comment), and another subsection on how Q-Block behaves well when observing these. Caching: * "are not part of the cache key": How about "are removed as part of the block assembly and thus do not reach the cache"? * "When the next client completes building the body": If the proxy chooses not to let them happen in parallel (which it may, see above on parallel requests, although the server might still not support it and cancel one of them), why bother letting the first finish just to abort it? (IOW: If the proxy does not intend to see both through, which it could if it held back the second until the first is through on the uplink, it could just as well err out of one of them early, but it may also rather see both through.) * Examples: * Figure 5: The ... between e3 request and response indicate the MAX_TRANSMIT_SPAN before sending the 4.08 response. I suppose there should be the same kind of delay between the failed e5 transmission and the e4 response. * If the second burst had 3 requests out of which 2 made it, is there any guidance for which of them the 4.08 would come back on? (In the end, none of them is terminal). * If that e4 response gets lost, does the whole mechanism recover from it in any way? Generally, the all-NON and all-CON examples don't look to me like what I'd be doing with this spec; the mixed "a CON every MAX_PAYLOADS" appears much more realistic. * Figure X: The request ahs M unset and thus indicats a request for just that block. If more than one is expected, it should say QB2:0/1/1024. * New Content Format: I think this needs a media type registration to go with it first; based on that, a content format can be registered. * General on MAX_TRANSMIT_SPAN and other timing parameters: I'm not sure they're 1:! applicable here. For example, MAX_TRANSMIT_SPAN is defined in terms of reliable transmission, but used for NONs as well. (So is the alternative ot 2x ACK_TIMEOUT). For the purpose of delaying a 4.08 or a follow-up GET, it may make more sense to define a new parameter based on MAX_LATENCY and the time it takes the sender to pump out the options (which I don't think we have a good factor for, but may even be negligible here). Could read like this: > The timing parameter MAX_BLOCK_JITTER is introduced, and by default > takes a value of MAX_LATENCY + MAX_PAYLOADS * MTU / BANDWIDTH. > > With Q-Block2, a client can ask for any missing blocks after not > having received any further response for the duration of > MAX_BLOCK_JITTER. > > With Q-Block1, a server holds off any response for MAX_BLOCK_JITTER > unless all blocks have been received. Only then it evaluates whether > to respond with a 2.0x code, a 4.08 with payload, or not at all > (because it responded to a later request). This also brings me back to the earlier matter of 2.31: What is a server supposed to send when no packages were lost, but it's pasing the timeout and wants to help the client flush out more packages by confirming something? It says 4.08 in 3.3, but it's not like there's a hole in the contiguous range. Does it need to send 4.08 enumerating all (or at least some) numbers between the first unreceived and what's indicated by Size1? Or can it just send 2.31 and the client knows all it needs to know b/c the response came to the largest block that was sent and 2.31 indicates that everything is good up to that point? * Also on parameters: This document is describing flow control stuff around a situation CoAP was not originally designed for. Wouldn't it make sense to include a set of parameters (PROBING_RATE, MAX_LATENCY, ACK_TIMEOUT) that's suitable for the DOTS use case? I doubt that PROBING_RATE will be left to 1 byte/second for any DOTS application using this (for sending 10KiB in the initial 10-package MAX_PAYLOADS burst would mark that connection as unusable for about 3 hours if they all get lost), so better give justifiable numbers here than rely on implemnetors to come up with unreviewed numbers or disregard PROBING_RATE altogether. I don't know if it needs additional justification, but an increased N_START may be justifiable there. * Somewhere (never comes up but I think it should): When CONs are used, a 4.08 (or 2.31?) response to a later request can indicate to the client that an earlier CON request has been processed successfully. If the client can match that up (and it should be able to), then it can (and should) cancel that particular CON request. Best regards Christian --=20 There's always a bigger fish. -- Qui-Gon Jinn --EQlrsLUWml5Hqwie Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl/izvcACgkQOY0REtOk veE7/BAAn4ne/XWB98QEaJT90TfRFzL0YogCC6wSv/+sG473p1WoYAF+bDuvna+O Bl7gOvAGEv++0k3ZpGspvSzg3KfpfW18TsIdW9EXpDdGjO0Jag+dUeAjRtwEYLEG pU7TSQo5m1WHXFvpz+RxokZ7jWLIqvl1u/JC0bC+lvt5C5DJ+lSrw2F/TYk9/ctA rtflXRQgz3zl1MHN+g6IYzChWgUjZVtkGb4yyQ2feu6MUnRqJJizOKJNB3yOtrKH ga4B+/2O63Z/Y6YXPxkCt94ITlC4GEABS0UY6Z+YkO44NEJLqjb73uB8WPq3/7+Y +7NjrgaSSVVLI2rSJF8MjjWVyIVySuun5agxK1ZUf6OSt6SVnR7nSrVKO65byKbR PtbL8zdiOlVCX8zIwht5nCJP0xjv4XpduHvVANUxAxpQ6sTFrL0sYXv8LkWC02Ag grU/ZONtPN1wny5pLz5Du9KSoJ50F3RJu5yK6wBUSme/ZgoXy3riZDDD6kFj16N+ YG9GWg2HrQXMyPMCrpaG3SKre+51//g3SeAq2zOiW5SRhLRVau5YPlaZZd7JKgfI jAKiPcUWd38Bjh7mj3dyujzX3Io32oBab+SKy722Sf5WQOQpzg0yxuDC1JS7RHn1 QA+aUunN9fSza3n5+EpKU9V5zXQG2rOPQECOL7mLOmU7CNFPI0M= =7Vbb -----END PGP SIGNATURE----- --EQlrsLUWml5Hqwie-- From nobody Wed Dec 23 00:51:29 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66EBF3A0C61; Wed, 23 Dec 2020 00:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 SMNMV631ef8p; Wed, 23 Dec 2020 00:51:21 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85DB93A0C36; Wed, 23 Dec 2020 00:51:21 -0800 (PST) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 4D16Pg5ZKTz5w9H; Wed, 23 Dec 2020 09:51:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1608713479; bh=dxepGVK25I2mTqu2Xp7n43EmMd7hCeniXY/xAB3g4Gg=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=tDCpMrqJiqxKw61lgoq4p0F6gw2fk9e9gdghGCa0pnszmvoN1pbATAx1Cynv/9Y7D SIoennn1h2XV1SyeNKCCd1btfRFp38TyCtdFOOzME2rsMJk2xb7S1appbDaPEMfDRX W0Z1sYsFM8Tzy4UG+Qa2k4ZHI+DhcCh97rT7Bv+jZuVyAp95RM+tmP6Tp7kimVdgaO cw0/WQsLq6nfXVpgrZgagXLRW73Xwroo/QvtihATUcqxFFjNVZeHwePwEH3du7B/mw WabCirMeSHABeGjUEw7Vis+GkmyvSKR8eO03LqnJsYU9zSIbAFoez1m+MP2+PxB6A7 k5+IbL8+aDZ1w== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.73]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 4D16Pg4RFPz1xp5; Wed, 23 Dec 2020 09:51:19 +0100 (CET) From: To: =?iso-8859-1?Q?Christian_Ams=FCss?= , "draft-ietf-core-new-block@ietf.org" CC: "core@ietf.org WG (core@ietf.org)" , "dots@ietf.org" Thread-Topic: [core] WG Last Call on draft-ietf-core-new-block (No-Response) Thread-Index: AdbZCMK38XVdj8FBRcWoH++pQBizgQ== Date: Wed, 23 Dec 2020 08:51:19 +0000 Message-ID: <18741_1608713479_5FE30507_18741_81_1_787AE7BB302AE849A7480A190F8B9330315A177C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block (No-Response) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2020 08:51:24 -0000 Hi Christian,=20 Thank you for the review.=20 Will focus on your first comment in this reply to ease tracking issues.=20 The text we have in the draft does not preclude No-Response (or any solutio= n that will be endorsed by the WG in the future):=20 Note: A delay of ACK_TIMEOUT after every transmission of MAX_PAYLOADS blocks may be observed even if the peer agent is able to handle more blocks without experiencing an overload. This delay can be reduced by using CON for the MAX_PAYLOADS packet to trigger sending the next set of data when the ACK is received. Nevertheless, this behavior is likely to create other timeout issues in a lossy environment (e.g., unidirectional loss as in DDoS pipe flooding). The use of NON is thus superior but requires an additional signal in the MAX_PAYLOADS packet to seek for a 2.31 (Continue) from the peer if it is ready to receive the next set of blocks. If both endpoints support No-Response, they can use it as a "signal in the = MAX_PAYLOADS" to trigger a 2.31 mentioned in the last sentence.=20 As we don't recommend No-Response (for reasons echoed in your message), it = is not worth to include much more details on how No-Response can be used.= =20=20 Thank you.=20 Cheers, Med > -----Message d'origine----- > De=A0: Christian Ams=FCss [mailto:christian@amsuess.com] > Envoy=E9=A0: mercredi 23 d=E9cembre 2020 06:01 > =C0=A0: draft-ietf-core-new-block@ietf.org > Cc=A0: core@ietf.org WG (core@ietf.org) ; dots@ietf.org > Objet=A0: Re: [core] WG Last Call on draft-ietf-core-new-block >=20 > Hello new-block authors, hello CoRE, >=20 > I've finally managed to have another look at the document (and it's > still the 22nd *somewhere*...). >=20 > My over-all summary is that while this document has matured quite a > bit (and turned out better than I had expected for the special- > purpose blocks it is), I think that the topic of response > suppression and congestion control sections still have to be > sharpened, and the examples could pick a more realistic balance > between going all-NON and all-CON (or explain why that's something > that wouldn't be done even though the text reads like that's what's > expected to be used but maybe it's just me). >=20 >=20 > Except for the first item (which is coming back to the notes for the > WGLC), all should be more or less sequential in the document (with > forward/back references as needed). >=20 > * On the downref to No-Response: I don't see the downref as too big > an > issue. It's a bit odd that that document didn't go through the > CoRE > WG, but my impression is that it's widely used (on a "when the > library > I maintain broke it people filed issues" level), and both OSCORE > and > groupcomm-bis (which is to replace RFC7390) reference it. It's an > informative reference because they don't mechanically depend on > it, > but it shows how well No-Response has been taken up. >=20 > (Frankly, I'd support a retroactive adoption. I don't suppose we > can > do that with "adults"?). >=20 > From how I understand Q-Block to be intended to work, No-Response > does > not cover all of the behavior (as it's timeout based); still, that > document lays good groundwork for what's done here in a rather > precise > way (see comment on "For Confirmable transmission, the server MUST > continue" later on) where this document needs the examples to be > fully > understood. >=20 > Based on the later text on MAX_TRANSMIT_SPAN, why not at least > acknowledge the equivalence? Maybe like this: >=20 > > The behavior of endpoints following this draft can equivalently > b > > described in terms of the No-Response option {{?RFC7967}}: > > > > For a message with a Q-Block1 option with M=3D1 that is followed > by > > another message on the same Request-Tag within MAX_TRANSMIT_SPAN > [ > > or MAX_BLOCK_JITTER, see later ], the default value for No- > Response > > is 8 (suppressing the 4.xx code that would be returned due to > the > > incomplete request); an explicitly set No-Response option would > > override that." >=20 > although I'd still advocate just using No-Response for the whole > definition even if No-Response is not typically expressed. >=20 > (I'm not really sure what the correct response would be for an > individual non-terminal request if it were to be answered due to > an > explicit No-Response:0 -- might be 2.31 Continue that's just not > used in this specification because it's always suppressed? I'll > come > back to that -- but then it'd rather be No-Response: 10). >=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Dec 23 01:14:15 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC86E3A0C93; Wed, 23 Dec 2020 01:14:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 4cKwM_P1PiYM; Wed, 23 Dec 2020 01:14:12 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D6D73A0C90; Wed, 23 Dec 2020 01:14:12 -0800 (PST) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 4D16w15K6Bz2xy2; Wed, 23 Dec 2020 10:14:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1608714849; bh=B+OsC9MxQf86njvwnLQF+gtGHn6muw1P/Sz1rkdhhJU=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=LJX2d6++cNSVeWUD7sNsZviN04gO41RUmJedkOamEfxCnwwoVFFgTWwtJTDMYtKFF bIFISeILFf9dM0iIBOGEpC3r3NGyRVLLI7tKS3gxJ8zk07A7+MwZgH5/wFFJqJRWFm WI5AUkuu4GfrfV6BIRPysyo0BWpyETTaXa7XQVof/xYPunhAf4vTbiOVKveD5bwU9A V0pUCVZqHUBMUI+POLXkALAPn9yv8eKaTa7dcR92Khi/odmrpx2lr+Cmep1p3mhMNP KmRS6gHUFsZnnKqMhQ5fJa0dP+Jw9ejy0NAfmiHBecnd4Tuyuxbnrb3BBZXAD88tO4 IrMLG+8B2IOaQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.26]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 4D16w14D5tz5vMq; Wed, 23 Dec 2020 10:14:09 +0100 (CET) From: To: =?iso-8859-1?Q?Christian_Ams=FCss?= , "draft-ietf-core-new-block@ietf.org" CC: "core@ietf.org WG (core@ietf.org)" , "dots@ietf.org" Thread-Topic: [core] WG Last Call on draft-ietf-core-new-block (Congestion Control) Thread-Index: AdbZC/aihA0VBDFOQyy3pGY3SL4iaQ== Date: Wed, 23 Dec 2020 09:14:09 +0000 Message-ID: <31613_1608714849_5FE30A61_31613_100_2_787AE7BB302AE849A7480A190F8B9330315A17B3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block (Congestion Control) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2020 09:14:14 -0000 Re-, You are completely right that the default probing-rate is to be increased f= or the DOTS case. FYI, this is why we went with the following in RFC8782: | Given that the size of the heartbeat request cannot exceed | ('heartbeat-interval' * 'probing-rate') bytes, 'probing-rate' | should be set appropriately to avoid slowing down heartbeat | exchanges. For example, 'probing-rate' may be set to 2 * | ("size of encrypted DOTS heartbeat request"/'heartbeat- | interval') or (("size of encrypted DOTS heartbeat request" + | "average size of an encrypted mitigation request")/'heartbeat- | interval'). Absent any explicit configuration or inability to | dynamically adjust 'probing-rate' values (Section 4.8.1 of | [RFC7252]), DOTS agents use 5 bytes/second as a default | 'probing-rate' value. We also allow DOTS peers to negotiate the transmission parameters (and prob= ing rate) with the following as default:=20 "The RECOMMENDED values of transmission parameter values are 'ack-timeout' (2 seconds), 'max- retransmit' (3), and 'ack-random-factor' (1.5). In addition to those parameters, the RECOMMENDED specific DOTS transmission parameter values are 'heartbeat-interval' (30 seconds) and 'missing-hb-allowed' (15)." We avoided to include a pointer to these details as these are application-s= pecific and that, even if the draft is motivated by the DOTS use case, othe= r applications can make use of the new block functionality.=20 For NSTART, we already have the following:=20 " NSTART will also need to be increased from the default (1) to get faster transmission rates." Cheers, Med > -----Message d'origine----- > De=A0: Christian Ams=FCss [mailto:christian@amsuess.com] > Envoy=E9=A0: mercredi 23 d=E9cembre 2020 06:01 > =C0=A0: draft-ietf-core-new-block@ietf.org > Cc=A0: core@ietf.org WG (core@ietf.org) ; dots@ietf.org > Objet=A0: Re: [core] WG Last Call on draft-ietf-core-new-block >=20 > * Also on parameters: This document is describing flow control stuff > around a situation CoAP was not originally designed for. Wouldn't > it > make sense to include a set of parameters (PROBING_RATE, > MAX_LATENCY, > ACK_TIMEOUT) that's suitable for the DOTS use case? I doubt that > PROBING_RATE will be left to 1 byte/second for any DOTS > application > using this (for sending 10KiB in the initial 10-package > MAX_PAYLOADS > burst would mark that connection as unusable for about 3 hours if > they > all get lost), so better give justifiable numbers here than rely > on > implemnetors to come up with unreviewed numbers or disregard > PROBING_RATE altogether. >=20 > I don't know if it needs additional justification, but an > increased > N_START may be justifiable there. >=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Dec 23 01:52:05 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2283A0E76; Wed, 23 Dec 2020 01:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q435Khb-I5yl; Wed, 23 Dec 2020 01:52:00 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D84E3A0E74; Wed, 23 Dec 2020 01:51:58 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 645FA407C1; Wed, 23 Dec 2020 10:51:55 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 5CB95AB; Wed, 23 Dec 2020 10:51:47 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:bd73:2e62:80f9:8152]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id A1F6663; Wed, 23 Dec 2020 10:51:46 +0100 (CET) Received: (nullmailer pid 2814293 invoked by uid 1000); Wed, 23 Dec 2020 09:51:45 -0000 Date: Wed, 23 Dec 2020 10:51:45 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: mohamed.boucadair@orange.com Cc: "draft-ietf-core-new-block@ietf.org" , "core@ietf.org WG (core@ietf.org)" , "dots@ietf.org" Message-ID: References: <18741_1608713479_5FE30507_18741_81_1_787AE7BB302AE849A7480A190F8B9330315A177C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Hr1RmnxscrfHuEJM" Content-Disposition: inline In-Reply-To: <18741_1608713479_5FE30507_18741_81_1_787AE7BB302AE849A7480A190F8B9330315A177C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block (No-Response) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2020 09:52:03 -0000 --Hr1RmnxscrfHuEJM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Med, > The text we have in the draft does not preclude No-Response (or any > solution that will be endorsed by the WG in the future):=20 >=20 > If both endpoints support No-Response, they can use it as a "signal in > the MAX_PAYLOADS" to trigger a 2.31 mentioned in the last sentence.=20 > > As we don't recommend No-Response (for reasons echoed in your > message), it is not worth to include much more details on how > No-Response can be used. =20 The only reason for No-Response I echo in my mail is the downref, and merely showing how these can interoperate does not create a normative reference. It's quite a stretch to assume people would read "requires an additional signal" as "could use No-Response". Working group documents time and again have outward references like "One way of doing this is being explored in [draft-...]", which is clearly non-normative, but at the same time allow the reader to get at least *some* indication of how things are meant to be used. What makes things worse here is that as long as this specification does not mention No-Response at all, it is not ensured that it interoperates well at all with No-Response; thus even if a reader can make the jump, they'd have to figure out on their own that it's probably best if No-Response overrides the response behavior of Q-Block. > The use of NON is thus superior but requires > an additional signal in the MAX_PAYLOADS packet to seek for a 2.31 > (Continue) from the peer if it is ready to receive the next set of > blocks. I missed that in the part where I'm asking for whether 2.31 would be produced. That paragraph really opens more questions than it answers: If Q-Block is intended to be usable with something to signal that now would be a good time for a response, then this almost contradicts the "2.31 (Continue) Response is not used in the current version" statement. Either this is a possibility already planned here, then the 2.31 cases should be properly described, even if it's just with a "but requires additional signaling, which for example can be achieved by combining this with No-Response:0". Or it's not planned out here, then the 2.31 mentioned in the quoted note is more of a note on future updates of Q-Block that would be necessary to leverage that combination (but I don't see any such document happening). Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --Hr1RmnxscrfHuEJM Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl/jEy0ACgkQOY0REtOk veHppg/8CcTB5BbUE7h8pOCAmGiEH8BI+tgRPPRSND3nIe/zAkHpc6wOZYTmyJpp OL2t6YH5W4PQl8o8wNFonWyiq0L3hgw67xDv8eCJEKgX6s6s3yucswQs/Rp5MZkj rMqZlfSIoPUeMfq2wWu46quOjb8AifssRSCRN8AUjoI/aZKERukQyKv+MeIOZuzF rOUl1T5RuEsE5uebG0mfT54wtpGqjHMuIzon75LqLN1tunwxujYewafZAZNaL58f RkOyj9TWJqpaxqF1yMq7UPnXtG9cHtzCNyRN3vY7rqrsxbQ2hVpbaX6eyMvyHfQh MFsRraUPv3JNTGES2nb02cFFCyAe83aNVidMLfkR6c4KZAR2sl2usjzQ2o+nLlDq 8T9ByLpnhampZTSa/BNi1bA9uj4TWjbaof1d4lDShhxCkzD1hlw7t91eXHM0XcuC H6BxoS0F4ddLf60ANem4REZoTw0h+DaGkd+9AT/1/oiK2bMIvs+XildM7GANfatj KVdkFuwiPoAtwnSdtGukfSKWTDJRKG4IuJgVfQOh6WlLqbbrwbSRrL3y1+8phzvH hL8uMWVmfGBHv60fq0X1Iymm0DsJW31aFJbOxUNlvMqVAMxeTzG7JGKT0bq2lHBl UB3qjhaFrIdmGYnu6XLu0tDcLCVY2VGowPukPGZtNuBsiSPWTZg= =/b/m -----END PGP SIGNATURE----- --Hr1RmnxscrfHuEJM-- From nobody Wed Dec 23 02:40:04 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0733A0E94; Wed, 23 Dec 2020 02:39:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYhsVkWTHPiq; Wed, 23 Dec 2020 02:39:57 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDD1C3A0E8F; Wed, 23 Dec 2020 02:39:54 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 8289E407C1; Wed, 23 Dec 2020 11:39:49 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 823F7AB; Wed, 23 Dec 2020 11:39:27 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:bd73:2e62:80f9:8152]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id DFD9E63; Wed, 23 Dec 2020 11:39:26 +0100 (CET) Received: (nullmailer pid 2826684 invoked by uid 1000); Wed, 23 Dec 2020 10:39:25 -0000 Date: Wed, 23 Dec 2020 11:39:25 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: mohamed.boucadair@orange.com Cc: "draft-ietf-core-new-block@ietf.org" , "core@ietf.org WG (core@ietf.org)" , "dots@ietf.org" Message-ID: References: <31613_1608714849_5FE30A61_31613_100_2_787AE7BB302AE849A7480A190F8B9330315A17B3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xZSAZ4uOpIvUYSpF" Content-Disposition: inline In-Reply-To: <31613_1608714849_5FE30A61_31613_100_2_787AE7BB302AE849A7480A190F8B9330315A17B3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block (Congestion Control) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2020 10:39:59 -0000 --xZSAZ4uOpIvUYSpF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, On Wed, Dec 23, 2020 at 09:14:09AM +0000, mohamed.boucadair@orange.com wrot= e: > You are completely right that the default probing-rate is to be > increased for the DOTS case. FYI, this is why we went with the > following in RFC8782: > > We avoided to include a pointer to these details as these are > application-specific and that, even if the draft is motivated by the > DOTS use case, other applications can make use of the new block > functionality.=20 At least a one-line reference into there would be helpful when reading the congestion control section. It can be phrased as an example ("For the particular use case of DOTS, these parameters are negotiated; even when not negotiated, that application uses altered defaults as in [ref-into-dots]") to avoid the impression of general applicability, but some example *should* be given, for without changed parameters the Q-Block mechanism is useless (3 hour wait if all 10 initial messages are lost). > For NSTART, we already have the following:=20 >=20 > "NSTART will also need to be increased from the default > (1) to get faster transmission rates." It would enhance readability if that were mentioned in the congestion control section. It may help to draw the parallel to the MAX_PAYLOADS of the non-confirmable case, or to talk more about the hybrid transmission (CON only after some blocks; does that have a name? see also comment around "seems to imply that the full exchange"). Does DOTS have an altered default here? Without having *anything* about non-1 NSTART, the all-CON case may not even be worth having in an example, as there's nothing even referenced where it could make sense. Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --xZSAZ4uOpIvUYSpF Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl/jHlkACgkQOY0REtOk veE+7A//aM8shJ7iAezFVfp0L/pW1JVez4Q5BGOR/PXNWo7R11kyySJLvCa5a2Dy G5tod1oEmda+6YevdY8eCH13IBu75vtrXIKohMWUVBV2AbKZNDv7pGSUTpCMMZxl HkCvDDpdPrhcVStvBruPnC9Zu+2J+H9Q+u0WwpIeOWNWZFsMybw97f08PQF9xxDb vyIwMtrsWSbcD916Egz0bADekkVbIJ1OCfR3OOT9xvpq1kIOMX/FsylnJzCW32Po iW4bffFUeYeHXRpBQNFUHwntkzWtUGG4GiafvausK36UX7n+KV1kBYdF1i8N/61z JlRURtD+5GMMHmGqoNRJUgbdLO6hZt8JU9d2Z4xsVAwwCUEIczz5W90OpJXQ9/wZ 5pCNQtmkMeFWPSXkVYY+DK1FPgrkRLDM1bhlY/M5cKRR5Swgw4mwgrAcLNXfG3MG bghXEXToSPHr644h0orJlgs5O5CnE3aTXeyw+x7/3rAaR8gh1RbmVi45lPpFfcQM kMttcwiD6ZmHXhVWzH+aJ7UFfFDAYr3E7WJ7oPJ28U5tVOpQ25iOOqeTmrT/Loru i59quElttXJFrUVBFtr7r7eSjbxA58kh5W1A2qwwAoHVk4Iw8cpEVp0mK5fM7rST dbFfJIt8P491yldp3OtpUzRub39tqih3HmGdf+tEE8g1CvCDlIc= =0zVB -----END PGP SIGNATURE----- --xZSAZ4uOpIvUYSpF-- From nobody Wed Dec 23 06:09:46 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19803A0FE7; Wed, 23 Dec 2020 06:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 mm6RdYQSK0NK; Wed, 23 Dec 2020 06:09:40 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 106393A0FE2; Wed, 23 Dec 2020 06:09:39 -0800 (PST) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 4D1FSy2VTnz8tHp; Wed, 23 Dec 2020 15:09:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1608732578; bh=4d8lkx8uBrL6luYMsr5c2LaeXA6y+OtE+oI9OPJTMTU=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=Ow5hQKz8gJJJDv2g/zYZIoz7evQY3f9oViQWT6ZCQ8BKrGtICkuJpUtnfvJr+4+jM coiODxyRU4Frkig3SVhyA7+MqfREzBEBkTtFQTOAHxvyjufPwvLH9WriaC+0OOtOTW dbWzShcFdk3OU6YaTG9GyqUs8RPkR+ErDTGcKbzu5F1BoFEwZLEgvyRgycJkT6Nak9 NGou0EC5x5mXS05iDaC+iRvNfQLxdXRah/z6hHK4W38NPfwZR4nlHCAwyAoTXGUfD2 FvNr/LvPvvE8jubZUzx9aMTWHWmKrGINmZKL1qY6dBiWDxw2JkjOb+6QftOQKuFEsT rZaG7oHgzoVnQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.95]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 4D1FSy1H5qz3wbT; Wed, 23 Dec 2020 15:09:38 +0100 (CET) From: To: =?iso-8859-1?Q?Christian_Ams=FCss?= CC: "draft-ietf-core-new-block@ietf.org" , "core@ietf.org WG (core@ietf.org)" , "dots@ietf.org" Thread-Topic: [core] WG Last Call on draft-ietf-core-new-block (No-Response) Thread-Index: AQHW2RFADVSDS+77YE2WSWeKTWYPaaoEtA4Q Date: Wed, 23 Dec 2020 14:09:37 +0000 Message-ID: <28095_1608732578_5FE34FA2_28095_105_1_787AE7BB302AE849A7480A190F8B9330315A1C90@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <18741_1608713479_5FE30507_18741_81_1_787AE7BB302AE849A7480A190F8B9330315A177C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block (No-Response) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2020 14:09:45 -0000 Re-, Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Christian Ams=FCss [mailto:christian@amsuess.com] > Envoy=E9=A0: mercredi 23 d=E9cembre 2020 10:52 > =C0=A0: BOUCADAIR Mohamed TGI/OLN > Cc=A0: draft-ietf-core-new-block@ietf.org; core@ietf.org WG > (core@ietf.org) ; dots@ietf.org > Objet=A0: Re: [core] WG Last Call on draft-ietf-core-new-block (No- > Response) >=20 > Hello Med, >=20 > > The text we have in the draft does not preclude No-Response (or > any > > solution that will be endorsed by the WG in the future): > > > > If both endpoints support No-Response, they can use it as a > "signal in > > the MAX_PAYLOADS" to trigger a 2.31 mentioned in the last > sentence. > > > > As we don't recommend No-Response (for reasons echoed in your > > message), it is not worth to include much more details on how > > No-Response can be used. >=20 > The only reason for No-Response I echo in my mail is the downref, > and merely showing how these can interoperate does not create a > normative reference. It's quite a stretch to assume people would > read "requires an additional signal" as "could use No-Response". >=20 > Working group documents time and again have outward references like > "One way of doing this is being explored in [draft-...]", which is > clearly non-normative, but at the same time allow the reader to get > at least > *some* indication of how things are meant to be used. [Med] Simply adding a pointer would work for me. We can go for the followin= g change:=20 s/an additional signal in the MAX_PAYLOADS packet/an additional signal in t= he MAX_PAYLOADS packet (e.g., [RFC7967]) >=20 > What makes things worse here is that as long as this specification > does not mention No-Response at all, it is not ensured that it > interoperates well at all with No-Response; thus even if a reader > can make the jump, they'd have to figure out on their own that it's > probably best if No-Response overrides the response behavior of Q- > Block. [Med] Here is where I disagree. As we don't recommend any solution (includi= ng No-Response), it is not up to this document to discuss how to graft the = various pieces.=20=20=20=20 >=20 > > The use of NON is thus superior but requires > > an additional signal in the MAX_PAYLOADS packet to seek for > a 2.31 > > (Continue) from the peer if it is ready to receive the next > set of > > blocks. >=20 > I missed that in the part where I'm asking for whether 2.31 would be > produced. That paragraph really opens more questions than it > answers: If Q-Block is intended to be usable with something to > signal that now would be a good time for a response, then this > almost contradicts the "2.31 > (Continue) Response is not used in the current version" statement. [Med] That statement is factual. It is meant to remind that 2.31 is legal a= nd that it is there as a provision for any future optimization that would r= equire it.=20 >=20 > Either this is a possibility already planned here, then the 2.31 > cases should be properly described, even if it's just with a "but > requires additional signaling, which for example can be achieved by > combining this with No-Response:0". Or it's not planned out here, > then the 2.31 mentioned in the quoted note is more of a note on > future updates of Q-Block that would be necessary to leverage that > combination (but I don't see any such document happening). >=20 > Best regards > Christian >=20 > -- > To use raw power is to make yourself infinitely vulnerable to > greater powers. > -- Bene Gesserit axiom ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Dec 23 06:27:32 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D483A0FFB; Wed, 23 Dec 2020 06:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 hnOsfdNSS9tu; Wed, 23 Dec 2020 06:27:26 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A85373A0FF7; Wed, 23 Dec 2020 06:27:25 -0800 (PST) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 4D1FsR0plkzCr8R; Wed, 23 Dec 2020 15:27:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1608733643; bh=I6pd2jrnslqK5SEc4yQC2ixBuUVn3KD08Awrjpmoz5g=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=NrWWBj12Kv0O6RJsUJ8aRxs/NC1j0nmbdW1io4+ayn9tVk4Y6C9Pm+W1G3u9MC0xh TVvN2tfJnmpp4Ec1KYR3tnSP9bVtYp4T5moX6VIA/mEN1h1uIKPp/iSPVkEIS28Ku4 fWkGCGVbgouwVLrcwkc+5LN/YaCkUANHyBUAQR67TauyrTHpUwXt6mZVunIPK45+a+ z8ECzzreKEuWSI4YRBNbOYt6l6mSy7ne7uKQz1JOwr6ezDmLls2nRxr3pQOSLqULbg yTM2at/3TNNjThCpQV4noNfecHAEF5KAxGFYAHTRropZAWeJDblzxBlsPdPnVzFJUl 4Y3Z1YqtoHI+Q== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.45]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 4D1FsQ6qVyzFpX6; Wed, 23 Dec 2020 15:27:22 +0100 (CET) From: To: =?iso-8859-1?Q?Christian_Ams=FCss?= CC: "draft-ietf-core-new-block@ietf.org" , "core@ietf.org WG (core@ietf.org)" , "dots@ietf.org" Thread-Topic: [core] WG Last Call on draft-ietf-core-new-block (Congestion Control) Thread-Index: AQHW2Rfx+Vo2GwnatkCDylILiJ0E+aoEusMw Date: Wed, 23 Dec 2020 14:27:22 +0000 Message-ID: <10267_1608733643_5FE353CA_10267_151_1_787AE7BB302AE849A7480A190F8B9330315A1CB6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <31613_1608714849_5FE30A61_31613_100_2_787AE7BB302AE849A7480A190F8B9330315A17B3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block (Congestion Control) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2020 14:27:27 -0000 Re-, Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: Christian Ams=FCss [mailto:christian@amsuess.com] > Envoy=E9=A0: mercredi 23 d=E9cembre 2020 11:39 > =C0=A0: BOUCADAIR Mohamed TGI/OLN > Cc=A0: draft-ietf-core-new-block@ietf.org; core@ietf.org WG > (core@ietf.org) ; dots@ietf.org > Objet=A0: Re: [core] WG Last Call on draft-ietf-core-new-block > (Congestion Control) >=20 > Hello, >=20 > On Wed, Dec 23, 2020 at 09:14:09AM +0000, > mohamed.boucadair@orange.com wrote: > > You are completely right that the default probing-rate is to be > > increased for the DOTS case. FYI, this is why we went with the > > following in RFC8782: > > > > We avoided to include a pointer to these details as these are > > application-specific and that, even if the draft is motivated by > the > > DOTS use case, other applications can make use of the new block > > functionality. >=20 > At least a one-line reference into there would be helpful when > reading the congestion control section. It can be phrased as an > example ("For the particular use case of DOTS, these parameters are > negotiated; even when not negotiated, that application uses altered > defaults as in > [ref-into-dots]") to avoid the impression of general applicability, > but some example *should* be given, for without changed parameters > the Q-Block mechanism is useless (3 hour wait if all 10 initial > messages are lost). [Med] OK. I added this note:=20 Note: For the particular DOTS application, PROBING_RATE and other transmission parameters are negotiated between peers. Even when not negotiated, the DOTS application uses customized defaults as discussed in Section 4.5.2 of [RFC8782]. >=20 > > For NSTART, we already have the following: > > > > "NSTART will also need to be increased from the default > > (1) to get faster transmission rates." >=20 > It would enhance readability if that were mentioned in the > congestion control section. [Med] Good point.=20 >=20 > It may help to draw the parallel to the MAX_PAYLOADS of the non- > confirmable case, or to talk more about the hybrid transmission (CON > only after some blocks; does that have a name? see also comment > around "seems to imply that the full exchange"). >=20 > Does DOTS have an altered default here? [Med] No.=20 Without having *anything* > about > non-1 NSTART, the all-CON case may not even be worth having in an > example, as there's nothing even referenced where it could make > sense. [Med] We do already say the following for the CON examples: "These examples assume NSTART has been increased to at least 4." Again, these examples are here to generalize the procedure rather than keep= ing it DOTS-centric.=20 >=20 > Best regards > Christian >=20 > -- > To use raw power is to make yourself infinitely vulnerable to > greater powers. > -- Bene Gesserit axiom ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Dec 24 00:51:47 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1E7B3A10F5; Thu, 24 Dec 2020 00:51:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 MKCaVyqlR2vz; Thu, 24 Dec 2020 00:51:45 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ADDC3A10FA; Thu, 24 Dec 2020 00:51:45 -0800 (PST) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 4D1kMg25nJz2y3k; Thu, 24 Dec 2020 09:51:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1608799903; bh=g/PMt+geeljWMQHwpcpgiJlng07DGrBWRtn/35Lfxlk=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=Myr1F7TmJZUsSR/GgW+QLGL3NGFrvFPm4CF2S8EGeKS+JNxgTgQAlVceRxB6Qxs7K 89nUHkW/lYP/Qflgj07P/t2MxB6uOF9G7fW/52HXwn6wGhYM+1unHFWpICnCBbBAa9 D/sxJhO/BirbMHVIKX6dJ7nBKUc+7CG0lUD9UJrOWoKFwcetJIHOqnQ6t7xDM0ghpv u0TZ8rmi1q3lXEOxkQHc3RCg70SU4XpBSvrrVRZaSK0izFJ+WaUW74Yi2B0wi0aDCN 9Efem+/qKwnynyLlFPwK0oU3J5Um/vJUeGYCQqRSttzFbrFF2iruDRVjMJs1ICsUZI OwwpzCzM8/Jrw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.89]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 4D1kMg0fgmz5vNK; Thu, 24 Dec 2020 09:51:43 +0100 (CET) From: To: =?iso-8859-1?Q?Christian_Ams=FCss?= , "draft-ietf-core-new-block@ietf.org" CC: "core@ietf.org WG (core@ietf.org)" , "dots@ietf.org" Thread-Topic: [core] WG Last Call on draft-ietf-core-new-block (Media type) Thread-Index: AdbZ0f4++PkavJGrTTSydpZLkyGARQ== Date: Thu, 24 Dec 2020 08:51:42 +0000 Message-ID: <13542_1608799903_5FE4569F_13542_412_22_787AE7BB302AE849A7480A190F8B9330315A2233@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block (Media type) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2020 08:51:47 -0000 Hi Christian, This one is fixed at: https://github.com/core-wg/new-block/commit/8c3972d3c= 32e2eb9186bb3deb59c865a1a9d37a0=20 For "Applications that use this media type", we used the same generic info = as in RFC 8742.=20 Thank you. Cheers, Med > -----Message d'origine----- > De=A0: Christian Ams=FCss [mailto:christian@amsuess.com] > Envoy=E9=A0: mercredi 23 d=E9cembre 2020 06:01 > =C0=A0: draft-ietf-core-new-block@ietf.org > Cc=A0: core@ietf.org WG (core@ietf.org) ; dots@ietf.org > Objet=A0: Re: [core] WG Last Call on draft-ietf-core-new-block >=20 > Hello new-block authors, hello CoRE, >=20 > I've finally managed to have another look at the document (and it's > still the 22nd *somewhere*...). >=20 ... >=20 > * New Content Format: I think this needs a media type registration > to go > with it first; based on that, a content format can be registered. >=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Dec 24 01:40:13 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E193A1128 for ; Thu, 24 Dec 2020 01:40:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8UcowAg7GlP for ; Thu, 24 Dec 2020 01:40:08 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 BE6DC3A0C6B for ; Thu, 24 Dec 2020 01:40:08 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1ksN6L-0000NS-Mx; Thu, 24 Dec 2020 09:40:05 +0000 From: To: , Cc: , References: <263d6f84-4a57-2085-288f-068b1d78f7ae@ri.se> In-Reply-To: Date: Thu, 24 Dec 2020 09:40:13 -0000 Message-ID: <04a201d6d9d8$c7919ae0$56b4d0a0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE9efsT42/5NWOZF7Ah7uUxJLBzEAIREyNWqyb5urA= Content-Language: en-gb Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2020 09:40:12 -0000 Hi Christian, Thanks for this and the time spent thinking about it. Some items have already become separate threads. Otherwise responses inline - part 1. Some of the changes can be seen at https://tinyurl.com/new-block-latest=20 Regards Jon > -----Original Message----- > From: Christian Ams=FCss [mailto: christian@amsuess.com] > Sent: 23 December 2020 05:01 > To: draft-ietf-core-new-block@ietf.org > Cc: dots@ietf.org; core@ietf.org WG (core@ietf.org) > Subject: Re: [core] WG Last Call on draft-ietf-core-new-block >=20 > Hello new-block authors, hello CoRE, >=20 > I've finally managed to have another look at the document (and it's = still the > 22nd *somewhere*...). >=20 > My over-all summary is that while this document has matured quite a = bit > (and turned out better than I had expected for the special-purpose = blocks it > is), I think that the topic of response suppression and congestion = control > sections still have to be sharpened, and the examples could pick a = more > realistic balance between going all-NON and all-CON (or explain why = that's > something that wouldn't be done even though the text reads like that's > what's expected to be used but maybe it's just me). >=20 >=20 > Except for the first item (which is coming back to the notes for the WGLC), > all should be more or less sequential in the document (with = forward/back > references as needed). >=20 > * On the downref to No-Response: I don't see the downref as too big an > issue. It's a bit odd that that document didn't go through the CoRE > WG, but my impression is that it's widely used (on a "when the = library > I maintain broke it people filed issues" level), and both OSCORE and > groupcomm-bis (which is to replace RFC7390) reference it. It's an > informative reference because they don't mechanically depend on it, > but it shows how well No-Response has been taken up. >=20 > (Frankly, I'd support a retroactive adoption. I don't suppose we can > do that with "adults"?). >=20 > From how I understand Q-Block to be intended to work, No-Response = does > not cover all of the behavior (as it's timeout based); still, that > document lays good groundwork for what's done here in a rather = precise > way (see comment on "For Confirmable transmission, the server MUST > continue" later on) where this document needs the examples to be = fully > understood. >=20 > Based on the later text on MAX_TRANSMIT_SPAN, why not at least > acknowledge the equivalence? Maybe like this: >=20 > > The behavior of endpoints following this draft can equivalently b > > described in terms of the No-Response option {{?RFC7967}}: > > > > For a message with a Q-Block1 option with M=3D1 that is followed = by > > another message on the same Request-Tag within MAX_TRANSMIT_SPAN > [ > > or MAX_BLOCK_JITTER, see later ], the default value for = No-Response > > is 8 (suppressing the 4.xx code that would be returned due to the > > incomplete request); an explicitly set No-Response option would > > override that." >=20 > although I'd still advocate just using No-Response for the whole > definition even if No-Response is not typically expressed. >=20 > (I'm not really sure what the correct response would be for an > individual non-terminal request if it were to be answered due to an > explicit No-Response:0 -- might be 2.31 Continue that's just not > used in this specification because it's always suppressed? I'll come > back to that -- but then it'd rather be No-Response: 10). >=20 > * intro: WebSockets (capitalization) [Jon] OK >=20 > * The list of pros and cons (with the cons being almost trivial) does > not explain to the reader why these are not a replacement; I suggest > to add: >=20 > * The Q-Block options do not support stateless operation / random > access. [Jon] Actually Q-Block2 does now support this following the redefinition = of the M bit usage in a previous iteration (with M=3D0 you can ask for any individual block). [Jon] For stateless, Request-Tag is included so this should be fine. https://datatracker.ietf.org/doc/html/draft-ietf-core-stateless-06#sectio= n-4 .2 >=20 > * Proxying of Q-Block is limited to caching full representations. >=20 > (The latter might be mitigated by additional text around caching, = but > I doubt it's worth the effort given it's not part of the use case). [Jon] I am not entirely convinced that Block1/2 have got the caching by block properly sorted out - e.g. what happens when different clients = make requests with different SZX and Block2 is part of the cache key. The limiting to caching full representations is there so that a new can of = worms is not opened up. [Jon] I will see if I can think of any further cons. >=20 > * "compromises of": I don't understand that sentence. [Jon] OK s/compromises of/comprises of/ >=20 > * "the asymmetrical packet loss is not a benefit here": It never is; > what is meant here? [Jon] OK. How about (which is obvious, but a reminder to the = implementer) OLD However, the asymmetrical packet loss is not a benefit here. NEW However, the use of Confirmable messages will not work if there = asymmetrical packet loss.=20 >=20 > * "Updated CoAP Response Code": "This document updates" sounds like a > formal update to RFC7959, which it neither is nor needs to be. > Phrasing it along the lines of "adds a media type that can be used > with 4.08" would ease that. [Jon] OLD 1.2. Updated CoAP Response Code (4.08) This document updates the 4.08 (Request Entity Incomplete) by defining an additional message format for reporting on payloads using the Q-Block1 Option that are not received by the server. NEW 1.2. CoAP Response Code (4.08) Usage This document adds a media type for the 4.08 (Request Entity Incomplete) response defining an additional message format for reporting on payloads using the Q-Block1 Option that are not received=20 by the server. >=20 > * "Only C and U columns are marked": "The Q-Block1 option is critical, = and > unsafe for proxies to forward" would be easier to read -- which > checkboxes are marked is visible alrady from the table. (Or just = leave > it for the later paragraphs that say that in more detail). [Jon] OK. Gone with Critical etc. >=20 > * "Q-Block1 Option is useful with": ... and FETCH. (Also in "Using the > Q-Block1 option" first paragraph). [Jon] OK >=20 > * "Is opaque in nature, but it is RECOMMENDED" on being a counter and > starting off random: Like other similar suggestions (ETag), this is > implementation guidance level and not required for interoperability. > Maybe phrase this the same way as the recommendations on tokens? [Jon] OLD The Request-Tag is opaque in nature, but it is RECOMMENDED that the client treats it as an unsigned integer of 8 bytes in length. An implementation may want to consider limiting this to 4 bytes to reduce packet overhead size. The server still treats it as an opaque entity. The Request-Tag value MUST be different for distinct bodies or sets of blocks of data and SHOULD be incremented whenever a new body of data is being transmitted between peers. The initial Request-Tag value SHOULD be randomly generated by the client. NEW The Request-Tag is opaque, the server still treats it as opaque but the client SHOULD ensure that it is unique for every different body of transmitted data. Implementation Note: It is suggested that the client treats the = Request-Tag as an unsigned integer of 8 bytes in length. An implementation may want to consider limiting this to 4 bytes to reduce packet overhead size. The initial Request-Tag value should be randomly generated and then subsequently incremented by the client whenever a new body of data is = being transmitted between peers. OLD The ETag is opaque in nature, but it is RECOMMENDED that the server treats it as an unsigned integer of 8 bytes in length. An implementation may want to consider limiting this to 4 bytes to reduce packet overhead size. The client still treats it as an opaque entity. The ETag value MUST be different for distinct bodies or sets of blocks of data and SHOULD be incremented whenever a new body of data is being transmitted between peers. The initial ETag value SHOULD be randomly generated by the server. NEW The ETag is opaque, the client still treats it as opaque but the = server SHOULD ensure that it is unique for every different body of transmitted data. Implementation Note: It is suggested that the server treats the ETag as = an unsigned integer of 8 bytes in length. An implementation may want to consider limiting this to 4 bytes to reduce packet overhead size. The initial ETag value should be randomly generated and then = subsequently incremented by the server whenever a new body of data is being transmitted between peers.=20 >=20 > * "For Confirmable transmission, the server MUST continue": This reads > like new-block could change anything about that, when all it does is > do things on the response level. [1] has a good note on that > separation topic. >=20 > [1]: https://tools.ietf.org/html/rfc7967#section-2 [Jon] The intent here was that CON continues to work for each request/response in that the request needs to be acknowledged, but a response (piggybacked or separate) is not required. OLD For Confirmable transmission, the server MUST continue to acknowledge each packet. NEW For Confirmable transmission, the server continues to acknowledge each packet, but a response is not required (whether separate or piggybacked) until retransmission or successful receipt of the body. [Jon] To be continued in part 2.