Re: [Ace] CoAP-EAP draft

Christian Amsüss <> Fri, 01 October 2021 08:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6D64A3A0113; Fri, 1 Oct 2021 01:23:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MBsbr4fPkz5K; Fri, 1 Oct 2021 01:23:05 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5F8133A0A25; Fri, 1 Oct 2021 01:23:02 -0700 (PDT)
Received: from (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by (Postfix) with ESMTPS id D25734174C; Fri, 1 Oct 2021 10:22:58 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTP id E254CD7; Fri, 1 Oct 2021 10:22:55 +0200 (CEST)
Received: from (unknown [IPv6:2a02:b18:c13b:8010:57cf:9775:915b:5002]) by (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, 1 Oct 2021 10:22:55 +0200
From: Christian =?iso-8859-1?Q?Ams=FCss?= <>
To: Dan Garcia Carrillo <>
Cc: EMU WG <>, "" <>, Rafa Marin-Lopez <>,
Message-ID: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="L5Xh2gZWNTasjqlQ"
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [Ace] CoAP-EAP draft
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 01 Oct 2021 08:23:12 -0000


(picking some easy targets to advance, not touching parallel or earlier

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
> (  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

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.


To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom