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