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
signature.asc
Description: PGP signature
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
