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

From: "Fries, Steffen" <[email-masked]>
Date: Tue, 2 Mar 2021 14:32:58 +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
> EDHOC).
Agreed, this was the intention with the signed object approach to be independent of the transport.

Best regards
Steffen

> 
> 
> [email-masked] 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 <[email-masked]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 03 Mar 2021 17:16:59 -0500

Fries, Steffen <[email-masked]> wrote:
    >> 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.

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

    >> 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...)

---

From: "Fries, Steffen" <[email-masked]>
Date: Thu, 4 Mar 2021 07:08:42 +0000

> From: Michael Richardson <[email-masked]> wrote:
> 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.

> I think that we can handle attacks on this side.
Yes, that is why we though to utilize the same endpoints (via https)

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

> (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
Steffen