Re: [Anima] draft-ietf-acme-star-delegation-05.txt and BRSKI-AE

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 03 March 2021 22:17 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 296323A1C51 for <anima@ietfa.amsl.com>; Wed, 3 Mar 2021 14:17:07 -0800 (PST)
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=ham 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 mbXBNaBsa44V for <anima@ietfa.amsl.com>; Wed, 3 Mar 2021 14:17:04 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 473193A1C31 for <anima@ietf.org>; Wed, 3 Mar 2021 14:17:04 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 9A070389A0; Wed, 3 Mar 2021 17:21:41 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7UQBVElswztI; Wed, 3 Mar 2021 17:21:38 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 0397D3899B; Wed, 3 Mar 2021 17:21:38 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4B568885; Wed, 3 Mar 2021 17:16:59 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Fries\, Steffen" <steffen.fries@siemens.com>, "anima\@ietf.org" <anima@ietf.org>
CC: "Brockhaus\, Hendrik" <hendrik.brockhaus@siemens.com>, =?utf-8?Q?Christian_Ams=C3=BCss?= <christian@amsuess.com>
In-Reply-To: <bb9ac3341495461aa19f9a32c123afa5@siemens.com>
References: <161393206518.11813.1416988663631870171@ietfa.amsl.com> <23305.1613938428@localhost> <bb9ac3341495461aa19f9a32c123afa5@siemens.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Wed, 03 Mar 2021 17:16:59 -0500
Message-ID: <1300.1614809819@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/5FLP5bbuz-znEFGqnxkMr_Kj2Js>
Subject: Re: [Anima] draft-ietf-acme-star-delegation-05.txt and BRSKI-AE
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Mar 2021 22:17:07 -0000

Fries, Steffen <steffen.fries@siemens.com> wrote:
    > Sorry for the late response.
    >> We have struggled with brski-ae to deal with how the pledge can pin a
    >> thing from the pledge-agent to prove proximity.

    > Based on some further discussion, we have to decide, how the proximity
    > is handled in BRSKI-AE. The motivation for now was to have it to avoid
    > DoS attacks on the pledge.

Understood.
Christian Amsuss has done some work with CoAP over the websocket version of
BTLE/NFC (Please correct me here).  The idea being that we could do EDHOC or
some such over that link.  That wouldn't be an IPv6 link.

A reason for this interest is that this interface is available to one-page
WEB apps on a smartphone via Javascript, while mucking around with IPv6 over
BTLE or changing wifi access points is a serious pain on smartphones.

This provides a fair bit of physical proximity, which I think can mitigate
the DOS attack concern.  Really, we need to do some experiments here with
some kind of spike solution.

EDHOC, running over CoAP, should be relatively happy with the
store-and-forward mechanism that BRSKI-AE would like.

    > If we assume that the likelihood for DoS
    > attacks is higher on the registrar side, it is important to protect the
    > registrars endpoints.

I think that we can handle attacks on this side.

    >> It feels that something like either Delegated STAR could work well.
    >> Or, if not that, and we are using TLS, then draft-ietf-tls-subcerts-10
    >> Failing that, we need to create some kind of JWT, or CWT artifact
    >> which the Registrar uses to bless the pledge-agent.

    > Currently, the proposal would be to utilize an LDevID between the
    > pledge-agent and the registrar. It can be provided either by a separate
    > BRSKI run to the pledge-agent or manually.

Agreed, that's what I had in mind as well.

    > connecting or a pledge-agent based on the utilized certificate (IDevID
    > or LDevID). I would like to discuss the trust relations in the next
    > design team meeting.

Awesome!

    >> I find the PULL/PUSH terminology confusing.  I recognize that the
    >> directionality that is implied by the PULL/PUSH is based upon, I
    >> thought, whether the RFC8366 voucher is retrieved by the pledge, or
    >> provided to the pledge.  But, in section 5.1, I think that it's called
    >> PULL because the communication with the RA?

    > The naming PULL and PUSH was motivated by the pledge behavior, that it
    > either PULLs information from the registrar or that it is pushed with
    > the information from the pledge-agent. From a naming perspective we
    > already introduced some further names like pledge(-callee) in the PUSH
    > case, as the pledge is acting as a server while in the PULL case the
    > pledge acts as a client.  So one option would be to state pledge-client
    > (UC1) and pledge-server (UC2). Would you have further suggestions for a
    > naming? We could also discuss this in the next design team meeting.

I suggest we refer to it as "pledge-initiated onboarding" (PULL),
or "registrar (or pledge-agent) initiated onboarding".
Also, it is a Pledge-Agent, or is it really a Registrar-Agent?

(In real-estate: we have seller's agent or buyer's agent...)


--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide