Re: [Lake] 🔔 WG Last Call for draft-ietf-lake-edhoc-17

Rafa Marin-Lopez <rafa@um.es> Thu, 03 November 2022 18:28 UTC

Return-Path: <rafa@um.es>
X-Original-To: lake@ietfa.amsl.com
Delivered-To: lake@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 094C6C14CF1B for <lake@ietfa.amsl.com>; Thu, 3 Nov 2022 11:28:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.023
X-Spam-Level:
X-Spam-Status: No, score=-1.023 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, RDNS_DYNAMIC=0.982, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=um.es
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2U64elGwLLW for <lake@ietfa.amsl.com>; Thu, 3 Nov 2022 11:28:05 -0700 (PDT)
Received: from mx07-006a4e02.pphosted.com (mx07-006a4e02.pphosted.com [143.55.146.78]) (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 A7B58C14F72B for <lake@ietf.org>; Thu, 3 Nov 2022 11:28:04 -0700 (PDT)
Received: from pps.filterd (m0316692.ppops.net [127.0.0.1]) by m0316692.ppops.net (8.17.1.19/8.17.1.19) with ESMTP id 2A3GUrsV004126 for <lake@ietf.org>; Thu, 3 Nov 2022 19:28:03 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=um.es; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=dkim3; bh=5cPXS892zOLpY9YG2VdIfSoLWf0X526Ivf1uiLCfbUA=; b=IWlyMUlzlVgElczkWHta1Eq2eEvs5Krv8zzYgrovEvW+4Yn+WD4wbfOoM3VXAb8sLNdW DLZwkgyptwXQAlIJMM9Jv8sF1eYtr0YGPTIgPQDY/Y4UZoJVK52Slrp6V0RoMkNVI640 yCR0PAmr3eVYCZ/4DRWraOxGCXu789ifMmLCiWyGMiNZF0zDFs7wfZblu6VJbAKoD93d 5Kceu4caVVi1GtwPY+ljG+4669mTa9KixXciQD26PPhU5G/bjlDqsl2AXbNdWNEaQEnN xSmZlffVTlBYggDjO5Ef0QaYaMKq1BuKJfQn0CQB8piHp7Z8xsnRvGcD8ZAElGxTnPGY 1w==
Received: from xenon44.um.es (xenon44.um.es [155.54.212.171]) by m0316692.ppops.net (PPS) with ESMTP id 3kmf5nawtc-1 for <lake@ietf.org>; Thu, 03 Nov 2022 19:28:02 +0100
Received: from localhost (localhost [127.0.0.1]) by xenon44.um.es (Postfix) with ESMTP id A0AAB220BC; Thu, 3 Nov 2022 19:28:02 +0100 (CET)
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 soOGqDVaxLGC; Thu, 3 Nov 2022 19:28:02 +0100 (CET)
Received: from smtpclient.apple (inf-205-228.inf.um.es [155.54.205.228]) (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 503FB2012D; Thu, 3 Nov 2022 19:28:02 +0100 (CET)
From: Rafa Marin-Lopez <rafa@um.es>
Message-Id: <ACBD2AE7-CDD2-4473-A256-F7DEA26B51CA@um.es>
Content-Type: multipart/alternative; boundary="Apple-Mail=_71C16AE6-788C-4BD8-A022-DC77CD3314A6"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Date: Thu, 03 Nov 2022 19:28:01 +0100
In-Reply-To: <4d31934f-2a26-3392-8511-934e0dbeeb35@inria.fr>
Cc: Rafa Marin-Lopez <rafa@um.es>
To: lake@ietf.org
References: <71E133FA-9C4D-4449-BC04-10F6D120D10D@inria.fr> <4d31934f-2a26-3392-8511-934e0dbeeb35@inria.fr>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Proofpoint-GUID: 8NWUFKGiKnnJGrbIGcuZH4jvS7CUulPI
X-Proofpoint-ORIG-GUID: 8NWUFKGiKnnJGrbIGcuZH4jvS7CUulPI
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-11-03_04,2022-11-03_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=outbounddefault_notspam policy=outbounddefault score=0 priorityscore=1501 lowpriorityscore=0 malwarescore=0 impostorscore=0 mlxscore=0 phishscore=0 mlxlogscore=953 spamscore=0 bulkscore=0 clxscore=1011 suspectscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000 definitions=main-2211030124
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/_tSTR3oa3jUZDp16fPkQgz_APWo>
Subject: Re: [Lake] 🔔 WG Last Call for draft-ietf-lake-edhoc-17
X-BeenThere: lake@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Lightweight Authenticated Key Exchange <lake.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lake>, <mailto:lake-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lake/>
List-Post: <mailto:lake@ietf.org>
List-Help: <mailto:lake-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lake>, <mailto:lake-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Nov 2022 18:28:10 -0000

Hi all:

I have been reading v17 and sent some comments to the authors, that I summarize here:

1) - Regarding RPK, previous versions of the document had a more detailed explanation about RPK. For example, in version v06 you had "The Initiator and the Responder MAY use different types of credentials, e.g. one uses an RPK and the other uses a public key certificate.” So RPK is included as part of the definition of authentication credential. 

However, v17 may have a different meaning since it seems “credentials" is defined as follows: 


"EDHOC relies on COSE for identification of credentials (see Section 3.5.3), for example X.509 certificates [RFC5280], C509
   certificates [I-D.ietf-cose-cbor-encoded-cert], CWTs [RFC8392] and
   CWT Claims Sets (CCS) [RFC8392].  When the identified credential is a
   chain or a bag, the authentication credential CRED_x is just the end
   entity X.509 or C509 certificate / CWT. 

I assume RPK is also an authentication credential and this should be included in this text. A clarification would be worthy.

2) I assume it is possible that any two IoT devices can act as initiator but also as a responder, even between same two peers. It is the application which decides when to start EDHOC (initiator) in a particular case, correct?


3) It seems the EDHOC does not define any exchange for the key update (some sort of rekey). It seems an application at some point exchange some messages as "some event that triggered the key update.” Then the application call to EDHOC-KeyUpdate function to get a new PRK. Am I right? I am asking because looking at IKEv2, for example, and for the rekey, an exchange is required. Although it would add a little bit more complexity, wouldn’t it be sensical that EDHOC defines a 1 RTT to exchange a couple of nonces for the rekeying. Moreover, this function is defined in an Appendix. Is it mandatory to implement?

Beyond these clarifications, I think the document is ready.

Best Regards.

>> Hi all,
>> 
>> As discussed during the interim on 5 October 2022, this email triggers the working group last call for the version 17 of the EDHOC draft, the main item on the agenda of the LAKE working group.
>> 
>> The draft can be found at: https://datatracker.ietf.org/doc/draft-ietf-lake-edhoc/ <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-lake-edhoc/__;!!D9dNQwwGXtA!Wan-fOxJpKCblWbmKcY1geqhUvbM2ogdP40RSH4d0e9QzAbuKgzRlPgRHN2yE-EETx-HXgTzq9ANoY5BAtUfPQ$>
>> 
>> Please state your position and comments to the list by 4 November 2022 so we can discuss them during the IETF 115 meeting in London.
>> 
>> Thanks,
>> Mališa, for the chairs
>> 
>> 
>> 
> -- 
> Lake mailing list
> Lake@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lake__;!!D9dNQwwGXtA!Wan-fOxJpKCblWbmKcY1geqhUvbM2ogdP40RSH4d0e9QzAbuKgzRlPgRHN2yE-EETx-HXgTzq9ANoY4zZl5Q0A$ 

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