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

"Fries, Steffen" <> Tue, 02 March 2021 14:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E5CE33A1912 for <>; Tue, 2 Mar 2021 06:33:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1gkVND9GTHbs for <>; Tue, 2 Mar 2021 06:33:03 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CB0713A1910 for <>; Tue, 2 Mar 2021 06:33:02 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTPS id 936CE468032; Tue, 2 Mar 2021 15:32:59 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTPS id 8DC1B17F29F56; Tue, 2 Mar 2021 15:32:59 +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; Tue, 2 Mar 2021 15:32:58 +0100
Received: from ([]) by ([]) with mapi id 15.01.2106.006; Tue, 2 Mar 2021 15:32:58 +0100
From: "Fries, Steffen" <>
To: Michael Richardson <>, "" <>, "Brockhaus, Hendrik" <>
Thread-Topic: [Anima] draft-ietf-acme-star-delegation-05.txt and BRSKI-AE
Thread-Index: AQHXCI4aI3KJbNx1uESz0kmGFFYTuKpwu3rg
Date: Tue, 2 Mar 2021 14:32:58 +0000
Message-ID: <>
References: <> <23305.1613938428@localhost>
In-Reply-To: <23305.1613938428@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-02T14:32:56Z; 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=e1d1f7d3-4ea0-4cc3-92db-91664304958f; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0
document_confidentiality: Restricted
x-originating-ip: []
x-tm-snts-smtp: 58A7AFD43E24140D6B8DAE516A5AAA71E260B8EC343639A13F4916286F069DD42000: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: Tue, 02 Mar 2021 14:33:05 -0000

Hi Michael,

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. If we assume that the likelihood for DoS attacks  is higher on the registrar side, it is important to protect the registrars endpoints. Specifically, as the registrar cares form multiple components in the domain.
In addition, if the pledge is provided with a registrar certificate to be included in the voucher-request, the pledge-agent and more importantly, the registrar can verify if the voucher-request is coming from an expected pledge as well as if the registrar is the destined registrar for that pledge.

> 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. As the agent transports the signed objects between the pledge and the registrar, this TLS connection is mainly to provide some kind of DoS protection for the registrar endpoints and also enables to utilize the already existing endpoint. Moreover, the registrar could distinguish, if a pledge is 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.

> We have spoken about gathering the voucher-request artifact from the
> pledge with the pledge-agent initiating the communication.  That is, the
> pledge is passive for this, and the pledge-agent initiates.  Some would call
> this PUSH, if they are thinking about things from the pledge point of view.
> But, the pledge-agent has to PULL the voucher-request from the pledge, and
> then PUSH the voucher-request to the RA...
> So, I want to suggest that sections 5.1 and 5.2 be renamed.
> 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 guess I am much more interested in the 5.2 interaction!
> That it could support, for instance, smart-phone + NFC, is very interesting.
> I believe that it should not be session based (i.e. object security, not TLS or
Agreed, this was the intention with the signed object approach to be independent of the transport.

Best regards

> wrote:
>     >         Title : An ACME Profile for Generating Delegated STAR
>     > Certificates Authors
>     > Abstract: This memo proposes a profile of the ACME protocol that allows
>     > the owner of an identifier (e.g., a domain name) to delegate to a third
>     > party access to a certificate associated with said identifier.  A
>     > primary use case is that of a CDN (the third party) terminating TLS
>     > sessions on behalf of a content provider (the owner of a domain name).
>     > The presented mechanism allows the owner of the identifier to retain
>     > control over the delegation and revoke it at any time by cancelling the
>     > associated STAR certificate renewal with the ACME CA.  Another key
>     > property of this mechanism is it does not require any modification to
>     > the deployed TLS ecosystem.
> --
> Michael Richardson <>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide