Re: [Ace] Charter discussion

"Brockhaus, Hendrik" <hendrik.brockhaus@siemens.com> Wed, 04 November 2020 17:38 UTC

Return-Path: <hendrik.brockhaus@siemens.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 415333A0A4A for <ace@ietfa.amsl.com>; Wed, 4 Nov 2020 09:38:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.267
X-Spam-Level:
X-Spam-Status: No, score=-0.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, LH_URI_DOM_IN_PATH=1.533, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.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 E-T5dMeR-0WP for <ace@ietfa.amsl.com>; Wed, 4 Nov 2020 09:38:32 -0800 (PST)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20040.outbound.protection.outlook.com [40.107.2.40]) (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 978E93A0DD6 for <ace@ietf.org>; Wed, 4 Nov 2020 09:38:31 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Tlgr+CNFkei0ufWbcjrIeTcIdMcW4quaOdYpUbZ2S/cDeBmtzCqb9CK1ZDEAxfR+ZsU1TLPlhFZYEIAsKtAYuAe03izwm/5rrvcJhDaKgG0bJdqYnBztNfSf952m4Cb2Rtdn5aNL1hGkmRvI1/Bph6Dw8PWbKUC1zOcsq+DmMXNEM4+xlV7+d4xHmK3za+MbWJ1wJlXAuODiWzuDrz0X99ETg+76LhvmHXezbFwFkEVnr0qAnKWZt98LpDthfL2mf1sWrPdP/ZZrcAqjpfDbGH9KnOlL5CpkgmuVNfGw+qzza4liQRfqR8K6rHfnlAaTAKXYWC7ijrsJNEId2ihdTw==
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=RzoJjl8KQYXCtKmvHZgNibi1h8KqT0e6DbJUtD1oDnI=; b=RGTTkYqCBd7Ldlm3JPeZr6AtKZ2/2btk9WadyhrwYKYA6oMAghEz1ToMmE7xu2xwAuIQ8O6K3ao38bHLKAe20SGbLeHzAv+440OjggtFiunqe1DesIa4qrUxVNlkZYXrZDYSdgaO27nfeiK5aJkXrx6FEZsj4XY15Ptg8XxF1vhIc2tHryEPcUC+z6MGbAb5ZT251nNFCjcm0puVKX0Tnw6gUgj4hKVDk3MboqGOyiktvRSMF8OAEREN7/Yc2Dfg8Bm/vLy1rAcaPWliwdjQRBKsFXrxyxuW4Bq3i0zdoqLMRdxiBF+3WG37se4UfsTTi5em5OjwzLKCoLo8hBVh9w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RzoJjl8KQYXCtKmvHZgNibi1h8KqT0e6DbJUtD1oDnI=; b=irMA5IR7Arclfopn110Df8pqpSnErSVPdmaIFhSCBt1DEgaRTHr4X8Wpze832XaTz5NAg6JvcNHfBL/ToWpE/EyN793w6YlUvq3+b7YKUTpIogu3XBOj2Bd3d5LGwiFJB88cUZRZIHlAQBR+Y3YQVf3NmuLY6WBuJEZdawtl/tg=
Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:dd::17) by AM0PR10MB3473.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:151::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.27; Wed, 4 Nov 2020 17:38:29 +0000
Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::48d8:f723:944:efe6]) by AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::48d8:f723:944:efe6%6]) with mapi id 15.20.3499.032; Wed, 4 Nov 2020 17:38:29 +0000
From: "Brockhaus, Hendrik" <hendrik.brockhaus@siemens.com>
To: Ace Wg <ace@ietf.org>, "Panos Kampanakis (pkampana)" <pkampana@cisco.com>
CC: =?iso-8859-1?Q?G=F6ran_Selander?= <goran.selander=40ericsson.com@dmarc.ietf.org>, Daniel Migault <mglt.ietf@gmail.com>
Thread-Topic: [Ace] Charter discussion
Thread-Index: AQHWoxtjVCYB49eUE0iMxKcy60l0Nam2S5IAgAElX4CAAOWqsA==
Date: Wed, 4 Nov 2020 17:38:28 +0000
Message-ID: <AM0PR10MB24188423CC124E1F9333EB50FEEF0@AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM>
References: <CADZyTkmnV_Dhb5iXzykUyEAskLDg7tj=80CbEBGmSyFQNS2FHw@mail.gmail.com> <HE1PR0702MB3674F5E7C6044443418E8B1BF4110@HE1PR0702MB3674.eurprd07.prod.outlook.com> <BN7PR11MB2547BF9B877E80FB9E1E7DBBC9EF0@BN7PR11MB2547.namprd11.prod.outlook.com>
In-Reply-To: <BN7PR11MB2547BF9B877E80FB9E1E7DBBC9EF0@BN7PR11MB2547.namprd11.prod.outlook.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-11-04T17:38:27Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=0f00faf7-57af-42d5-adb4-13a82fe72761; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0
document_confidentiality: Restricted
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=siemens.com;
x-originating-ip: [165.225.200.147]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 04183e94-63a5-4ed3-36be-08d880e8710a
x-ms-traffictypediagnostic: AM0PR10MB3473:
x-microsoft-antispam-prvs: <AM0PR10MB3473A7BE833889AD8DFAB39BFEEF0@AM0PR10MB3473.EURPRD10.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: qeNCdX6z65Y0/4n1svf46JxhG1m9zuDVrfCkIdr5+0lMA6x1FgDfH4/zEXQZ7trcaVNyepQu7UJm4qA3VcHoaWgKwvQY3/YVCBApgF2yXBZ/LnnPV6pw5G8DB6pG+W7aiXq0r6E7s/6sssRfo592K2kPOcgYEk3+70/PFhWsU5TphhPgCiqBR4uxczc/nMCPZq9ejNyG7SSFqanXzw73oWPIUj0YlfAUhhpd/98+lIWX/w/A3ZpZXHSdq5QLTwt3IfSSVJwgyOZYmDokCukTXD9JxzW968V97P3gg0rYrr5cwUN2/OsLnjmSShcAER5RQAiINFM1fVf9xAC9/xLXAfxDUfZ/bMA0XM/gjaQpdenTpRvuVEPfkClsio67fvSr5vVs2nyVA9AyofL6epzZ+w==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(136003)(39860400002)(346002)(376002)(66946007)(76116006)(53546011)(55236004)(54906003)(110136005)(64756008)(966005)(66556008)(6506007)(9686003)(71200400001)(86362001)(316002)(8936002)(66574015)(66476007)(55016002)(66446008)(186003)(2906002)(5660300002)(26005)(7696005)(8676002)(4326008)(83380400001)(4001150100001)(33656002)(478600001)(52536014)(166002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: fxMpsic351KnjNl4xDOiXwm+5Irc8KHGKN3CuvTqTOHWIWradVMolmibn2ZA3xOYEnPvJD3NGkekCVbm7SLT/fGBcqSjsR6h2OYzzd0e4yKZRg3xVRPgzFa4RSS3yGyr+UTPMYrBgfKKU5tfjGKneBmYi8tUbNqRXqTcUkLqnRaqsuWqoAHpeYqyjtJR0YyEzBqm0wZOTkXYpSJmM2BMtr5/LTiJaym1qyfkgzaxLSofeg2L/aJttYzb+n47hcC4gxBnZGRgq3ZxpeFusL6PyIRJpo80MnnD87InzcyzUKSenck+z81SbUe5S7O5jRRHHcBBvC0MCp2EC+478zgPRGnFLE6zJenuIeW2jlpheJ9HXbTSTsHqjyY33zlD09h7VObo0LcRttOinBa9bjNQkbuQy+asSXTL5lOx+35NoObYiFwc+Y06doF+nT5vSRXh55LSapHnfol6l4ue4CaTyBbaQ+87rJ8klYqLj3WX8kG8pqkRPVEfj+5fJzDFR6ebLkVauXmehULPiZysQV88V4UahxSlS/Es3JO6zI1mC1zOsrMMHKrGuMH8rp63G+jbIcC2rFhHFwnRmoe5YrbqyjuQI0HgRYY1T1WhSPCR4RNcxozB0YZiQei/h7JJBEa/iMc/Yog95pM16gUY1NWyDA==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_AM0PR10MB24188423CC124E1F9333EB50FEEF0AM0PR10MB2418EURP_"
MIME-Version: 1.0
X-OriginatorOrg: siemens.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 04183e94-63a5-4ed3-36be-08d880e8710a
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2020 17:38:28.8878 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 1bO5V46DunVlWEOr4PVvbk/ddMQAlBAJ7Vqk0vx097t1YlpEAPjcqlrMkmWiu3+lMx0y1ImaiTAl1IIAud53qSnW+RG+4berigIa4AW/Lxs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB3473
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/bcP5yNJeotlsZCNFv7s85xbMqB8>
Subject: Re: [Ace] Charter discussion
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Nov 2020 17:38:34 -0000

Panos, thank you for explaining you position. I understand that you support EST. I already expressed my position and arguments in favor of CMP. :-)
As you see the authentication provided by binding the CSR to the TLS handshake as a pro of EST, I see in many environments exactly this as a drawback of EST and a pro of CMP having all needed security on the application layer. I do not see, why this should not be valid when using CoAP instead of HTTP.
As already pointed out, I do not believe we can address all requirements out there by one certificate enrollment/management protocol.

Important from my perspective is, as Panos also says, there are currently four votes in favor and only one clear vote against the adoption. Or did I miss further votes?

Hendrik

Von: Ace <ace-bounces@ietf.org> Im Auftrag von Panos Kampanakis (pkampana)
Gesendet: Mittwoch, 4. November 2020 04:36
An: Göran Selander <goran.selander=40ericsson.com@dmarc.ietf.org>rg>; Daniel Migault <mglt.ietf@gmail.com>om>; Ace Wg <ace@ietf.org>
Betreff: Re: [Ace] Charter discussion

I support the addition of draft-selander-ace-coap-est-oscore in the Charter as it introduces OSCORE with its advantages in constrained environments for EST which is already standardized in EST-coaps in ACE.

As I have said before, I oppose the addition of CMPv2 over COAP in the charter. Summarizing the reasons here again for brevity:
- we should not repeat the mistakes of the past and introduce multiple protocols doing the same thing (cert enrollment or management) over COAP unless there is a compelling reason. To answer your other question Daniel, I don't think we need a new certificate management protocol at this stage.
- I am not convinced of the technical advantages of using CMPv2 over COAP in constrained environments.
- I have not seen overwhelming support for the draft in the list other than Michael saying "why not" and Steffen and Hendrik (from Siemens) clearly supporting it. Also, minutes from IETF-108 say "DM: Objections to doing this work? No objections registered". I was not there to oppose, but I would not call that overwhelming active support either.
- it is not clear who intends to use and implement the draft. If it is a one or two vendor thing then I don't think ACE should spend the cycles. I have not seen many people chiming in that want to the draft and are willing to review.

Rgs,
Panos


From: Ace <ace-bounces@ietf.org<mailto:ace-bounces@ietf.org>> On Behalf Of Göran Selander
Sent: Tuesday, November 03, 2020 5:06 AM
To: Daniel Migault <mglt.ietf@gmail.com<mailto:mglt.ietf@gmail.com>>; Ace Wg <ace@ietf.org<mailto:ace@ietf.org>>
Subject: Re: [Ace] Charter discussion

Hi Daniel, and all,

Some comments on the proposed charter and your mail, sorry for late response.

1.
"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"

I take it this text covers (should the WG want to adopt):


  *   draft-tiloca-ace-group-oscore-profile
  *   an ACE-EDHOC profile (i.e. the POST /token response and the access token provision information to support authentication with EDHOC, e.g. raw public key of the other party). Such a profile could provide good trust management properties, potentially at the cost of a larger access token etc.

Right?

2.
"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."

As I remember it, the outcome of this discussion was - in line with the mindset of EST - that it is beneficial to re-use authentication and communication security appropriate for actual use case. If coaps is suitable for a particular use case, then it makes sense to protect also the enrolment procedure with this protocol. But whereas the security protocol is coaps instead of https, the enrolment functionality and semantics should reuse that of EST, possibly profiled for the new setting: [4].

In the same spirit there was support at the meeting [2] to specify protection of EST payloads profiled for use with OSCORE as communication security protocol, together with a suitable AKE for authentication. Following the adoption of EDHOC in LAKE this work has now been revived [5]. IMHO the reasoning above still makes sense.

With this in mind, and taking into account recent discussion on the list, perhaps this part of the charter:


"The Working Group will standardize how to use Constrained Application Protocol (CoAP) as a Transport Medium for the Certificate management protocol version 2 (CMPv2).   "

should be rephrased or complemented with the reasoning above, for example:

The scope of the Working Group includes profiles of the Enrolment over Secure Transport (EST) transported with the Constrained Application Protocol (CoAP)"

Thanks
Göran

[4] https://tools.ietf.org/html/draft-ietf-ace-coap-est<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-ace-coap-est&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C27193ea305fb4be4501e08d88072ca26%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637400577806351097%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Nd0%2B2%2B9QCiQX905x8eeFATC2s5nxgvPElL%2FEd3x9zHc%3D&reserved=0>
[5] https://tools.ietf.org/html/draft-selander-ace-coap-est-oscore<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-selander-ace-coap-est-oscore&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C27193ea305fb4be4501e08d88072ca26%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637400577806361092%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=FhwPXjvDW%2Fio6WdTN8ca5sMYx754V7332qxGNjrCdQE%3D&reserved=0>




On 2020-10-15, 19:50, "Ace" <ace-bounces@ietf.org<mailto: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] https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C27193ea305fb4be4501e08d88072ca26%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637400577806371088%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Wx02SgrYvA%2BBaoqY8Cl6e1jQXY9IzDNSOekqSl7y9cc%3D&reserved=0> <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<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D4f3d9c3b-118c475b-4f3ddca0-86e2237f51fb-627e48b069462d70%26q%3D1%26e%3D6924b2a6-e7e5-4ec1-a1af-c94637953dc5%26u%3Dhttps%253A%252F%252Fdocs.google.com%252Fdocument%252Fd%252F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%252Fedit%253Fusp%253Dsharing&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C27193ea305fb4be4501e08d88072ca26%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637400577806371088%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=hN20xt76IQDFPFNENNE3kwJgFMWrFgh0N5m5Aib4Mx4%3D&reserved=0>>
[2] https://datatracker.ietf.org/doc/minutes-interim-2017-ace-03-201710191300/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fminutes-interim-2017-ace-03-201710191300%2F&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C27193ea305fb4be4501e08d88072ca26%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637400577806381083%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=oPHqgbrFmyVbHWeXzn4xmQLWh%2FPmXMS%2BpjrTPTWrmGo%3D&reserved=0>
[3] https://datatracker.ietf.org/doc/draft-selander-ace-eals/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-selander-ace-eals%2F&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C27193ea305fb4be4501e08d88072ca26%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637400577806391076%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=X4Fe%2B%2Bd0lSti0geRyNzXdINWAx3ym%2FS%2FO2zThQ0icKc%3D&reserved=0>

--
Daniel Migault

Ericsson