[Ace] Re: Iotdir telechat review of draft-ietf-ace-wg-coap-eap-11
Dan Garcia Carrillo <garciadan@uniovi.es> Tue, 12 November 2024 13:34 UTC
Return-Path: <garciadan@uniovi.es>
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 4A047C15108C; Tue, 12 Nov 2024 05:34:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3G5F9oBcSq8; Tue, 12 Nov 2024 05:34:53 -0800 (PST)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2132.outbound.protection.outlook.com [40.107.21.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 962BFC151087; Tue, 12 Nov 2024 05:34:47 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=eiPlemYihdTflUWD9wwy9UklUKBYDrgV2tJGfCQx4ZRliS0jKGm+nm1ocJCs2u8YqW/VYdSZF2eBLXphoRzswT8vD0XWS4mAEO8lvMMjNudcAV1XYXx5knTSzdAbyAGuZ/uX3y2l1zF0DwVB6gXXk+IVujK0mZVyrqyKYqu70C74aEi1cENbogXTKMW5fOVz4BZvyawPyXmNRj/KV+/6IL5P6LVZr/cGS8Xl8pW8jiWol89UCd0GOeoCGS2vrlm0zsuzXg9KHmdX2WLuhH2qc+Y38gAM+6+FHST8l/ggI7jSb7/bUGFcvtzwgHpCvLv4JNo8wP/7zYigxKLXOGH07Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=nZoagmhFI1RClZVm3SRfW/gyiuNGM1o2UlqdXKSQSj4=; b=bWpspDYYA578vAu/ov6gAm2aBJCG1F4pLmjySAynFaT1DXkUxhFStd9MtzJUlJ7kpSYmf59vVKtk2Zn0QVObqohi57z72n6iFqFgv/nxwl27uUt5arGXKaHzAbqWo7vqOCnLQGubKmLJRKICJamWwi95/2CjCi5MSkdJVkZ6wUgaiDo78xVDOzqCos0NUl4fDGrk8Ps18wzv7ANdhBfsEkz47osB/RmKTQzLJLutoAqJslb0IUMgicBqfVn4o8vtQaymmHV9C7vA6kBQBJNWZijlNE2VfKCDbmM8jm6SfYelJizK7tPXpMTIjUKXAVN69XfHcKHilNodfPY19kQUoA==
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=nZoagmhFI1RClZVm3SRfW/gyiuNGM1o2UlqdXKSQSj4=; b=tOYXfQzTcEQb4x2mlGdfvcIeSEGkIIZSnYyzbaJ8+78v9kR+JsN8GCxQ14FkHD/t0LLnQibN7Llu4gHGcTkPCF9k+ueAwGB6fMP7lDatbv0Mg5YjZ0Ftt7MqaE+94acOleBw/Kwhdryt2L+nq9xUAsJ5W3+DNOaoVmlCKb4FAOk=
Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=uniovi.es;
Received: from AS4PR08MB8093.eurprd08.prod.outlook.com (2603:10a6:20b:588::18) by PAXPR08MB6350.eurprd08.prod.outlook.com (2603:10a6:102:12c::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8137.29; Tue, 12 Nov 2024 13:34:45 +0000
Received: from AS4PR08MB8093.eurprd08.prod.outlook.com ([fe80::efad:bcac:47a9:6619]) by AS4PR08MB8093.eurprd08.prod.outlook.com ([fe80::efad:bcac:47a9:6619%6]) with mapi id 15.20.8137.027; Tue, 12 Nov 2024 13:34:45 +0000
Message-ID: <3dd23b05-c5fc-4272-ad00-148303376151@uniovi.es>
Date: Tue, 12 Nov 2024 14:34:43 +0100
User-Agent: Mozilla Thunderbird
To: Eliot Lear <lear@cisco.com>, iot-directorate@ietf.org
References: <172935977050.1659683.6054585480632855805@dt-datatracker-78dc5ccf94-w8wgc>
Content-Language: en-GB
From: Dan Garcia Carrillo <garciadan@uniovi.es>
Organization: Universidad de Oviedo
In-Reply-To: <172935977050.1659683.6054585480632855805@dt-datatracker-78dc5ccf94-w8wgc>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P265CA0128.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2c6::16) To AS4PR08MB8093.eurprd08.prod.outlook.com (2603:10a6:20b:588::18)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS4PR08MB8093:EE_|PAXPR08MB6350:EE_
X-MS-Office365-Filtering-Correlation-Id: a05f0a01-5d26-4fdd-71e5-08dd031ec52d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016;
X-Microsoft-Antispam-Message-Info: /1aoKe5+0EtJxQ+NP/4bcM8hLUNLtd9rqxj6flmtu1TBD8FU3Qb0taYEOzJJVMpystVnhuyN1mRENoTT0xa/IWOkmuYTmRtCtzzHj3fIxUSXPWlNQl85VJhiCdhNsJOtIi/C42uPI5k12jv6CXQvS3etqBf6Xs9go64rclY0XrhVkkQvYPnryMRz6A4AkJLJU3xFQYlYree/NZ/WPYi4o57FlQmRF5b2khRfIfjV5sVLvZ/dUK/Oj1KwnuFwAU47375W+Kpg2NwuOdiE/Qi2eRLDRM3QzD3XECDhuV+P2P/FtDYixCQBR1e5jSVPtjpFIxKsizwuj00jowG3hsheV2TMAfLs2Bw9u7EKAUP500TS97zWqONbiM0VfzqFqbcPAETkM3qOEUZUr5eeccjs+FdT6redMJ5FhTVVQbuFCsvhbWR80n+UNdEzuahgTRnYZqT0cXN61htnYdqvJfjze4JhDVAwrGVv7dU81utlECOG/0Uu2Jz0KkcV6yTgHxAtYvg432hZgMIeBhQ/3JEnL0EgmJSfbAEYbNzPTIwI5UZbUnjbm3OEGu9YF+jqpLBlJ1T2VrHfjX/V3ODsNdi6ReqJ3j1VEizl2ryxHvrlsrWxIm0mt3ql5meBeR82JvNBEZal8VahNPCzYA76sbNvkOfIW8J/HVnqMUI+FUnGZlUjJ9HP9Hq0EzJsRRB8Rpna/Ah26LanCt6emxGqc7wKuh2fOctWEEnVa8PxnnlqzYnpVi4hUzZeSBKjZKyV6qyVcd3vtDVbsC3s0Nm2jgnoEAcvSnNTCyKqlkbMAzvQkT4FgZ7Xiz8E8huQTXaWfwU22cp6ehTmSRuij/AZNa+wICQUa9Bc3h4UISGxMnAiNp/AWDg3rD6i6bihI8SFDOz35wtbIorqMSInvfbz9uFps4Pe0x43tiEM3XQaR0osxNrOdWymuaDLO0SkBrTV2JjJxUhtFZvHMk3UnAoA4B88zQuLBAV3nbPp5ves/qlCcTtMbjVaaAwsxJmglwK6+9orkCJYr0yDwoZYqBuLUB6psfdqIAA4McC9KmFaxCob1cqhK0Ynai6QdyAyBsH5/2NpBKrRPFRaz1tMZiYfWsQVyfG94QEOpU7i3QB2GXVumAPZyZIK4b9sAZ5qPa1A7P1+okB12Aw1fInN1AVvEUVwZ5d6vn93R6gsVG3G9qMNbnTXNhwuoY7n6ctcjWcSd6k5a6sJhU5F2Zqr1FntaNNN80uZvFPK2XrGDK2M12CAwrokdfGfKWPPsznAfEyLJkYEzQHepccslPwDbjaziUnvqsFehL5rqthIZH4Dn43LO1Q1gGGlXV5mC/ecE/o9p/CR
X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS4PR08MB8093.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: MRRZuvisUpMgt/5ix4m5Yhv/rxWKf+R+HaQbDfjL+W3x6/DDye5HqfR+3SRtJnP2XFsA92hIFaVGgBJZW/aHxy04n5tHfsYMljVenzp7c30zzrimA1CKUXYmdQQuNDEsBX6SaQ3WZR9d7spPXRJ2EX7ycq+zdee0sIRd4uRljHIEym66SQmgvcsOA5W8me4dC+n6GNfoU9/0c09MK9mifNIQeNkCiTWeq2qRRdkd4Uev4DXwMsDT0uzTZUUCcuwObouWPePczJRnY9NLnu8KO5vSA7p0ie7tJCNOaVOxUza+UZjWhmSFM7nHHW7yXnU8v/dkstuHki3LWESzdD5js/NuD9zlxzAsjPMa18Kwf2WJRv041+PrbuWw4j+sBLgxvpu+hvt+vo1tGGZzkfE/x1TdUD0VHyRvZDqs7N3y3zgEuXX5b3mZSwY7N/LZZuplg7jsz3p0gbyC/9tkW9NY5Y0HFzY/FwmUObWAdbTy+cDjIl5abZiDlNJzeDigucV4f1gQXAgsEWodhUbfiSuzl0FEczsNFpAhHnXKSLmUNlbG847Agryh51lccc+Zb4e2Acz1zz8Y82qTNvouMl2KKnO7+qrD1ikVAMmeUB5yyxX9+eOwPSMkBUF8wyfHl/2fxPZY8v4FEnyP7QDM3jto3dUmr3E2sxzLEQstuijm8LB6214eJxiOzyfo+F+VgI8GV9jCLLu989M5uVcgU4YvQdXqRiBtJVr9RhECObODLlNVzhbFBkfeQ3HIOg9PygF7VKGJ7OZMqX2jfqmWYkDRS2oPuDw6YPetSdFKFx6sw9evu+xJpxh280287bzg6M5Is/Yj11cttFuqdqrixQKFxmIlOQ6EVMj2HvibT+m/KC00nV8dtMQ3mp7t4rV0QPieEW82uHj/GqwZFD23TTDtBNr0j6UjdAF0jzKsyPIvONQOtOnFG7Z0B3y4m6nVV+S0BRSiMapt91dRAVb1QAlWeztXfLV2g/uED7sU1vWriUxRDGDmLAEXQjzzWoJDEkDRMclob+XHd/IpVTHfk6V79yULKB6JppQge3D2hQOEW0OVDjwEEtgLxyB5U+HQb/380LU6bt29Sx7rCxBaL3u2UHCAk2ejrmNLYQR3gb9BE7xaRYumP1U/jUoV/xRvB7Vb5ohtpsoIJ3HiOnH3tZh3iWaGx1mVWrWyUCfBKL1Ni2O2KvOQNLWB/HnKOhYe9XFL76DHX0cLw/T+faGPPv3B0ccEVaevKZGPOCJyopAywXjt7Y00zKK6U3wxWx6u6fTcJoE4GHAEiU5hbYe0Lb4yDWpiJnOPl9Xz2QBIjAt74Ci/w1nfV7u/VvtwOXuiLn9pWOXWgdeGge6q25wg9QdVHFz2RT3OCe6sbRJsBYx8QoM5vMU7zsuqtvU61q9vMqlVn3wgD/fxqN5cuMOQ9eqQWzCvvsm5Z/ldr7SVvg44yimZKgQx8phHKYQJaXlAGq/zwFS8EM13mtsYnpEwZ3XgPeviLmVMK+r+XzAiLEOQKCN2juohMQvI3Ls0/0w5bsCGy0+s6gTtYF5uFHhIX00nAJA1SsRSpJUZ3YH9XK75Z7Lh8vHR7UGs4O7ueVTZQDHC
X-OriginatorOrg: uniovi.es
X-MS-Exchange-CrossTenant-Network-Message-Id: a05f0a01-5d26-4fdd-71e5-08dd031ec52d
X-MS-Exchange-CrossTenant-AuthSource: AS4PR08MB8093.eurprd08.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Nov 2024 13:34:44.9778 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 05ea74a3-92c5-4c31-978a-925c3c799cd0
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: gVR+NhJsCARN4DrE5KNq/TjkV4chtFqbCWXu8byuFDy4s06zTMckUTlJ0LHXiGHcn1OXXYWLH5w0DVfiNe7HQQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR08MB6350
X-MS-Exchange-CrossPremises-AuthSource: AS4PR08MB8093.eurprd08.prod.outlook.com
X-MS-Exchange-CrossPremises-AuthAs: Internal
X-MS-Exchange-CrossPremises-AuthMechanism: 14
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: PAXPR08MB6350.eurprd08.prod.outlook.com
Message-ID-Hash: CMJXFFZSEOKK6UC42NCIX2A5BJXQFKSS
X-Message-ID-Hash: CMJXFFZSEOKK6UC42NCIX2A5BJXQFKSS
X-MailFrom: garciadan@uniovi.es
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ace.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: garciadan@uniovi.es, ace@ietf.org, draft-ietf-ace-wg-coap-eap.all@ietf.org, last-call@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Reply-To: garciadan@uniovi.es
Subject: [Ace] Re: Iotdir telechat review of draft-ietf-ace-wg-coap-eap-11
List-Id: "Authentication and Authorization for Constrained Environments (ace)" <ace.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/svEbX4JVCVqwTbypPnYqhqyAWBc>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Owner: <mailto:ace-owner@ietf.org>
List-Post: <mailto:ace@ietf.org>
List-Subscribe: <mailto:ace-join@ietf.org>
List-Unsubscribe: <mailto:ace-leave@ietf.org>
Dear Eliot, Thank you again for your review. After your e-mail we think we can consider the following cases: A) The node does not have an IPv6 address (non IPv6 connectivity) B) The node does have an IPv6 address (e.g. link-local IPv6 link-local or IPv6 global address) It is important to mention that if EAP over a particular link-layer (e.g. IEEE 802.1X) is already in place for network access, CoAP-EAP can be used for a secondary authentication for other services, as commented in C.5.2. (that would be an example of B with IPv6 global address) In the case of A), we will need support for the transport of CoAP-EAP at link-layer. For example, in IEEE 802.15.4 networks, a new KMP ID can be defined in IEEE 802.15.9 to add such support. In the case of B) we can assume that the device has at least a link-layer IPv6 address to run CoAP-EAP, be it directly with the Controller or through an intermediary entity such as proxy, as we mention in 3.6. Proxy operation in CoAP-EAP. Once the authentication is completed, we can assign a global IPv6 address to the device. This would follow a similar model as 6TiSCH Join Protocol or Zigbee IP. Regarding the case where we intend to add support for CoAP-EAP in mesh networks, we would follow the same process we either have connectivity with the Controller, or through an intermediary entity (proxy) that is already authenticated and can aid in running CoAP-EAP, as discussed in section 8.3 and in the new text of section C.5.1 To make this possible, as expressed in 8.3. Allowing CoAP-EAP traffic to perform authentication. "This link MUST authorize exclusively unprotected IP traffic to be sent between the EAP peer and the EAP authenticator (or the CoAP proxy) during the authentication with CoAP-EAP." . We have also added the following text to highlight the possibility of link-layer support for CoAP-EAP: " Alternatively, the link-layer MAY provide support to transport CoAP- EAP without a IP address by using link-layer frames (e.g. by defining a new Key Management Protocol ID in IEEE 802.15.9 [ieee802159]). " For admission and removal, text in section C.5.1 incorporates now this discussion. The resulting added text is the following: "In the process of joining a network, we may find two cases: 1) the node does not have an IPv6 address; 2) the node does have an IPv6 address (e.g., link-local IPv6 or IPv6 global address). In networks where the device is placed and no IP support is available until the EAP peer is authenticated, specific support for this EAP lower layer has to be defined to allow CoAP-EAP messages to be exchanged between the EAP peer and the EAP authenticator. For example, in IEEE 802.15.4 networks, a new KMP ID can be defined to add such support in the case of IEEE 802.15.9 [ieee802159]. Where we can assume that the device has at least a link-layer IPv6 address. When the EAP peer intends to be admitted into the network, it would search for an entity that offers the CoAP-EAP service, be it the EAP authenticator directly, or through the intermediary (i.e., proxy). See Section 3.1. CoAP-EAP will run between the EAP peer and the EAP authenticator or through an intermediary entity such as a proxy, as happens in a mesh network, where the EAP authenticator could be placed to 1 or more hops from the EAP peer. In the case a proxy participates in CoAP- EAP, it will be because it is already a trustworthy entity within the domain, which communicates through a secure channel with the EAP authenticator, as illustrated by Figure 11. Thus, the EAP peer follows the same process described in Appendix C.5.1 to perform the authentication. As mentioned, we either have direct link to the EAP authenticator, or through an intermediary entity (proxy) that is already part of the network (already shares key material and communicate through a secure channel with the authenticator) and can aid in running CoAP-EAP. When CoAP-EAP is completed, and the OSCORE security association is established with the EAP authenticator, the EAP peer receives the local configuration parameters for the network (e.g. a network key) and can configure a global IPv6 address. Moreover, there is no need of a CoAP proxy after a successful authentication. For removal, if the EAP authenticator decides to remove a particular EAP peer from the network or the peer itself intends to leave, either EAP peer or EAP authenticator can directly send a DELETE command to explicitly express that the network access state is removed, and the device will no longer belong to the network. Thus, any state related to the EAP peer is removed in the EAP authenticator. Forced removal can be done by sending new specific key material to the devices that still belong to the network, excluding the removed device, following a similar model as 6TiSCH Join Protocol [RFC9031] or Zigbee IP[ZigbeeIP]. The specifics on how this process is to be done, is out of scope of this document. +----------+ +----------+ +--------------+ | EAP | | CoAP | | EAP | | peer |<------>| Proxy |<------------------------->| authenticator| +----------+ CoAP +----------+ CoAP +--------------+ OSCORE/DTLS <--(Security Association)--> Figure 11: CoAP-EAP through CoAP proxy Given that EAP is also used for network access authentication, we can adapt this service to other technologies. For instance, to provide network access control to very constrained technologies (e.g., LoRa network). Authors in [lo-coap-eap] provide a study of a minimal version of CoAP-EAP for LPWAN networks with interesting results. In this specific case, we could leverage the compression by SCHC for CoAP [RFC8824]." Best regards. El 19/10/24 a las 19:42, Eliot Lear via Datatracker escribió: > Reviewer: Eliot Lear > Review result: Ready with Issues > > This is a follow-up to my earlier IoT directorate review. In that review I > raised four issues: > > 1. Proper illustration of EMSK key derivation (this is somewhat optional) > 2. Terminology alignment > 3. MTU issues > 4. A difference between how EAP is used (e.g., without IP connectivity) and > this work. > > All four points have (mostly) been addressed, although I have comments on the > last one. There is a key deployment aspect missing that I would suggest the WG > consider: > > When dealing with EAP at the 802.1X layer, since the device doesn't have an IP > address, in effect from the application point of view, and even at certain > kernel layers, the interface is down. That means that no address has been > assigned, and from the network edge standpoint, no IEEE 802.1q VLANs assigned > either. > > One complication that remains is this: if the network enables access based on > VLAN assignments, then the L3 address may need to change. Upper layers in the > client need to be prepared for that, and address plans may need to take it into > account. I suggest that some operational cautions be added to address these > points. > > In addition, and without going into a whole lot of detail, if this method is > being made use of by a mesh network for permitting access, it must be clear how > both admission and removal are handled; or an applicability statement should be > added that until someone does that work, this document should not be > recommended for such networks. > > > -- Dan García Carrillo --------------------- Departamento de Informática, Área de Telemática, Universidad de Oviedo 2.7.8 - Escuela Politécnica de Ingeniería, 33204, Campus de Viesques, Gijón Tel.: +34 985182654 (Ext. 2654) | email: garciadan@uniovi.es
- [Ace] Iotdir telechat review of draft-ietf-ace-wg… Eliot Lear via Datatracker
- [Ace] Re: Iotdir telechat review of draft-ietf-ac… Dan Garcia Carrillo