Re: [Lake] Review of draft-selander-lake-authz-00
Michael Richardson <mcr+ietf@sandelman.ca> Mon, 07 November 2022 18:47 UTC
Return-Path: <mcr+ietf@sandelman.ca>
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 BD8D8C1526E5 for <lake@ietfa.amsl.com>; Mon, 7 Nov 2022 10:47:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 L528WQAmzFQh for <lake@ietfa.amsl.com>; Mon, 7 Nov 2022 10:47:19 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00:e000:2bb::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7276DC1524D2 for <lake@ietf.org>; Mon, 7 Nov 2022 10:47:19 -0800 (PST)
Received: from dyas.sandelman.ca (unknown [IPv6:2001:67c:370:1998:3672:818a:e299:2fd7]) by relay.sandelman.ca (Postfix) with ESMTPS id 70A2D1F44E; Mon, 7 Nov 2022 18:47:17 +0000 (UTC)
Received: by dyas.sandelman.ca (Postfix, from userid 1000) id 202EBA0F00; Mon, 7 Nov 2022 18:47:15 +0000 (GMT)
Received: from dyas (localhost [127.0.0.1]) by dyas.sandelman.ca (Postfix) with ESMTP id 1DB1CA0EFF; Mon, 7 Nov 2022 18:47:15 +0000 (GMT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Marco Tiloca <marco.tiloca=40ri.se@dmarc.ietf.org>
cc: "lake@ietf.org" <lake@ietf.org>
In-reply-to: <e7e16233-3bfc-56b0-1a77-dd8ce370bf44@ri.se>
References: <e7e16233-3bfc-56b0-1a77-dd8ce370bf44@ri.se>
Comments: In-reply-to Marco Tiloca <marco.tiloca=40ri.se@dmarc.ietf.org> message dated "Mon, 07 Nov 2022 17:26:51 +0000."
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Mon, 07 Nov 2022 18:47:15 +0000
Message-ID: <176307.1667846835@dyas>
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/wi_-Z1J2KXrYK6TOk15zEDIkfrk>
Subject: Re: [Lake] Review of draft-selander-lake-authz-00
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: Mon, 07 Nov 2022 18:47:21 -0000
Thank you for your comments, I think that I need to go through them a second time. Marco Tiloca <marco.tiloca=40ri.se@dmarc.ietf.org> wrote: > It is fine (although excessive) to assume that, but later on the > voucher is intended to be computed over the whole authentication > credential CRED_R, not only on the public key PK_V. I don't think that we can calculate the voucher across CRED_R as the protocol is currently designed. Why do we need to do that? Why isn't PK_V enough? > When establishing the secure session between V and W, it might not > have been possible to use exactly CRED_R for authenticating V. In > particular, CRED_R has to be a CCS, which might not be accepted as is > by the (D)TLS handshake as raw public key of the (D)TLS client. Ha, yes. So, in RFC8995, we prefer client-side certificates for V's TLS client, but we don't insist that it be identical to PK_v. In smaller systems it can often be the case. So, that's why the Registrar Voucher Request (RVR), is signed by PK_V. draft-richardson-anima-registrar-considerations, sections 4 and 5. > Basically, out of the secure association establishment with V, W > knows the public key PK_V, but it might not know the exact CRED_R to > compute the Voucher. > As per Section 4.3.2, "The voucher is essentially a message > authentication code which binds the authentication credential of V to > message_1 of EDHOC", so the whole authentication credential has to be > considered. > Why not entirely decoupling the two ways that V uses to authenticate > with U and with W? See further comments below. Hmm. > * "A future version of this draft may specify explicit proof of > possession of the private key of PK_V in VREQ, e.g., by including a > signature of the contents of the voucher request made with the private > key corresponding to PK_V." > Yes, this would be much better and more flexible. And if fits into RFC8995 model better. > The Voucher Request can include the whole authentication credential > CRED_R, together with the Proof-of-Possession (PoP) evidence > PoP_V. After all, the leg V-W is supposed to rely on a non-constrained > link. Seems like maybe a hash of CRED_R could be sent as part of the voucher request, which Pledge (U) would be able to independantly calculate. > The Diffie-Hellman secret can be computed using the > public/private key corresponding to CRED_R, as well as the public key > G_W and the corresponding private key. This assumes that V has the > Diffie-Hellman public key of W, or that it can retrieve it latest when > preparing the Voucher Request. > This is the same approach used to build Proof-of-Possession in > draft-ietf-ace-key-groupcomm-oscore and > draft-tiloca-ace-group-oscore-profile. thanks. > [Section 4.4.2.2] > * This implies that, at least for this particular EDHOC execution > involving this particular use of EAD items, U considers a TOFU policy > for trusting any new authentication credentials as long as they are > valid, right? I might need more expansion of your thoughts here. > This has the following advantages: > - You don't need to mandate (D)TLS client authentication between V > and W. Besides, if you still use it, it does not have to necessarily > rely on client certificates. I think that misses some of the sales channel integration that is desirable. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
- [Lake] Review of draft-selander-lake-authz-00 Marco Tiloca
- Re: [Lake] Review of draft-selander-lake-authz-00 Michael Richardson
- Re: [Lake] Review of draft-selander-lake-authz-00 Michael Richardson
- Re: [Lake] Review of draft-selander-lake-authz-00 Marco Tiloca