Subject: Re: [Anima] Handling of endpoint path names (from BRSKI-AE discussion today)

From: Michael Richardson <[email-masked]>
Date: Tue, 01 Sep 2020 23:22:38 -0400

Fries, Steffen <[email-masked]> wrote:
    >> -----Original Message-----
    >> From: Michael Richardson <[email-masked]>
    >> Sent: Freitag, 28. August 2020 20:32
    >> > Maybe I phrased it wrong. The intention is not to make the pledge more
    >> > complex. The goal should be to keep the pledge simple and enhance the
    >> > registrar to handle also other situations like unavailability of
    >> > certain connections. The registrar should be the more capable
    >> > component. The discovery was intended in situations, in which the
    >> > registrar supports multipole options, but not all may be mandatory
    >> > supported. In this case the discovery would help. Otherwise the pledge
    >> > may do trial and error.
    >>
    >> While I appreciate the idea of having the pledge fail faster, and go onto to
    >> the next possible registrar, I think that the pledge should support one and
    >> only one mechanism, and it's up to the registrars to keep up.

    > Yes, this keeps the pledge simple, but would require the registrar to
    > implement the other options mandatorily.

*A* Registrar has to implement the right options.
There could be more than one system with the same CA behind them.
I way prefer to just let the pledge implement one thing.

Maybe that will cause significant bifurcation in the BRSKI-capable thing
market, but I suspect that most registrars will implement it all.

    >> If we are doing proper ACP ANIMA, then we can include the enrollment
    >> options for the Registrar into the GRASP DULL announcement, and this can
    >> inform the pledge's decision as to which Registrar to pick.

    > This would also be an option for a  discovery, but I have to dig deeper into GRASP.

okay.

    >> I don't yet understand how the voucher-request is done in async BRSKI.

    > I realize more an more that a pure "request-object" without considering
    > the transport is probably too abstract. Implementing requires also the
    > transport.

Yes, okay, I thought that this was in scope for this document.
Or, when I agreed to adopt, I thought that.

I have quite a few ideas on how to do this: we really ran through them all
during BRSKI/6tisch-zero-touch/SZTP and we settled on a compromise.

    >> I thought that was what we were doing.. I have many ideas about this.

    > Yes, voucher-request and also certification-request would be collected
    > by the pledge-agent. Good to hear you have ideas here, as we need to
    > define the approach more precisely.

    >> > Regarding PUSH. As outlined in BRSKI-AE section 5.2.4 the pledge would
    >> > be queried by the pledge-agent for certain objects. It was intended to
    >>
    >> But, how is it queried?

    > The pledge essentially must be able to listen for the request. In
    > industrial environments the embedded device is most often in a server
    > role waiting for requests. This would have to be leveraged also for the
    > PUSH interaction.

Cool.
I can also see BT and NFC being used for the push.

    >> Well, I thought that the furnace in the basement where there is no
    >> connectivity was a really good use case.
    >> The furnace installer has a smartphone or dedicated comissioning
    >device.

    > This was one of the point I concluded form the last meeting. The trust
    > assumptions about the pledge and pledge-agent interaction is one of the
    > points to be discussed further.

Good.

    >> As for HTTP: I would tend to suggest that we should use CoAP.
    >> This works over WIFI as well as other technologies, and convergence here
    >> would be good.

    > Which may bring it closer to the constraint voucher than BRSKI. I was
    > looking for the latter, hence HTTP as proposal. But this is open for
    > discussion.

:-)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 2 Sep 2020 16:39:43 +1200

>     > This would also be an option for a  discovery, but I have to dig deeper into GRASP.

Let me know if you want to try to specify that. At the moment the only defined
value for the "AN_join_registrar" objective is the string "EST-TLS", but we
could trivially extend it to define another method, or a set of methods.
Also the syntax already allows for multiple announcements in one M_FLOOD
message, so I'd be surprised if we can't do whatever you want. (I had demo
code for announcing a set of methods a long time ago, but I actually
simplified it to only announce "EST-TLS" as BRSKI converged.)

    Brian

> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: Esko Dijk <[email-masked]>
Date: Fri, 18 Sep 2020 11:44:36 +0000

Hi Thomas,

I created a Github issue for constrained-voucher to capture the outcome of this discussion:
https://github.com/anima-wg/constrained-voucher/issues/51

