Re: [Emu] [Ace] About securing last exchange CoAP-EAP

Christian Amsüss <> Mon, 16 August 2021 14:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 73C413A1874; Mon, 16 Aug 2021 07:52:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AgDMP2wJO7ID; Mon, 16 Aug 2021 07:52:12 -0700 (PDT)
Received: from ( [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 036723A1871; Mon, 16 Aug 2021 07:52:11 -0700 (PDT)
Received: from (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by (Postfix) with ESMTPS id 3F4A440104; Mon, 16 Aug 2021 16:52:04 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTP id 9780FD0; Mon, 16 Aug 2021 16:52:03 +0200 (CEST)
Received: from (unknown [IPv6:2a02:b18:c13b:8010:6a01:d988:4e55:c71b]) by (Postfix) with ESMTPSA id 6140246; Mon, 16 Aug 2021 16:52:03 +0200 (CEST)
Received: (nullmailer pid 2872923 invoked by uid 1000); Mon, 16 Aug 2021 14:52:03 -0000
Date: Mon, 16 Aug 2021 16:52:03 +0200
From: Christian =?iso-8859-1?Q?Ams=FCss?= <>
To: Dan Garcia Carrillo <>
Cc: EMU WG <>, "" <>
Message-ID: <YRp7k/qFA0dE+/>
References: <>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6QeRU75tkUw4cMvK"
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [Emu] [Ace] About securing last exchange CoAP-EAP
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 16 Aug 2021 14:52:17 -0000


On Sat, Aug 14, 2021 at 01:37:06PM +0200, Dan Garcia Carrillo wrote:
> As such, CoAP server (left side) could not see the content of the CoAP
> message (message 7) without deciphering it. Moreover, as the URI-path is
> also ciphered we cannot point to the right application to process the
> message to achieve an alternate indication of success.

If the recipient ID were available a bit earlier (and not derived from
the MSK), would it then be viable to infer from the OSCORE ID that this
is the last message, process an "EAP success", and start derivation just
to extract the session lifetime (and thereby confirm the keys)?

(That'd be all assuming that the "EAP success" contains really just the
EAP success code and no further information, which would be "compressed"
into the "some OSCORE is sent on this" information, and that the
Session-Lifetime does not need to be known to advance the EAP state


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