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

"Fries, Steffen" <> Thu, 04 March 2021 07:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 565E03A147A for <>; Wed, 3 Mar 2021 23:08:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vBxmTG5dSVjd for <>; Wed, 3 Mar 2021 23:08:49 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 32C933A1479 for <>; Wed, 3 Mar 2021 23:08:49 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTPS id 24F5F4F0016; Thu, 4 Mar 2021 08:08:44 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTPS id B836918CF5B90; Thu, 4 Mar 2021 08:08:43 +0100 (CET)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 4 Mar 2021 08:08:43 +0100
Received: from ([]) by ([]) with mapi id 15.01.2106.013; Thu, 4 Mar 2021 08:08:43 +0100
From: "Fries, Steffen" <>
To: Michael Richardson <>, "" <>
CC: "Brockhaus, Hendrik" <>, =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= <>
Thread-Topic: [Anima] draft-ietf-acme-star-delegation-05.txt and BRSKI-AE
Thread-Index: AQHXCI4aI3KJbNx1uESz0kmGFFYTuKpwu3rggAIYgYCAAKFesA==
Date: Thu, 4 Mar 2021 07:08:42 +0000
Message-ID: <>
References: <> <23305.1613938428@localhost> <> <1300.1614809819@localhost>
In-Reply-To: <1300.1614809819@localhost>
Accept-Language: en-US, de-DE
Content-Language: en-US
msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2021-03-04T07:08:40Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=bb2f2bc7-c85a-4d36-87db-600cdebb7a53; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0
document_confidentiality: Restricted
x-originating-ip: []
x-tm-as-product-ver: SMEX-
x-tm-as-result: No-10--27.460500-8.000000
x-tmase-matchedrid: grK+ChACArzdDS6etHbe2wFP3zQ/z11d0bm0QnK23OYK3Ma88LL+bt3Q prxGuiIh4GDT9PuL9Z6f6eu+NowNgf8nv9x3PStadH9kusomMxcZcLrAZ/XZFTMvozJIQnRWIQX VF2qsdV1h2fnHe1cilwO2c6ovBmDph40R7G5gclz0eK/d+mnNvdtQoXKm4JivMhko6oynp7bdYV rFVbszaNRGf5c57+FFUNzM39IykFjIW6O1WInIUAPF8/7D3WUe8GhZM9HP2b46LZngKEXBdc6gB dMBUo41YjNWMNi9SZo4ijYc5twsTv6X154lAoxD7H0prhByuzjX8DucA0mWtcOC5QFrchIlv/9o vxpTvIAfyMkN7e89Axszr5/QcdMSV4tMYEJxbKDeEtMuS1eIWw/sueJZRd3ZHZJmvOZBmBEAXOn qjVuo8wg2kgWdt3qayqat6b4pc9054m3Nc0twG4P1KYKlSmjQuKlcYh5MR8RbfP6Rn++qeZIU5V RwhxxfBthzL1hCXp5efevuRniZm9/3V/OM7Vjge/d6+ieb/6q9a7L3aaqeU8LRNemq17EipWOBf K9L1z90A3EYPb/xOPoyx2o9QKI6OtZjV93JWoyzE1I26BnC6MRI9S5UU3PpU8KO1ajdBDwfkDOl TQgzYbnoQlc940JDINVMCwGUhxf0IaDcAWFEqZmLngkC75apthfZltvQe7LW4Mz461fsHAL3rpy OT0zYOBy9qYAHlxFOhVUhwURBiAUY+Xt/b/3h8Qk1Q6ghyPET6F/I3FhqMDKVTrGMDe/DEJBSu9 U3+s9jyv+d0Z0OxYoL26yYoYgd585VzGMOFzABi3kqJOK62QtuKBGekqUpIG4YlbCDECtruV6hT 84yE/IxdJB3PGL0
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
x-tmase-result: 10--27.460500-8.000000
x-tmase-version: SMEX-
x-tm-snts-smtp: 3CF0205411EC97BD35C4371F485C53C62BB10BC2E38A87D57D668CFFC77581062000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Anima] draft-ietf-acme-star-delegation-05.txt and BRSKI-AE
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 04 Mar 2021 07:08:51 -0000

> From: Michael Richardson <> 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.
Wouldn't this still require that the pledge is able to verify the certificate of the pledge-agent during the first contact? The pledge authentication at the pledge-agent is probably easier, if we assume the pledge-agent knows the signing certificate of the pledge manufacturer. We run into a similar issue with the discussion when using TLS. The pledge (acting as server in PUSH) itself does not have a certificate the has the correct subjectAltName (and the key usages) to perform the verification on the pledge-agent side. Also, the Pledge would not be able to authenticate the pledge-agent until it receives the voucher.

>     > 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.
Yes, that is why we though to utilize the same endpoints (via https)

>     >> 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".
A further alternative may be pledge-client or pledge server.

> 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...)
Yes, this is some point I already put on the slides to have a change in terminology. We discussed this and the agent is actually acting rather as a registrar agent, specifically in the case were it has an LDevID.

Best regards

> --
> Michael Richardson <>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide