Subject: Re: [Anima] BRSKI design team meeting on Thursday

From: Michael Richardson <[email-masked]>
Date: Sun, 04 Jul 2021 19:30:07 -0400

Esko Dijk <[email-masked]> wrote:
    > Let's meet tomorrow and see who is there and what we can discuss.  In particular, the following would be useful agenda points

    > * July constrained-voucher interop: define the details to use for the
    > Registrar <-> MASA interface. For example, is the following supported
    > if we try Registrar/MASA interop of different implementations:

Thanks for nailing this down.  I thought that
  https://docs.google.com/document/d/1T8Rtfk1zia_p05_6eb_WQA2Mmid-eP1-cAgnwdpF9Xk/edit?usp=sharing

and the documents already said:

    > - Registrar's Voucher Request:  application/voucher-cms+json over HTTPS  , per [RFC 8995]

    > - MASA's Voucher Response: application/voucher-cose+cbor over HTTPS
    > (Registrar client included an Accept header indicating this
    > Content-Type)

I guess I'm wondering why this is still uncertain?

    > - MASA does not verify client authorization (i.e. any Registrar client
    > is allowed to connect with TLS)

I think that Siemens-BT requires that it knows about the Registrar.
Thomas, can you confirm?  Can we collect Registrar client certificates as go
into the Hackathon?

I'll also say that my Registrars support hostname:9443/version.json
and hostname:9443/status.json.  I accept this from any origin, not validating
the TLS Client Certificate.

I wonder if an additional target like, "/diag.json", or "/diag.cbor" (or
using Accept: headers), which does validate the TLS Client Certificate, and
then spits back some info about what it thought about the client.
Would that be useful to people writing Registrars?

    > - Registrar does not verify MASA server is authorized (i.e. any MASA
    > server is allowed to connect with TLS)

This could mean a few things:
  1) Registrar doesn't verify MASA TLS Server Certificate at all.
  2) Registrar will only connect to MASA with configured TLS anchors,
     including possibly WebPKI list of anchors.
  3) Registrar will only onboard devices with Manufacturer's listed as
     trusted.
     (In the context of above statement, it means that Registrar will
     operate with any manufacturer, that is, not{3})

    > * New issue #122: Use of CoAP 4.03 Forbidden vs 4.01 Unauthorized
    > - https://github.com/anima-wg/constrained-voucher/issues/122

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

---

From: "Werner, Thomas" <[email-masked]>
Date: Mon, 5 Jul 2021 12:27:43 +0000

> -----Original Message-----
> From: Anima <[email-masked]> On Behalf Of Michael Richardson
> Sent: Montag, 5. Juli 2021 01:30
> To: Esko Dijk <[email-masked]>; [email-masked]
> Subject: Re: [Anima] BRSKI design team meeting on Thursday
> 
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1T8Rtfk1zia_p05_6eb
> _WQA2Mmid-eP1-cAgnwdpF9Xk%2Fedit%3Fusp%3Dsharing&amp;data=04%7C01%7Cthomas-
> werner%40siemens.com%7Cf8edf21940f545cc69c908d93f43b66c%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6376103827
> 83828128%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&a
> mp;sdata=QfiW96r3BzSDsQzAlTAtKY4tiM73BaGIjW%2FvMHcMDJ8%3D&amp;reserved=0
> 
> Thomas, can you confirm?  Can we collect Registrar client certificates as go into the Hackathon?
Our Siemens interop MASA  is not enforcing TLS client authentication of a registrar.
But checks the "registrar-voucher-request" signature, think this was meant by "knows about the Registrar ".
So a trust anchor of the "registrar-voucher-request" signing cert is required, should be collected in advance to the Hackathon (or I could get it from the MASA logs, which is more effort during testing)

