Re: [Emu] [Ace] CoAP-EAP draft

[Christian Amsüss <[e-mail]>]

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