Re: [Ace] About securing last exchange CoAP-EAP ( and EAP state machine - RFC 4137)

Christian Amsüss <christian@amsuess.com> Mon, 11 October 2021 10:09 UTC

Return-Path: <christian@amsuess.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD8FF3A08D3; Mon, 11 Oct 2021 03:09:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
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=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47KfkecmO3lq; Mon, 11 Oct 2021 03:09:45 -0700 (PDT)
Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A90513A05A7; Mon, 11 Oct 2021 03:09:44 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id C12A4400D8; Mon, 11 Oct 2021 12:09:41 +0200 (CEST)
Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 97679106; Mon, 11 Oct 2021 12:09:40 +0200 (CEST)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:58a:38c7:d462:d25e]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 55AEA10A; Mon, 11 Oct 2021 12:09:40 +0200 (CEST)
Received: (nullmailer pid 1455897 invoked by uid 1000); Mon, 11 Oct 2021 10:09:40 -0000
Date: Mon, 11 Oct 2021 12:09:40 +0200
From: Christian =?iso-8859-1?Q?Ams=FCss?= <christian@amsuess.com>
To: Rafa Marin-Lopez <rafa@um.es>
Cc: =?iso-8859-1?Q?G=F6ran?= Selander <goran.selander=40ericsson.com@dmarc.ietf.org>, EMU WG <emu@ietf.org>, Dan Garcia Carrillo <garciadan@uniovi.es>, "ace@ietf.org" <ace@ietf.org>
Message-ID: <YWQNZF8weRLbrT9V@hephaistos.amsuess.com>
References: <07cd0942-9ee0-b124-b3a7-649f262d7c9e@uniovi.es> <6d2a20fc-7b79-4555-840e-d57f686be42f@VE1EUR02FT003.eop-EUR02.prod.protection.outlook.com> <BB962406-48C4-4BE8-B13F-8D55291964E6@ericsson.com> <38B0BDE9-5B5C-4F77-B914-DFA98AB711B0@um.es>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mmAT7aS1TsIGwA0g"
Content-Disposition: inline
In-Reply-To: <38B0BDE9-5B5C-4F77-B914-DFA98AB711B0@um.es>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/r7lg_srkU8nTHQZFZD-ZFU41KRY>
Subject: Re: [Ace] About securing last exchange CoAP-EAP ( and EAP state machine - RFC 4137)
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Oct 2021 10:09:50 -0000

Hello Rafa,

that's the mail I missed in our previous discussion -- and yes, it
largely describes already just what I think can work, see comments
below.

On Sat, Sep 04, 2021 at 09:19:35PM +0200, Rafa Marin-Lopez wrote:
> I think that is not possible because that would move the EAP peer
> state machine to a final state SUCCESS without any chance to withdraw. 

Does there need to be?

If a request arrives at an OSCORE context and the validation *fails*,
the most probable explanation is that someone got the key derivation
wrong -- no point in allowing another attempt.

Or, of course, an attacker has been listening, and either attempting to
guess a key (giving them several attempts is questionable) or trying to
disturb the negotiation (which they can already do more easily by
sending unsuccessful CoAP responses).

> However, the MSK required to create the OSCORE context, which allows
> deciphering the message, is not available yet (even though eapKeyData
> variable has content). The reason is that, according to EAP state
> machine (RFC 4137) Figure 3, the MSK becomes available
> (eapKeyAvailable = TRUE) when EAP success (rxSuccess or altSuccess
> from the EAP lower layer) is sent to EAP state machine.

The OSCORE context can be partially initialized, or updated over its
lifetime. This is odd if you think of the context as a Recipient ID to
key mapping, but that's not generally the case in OSCORE, and the
construction of its RFC8613 B.2 also depends on data about requests
being fed "live" into the key derivation before the actual key is there.

With agreed-on recipient IDs[1], what happens as the "last" message EAP
is involved in can be this:

* OSCORE message is received
* OSCORE library looks into OSCORE option, finds an ID placed there by
  EAP
* OSCORE library asks EAP for key material for that ID (this is a
  callback, not a dictionary lookup)
* EAP sees that and declares altSuccess based on the receiption of the
  message alone, and then extracts the key material from the state
  machine
* EAP returns the context key material to the OSCORE library
* Message is decrypted

That message does not even need to go up to the EAP resource any more --
it's just as fine if that is already usable data. (If there is no
request pending and you prefer to have such a message just to clean out
the EAP state even though it has no timeouts, any encrypted message
would do, including a POST to the EAP resource).

BR
c

[1]: https://mailarchive.ietf.org/arch/msg/core/AK8Wxy64tXofocdRHm5HNew8dpE/

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