Re: [core] [Ace] CoAP-EAP draft
Christian Amsüss <christian@amsuess.com> Fri, 01 October 2021 08:23 UTC
Return-Path: <christian@amsuess.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D64A3A0113; Fri, 1 Oct 2021 01:23:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 MBsbr4fPkz5K; Fri, 1 Oct 2021 01:23:05 -0700 (PDT)
Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F8133A0A25; Fri, 1 Oct 2021 01:23:02 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id D25734174C; Fri, 1 Oct 2021 10:22:58 +0200 (CEST)
Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id E254CD7; Fri, 1 Oct 2021 10:22:55 +0200 (CEST)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:57cf:9775:915b:5002]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 9281313C; Fri, 1 Oct 2021 10:22:55 +0200 (CEST)
Received: (nullmailer pid 3462502 invoked by uid 1000); Fri, 01 Oct 2021 08:22:55 -0000
Date: Fri, 01 Oct 2021 10:22:55 +0200
From: Christian Amsüss <christian@amsuess.com>
To: Dan Garcia Carrillo <garciadan@uniovi.es>
Cc: EMU WG <emu@ietf.org>, "ace@ietf.org" <ace@ietf.org>, Rafa Marin-Lopez <rafa@um.es>, core@ietf.org
Message-ID: <YVbFX0GnnwoDMtm4@hephaistos.amsuess.com>
References: <0cfd2df3-9264-b6fd-e58b-a93a7d8fda5f@uniovi.es> <A4C71152-DA98-47B1-9BFC-136F59CAB68A@amsuess.com> <c9cdb216-59a7-b06a-7cd0-9386e7b6f9ae@uniovi.es> <ea8e5cbd-952c-2728-eecf-cc6a668179dc@uniovi.es>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="L5Xh2gZWNTasjqlQ"
Content-Disposition: inline
In-Reply-To: <ea8e5cbd-952c-2728-eecf-cc6a668179dc@uniovi.es>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/0sNQAhmyVnnlc64Kulam80YYh1w>
Subject: Re: [core] [Ace] CoAP-EAP draft
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Oct 2021 08:23:12 -0000
Hello, (picking some easy targets to advance, not touching parallel or earlier discussion), On Fri, Sep 10, 2021 at 10:42:56AM +0200, Dan Garcia Carrillo wrote: > > IoT device Controller > > +------------+ +------------+ > > | EAP peer/ | | EAP auth./ |+-----+[ AAA infra. ] > > | CoAP server|+------+| CoAP client|+-----+[ EAP server?] > > +------------+ CoAP +------------+ EAP? > > \_____ Scope of this document _____/ > > > > Figure 1: CoAP-EAP Architecture > > > [Authors] This is a good point. We did not include it at first, as having a > AAA infrastructure is not mandatory. But the optionality can also be > expressed in the figure. We will consider using this for the next version. > Please also be aware that this architecture including AAA is assuming > something called EAP authenticator in pass-through mode. Nevertheless, an > EAP authenticator in standalone mode is also possible, where no AAA exists. Maybe it helps to emphasize the components then (which I probably got wrong in the image) -- there's the (existing / unmodifed) EAP server in the controller, which now gains the CoAP transport, and optionally passes on the data to some AAA infrastructure: | IoT device Controller AAA infrastructure | +------------+ +------------+--------+ (optional) | | EAP peer/ | | EAP auth./ | EAP | | | CoAP server|+------+| CoAP client| server |+-----+[ ...] | +------------+ CoAP +------------+--------+ | \___ Scope of this document ___/ | | Figure 1: CoAP-EAP Architecture > > * (Bycatch of suggesting URIs): It may be worth mentioning that the > > NON's source address can easily be spoofed. Thus, any device on the > > network can trigger what the authenticator may think of as a > > device-triggered reauthentication, and the device may think of as an > > authenticator-triggered reauthentication (provided it works that way, > > see below when reauthentication is mentioned again). > > [Authors] But this case would not be possible since we mention that (re) > authentication is initiated by the device. Thus, when the device sees an > authenticator triggered re-authentication will discard that. If authenticators don't reauthenticate, then fine. (But I wonder: What happens to an established context if, for example, the authenticator finds that a used credential just wound up on a CRL?). > > * Proxying: As it is right now, this protocol just barely works across > > proxies, and only if they support CoAP-EAP explicitly. (And while it > > may sound odd to even consider that, bear in mind that they are used > > in a very similar way in RFC9031). > > > > While it's a bit open whether all CoAP-based protocols should > > reasonably be expected to work across proxies or not, a remark (maybe > > before 3.1?) that "If CoAP proxies are used between EAP peer and EAP > > authenticator, they must be configured with knowledge of this > > specification, or the operations will fail after step 0." > > [Authors] Based on your comment, it seems there is no guarantee that any > CoAP-based protocol would work across proxies. Our question is whether there > is any adaptation or change that would favour working through proxies. At > the research level, we worked with proxy and you are right, our assumption > is that proxies support CoAP-EAP explicitly > (https://ieeexplore.ieee.org/document/8467302). Since we are trying > to avoid right now anything tailored to CoAP-EAP and only using CoAP > as a means of transport for the exchange, why do you think this would > not work with proxies? A CoAP-based protocol in general works across proxies if it doesn't use any of the following: * Options that are not safe-to-forward * The role-reversal address (without a means to indicate an address more explicitly) This document does not use new options, but the initiation step uses the role-reversal address. The part where the controller is the CoAP client and the device is the CoAP server should work through any proxy -- but the initial step means that the initial CoAP server (the controller) looks at its role-reversal address (the source of the request). As it is now, a proxy that facilitates EAP-CoAP would need to recognize that first message and send it from a port dedicated to forwarding to that client. Allowing the client to set its address would not do away with all the issues, but at least paint a way out. > > > * 3.3.1: "after the maximum retransmission attempts, the CoAP client > > > will remove the state from its side". > > > > > > So the device that's being kicked from the network can delay its own > > > eviction for about a minute as long as it doesn't answer? > > > > [Authors] This is an interesting use case. To avoid this, we may have to > change the behaviour, to a NON-message and just remove the state. The application can grant a grace time if the reason for eviction warrants it -- but it should be the application / its reason guiding that time, not the OK. > > * OSCORE derivation: Is it cryptographically necessary to derive *both* > > a master secret and a master salt through KDF? (Sounds like a > > needless step to me, as both only go into KDF once more when the > > actual OSCORE parameters are derived). I *guess* there's a good reason > > why the MSK is not used as the OSCORE IKM right away and the CSO as > > OSCORE master salt, but it'd help to have at list a comment here on > > why that's needed. > > > > (It may be useful to compare this step to the HKDF steps in OSCORE; > > their info element is always a 5-element array with a 4th "type" > > element of "Key" or "IV"; other extractions might just hook in there > > with different type values, maybe, and save everyone an extra handling > > step). > > [Authors] You are right, there should be a clarification on why this is done > the way it is. The main purpose is to use MSK as the root key for key > derivation. It is common practice with the usage of the MSK. If say key were > compromised, another one could be derived from the MSK, without having to > resort to a new bootstrapping to refresh the MSK. But is ther an actual way to get different keys out of the same MSK? (Because if there's not, I don't see how it helps with that goal). > > > * If the parties happen to be assigned the same sender ID, bad things > > > happen (identical key derivation, nonce reuse, nuclear meltdown). > > > > > > If the current pattern of KDF'ing IDs stands, this needs to be > > > prevented explicitly. > > [Authors] Since the Sender and recipient IDs, are derived from the MSK, > which is assumed to be fresh key material, I think this should not be a > problem. It's not an issue of freshness but of chances of collisions. The length is limited (like 5 bytes depending on suite IIRC), and the birthday paradox can hit. BR c -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom
- Re: [core] [Ace] CoAP-EAP draft Christian Amsüss
- Re: [core] [Ace] CoAP-EAP draft Dan Garcia Carrillo
- Re: [core] [Ace] CoAP-EAP draft Dan Garcia Carrillo
- Re: [core] [Ace] CoAP-EAP draft Christian Amsüss
- Re: [core] [Ace] CoAP-EAP draft Christian Amsüss