> 
> I'll also say that my Registrars support hostname:9443/version.json and hostname:9443/status.json.  I accept this from any origin, not
> validating the TLS Client Certificate.
> 
> I wonder if an additional target like, "/diag.json", or "/diag.cbor" (or using Accept: headers), which does validate the TLS Client
> Certificate, and then spits back some info about what it thought about the client.
>     > - https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fanima-wg%2Fconstrained-
> voucher%2Fissues%2F122&amp;data=04%7C01%7Cthomas-
> werner%40siemens.com%7Cf8edf21940f545cc69c908d93f43b66c%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6376103827
> 83838119%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&a
> mp;sdata=bo8rZ7uyDjd0Sg9IO3GWjOmQL6G2ykuPGthUJ4XVUyw%3D&amp;reserved=0
> 
> 
> 
> --

---

From: Esko Dijk <[email-masked]>
Date: Mon, 5 Jul 2021 13:31:55 +0000

Hi Michael,

Maybe I should've looked into the document first - sorry.
The online doc actually says that the Registrar will send out the voucher request format to MASA which is equal to the voucher request format it received. So, typically [for constrained-voucher implementations] this is COSE-signed-CBOR. My proposal was to send CMS-signed-JSON always by the Registrar. That was because I didn't saw a reason to deviate from RFC 8995 on the unconstrained network path between Registrar and MASA. But MASA supporting both methods could also be an option for the interop.

> I wonder if an additional target like, "/diag.json", or "/diag.cbor"
That sounds useful for debugging.

With the following
>     - Registrar does not verify MASA server is authorized (i.e. any MASA server is allowed to connect with TLS)
I meant that the Registrar client will not abort the TLS handshake to MASA server for pure authentication/authorization reasons. Such reasons for typically aborting the TLS handshake may be
1* MASA's server certificate is not set to explicitly 'trusted' in a trust store of the Registrar
2* MASA's server certificate does not have a dnsName field in it
3* MASA's server certificate does have a dnsName in it but it does not match the DNS hostname used to contact the MASA server
For other reasons (e.g. format errors, incorrect signature, etc.) it can of course abort the handshake. In my HTTPS client I saw that by default reasons 1/2/3 are enough to abort the connection; so the HTTPS client's verification level has to be lowered, and it seems good if implementations are doing so / are aware of this prior to the interop.

Best regards
Esko

---

From: Michael Richardson <[email-masked]>
Date: Wed, 14 Jul 2021 13:37:44 -0400

Peter has sent me some constrained voucher requests to process.

1) he used secp256k1 rather than secp256r1 (aka prime256r1).
   {I'm terrible at remembering which is which)

   secp256r1 is, I think, the one more commonly implemented in hardware, and
   which is used extensively in the webpki as the replacement for RSA.

   secp256k1 is used in Bitcoin.

   Our document says that both are MUST.
   I wonder if we shouldn't pick one ECDSA curve, and if we want a backup
   algorithm (we so), that we pick EDDSA/25519.

2) The kid contains what I think is the hash of public key, as clearly
   indicated in section 8.3, where the example says:

      h'A101382E',        # { "alg": EC256K1 }
       {
         "kid" : h'7890....1234'  # hash256(public key)
       },

(no wonder Peter used EC256K1!)

The problem that I have is that I don't have the public key for his Registrar.
It wasn't included in an x5bag, nor as a TLS Client Side Certificate, so I
can't validate anything.  I'd have to have registered the Registrar a priori.

Pre-registration is a supported mechanism.  For this case, where everything
is that way, I return a 406.    I wonder if 401 or 403 might be better in
this case.... or do we perhaps need new returns.

I prefer to always be able to support TOFU MASA, even if that policy is
turned off, so I think that Registrars need to always provide their signing
key in x5bag.
If doing x5bag, it seems wasteful to then include kid.

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

3) In our SID assignment diagram, in 8.1.2,  We have some sorting that
   relates to voucher and then voucher-request.
   The dump in -12 is just screwed up, and I appologize for that.
   I'm not sure what happened that resulted in the duplication.
   The sorting is by SID value.   Should we invert and present this more as a table?
   I'm trying to make sure that it's driven by pyang.

4) I have removed the comment in section 8 relating to http://comi.space.

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