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

Rafa Marin-Lopez <rafa@um.es> Fri, 03 September 2021 18:33 UTC

Return-Path: <rafa@um.es>
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 999AA3A2805; Fri, 3 Sep 2021 11:33:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=um.es
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 lj6cnqDXIH_6; Fri, 3 Sep 2021 11:33:16 -0700 (PDT)
Received: from mx01.puc.rediris.es (outbound6mad.lav.puc.rediris.es [130.206.19.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94E403A2801; Fri, 3 Sep 2021 11:33:15 -0700 (PDT)
Received: from xenon44.um.es (xenon44.um.es [155.54.212.171]) by mx01.puc.rediris.es with ESMTP id 183IX6s5030498-183IX6s6030498; Fri, 3 Sep 2021 20:33:06 +0200
Received: from localhost (localhost [127.0.0.1]) by xenon44.um.es (Postfix) with ESMTP id 0857220A9C; Fri, 3 Sep 2021 20:33:06 +0200 (CEST)
X-Virus-Scanned: by antispam in UMU at xenon44.um.es
Received: from xenon44.um.es ([127.0.0.1]) by localhost (xenon44.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Uuqrg-fEXFSN; Fri, 3 Sep 2021 20:33:05 +0200 (CEST)
Received: from [192.168.9.127] (unknown [84.78.251.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa@um.es) by xenon44.um.es (Postfix) with ESMTPSA id 891EF2020F; Fri, 3 Sep 2021 20:33:01 +0200 (CEST)
From: Rafa Marin-Lopez <rafa@um.es>
Message-Id: <78D49A4D-AE9D-4701-9ADF-DAF8ABB317ED@um.es>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F93A85EF-C1BC-4F81-83B3-D3D34D2BA90C"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Date: Fri, 3 Sep 2021 20:32:59 +0200
In-Reply-To: <YRp7k/qFA0dE+/wp@hephaistos.amsuess.com>
Cc: Rafa Marin-Lopez <rafa@um.es>, Dan Garcia Carrillo <garciadan@uniovi.es>, EMU WG <emu@ietf.org>, "ace@ietf.org" <ace@ietf.org>
To: =?utf-8?Q?Christian_Ams=C3=BCss?= <christian@amsuess.com>
References: <07cd0942-9ee0-b124-b3a7-649f262d7c9e@uniovi.es> <YRp7k/qFA0dE+/wp@hephaistos.amsuess.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
X-FEAS-SPF: spf-result=pass, ip=155.54.212.171, helo=xenon44.um.es, mailFrom=rafa@um.es
Authentication-Results: mx01.puc.rediris.es; spf=pass (rediris.es: domain of rafa@um.es designates 155.54.212.171 as permitted sender) smtp.mailfrom=rafa@um.es
X-FE-Policy-ID: 2:15:0:SYSTEM, 2:15:1:uniovi.es
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=um.es; s=DKIM; c=relaxed/relaxed; h=from:message-id:content-type:mime-version:subject:date:cc:to:references; bh=wK4VT/Eu+KjPdg6IxicDph3LE1498zPWZkGl1uh9rFg=; b=QyF28XgKoN8UAtFfotVnIF0A+Zh02//TQRA5yej1uADTnH/sepNYDOOkh54yKoIm9r9CBcUm9Sjh tAh/ertDyIP1+xOzEFw00R4ee6qeXxfDDXGx9D0f0iXAipzNycH4PSyvDjXVGV/emz6zYDRuVBxy IwrKqVQOUFDE8mfIxRaUaXdCX1r8kvag0QH2S6QEat7Zy0Nxb0qkvWpH6pREB5SYLg39FhE/FDu7 3o9s4qUrthyvSxP+gwKM/yuwqLNvYgHRoISBML7p3CyeJoMCuGcSDb1jAuyvXDP9RgpZFxN4JaG/ yQ0mAQ6FChXKQ6nMxfQljSjJZYwOLo5XVTdBhQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/7c2t5Lebf0rC_Xx4c_X4kneeEKs>
Subject: Re: [Ace] About securing last exchange CoAP-EAP
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: Fri, 03 Sep 2021 18:33:22 -0000

Hi Christian:

Thank you for comments. See our comments inline.

> El 16 ago 2021, a las 16:52, Christian Amsüss <christian@amsuess.com> escribió:
> 
> Hello,
> 
> 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)?

What you mentioned was something we already considered but we do not see how it would solve the problem. Let me explain. According to OSCORE RFC , Section 8.2 - step 2:

"If either the
       decompression or the COSE message fails to decode, or the server
       fails to retrieve a Recipient Context with Recipient ID
       corresponding to the 'kid' parameter received, then the server
       SHALL stop processing the request.”

What you mention solves step 2, however the step 5 says:

"If decryption fails, the server MUST stop processing the
          request and MAY respond with a 4.00 (Bad Request) error
          message."

However, the OSCORE context with Recipient ID does not have any Recipient key yet, correct?. To make this work, we believe this should happen.


1) The CoAP server should create an OSCORE context with ID but without any key material.

2) When the CoAP message contains the OSCORE ID that hits the OSCORE context without any key material, we would have to assume this is CoAP-EAP: the OSCORE implementation should not discard or give a fail for this coap message but "pass the control" to CoAP-EAP so that we send a altAccept to the EAP state machine so we get the MSK.

3) From the MSK, we derive the OSCORE key material for the OSCORE context with the corresponding ID and update the OSCORE context with this key material 

4) Verify that the received protected coap-message with OSCORE.

5) Then we can get the cleartext information.

For us, this seems a little odd and we do no think it is supported by OSCORE RFC, are we wrong?

Any comment is welcome.

Best Regards

P.D: Dan is processing your review of the I-D. Thank you very much.

> 
> (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
> machine).
> 
> BR
> c
> 
> -- 
> To use raw power is to make yourself infinitely vulnerable to greater powers.
>  -- Bene Gesserit axiom
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace

-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es
-------------------------------------------------------