Subject: Re: [core] [Ace] CoAP-EAP draft

From: Christian Amsüss <[email-masked]>
Date: Fri, 1 Oct 2021 10:22:55 +0200

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

---

From: Christian Amsüss <[email-masked]>
Date: Mon, 11 Oct 2021 11:10:35 +0200

Hello Dan & Rafa,

On Fri, Sep 10, 2021 at 10:42:56AM +0200, Dan Garcia Carrillo wrote:
> > * OSCORE ID derivation:
> > 
> >    * Randomly assigned full-length ideas look like an odd choice.
> >      [...]
> > 
> >      Any chance something like that can still make it in?
>
> [Authors] Did not see that as random but parametrised according to the
> crypto suite. We will try to make this as straightforward as possible
> following your comments.

the construction we recently discussed (where both peers decide actively
on the OSCORE Recipient IDs (or client ID for DTLS) they'd later want to
use as inputs to EAP) would resolve this issue conveniently.

(See coming follow-up in "About securing last exchange CoAP-EAP"[1] on
how this makes things easier over there).

BR
c

[1]: https://mailarchive.ietf.org/arch/msg/emu/bnMFV4_1uTW7sSwVOp7WzVZZCAI/