(Reminder: There are also a couple of more open issues. I can work on these too and have already contacted Peter about these.)

Esko

-----Original Message-----
From: Anima <[email-masked]> On Behalf Of Werner, Thomas
Sent: Wednesday, August 26, 2020 17:40
To: Michael Richardson <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Anima] Handling of endpoint path names (from BRSKI-AE discussion today)

Hi Michael,

as already stated the renaming of the endpoints is just a cosmetic issue, machines would not care about.
Nevertheless as this came up now, I think the proposed changes are fine and should be included as you already outlined:
- https://ietf.org/rfcdiff?url1=draft-ietf-anima-bootstrapping-keyinfra-42&url2=https://raw.githubusercontent.com/anima-wg/anima-bootstrap/brski-est-rename/dtbootstrap-anima-keyinfra.txt 
- https://ietf.org/rfcdiff?url1=draft-ietf-anima-bootstrapping-keyinfra-41&url2=https://raw.githubusercontent.com/anima-wg/anima-bootstrap/brski-est-rename/dtbootstrap-anima-keyinfra.txt 

Summary for renaming:
1) /.well-known/est/requestvoucher    [used by pledge to registrar but also from registrar to MASA]
    --> /.well-known/brski/requestvoucher
2) /.well-known/est/voucher_status    [used by pledge to registrar]
  --> /.well-known/brski/voucher_status
3) /.well-known/est/requestauditlog   [used by registrar to MASA]
  --> /.well-known/brski/requestauditlog
4) /.well-known/est/enrollstatus          [used by pledge to registrar]
  --> /.well-known/brski/enrollstatus

Note: 
This changes should be also adopted by: https://tools.ietf.org/html/draft-ietf-anima-constrained-voucher-08 
With the result of two more characters "/est/" --> "brski", maybe the draft-ietf-anima-constrained-voucher should shrink this part to something like  "/br/", "/brs/", "bki"?

Best regards
Thomas

-----Ursprüngliche Nachricht-----
Von: Anima <[email-masked]> Im Auftrag von [ext] Fries, Steffen
Gesendet: Mittwoch, 19. August 2020 15:29
An: Michael Richardson <[email-masked]>
Cc: [email-masked]
Betreff: Re: [Anima] Handling of endpoint path names (from BRSKI-AE discussion today)

> From: Michael Richardson <[email-masked]> Fries, Steffen 
> <[email-masked]> wrote:
>     >> I understand the use case with CoAP, where one wants to be able 
> to multicast a
>     >> request to /.well-known/core to find out which devices support 
> a particular
>     >> service.
>     >> HTTP does not have the same thing, so I don't see the point of 
> agility in the end
>     >> points if they are all in /.well-known anyway.
> 
>     > Agreed. As BRSKI-AE is intended to extend BRSKI and therefore uses
>     > HTTP, there is no need for a specific enhancement. The discovery using
>     > /.well-known will provide all available endpoints to the pledge, which
>     > then can evaluate the response. From an application perspective I would
>     > expect that the pledge may not support multiple enrollment approaches
>     > and simply try whatever he supports. The domain registrar would be the
>     > more capable component to support multiple options.
> 
> Can you explain to me why the discovery via /.well-known/brski is useful?
> This is on the *REGISTRAR*.
The intention was to let the pledge or the pledge-agent know in advance what enrollment options are available at the registrar side allowing the pledge to fail fast if it does not have a matching enrollment protocol. For the original BRSKI, this is not the case, as both sides support the same feature set. In BRSKI-AE allowing alternative enrollment protocols, the registrar may support multiple different ways. To avoid make support for specific protocols mandatory on the registrar side, discovery of supported options was intended. Based on the discussion we had after the last meeting I think the discovery of /.well-known/ would be sufficient.

> In reading BRSKI-AE, I seem to be missing any place where the PUSH 
> mechanism is described.  In a PUSH use case, what protocol would the 
> pledge expose to the pledge-agent and/or commissioner?
This is currently left outside in terms of the protocol. The intention was to only specify the necessary (signature wrapped) data objects to be exchanged, to be open regarding the underlying transport between the pledge and the pledge-agent. This also would allow to use an arbitrary pledge-agent, but this is up for discussion. I'm currently thinking about the necessity to be able to authenticate the pledge-agent using an LDevID, if we solely rely on the objects. Authentication could also be done using HTTP authentication merely to authorize the pledge-agent to act as proxy between the pledge and the registrar. 

