From nobody Thu Dec 3 00:22:56 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B325F3A0AE5 for ; Thu, 3 Dec 2020 00:22:54 -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=aalto.fi 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 GMDFqZQn0ITw for ; Thu, 3 Dec 2020 00:22:50 -0800 (PST) Received: from smtp-out-02.aalto.fi (smtp-out-02.aalto.fi [130.233.228.121]) (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 2F03C3A0ADD for ; Thu, 3 Dec 2020 00:22:49 -0800 (PST) Received: from smtp-out-02.aalto.fi (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id A014C271570_FC8A054B for ; Thu, 3 Dec 2020 08:22:44 +0000 (GMT) Received: from exng4.org.aalto.fi (exng4.org.aalto.fi [130.233.223.23]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client CN "exng4.org.aalto.fi", Issuer "RootCA3" (not verified)) by smtp-out-02.aalto.fi (Sophos Email Appliance) with ESMTPS id 6D0BB271554_FC8A054F for ; Thu, 3 Dec 2020 08:22:44 +0000 (GMT) Received: from [192.168.11.105] (130.233.0.5) by exng4.org.aalto.fi (130.233.223.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2106.2; Thu, 3 Dec 2020 10:22:44 +0200 To: References: <2544_1606001529_5FB9A379_2544_45_1_CAOgPGoCm=+hWH+W6cJiTT3XYZzeCCN0T41d1DroS0kAjUPvaHA@mail.gmail.com> From: Aleksi Peltonen Message-ID: <6ab592a7-5dc8-0aa0-9cc3-46d4f6b8b81e@aalto.fi> Date: Thu, 3 Dec 2020 10:22:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <2544_1606001529_5FB9A379_2544_45_1_CAOgPGoCm=+hWH+W6cJiTT3XYZzeCCN0T41d1DroS0kAjUPvaHA@mail.gmail.com> Content-Type: multipart/alternative; boundary="------------D6EA3F18011F0BAFDAFB9453" Content-Language: en-GB X-Originating-IP: [130.233.0.5] X-ClientProxiedBy: exng2.org.aalto.fi (130.233.223.21) To exng4.org.aalto.fi (130.233.223.23) X-SASI-RCODE: 200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aalto.fi; h=subject:to:references:from:message-id:date:mime-version:in-reply-to:content-type; s=its18; bh=Cjjwl2Vgf0XddI81nViMYMRYgfepGV3Emvgykx/vrEU=; b=cgTKc5M0HrXQXaQgvRnoDxLRX0ocRsrGAoBmZmvbmjpghcnRnIDaB4Vnfm0fzpOfwJt94NOFzPHZnEdrVXOkYbgfSKhA0nkVHwAEJ7A3pXNkN0lZN6v//xrJTBy5TLGy1EGFuHYL1RCZlj34uysA0EbHKLO/Jas0IPJF7WAkJ3Mg/ZdWZU5MKV9V/SKIeGAwV+Z6wBX6OpSSxeDF/q3HPmoEeHYiQ89/ugsHk7v5qOA+aZpYgSgKI6xIezW5ljoAZra6BDaDvPX2EJMf1mBWdT6/PMLwE29gnw6jy737tjb4zjpqFrXPKdl8DmVBl7hu8JnCk7oi/0khq/U9mo501A== Archived-At: Subject: Re: [Emu] Working Group Last Call for draft-ietf-emu-eap-noob-02 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 08:22:55 -0000 --------------D6EA3F18011F0BAFDAFB9453 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit I think the draft is ready. I was involved in the formal modeling of the protocol with both ProVerif and mCRL2. All issues discovered from the modeling phase have been addressed in the current draft. I am also working on modeling other protocols, including EAP methods, and will share my results when they are published. Best regards, Aleksi On 22/11/2020 01:31, Joseph Salowey wrote: > At  IETF 109 meeting there was support for moving EAP-NOOB forward.  > The chairs and authors believe the document is ready to progress so > this starts the working group last call for EAP-NOOB [1].   Please > review the document and send comments to the list by December 11, > 2020.  Statements of support or opposition are welcome especially if > accompanied with reasons for the position. > > Thanks, > > Joe > > [1] https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/ > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu --------------D6EA3F18011F0BAFDAFB9453 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit

I think the draft is ready. I was involved in the formal modeling of the protocol with both ProVerif and mCRL2. All issues discovered from the modeling phase have been addressed in the current draft. I am also working on modeling other protocols, including EAP methods, and will share my results when they are published.

Best regards,
Aleksi

On 22/11/2020 01:31, Joseph Salowey wrote:
At  IETF 109 meeting there was support for moving EAP-NOOB forward.  The chairs and authors believe the document is ready to progress so this starts the working group last call for EAP-NOOB [1].   Please review the document and send comments to the list by December 11, 2020.  Statements of support or opposition are welcome especially if accompanied with reasons for the position.  

Thanks,

Joe



_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
--------------D6EA3F18011F0BAFDAFB9453-- From nobody Thu Dec 3 02:30:20 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F18BD3A0E3B for ; Thu, 3 Dec 2020 02:30:17 -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=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 EyR_S5B35r9a for ; Thu, 3 Dec 2020 02:30:16 -0800 (PST) Received: from mx01.puc.rediris.es (outbound4mad.lav.puc.rediris.es [130.206.19.146]) (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 F15C13A0E3A for ; Thu, 3 Dec 2020 02:30:15 -0800 (PST) Received: from xenon42.um.es (xenon42.um.es [155.54.212.169]) by mx01.puc.rediris.es with ESMTP id 0B3AUEw8012460-0B3AUEw9012460 for ; Thu, 3 Dec 2020 11:30:14 +0100 Received: from localhost (localhost [127.0.0.1]) by xenon42.um.es (Postfix) with ESMTP id D0FDF20E45 for ; Thu, 3 Dec 2020 11:30:13 +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 dhF2uhVNd5vX for ; Thu, 3 Dec 2020 11:30:13 +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 AD27E20E3E for ; Thu, 3 Dec 2020 11:30:13 +0100 (CET) To: emu@ietf.org References: <2544_1606001529_5FB9A379_2544_45_1_CAOgPGoCm=+hWH+W6cJiTT3XYZzeCCN0T41d1DroS0kAjUPvaHA@mail.gmail.com> <6ab592a7-5dc8-0aa0-9cc3-46d4f6b8b81e@aalto.fi> From: Dan Garcia Message-ID: Date: Thu, 3 Dec 2020 11:30:13 +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: <6ab592a7-5dc8-0aa0-9cc3-46d4f6b8b81e@aalto.fi> Content-Type: multipart/alternative; boundary="------------C493411851C27CEC8B7C2472" 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: mx01.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=9wHQpdJqvHVQXiGqvDd65JtYnkcbQxO+5YDl8bE5yNU=; b=N2e4iZeSXiXVENNmyY7ObQX05myzHru+Sbxmz2ftoDtqD8sFrWKMT4E1CubzePhE2IDg2nZhxxre b959XqWidlVtFS/hRrjec6T03kO54napnL9gBUorq9KOngNWzUtGiegkSWkigPgMi9754pqQmqCl 53Jn0A7n5P20SuezpX8t0py/i/TkHvC4lrEjrC09EnTpSbqAhqtl2il1s5slY8qbqCd0IEE6YZtW J/zg2fKAsoCnIE65C4a9Q6CshclSjj7r7Z4VKJI4Hb0D20R11u9G8JcjQp+9d22HWsX8PFBF7jY9 OhFx+CmNQLaIHajywLa1qG+MPY+yEm9EBhN6Cw== Archived-At: Subject: Re: [Emu] Working Group Last Call for draft-ietf-emu-eap-noob-02 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 10:30:18 -0000 This is a multi-part message in MIME format. --------------C493411851C27CEC8B7C2472 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello all, I have read the draft and I think it is useful tool to have within the EAP framework. I support its publication. Regards, Dan El 03/12/2020 a las 9:22, Aleksi Peltonen escribió: > > I think the draft is ready. I was involved in the formal modeling of > the protocol with both ProVerif and mCRL2. All issues discovered from > the modeling phase have been addressed in the current draft. I am also > working on modeling other protocols, including EAP methods, and will > share my results when they are published. > > Best regards, > Aleksi > > On 22/11/2020 01:31, Joseph Salowey wrote: >> At  IETF 109 meeting there was support for moving EAP-NOOB forward.  >> The chairs and authors believe the document is ready to progress so >> this starts the working group last call for EAP-NOOB [1].   Please >> review the document and send comments to the list by December 11, >> 2020.  Statements of support or opposition are welcome especially if >> accompanied with reasons for the position. >> >> Thanks, >> >> Joe >> >> [1] https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/ >> >> >> >> _______________________________________________ >> Emu mailing list >> Emu@ietf.org >> https://www.ietf.org/mailman/listinfo/emu > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu --------------C493411851C27CEC8B7C2472 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hello all,

I have read the draft and I think it is useful tool to have within the EAP framework. I support its publication.

Regards,
Dan

El 03/12/2020 a las 9:22, Aleksi Peltonen escribió:

I think the draft is ready. I was involved in the formal modeling of the protocol with both ProVerif and mCRL2. All issues discovered from the modeling phase have been addressed in the current draft. I am also working on modeling other protocols, including EAP methods, and will share my results when they are published.

Best regards,
Aleksi

On 22/11/2020 01:31, Joseph Salowey wrote:
At  IETF 109 meeting there was support for moving EAP-NOOB forward.  The chairs and authors believe the document is ready to progress so this starts the working group last call for EAP-NOOB [1].   Please review the document and send comments to the list by December 11, 2020.  Statements of support or opposition are welcome especially if accompanied with reasons for the position.  

Thanks,

Joe



_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
--------------C493411851C27CEC8B7C2472-- From nobody Thu Dec 3 05:20:27 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@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: [Emu] [Ace] Proposed charter for ACE (EAP over CoAP?) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" 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 05:23:27 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9783A09F6 for ; Thu, 3 Dec 2020 05:23:26 -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 Kucs5PLVrOPH for ; Thu, 3 Dec 2020 05:23:24 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD75D3A09E7 for ; Thu, 3 Dec 2020 05:23:24 -0800 (PST) Received: from [192.168.46.129] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 7A72819CF; Thu, 3 Dec 2020 13:23:22 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Alan DeKok In-Reply-To: Date: Thu, 3 Dec 2020 08:23:20 -0500 Cc: EMU WG Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Joseph Salowey X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Emu] Working Group Last Call for draft-ietf-emu-eap-noob-02 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 13:23:27 -0000 > On Nov 21, 2020, at 6:31 PM, Joseph Salowey wrote: >=20 > At IETF 109 meeting there was support for moving EAP-NOOB forward. = The chairs and authors believe the document is ready to progress so this = starts the working group last call for EAP-NOOB [1]. Please review the = document and send comments to the list by December 11, 2020. Statements = of support or opposition are welcome especially if accompanied with = reasons for the position. =20 I support publication of this document. NITs: Section 3.3.1 says "The default realm for the peer is "eap-noob.arpa". But the diagram in 3.2.1 has: (NAI=3Dnoob@eap-noob.net) I suggest using "arpa" instead of "net". Section 3.3.1 says "The peer MUST copy the PeerId byte-by- byte from the message where it was allocated, and the server MUST perform a byte-by-byte comparison" It's a little odd to talk about "byte-by-byte". Perhaps just "copy = the PeerID", and "the server must verify that the PeerID exactly matches = ..." =20 Section 3.3.1 also discusses a "server-assigned realm". But there = seems to be no guidance on which realm to use. Since this specification = also mandates the use of a particular utf8-username "noob", there is a = potential conflict with existing users. It may be useful to suggest the use of a sub-realm, specifically used = for EAP-NOOB, e.g. "noob.example.net". Allowing a sub-realm for noob = means that administrators can select an otherwise unused realm, and = assign it specifically for use with EAP-NOOB. That can cause issues with roaming, however. Roaming systems match on = realms, and may not always be capable of matching on variants of realms. = So if they allow "example.net", they may not be capable of processing = "noob.example.net". RFC 7542 Section 3 "Routing inside of AAA Systems" = is silent on this topic, while Eduroam allows sub-realms. My suggestion is that the document should recommend the use of = noob-specific sub-realms, and then admit that this might cause issues in = some roaming environments. That trade-off is acceptable, I think. Most = roaming systems which cannot handle sub-realms will likely not be using = EAP-NOOB. Appendix E says: PeerId is provided to the peer by the server and might be a 22-character ASCII string.=20 I think it's best to just refer to Section 3.3.1, for the format of = the PeerId. And then note that the construction in Section 3.3.1 is = compatible with HTTP, and does not require escaping. Alan DeKok. From nobody Thu Dec 3 11:01:35 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@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: [Emu] [core] [Ace] Proposed charter for ACE (EAP over CoAP?) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" 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 Fri Dec 4 02:26:27 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@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: [Emu] [Ace] Proposed charter for ACE (EAP over CoAP?) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" 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 Sun Dec 6 04:53:48 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA9E33A0D4C; Sun, 6 Dec 2020 04:53:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 cogXjq9iXIk8; Sun, 6 Dec 2020 04:53:38 -0800 (PST) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 E30973A0D41; Sun, 6 Dec 2020 04:53:37 -0800 (PST) Received: by mail-io1-xd2c.google.com with SMTP id y5so10650619iow.5; Sun, 06 Dec 2020 04:53:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=Ym3ibNxg7PBxVYfZ0uXDnLBcU8GmXEJiBo0g9PbILps=; b=ZA2Da5wIiYX0HxPTOYMEobnvlq8CNDRUolUpgD19sGe49h19btqW8o5OXpMMCzLljz CcxJeHxXTw9cjuyfBGjw0Rc0YC07BhqMT1A2gz+Qi1fOlJnoMZxIZmdaslN4CLWDQsAj ks6hjhrpj6yw1/HJd8/4qeLMWmat7dwhbZxAUv3lcAY9n47ktPUZtdb+ujtSIvUKQXzt CFD1rCNXSYZRPWiHobldqYBIrQG2vcKYOelAuiZaUgdndZfnE/xjZlIzPgDYthx4W3/w SKyLrc25a9DHAePdRMSkQ0nS8D54byEhgX92mo/EIuHjn0p3/LQWf3mQcsp9010LTL7O hNPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=Ym3ibNxg7PBxVYfZ0uXDnLBcU8GmXEJiBo0g9PbILps=; b=AS50/3PQyUO7tesp2x37dJxak52+Qmo5u7dpSzihrBO22TI1mLCYk6Kl60R7bR0KkM FMdHOeUUVd35Eq1mAiQHULBj2ft/XzAOeoQd3OcT4Ru4yn5OK2wvU94geshFi83/xUeU G94QsKW12inKJ6dypeJrS5lzPT4NmGs6HPIudIAUxD/DKGPNWcywJ5oMTj0sgmIvfMOf IWHmetNwP640yw13OaSBnb1vo8d8ict9YTTOjwVo1uGqFWzulawVy2JJgdF2JsHXH8Ir lPRBuoue71B0NweoLS05d7dOARlTuW2k1XGTtf7RPTAy+KB7m7j6Wkxw9YTuWFv54Ju1 xNvQ== X-Gm-Message-State: AOAM532f0sQJ08c0VejktZmNWrUVeeBJ+2rVwCsr9RrwJpFCLJIlpWAG u6qpYE7drjc4ngR7iRwXxgWDaGZZevZMLA== X-Google-Smtp-Source: ABdhPJy1+C7LEkZpMShSngHiZeH/NLv6pgbG0siXgEI7tYErT0RkdfY2eWhgoch/9tGsMnK0ZdhS/Q== X-Received: by 2002:a05:6638:604:: with SMTP id g4mr15628707jar.22.1607259216651; Sun, 06 Dec 2020 04:53:36 -0800 (PST) Received: from [192.168.86.34] (146-115-101-80.s7246.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [146.115.101.80]) by smtp.gmail.com with ESMTPSA id x5sm475693ilp.55.2020.12.06.04.53.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Dec 2020 04:53:35 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Kathleen Moriarty Mime-Version: 1.0 (1.0) Date: Sun, 6 Dec 2020 07:53:35 -0500 Message-Id: References: <6fbd2457-4f3a-3508-99f8-5be69715a5ab@cs.tcd.ie> Cc: Eliot Lear , last-call@ietf.org, draft-ietf-tls-oldversions-deprecate@ietf.org, EMU WG , tls-chairs@ietf.org, tls@ietf.org In-Reply-To: <6fbd2457-4f3a-3508-99f8-5be69715a5ab@cs.tcd.ie> To: Stephen Farrell X-Mailer: iPhone Mail (18B92) Archived-At: Subject: Re: [Emu] [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2020 12:53:42 -0000 Hi Eliot, Thanks for raising your concern. I=E2=80=99ll note that I first started wor= king on this because a well deployed library already had plans to drop suppo= rt for versions 1.0 and 1.1 in their next release. Customers that wanted th= ose versions would have to use a prior library. This history may help. Best regards, Kathleen=20 Sent from my mobile device > On Nov 28, 2020, at 10:26 AM, Stephen Farrell w= rote: >=20 > =EF=BB=BF > Hi Eliot, >=20 >> On 28/11/2020 10:45, Eliot Lear wrote: >> Hi there IESG >> I support the intent of this document, and I think the approach to >> update the various documents listed is the right one. >=20 > Cool. >=20 >> Because of the breadth of documents updated, I wonder if at least >> some implementation guidance is warranted, in order to assist >> developers and even perhaps administrators. Perhaps in some cases >> these are compile-time or even run time options. I=E2=80=99d suggest >> guidance for common libraries, such as Microsoft .NET, OpenSSL, >> GNUTLS, and WolfSSL. Better to give that guidance to get people to >> TLS 1.3 rather than 1.2, of course. Even informational references >> would be fine, as assuredly some of this guidance exists. >=20 > Text welcomed of course, but I think it's mostly a case of > doing the s/w update for the library and then either waiting > 'till the library developer defaults to TLSv1.2 or better, or > else various config file or API options that don't differ > that much from library to library. I can check it out before > we're done (again, text welcome if someone else wants to do > that), but not sure it'll be that useful in the end TBH. > (I'll get back when I get to doing that.) >=20 > Cheers, > S. >=20 >> Thanks, >> Eliot >>>> On 9 Nov 2020, at 23:26, The IESG wrote: >>> The IESG has received a request from the Transport Layer Security >>> WG (tls) to consider the following document: - 'Deprecating TLSv1.0 >>> and TLSv1.1' as Best >>> Current Practice >>> The IESG plans to make a decision in the next few weeks, and >>> solicits final comments on this action. Please send substantive >>> comments to the last-call@ietf.org mailing lists by 2020-11-30. >>> Exceptionally, comments may be sent to iesg@ietf.org instead. In >>> either case, please retain the beginning of the Subject line to >>> allow automated sorting. >>> Abstract >>> This document, if approved, formally deprecates Transport Layer Security= (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346). Accordingly, those docume= nts (will be moved|have been moved) to Historic status. These versions lack= support for current and recommended cryptographic algorithms and mechanisms= , and various government and industry profiles of applications using TLS now= mandate avoiding these old TLS versions. TLSv1.2 has been the recommended v= ersion for IETF protocols since 2008, providing sufficient time to transitio= n away from older versions. Removing support for older versions from implem= entations reduces the attack surface, reduces opportunity for misconfigurati= on, and streamlines library and product maintenance. >>> This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC6347),= but not DTLS version 1.2, and there is no DTLS version 1.1. >>> This document updates many RFCs that normatively refer to TLSv1.0 >>> or TLSv1.1 as described herein. This document also updates the >>> best practices for TLS usage in RFC 7525 and hence is part of >>> BCP195. >>> The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf= -tls-oldversions-deprecate/ >>>=20 >>>=20 >>>=20 >>>=20 > No IPR declarations have been submitted directly on this I-D. >>> The document contains these normative downward references. See RFC >>> 3967 for additional information: rfc5024: ODETTE File Transfer >>> Protocol 2.0 (Informational - Independent Submission Editor >>> stream) rfc5024: ODETTE File Transfer Protocol 2.0 (Informational - >>> Independent Submission Editor stream) rfc5023: The Atom Publishing >>> Protocol (Proposed Standard - IETF stream) rfc5019: The Lightweight >>> Online Certificate Status Protocol (OCSP) Profile for High-Volume >>> Environments (Proposed Standard - IETF stream) rfc5019: The >>> Lightweight Online Certificate Status Protocol (OCSP) Profile for >>> High-Volume Environments (Proposed Standard - IETF stream) rfc5018: >>> Connection Establishment in the Binary Floor Control Protocol >>> (BFCP) (Proposed Standard - IETF stream) rfc4992: XML Pipelining >>> with Chunks for the Internet Registry Information Service (Proposed >>> Standard - IETF stream) rfc4992: XML Pipelining with Chunks for the >>> Internet Registry Information Service (Proposed Standard - IETF >>> stream) rfc4976: Relay Extensions for the Message Sessions Relay >>> Protocol (MSRP) (Proposed Standard - IETF stream) rfc4975: The >>> Message Session Relay Protocol (MSRP) (Proposed Standard - IETF >>> stream) rfc4975: The Message Session Relay Protocol (MSRP) >>> (Proposed Standard - IETF stream) rfc4964: The P-Answer-State >>> Header Extension to the Session Initiation Protocol for the Open >>> Mobile Alliance Push to Talk over Cellular (Informational - IETF >>> stream) rfc4964: The P-Answer-State Header Extension to the Session >>> Initiation Protocol for the Open Mobile Alliance Push to Talk over >>> Cellular (Informational - IETF stream) rfc4851: The Flexible >>> Authentication via Secure Tunneling Extensible Authentication >>> Protocol Method (EAP-FAST) (Informational - IETF stream) rfc4851: >>> The Flexible Authentication via Secure Tunneling Extensible >>> Authentication Protocol Method (EAP-FAST) (Informational - IETF >>> stream) rfc4823: FTP Transport for Secure Peer-to-Peer Business >>> Data Interchange over the Internet (Informational - IETF stream) rfc4823= : FTP Transport for Secure Peer-to-Peer Business Data >>> Interchange over the Internet (Informational - IETF stream) rfc4791: Cal= endaring Extensions to WebDAV (CalDAV) (Proposed >>> Standard - IETF stream) rfc4791: Calendaring Extensions to WebDAV >>> (CalDAV) (Proposed Standard - IETF stream) rfc4785: Pre-Shared Key >>> (PSK) Ciphersuites with NULL Encryption for Transport Layer >>> Security (TLS) (Proposed Standard - IETF stream) rfc4785: >>> Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for >>> Transport Layer Security (TLS) (Proposed Standard - IETF stream) rfc4744= : Using the NETCONF Protocol over the Blocks Extensible >>> Exchange Protocol (BEEP) (Historic - IETF stream) rfc4744: Using >>> the NETCONF Protocol over the Blocks Extensible Exchange Protocol >>> (BEEP) (Historic - IETF stream) rfc4743: Using NETCONF over the >>> Simple Object Access Protocol (SOAP) (Historic - IETF stream) rfc4743: U= sing NETCONF over the Simple Object Access Protocol >>> (SOAP) (Historic - IETF stream) rfc4732: Internet Denial-of-Service >>> Considerations (Informational - IAB stream) rfc4732: Internet >>> Denial-of-Service Considerations (Informational - IAB stream) rfc4712: T= ransport Mappings for Real-time Application >>> Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU) >>> (Proposed Standard - IETF stream) rfc4712: Transport Mappings for >>> Real-time Application Quality-of-Service Monitoring (RAQMON) >>> Protocol Data Unit (PDU) (Proposed Standard - IETF stream) rfc4681: >>> TLS User Mapping Extension (Proposed Standard - IETF stream) rfc4680: TL= S Handshake Message for Supplemental Data (Proposed >>> Standard - IETF stream) rfc4680: TLS Handshake Message for >>> Supplemental Data (Proposed Standard - IETF stream) rfc4642: Using >>> Transport Layer Security (TLS) with Network News Transfer Protocol >>> (NNTP) (Proposed Standard - IETF stream) rfc4642: Using Transport >>> Layer Security (TLS) with Network News Transfer Protocol (NNTP) >>> (Proposed Standard - IETF stream) rfc4616: The PLAIN Simple >>> Authentication and Security Layer (SASL) Mechanism (Proposed >>> Standard - IETF stream) rfc4616: The PLAIN Simple Authentication >>> and Security Layer (SASL) Mechanism (Proposed Standard - IETF >>> stream) rfc4582: The Binary Floor Control Protocol (BFCP) (Proposed >>> Standard - IETF stream) rfc4582: The Binary Floor Control Protocol >>> (BFCP) (Proposed Standard - IETF stream) rfc4540: NEC's Simple >>> Middlebox Configuration (SIMCO) Protocol Version 3.0 (Experimental >>> - Independent Submission Editor stream) rfc4540: NEC's Simple >>> Middlebox Configuration (SIMCO) Protocol Version 3.0 (Experimental >>> - Independent Submission Editor stream) rfc4531: Lightweight >>> Directory Access Protocol (LDAP) Turn Operation (Experimental - >>> IETF stream) rfc4513: Lightweight Directory Access Protocol (LDAP): >>> Authentication Methods and Security Mechanisms (Proposed Standard - >>> IETF stream) rfc3436: Transport Layer Security over Stream Control >>> Transmission Protocol (Proposed Standard - IETF stream) rfc3436: >>> Transport Layer Security over Stream Control Transmission Protocol >>> (Proposed Standard - IETF stream) rfc3329: Security Mechanism >>> Agreement for the Session Initiation Protocol (SIP) (Proposed >>> Standard - IETF stream) rfc3329: Security Mechanism Agreement for >>> the Session Initiation Protocol (SIP) (Proposed Standard - IETF >>> stream) rfc3261: SIP: Session Initiation Protocol (Proposed >>> Standard - IETF stream) rfc3261: SIP: Session Initiation Protocol >>> (Proposed Standard - IETF stream) rfc2246: The TLS Protocol Version >>> 1.0 (Proposed Standard - IETF stream) rfc6749: The OAuth 2.0 >>> Authorization Framework (Proposed Standard - IETF stream) rfc6739: >>> Synchronizing Service Boundaries and Elements Based on >>> the Location-to-Service Translation (LoST) Protocol (Experimental - >>> IETF stream) rfc6739: Synchronizing Service Boundaries and >>> Elements Based on the Location-to-Service Translation >>> (LoST) Protocol (Experimental - IETF stream) rfc6367: Addition of >>> the Camellia Cipher Suites to Transport Layer Security (TLS) >>> (Informational - IETF stream) rfc6367: Addition of the Camellia >>> Cipher Suites to Transport Layer Security (TLS) (Informational - >>> IETF stream) rfc6176: Prohibiting Secure Sockets Layer (SSL) >>> Version 2.0 (Proposed Standard - IETF stream) rfc6176: Prohibiting >>> Secure Sockets Layer (SSL) Version 2.0 (Proposed Standard - IETF >>> stream) rfc6042: Transport Layer Security (TLS) Authorization Using >>> KeyNote (Informational - Independent Submission Editor stream) rfc5878: T= ransport Layer Security (TLS) Authorization Extensions >>> (Experimental - IETF stream) rfc5469: DES and IDEA Cipher Suites >>> for Transport Layer Security (TLS) (Informational - IETF stream) rfc5469= : DES and IDEA Cipher Suites for Transport Layer Security >>> (TLS) (Informational - IETF stream) rfc5422: Dynamic Provisioning >>> Using Flexible Authentication via Secure Tunneling Extensible >>> Authentication Protocol (EAP-FAST) (Informational - IETF stream) rfc5422= : Dynamic Provisioning Using Flexible Authentication via >>> Secure Tunneling Extensible Authentication Protocol (EAP-FAST) >>> (Informational - IETF stream) rfc5364: Extensible Markup Language >>> (XML) Format Extension for Representing Copy Control Attributes in >>> Resource Lists (Proposed Standard - IETF stream) rfc5364: >>> Extensible Markup Language (XML) Format Extension for Representing >>> Copy Control Attributes in Resource Lists (Proposed Standard - IETF >>> stream) rfc5281: Extensible Authentication Protocol Tunneled >>> Transport Layer Security Authenticated Protocol Version 0 >>> (EAP-TTLSv0) (Informational - IETF stream) rfc5281: Extensible >>> Authentication Protocol Tunneled Transport Layer Security >>> Authenticated Protocol Version 0 (EAP-TTLSv0) (Informational - IETF >>> stream) rfc5263: Session Initiation Protocol (SIP) Extension for >>> Partial Notification of Presence Information (Proposed Standard - >>> IETF stream) rfc5263: Session Initiation Protocol (SIP) Extension >>> for Partial Notification of Presence Information (Proposed Standard >>> - IETF stream) rfc5238: Datagram Transport Layer Security (DTLS) >>> over the Datagram Congestion Control Protocol (DCCP) (Proposed >>> Standard - IETF stream) rfc5216: The EAP-TLS Authentication >>> Protocol (Proposed Standard - IETF stream) rfc5216: The EAP-TLS >>> Authentication Protocol (Proposed Standard - IETF stream) rfc5158: >>> 6to4 Reverse DNS Delegation Specification (Informational - IETF >>> stream) rfc5091: Identity-Based Cryptography Standard (IBCS) #1: >>> Supersingular Curve Implementations of the BF and BB1 Cryptosystems >>> (Informational - IETF stream) rfc5054: Using the Secure Remote >>> Password (SRP) Protocol for TLS Authentication (Informational - >>> IETF stream) rfc5054: Using the Secure Remote Password (SRP) >>> Protocol for TLS Authentication (Informational - IETF stream) rfc5049: A= pplying Signaling Compression (SigComp) to the Session >>> Initiation Protocol (SIP) (Proposed Standard - IETF stream) rfc3501: INT= ERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 (Proposed >>> Standard - IETF stream) rfc3501: INTERNET MESSAGE ACCESS PROTOCOL - >>> VERSION 4rev1 (Proposed Standard - IETF stream) rfc4346: The >>> Transport Layer Security (TLS) Protocol Version 1.1 (Proposed >>> Standard - IETF stream) rfc2246: The TLS Protocol Version 1.0 >>> (Proposed Standard - IETF stream) rfc4346: The Transport Layer >>> Security (TLS) Protocol Version 1.1 (Proposed Standard - IETF >>> stream) rfc4279: Pre-Shared Key Ciphersuites for Transport Layer >>> Security (TLS) (Proposed Standard - IETF stream) rfc4261: Common >>> Open Policy Service (COPS) Over Transport Layer Security (TLS) >>> (Proposed Standard - IETF stream) rfc4235: An INVITE-Initiated >>> Dialog Event Package for the Session Initiation Protocol (SIP) >>> (Proposed Standard - IETF stream) rfc4235: An INVITE-Initiated >>> Dialog Event Package for the Session Initiation Protocol (SIP) >>> (Proposed Standard - IETF stream) rfc4217: Securing FTP with TLS >>> (Proposed Standard - IETF stream) rfc4168: The Stream Control >>> Transmission Protocol (SCTP) as a Transport for the Session >>> Initiation Protocol (SIP) (Proposed Standard - IETF stream) rfc4162: Add= ition of SEED Cipher Suites to Transport Layer Security >>> (TLS) (Proposed Standard - IETF stream) rfc4111: Security Framework >>> for Provider-Provisioned Virtual Private Networks (PPVPNs) >>> (Informational - IETF stream) rfc4097: Middlebox Communications >>> (MIDCOM) Protocol Evaluation (Informational - IETF stream) rfc4097: >>> Middlebox Communications (MIDCOM) Protocol Evaluation >>> (Informational - IETF stream) rfc3983: Using the Internet Registry >>> Information Service (IRIS) over the Blocks Extensible Exchange >>> Protocol (BEEP) (Proposed Standard - IETF stream) rfc3943: >>> Transport Layer Security (TLS) Protocol Compression Using >>> Lempel-Ziv-Stac (LZS) (Informational - IETF stream) rfc3903: >>> Session Initiation Protocol (SIP) Extension for Event State >>> Publication (Proposed Standard - IETF stream) rfc6749: The OAuth >>> 2.0 Authorization Framework (Proposed Standard - IETF stream) rfc3887: M= essage Tracking Query Protocol (Proposed Standard - IETF >>> stream) rfc3871: Operational Security Requirements for Large >>> Internet Service Provider (ISP) IP Network Infrastructure >>> (Informational - IETF stream) rfc3871: Operational Security >>> Requirements for Large Internet Service Provider (ISP) IP Network >>> Infrastructure (Informational - IETF stream) rfc3856: A Presence >>> Event Package for the Session Initiation Protocol (SIP) (Proposed >>> Standard - IETF stream) rfc3767: Securely Available Credentials >>> Protocol (Proposed Standard - IETF stream) rfc3749: Transport Layer >>> Security Protocol Compression Methods (Proposed Standard - IETF >>> stream) rfc3749: Transport Layer Security Protocol Compression >>> Methods (Proposed Standard - IETF stream) rfc3656: The Mailbox >>> Update (MUPDATE) Distributed Mailbox Database Protocol >>> (Experimental - Independent Submission Editor stream) rfc3568: >>> Known Content Network (CN) Request-Routing Mechanisms >>> (Informational - IETF stream) rfc6750: The OAuth 2.0 Authorization >>> Framework: Bearer Token Usage (Proposed Standard - IETF stream) rfc6750:= The OAuth 2.0 Authorization Framework: Bearer Token Usage >>> (Proposed Standard - IETF stream) rfc7030: Enrollment over Secure >>> Transport (Proposed Standard - IETF stream) rfc7030: Enrollment >>> over Secure Transport (Proposed Standard - IETF stream) rfc7465: >>> Prohibiting RC4 Cipher Suites (Proposed Standard - IETF stream) rfc7465:= Prohibiting RC4 Cipher Suites (Proposed Standard - IETF >>> stream) rfc7507: TLS Fallback Signaling Cipher Suite Value (SCSV) >>> for Preventing Protocol Downgrade Attacks (Proposed Standard - IETF >>> stream) rfc7507: TLS Fallback Signaling Cipher Suite Value (SCSV) >>> for Preventing Protocol Downgrade Attacks (Proposed Standard - IETF >>> stream) rfc7562: Transport Layer Security (TLS) Authorization Using >>> Digital Transmission Content Protection (DTCP) Certificates >>> (Informational - Independent Submission Editor stream) rfc7562: >>> Transport Layer Security (TLS) Authorization Using Digital >>> Transmission Content Protection (DTCP) Certificates (Informational >>> - Independent Submission Editor stream) rfc7568: Deprecating Secure >>> Sockets Layer Version 3.0 (Proposed Standard - IETF stream) rfc7568: Dep= recating Secure Sockets Layer Version 3.0 (Proposed >>> Standard - IETF stream) rfc8422: Elliptic Curve Cryptography (ECC) >>> Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and >>> Earlier (Proposed Standard - IETF stream) rfc8422: Elliptic Curve >>> Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) >>> Versions 1.2 and Earlier (Proposed Standard - IETF stream) >>> _______________________________________________ IETF-Announce >>> mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinf= o/ietf-announce >> _______________________________________________ TLS mailing list TLS@ietf= .org https://www.ietf.org/mailman/listinfo/tls > From nobody Mon Dec 7 06:07:57 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@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: [Emu] [core] [Ace] Proposed charter for ACE (EAP over CoAP?) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" 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:51:01 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@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: Subject: Re: [Emu] [core] [Ace] Proposed charter for ACE (EAP over CoAP?) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" 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 14:10:06 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@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: [Emu] [Ace] [core] Proposed charter for ACE (EAP over CoAP?) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" 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 02:05:08 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@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: X-Mailman-Approved-At: Wed, 09 Dec 2020 02:05:08 -0800 Subject: Re: [Emu] [core] [Ace] Proposed charter for ACE (EAP over CoAP?) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" 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 Dans 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 *Gran 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.) > > Gran > > 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 Gran Selander < > > > > goran.selander@ericsson.com > > wrote: > > > > > > > >> Hi Daniel, > > > >> > > > >> > > > >> > > > >> Heres 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). > > > >> > > > >> > > > >> > > > >> Gran > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> 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) ---+----------- Tlcom 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 Dans 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 Gran 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.)

Gran

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 Gran Selander <

> >

> >> Hi Daniel,

> >>

> >>

> >>

> >> Heres 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).

> >>

> >>

> >>

> >> Gran

> >>

> >>

> >>

> >>

> >>

> >>

> >>

> >> 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) ---+----------- Tlcom 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 02:53:38 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F493A083B for ; Wed, 9 Dec 2020 02:53:37 -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, HTML_MESSAGE=0.001, NICE_REPLY_A=-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 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 8yoKguos35CD for ; Wed, 9 Dec 2020 02:53:36 -0800 (PST) Received: from mx02.puc.rediris.es (outbound4sev.lav.puc.rediris.es [130.206.19.177]) (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 E1F9C3A082F for ; Wed, 9 Dec 2020 02:53:34 -0800 (PST) Received: from xenon44.um.es (xenon44.um.es [155.54.212.171]) by mx02.puc.rediris.es with ESMTP id 0B9ArWMu008327-0B9ArWMv008327 for ; Wed, 9 Dec 2020 11:53:32 +0100 Received: from localhost (localhost [127.0.0.1]) by xenon44.um.es (Postfix) with ESMTP id B4EC7204E1 for ; Wed, 9 Dec 2020 11:53:32 +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 wpOULnDzmVuH for ; Wed, 9 Dec 2020 11:53:32 +0100 (CET) Received: from [10.188.167.166] (eth-east-parth2-46-193-68-109.wb.wifirst.net [46.193.68.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: eduardo.ingles) by xenon44.um.es (Postfix) with ESMTPSA id 7C82B204F6 for ; Wed, 9 Dec 2020 11:53:31 +0100 (CET) To: emu@ietf.org References: From: "Eduardo Ingles (UM)" Message-ID: <637c83c0-a281-7d1f-2ef5-f928dc12c267@um.es> Date: Wed, 9 Dec 2020 11:53:27 +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: Content-Type: multipart/alternative; boundary="------------99CFC5BBFBA2DD6A791A294B" Content-Language: es-ES X-FEAS-SPF: spf-result=pass, ip=155.54.212.171, helo=xenon44.um.es, mailFrom=eduardo.ingles@um.es Authentication-Results: mx02.puc.rediris.es; spf=pass (rediris.es: domain of eduardo.ingles@um.es designates 155.54.212.171 as permitted sender) smtp.mailfrom=eduardo.ingles@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=iIw2PxTa9Xv6vlsgl9+cIrQ8qC47Ki/B9sRxzJbxiB4=; b=dP8Fkgy09rRPtUcHijQcD79wbPgi0DAzwbB6ILSxnhsCMLlYIpU6G5u4FvKgfpzDXC00U+o8IIza oTwo4caurEBfrwnDynFsvX2Kf0jtUUCGtG1jLjY7YHw+VSBiVLxSheyB/MtEqQJ16UxeMjFCaL0O 95HEPqi0v3VgspWYxFiwNzAjjcKiXRvxEs/Jx5ojEZGctQsymFI9gxlZ5Yg8DznUxj/ioWXYT8FX rxTS0RHe/ft1wMppEJCcF4HfQ3OWnrP3KUiSDe8eeCZCL6Yx6E5secujWie2iEoYbQC8dp/80hdS eZMwOJAp1HRrW5Si0P+6E2l1aQ+vVymeioaf9Q== Archived-At: Subject: Re: [Emu] Working Group Last Call for draft-ietf-emu-eap-noob-02 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 10:53:38 -0000 This is a multi-part message in MIME format. --------------99CFC5BBFBA2DD6A791A294B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi all, I have worked with EAP-NOOB and implemented a constrained version for Contiki (https://github.com/eduingles/coap-eap-noob). I exposed some issues on the list such as adding support for P-256 and clarifying the text on waiting exchange and the authors have addressed my issues. The draft now has P-256 as one of the curves. I support it and I think it is ready for publication. Best regards, Eduardo Inglés El 22/11/2020 a las 0:31, Joseph Salowey escribió: > At  IETF 109 meeting there was support for moving EAP-NOOB forward.  > The chairs and authors believe the document is ready to progress so > this starts the working group last call for EAP-NOOB [1].   Please > review the document and send comments to the list by December 11, > 2020.  Statements of support or opposition are welcome especially if > accompanied with reasons for the position. > > Thanks, > > Joe > > [1] https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/ > > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu -- Eduardo Inglés Sánchez eduardo.ingles@um.es Department of Information and Communication Engineering Faculty of Computer Science University of Murcia 30100 Murcia, Spain --------------99CFC5BBFBA2DD6A791A294B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi all,

I have worked with EAP-NOOB and implemented a constrained version for Contiki (https://github.com/eduingles/coap-eap-noob). I exposed some issues on the list such as adding support for P-256 and clarifying the text on waiting exchange and the authors have addressed my issues. The draft now has P-256 as one of the curves. I support it and I think it is ready for publication.

Best regards,
Eduardo Inglés

El 22/11/2020 a las 0:31, Joseph Salowey escribió:
At  IETF 109 meeting there was support for moving EAP-NOOB forward.  The chairs and authors believe the document is ready to progress so this starts the working group last call for EAP-NOOB [1].   Please review the document and send comments to the list by December 11, 2020.  Statements of support or opposition are welcome especially if accompanied with reasons for the position.  

Thanks,

Joe



_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
-- 
Eduardo Inglés Sánchez
eduardo.ingles@um.es

Department of Information and Communication Engineering
Faculty of Computer Science
University of Murcia
30100 Murcia, Spain
--------------99CFC5BBFBA2DD6A791A294B-- From nobody Wed Dec 9 03:46:26 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@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: [Emu] [Ace] [core] Proposed charter for ACE (EAP over CoAP?) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" 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:30 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94AB23A1415 for ; Wed, 9 Dec 2020 04:12:22 -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=unavailable 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 CxMmfhVIQiBh for ; Wed, 9 Dec 2020 04:12:19 -0800 (PST) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 068DC3A1402 for ; Wed, 9 Dec 2020 04:12:18 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id n14so1389435iom.10 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=GueE32De1aWscJ2KlVwwzOXtLlNGtKJYGP2hAypsrngPbN3UWd/kGmSD5Z3oVR89Xp +fhqGR0rlMXCerYdfS83FaNMuM7u07sbJJBy4uSxTBNgRBtKhqqgujfEg65i/bOJ1IsS 2LnmxoKM3uejVObEZ71Gm6vu3zCuj8o5tn6zWlqMW+1wh2DQo0dtmqywwv+NcwfxusD+ qFFOC3ri6khWVp2YC0uIfzTTuVSJ6WHFZMoZhrXpJoBCQBdn6OOqSE/bgMFJAPXvq0SL wfUcDuV9bUzdipVkXVgmSUGGI6GHbyI1JGBL/9Eda576URKgHT/u1PcCpe4LFMvvoEwG 8UmA== X-Gm-Message-State: AOAM531mqO2tVNxLd0wZmC/DBoDLchKe6Y4YaTAI3TyJYAq4OTn7gc0h x0vX0er3ZzHOs9e6gRQiyV6lSCJ+BUcL0fVhhoJM+A== 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: [Emu] [Ace] [core] Proposed charter for ACE (EAP over CoAP?) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 12:12:23 -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:08 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@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: [Emu] [Ace] Proposed charter for ACE (EAP over CoAP?) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" 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:15 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@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: [Emu] [core] [Ace] Proposed charter for ACE (EAP over CoAP?) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 13:52:10 -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 10:55:54 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@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: [Emu] [Ace] [core] Proposed charter for ACE (EAP over CoAP?) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" 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 01:04:47 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@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: [Emu] [Ace] [core] Proposed charter for ACE (EAP over CoAP?) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" 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 06:13:52 2020 Return-Path: X-Original-To: emu@ietf.org Delivered-To: emu@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A89963A0E7E; Thu, 10 Dec 2020 06:13:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-emu-eap-tls13@ietf.org, emu-chairs@ietf.org, emu@ietf.org, Joseph Salowey , joe@salowey.net X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <160760962730.29119.12837976351667725920@ietfa.amsl.com> Date: Thu, 10 Dec 2020 06:13:47 -0800 Archived-At: Subject: [Emu] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf-?= =?utf-8?q?emu-eap-tls13-13=3A_=28with_COMMENT=29?= X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2020 14:13:48 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-emu-eap-tls13-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. Improving EAP-TLS is indeed welcome! BTW, I left the security review to the SEC Area Directors. Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Abstract -- Should the abstract briefly talk about EAP? -- Section 1 -- Should "ietf-tls-oldversions-deprecate" be normative ? -- Section 2 -- Nicely done to have kept the same sub-section numbers with respect to RFC 5216. Kudos ! -- Section 2.1.1 & 2.1.3 & 2.1.4 -- I find "This section updates Section 2.1.1 of [RFC5216]." a little ambiguous as it the 'updated section' is not identified clearly. I.e., as the sections in RFC 5216 are not too long, why not simply providing whole new sections ? -- Section 5.9 -- What is the added benefit of this section (pervasive monitoring) compared to section 5.8 (privacy considerations)? Esp when I am afraid that pervasive monitoring is deeper in the network rather than in the access network (happy to be corrected) == NITS == None of us are native English speaker, but "e.g." as "i.e." are usually followed by a comma while "but" has usually no comma before ;-) From nobody Thu Dec 10 09:43:51 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@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: [Emu] [core] [Ace] Proposed charter for ACE (EAP over CoAP?) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" 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 Thu Dec 10 09:53:19 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 367263A1147 for ; Thu, 10 Dec 2020 09:53:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l_gy_XxkJbm6 for ; Thu, 10 Dec 2020 09:53:14 -0800 (PST) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2103.outbound.protection.outlook.com [40.107.94.103]) (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 E28E53A1146 for ; Thu, 10 Dec 2020 09:53:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RAg28iGgIXAvESaRBKUuoCPH25/TxFYpBkelMzgCOjImprB7hqSjaYDmr7SQlmTBCicvvKoQ0dUU7gl3Wqw81RuQ3qmJyjiBSoiAz8+tUUthTwEoQGuJ2mRC11tbosUvcnxDzCfaqpIhfhHWGdGKsykQUbQnu16aAXHJrgAbodpG0ByDt/cWW6sU0c4P+1vEpziHPhcO2mmbli/azDW3L0PJAc1cQFwnbqDAkYZdwX5EwZmRHntdmOVQ6oYrw8dcNn9169wtBBP1+Y/e92pqiwQEKz7nxNjLjqGLX1ptA3Xj8SKT8YV2y/e3mSrKSYUofXSFgoggvZr8xTHtoeMrNw== 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=fhXHRXUYEzorndxPinx7saskveTBZtF9Bhwu10g6xwE=; b=Kd05B5DNRhQx7LF50WGXMEJdFYMBbIBpqoikUczi9Ya0aHdtNsCMtQDQ2zJBMkemE2+i1V4qOJuD7H/KxgQkU6ToEwjXhjNAjcALnp/37/HG/e9oSXuGUIqR2XhidZPzqgCoSUFmYimOpbYv7RBk8atT1MFhlIGSkOPexXlkCzhXtXJ3Ay4fpZgRClbzdHuBlMatFjgg/IutsSuJFSNnpbyBkmEE4HXP7FLux+6+TD8dYlnOR1bnDMy8SlehQUU7VLtZ8pIsPvWrpjZ5vT837Q6Xh56g+McXHO4lbVjRAtI5FpujNhTeIIPTFbqGiUHBjFYuiNJGUmGivUYmvajkLg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fhXHRXUYEzorndxPinx7saskveTBZtF9Bhwu10g6xwE=; b=czBP13Yb0TK4vsTzN7FwNRB8h2D6ZKs6JYFcVI3117sa5ldOa5H1d7LZ7MN0k/t2fFMwDPMO0ahCyw0/6IBZJOpHs8L66wMSHUnxBRFRQzhnmmsizgoawb7ju8RpXINnKamSK9JQ2AVP3M3veMqx6T2NgVvCq/vTFd0pNlQRy3M= Received: from (2603:10b6:302:10::31) by MWHPR21MB0637.namprd21.prod.outlook.com (2603:10b6:300:127::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3676.7; Thu, 10 Dec 2020 17:53:13 +0000 Received: from MW2PR2101MB0923.namprd21.prod.outlook.com ([fe80::9d4d:3620:f1ef:c826]) by MW2PR2101MB0923.namprd21.prod.outlook.com ([fe80::9d4d:3620:f1ef:c826%9]) with mapi id 15.20.3654.012; Thu, 10 Dec 2020 17:53:13 +0000 From: Jorge Vergara To: Joseph Salowey CC: Oleg Pekar , EMU WG , Jouni Malinen Thread-Topic: Proposed Resolution for TEAP errata 5768 Thread-Index: AQHWqk8KjKSqiIUcrEGlgYUSoVjMjamnZnSAgCkz4HCABMK2AIAbiMgQ Date: Thu, 10 Dec 2020 17:53:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=de68d63a-3a66-48b1-a498-e52c10d357f5; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-12-10T17:52:26Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: salowey.net; dkim=none (message not signed) header.d=none;salowey.net; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:7:a13e:e605:c16b:79a7] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 3ef140d7-d5a9-4759-96cc-08d89d3476ee x-ms-traffictypediagnostic: MWHPR21MB0637: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +XLoktBHXS6qCcQy4gNuhFWCSBIOrO6WWD//+a3qEzIJnti96d0A3C/3A+nV1aQm0n72s5kjBqxe8crtA2OUjyi4FIouFXayGNDxazPk/IaYa7QQxgXtQFL2ClirEzV8hKVNsXAxwI35bRjLHD0YCXROAgW42A55OOD6xWyMOeVO9htmzEsSwOvWMwS0MGIA6PGsPusYMeofeRc+F1XTJrgB2qfbZU1KpjhrxsTEeE5G4Fsmb/qwXg79d0Y0IjAwfhWqhuW0erkuhJ0Z+1A+/KFhyXi+dCONHQrBfxVzW7rsHqPmpdNTQroPgl48CkvG953v+RGC0SwxKOLQ+q7x4bOr7lgAqb23oXbmRhisXJd7eSmo5zfjlllklpRhCFRAgmISUxPFKEPwkbGBmH7axdjB2+ZTs2WbPpG87lOY5qITeMjWpykb02yTaWsVarvmuC9ldVDUUmJF6erNPHxCEA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW2PR2101MB0923.namprd21.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(346002)(366004)(376002)(82950400001)(82960400001)(52536014)(8990500004)(166002)(54906003)(83380400001)(2906002)(966005)(186003)(7696005)(508600001)(6506007)(53546011)(4326008)(71200400001)(10290500003)(8936002)(8676002)(33656002)(55016002)(86362001)(76116006)(5660300002)(6916009)(66946007)(9686003)(66446008)(64756008)(66476007)(66556008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?cWZTenFGTjFwRjRqem9nVlE5OTNlRDlNazFCTUVtUG55TUZkazJxYzdnUlZ3?= =?utf-8?B?VDlWVHJiRzh6S2RUTGlIQjBsc3l3TURwdkZtRWdUVjhKcmR3Uys5THNMcWNh?= =?utf-8?B?cnJTc3RjaGpad1VKUTlYUkxmcEFKdVZZTUUrdW9RdzJsaWFadU5CUUhLUGow?= =?utf-8?B?d3dKYjAvdEkyTUw0WC9qQjdiaG41WVJBMFZlOEZxb0dRd0lTUk9lS1p4UFdl?= =?utf-8?B?dmhlcjBLbk9aR3kzeHRFSWUyeVl3TnI5NGRQMkN4Kzhkak80WEZkNTRmcVNh?= =?utf-8?B?U0hubXBUek1senRGVDF1aHJZbU9UUW1RbitLdmloK1Q0Y0toUGJMKzBZbUxG?= =?utf-8?B?MFNWQzcvOEwwSjJFbVdiM1cwYk1GWTBuZjFYWnJHUVBmMHpPTHVySzBzYW03?= =?utf-8?B?VUhON2ZKK2phWlN3ZUd4cERZa09OZUhPbzcyendWWW1KR0pidnoyclJ0ZTJn?= =?utf-8?B?Mi9ZSEVIaDlvYml2ZGMvUjdEVGZ4dUMzUmtsNi9zS1RxcVFpcDNwWEYrL2JU?= =?utf-8?B?S2pPb1dVWVVzemc2VEVpL0ViSUhZR0o5WHI0WTNyNUNqMGtvOUJWYmpVbEpZ?= =?utf-8?B?Q20vZVlCU3Z1MlJUcVVQeVkvd3RVU1VUejhkbGw1SlA1LzRQUVRjSkk1bzA1?= =?utf-8?B?OWdsMGtyNFMwUE02QklIa2VaWjJjV2ZNNExpdHlDSWJLMFFlOXd2OGVZSG9G?= =?utf-8?B?aVFsSFllc2N6VGEzRkVhdkc2aklpcjdwVzhGU1d3WjJFSEZLcFpNL3Mvb0Nt?= =?utf-8?B?Y2xKREhLQWJ1YU41eGtURGhnVHljRmNvZUxLUzdYQ2dJaktZOVViUFdJaGRz?= =?utf-8?B?aFByMzFwZ0hqaVkvZGY4ZWo1WElJWmVjMFl2VW44dUhmcFlTaS9TOW1QNFhE?= =?utf-8?B?ZGtidzN0emxVQzVGMVN2QllrY0l5Ti9nbFNIbzFsNGlQdmlMV0lZdGpybFBR?= =?utf-8?B?bnRrWXhWbldETjlJdjQzQSsreXo2MlpXaXlzSklYamZUMWsvV0lBK3d0NGVh?= =?utf-8?B?MFlqVjVnK3FhOFZUV1E5OVJzOTBsbjZoUk5ZUnFyenJFQ2p0QTI0TUJGYS83?= =?utf-8?B?bGoyMUFvQzAwaS9TVTlxRU1EdktSTVBjVFI3cXZCSEtzbXdSazA3OHZRdVdh?= =?utf-8?B?SmdhdGZkNFpNc1hwbjBMUXYyRGlaSk1uMHdWaFFLSXl5Q0VDRFQ1VW9Sd2Z2?= =?utf-8?B?QjBkY1FObmlsQ1hHdGt3dHRrNjlMMGRBUkl6RGtKa2YxMCtkeUNZeC9wMUxl?= =?utf-8?B?OEdSWndFcjFMcUgwcW9UTWo4NHlneTVZSFVxUFFQSnJUM1d3Z3pyV0lMZVFN?= =?utf-8?B?eStTMDNBdWlTWmJRVkduaE9GcVZJZHJkTjlJZ0p4ZktuNVBnQk1KVjJ0Zjhh?= =?utf-8?Q?0c/UmwjAUezHf5AIPkgfUkUfJ55YoqqI=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MW2PR2101MB092324163BC435330C8904CDD1CB1MW2PR2101MB0923_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW2PR2101MB0923.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3ef140d7-d5a9-4759-96cc-08d89d3476ee X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Dec 2020 17:53:12.9304 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: DKw1jGR2C368iGmx/kkLA9ow1TwLf8aHH3LBfwKwpfgAtOvPx73F8kAj9CqyyS251VH6KdrpN5xpBQqclUBFFw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0637 Archived-At: Subject: Re: [Emu] Proposed Resolution for TEAP errata 5768 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2020 17:53:17 -0000 --_000_MW2PR2101MB092324163BC435330C8904CDD1CB1MW2PR2101MB0923_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBjaGFuZ2UgbG9va3MgZ29vZCB0byBtZS4gV291bGQgYXBwcmVjaWF0ZSBhIHNhbml0eSBj aGVjayBvZiBhbm90aGVyIGltcGxlbWVudGF0aW9uIGJ5IE9sZWcgdG8gbWFrZSBzdXJlIEkgaGF2 ZSBteSBmYWN0cyBzdHJhaWdodCBoZXJlLg0KDQpGcm9tOiBKb3NlcGggU2Fsb3dleSA8am9lQHNh bG93ZXkubmV0Pg0KU2VudDogU3VuZGF5LCBOb3ZlbWJlciAyMiwgMjAyMCA5OjI0IFBNDQpUbzog Sm9yZ2UgVmVyZ2FyYSA8am92ZXJnYXJAbWljcm9zb2Z0LmNvbT4NCkNjOiBPbGVnIFBla2FyIDxv bGVnLnBla2FyLjIwMTdAZ21haWwuY29tPjsgRU1VIFdHIDxlbXVAaWV0Zi5vcmc+OyBKb3VuaSBN YWxpbmVuIDxqQHcxLmZpPg0KU3ViamVjdDogUmU6IFByb3Bvc2VkIFJlc29sdXRpb24gZm9yIFRF QVAgZXJyYXRhIDU3NjgNCg0KDQoNCk9uIFRodSwgTm92IDE5LCAyMDIwIGF0IDg6NTMgUE0gSm9y Z2UgVmVyZ2FyYSA8am92ZXJnYXJAbWljcm9zb2Z0LmNvbTxtYWlsdG86am92ZXJnYXJAbWljcm9z b2Z0LmNvbT4+IHdyb3RlOg0KU29ycnkgZm9yIHRoZSBsYXN0IG1pbnV0ZSBjb21tZW50IG9uIHRo aXMgb25lIGJlZm9yZSB0aGUgbWVldGluZy4gSSB3b3VsZCBsaWtlIHRvIG1hcmsgdGhpcyBhcyBh IOKAnGRpc2N1c3PigJ0gLSBJIGhhdmUgc29tZSBjb21wYXQgY29uY2VybiBhYm91dCBtYWtpbmcg dGhlIFRMViBsZW5ndGggdmFyaWFibGUuIEN1cnJlbnQgaW1wbGVtZW50YXRpb25zIHRydW5jYXRl IHRoZSBNQUMgZmllbGQgYXQgMjAgb2N0ZXRzLiBBbHRob3VnaCBJIGFncmVlIGluIHNwaXJpdCB3 aXRoIHRoZSBkaXJlY3Rpb24gb2YgdGhpcyBjaGFuZ2UsIEkgdGhpbmsgaXQgd291bGQgcmVxdWly ZSBjaGFuZ2luZyB0aGUgdmVyc2lvbiBvZiB0aGUgQ3J5cHRvLUJpbmRpbmcgVExWLg0KDQpJIHJl Y29nbml6ZSB0aGF0IG1vc3QgcHJvYmFibHkgd29u4oCZdCBoYXZlIHRpbWUgdG8gcmV2aWV3IHRo aXMgY29uY2VybiBiZWZvcmUgdGhlIG1lZXRpbmcgYW5kIHNvIHRoZSBkaXNjdXNzaW9uIG1heSBu b3QgYmUgYWJsZSB0byBvY2N1ciB0aGVyZS4gQXBvbG9naWVzIGFnYWluIGFzIEkgb25seSByZWFs aXplZCB0aGlzIGNvbmNlcm4gYXMgSSB3YXMgZ2l2aW5nIGV2ZXJ5dGhpbmcgYSBmaW5hbCBwYXNz LW92ZXIuDQoNCg0KW0pvZV0gVGhhbmtzIGZvciBjYXRjaGluZyB0aGlzLiAgSWYgdGhpcyBpcyB0 aGUgY2FzZSB0aGVuIHdlIHNob3VsZCBoYXZlIHRoZSBlcnJhdGEgcmVzb2x1dGlvbiByZWZsZWN0 IHdoYXQgaW1wbGVtZW50YXRpb25zIGRvIGFuZCBsZWF2ZSB0aGUgcmVzdCBvZiB0aGUgY2hhbmdl IGZvciBhIGRvY3VtZW50IHVwZGF0ZS4NCg0KRm9yIHRoaXMgSSBzdWdnZXN0IHRoYXQgd2UgbGVh dmUgc2VjdGlvbiA0LjIuMTMgdW5jaGFuZ2VkIGFuZCBtYWtlIGNoYW5nZXMgdG8gNS4zLg0KDQpT ZWN0aW9uIDUuMyBTYXlzOg0KDQogVGhlIENvbXBvdW5kIE1BQyBjb21wdXRhdGlvbiBpcyBhcyBm b2xsb3dzOg0KDQogICAgICBDTUsgPSBDTUtbal0NCiAgICAgIENvbXBvdW5kLU1BQyA9IE1BQygg Q01LLCBCVUZGRVIgKQ0KDQogICB3aGVyZSBqIGlzIHRoZSBudW1iZXIgb2YgdGhlIGxhc3Qgc3Vj Y2Vzc2Z1bGx5IGV4ZWN1dGVkIGlubmVyIEVBUA0KICAgbWV0aG9kLCBNQUMgaXMgdGhlIE1BQyBm dW5jdGlvbiBuZWdvdGlhdGVkIGluIFRMUyAxLjIgW1JGQzUyNDZdLCBhbmQNCiAgIEJVRkZFUiBp cyBjcmVhdGVkIGFmdGVyIGNvbmNhdGVuYXRpbmcgdGhlc2UgZmllbGRzIGluIHRoZSBmb2xsb3dp bmcNCiAgIG9yZGVyOg0KDQogICAxICBUaGUgZW50aXJlIENyeXB0by1CaW5kaW5nIFRMViBhdHRy aWJ1dGUgd2l0aCBib3RoIHRoZSBFTVNLIGFuZCBNU0sNCiAgICAgIENvbXBvdW5kIE1BQyBmaWVs ZHMgemVyb2VkIG91dC4NCg0KICAgMiAgVGhlIEVBUCBUeXBlIHNlbnQgYnkgdGhlIG90aGVyIHBh cnR5IGluIHRoZSBmaXJzdCBURUFQIG1lc3NhZ2UuDQoNCkl0IFNob3VsZCBzYXk6DQoNCiBUaGUg Q29tcG91bmQgTUFDIGNvbXB1dGF0aW9uIGlzIGFzIGZvbGxvd3M6DQoNCiAgICAgIENNSyA9IENN S1tqXQ0KICAgICAgQ29tcG91bmQtTUFDID0gTUFDKCBDTUssIEJVRkZFUiApDQoNCiAgIHdoZXJl IGogaXMgdGhlIG51bWJlciBvZiB0aGUgbGFzdCBzdWNjZXNzZnVsbHkgZXhlY3V0ZWQgaW5uZXIg RUFQDQogICBtZXRob2QsIE1BQyBpcyBITUFDIFtSRkMyMTA0XSB1c2luZyB0aGUgaGFzaCBmdW5j dGlvbiBuZWdvdGlhdGVkIGluDQogICBUTFMgW1JGQzUyNDZdLiAgSWYgdGhlIG91dHB1dCBvZiB0 aGUgSE1BQyBpcyBncmVhdGVyIHRoYW4gMjAgYnl0ZXMgdGhlbg0KICAgaXQgaXMgdHJ1bmNhdGVk IHRvIDIwIGJ5dGVzLiAgVGhlIEJVRkZFUiBpcyBjcmVhdGVkIGFmdGVyIGNvbmNhdGVuYXRpbmcN CiAgIHRoZXNlIGZpZWxkcyBpbiB0aGUgZm9sbG93aW5nIG9yZGVyOg0KDQogICAxICBUaGUgZW50 aXJlIENyeXB0by1CaW5kaW5nIFRMViBhdHRyaWJ1dGUgd2l0aCBib3RoIHRoZSBFTVNLIGFuZCBN U0sNCiAgICAgIENvbXBvdW5kIE1BQyBmaWVsZHMgemVyb2VkIG91dC4NCg0KICAgMiAgVGhlIEVB UCBUeXBlIHNlbnQgYnkgdGhlIG90aGVyIHBhcnR5IGluIHRoZSBmaXJzdCBURUFQIG1lc3NhZ2Uu IFRoaXMNCiAgICAgICBpcyBhIHNpbmdsZSBvY3RldCBlbmNvZGVkIGFzICgweDM3KQ0KDQpKb3Jn ZSBWZXJnYXJhDQoNCkZyb206IE9sZWcgUGVrYXIgPG9sZWcucGVrYXIuMjAxN0BnbWFpbC5jb208 bWFpbHRvOm9sZWcucGVrYXIuMjAxN0BnbWFpbC5jb20+Pg0KU2VudDogU2F0dXJkYXksIE9jdG9i ZXIgMjQsIDIwMjAgNDozMCBQTQ0KVG86IEpvc2VwaCBTYWxvd2V5IDxqb2VAc2Fsb3dleS5uZXQ8 bWFpbHRvOmpvZUBzYWxvd2V5Lm5ldD4+DQpDYzogRU1VIFdHIDxlbXVAaWV0Zi5vcmc8bWFpbHRv OmVtdUBpZXRmLm9yZz4+OyBKb3VuaSBNYWxpbmVuIDxqQHcxLmZpPG1haWx0bzpqQHcxLmZpPj47 IEpvcmdlIFZlcmdhcmEgPGpvdmVyZ2FyQG1pY3Jvc29mdC5jb208bWFpbHRvOmpvdmVyZ2FyQG1p Y3Jvc29mdC5jb20+Pg0KU3ViamVjdDogUmU6IFByb3Bvc2VkIFJlc29sdXRpb24gZm9yIFRFQVAg ZXJyYXRhIDU3NjgNCg0KPiAyICBUaGUgRUFQIFR5cGUgc2VudCBieSB0aGUgb3RoZXIgcGFydHkg aW4gdGhlIGZpcnN0IFRFQVAgbWVzc2FnZS4gVGhpcyBpcyBhIHNpbmdsZSBvY3RldCBlbmNvZGVk IGFzICgweDM3KQ0KDQpTaG91bGRuJ3Qgd2UgY2xhcmlmeSB0aGUgbW90aXZhdGlvbiBmb3IgcGxh Y2luZyB0aGUgb2N0ZXQgd2l0aCBURUFQIHR5cGUgMHgzNyBpbnRvIHRoZSBCVUZGRVI/IEpvZSwg SSByZW1lbWJlciB5b3UgZXhwbGFpbmVkIHRoYXQgaXQgaXMgZm9yIHByb3RlY3Rpb24gYWdhaW5z dCBjcm9zcyBwcm90b2NvbCBhdHRhY2tzIGlmIENyeXB0by1CaW5kaW5nIFRMViB3YXMgcmV1c2Vk IChlLmcuIGZyb20gUEVBUCkuDQoNCk9uIFN1biwgT2N0IDI1LCAyMDIwIGF0IDEyOjQ1IEFNIEpv c2VwaCBTYWxvd2V5IDxqb2VAc2Fsb3dleS5uZXQ8bWFpbHRvOmpvZUBzYWxvd2V5Lm5ldD4+IHdy b3RlOg0KRXJyYXRhIDU3Njg6ICBodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGEvZWlk NTc2ODxodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9 aHR0cHMlM0ElMkYlMkZ3d3cucmZjLWVkaXRvci5vcmclMkZlcnJhdGElMkZlaWQ1NzY4JmRhdGE9 MDQlN0MwMSU3Q2pvdmVyZ2FyJTQwbWljcm9zb2Z0LmNvbSU3QzcwMTExNDJkMjY4NjQwNDlkYjE4 MDhkODhmNmZmZTVjJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3 QzYzNzQxNzA1ODQ1ODY1MjQ1NCU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdM akF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0Mx MDAwJnNkYXRhPUoySGtTVDBmRVRQJTJGdTVDSjc4OUluUkZGaUk5T3RYMWF3dUtVaGhEZkJTUSUz RCZyZXNlcnZlZD0wPg0KUHJvcG9zZWQgU3RhdGU6IFZlcmlmaWVkDQpSZXZpc2lvbjoNCg0KU2Vj dGlvbiA0LjIuMTMuIFNheXM6DQoNCkxlbmd0aA0KDQogICAgNzYNCg0KSXQgc2hvdWxkIHNheToN Cg0KTGVuZ3RoDQoNCiAgICAgMzYgcGx1cyB0aGUgbGVuZ3RoIG9mIHRoZSAyIE1BQyBmaWVsZHMN Cg0KU2VjdGlvbiA0LjIuMTMuIFNheXM6DQoNCiAgIEVNU0sgQ29tcG91bmQgTUFDDQoNCiAgICAg IFRoZSBFTVNLIENvbXBvdW5kIE1BQyBmaWVsZCBpcyAyMCBvY3RldHMuICBUaGlzIGNhbiBiZSB0 aGUgU2VydmVyDQogICAgICBNQUMgKEIxX01BQykgb3IgdGhlIENsaWVudCBNQUMgKEIyX01BQyku ICBUaGUgY29tcHV0YXRpb24gb2YgdGhlDQogICAgICBNQUMgaXMgZGVzY3JpYmVkIGluIFNlY3Rp b24gNS4zLg0KDQogICBNU0sgQ29tcG91bmQgTUFDDQoNCiAgICAgIFRoZSBNU0sgQ29tcG91bmQg TUFDIGZpZWxkIGlzIDIwIG9jdGV0cy4gIFRoaXMgY2FuIGJlIHRoZSBTZXJ2ZXINCiAgICAgIE1B QyAoQjFfTUFDKSBvciB0aGUgQ2xpZW50IE1BQyAoQjJfTUFDKS4gIFRoZSBjb21wdXRhdGlvbiBv ZiB0aGUNCiAgICAgIE1BQyBpcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA1LjMuDQoNCkl0IFNob3Vs ZCBTYXk6DQoNCiAgIEVNU0sgQ29tcG91bmQgTUFDDQoNCiAgICAgIFRoZSBjb21wdXRhdGlvbiBv ZiB0aGUgTUFDIGlzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDUuMy4gIFRoaXMgY2FuIGJlDQogICAg ICB0aGUgU2VydmVyIE1BQyAoQjFfTUFDKSBvciB0aGUgQ2xpZW50IE1BQyAoQjJfTUFDKS4NCg0K ICAgTVNLIENvbXBvdW5kIE1BQw0KDQogICAgICBUaGUgY29tcHV0YXRpb24gb2YgdGhlIE1BQyBp cyBkZXNjcmliZWQgaW4gU2VjdGlvbiA1LjMuICBUaGlzIGNhbiBiZQ0KICAgICAgdGhlIFNlcnZl ciBNQUMgKEIxX01BQykgb3IgdGhlIENsaWVudCBNQUMgKEIyX01BQykuDQoNClNlY3Rpb24gNS4z IFNheXM6DQoNCiBUaGUgQ29tcG91bmQgTUFDIGNvbXB1dGF0aW9uIGlzIGFzIGZvbGxvd3M6DQoN CiAgICAgIENNSyA9IENNS1tqXQ0KICAgICAgQ29tcG91bmQtTUFDID0gTUFDKCBDTUssIEJVRkZF UiApDQoNCiAgIHdoZXJlIGogaXMgdGhlIG51bWJlciBvZiB0aGUgbGFzdCBzdWNjZXNzZnVsbHkg ZXhlY3V0ZWQgaW5uZXIgRUFQDQogICBtZXRob2QsIE1BQyBpcyB0aGUgTUFDIGZ1bmN0aW9uIG5l Z290aWF0ZWQgaW4gVExTIDEuMiBbUkZDNTI0Nl0sIGFuZA0KICAgQlVGRkVSIGlzIGNyZWF0ZWQg YWZ0ZXIgY29uY2F0ZW5hdGluZyB0aGVzZSBmaWVsZHMgaW4gdGhlIGZvbGxvd2luZw0KICAgb3Jk ZXI6DQoNCiAgIDEgIFRoZSBlbnRpcmUgQ3J5cHRvLUJpbmRpbmcgVExWIGF0dHJpYnV0ZSB3aXRo IGJvdGggdGhlIEVNU0sgYW5kIE1TSw0KICAgICAgQ29tcG91bmQgTUFDIGZpZWxkcyB6ZXJvZWQg b3V0Lg0KDQogICAyICBUaGUgRUFQIFR5cGUgc2VudCBieSB0aGUgb3RoZXIgcGFydHkgaW4gdGhl IGZpcnN0IFRFQVAgbWVzc2FnZS4NCg0KSXQgU2hvdWxkIHNheToNCg0KIFRoZSBDb21wb3VuZCBN QUMgY29tcHV0YXRpb24gaXMgYXMgZm9sbG93czoNCg0KICAgICAgQ01LID0gQ01LW2pdDQogICAg ICBDb21wb3VuZC1NQUMgPSBNQUMoIENNSywgQlVGRkVSICkNCg0KICAgd2hlcmUgaiBpcyB0aGUg bnVtYmVyIG9mIHRoZSBsYXN0IHN1Y2Nlc3NmdWxseSBleGVjdXRlZCBpbm5lciBFQVANCiAgIG1l dGhvZCwgTUFDIGlzIEhNQUMgW1JGQzIxMDRdIHVzaW5nIHRoZSBoYXNoIGZ1bmN0aW9uIG5lZ290 aWF0ZWQgaW4NCiAgIFRMUyBbUkZDNTI0Nl0uICBUaGUgb3V0cHV0IGxlbmd0aCBpcyB0aGUgbGVu Z3RoIG9mIHRoZSBvdXRwdXQgb2YgdGhlIEhNQUMNCiAgIGZ1bmN0aW9uLiAgVGhlIEJVRkZFUiBp cyBjcmVhdGVkIGFmdGVyIGNvbmNhdGVuYXRpbmcgdGhlc2UgZmllbGRzIGluDQogICB0aGUgZm9s bG93aW5nIG9yZGVyOg0KDQogICAxICBUaGUgZW50aXJlIENyeXB0by1CaW5kaW5nIFRMViBhdHRy aWJ1dGUgd2l0aCBib3RoIHRoZSBFTVNLIGFuZCBNU0sNCiAgICAgIENvbXBvdW5kIE1BQyBmaWVs ZHMgemVyb2VkIG91dC4NCg0KICAgMiAgVGhlIEVBUCBUeXBlIHNlbnQgYnkgdGhlIG90aGVyIHBh cnR5IGluIHRoZSBmaXJzdCBURUFQIG1lc3NhZ2UuIFRoaXMNCiAgICAgICBpcyBhIHNpbmdsZSBv Y3RldCBlbmNvZGVkIGFzICgweDM3KQ0KDQpOb3RlczoNCg0KVGhpcyBjb3JyZWN0cyB0aGUgcHJv YmxlbSB0aGF0IHRoZSBNQUMgb3V0cHV0IHdpbGwgdmFyeSBkZXBlbmRpbmcgdXBvbiB0aGUgVExT IGhhc2ggZnVuY3Rpb24uIEl0IGNsYXJpZmllcyB0aGF0IEhNQUMgaXMgdXNlZCB3aXRoIHRoZSBo YXNoIGZ1bmN0aW9uIG5lZ290aWF0ZWQgaW4gVExTLiAgIEl0IGFsc28gY2xhcmlmaWVzIHRoYXQg dGhlICBFQVAgVHlwZSB1c2VkIGluIHRoZSBUTFMgbWVzc2FnZSBpcyB0aGUgVEVBUCBFQVAgdHlw ZSBlbmNvZGVkIGFzIGEgc2luZ2xlIGJ5dGUuDQo= --_000_MW2PR2101MB092324163BC435330C8904CDD1CB1MW2PR2101MB0923_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3Jh cDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGlzIGNoYW5nZSBsb29rcyBnb29kIHRvIG1lLiBXb3VsZCBhcHByZWNpYXRlIGEg c2FuaXR5IGNoZWNrIG9mIGFub3RoZXIgaW1wbGVtZW50YXRpb24gYnkgT2xlZyB0byBtYWtlIHN1 cmUgSSBoYXZlIG15IGZhY3RzIHN0cmFpZ2h0IGhlcmUuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBKb3NlcGggU2Fsb3dleSAm bHQ7am9lQHNhbG93ZXkubmV0Jmd0OyA8YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBOb3ZlbWJl ciAyMiwgMjAyMCA5OjI0IFBNPGJyPg0KPGI+VG86PC9iPiBKb3JnZSBWZXJnYXJhICZsdDtqb3Zl cmdhckBtaWNyb3NvZnQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gT2xlZyBQZWthciAmbHQ7b2xl Zy5wZWthci4yMDE3QGdtYWlsLmNvbSZndDs7IEVNVSBXRyAmbHQ7ZW11QGlldGYub3JnJmd0Ozsg Sm91bmkgTWFsaW5lbiAmbHQ7akB3MS5maSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFBy b3Bvc2VkIFJlc29sdXRpb24gZm9yIFRFQVAgZXJyYXRhIDU3Njg8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBOb3YgMTksIDIwMjAgYXQgODo1MyBQTSBK b3JnZSBWZXJnYXJhICZsdDs8YSBocmVmPSJtYWlsdG86am92ZXJnYXJAbWljcm9zb2Z0LmNvbSI+ am92ZXJnYXJAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNv cnJ5IGZvciB0aGUgbGFzdCBtaW51dGUgY29tbWVudCBvbiB0aGlzIG9uZSBiZWZvcmUgdGhlIG1l ZXRpbmcuIEkgd291bGQgbGlrZSB0byBtYXJrIHRoaXMgYXMgYSDigJxkaXNjdXNz4oCdIC0gSSBo YXZlIHNvbWUgY29tcGF0IGNvbmNlcm4gYWJvdXQgbWFraW5nIHRoZSBUTFYgbGVuZ3RoIHZhcmlh YmxlLiBDdXJyZW50DQogaW1wbGVtZW50YXRpb25zIHRydW5jYXRlIHRoZSBNQUMgZmllbGQgYXQg MjAgb2N0ZXRzLiBBbHRob3VnaCBJIGFncmVlIGluIHNwaXJpdCB3aXRoIHRoZSBkaXJlY3Rpb24g b2YgdGhpcyBjaGFuZ2UsIEkgdGhpbmsgaXQgd291bGQgcmVxdWlyZSBjaGFuZ2luZyB0aGUgdmVy c2lvbiBvZiB0aGUgQ3J5cHRvLUJpbmRpbmcgVExWLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+SSByZWNvZ25pemUgdGhhdCBtb3N0IHByb2JhYmx5IHdvbuKAmXQgaGF2ZSB0aW1lIHRvIHJl dmlldyB0aGlzIGNvbmNlcm4gYmVmb3JlIHRoZSBtZWV0aW5nIGFuZCBzbyB0aGUgZGlzY3Vzc2lv biBtYXkgbm90IGJlIGFibGUgdG8gb2NjdXIgdGhlcmUuIEFwb2xvZ2llcyBhZ2FpbiBhcyBJIG9u bHkgcmVhbGl6ZWQNCiB0aGlzIGNvbmNlcm4gYXMgSSB3YXMgZ2l2aW5nIGV2ZXJ5dGhpbmcgYSBm aW5hbCBwYXNzLW92ZXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltKb2VdIFRoYW5rcyBmb3IgY2F0Y2hpbmcgdGhpcy4m bmJzcDsgSWYgdGhpcyBpcyB0aGUgY2FzZSB0aGVuIHdlIHNob3VsZCBoYXZlIHRoZSBlcnJhdGEg cmVzb2x1dGlvbiByZWZsZWN0IHdoYXQgaW1wbGVtZW50YXRpb25zIGRvIGFuZCBsZWF2ZSB0aGUg cmVzdCBvZiB0aGUgY2hhbmdlIGZvciBhIGRvY3VtZW50IHVwZGF0ZS4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIHRoaXMgSSBz dWdnZXN0IHRoYXQgd2UgbGVhdmUgc2VjdGlvbiZuYnNwOzQuMi4xMyB1bmNoYW5nZWQmbmJzcDth bmQgbWFrZSBjaGFuZ2VzIHRvIDUuMy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U2VjdGlvbiA1LjMgU2F5czo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7VGhlIENvbXBv dW5kIE1BQyBjb21wdXRhdGlvbiBpcyBhcyBmb2xsb3dzOjxicj4NCjxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7IENNSyA9IENNS1tqXTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IENvbXBvdW5k LU1BQyA9IE1BQyggQ01LLCBCVUZGRVIgKTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDt3aGVyZSBq IGlzIHRoZSBudW1iZXIgb2YgdGhlIGxhc3Qgc3VjY2Vzc2Z1bGx5IGV4ZWN1dGVkIGlubmVyIEVB UDxicj4NCiZuYnNwOyAmbmJzcDttZXRob2QsIE1BQyBpcyB0aGUgTUFDIGZ1bmN0aW9uIG5lZ290 aWF0ZWQgaW4gVExTIDEuMiBbUkZDNTI0Nl0sIGFuZDxicj4NCiZuYnNwOyAmbmJzcDtCVUZGRVIg aXMgY3JlYXRlZCBhZnRlciBjb25jYXRlbmF0aW5nIHRoZXNlIGZpZWxkcyBpbiB0aGUgZm9sbG93 aW5nPGJyPg0KJm5ic3A7ICZuYnNwO29yZGVyOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsxICZu YnNwO1RoZSBlbnRpcmUgQ3J5cHRvLUJpbmRpbmcgVExWIGF0dHJpYnV0ZSB3aXRoIGJvdGggdGhl IEVNU0sgYW5kIE1TSzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IENvbXBvdW5kIE1BQyBmaWVs ZHMgemVyb2VkIG91dC48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7MiAmbmJzcDtUaGUgRUFQIFR5 cGUgc2VudCBieSB0aGUgb3RoZXIgcGFydHkgaW4gdGhlIGZpcnN0IFRFQVAgbWVzc2FnZS48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCBTaG91bGQg c2F5OiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7VGhlIENvbXBvdW5kIE1BQyBjb21wdXRhdGlvbiBpcyBhcyBmb2xs b3dzOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IENNSyA9IENNS1tqXTxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7IENvbXBvdW5kLU1BQyA9IE1BQyggQ01LLCBCVUZGRVIgKTxicj4N Cjxicj4NCiZuYnNwOyAmbmJzcDt3aGVyZSBqIGlzIHRoZSBudW1iZXIgb2YgdGhlIGxhc3Qgc3Vj Y2Vzc2Z1bGx5IGV4ZWN1dGVkIGlubmVyIEVBUDxicj4NCiZuYnNwOyAmbmJzcDttZXRob2QsIE1B QyBpcyBITUFDIFtSRkMyMTA0XSB1c2luZyB0aGUgaGFzaCBmdW5jdGlvbiBuZWdvdGlhdGVkIGlu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOyAmbmJzcDtUTFMgW1JGQzUyNDZdLiZuYnNwOyBJZiB0aGUgb3V0cHV0IG9mIHRoZSBITUFD IGlzIGdyZWF0ZXIgdGhhbiAyMCBieXRlcyB0aGVuJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDtpdCBpcyB0cnVuY2F0ZWQgdG8gMjAgYnl0 ZXMuJm5ic3A7IFRoZSBCVUZGRVIgaXMgY3JlYXRlZCBhZnRlciBjb25jYXRlbmF0aW5nJm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDt0aGVz ZSBmaWVsZHMgaW4gdGhlIGZvbGxvd2luZyBvcmRlcjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KJm5ic3A7ICZuYnNwOzEgJm5ic3A7 VGhlIGVudGlyZSBDcnlwdG8tQmluZGluZyBUTFYgYXR0cmlidXRlIHdpdGggYm90aCB0aGUgRU1T SyBhbmQgTVNLPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgQ29tcG91bmQgTUFDIGZpZWxkcyB6 ZXJvZWQgb3V0Ljxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsyICZuYnNwO1RoZSBFQVAgVHlwZSBz ZW50IGJ5IHRoZSBvdGhlciBwYXJ0eSBpbiB0aGUgZmlyc3QgVEVBUCBtZXNzYWdlLiBUaGlzPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2lzIGEgc2luZ2xlIG9jdGV0IGVuY29kZWQgYXMgKDB4Mzcp PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkpvcmdlIFZlcmdhcmE8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206PC9iPiBPbGVn IFBla2FyICZsdDs8YSBocmVmPSJtYWlsdG86b2xlZy5wZWthci4yMDE3QGdtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPm9sZWcucGVrYXIuMjAxN0BnbWFpbC5jb208L2E+Jmd0Ow0KPGJyPg0KPGI+ U2VudDo8L2I+IFNhdHVyZGF5LCBPY3RvYmVyIDI0LCAyMDIwIDQ6MzAgUE08YnI+DQo8Yj5Ubzo8 L2I+IEpvc2VwaCBTYWxvd2V5ICZsdDs8YSBocmVmPSJtYWlsdG86am9lQHNhbG93ZXkubmV0IiB0 YXJnZXQ9Il9ibGFuayI+am9lQHNhbG93ZXkubmV0PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IEVN VSBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVtdUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmVt dUBpZXRmLm9yZzwvYT4mZ3Q7OyBKb3VuaSBNYWxpbmVuICZsdDs8YSBocmVmPSJtYWlsdG86akB3 MS5maSIgdGFyZ2V0PSJfYmxhbmsiPmpAdzEuZmk8L2E+Jmd0OzsgSm9yZ2UgVmVyZ2FyYSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmpvdmVyZ2FyQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5q b3ZlcmdhckBtaWNyb3NvZnQuY29tPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFBy b3Bvc2VkIFJlc29sdXRpb24gZm9yIFRFQVAgZXJyYXRhIDU3Njg8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZndDsgMiAmbmJzcDtUaGUgRUFQIFR5cGUgc2VudCBi eSB0aGUgb3RoZXIgcGFydHkgaW4gdGhlIGZpcnN0IFRFQVAgbWVzc2FnZS4gVGhpcyBpcyBhIHNp bmdsZSBvY3RldCBlbmNvZGVkIGFzICgweDM3KTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPlNob3VsZG4ndCB3ZSBjbGFyaWZ5IHRoZSBtb3RpdmF0aW9u IGZvciBwbGFjaW5nIHRoZSBvY3RldCB3aXRoIFRFQVAgdHlwZSAweDM3IGludG8gdGhlIEJVRkZF Uj8gSm9lLCBJIHJlbWVtYmVyIHlvdSBleHBsYWluZWQgdGhhdCBpdCBpcyBmb3IgcHJvdGVjdGlv biBhZ2FpbnN0IGNyb3NzIHByb3RvY29sIGF0dGFja3MNCiBpZiBDcnlwdG8tQmluZGluZyBUTFYg d2FzIHJldXNlZCAoZS5nLiBmcm9tIFBFQVApLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gU3VuLCBPY3QgMjUsIDIwMjAgYXQgMTI6 NDUgQU0gSm9zZXBoIFNhbG93ZXkgJmx0OzxhIGhyZWY9Im1haWx0bzpqb2VAc2Fsb3dleS5uZXQi IHRhcmdldD0iX2JsYW5rIj5qb2VAc2Fsb3dleS5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5FcnJhdGEgNTc2ODombmJzcDsm bmJzcDs8YSBocmVmPSJodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Y29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cucmZjLWVkaXRvci5vcmclMkZlcnJhdGElMkZlaWQ1 NzY4JmFtcDtkYXRhPTA0JTdDMDElN0Nqb3ZlcmdhciU0MG1pY3Jvc29mdC5jb20lN0M3MDExMTQy ZDI2ODY0MDQ5ZGIxODA4ZDg4ZjZmZmU1YyU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFk YjQ3JTdDMSU3QzAlN0M2Mzc0MTcwNTg0NTg2NTI0NTQlN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4 ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhW Q0k2TW4wJTNEJTdDMTAwMCZhbXA7c2RhdGE9SjJIa1NUMGZFVFAlMkZ1NUNKNzg5SW5SRkZpSTlP dFgxYXd1S1VoaERmQlNRJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cucmZjLWVkaXRvci5vcmcvZXJyYXRhL2VpZDU3Njg8L2E+PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Qcm9wb3NlZCBTdGF0ZTogVmVyaWZpZWQ8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UmV2aXNp b246PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5TZWN0aW9uIDQuMi4xMy4gU2F5czo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkxlbmd0aCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyA3 NjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+SXQgc2hvdWxkIHNheTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkxlbmd0aDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyAmbmJzcDszNiBw bHVzIHRoZSBsZW5ndGggb2YgdGhlIDIgTUFDIGZpZWxkczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U2VjdGlvbiA0LjIuMTMuIFNheXM6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KJm5i c3A7ICZuYnNwO0VNU0sgQ29tcG91bmQgTUFDPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgVGhlIEVNU0sgQ29tcG91bmQgTUFDIGZpZWxkIGlzIDIwIG9jdGV0cy4mbmJzcDsgVGhpcyBj YW4gYmUgdGhlIFNlcnZlcjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IE1BQyAoQjFfTUFDKSBv ciB0aGUgQ2xpZW50IE1BQyAoQjJfTUFDKS4mbmJzcDsgVGhlIGNvbXB1dGF0aW9uIG9mIHRoZTxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IE1BQyBpcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA1LjMu PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO01TSyBDb21wb3VuZCBNQUM8YnI+DQo8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyBUaGUgTVNLIENvbXBvdW5kIE1BQyBmaWVsZCBpcyAyMCBvY3RldHMu Jm5ic3A7IFRoaXMgY2FuIGJlIHRoZSBTZXJ2ZXI8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBN QUMgKEIxX01BQykgb3IgdGhlIENsaWVudCBNQUMgKEIyX01BQykuJm5ic3A7IFRoZSBjb21wdXRh dGlvbiBvZiB0aGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBNQUMgaXMgZGVzY3JpYmVkIGlu IFNlY3Rpb24gNS4zLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPkl0IFNob3VsZCBTYXk6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7RU1TSyBDb21wb3VuZCBNQUM8YnI+ DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBUaGUgY29tcHV0YXRpb24gb2YgdGhlIE1BQyBp cyBkZXNjcmliZWQgaW4gU2VjdGlvbiA1LjMuJm5ic3A7IFRoaXMgY2FuIGJlJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAm bmJzcDsgJm5ic3A7IHRoZSBTZXJ2ZXIgTUFDIChCMV9NQUMpIG9yIHRoZSBDbGllbnQgTUFDIChC Ml9NQUMpLiAmbmJzcDs8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7TVNLIENvbXBvdW5kIE1BQzxi cj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IFRoZSBjb21wdXRhdGlvbiBvZiB0aGUgTUFD IGlzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDUuMy4mbmJzcDsgVGhpcyBjYW4gYmUmbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgdGhlIFNlcnZlciBNQUMgKEIxX01BQykgb3IgdGhlIENsaWVudCBNQUMg KEIyX01BQykuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+U2VjdGlvbiA1LjMgU2F5czo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7VGhlIENvbXBvdW5kIE1BQyBjb21w dXRhdGlvbiBpcyBhcyBmb2xsb3dzOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IENN SyA9IENNS1tqXTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IENvbXBvdW5kLU1BQyA9IE1BQygg Q01LLCBCVUZGRVIgKTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDt3aGVyZSBqIGlzIHRoZSBudW1i ZXIgb2YgdGhlIGxhc3Qgc3VjY2Vzc2Z1bGx5IGV4ZWN1dGVkIGlubmVyIEVBUDxicj4NCiZuYnNw OyAmbmJzcDttZXRob2QsIE1BQyBpcyB0aGUgTUFDIGZ1bmN0aW9uIG5lZ290aWF0ZWQgaW4gVExT IDEuMiBbUkZDNTI0Nl0sIGFuZDxicj4NCiZuYnNwOyAmbmJzcDtCVUZGRVIgaXMgY3JlYXRlZCBh ZnRlciBjb25jYXRlbmF0aW5nIHRoZXNlIGZpZWxkcyBpbiB0aGUgZm9sbG93aW5nPGJyPg0KJm5i c3A7ICZuYnNwO29yZGVyOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsxICZuYnNwO1RoZSBlbnRp cmUgQ3J5cHRvLUJpbmRpbmcgVExWIGF0dHJpYnV0ZSB3aXRoIGJvdGggdGhlIEVNU0sgYW5kIE1T Szxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IENvbXBvdW5kIE1BQyBmaWVsZHMgemVyb2VkIG91 dC48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7MiAmbmJzcDtUaGUgRUFQIFR5cGUgc2VudCBieSB0 aGUgb3RoZXIgcGFydHkgaW4gdGhlIGZpcnN0IFRFQVAgbWVzc2FnZS48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCBTaG91bGQgc2F5OiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7VGhlIENvbXBvdW5kIE1BQyBjb21wdXRhdGlvbiBpcyBhcyBmb2xsb3dzOjxicj4NCjxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IENNSyA9IENNS1tqXTxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7IENvbXBvdW5kLU1BQyA9IE1BQyggQ01LLCBCVUZGRVIgKTxicj4NCjxicj4NCiZuYnNw OyAmbmJzcDt3aGVyZSBqIGlzIHRoZSBudW1iZXIgb2YgdGhlIGxhc3Qgc3VjY2Vzc2Z1bGx5IGV4 ZWN1dGVkIGlubmVyIEVBUDxicj4NCiZuYnNwOyAmbmJzcDttZXRob2QsIE1BQyBpcyBITUFDIFtS RkMyMTA0XSB1c2luZyB0aGUgaGFzaCBmdW5jdGlvbiBuZWdvdGlhdGVkIGluPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDtU TFMgW1JGQzUyNDZdLiZuYnNwOyBUaGUgb3V0cHV0IGxlbmd0aCBpcyB0aGUgbGVuZ3RoIG9mIHRo ZSBvdXRwdXQgb2YgdGhlIEhNQUM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwO2Z1bmN0aW9uLiZuYnNwOyBUaGUgQlVGRkVS IGlzIGNyZWF0ZWQgYWZ0ZXIgY29uY2F0ZW5hdGluZyB0aGVzZSBmaWVsZHMgaW4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 ICZuYnNwO3RoZSBmb2xsb3dpbmcgb3JkZXI6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCiZuYnNwOyAmbmJzcDsxICZuYnNwO1RoZSBl bnRpcmUgQ3J5cHRvLUJpbmRpbmcgVExWIGF0dHJpYnV0ZSB3aXRoIGJvdGggdGhlIEVNU0sgYW5k IE1TSzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IENvbXBvdW5kIE1BQyBmaWVsZHMgemVyb2Vk IG91dC48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7MiAmbmJzcDtUaGUgRUFQIFR5cGUgc2VudCBi eSB0aGUgb3RoZXIgcGFydHkgaW4gdGhlIGZpcnN0IFRFQVAgbWVzc2FnZS4gVGhpczxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtpcyBhIHNpbmdsZSBvY3RldCBlbmNvZGVkIGFzICgweDM3KTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Tm90 ZXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5UaGlzIGNvcnJlY3RzIHRoZSBwcm9ibGVtIHRoYXQgdGhlIE1BQyBvdXRwdXQgd2lsbCB2 YXJ5IGRlcGVuZGluZyB1cG9uIHRoZSBUTFMgaGFzaCBmdW5jdGlvbi4gSXQgY2xhcmlmaWVzIHRo YXQgSE1BQyBpcyB1c2VkIHdpdGggdGhlIGhhc2ggZnVuY3Rpb24gbmVnb3RpYXRlZCBpbiBUTFMu Jm5ic3A7ICZuYnNwO0l0IGFsc28NCiBjbGFyaWZpZXMgdGhhdCB0aGUmbmJzcDsgRUFQIFR5cGUg dXNlZCBpbiB0aGUgVExTIG1lc3NhZ2UgaXMgdGhlIFRFQVAgRUFQIHR5cGUgZW5jb2RlZCBhcyBh IHNpbmdsZSBieXRlLiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_MW2PR2101MB092324163BC435330C8904CDD1CB1MW2PR2101MB0923_-- From nobody Fri Dec 11 09:41:44 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@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: [Emu] [core] [Ace] Proposed charter for ACE (EAP over CoAP?) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" 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:40 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@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: [Emu] [core] [Ace] Proposed charter for ACE (EAP over CoAP?) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" 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:12 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@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: [Emu] [core] [Ace] Proposed charter for ACE (EAP over CoAP?) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" 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 Sun Dec 13 12:07:12 2020 Return-Path: X-Original-To: emu@ietf.org Delivered-To: emu@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D99173A0811; Sun, 13 Dec 2020 12:07:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: emu@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: emu@ietf.org Message-ID: <160789003075.4694.1368207879400208967@ietfa.amsl.com> Date: Sun, 13 Dec 2020 12:07:10 -0800 Archived-At: Subject: [Emu] I-D Action: draft-ietf-emu-eap-noob-03.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2020 20:07:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the EAP Method Update WG of the IETF. Title : Nimble out-of-band authentication for EAP (EAP-NOOB) Authors : Tuomas Aura Mohit Sethi Aleksi Peltonen Filename : draft-ietf-emu-eap-noob-03.txt Pages : 67 Date : 2020-12-13 Abstract: The Extensible Authentication Protocol (EAP) provides support for multiple authentication methods. This document defines the EAP-NOOB authentication method for nimble out-of-band (OOB) authentication and key derivation. The EAP method is intended for bootstrapping all kinds of Internet-of-Things (IoT) devices that have no pre-configured authentication credentials. The method makes use of a user-assisted one-directional OOB message between the peer device and authentication server to authenticate the in-band key exchange. The device must have an input or output interface, such as a display, microphone, speaker or blinking light, which can send or receive dynamically generated messages of tens of bytes in length. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-emu-eap-noob-03 https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-noob-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-noob-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 Sun Dec 13 12:10:53 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1193A0829 for ; Sun, 13 Dec 2020 12:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aalto.fi 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 P_EdR-Yu2M7u for ; Sun, 13 Dec 2020 12:10:50 -0800 (PST) Received: from smtp-out-01.aalto.fi (smtp-out-01.aalto.fi [130.233.228.120]) (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 DEA993A0827 for ; Sun, 13 Dec 2020 12:10:49 -0800 (PST) Received: from smtp-out-01.aalto.fi (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 5578111572B_FD67547B; Sun, 13 Dec 2020 20:10:47 +0000 (GMT) Received: from exng4.org.aalto.fi (exng4.org.aalto.fi [130.233.223.23]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client CN "exng4.org.aalto.fi", Issuer "RootCA3" (not verified)) by smtp-out-01.aalto.fi (Sophos Email Appliance) with ESMTPS id 12ABA11571B_FD67547F; Sun, 13 Dec 2020 20:10:47 +0000 (GMT) Received: from exng6.org.aalto.fi (130.233.223.25) by exng4.org.aalto.fi (130.233.223.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2106.2; Sun, 13 Dec 2020 22:10:46 +0200 Received: from exng6.org.aalto.fi ([fe80::3dc2:a1e7:902b:1296]) by exng6.org.aalto.fi ([fe80::3dc2:a1e7:902b:1296%17]) with mapi id 15.01.2106.004; Sun, 13 Dec 2020 22:10:46 +0200 From: Aura Tuomas To: Alan DeKok CC: EMU WG Thread-Topic: [Emu] Working Group Last Call for draft-ietf-emu-eap-noob-02 Thread-Index: AQHWyXd3/c3pVZtm+UG3TsvK/WbeBan1PiRQ Date: Sun, 13 Dec 2020 20:10:46 +0000 Message-ID: <10ba6209f1534bcda41972abeae7801a@aalto.fi> References: <21469_1607001817_5FC8E6D8_21469_84_1_BB9A941D-112B-46D9-BD35-075DB7DD4FFF@deployingradius.com> In-Reply-To: <21469_1607001817_5FC8E6D8_21469_84_1_BB9A941D-112B-46D9-BD35-075DB7DD4FFF@deployingradius.com> Accept-Language: en-US, fi-FI Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.233.0.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SASI-RCODE: 200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aalto.fi; h=from:to:cc:subject:date:message-id:references:in-reply-to:content-type:content-transfer-encoding:mime-version; s=its18; bh=wjiY6w4q5ZCuPn4bKDX6OV5WpuyIPkCQ46Q/mRluMrE=; b=rqEEO4QNpCLgGo03rYN/5v9zYXyLJWJVMgNmsvgKz8WQq1yIYtcWrHYThuaC4Im6EH5w5/EMrHCynWmq0hQ+zXZCdRfGz6ixSztCP3e64fZ0eq8dIxWi2iC0pXLvyshUyFQ9HjtLiYA/TWIhRwd/b8ZLy7x86aycEA0+r9f5ONORZsvOatv4lf/E4X7e3fa/TwPdyoAb+bA0PcxsSUmDXmuFsPmXQ9ZWXLKaCOq4qvqUYpkJamHbdTJJ5Ug/60sPrDAV7e994Chq++nod/s0kf89NfJzgAx4DLciPyTrUOiHWTM/FPw6no4/naRH6cDbAu5eNAObv2hEr2OYApJUFQ== Archived-At: Subject: Re: [Emu] Working Group Last Call for draft-ietf-emu-eap-noob-02 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2020 20:10:52 -0000 Alan, thank you for your review! We had not thought about the collisions of uft8-username within the realm. = After some discussion, the best solution seemst to be to let the server ass= ign a full NAI instead of just the Realm. This is the only significant chan= ge made to the new draft 3.=20 Tuomas -----Original Message----- From: Emu On Behalf Of Alan DeKok Sent: torstai 3. joulukuuta 2020 15:23 To: Joseph Salowey Cc: EMU WG Subject: Re: [Emu] Working Group Last Call for draft-ietf-emu-eap-noob-02 Importance: High > On Nov 21, 2020, at 6:31 PM, Joseph Salowey wrote: >=20 > At IETF 109 meeting there was support for moving EAP-NOOB forward. The = chairs and authors believe the document is ready to progress so this starts= the working group last call for EAP-NOOB [1]. Please review the document= and send comments to the list by December 11, 2020. Statements of support= or opposition are welcome especially if accompanied with reasons for the p= osition. =20 I support publication of this document. NITs: Section 3.3.1 says "The default realm for the peer is "eap-noob.arpa". But the diagram in 3.2.1 has: (NAI=3Dnoob@eap-noob.net) I suggest using "arpa" instead of "net". Section 3.3.1 says "The peer MUST copy the PeerId byte-by- byte from the message where it was allocated, and the server MUST perform a byte-by-byte comparison" It's a little odd to talk about "byte-by-byte". Perhaps just "copy the P= eerID", and "the server must verify that the PeerID exactly matches ..." =20 Section 3.3.1 also discusses a "server-assigned realm". But there seems = to be no guidance on which realm to use. Since this specification also man= dates the use of a particular utf8-username "noob", there is a potential co= nflict with existing users. It may be useful to suggest the use of a sub-realm, specifically used for= EAP-NOOB, e.g. "noob.example.net". Allowing a sub-realm for noob means th= at administrators can select an otherwise unused realm, and assign it speci= fically for use with EAP-NOOB. That can cause issues with roaming, however. Roaming systems match on re= alms, and may not always be capable of matching on variants of realms. So = if they allow "example.net", they may not be capable of processing "noob.ex= ample.net". RFC 7542 Section 3 "Routing inside of AAA Systems" is silent = on this topic, while Eduroam allows sub-realms. My suggestion is that the document should recommend the use of noob-speci= fic sub-realms, and then admit that this might cause issues in some roaming= environments. That trade-off is acceptable, I think. Most roaming system= s which cannot handle sub-realms will likely not be using EAP-NOOB. Appendix E says: PeerId is provided to the peer by the server and might be a 22-character ASCII string.=20 I think it's best to just refer to Section 3.3.1, for the format of the P= eerId. And then note that the construction in Section 3.3.1 is compatible = with HTTP, and does not require escaping. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From nobody Sun Dec 13 14:20:05 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCE43A0B32 for ; Sun, 13 Dec 2020 14:20:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwt1Lri1deyh for ; Sun, 13 Dec 2020 14:20:01 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 594EB3A0B05 for ; Sun, 13 Dec 2020 14:20:00 -0800 (PST) Received: from [192.168.46.129] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id D40A31584; Sun, 13 Dec 2020 22:19:58 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Alan DeKok In-Reply-To: <10ba6209f1534bcda41972abeae7801a@aalto.fi> Date: Sun, 13 Dec 2020 17:19:56 -0500 Cc: EMU WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <21469_1607001817_5FC8E6D8_21469_84_1_BB9A941D-112B-46D9-BD35-075DB7DD4FFF@deployingradius.com> <10ba6209f1534bcda41972abeae7801a@aalto.fi> To: Aura Tuomas X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Emu] Working Group Last Call for draft-ietf-emu-eap-noob-02 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2020 22:20:03 -0000 On Dec 13, 2020, at 3:10 PM, Aura Tuomas wrote: > We had not thought about the collisions of uft8-username within the = realm. After some discussion, the best solution seemst to be to let the = server assign a full NAI instead of just the Realm. This is the only = significant change made to the new draft 3.=20 That's a better approach, thanks. Alan DeKok. From nobody Tue Dec 15 21:57:05 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3B13A0FBB for ; Tue, 15 Dec 2020 21:53:39 -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_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 3mi9cT6Qjntv for ; Tue, 15 Dec 2020 21:53:37 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 711BD3A0FB9 for ; Tue, 15 Dec 2020 21:53:35 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 2B6D2F40749; Tue, 15 Dec 2020 21:53:29 -0800 (PST) To: dansimon@microsoft.com, bernarda@microsoft.com, rmh@microsoft.com, rdd@cert.org, kaduk@mit.edu, joe@salowey.net, mohit.m.sethi@ericsson.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Cc: kaduk@mit.edu, emu@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20201216055329.2B6D2F40749@rfc-editor.org> Date: Tue, 15 Dec 2020 21:53:29 -0800 (PST) Archived-At: X-Mailman-Approved-At: Tue, 15 Dec 2020 21:57:04 -0800 Subject: [Emu] [Editorial Errata Reported] RFC5216 (6357) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2020 05:53:39 -0000 The following errata report has been submitted for RFC5216, "The EAP-TLS Authentication Protocol". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6357 -------------------------------------- Type: Editorial Reported by: Benjamin Kaduk Section: 5.1 Original Text ------------- [3] Section 5 of BCP 86 [RFC3766] offers advice on the required RSA or Diffie-Hellman (DH) module and Digital Signature Algorithm (DSA) subgroup size in bits, for a given level of attack resistance in bits. For example, a 2048-bit RSA key is recommended to provide 128-bit equivalent key strength. The National Institute of Standards and Technology (NIST) also offers advice on appropriate key sizes in [SP800-57]. Corrected Text -------------- [3] Section 5 of BCP 86 [RFC3766] offers advice on the required RSA or Diffie-Hellman (DH) modulus and Digital Signature Algorithm (DSA) subgroup size in bits, for a given level of attack resistance in bits. For example, a 2048-bit RSA key is recommended to provide 128-bit equivalent key strength. The National Institute of Standards and Technology (NIST) also offers advice on appropriate key sizes in [SP800-57]. Notes ----- RSA and DH computations are parameterized by their moduli, with singular "modulus" (not "module"). Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5216 (draft-simon-emu-rfc2716bis-13) -------------------------------------- Title : The EAP-TLS Authentication Protocol Publication Date : March 2008 Author(s) : D. Simon, B. Aboba, R. Hurst Category : PROPOSED STANDARD Source : EAP Method Update Area : Security Stream : IETF Verifying Party : IESG From nobody Wed Dec 16 03:19:05 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6E23A09A4; Wed, 16 Dec 2020 03:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 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, 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=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 WraveeACQeZK; Wed, 16 Dec 2020 03:19:01 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10050.outbound.protection.outlook.com [40.107.1.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64A9E3A0978; Wed, 16 Dec 2020 03:19:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NoA+qYCnbtaIz0Xt1BxcjG8XIJN80qml0FJr+Cv5A/OLHRJIV1F89/IYJkvmwj8Xq25vbwi79L9t4xSBkuBq/Hhq+yPLCMG0c3qBu7hy6Pd6r/caoi5A49+No9LJmLomcYSyoPumg6uKIEoR8himTLfw6cUXp9xnfnMv+CLMVOtcI4tHmatOTPzQJn5mw1gQYcV0zQeKcuoqqdjtR/FR8n6ww9ijkwN9hgE+bZYS0nV6zhxYmFbWWOfXIA2hrQ0hZHGTKOWie6NUxBo979ENH5y019rnSCT7E3QGBG92r4fKA4zk1MBKy7RwrsxuVdWnx4UhvP8TqzB3MXjJupCH2A== 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=CF1VWDVjeK09YzjNNH62NW8wA491wSRxpS0hLE7JOT8=; b=IE3ifPqiw9OjnL0qYfXgaAVghhMlq9vzW1BbyX9wu7djhfPng1PtciloQJ4nPuJZ2o6JCb0rn4NJdI6h2DMu0L1C2dwvmxZC+TVFNl5nkLodWPKe6578M6CS1bIuqOCF2zooxUlPM7w3AjYxM47mlJkyIVWZBjIae3y238dIsudS1jPdhHG7DtDOm+CRs2QhWK5bWezdWY83EiRJlWfab9hSDJ/192E4WI4jzM+0rupfBCu69JxiFCJaIjldGNWzx94BcBujcCUHaCthUH3LP88+xJNzDzkYyDc8cKh0KZX3bJUDhQ0U79/Xxz6gkoYoyWdUeMBNV5QhS4K11yCMUg== 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=CF1VWDVjeK09YzjNNH62NW8wA491wSRxpS0hLE7JOT8=; b=GDtB//U9XbQyouHcqOcAbJXn+deyo+ZHDbpBdc0Jm5Og9FSt/maIM21nLXTKq7U5gPMRuLpmnjNPjdzYQ9Xd2Nx8fIWFcyeUao7F4QxfpbkqnhhgnwuFMhU1mBPjHMUxg2HbsRJ6g6evTUWF8XFRRbo9jeIKkrvV5dq7D87QoF0= Received: from HE1PR0701MB2185.eurprd07.prod.outlook.com (2603:10a6:3:2a::21) by HE1PR0701MB2810.eurprd07.prod.outlook.com (2603:10a6:3:54::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3676.14; Wed, 16 Dec 2020 11:18:58 +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.3676.015; Wed, 16 Dec 2020 11:18:58 +0000 From: Mohit Sethi M To: =?utf-8?B?w4lyaWMgVnluY2tl?= , The IESG CC: "draft-ietf-emu-eap-tls13@ietf.org" , "emu-chairs@ietf.org" , "emu@ietf.org" Thread-Topic: =?utf-8?B?W0VtdV0gw4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWll?= =?utf-8?Q?tf-emu-eap-tls13-13:_(with_COMMENT)?= Thread-Index: AQHWzv6xivtj+kRwWkCehHrLxL5sI6n5nICA Date: Wed, 16 Dec 2020 11:18:58 +0000 Message-ID: <140da8b8-c4d3-bdb9-d653-2f56db43c21d@ericsson.com> References: <160760962730.29119.12837976351667725920@ietfa.amsl.com> In-Reply-To: <160760962730.29119.12837976351667725920@ietfa.amsl.com> 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: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:14bb:140:1588:9f56:4873:e007:482c] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 51f48c3f-1265-4d41-72d3-08d8a1b4624c x-ms-traffictypediagnostic: HE1PR0701MB2810: 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: pmeGegxKfr+tsM55ee14uTOSz7yggU9JySQKSMzVv3/TT8K//zhaRrwabPZY/2sn6RZ+VAQsTZi7PDxYQej+4lzUKAekCHqXyLFGL8w19kzIhi87DWSFWuQntlBPBZNN/eGr//SyQ0XlX97S1OMdmCKYM/hJNKkMFA5C3ymvnV1xnLfzVfw8rgHTeSX11/X9RUH5kvaLcmb3jM6qAKmHmmCFvLHlSuorcq8EEMSzywB45cTgGJaL7RTjkvA8w9RrEcuaZc5HtBBBooBPlpaL20y963gEiKaohFJwAuWx6Z00B+y19ujMuUmPJ6LBEN7cPZyiwNEZbB/671Q27mqoEUI63MLW6aTfMRoU9nzq03opzpvqfu2ozoLLue7u5JAw2moTNJX4BX4e1woUv2Qd8rODiZgxWcT/1xsRu5wijS1ZudDBflXA9YjO/N6lB9IUOBvF0NV0frdDy2dgee6zocqJevcJcW7anEX5FhFB8dyYA31zXRQVhjLV+90bNUSFpOu3JqjxAM3zxA8buETL1auUL5ywzAllffvaguRns4BIU2ZxEb74Fk2lq4OPmzq9 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)(376002)(136003)(39860400002)(366004)(396003)(346002)(66946007)(76116006)(86362001)(66556008)(110136005)(6512007)(31686004)(2616005)(31696002)(71200400001)(66476007)(6506007)(54906003)(53546011)(6486002)(4326008)(36756003)(5660300002)(478600001)(64756008)(83380400001)(966005)(186003)(224303003)(8936002)(66446008)(2906002)(316002)(66574015)(43740500002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?eDRJaEdFeVlIb0NMbEErU2YvWTFra1J2TGtEbXdKTEErajB3b3pBSVg1dnBw?= =?utf-8?B?SmEzS3duZ2JyVnpQT2dySDRMKzNBc3VXMURIQTJ3dnZHdkV3NlcwQkowazV2?= =?utf-8?B?WmRTdk5tTFNaTW1TamdFQ1pnODhvUFF2SVJtcmN6TDRLMGwwSHltdVFrK0t6?= =?utf-8?B?cVRzcGM2WTU2UVBpYjloa2pJaFl0bVBKa2RaREZZVnJrRmh6MU1odWh4TWtH?= =?utf-8?B?VnZ1SDBvWnBvSk9NRXMySzdmK1E4aEcyZUkyNTZqSnJ4VDFnci9YZ3JQNVNB?= =?utf-8?B?MS9FTGVxYkVucjJTbzZ0ay91ZkR0Z2c4NVJHRm1HR1NmQ29uZzQySWxnUGVI?= =?utf-8?B?ZmNobzZMYWdWODg1MGtTaCtGb3ZIcVUwMTM3M013OUlmbVFvMTlNWk50QjZY?= =?utf-8?B?dGFjYkVMZHVuT3NHTGpwdEQ4WDFOWFFzVHlkM1VrMFUwZFZ6NktQWjltd2l4?= =?utf-8?B?WmtWalpYYnpxU3lzNThvZmtabGsvckNQTENrM0JqeVBmOVRwQm96eEd0Q0RB?= =?utf-8?B?bDFtK1QrLzNtaFhFYUcrYVBpSVBha042aWlLTWRRYUk0MVJLZEFVZUJxMG56?= =?utf-8?B?N2tONGlPUlAzWHVZRW1nR2UxVUh4VWkrQnRYMVVFTHFFaEtXNlVNeWx6QU53?= =?utf-8?B?TU5tTmFPVTIvVUVLaisvOWptcW5HM0FQUkN6UHNoMjZOSnNsTk4zbnMzQmQ3?= =?utf-8?B?Vy9GMjFJY0VlLzF0cWxTTmdmQkxNS1hsZ2JXbHo1c1htRDJZaUNsb0JoZGp5?= =?utf-8?B?SE5KUkl5eDVCTGF2dVlUMkV4ZGovWmdZaVV0bFZBWktDcEZqZWJwekltUVlw?= =?utf-8?B?WmVSOEduYVNmdGVHR3lHT203eEJVd3B0WjllQTJvdTJNYUdaYXlpS2Q3NTdJ?= =?utf-8?B?aVNiZDQvWnNISG1JMkZOVUlvL1pMMXJISlR4S1NlY1Y4N3YvMWVTRHRGb29a?= =?utf-8?B?a3dhRVNVekczTFB6dXhnYVRPYkM5MHVUQ2l0dTNPVnA0Mkh0bkp0VFU1d2p6?= =?utf-8?B?ZXBFaERwc0JMZVM3SWc0TjFCcW5waDdkRnJPWDgrZEJ2R010dkJlaXJKNGsy?= =?utf-8?B?ZGF0NFVTMEJjc3UrUm9MMDZtMC8xRzhQTkZwdW1iRTQ4SzJGZlJKbTQ2Q1oz?= =?utf-8?B?MWtmOE9ZSmJJdkRUR2tEUS90amFmRjh5Mi9MdVREZVBzeXdhQWlzOVhFN1JU?= =?utf-8?B?Q2ZGclNXMDlnTk1jQXVTbFBJVmVqVi9tZnNzNSs5OUExT0FBbVFhd1FGWFU1?= =?utf-8?B?NUs5Y0tEd05nVGh1WWlNaVVGU1BobEVtSGZpOVBQUGFzYk5kNmorUVNIbGNy?= =?utf-8?B?MjJjeFo5KzJGQ25lV0tEdXJHcVc3Q2VhTFhNZitJMjFOa0F0RmJhblRaUFYv?= =?utf-8?Q?3ErKwT+1YHtkJvzKZ98hBI2Pd52mqGLQ=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB2185.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 51f48c3f-1265-4d41-72d3-08d8a1b4624c X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2020 11:18:58.6738 (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: eTsxMYcaVrRtC8Dy9Y4vmDl8PZdnrVTpdW0QCNN9YnuLF2QdMQ5yRiKGiIM5jRr7zwokpvNFrYBbnKEwsDr9VVpwSb5m4ARbYa6Cu1hinxo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2810 Archived-At: Subject: Re: [Emu] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf-?= =?utf-8?q?emu-eap-tls13-13=3A_=28with_COMMENT=29?= X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2020 11:19:04 -0000 SGkgw4lyaWMsDQoNClRoYW5rIHlvdSBmb3IgeW91ciByZXZpZXcuIEFuc3dlcnMgaW4tbGluZToN Cg0KT24gMTIvMTAvMjAgNDoxMyBQTSwgw4lyaWMgVnluY2tlIHZpYSBEYXRhdHJhY2tlciB3cm90 ZToNCj4gw4lyaWMgVnluY2tlIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0 aW9uIGZvcg0KPiBkcmFmdC1pZXRmLWVtdS1lYXAtdGxzMTMtMTM6IE5vIE9iamVjdGlvbg0KPg0K PiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFu ZCByZXBseSB0byBhbGwNCj4gZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQg Q0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMNCj4gaW50cm9kdWN0b3J5IHBhcmFncmFw aCwgaG93ZXZlci4pDQo+DQo+DQo+IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9y Zy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4gZm9yIG1vcmUgaW5mb3Jt YXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4NCj4NCj4g VGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBm b3VuZCBoZXJlOg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm LWVtdS1lYXAtdGxzMTMvDQo+DQo+DQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPg0KPiBUaGFuayB5b3UgZm9yIHRoZSB3b3JrIHB1dCBpbnRvIHRoaXMg ZG9jdW1lbnQuIEltcHJvdmluZyBFQVAtVExTIGlzIGluZGVlZA0KPiB3ZWxjb21lISBCVFcsIEkg bGVmdCB0aGUgc2VjdXJpdHkgcmV2aWV3IHRvIHRoZSBTRUMgQXJlYSBEaXJlY3RvcnMuDQo+DQo+ IFBsZWFzZSBmaW5kIGJlbG93IHNvbWUgbm9uLWJsb2NraW5nIENPTU1FTlQgcG9pbnRzIChidXQg cmVwbGllcyB3b3VsZCBiZQ0KPiBhcHByZWNpYXRlZCksIGFuZCBzb21lIG5pdHMuDQo+DQo+IEkg aG9wZSB0aGF0IHRoaXMgaGVscHMgdG8gaW1wcm92ZSB0aGUgZG9jdW1lbnQsDQo+DQo+IFJlZ2Fy ZHMsDQo+DQo+IC3DqXJpYw0KPg0KPiA9PSBDT01NRU5UUyA9PQ0KPg0KPiAtLSBBYnN0cmFjdCAt LQ0KPiBTaG91bGQgdGhlIGFic3RyYWN0IGJyaWVmbHkgdGFsayBhYm91dCBFQVA/DQpHb29kIHBv aW50LiBJIGhhdmUgdXBkYXRlZCB0aGUgZHJhZnQgaW4gZ2l0aHViOiANCmh0dHBzOi8vZ2l0aHVi LmNvbS9lbXUtd2cvZHJhZnQtaWV0Zi1lbXUtZWFwLXRsczEzL2NvbW1pdC9iYWFmOWEwM2M1ZjI4 MmU5OTA0ZGE2MDcwMDY4N2UyNDhiZWJlMjhjDQo+DQo+IC0tIFNlY3Rpb24gMSAtLQ0KPiBTaG91 bGQgImlldGYtdGxzLW9sZHZlcnNpb25zLWRlcHJlY2F0ZSIgYmUgbm9ybWF0aXZlID8NCkkgYmVs aWV2ZSB0aGF0IGluZm9ybWF0aW9uYWwgaXMgdGhlIGNvcnJlY3QgY2hvaWNlLiBXZSBhcmUgb25s eSANCmluZm9ybWluZyByZWFkZXJzIGFuZCBpbXBsZW1lbnRlcnMgb2YgdGhpcyBkcmFmdCB0aGF0 IG9sZCB2ZXJzaW9ucyBvZiANClRMUyAoMS4wIGFuZCAxLjEpIGFyZSBiZWluZyBkZXByZWNhdGVk LiBUaGV5IGRvbid0IHN0cmljdGx5IG5lZWQgdGhhdCANCmluZm9ybWF0aW9uIGZvciBpbXBsZW1l bnRpbmcgRUFQLVRMUyB3aXRoIFRMUyAxLjMuIEhvd2V2ZXIsIEkgZG9uJ3QgaGF2ZSANCnN0cm9u ZyBvcGluaW9ucyBhbmQgY2FuIHJlY29uc2lkZXIuDQo+DQo+IC0tIFNlY3Rpb24gMiAtLQ0KPiBO aWNlbHkgZG9uZSB0byBoYXZlIGtlcHQgdGhlIHNhbWUgc3ViLXNlY3Rpb24gbnVtYmVycyB3aXRo IHJlc3BlY3QgdG8gUkZDIDUyMTYuDQo+IEt1ZG9zICENClRoYW5rIHlvdSBmb3IgdGhlIHBvc2l0 aXZlIGZlZWRiYWNrLg0KPg0KPiAtLSBTZWN0aW9uIDIuMS4xICYgMi4xLjMgJiAyLjEuNCAtLQ0K PiBJIGZpbmQgIlRoaXMgc2VjdGlvbiB1cGRhdGVzIFNlY3Rpb24gMi4xLjEgb2YgW1JGQzUyMTZd LiIgYSBsaXR0bGUgYW1iaWd1b3VzIGFzDQo+IGl0IHRoZSAndXBkYXRlZCBzZWN0aW9uJyBpcyBu b3QgaWRlbnRpZmllZCBjbGVhcmx5LiBJLmUuLCBhcyB0aGUgc2VjdGlvbnMgaW4NCj4gUkZDIDUy MTYgYXJlIG5vdCB0b28gbG9uZywgd2h5IG5vdCBzaW1wbHkgcHJvdmlkaW5nIHdob2xlIG5ldyBz ZWN0aW9ucyA/DQpZb3UgaGF2ZSBhIHZhbGlkIHBvaW50LiBIb3dldmVyLCBzaW5jZSB0aGlzIGRv Y3VtZW50IHVwZGF0ZXMgYW5kIG5vdCANCm9ic29sZXRlcyBSRkMgNTIxNiwgd2UgZm91bmQgaXQg c3ViLW9wdGltYWwgdG8gcmVwZWF0IHRoZSB0ZXh0LiBXZSBoYXZlIA0Kd3JpdHRlbiB0aGlzIGRv Y3VtZW50IGZvciBhIGRldmVsb3BlciB3aG8gYWxyZWFkeSBoYXMgYW4gRUFQLVRMUyANCmltcGxl bWVudGF0aW9uIGFuZCB3YW50cyB0byB1cGRhdGUgaXQgZm9yIHVzZSB3aXRoIFRMUyAxLjMuIFRo YW5rZnVsbHksIA0KbGFyZ2UgcGFydHMgb2YgdGhlIHVwZGF0ZSBjb21wbGV4aXR5IGFyZSBhY3R1 YWxseSBoYW5kbGVkIGJ5IHRoZSANCnVuZGVybHlpbmcgVExTIGxpYnJhcnkgbGVhdmluZyBvbmx5 IGEgc21hbGwgYW1vdW50IG9mIGNoYW5nZSBuZWVkZWQgZnJvbSANCmFuIEVBUC1UTFMgZGV2ZWxv cGVyLg0KPg0KPiAtLSBTZWN0aW9uIDUuOSAtLQ0KPiBXaGF0IGlzIHRoZSBhZGRlZCBiZW5lZml0 IG9mIHRoaXMgc2VjdGlvbiAocGVydmFzaXZlIG1vbml0b3JpbmcpIGNvbXBhcmVkIHRvDQo+IHNl Y3Rpb24gNS44IChwcml2YWN5IGNvbnNpZGVyYXRpb25zKT8gRXNwIHdoZW4gSSBhbSBhZnJhaWQg dGhhdCBwZXJ2YXNpdmUNCj4gbW9uaXRvcmluZyBpcyBkZWVwZXIgaW4gdGhlIG5ldHdvcmsgcmF0 aGVyIHRoYW4gaW4gdGhlIGFjY2VzcyBuZXR3b3JrIChoYXBweSB0bw0KPiBiZSBjb3JyZWN0ZWQp DQo+DQo+ID09IE5JVFMgPT0NCj4NCj4gTm9uZSBvZiB1cyBhcmUgbmF0aXZlIEVuZ2xpc2ggc3Bl YWtlciwgYnV0ICJlLmcuIiBhcyAiaS5lLiIgYXJlIHVzdWFsbHkNCj4gZm9sbG93ZWQgYnkgYSBj b21tYSB3aGlsZSAiYnV0IiBoYXMgdXN1YWxseSBubyBjb21tYSBiZWZvcmUgOy0pDQoNCkdvb2Qg cG9pbnQuIEkgdGhpbmsgSSBoYXZlIGFkZGVkIGEgY29tbWEgYWZ0ZXIgYWxsIGluc3RhbmNlcyBu b3c6IA0KaHR0cHM6Ly9naXRodWIuY29tL2VtdS13Zy9kcmFmdC1pZXRmLWVtdS1lYXAtdGxzMTMv Y29tbWl0LzdjYmNlOWI4YzNhZDA1YTY0MDZhOGM0OGQ1YjFjYmVmZTIzZmFmNDcNCg0KLS1Nb2hp dA0KDQo+DQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IEVtdSBtYWlsaW5nIGxpc3QNCj4gRW11QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZW11DQoNCg== From nobody Wed Dec 16 08:38:24 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6DE03A10E3 for ; Wed, 16 Dec 2020 08:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCkAyBP1Tso7 for ; Wed, 16 Dec 2020 08:38:21 -0800 (PST) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650103.outbound.protection.outlook.com [40.107.65.103]) (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 1F3A93A10E2 for ; Wed, 16 Dec 2020 08:38:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=h2FQdOmiU1q1Y7oVnmcPYNYQWtx/LcTHtjt4iPoAt1cUmJaGOmcz7XEtO9ROOqEJW8LRQuBzgpgy+o5weV5IofJS6fGDYKEsYA0gxKK/9zNR4iR8PhydQqu4WgV0gaVRcBj69IkITMto8npOaxW/011tXIApiB47598uXH4fLdOvwkX4g6UNt0qi1eWF+7ksLAXfjktP6EcbOUpYvO0g8WazVGj3n+QNmy+NEJBkAdOi45ox8AuPCaM78DJIS1btAyhCyrNk/hLk3SkGwT5ZhU8TTLPZ/lOOfROC7ij+g6fgiq9whk07UCONck68RF5GMGwERLMZl2voUL0qTluuow== 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=LQKLgeUsVRCTzVMB/6LmhtpqQ9ecwFxXkU8fDvK+B78=; b=gNLljCNvxwEJQfqg6fWKziX1vi7T4fLRchZAqLh0AEqNCPMq22YtQI1MJX9dYTa8NcAchyJGp8uxGQEKYPInaWpI5YIHXnmXvdrrrTvv5HapmNCxDWanahPwkiBXZp4FobKeuHEfyNQuNUBGAXyJO5Z9Ykxd1pE5p9uAKZ4/PF+iE8VmxsksAjyd4X3ljS7aV4wGe7OxrkA4o3EuQkpRwEIF7J7B08XAZEdPzu77/dM1/Gn/Q2mhvx/IPgF2NCJSQVDSqqTQGi1pdOCYBuDE1H6anVFrXC5w5gyIqAEN+Jtdhz9wf7lgkBhvVI+R6hy9Rt0FiLypU45fa9iYCNwTGA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LQKLgeUsVRCTzVMB/6LmhtpqQ9ecwFxXkU8fDvK+B78=; b=NoRQpL49dk7qQhWDcPpmbjlcNebGUemJvEhkBvPGPAo/V1rFJ/UxFLsTdfEEx8AjC5vjdCoAIv6cTIUYWdNvqN2YWIl7qVf2N8Gyq4dDBkxATnVqZ8818QaWg9JNUmBbJYHXrKyy6B0Fb2+O4FzsRW/B8PA2ifvKUHYGRWHzWJo= Received: from (2603:10b6:208:c7::23) by MN2PR00MB0896.namprd00.prod.outlook.com (2603:10b6:208:38::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3718.0; Wed, 16 Dec 2020 16:38:16 +0000 Received: from MN2PR00MB0654.namprd00.prod.outlook.com ([fe80::c57e:533d:18a6:3623]) by MN2PR00MB0654.namprd00.prod.outlook.com ([fe80::c57e:533d:18a6:3623%8]) with mapi id 15.20.3718.000; Wed, 16 Dec 2020 16:38:16 +0000 From: Bernard Aboba To: "rfc-editor@rfc-editor.org" CC: "dansimon@microsoft.com" , "rmh@microsoft.com" , "rdd@cert.org" , "kaduk@mit.edu" , "joe@salowey.net" , "mohit.m.sethi@ericsson.com" , "emu@ietf.org" Thread-Topic: [EXTERNAL] [Editorial Errata Reported] RFC5216 (6357) Thread-Index: AQHW02/o7w/py+MkmkOmA5EFq+/dVan57NWk Date: Wed, 16 Dec 2020 16:38:16 +0000 Message-ID: <229AAB27-64CD-4A9F-BEB2-56BB0467ADC7@microsoft.com> References: <20201216055329.2B6D2F40749@rfc-editor.org> In-Reply-To: <20201216055329.2B6D2F40749@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: microsoft.com; dkim=none (message not signed) header.d=none;microsoft.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [71.227.236.207] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 9c847531-ea25-4c55-93ea-08d8a1e0fd24 x-ms-traffictypediagnostic: MN2PR00MB0896: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /0XoqVZwr5ZJznRgYY8VHyUfM6FvwfLQkylNDRm/ejig05LZ/443w+h/H54U6cwZC3F0A+gC8CvAu/1lOjbLyyoHIJW6AzoyJGFXukQazSCdLWtSyW2lhNQtHHkn3pNkT6d/gJEoF6UC5tGt6VH/kC1AzBRKHPWrSIcPX271KZJCYhq9kQdRHQZO8c977OwkS6JUFrQSJpY1pL6h4gjn/5DsfhtfK3SYSzggb6uBg6m/IishpNiD3dfmunGZ2I6XRKlFCQ6aBIbAe5Pej4jPiRQBn20m/yPfziiREUEwO2I/06BsZCALdfxEL+iAyP5E9w8WQ4iE6HKojYtkKCDD5i1rj1ybxyi+GzAq3re1r9+w0t+Ji0/VKK6xDaEUtsHZBhHngMFjCTDlYUjRuZeZgbI5gqwtU80OEzKXwvZj+CYSSRfRnYBtKiUSqzgOzNwFzMG3n5lihNIf8JssAIhd4llQ3uvKsqcsofEvW25EkwB/d9fzWo5sZJqorMo1crNZPRZbXmmc6zZd7f7g1bXX9Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR00MB0654.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(136003)(346002)(376002)(396003)(39860400002)(82950400001)(36756003)(91956017)(82960400001)(76116006)(66946007)(66556008)(66476007)(4326008)(6506007)(966005)(64756008)(66446008)(71200400001)(316002)(5660300002)(54906003)(6916009)(6486002)(8676002)(33656002)(26005)(2616005)(86362001)(186003)(8936002)(6512007)(2906002)(53546011)(478600001)(83380400001)(10290500003)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?dER2ZnhWdG9kWXlXNGJvTmk2TStUeWhoR0h6dTQvWktMVEdVOENWaXdvOGF5?= =?utf-8?B?ZkRvUlhQdlZhcjN3R1JxR0tYOTlXNEV3MjFMRzJPNXpVRm5EbHREME9GMVZv?= =?utf-8?B?M0JNRXJhRTFsbXBKbnJ0QzdFSmljZHRZVnhnbENvWGFhYjBES1dUOEZDbkJn?= =?utf-8?B?WFhkdXdZY3R3Y3A0ZDVMa3FqWjU3d2V5QnV4QXZSNzlLZ3ljK20xSStObytv?= =?utf-8?B?cjUxcVI5UTQzQjVZQ0YwblE3R3A4aE4rV0Z5RTBwMUM0L2t0WmI1c2ZKWXpV?= =?utf-8?B?bWdBL3VmQmZqcWlRU2JScEYza2FKeDBjUGFVQnRDZVZISkJJcko0TU9FcU1M?= =?utf-8?B?dW1jNDV2SVVGK0h4N00rVi93cUloZ2o4eUVCMk5aY2tvcEd6VlpnSzV0U1k3?= =?utf-8?B?bWw4UXFVODZFNUN0RFNQS3A1am9FYVowNXNCdW9LQ3Izc1YrdmxDOE5HRUI5?= =?utf-8?B?SlI5dmdTRFRhR0xtY3duYXNSb0c2dndPcll5SFIzQnp5ZUNhKzJZb1FueElj?= =?utf-8?B?VTBTQktQT1E5d0ZJcFI5blpFRWdOekxKQXMzbVk5VVpPNUpWVGVNZzBTVmdN?= =?utf-8?B?LzFvS3JxRERyWWp0dXNnbXplZTJ6NHVPdzk5K0d1RmZ0eHJBRVNkNkM1RUhV?= =?utf-8?B?MkdTU1BhRnNpWlJBanViZFFpdG5FcncxK1FzMVR4ajZjekRHWW5GNDZDVXN2?= =?utf-8?B?RUhjUTdEdjhMODliVjU2K2VYRDAvZ1k2ZmMzRXVoWU5sOFNBZEwwY0NrQ3J1?= =?utf-8?B?NnZ4eEgzKzdZOG1tdDcxRHZuSE55Mkpud1p4c3dvb3p5aDFPWEQzMU1LVFFP?= =?utf-8?B?QXN4dC9YZnh2NkxzbkRzbzJTMTlVdEhjSWxLT0lRR3VrbklRcFpyajh3aGhG?= =?utf-8?B?TEJvcHVIYm5jc2xnZUxYMm11MkVadGtnTHVZUEtNdmhOSmp4SnFudWIycjRM?= =?utf-8?B?eVYyUUs0ZWoycTlKVTdVdmpFb2xTVm02RTFGYmlYTHc0cXFiSWNsOW5KTmtk?= =?utf-8?B?VHBCRncwdmR4Y3NPWkt3eGJXZXkzeEQ4VnZzMm9MZHl0TUMzYTAwOEZBbURq?= =?utf-8?B?Z2NtVUR0N1JIekpLUXg3RWYzeHB3THJGdUpCOWxYNWlaMXNTellqRHlIeERx?= =?utf-8?B?WGtVV2NObDlSR29HckZjR1J1K1VkTVJXT3ViMDBWUVE3TTJtSWlYWFo3d2dt?= =?utf-8?B?blovdUZGUDFPYmxCL0JHNTMwVFkrSC9xZjJlSVNsd1cxNGd0OVpXUDVMM0Z2?= =?utf-8?B?U3p2U0tlVlQxSWtnTmhsTnBjZzgvZXQ2QnYyc25sUlBYKzhxRFdvRUtwZG8w?= =?utf-8?B?bUR3VnRMbzlrTDVNNkZSZDU2WjI5bXhZVitSMFY0blRGYXFNaUk3d2JZS2ZT?= =?utf-8?B?Q2JoV2o2M3VyQVczOXJxS1RZa2VmZ0p2WlYxWTZpOFhiWjdEU2FWWEtjN0tr?= =?utf-8?Q?P0Qba04D?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR00MB0654.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9c847531-ea25-4c55-93ea-08d8a1e0fd24 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2020 16:38:16.4394 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yOaKlHUKzK4UXU6XxP2gRYHNQPgnTQc2HYZvGKsq8LZoUlovgmuN5Y1+k/Om5DsTg9r3AM/ikF+bdfHFjsN8DQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR00MB0896 Archived-At: Subject: Re: [Emu] [EXTERNAL] [Editorial Errata Reported] RFC5216 (6357) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2020 16:38:23 -0000 TG9va3Mgb2sgdG8gbWUuDQoNCj4gT24gRGVjIDE1LCAyMDIwLCBhdCAyMTo1NCwgUkZDIEVycmF0 YSBTeXN0ZW0gPHJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmc+IHdyb3RlOg0KPiANCj4g77u/VGhl IGZvbGxvd2luZyBlcnJhdGEgcmVwb3J0IGhhcyBiZWVuIHN1Ym1pdHRlZCBmb3IgUkZDNTIxNiwN Cj4gIlRoZSBFQVAtVExTIEF1dGhlbnRpY2F0aW9uIFByb3RvY29sIi4NCj4gDQo+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFlvdSBtYXkgcmV2aWV3IHRoZSByZXBv cnQgYmVsb3cgYW5kIGF0Og0KPiBodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91 dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cucmZjLWVkaXRvci5vcmclMkZlcnJhdGEl MkZlaWQ2MzU3JmFtcDtkYXRhPTA0JTdDMDElN0NCZXJuYXJkLkFib2JhJTQwbWljcm9zb2Z0LmNv bSU3Q2ZkMThjMzc2MzQyNjRkOTE2MzM1MDhkOGExODZlZTA4JTdDNzJmOTg4YmY4NmYxNDFhZjkx YWIyZDdjZDAxMWRiNDclN0MwJTdDMCU3QzYzNzQzNjk0ODY0NzI4NDk4MyU3Q1Vua25vd24lN0NU V0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklr MWhhV3dpTENKWFZDSTZNbjAlM0QlN0MyMDAwJmFtcDtzZGF0YT1KbVRIJTJCRWN3MWtzbnljQWVa eXFndFV5SmNwdjMlMkZ0TUYwelFwMWdDTXFRbyUzRCZhbXA7cmVzZXJ2ZWQ9MA0KPiANCj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gVHlwZTogRWRpdG9yaWFsDQo+ IFJlcG9ydGVkIGJ5OiBCZW5qYW1pbiBLYWR1ayA8a2FkdWtAbWl0LmVkdT4NCj4gDQo+IFNlY3Rp b246IDUuMQ0KPiANCj4gT3JpZ2luYWwgVGV4dA0KPiAtLS0tLS0tLS0tLS0tDQo+ICAgWzNdIFNl Y3Rpb24gNSBvZiBCQ1AgODYgW1JGQzM3NjZdIG9mZmVycyBhZHZpY2Ugb24gdGhlIHJlcXVpcmVk IFJTQQ0KPiAgIG9yIERpZmZpZS1IZWxsbWFuIChESCkgbW9kdWxlIGFuZCBEaWdpdGFsIFNpZ25h dHVyZSBBbGdvcml0aG0gKERTQSkNCj4gICBzdWJncm91cCBzaXplIGluIGJpdHMsIGZvciBhIGdp dmVuIGxldmVsIG9mIGF0dGFjayByZXNpc3RhbmNlIGluDQo+ICAgYml0cy4gIEZvciBleGFtcGxl LCBhIDIwNDgtYml0IFJTQSBrZXkgaXMgcmVjb21tZW5kZWQgdG8gcHJvdmlkZQ0KPiAgIDEyOC1i aXQgZXF1aXZhbGVudCBrZXkgc3RyZW5ndGguICBUaGUgTmF0aW9uYWwgSW5zdGl0dXRlIG9mIFN0 YW5kYXJkcw0KPiAgIGFuZCBUZWNobm9sb2d5IChOSVNUKSBhbHNvIG9mZmVycyBhZHZpY2Ugb24g YXBwcm9wcmlhdGUga2V5IHNpemVzIGluDQo+ICAgW1NQODAwLTU3XS4NCj4gDQo+IENvcnJlY3Rl ZCBUZXh0DQo+IC0tLS0tLS0tLS0tLS0tDQo+ICAgWzNdIFNlY3Rpb24gNSBvZiBCQ1AgODYgW1JG QzM3NjZdIG9mZmVycyBhZHZpY2Ugb24gdGhlIHJlcXVpcmVkIFJTQQ0KPiAgIG9yIERpZmZpZS1I ZWxsbWFuIChESCkgbW9kdWx1cyBhbmQgRGlnaXRhbCBTaWduYXR1cmUgQWxnb3JpdGhtIChEU0Ep DQo+ICAgc3ViZ3JvdXAgc2l6ZSBpbiBiaXRzLCBmb3IgYSBnaXZlbiBsZXZlbCBvZiBhdHRhY2sg cmVzaXN0YW5jZSBpbg0KPiAgIGJpdHMuICBGb3IgZXhhbXBsZSwgYSAyMDQ4LWJpdCBSU0Ega2V5 IGlzIHJlY29tbWVuZGVkIHRvIHByb3ZpZGUNCj4gICAxMjgtYml0IGVxdWl2YWxlbnQga2V5IHN0 cmVuZ3RoLiAgVGhlIE5hdGlvbmFsIEluc3RpdHV0ZSBvZiBTdGFuZGFyZHMNCj4gICBhbmQgVGVj aG5vbG9neSAoTklTVCkgYWxzbyBvZmZlcnMgYWR2aWNlIG9uIGFwcHJvcHJpYXRlIGtleSBzaXpl cyBpbg0KPiAgIFtTUDgwMC01N10uDQo+IA0KPiBOb3Rlcw0KPiAtLS0tLQ0KPiBSU0EgYW5kIERI IGNvbXB1dGF0aW9ucyBhcmUgcGFyYW1ldGVyaXplZCBieSB0aGVpciBtb2R1bGksIHdpdGggc2lu Z3VsYXIgIm1vZHVsdXMiIChub3QgIm1vZHVsZSIpLg0KPiANCj4gSW5zdHJ1Y3Rpb25zOg0KPiAt LS0tLS0tLS0tLS0tDQo+IFRoaXMgZXJyYXR1bSBpcyBjdXJyZW50bHkgcG9zdGVkIGFzICJSZXBv cnRlZCIuIElmIG5lY2Vzc2FyeSwgcGxlYXNlDQo+IHVzZSAiUmVwbHkgQWxsIiB0byBkaXNjdXNz IHdoZXRoZXIgaXQgc2hvdWxkIGJlIHZlcmlmaWVkIG9yDQo+IHJlamVjdGVkLiBXaGVuIGEgZGVj aXNpb24gaXMgcmVhY2hlZCwgdGhlIHZlcmlmeWluZyBwYXJ0eSAgDQo+IGNhbiBsb2cgaW4gdG8g Y2hhbmdlIHRoZSBzdGF0dXMgYW5kIGVkaXQgdGhlIHJlcG9ydCwgaWYgbmVjZXNzYXJ5LiANCj4g DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFJGQzUyMTYgKGRy YWZ0LXNpbW9uLWVtdS1yZmMyNzE2YmlzLTEzKQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPiBUaXRsZSAgICAgICAgICAgICAgIDogVGhlIEVBUC1UTFMgQXV0aGVu dGljYXRpb24gUHJvdG9jb2wNCj4gUHVibGljYXRpb24gRGF0ZSAgICA6IE1hcmNoIDIwMDgNCj4g QXV0aG9yKHMpICAgICAgICAgICA6IEQuIFNpbW9uLCBCLiBBYm9iYSwgUi4gSHVyc3QNCj4gQ2F0 ZWdvcnkgICAgICAgICAgICA6IFBST1BPU0VEIFNUQU5EQVJEDQo+IFNvdXJjZSAgICAgICAgICAg ICAgOiBFQVAgTWV0aG9kIFVwZGF0ZQ0KPiBBcmVhICAgICAgICAgICAgICAgIDogU2VjdXJpdHkN Cj4gU3RyZWFtICAgICAgICAgICAgICA6IElFVEYNCj4gVmVyaWZ5aW5nIFBhcnR5ICAgICA6IElF U0cNCg== From nobody Wed Dec 16 12:17:13 2020 Return-Path: X-Original-To: emu@ietf.org Delivered-To: emu@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 10EC33A0EFA; Wed, 16 Dec 2020 12:17:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alvaro Retana via Datatracker To: "The IESG" Cc: draft-ietf-emu-eap-tls13@ietf.org, emu-chairs@ietf.org, emu@ietf.org, Joseph Salowey X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alvaro Retana Message-ID: <160814982804.27468.5022098982817383443@ietfa.amsl.com> Date: Wed, 16 Dec 2020 12:17:08 -0800 Archived-At: Subject: [Emu] Alvaro Retana's No Objection on draft-ietf-emu-eap-tls13-13: (with COMMENT) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2020 20:17:08 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-emu-eap-tls13-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Is the intention of the Appendix to provide additional formal updates to rfc5216? That is what it looks like to me, but there's no reference to it from the main text. Please either reference the Appendix when talking about some of the other updates (if appropriate) or specifically include the text somewhere more prominent. From nobody Wed Dec 16 14:30:55 2020 Return-Path: X-Original-To: emu@ietf.org Delivered-To: emu@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 164303A1276; Wed, 16 Dec 2020 14:30:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-emu-eap-tls13@ietf.org, emu-chairs@ietf.org, emu@ietf.org, Joseph Salowey , joe@salowey.net X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <160815785407.21119.13524832863443181193@ietfa.amsl.com> Date: Wed, 16 Dec 2020 14:30:54 -0800 Archived-At: Subject: [Emu] Barry Leiba's No Objection on draft-ietf-emu-eap-tls13-13: (with COMMENT) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2020 22:30:54 -0000 Barry Leiba has entered the following ballot position for draft-ietf-emu-eap-tls13-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I found this to be exceptionally well written and clear. Thanks for the great work on this! From nobody Wed Dec 16 14:36:57 2020 Return-Path: X-Original-To: emu@ietf.org Delivered-To: emu@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8393A1277; Wed, 16 Dec 2020 14:36:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-emu-eap-tls13@ietf.org, emu-chairs@ietf.org, emu@ietf.org, Joseph Salowey , joe@salowey.net X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <160815821055.25925.15897627611548078426@ietfa.amsl.com> Date: Wed, 16 Dec 2020 14:36:50 -0800 Archived-At: Subject: [Emu] Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2020 22:36:51 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-emu-eap-tls13-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I'm going to defer this document's evaluation because I think there are several interrelated subtle issues that merit closer consideration than has been given so far. I will also invite the TLS WG to provide input on these issues, since they relate to rather fundamental issues of the operation of the TLS sub-protocols. Most of them concern the Commitment Message, in terms of what goals it aims to achieve, how it is specified, and what mechanism is used to effectuate it. To start with the easy one: currently the way in which the structure of the Commitment Message is described makes reference to many fields of TLS Record Layer structures in order to specify what is fundamentally a message on the TLS Application Data stream. This is a layering violation; I don't see any reason to say more than what was suggested in https://mailarchive.ietf.org/arch/msg/emu/ECgvnq-C_VVXT5bpvOowte8LBjw/ : "the commit[ment] message is a single byte of [value] 0 in the application data stream". All the bits about cryptographic protection and expansion of the plaintext in prepararation for record protection are just adding noise, and the interface between the TLS stack and the application is supposed to be a data-stream abstraction, not a record abstraction. Next, the whole reason for the existence of a Commitment Message seems under-justified -- the only mention I could find in the document is that it serves "to decrease the uncertainty for the EAP-TLS peer". What harm would be caused by a lack of certainty in this area? Why does waiting for an EAP-Success or EAP-Failure not provide a similar level of certainty? The document also suggests in several places that the Commitment Message can or should be sent at 0.5-RTT data in the same flight as the server Finished. The intent, as determined from the mailing list archive, seems to be to save a round-trip compared to a typical full message flow where the server does not send application data until after the client's Finished (and any application data alongside it) is received. In particular, this came out during discussion of how a TLS "close_notify" alert would be unsuitable for the role of the Commitment Message, since sending the "close_notify" in 0.5-RTT would prevent sending an alert if the client authentication failed, and the diagnostic value of such alerts is significant. This is where the issues start to become interrelated -- the Commitment Message as a new application-data construct is for the objective of reducing the number of round trips. However, TLS session resumption is also designed to reduce the number of round-trips (including by no longer needing to send potentially large TLS Certificate messages that get fragmented at the EAP layer, with the cost of a round trip per fragment), and there is a nasty interaction between the two mechanisms. Specifically, TLS 1.3 session resumption requires the use of a NewSessionTicket message, which is associated with a resumption secret; the resumption secret, in turn, is not available in the key schedule until the client Finished (and client authentication messages, if any) is available. While it is possible in many Web scenarios for NewSessionTicket to be issued in the 0.5-RTT flight, this is because the server can precompute what the valid client Finished would be and use that in the key schedule to precompute the resumption secret. If the client is to be authenticated, as is the case for the vast majority of EAP exchanges, then such precomputation is impossible, and the session ticket cannot be issued until the extra round trip is completed. The document contains no discussion of the inherent tradeoff between sending the commitment message in 0.5-RTT and using resumption, and this tradeoff seems to call into question the merits of choosing this mechanism to implement the commitment message, since... The commitment message as specified seems to itself be a layering violation. The TLS protocol itself consists of a few sub-protocols, e.g., the handshake protocol, record protocol, and alert protocol. The operation of the handshake protocol is supposed to be completely independent of the application-data record protocol (except to the extent that the handshake protocol supplies the keys used for cryptographic protection of application data records). In particular, there should not be any interaction between the handshake state machine and the application data. If there is to be a commitment made about the operation of the TLS handshake protocol, that more properly belongs in the handshake layer itself, or perhaps the alert layer if it relates to the overall operation of the TLS connection. It seems inappropriate and unsustainable to expect that an application-data message would affect the operation of the handshake layer. The use of application data for the commitment message also may have unfortunate interactions with other TLS-using EAP methods, which is very briefly mentioned as a possibility but not explored at all: While EAP-TLS does not protect any application data except for the Commitment Message, the negotiated cipher suites and algorithms MAY be used to secure data as done in other TLS-based EAP methods. If we are to expect this construction of commitment message to become the de facto standard for using TLS 1.3 with EAP, I think we need to consider whether other EAP methods that do need to actually protect application data with the TLS connection will be affected by this proposal to insert the EAP commitment message into the application data stream. This is worth particular consideration given that we require that "EAP-TLS peer implementations MUST accept any application data as a Commitment Message from the EAP-TLS server to not send any more handshake messages" -- these seem like new semantics that might be quite unexpected if applied to other EAP methods. There's also a few internal inconsistencies that raise to a discuss-level and will need to be resolved before publication: The body text around Figure 3 indicates that mutual authentication should be depicted, but the figure shows only normal server-only authentication. The example in Figure 8 needs a TLS CertificateRequest in there in order for the rest of the flow to make sense. Section 2.1.4 says that "TLS warning alerts generally mean that the connection can continue normally and does not change the message flow." but this is no longer true with TLS 1.3 -- the only alerts sent at warning level are "close_notify" and "user_cancelled", both of which indicate that the connection is not going to continue normally. Section 2.1.9 claims that the largest size of a TLS record is 16387 octets, but by my count a TLSCiphertext can get up to 16643, since the length field "MUST NOT exceed 2^14 + 256 bytes" (and there's the other 3 bytes of header). Please also check the statements made about RFC 8446 that I note in my comments on Section 5.1. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Some of these comments are a bit rough, as I did not do my full editing pass since I plan to defer the ballot. I'm including them anyway as they still seem likely to be useful even in this form. I strongly suggest that the option for the server to send an alert instead of HelloRetryRequest in the case of missing "key_share" be removed; see my comments on Section 2.1.3. As far as I can tell this option is flat-out bad practice and should not be allowed. I also strongly suggest that the WG make the simple modification to the key schedule that I suggest in my comments on Sections 2.3 and 5.5, that would have the effect of achieving the property anticipated by Section 5.5 of RFC 5216, whereby incorporating the EAP-TLS Type information into the key derivation formula prevents a type of packet modification attack. Abstract reduced latency when compared to earlier versions of TLS. EAP-TLS with TLS 1.3 further improves security and privacy by mandating use of privacy and revocation checking. This document also provides I agree with the secdir reviewer that some indication of what is meant by (EAP) "privacy" here is likely in order. Section 1 In addition to the improved security and privacy offered by TLS 1.3, there are other significant benefits of using EAP-TLS with TLS 1.3. Privacy is mandatory and achieved without any additional round-trips, (ditto) Section 2.1.1 for resumption. SessionID is deprecated in TLS 1.3 and the EAP-TLS server SHALL ignore the legacy_session_id field if TLS 1.3 is negotiated. TLS 1.3 introduced early application data which is not (nit) we could perhaps quibble about whether "SHALL ignore" is consistent with the RFC 8446 requirement to echo the legacy_session_id value from the ClientHello in the ServerHello, though I'm not going to make a big deal about it. used in EAP-TLS. A EAP-TLS server which receives an "early_data" extension MUST ignore the extension or respond with a HelloRetryRequest as described in Section 4.2.10 of [RFC8446]. It's probably better to place restrictions on the indication that early data might be possible, than to (just) place restrictions on accepting it. That is, if the server is forbidden from generating a NewSessionTicket message that includes the "early_data" extension, then the client is also forbidden from sending "early_data" in a ClientHello. [ed. we do do this in §2.1.2] Section 2.1.3 full handshake. It is left up to the EAP-TLS peer whether to use resumption, but it is RECOMMENDED that the EAP-TLS server accept resumption as long as the ticket is valid. However, the EAP-TLS But the EAP-TLS server sets how long the ticket is valid :) Should we give some guidance on how long that should be (noting that it must say within the RFC 8446-mandated 7 day maximum). was used in the original full authentication. E.g. the NAI @realm can safely be reused, while the NAI ZmxleG8=@realm cannot. The TLS (Does base64("flexo") have enough randomness to be reflective of a good privacy NAI?) A subsequent authentication using resumption, where both sides authenticate successfully (without the issuance of more resumption tickets) is shown in Figure 3. (It's slightly surprising to show an example of resumption without issuing additional resumption tickets, since such issuance is basically necessary in order to comply with the recommendation from earlier in the section to follow the client tracking prevention mechanisms in Appendix C.4 of RFC 8446. Though I guess draft-ietf-tls-ticketrequests is potentially relevant for just how necessary it is going to be in practice.) back to a full handshake. If the EAP-TLS peer did not supply a "key_share" extension when attempting resumption, the EAP-TLS server needs to reject the ClientHello and the EAP-TLS peer needs to restart a full handshake. The message flow in this case is given by Figure 4 followed by Figure 1. Also during resumption, the EAP-TLS server can respond with a Hello Retry Request (see Section 2.1.6) or issue a new ticket (see Section 2.1.2) I don't understand why the "alert plus fresh handshake" flow is even listed as an option -- AFAICT the HelloRetryRequest (note: no spaces) flow is uniformly superior. There is no benefit in round-trip count to starting a fresh handshake, and HelloRetryRequest allows the initial interaction to be authenticated by the continued handshake transcript. Aborting and starting over is analogous to the dreaded "downgrade dance" that has periodically plagued the TLS ecosystem, and I'm confused that we would consider encouraging it to return. I would instead say that the server "needs to send HelloRetryRequest to signal that additional information is needed to complete the handshake, and the EAP-TLS peer needs to send a second ClientHello containing that information" (or similar), and drop the "Figure 4 followed by Figure 1" sentence. (The final paragraph would then become a bit redundant, but perhaps there is still some information that should be persisted.) Section 2.1.4 The two paragraphs below replaces the corresponding paragraphs in Section 2.1.3 of [RFC5216] when EAP-TLS is used with TLS 1.3 or higher. The other paragraphs in Section 2.1.3 of [RFC5216] still apply with the exception that SessionID is deprecated. If the EAP-TLS peer authenticates successfully, the EAP-TLS server MUST send an EAP-Request packet with EAP-Type=EAP-TLS containing TLS records conforming to the version of TLS used. The message flow ends with the EAP-TLS server sending an EAP-Success message. If the EAP-TLS server authenticates successfully, the EAP-TLS peer MUST send an EAP-Response message with EAP-Type=EAP-TLS containing TLS records conforming to the version of TLS used. Just to walk through the various scenarios here; if the last message of the TLS handshake for a given TLS version is sent by the TLS client, that will go in an EAP-Response, so the server is then able to send EAP-Success directly. On the other hand, if the last TLS handshake message is sent by the server, that will have to go in an EAP-TLS EAP-Request, and so the peer will have to send an empty EAP-TLS response in order for the server to be able to wend EAP-Success? Do we need to have any text here to handle that empty EAP-TLS Eap-Request case? In the case where the EAP-TLS server rejects the ClientHello with a fatal error, the conversation will appear as shown in Figure 4. The Should we perhaps say that these examples are with TLS 1.3, even if the actual normative protocol is no longer tied to a specific TLS version? Section 2.1.5 In some sense, this figure depicting the no-peer-authentication case is just an example specific to TLS 1.3 and is not necessarily representative of the generic EAP-TLS case for potential future versions of TLS. Should we make that more clear from the prose? Section 2.1.6 the handshake. One use case is if the EAP-TLS server does not support the groups in the "key_share" extension, but supports one of I'd consider adding a parenthetical "(or there is no "key_share" extension)". Section 2.1.8 username in cleartext in the Identity Response. Following [RFC7542], it is RECOMMENDED to omit the username (i.e. the NAI is @realm), but other constructions such as a fixed username (e.g. anonymous@realm) or an encrypted username (e.g. YmVuZGVy@realm) are allowed. Note (I note that YmVuZGVy is just base64("bender"); does that really count as "encrypted"?) Section 2.3 The use of a constant 0x0D (the "Type-Code") as the TLS-Exporter context is rather unusual; per RFC 8446 this value is intended to be a "per-association context value provided by the application using the exporter" per RFC 5705 -- this value is not a per-association value but rather a global one. Section 2.4 While EAP-TLS does not protect any application data except for the Commitment Message, the negotiated cipher suites and algorithms MAY be used to secure data as done in other TLS-based EAP methods. This makes me uncomfortable -- is this other data being secured going to live in the same "namespace" as the Commitment Message? Section 2.5 and TLSPlaintext.fragment = 0x00). Note that the length of the plaintext is greater than the corresponding TLSPlaintext.length due (This sentence reads oddly; perhaps "length of the TLSInnerPlaintext" is more clear? But we shouldn't be saying this at all, per the Discuss.) Section 5.1 [2] Confidentiality: The TLS 1.3 handshake offers much better confidentiality than earlier versions of TLS by mandating cipher suites with confidentiality and encrypting certificates and some of the extensions, see [RFC8446]. When using EAP-TLS with TLS 1.3, the I note that there exist codepoints for TLS 1.3 ciphersuites that do not provide confidentiality protection. Please point to the part of RFC 8446 that mandates this behavior. [3] Key strength: TLS 1.3 forbids all algorithms with known weaknesses including 3DES, CBC mode, RC4, SHA-1, and MD5. TLS 1.3 Where does RFC 8446 forbid 3DES? CBC is forbidden by the requirement to be AEAD, and RC4 and MD5 are explicitly forbidden, but the situation for SHA-1 is more subtle. Please reword this sentence to be accurate. Section 5.4 When EAP-TLS is used with TLS 1.3, the revocation status of all the certificates in the certificate chains MUST be checked. What does this mandatory checking entail when a certificate contains neither a CRL Distribution Point nor an OCSP responder URL? (See also the recent thread on the LAMPS WG list with Subject: "The id-ce-noRevAvail extension".) TLS, see Section 4.4.2.1 of [RFC8446]. In TLS 1.3 the OCSP information is carried in the CertificateEntry containing the associated certificate instead of a separate CertificateStatus message as in [RFC4366]. This enables sending OCSP information for RFC 4366 seems like a stale (obsolete) reference, and RFC 6066 should be preferred. (RFC 4366 would then become an unused reference, I believe.) To enable revocation checking in situations where EAP-TLS peers do not implement or use OCSP stapling, and where network connectivity is not available prior to authentication completion, EAP--TLS peer implementations MUST also support checking for certificate revocation after authentication completes and network connectivity is available, and they SHOULD utilize this capability by default. If it's RECOMMENDED to use OCSP stapling, what does it mean that they "SHOULD utilize this capability by default" (as well)? (Also, nit: only one '-' in EAP-TLS.) Section 5.5 It seems like there may be some scope for improvements on the RFC 5216 behavior here. For example, what if we used the EAP Type field as the TLS Exporter 'context' argument, instead of the literal 0x0D? That seems like it would prevent the modification from successfully causing a different TLS-based EAP method to be used, by using a different key-derivation formula, exactly as postulated by RFC 5126. Section 5.7 and the authorizations of the other party may have been reduced. If the cached revocation is not sufficiently current, the EAP-TLS peer or EAP-TLS server MAY force a full TLS handshake. nit: s/cached revocation/cached revocation data/ in the certificate chain has been revoked or has expired. In all such cases, resumption results in a full TLS handshake instead. nit: s/resumption results/an attempt at resumption results/ (or similar) If any authorization, accounting, or policy decisions were made with information that have changed between the initial full handshake and resumption, and if change may lead to a different decision, such decisions MUST be reevaluated. It is RECOMMENDED that authorization, accounting, and policy decisions are reevaluated based on the information given in the resumption. [...] I'm not sure I understand how these two sentences fit together. Is it trying to say that "if there could be a different decision, you definitly have to re-check, and we recommend just always re-checking since that's timpler"? Where a good decision is unclear, EAP-TLS servers SHOULD reject the resumption. I suggest "reject the assumption and continue with a full handshake". Section 4.2.11, 8.1, and 8.2 of [RFC8446] provides security considerations for resumption. I'm curious why specifically § 8.1 and 8.2 were selected, given that §8 as a whole is about "0-RTT and Anti-Replay", which is a more specific topic than just resumption. Section 5.8 Tracking of users by eavesdropping on identity responses or certificates is a well-known problem in many EAP methods. When EAP- TLS is used with TLS 1.3, all certificates are encrypted, and the username part of the identity response is always confidentiality protected (e.g. using anonymous NAIs). [...] As written this applies to server certificates as well as TLS client certificates. For which the statement is technically true, but with the caveat that it is typically easy to persuade the server to (re-)send those same certificates encrypted to a key known to the attacker, so the protection provided by the encryption is limited. (The server has been fairly strongly authenticated by the time the EAP peer makes the decision to send its certificate, so there the reverse situation is different.) and only using the pseudo-random usernames a single time. Note that the privacy-friendly usernames also MUST NOT include substrings that can be used to relate the identity to a specific user. Similarly, privacy-friendly username SHOULD NOT be formed by a fixed mapping that stays the same across multiple different authentications. I think that violating the SHOULD NOT would intrinsically violate the preceding MUST NOT ... so should they both be MUST NOTs? static RSA based cipher suites without privacy. This implies that an EAP-TLS peer SHOULD NOT continue the handshake if a TLS 1.2 EAP-TLS server responds to an empty certificate message with a TLS alert message. Just to check my understanding, this "response" would be an EAP-TLS response containing a new ClientHello (that would proceed to do a handshake including the client certificate in the unprotected initial handshake)? That is, it would be a response at the EAP layer but not at the TLS layer. Section 5.9 Pervasive monitoring refers to widespread surveillance of users. In the context EAP-TLS, pervasive monitoring attacks can target EAP-TLS nit: "context of" Section 5.10 summarizes the attacks that were known at the time of publishing and [RFC7525] provides recommendations for improving the security of deployed services that use TLS. However, many of the attacks are Using BCP195 as the slug is probably preferred, since any RFCs associated with the BCP are going to be relevant and topical. From nobody Wed Dec 16 14:38:56 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB9403A1277; Wed, 16 Dec 2020 14:38:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 H5L--DVaQb-K; Wed, 16 Dec 2020 14:38:50 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BBE93A127D; Wed, 16 Dec 2020 14:38:49 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0BGMcgCh011338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 16 Dec 2020 17:38:47 -0500 Date: Wed, 16 Dec 2020 14:38:42 -0800 From: Benjamin Kaduk To: tls@ietf.org Cc: emu@ietf.org Message-ID: <20201216223842.GR64351@kduck.mit.edu> References: <160815821055.25925.15897627611548078426@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <160815821055.25925.15897627611548078426@ietfa.amsl.com> Archived-At: Subject: [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2020 22:38:54 -0000 Hi TLS WG, I'm forwarding my ballot comments on the (now-deferred) EAP with TLS 1.3 draft here, since they relate to some rather core TLS protocol concepts, and I'd like to get some broader feedback with the extra time given by deferring the ballot. Please ensure that comments reach the EMU WG list (cc'd). Thanks, Ben On Wed, Dec 16, 2020 at 02:36:50PM -0800, Benjamin Kaduk via Datatracker wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-emu-eap-tls13-13: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I'm going to defer this document's evaluation because I think there are > several interrelated subtle issues that merit closer consideration than > has been given so far. I will also invite the TLS WG to provide input > on these issues, since they relate to rather fundamental issues of the > operation of the TLS sub-protocols. > > Most of them concern the Commitment Message, in terms of what goals it > aims to achieve, how it is specified, and what mechanism is used to > effectuate it. > > To start with the easy one: currently the way in which the structure of > the Commitment Message is described makes reference to many fields of > TLS Record Layer structures in order to specify what is fundamentally a > message on the TLS Application Data stream. This is a layering > violation; I don't see any reason to say more than what was suggested in > https://mailarchive.ietf.org/arch/msg/emu/ECgvnq-C_VVXT5bpvOowte8LBjw/ : > "the commit[ment] message is a single byte of [value] 0 in the application data > stream". All the bits about cryptographic protection and expansion of the > plaintext in prepararation for record protection are just adding noise, > and the interface between the TLS stack and the application is supposed > to be a data-stream abstraction, not a record abstraction. > > Next, the whole reason for the existence of a Commitment Message seems > under-justified -- the only mention I could find in the document is that > it serves "to decrease the uncertainty for the EAP-TLS peer". What harm > would be caused by a lack of certainty in this area? Why does waiting > for an EAP-Success or EAP-Failure not provide a similar level of > certainty? > > The document also suggests in several places that the Commitment Message > can or should be sent at 0.5-RTT data in the same flight as the server > Finished. The intent, as determined from the mailing list archive, > seems to be to save a round-trip compared to a typical full message flow > where the server does not send application data until after the client's > Finished (and any application data alongside it) is received. In > particular, this came out during discussion of how a TLS "close_notify" > alert would be unsuitable for the role of the Commitment Message, since > sending the "close_notify" in 0.5-RTT would prevent sending an alert if > the client authentication failed, and the diagnostic value of such > alerts is significant. This is where the issues start to become > interrelated -- the Commitment Message as a new application-data > construct is for the objective of reducing the number of round trips. > However, TLS session resumption is also designed to reduce the number of > round-trips (including by no longer needing to send potentially large > TLS Certificate messages that get fragmented at the EAP layer, with the > cost of a round trip per fragment), and there is a nasty interaction > between the two mechanisms. Specifically, TLS 1.3 session resumption > requires the use of a NewSessionTicket message, which is associated with > a resumption secret; the resumption secret, in turn, is not available in > the key schedule until the client Finished (and client authentication > messages, if any) is available. While it is possible in many Web > scenarios for NewSessionTicket to be issued in the 0.5-RTT flight, this > is because the server can precompute what the valid client Finished > would be and use that in the key schedule to precompute the resumption > secret. If the client is to be authenticated, as is the case for the > vast majority of EAP exchanges, then such precomputation is impossible, > and the session ticket cannot be issued until the extra round trip is > completed. The document contains no discussion of the inherent tradeoff > between sending the commitment message in 0.5-RTT and using resumption, > and this tradeoff seems to call into question the merits of choosing > this mechanism to implement the commitment message, since... > > The commitment message as specified seems to itself be a layering > violation. The TLS protocol itself consists of a few sub-protocols, > e.g., the handshake protocol, record protocol, and alert protocol. The > operation of the handshake protocol is supposed to be completely > independent of the application-data record protocol (except to the > extent that the handshake protocol supplies the keys used for > cryptographic protection of application data records). In particular, > there should not be any interaction between the handshake state machine > and the application data. If there is to be a commitment made about the > operation of the TLS handshake protocol, that more properly belongs in > the handshake layer itself, or perhaps the alert layer if it relates to > the overall operation of the TLS connection. It seems inappropriate and > unsustainable to expect that an application-data message would affect > the operation of the handshake layer. > > The use of application data for the commitment message also may have > unfortunate interactions with other TLS-using EAP methods, which is very > briefly mentioned as a possibility but not explored at all: > > While EAP-TLS does not protect any application data except for the > Commitment Message, the negotiated cipher suites and algorithms MAY > be used to secure data as done in other TLS-based EAP methods. > > If we are to expect this construction of commitment message to become > the de facto standard for using TLS 1.3 with EAP, I think we need to > consider whether other EAP methods that do need to actually protect > application data with the TLS connection will be affected by this > proposal to insert the EAP commitment message into the application data > stream. This is worth particular consideration given that we require > that "EAP-TLS peer implementations MUST accept any application data as a > Commitment Message from the EAP-TLS server to not send any more > handshake messages" -- these seem like new semantics that might be quite > unexpected if applied to other EAP methods. > > There's also a few internal inconsistencies that raise to a > discuss-level and will need to be resolved before publication: > > The body text around Figure 3 indicates that mutual authentication > should be depicted, but the figure shows only normal server-only > authentication. > > The example in Figure 8 needs a TLS CertificateRequest in there in order > for the rest of the flow to make sense. > > Section 2.1.4 says that "TLS warning alerts generally mean that the > connection can continue normally and does not change the message flow." > but this is no longer true with TLS 1.3 -- the only alerts sent at > warning level are "close_notify" and "user_cancelled", both of which > indicate that the connection is not going to continue normally. > > Section 2.1.9 claims that the largest size of a TLS record is 16387 > octets, but by my count a TLSCiphertext can get up to 16643, since the > length field "MUST NOT exceed 2^14 + 256 bytes" (and there's the other 3 > bytes of header). > > Please also check the statements made about RFC 8446 that I note in my > comments on Section 5.1. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Some of these comments are a bit rough, as I did not do my full editing pass > since I plan to defer the ballot. I'm including them anyway as they still > seem likely to be useful even in this form. > > I strongly suggest that the option for the server to send an alert > instead of HelloRetryRequest in the case of missing "key_share" be > removed; see my comments on Section 2.1.3. As far as I can tell this > option is flat-out bad practice and should not be allowed. > > I also strongly suggest that the WG make the simple modification to the > key schedule that I suggest in my comments on Sections 2.3 and 5.5, that > would have the effect of achieving the property anticipated by Section > 5.5 of RFC 5216, whereby incorporating the EAP-TLS Type information into > the key derivation formula prevents a type of packet modification > attack. > > Abstract > > reduced latency when compared to earlier versions of TLS. EAP-TLS > with TLS 1.3 further improves security and privacy by mandating use > of privacy and revocation checking. This document also provides > > I agree with the secdir reviewer that some indication of what is meant > by (EAP) "privacy" here is likely in order. > > Section 1 > > In addition to the improved security and privacy offered by TLS 1.3, > there are other significant benefits of using EAP-TLS with TLS 1.3. > Privacy is mandatory and achieved without any additional round-trips, > > (ditto) > > Section 2.1.1 > > for resumption. SessionID is deprecated in TLS 1.3 and the EAP-TLS > server SHALL ignore the legacy_session_id field if TLS 1.3 is > negotiated. TLS 1.3 introduced early application data which is not > > (nit) we could perhaps quibble about whether "SHALL ignore" is > consistent with the RFC 8446 requirement to echo the legacy_session_id > value from the ClientHello in the ServerHello, though I'm not going to > make a big deal about it. > > used in EAP-TLS. A EAP-TLS server which receives an "early_data" > extension MUST ignore the extension or respond with a > HelloRetryRequest as described in Section 4.2.10 of [RFC8446]. > > It's probably better to place restrictions on the indication that early > data might be possible, than to (just) place restrictions on accepting > it. That is, if the server is forbidden from generating a > NewSessionTicket message that includes the "early_data" extension, then > the client is also forbidden from sending "early_data" in a ClientHello. > [ed. we do do this in 2.1.2] > > Section 2.1.3 > > full handshake. It is left up to the EAP-TLS peer whether to use > resumption, but it is RECOMMENDED that the EAP-TLS server accept > resumption as long as the ticket is valid. However, the EAP-TLS > > But the EAP-TLS server sets how long the ticket is valid :) > Should we give some guidance on how long that should be (noting that it > must say within the RFC 8446-mandated 7 day maximum). > > was used in the original full authentication. E.g. the NAI @realm > can safely be reused, while the NAI ZmxleG8=@realm cannot. The TLS > > (Does base64("flexo") have enough randomness to be reflective of a good > privacy NAI?) > > A subsequent authentication using resumption, where both sides > authenticate successfully (without the issuance of more resumption > tickets) is shown in Figure 3. > > (It's slightly surprising to show an example of resumption without > issuing additional resumption tickets, since such issuance is basically > necessary in order to comply with the recommendation from earlier in the > section to follow the client tracking prevention mechanisms in Appendix > C.4 of RFC 8446. Though I guess draft-ietf-tls-ticketrequests is > potentially relevant for just how necessary it is going to be in > practice.) > > back to a full handshake. If the EAP-TLS peer did not supply a > "key_share" extension when attempting resumption, the EAP-TLS server > needs to reject the ClientHello and the EAP-TLS peer needs to restart > a full handshake. The message flow in this case is given by Figure 4 > followed by Figure 1. > > Also during resumption, the EAP-TLS server can respond with a Hello > Retry Request (see Section 2.1.6) or issue a new ticket (see > Section 2.1.2) > > I don't understand why the "alert plus fresh handshake" flow is even > listed as an option -- AFAICT the HelloRetryRequest (note: no spaces) > flow is uniformly superior. There is no benefit in round-trip count to > starting a fresh handshake, and HelloRetryRequest allows the initial > interaction to be authenticated by the continued handshake transcript. > Aborting and starting over is analogous to the dreaded "downgrade dance" > that has periodically plagued the TLS ecosystem, and I'm confused that > we would consider encouraging it to return. I would instead say that > the server "needs to send HelloRetryRequest to signal that additional > information is needed to complete the handshake, and the EAP-TLS peer > needs to send a second ClientHello containing that information" (or > similar), and drop the "Figure 4 followed by Figure 1" sentence. (The > final paragraph would then become a bit redundant, but perhaps there is > still some information that should be persisted.) > > Section 2.1.4 > > The two paragraphs below replaces the corresponding paragraphs in > Section 2.1.3 of [RFC5216] when EAP-TLS is used with TLS 1.3 or > higher. The other paragraphs in Section 2.1.3 of [RFC5216] still > apply with the exception that SessionID is deprecated. > > If the EAP-TLS peer authenticates successfully, the EAP-TLS server > MUST send an EAP-Request packet with EAP-Type=EAP-TLS containing > TLS records conforming to the version of TLS used. The message > flow ends with the EAP-TLS server sending an EAP-Success message. > > If the EAP-TLS server authenticates successfully, the EAP-TLS peer > MUST send an EAP-Response message with EAP-Type=EAP-TLS containing > TLS records conforming to the version of TLS used. > > Just to walk through the various scenarios here; if the last message of > the TLS handshake for a given TLS version is sent by the TLS client, that > will go in an EAP-Response, so the server is then able to send > EAP-Success directly. On the other hand, if the last TLS handshake > message is sent by the server, that will have to go in an EAP-TLS > EAP-Request, and so the peer will have to send an empty EAP-TLS response > in order for the server to be able to wend EAP-Success? Do we need to > have any text here to handle that empty EAP-TLS Eap-Request case? > > In the case where the EAP-TLS server rejects the ClientHello with a > fatal error, the conversation will appear as shown in Figure 4. The > > Should we perhaps say that these examples are with TLS 1.3, even if the > actual normative protocol is no longer tied to a specific TLS version? > > Section 2.1.5 > > In some sense, this figure depicting the no-peer-authentication case is > just an example specific to TLS 1.3 and is not necessarily > representative of the generic EAP-TLS case for potential future versions > of TLS. Should we make that more clear from the prose? > > Section 2.1.6 > > the handshake. One use case is if the EAP-TLS server does not > support the groups in the "key_share" extension, but supports one of > > I'd consider adding a parenthetical "(or there is no "key_share" > extension)". > > Section 2.1.8 > > username in cleartext in the Identity Response. Following [RFC7542], > it is RECOMMENDED to omit the username (i.e. the NAI is @realm), but > other constructions such as a fixed username (e.g. anonymous@realm) > or an encrypted username (e.g. YmVuZGVy@realm) are allowed. Note > > (I note that YmVuZGVy is just base64("bender"); does that really count > as "encrypted"?) > > Section 2.3 > > The use of a constant 0x0D (the "Type-Code") as the TLS-Exporter context > is rather unusual; per RFC 8446 this value is intended to be a > "per-association context value provided by the application using the > exporter" per RFC 5705 -- this value is not a per-association value but > rather a global one. > > Section 2.4 > > While EAP-TLS does not protect any application data except for the > Commitment Message, the negotiated cipher suites and algorithms MAY > be used to secure data as done in other TLS-based EAP methods. > > This makes me uncomfortable -- is this other data being secured going to > live in the same "namespace" as the Commitment Message? > > Section 2.5 > > and TLSPlaintext.fragment = 0x00). Note that the length of the > plaintext is greater than the corresponding TLSPlaintext.length due > > (This sentence reads oddly; perhaps "length of the TLSInnerPlaintext" is > more clear? But we shouldn't be saying this at all, per the Discuss.) > > Section 5.1 > > [2] Confidentiality: The TLS 1.3 handshake offers much better > confidentiality than earlier versions of TLS by mandating cipher > suites with confidentiality and encrypting certificates and some of > the extensions, see [RFC8446]. When using EAP-TLS with TLS 1.3, the > > I note that there exist codepoints for TLS 1.3 ciphersuites that do not > provide confidentiality protection. Please point to the part of RFC > 8446 that mandates this behavior. > > [3] Key strength: TLS 1.3 forbids all algorithms with known > weaknesses including 3DES, CBC mode, RC4, SHA-1, and MD5. TLS 1.3 > > Where does RFC 8446 forbid 3DES? CBC is forbidden by the requirement to > be AEAD, and RC4 and MD5 are explicitly forbidden, but the situation for > SHA-1 is more subtle. Please reword this sentence to be accurate. > > Section 5.4 > > When EAP-TLS is used with TLS 1.3, the revocation status of all the > certificates in the certificate chains MUST be checked. > > What does this mandatory checking entail when a certificate contains > neither a CRL Distribution Point nor an OCSP responder URL? (See also > the recent thread on the LAMPS WG list with Subject: "The > id-ce-noRevAvail extension".) > > TLS, see Section 4.4.2.1 of [RFC8446]. In TLS 1.3 the OCSP > information is carried in the CertificateEntry containing the > associated certificate instead of a separate CertificateStatus > message as in [RFC4366]. This enables sending OCSP information for > > RFC 4366 seems like a stale (obsolete) reference, and RFC 6066 should be > preferred. (RFC 4366 would then become an unused reference, I believe.) > > To enable revocation checking in situations where EAP-TLS peers do > not implement or use OCSP stapling, and where network connectivity is > not available prior to authentication completion, EAP--TLS peer > implementations MUST also support checking for certificate revocation > after authentication completes and network connectivity is available, > and they SHOULD utilize this capability by default. > > If it's RECOMMENDED to use OCSP stapling, what does it mean that they > "SHOULD utilize this capability by default" (as well)? > > (Also, nit: only one '-' in EAP-TLS.) > > Section 5.5 > > It seems like there may be some scope for improvements on the RFC 5216 > behavior here. For example, what if we used the EAP Type field as the > TLS Exporter 'context' argument, instead of the literal 0x0D? That > seems like it would prevent the modification from successfully causing a > different TLS-based EAP method to be used, by using a different > key-derivation formula, exactly as postulated by RFC 5126. > > Section 5.7 > > and the authorizations of the other party may have been reduced. If > the cached revocation is not sufficiently current, the EAP-TLS peer > or EAP-TLS server MAY force a full TLS handshake. > > nit: s/cached revocation/cached revocation data/ > > in the certificate chain has been revoked or has expired. In all > such cases, resumption results in a full TLS handshake instead. > > nit: s/resumption results/an attempt at resumption results/ (or similar) > > If any authorization, accounting, or policy decisions were made with > information that have changed between the initial full handshake and > resumption, and if change may lead to a different decision, such > decisions MUST be reevaluated. It is RECOMMENDED that authorization, > accounting, and policy decisions are reevaluated based on the > information given in the resumption. [...] > > I'm not sure I understand how these two sentences fit together. Is it > trying to say that "if there could be a different decision, you > definitly have to re-check, and we recommend just always re-checking > since that's timpler"? > > Where a good decision is unclear, EAP-TLS servers SHOULD reject the > resumption. > > I suggest "reject the assumption and continue with a full handshake". > > Section 4.2.11, 8.1, and 8.2 of [RFC8446] provides security > considerations for resumption. > > I'm curious why specifically 8.1 and 8.2 were selected, given that 8 > as a whole is about "0-RTT and Anti-Replay", which is a more specific > topic than just resumption. > > Section 5.8 > > Tracking of users by eavesdropping on identity responses or > certificates is a well-known problem in many EAP methods. When EAP- > TLS is used with TLS 1.3, all certificates are encrypted, and the > username part of the identity response is always confidentiality > protected (e.g. using anonymous NAIs). [...] > > As written this applies to server certificates as well as TLS client > certificates. For which the statement is technically true, but with the > caveat that it is typically easy to persuade the server to (re-)send > those same certificates encrypted to a key known to the attacker, so the > protection provided by the encryption is limited. (The server has been > fairly strongly authenticated by the time the EAP peer makes the > decision to send its certificate, so there the reverse situation is > different.) > > and only using the pseudo-random usernames a single time. Note that > the privacy-friendly usernames also MUST NOT include substrings that > can be used to relate the identity to a specific user. Similarly, > privacy-friendly username SHOULD NOT be formed by a fixed mapping > that stays the same across multiple different authentications. > > I think that violating the SHOULD NOT would intrinsically violate the > preceding MUST NOT ... so should they both be MUST NOTs? > > static RSA based cipher suites without privacy. This implies that an > EAP-TLS peer SHOULD NOT continue the handshake if a TLS 1.2 EAP-TLS > server responds to an empty certificate message with a TLS alert > message. > > Just to check my understanding, this "response" would be an EAP-TLS > response containing a new ClientHello (that would proceed to do a > handshake including the client certificate in the unprotected initial > handshake)? That is, it would be a response at the EAP layer but not at > the TLS layer. > > Section 5.9 > > Pervasive monitoring refers to widespread surveillance of users. In > the context EAP-TLS, pervasive monitoring attacks can target EAP-TLS > > nit: "context of" > > Section 5.10 > > summarizes the attacks that were known at the time of publishing and > [RFC7525] provides recommendations for improving the security of > deployed services that use TLS. However, many of the attacks are > > Using BCP195 as the slug is probably preferred, since any RFCs > associated with the BCP are going to be relevant and topical. > > > From nobody Wed Dec 16 16:23:59 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 518003A0E70; Wed, 16 Dec 2020 16:23: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 hlqtW30bgSLd; Wed, 16 Dec 2020 16:23:51 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 304243A09F5; Wed, 16 Dec 2020 16:23:49 -0800 (PST) Received: from [192.168.46.129] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 1E13153E; Thu, 17 Dec 2020 00:23:46 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Alan DeKok In-Reply-To: <160815821055.25925.15897627611548078426@ietfa.amsl.com> Date: Wed, 16 Dec 2020 19:23:45 -0500 Cc: The IESG , draft-ietf-emu-eap-tls13@ietf.org, emu-chairs@ietf.org, emu@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5E174CB1-9C9E-4DF2-A377-72550E89B50A@deployingradius.com> References: <160815821055.25925.15897627611548078426@ietfa.amsl.com> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Emu] Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2020 00:23:54 -0000 On Dec 16, 2020, at 5:36 PM, Benjamin Kaduk via Datatracker = wrote: > To start with the easy one: currently the way in which the structure = of > the Commitment Message is described makes reference to many fields of > TLS Record Layer structures in order to specify what is fundamentally = a > message on the TLS Application Data stream. This is a layering > violation; I don't see any reason to say more than what was suggested = in > https://mailarchive.ietf.org/arch/msg/emu/ECgvnq-C_VVXT5bpvOowte8LBjw/ = : I will wave a magic wand of "implementation issues". :( There appears to be few ways to *explicitly* signal that negotiation = has completed. i.e. ways which are both implemented in SSL libraries, = and available to EAP-TLS implementations. We implemented multiple ways in FreeRADIUS (0 octet of application = data and other methods). I'll have to double-check the list archive. = But my recollection is that the "0x00" of application data was the least = ugly alternative. > Next, the whole reason for the existence of a Commitment Message seems > under-justified -- the only mention I could find in the document is = that > it serves "to decrease the uncertainty for the EAP-TLS peer". What = harm > would be caused by a lack of certainty in this area? Why does waiting > for an EAP-Success or EAP-Failure not provide a similar level of > certainty? The EAP-Success and EAP-Failure messages are *not* protected. i.e. = they are 4-bytes of data which can be spoofed rather trivially. In contrast, the 0 byte is an application-layer signal that EAP-TLS = has succeeded. > The commitment message as specified seems to itself be a layering > violation. The TLS protocol itself consists of a few sub-protocols, > e.g., the handshake protocol, record protocol, and alert protocol. = The > operation of the handshake protocol is supposed to be completely > independent of the application-data record protocol (except to the > extent that the handshake protocol supplies the keys used for > cryptographic protection of application data records). In particular, > there should not be any interaction between the handshake state = machine > and the application data. If there is to be a commitment made about = the > operation of the TLS handshake protocol, that more properly belongs in > the handshake layer itself, or perhaps the alert layer if it relates = to > the overall operation of the TLS connection. It seems inappropriate = and > unsustainable to expect that an application-data message would affect > the operation of the handshake layer. IMHO, it doesn't affect the TLS-layer handshakes. It's a signal = specific to EAP-TLS, which is an application using TLS. > The use of application data for the commitment message also may have > unfortunate interactions with other TLS-using EAP methods, which is = very > briefly mentioned as a possibility but not explored at all: I have a draft on precisely this issue. We have implemented TLS 1.3 = for TTLS and PEAP (hostap && FreeRADIUS). Where they send application = data, there is no need for a commitment message. The EAP method sends = it's own application data. Where the methods don't send application data (i.e. session = resumption), they have the same problem as EAP-TLS, and require a = similar solution. In general, a number of your comments here conflate EAP-TLS with other = TLS-based EAP methods. This document specifies a standard for EAP-TLS. = It doesn't apply to other methods. There are similar issues for other = methods, but those methods require method-specific solutions. > Section 2.3 >=20 > The use of a constant 0x0D (the "Type-Code") as the TLS-Exporter = context > is rather unusual; per RFC 8446 this value is intended to be a > "per-association context value provided by the application using the > exporter" per RFC 5705 -- this value is not a per-association value = but > rather a global one. The existing TLS-based EAP methods have consistently used exporters = which are global. I'm not even sure what would be used for per-association value. This = is EAP, there is generally no underlying transport method (or data) = which is consistently available to the EAP layer. i.e. Can you suggest a per-association value which would *work* for = EAP? Across RADIUS, Diameter, PANA, ... > Section 5.5 >=20 > It seems like there may be some scope for improvements on the RFC 5216 > behavior here. For example, what if we used the EAP Type field as the > TLS Exporter 'context' argument, instead of the literal 0x0D? The EAP-Type field is 0x0D for EAP-TLS. This value is hard-coded for = EAP-TLS. For other EAP types, the use of the field is clarified here; https://tools.ietf.org/html/draft-dekok-emu-tls-eap-types-00 i.e. this document specifies EAP-TLS, and does *not* affect other = TLS-based EAP methods. Those are defined elsewhere. > That > seems like it would prevent the modification from successfully causing = a > different TLS-based EAP method to be used, by using a different > key-derivation formula, exactly as postulated by RFC 5126. I think there's a misunderstanding here. This document specifies = EAP-TLS. It doesn't specify how other TLS-based EAP methods use TLS = 1.3. The discussion in the WG, and implementations guided this approach. = This document species EAP-TLS. The above referenced document "patches" = this one in order to specify the use of TLS 1.3 with other TLS-based EAP = methods. > If any authorization, accounting, or policy decisions were made with > information that have changed between the initial full handshake and > resumption, and if change may lead to a different decision, such > decisions MUST be reevaluated. It is RECOMMENDED that = authorization, > accounting, and policy decisions are reevaluated based on the > information given in the resumption. [...] >=20 > I'm not sure I understand how these two sentences fit together. Is it > trying to say that "if there could be a different decision, you > definitly have to re-check, and we recommend just always re-checking > since that's timpler"? Pretty much, yes. Alan DeKok. From nobody Wed Dec 30 22:11:41 2020 Return-Path: X-Original-To: emu@ietf.org Delivered-To: emu@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 511F73A0D79; Wed, 30 Dec 2020 22:11:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Erik Kline via Datatracker To: "The IESG" Cc: draft-ietf-emu-eap-tls13@ietf.org, emu-chairs@ietf.org, emu@ietf.org, Joseph Salowey , joe@salowey.net X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Erik Kline Message-ID: <160939509976.27231.38708696001514029@ietfa.amsl.com> Date: Wed, 30 Dec 2020 22:11:40 -0800 Archived-At: Subject: [Emu] Erik Kline's No Objection on draft-ietf-emu-eap-tls13-13: (with COMMENT) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 06:11:41 -0000 Erik Kline has entered the following ballot position for draft-ietf-emu-eap-tls13-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [[ nits ]] [ section 1 ] * s/and and/and/ [ section 2.1.7 ] * "Many client certificates contains" -> "Many client certificates contain" [ section 5.4 ] * s/EAP--TLS/EAP-TLS/ [ section 5.9 ] * "In the context EAP-TLS" -> "In the context of EAP-TLS"?