> As far as I can tell, in the PULL case, when CMP (or another 
> mechanism) will be used, there is still a voucher exchange first.  The 
> Registrar can express it's preference in the (parboiled) voucher-request from Registrar to MASA.
PULL was meant to describe the behavior of the pledge to start the onboarding while PUSH was more the trigger from the pledge-agent.
As the enrollment is between the pledge, the registrar, and the CA, I would not see a need to include this information in the voucher. This should be done as outlined in BRSKI. 
> 
> The MASA, if the pledge supports the desired enrollment protocol, 
> could include the hint.  In fact, the MASA could include an entire URL 
> with meta- data about the protocol to use.
> 
> This would jive very nicely with the brski-cloud mechanism!!!
Hm, haven't though about this. In case of standard BRSKI I would not see a need, as it would be handled by the domain registrar, but in case of the cloud registrar, it would provide the option to point to the right domain registrar supporting the enrollment. 

> 
>     > For the constraint case (not contained in BRSKI), the discovery of
>     > specific endpoints is more important to not overload the pledge.
> 
> I don't understand this at all.  What do you mean, overload the pledge?
> Are you talking about network or code space or what?
I was referring to the discovery of specific endpoints. In case of /.well-known the registrar would deliver all endpoints including their options supported, while in case of asking for a specific endpoint only delivers the specific options of that endpoint. What I meant to say was that the pledge only gets the necessary information about the endpoints he needs not all. So it would relate to the processing on the pledge. 

> 
>     >> If there is value in renaming, then lets do it RIGHT NOW.
>     >> I DO NOT WANT to confuse the market by having an RFC come out, 
> followed by
>     >> another one 'correcting' it six months later.
>     >> I CAN NOT live with that situation.
> 
>     > As stated before, the value from my understanding is more clarity
>     > (distinct naming) regarding the provided services/endpoints.
> 
> yes, but that's a cosmetic issue.
> it appeals to humans, but it makes no technical difference.
> Nevertheless, if we can do this quickly, then let's do it.
> I've provided proposed text in the form of a diff, the ADs have agreed 
> to a process, the chairs , just need to run it.
It may be cosmetic, but it would be consistent regarding the functionality provided by the specific endpoint if alternative enrollment options are used.  

> 
> I hope that your(Siemens) Thomas Werner will comment.
I will give him a trigger ;-)

Best regards
Steffen

_______________________________________________
Anima mailing list
[email-masked]
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fanima&amp;data=02%7C01%7Cthomas-werner%40siemens.com%7Cff1afabca2014c1fa20208d84443e0f9%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637334405616918902&amp;sdata=cL0Aa22O9Ef7QYWEEME%2Bvjb5aRTj%2BGxhlCYqfWBuUoY%3D&amp;reserved=0

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Sep 2020 15:59:53 -0400

> https://github.com/anima-wg/constrained-voucher/issues/51

Thank you.

    > (Reminder: There are also a couple of more open issues. I can work on
    > these too and have already contacted Peter about these.)

I think that we can finally start digging these items out of the ditch
created by ACP and BRSKI stalling up the process.

In constrained-voucher/brski, there is a CoAP RD call:

     REQ: GET /.well-known/core?rt=ace.est*

     RES: 2.05 Content
     </est>; rt="ace.est"
     </est/rv>; rt="ace.est/rv";ct=TBD2 TBD3
     </est/vs>; rt="ace.est/vs";ct=50 60
     </est/es>; rt="ace.est/es";ct=50 60
     </est/ra>; rt="ace.est/ra";ct=TBD2 TBD3

I don't really know how to ask for multiple things.
  Clearly, we should be asking for "ace.brski" now?
  Do we have to change our allocation somewhere?
  I don't see any IANA activity around rt=ace.est/rv, unless it's section 9.1?
  which regisgters things, but I don't understand why it asks for ranges,
  because I have no idea where those *numbers* would go.
  I probably just don't know enough about this stuff.

I think that RFC6690 should probably be a normative reference.

I guess that we would have gotten all of the end points associated with
draft-ietf-ace-coaps-est when we above asked for ace.est.

RFC6690, section 4.1 [
   https://www.rfc-editor.org/rfc/rfc6690.html#section-4.1 ]

does not seem to permit two or three things to be returned, just wildcards.
What would happen if, when asked for rt=anima.brski, that it returned the
entries for ace.est and/or blah.cmp?

Is it late enough that we could just switch to CoRAL?
Do I even understand what means.

---

From: Esko Dijk <[email-masked]>
Date: Mon, 21 Sep 2020 09:08:05 +0000

I added some comments on below questions on Github https://github.com/anima-wg/constrained-voucher/issues/51 .

In summary, you can ask for both resources of type ace.est and ace.brski by doing a wildcard query:
GET /.well-known/core?rt=ace.*

However this not only returns the two (intended?) resources ace.est and ace.brski, but also all the subtypes of these which is: 
ace.est.rv, ace.est.vs, ace.est.es, ace.est.ra

Note that the '/' in the rt name is not permitted by RFC 6690, it should be a '.' to indicate the hierarchy here. Created issues #54 for this.

Alternatively one can discover two times:
GET /.well-known/core?rt=ace.est
GET /.well-known/core?rt=ace.brski

This gets exactly the main resources but not the sub-resources below it separately. From the main resources the sub-resources are automatically inferred (i.e. the standard names 'rv', 'vs', 'es', and 'ra'.)
Doing this will reduce the amount of data transferred over the constrained network but adds an extra message roundtrip.

Section 9.1 needs to be extended to a proper IANA registration, and it should include these types:
ace.est
ace.est.rv
ace.est.vs
ace.est.es
ace.est.ra
(or the equivalent types 'ace.brski.*' in case we decide to change namespace est to brski  . Or maybe consider 'anima.brski.*'  or just 'brski.*' as the root rt namespace because BRSKI originated not in ACE WG scope but in ANIMA WG! )

Note that in my opinion all this discovery adds unnecessary complexity and overhead in the constrained node/network, so I created a proposal to also allow the .well-known resources that BRSKI is already using.  Why make something less efficient than the unconstrained protocol and force clients to use it ... ?
See issue #53  https://github.com/anima-wg/constrained-voucher/issues/53 
Note that ACE-coap-EST also supports the .well-known resources.

Esko

-----Original Message-----
From: Michael Richardson <[email-masked]> 
Sent: Friday, September 18, 2020 22:00
To: Esko Dijk <[email-masked]>; Werner, Thomas <[email-masked]>; [email-masked]; [email-masked]
Subject: constrained handling of endpoint path names (from BRSKI-AE discussion today)

Thank you.

     RES: 2.05 Content
     </est>; rt="ace.est"

RFC6690, section 4.1 [

---

From: Michael Richardson <[email-masked]>
Date: Mon, 21 Sep 2020 11:10:38 -0400

Esko Dijk <[email-masked]> wrote:
    > I added some comments on below questions on Github
    > https://github.com/anima-wg/constrained-voucher/issues/51 .

    > GET /.well-known/core?rt=ace.*

Right.

    > However this not only returns the two (intended?) resources ace.est and
    > ace.brski, but also all the subtypes of these which is:

I think that we'd want them all anyway, but if course, we'd get anything else
under ace. (other than est and brski).

    > Note that the '/' in the rt name is not permitted by RFC 6690, it
    > should be a '.' to indicate the hierarchy here. Created issues #54 for
    > this.

Understood, thank you for the fix.

    > This gets exactly the main resources but not the sub-resources below it
    > separately. From the main resources the sub-resources are automatically
    > inferred (i.e. the standard names 'rv', 'vs', 'es', and 'ra'.)
    > Doing this will reduce the amount of data transferred over the
    > constrained network but adds an extra message roundtrip.

Yes, exactly.

    > Note that in my opinion all this discovery adds unnecessary complexity
    > and overhead in the constrained node/network, so I created a proposal
    > to also allow the .well-known resources that BRSKI is already using.
    > Why make something less efficient than the unconstrained protocol and
    > force clients to use it ... ?

I also agree.
In my opinion the only reason to do this discovery is to enable multicast RD,
such as I think that brski-ae really wants to do.

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