Re: [Anima] [media-types] Thoughts on suffixes, single and multiple

[Esko Dijk]

> The utility to the community is that if a dissector (debug tool) can see it's
> a signature, then it can, even without verifying the signature, dig down into
> the payload to show a developer what's what.   It seems reasonable to common
> tools will evolve to decode JWS and COSE, but not necessarily know what a
> voucher is.

I fully agree with this! A generic +jws or +cose or +cbor or +json viewer with 
syntax and 
component highlighting  would be super useful -- just like we have generic .txt 
/ .json / .c  file viewers today. 
For +cose for example, the viewer can immediately extract the signed payload 
part without necessarily 
knowing how to validate the signature, or knowing what key it needs for that.

> Or maybe I should reverse this: in order for common tools to evolve, we need
> clear signals about the encoding of the signature blob.

Agree even more here :-)   

For the cBRSKI draft I looked at multiple suffixes, but saw it as getting too 
complex for us / the 
target population to understand and correctly apply. Without much benefit.  A 
single +name prefix is
useful however.

> I think that application/voucher-cms+json in RFC8366 was in the wrong.
> It should have been application/voucher-json+cms

Yes, I also saw this a while back - the +cms at the end would have been the 
right thing. 
A generic +cms viewer could for example extract, or highlight the payload and 
also separately
show the signing certificates even without necessarily being able to validate 
the CMS.
The CMS structure itself can also contain a number indicating the payload type, 
in eContentType.
The viewer can optionally use this to render the payload better.
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Lightweight GRASP

[Esko Dijk]

One nice thing about CoAP is that it has also been defined/used over other 
transports, that are not UDP. Like directly over a serial link or over SMS.  
This was another potential use case: to use GRASP when there's not even IP 
connectivity yet.

The charter says this about a potential new "lightweight GRASP":

Generic use cases of Autonomic Network and new GRASP extensions/options for 
them

If one sees it as an extension of GRASP (ability to run over non-TCP, UDP, or 
non-IP transports) then it does fit in charter.

Defining some use cases would be relevant also - if it's a wired ANI then we 
don't have a huge amount of changes in links over times. If it's a wireless 
(e.g. 6LoWPAN) ANI then this may be the case. 
Even if mesh links are highly variable over time, resulting in more packet loss 
(e.g. 6LoWPAN situations), TCP may still work ok if it's tuned to this use 
case. OpenThread's TCP implementation was I believe tuned in this way based on 
work of Sam Kumar
(see https://www.usenix.org/conference/nsdi20/presentation/kumar ) . In 
Thread's case, even when links change and mesh topology changes the nodes still 
keep their original IPv6 address so the TCP communication can continue in 
principle.  I never tested TCP performance yet in this case, but it would be 
interesting to see if there's a problem there or not, depending on the level of 
links change.

Esko

-Original Message-
From: Anima  On Behalf Of Brian E Carpenter
Sent: Monday, March 18, 2024 09:38
To: 蒋胜 (Sheng Jiang) ; Anima WG 
Subject: [Anima] Lightweight GRASP

I think it would be good to see a first draft on this, with some ideas about 
UDP and COAP instead of TCP.
  
Regards
Brian

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] RFC 8995, Voucher Signing, MASA Certificate Chain provisioning

[Esko Dijk]

PS for the equivalent cBRSKI consideration, see also 
https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-voucher-24#name-signing-of-voucher-by-masa,
 third paragraph.


From: Anima  On Behalf Of Esko Dijk
Sent: Friday, March 8, 2024 12:41
To: Fries, Steffen ; anima@ietf.org
Subject: Re: [Anima] RFC 8995, Voucher Signing, MASA Certificate Chain 
provisioning

Hi Steffen,

> it would mean to provide the MASA certificate chain also in the pledge 
> firmware

This is one way to do it. The simplest solution is only include the public key 
of the signer (MASA), also allowed by the 9.1.1 text. In this case, it's less 
flexible: the MASA service can't go sign with another identity/private-key: it 
MUST sign with the private key associated with the public key that's already 
baked into the Pledge.
In case a whole chain is included in the Pledge firmware as you propose, the 
validation can be a bit more flexible I think.

The requirement for the Pledge in RFC 8995 is (5.6.1):
The pledge MUST verify the voucher signature using the manufacturer-installed 
trust anchor(s) associated with the manufacturer's MASA

This leaves quite some vendor flexibility I think on how exactly to verify: 
against 1 public key, against multiple public keys, against a chain baked into 
the device, against a single root CA cert, against a single root CA cert taken 
from the chain baked into the device, etc etc.

> I would propose to also allow the submission of the certificate chain of the 
> MASA signing certificate in the SignedData part of the CMS container of the 
> voucher.

I expect this is already allowed by RFC 8995, given the text in 11.6:

There are good cryptographic hygiene reasons why a manufacturer would not want 
to maintain access to a private key for many decades. A manufacturer in that 
situation can leverage a long-term CA anchor, built-in to the pledge, and then 
a certificate chain may be incorporated using the normal CMS certificate set. 
This may increase the size of the voucher artifacts, but that is not a 
significant issue in non-constrained 
environments.¶<https://datatracker.ietf.org/doc/html/rfc8995#section-11.6-3>
So this effectively says a vendor may want to not use the "simplest solution" 
for security reasons, and include a cert chain of the signer.

Regards
Esko


From: Anima mailto:anima-boun...@ietf.org>> On Behalf 
Of Fries, Steffen
Sent: Wednesday, March 6, 2024 16:41
To: anima@ietf.org<mailto:anima@ietf.org>
Subject: [Anima] RFC 8995, Voucher Signing, MASA Certificate Chain provisioning

Hi Michael,

I've got a question regarding the MASA voucher signing or better the 
certificate chain provisioning for the MASA certificate to the pledge.

RFC 8995 states in section 91.1. 
(https://www.rfc-editor.org/rfc/rfc8995.html#section-9.1.1)
"The online service MUST have access to a private key with which to sign 
voucher artifacts 
[RFC8366<https://www.rfc-editor.org/rfc/rfc8995.html#RFC8366>]. The public key, 
certificate, or certificate chain MUST be built into the device as part of the 
firmware."

I had the assumption that the pledge only knows its IDevID and with that his 
own certificate, public/private key pair and the certificate chain from the 
issuing CA to the trust anchor.
In operational environments the issuing CA for the IDevID may not be the same 
as the issuing CA for the MASA signing certificate. From the requirement above, 
it would mean to provide the MASA certificate chain also in the pledge 
firmware, if it is different than the IDevID issuing CA. As the voucher is a 
CMS container that allows to convey the certificate chain of the signer in the 
SignedData, I would have expected it is contained there. This would be similar 
to the voucher request, in which the registrar-voucher-request also contains 
the certificate chain according to section 5.5.2 
(https://www.rfc-editor.org/rfc/rfc8995.html#section-5.5.2), which states:
"A certificate chain is extracted from the registrar's signed CMS container. "

I would propose to also allow the submission of the certificate chain of the 
MASA signing certificate in the SignedData part of the CMS container of the 
voucher.
Any thoughts?

Best regards
Steffen
--
Steffen Fries



___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] RFC 8995, Voucher Signing, MASA Certificate Chain provisioning

[Esko Dijk]

Hi Steffen,

> it would mean to provide the MASA certificate chain also in the pledge 
> firmware

This is one way to do it. The simplest solution is only include the public key 
of the signer (MASA), also allowed by the 9.1.1 text. In this case, it's less 
flexible: the MASA service can't go sign with another identity/private-key: it 
MUST sign with the private key associated with the public key that's already 
baked into the Pledge.
In case a whole chain is included in the Pledge firmware as you propose, the 
validation can be a bit more flexible I think.

The requirement for the Pledge in RFC 8995 is (5.6.1):
The pledge MUST verify the voucher signature using the manufacturer-installed 
trust anchor(s) associated with the manufacturer's MASA

This leaves quite some vendor flexibility I think on how exactly to verify: 
against 1 public key, against multiple public keys, against a chain baked into 
the device, against a single root CA cert, against a single root CA cert taken 
from the chain baked into the device, etc etc.

> I would propose to also allow the submission of the certificate chain of the 
> MASA signing certificate in the SignedData part of the CMS container of the 
> voucher.

I expect this is already allowed by RFC 8995, given the text in 11.6:

There are good cryptographic hygiene reasons why a manufacturer would not want 
to maintain access to a private key for many decades. A manufacturer in that 
situation can leverage a long-term CA anchor, built-in to the pledge, and then 
a certificate chain may be incorporated using the normal CMS certificate set. 
This may increase the size of the voucher artifacts, but that is not a 
significant issue in non-constrained 
environments.¶
So this effectively says a vendor may want to not use the "simplest solution" 
for security reasons, and include a cert chain of the signer.

Regards
Esko


From: Anima  On Behalf Of Fries, Steffen
Sent: Wednesday, March 6, 2024 16:41
To: anima@ietf.org
Subject: [Anima] RFC 8995, Voucher Signing, MASA Certificate Chain provisioning

Hi Michael,

I've got a question regarding the MASA voucher signing or better the 
certificate chain provisioning for the MASA certificate to the pledge.

RFC 8995 states in section 91.1. 
(https://www.rfc-editor.org/rfc/rfc8995.html#section-9.1.1)
"The online service MUST have access to a private key with which to sign 
voucher artifacts 
[RFC8366]. The public key, 
certificate, or certificate chain MUST be built into the device as part of the 
firmware."

I had the assumption that the pledge only knows its IDevID and with that his 
own certificate, public/private key pair and the certificate chain from the 
issuing CA to the trust anchor.
In operational environments the issuing CA for the IDevID may not be the same 
as the issuing CA for the MASA signing certificate. From the requirement above, 
it would mean to provide the MASA certificate chain also in the pledge 
firmware, if it is different than the IDevID issuing CA. As the voucher is a 
CMS container that allows to convey the certificate chain of the signer in the 
SignedData, I would have expected it is contained there. This would be similar 
to the voucher request, in which the registrar-voucher-request also contains 
the certificate chain according to section 5.5.2 
(https://www.rfc-editor.org/rfc/rfc8995.html#section-5.5.2), which states:
"A certificate chain is extracted from the registrar's signed CMS container. "

I would propose to also allow the submission of the certificate chain of the 
MASA signing certificate in the SignedData part of the CMS container of the 
voucher.
Any thoughts?

Best regards
Steffen
--
Steffen Fries


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] Standards/specs using "YANG to CBOR" encoding

[Esko Dijk]

Hi Toerless,

Yesterday in the design team call you asked if any specifications use the "YANG 
to CBOR" mapping (RFC 9254), apart from us (cBRSKI).
In the call we forgot to mention this user:  "CORECONF" 
(https://datatracker.ietf.org/doc/html/draft-ietf-core-comi-17) , a 
CoAP-with-CBOR version of NETCONF/RESTCONF.

Regards
Esko

IoTconsultancy.nl  |  Email/Teams: esko.d...@iotconsultancy.nl


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] Pending updates for cBRSKI draft & new version this week

[Esko Dijk]

Hi Michael, all,

For cBRSKI I made some PRs with new text - still available for comments here: 
https://github.com/anima-wg/constrained-voucher/pulls

I'm planning to integrate these PRs this week and publish a new version of the 
draft.

Best regards,
Esko


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Errata 6642: Re: Registrar to MASA connections: SNI required

[Esko Dijk]

> I think we had a long enough discussion time about this so everybody who has 
> an opinion
Ok, agreed. I'm okay with the proposed change you sent to Rob!

> And again, this thread is just for the RFC8995 Register/MASA section Errata.
Good; some of the thread seemed to imply the Pledge would send SNI but that was 
only suggested for the Cloud-Registrar case then, probably.

Small addendum: Even if RFC 6066 would allow IP literals in a SNI (which it 
doesn't), then it still could not be used by a Pledge. Reason is that a Pledge 
would discover only the IP literal of a Proxy and not the one of the Registrar. 
So the Registrar would receive SNI with an incorrect IP address in it in that 
hypothetical case. So it wouldn't work anyway.

Esko

-Original Message-
From: Toerless Eckert  
Sent: Thursday, February 15, 2024 17:52
To: Esko Dijk 
Cc: Michael Richardson ; rwil...@cisco.com; 
anima@ietf.org
Subject: Re: [Anima] Errata 6642: Re: Registrar to MASA connections: SNI 
required

Trying to find better rules for the process without success, so i think
that it's up to Rob to determine whethrer he wants additional input from the WG
or simply accept/reject the proposed text change based on his own evaluation.

I think we had a long enough discussion time about this so everybody who has an 
opinion
did have a chance to chime in.

And again, this thread is just for the RFC8995 Register/MASA section Errata.
The discussion about my github request in BRSKI cloud Pledge->Registrar is 
independent.
Sending of SNI is an application choice as explained in TLS 1.3 (probably also
in RFC6066), so it really needs to be decided by each application function, 
although
it seems as if the rule of thumb is to always send it as long as the TLS 
responder
is known by DNS hostname. But it seems neither RFC6066 nor TLS 1.3 make this a 
rule.

Cheers
Toerless

On Thu, Feb 15, 2024 at 12:54:19PM +0000, Esko Dijk wrote:
> Shouldn't the ANIMA WG also agree on a new text or a new concept for an 
> erratum?  
> And who are "all parties"? For me this is just too vague.
> 
> Esko
> 
> -Original Message-
> From: Anima  On Behalf Of Michael Richardson
> Sent: Wednesday, February 14, 2024 19:54
> To: Toerless Eckert 
> Cc: rwil...@cisco.com; anima@ietf.org
> Subject: Re: [Anima] Errata 6642: Re: Registrar to MASA connections: SNI 
> required
> 
> 
> Toerless Eckert  wrote:
> >> I'm fine with this.  But, since it's hold for document update, we
> >> don't have to wordsmith it now, as long as we get across the right
> >> idea in the patch.
> 
> > Well, my understanding is that Rob simply wants a replacement text for
> > the Errata that we both agree on so he can update the Errata with it.
> 
> All of the text you have proposed is fine with me in the end.
> Short of it: all parties always send SNI.
> 
> (Registrar must often ignore SNI upon receipt)
> 
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 

-- 
---
t...@cs.fau.de

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Errata 6642: Re: Registrar to MASA connections: SNI required

[Esko Dijk]

Shouldn't the ANIMA WG also agree on a new text or a new concept for an 
erratum?  
And who are "all parties"? For me this is just too vague.

Esko

-Original Message-
From: Anima  On Behalf Of Michael Richardson
Sent: Wednesday, February 14, 2024 19:54
To: Toerless Eckert 
Cc: rwil...@cisco.com; anima@ietf.org
Subject: Re: [Anima] Errata 6642: Re: Registrar to MASA connections: SNI 
required


Toerless Eckert  wrote:
>> I'm fine with this.  But, since it's hold for document update, we
>> don't have to wordsmith it now, as long as we get across the right
>> idea in the patch.

> Well, my understanding is that Rob simply wants a replacement text for
> the Errata that we both agree on so he can update the Errata with it.

All of the text you have proposed is fine with me in the end.
Short of it: all parties always send SNI.

(Registrar must often ignore SNI upon receipt)

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




___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Errata 6642: Re: Registrar to MASA connections: SNI required

[Esko Dijk]

Just wanted to double-check this part:

> > Pledges MUST include SNI for 1.2 and 1.3.
>
> Right. Except for language maybe using the "server-name" terminology as the 
> TLS 1.3 RFC.

Instead of "Pledges", it should say "Registrars" here, right?

Esko


-Original Message-
From: Anima  On Behalf Of Toerless Eckert
Sent: Tuesday, February 13, 2024 03:05
To: Michael Richardson 
Cc: rwil...@cisco.com; anima@ietf.org
Subject: Re: [Anima] Errata 6642: Re: Registrar to MASA connections: SNI 
required

On Mon, Feb 12, 2024 at 09:01:50AM -0500, Michael Richardson wrote:
> 
> Toerless Eckert  wrote:
> > agile. But SNI is one such example, where the pledge does need to
> > signal the right info (SNI) to enable "cheaper" cloud registrars, aka:
> > those not owning a separate IPv4 address. See e.g.: AWS cost for IPv4
> > address.
> 
> Right, but it's self-righting.
> A manufacturer that uses an SNI-only cloud registrar and does not do SNI will
> fail immediately: they won't get out of the lab.  And the manufacturer
> controls both initial sides of this.

Just to double check: in this thread we're only talking registrar to MASA (no 
pledges).

Then the biggest risk is when there are a lot of Registrar instances out in the
field and the company wants to make the MASA service cheaper by putting it into
some cloud service data center from a third party, and only then wake up and see
that that cloud data center (opposed to the vendors original own data center) 
does
require SNI. So now, the vendor needs to update all Registrars in the field.

Aka: IMHO serious enough that it justifies the one sentence we can write 
upfront to
avoid this.

> Where we could go into trouble is when there are 307 redirects.

Explain ? Or separate thread ?
> 
> > Lets just agree on the final text for this errata so Rob can close the
> > book on it.
> 
> Pledges MUST include SNI for 1.2 and 1.3.

Right. Except for language maybe using the "server-name" terminology as the TLS 
1.3 RFC.

> (Registrar's with provisional-TLS connections MUST ignore the SNI: they can
> not be virtual-hosted)
> 
> If you didn't like my errata text, then let's come back to that.
> (I wish errata was on gitlab)
> 
> https://www.rfc-editor.org/errata/eid6642
> 
> says:
> Held for Document Update by: Rob Wilton
> Date Held: 2024-01-15
> 
> so we get another chance to fix the text when we do a document update.
> Does the text that is there upset you?

Yes, to repeat what i said in the first email of this thread:

1. the way you wrote it, you replace the whole two sentences, aka: you remove:

   Use of TLS 1.3 (or newer) is encouraged.  TLS 1.2 or newer is 
   REQUIRED.  TLS 1.3 (or newer) SHOULD be available.

   I am sure you wanted your text to be ADDED after those two sentences.

2. "TLS 1.2 [RFC5246] with SNI support [RFC6066] is REQUIRED if 
   TLS 1.3 is not available."

   This does not say that Registrars must send SNI/"server-name". It
   just means the TLS stack on registrars/MASA needs to be able to support
   SNI. And i am a fourth degree burn victim of text like this.  Many
   customers who could not deploy multicast appropritely because
   they believed vendor text "device supports IGMPv3" was sufficient, when 
instead
   what was required was: "(IPTV) application MUST use SSM signalling via 
IGMPv3".
   (see also the TLS 1.3 text related to this "server-name" support vs. 
application
   support).

   Aka: 

   Append to the section 5.4 text from above the following:

   When the MASA is known to the registrar by its domain name,
   the registrar MUST send the domain name of the MASA in the
   TLS "Server Name Indicator" (SNI) option (also called "server-name")
   [RFC6066] whether TLS 1.2 [RFC5246] or TLS 1.3 [RFC8446] is used.

   SNI is required when the Registrar communicates with the MASA in
   order for the MASA to be hosted in a modern multi-tenant TLS infrastructure 
where
   it shares its IP/IPv6 address with other HTTPS services.

Cheers
Toerless

> -- 
> ]   Never tell me the odds! | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works|IoT architect   [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
> [
> 



-- 
---
t...@cs.fau.de

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adoption call on draft-eckert-anima-brski-discovery-01 by 2024/2/23rd

[Esko Dijk]

Hi Sheng, all,

I support the adoption of this document.

Best regards
Esko

-Original Message-
From: Anima  On Behalf Of Sheng JIANG
Sent: Friday, February 9, 2024 09:29
To: anima 
Cc: anima-chairs ; rwilton 
Subject: [Anima] Adoption call on draft-eckert-anima-brski-discovery-01 by 
2024/2/23rd

Hi, ANIMAers,

This email starts a two-week adoption call on 
draft-eckert-anima-brski-discovery-01. It ends by 2024/2/23rd.

This draft is not new as normal -01 individual draft. It is coalesced from the 
discovery options parts of several ANIMA WG documents:

draft-ietf-anima-brski-prm
draft-ietf-anima-brski-ae
draft-ietf-anima-brski-constrained-voucher
draft-ietf-anima-brski-constrained-proxy


It has been introduced and discussed during the Prague meeting. Hence, the 
ANIMA chairs think it has a reasonable good foundation for adoption. Please 
express your opinions on whether this document is meaningful for our ANIMA WG 
by the ending time 2024/2/23rd. The writing quality of this document is a late 
consideration after WG adoption.

Regards,


Sheng JIANG


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [Technical Errata Reported] RFC8995 (7263)

[Esko Dijk]

Thanks Rob,

Not sure if the 7263 got discussed on the call (probably not), but the 
discussion thread on it leads to your current proposal and I’m okay with that.

Just on the side, I’m still wondering if this is helping overall, because for 
other fields there is similar wording used like “X is included”  and in those 
other cases we don’t have errata to change these to a MUST.   And all these 
requirements are effectively MUST. But maybe such consistency isn’t so 
important. The language in the given context may be just more unclear to some 
readers, for some fields/parameters.

Esko


From: Rob Wilton (rwilton) 
Sent: Monday, January 15, 2024 11:44
To: Buschart, Rufus ; Esko Dijk 
; Michael Richardson 
Cc: RFC Errata System ; Max Pritikin (pritikin) 
; tte+i...@cs.fau.de; michael.h.behrin...@gmail.com; 
kent+i...@watsen.net; war...@kumari.net; t...@cs.fau.de; 
shengji...@bupt.edu.cn; anima@ietf.org
Subject: RE: [Anima] [Technical Errata Reported] RFC8995 (7263)

Hi,

I’m attempting to work through my errata backlog.

For errata 7263, it looks like this was going to be discussed.  Did this 
happen, and if so, what was the outcome please?

My currently proposal is to edit the errata to change the “SHOULD BE” to “MUST 
be” and then mark the errata as HFDU.  Does anyone have any opinions on this 
resolution?

Regards,
Rob


From: Buschart, Rufus 
mailto:rufus.busch...@siemens.com>>
Sent: Tuesday, December 13, 2022 8:11 AM
To: Esko Dijk 
mailto:esko.d...@iotconsultancy.nl>>; Michael 
Richardson mailto:mcr+i...@sandelman.ca>>
Cc: RFC Errata System 
mailto:rfc-edi...@rfc-editor.org>>; Max Pritikin 
(pritikin) mailto:priti...@cisco.com>>; 
tte+i...@cs.fau.de<mailto:tte+i...@cs.fau.de>; 
michael.h.behrin...@gmail.com<mailto:michael.h.behrin...@gmail.com>; 
kent+i...@watsen.net<mailto:kent+i...@watsen.net>; 
war...@kumari.net<mailto:war...@kumari.net>; Rob Wilton (rwilton) 
mailto:rwil...@cisco.com>>; 
t...@cs.fau.de<mailto:t...@cs.fau.de>; 
shengji...@bupt.edu.cn<mailto:shengji...@bupt.edu.cn>; 
anima@ietf.org<mailto:anima@ietf.org>
Subject: Re: [Anima] [Technical Errata Reported] RFC8995 (7263)

Hi!

I do have a PTO today and will not be able to dial in ;-)

Best regards

Rufus

From: Esko Dijk 
mailto:esko.d...@iotconsultancy.nl>>
Sent: Tuesday, December 13, 2022 8:55:46 AM
To: Buschart, Rufus (IT IPS SIP) 
mailto:rufus.busch...@siemens.com>>; Michael 
Richardson mailto:mcr+i...@sandelman.ca>>
Cc: RFC Errata System 
mailto:rfc-edi...@rfc-editor.org>>; 
priti...@cisco.com<mailto:priti...@cisco.com> 
mailto:priti...@cisco.com>>; 
tte+i...@cs.fau.de<mailto:tte+i...@cs.fau.de> 
mailto:tte+i...@cs.fau.de>>; 
michael.h.behrin...@gmail.com<mailto:michael.h.behrin...@gmail.com> 
mailto:michael.h.behrin...@gmail.com>>; 
kent+i...@watsen.net<mailto:kent+i...@watsen.net> 
mailto:kent+i...@watsen.net>>; 
war...@kumari.net<mailto:war...@kumari.net> 
mailto:war...@kumari.net>>; 
rwil...@cisco.com<mailto:rwil...@cisco.com> 
mailto:rwil...@cisco.com>>; 
t...@cs.fau.de<mailto:t...@cs.fau.de> mailto:t...@cs.fau.de>>; 
shengji...@bupt.edu.cn<mailto:shengji...@bupt.edu.cn> 
mailto:shengji...@bupt.edu.cn>>; 
anima@ietf.org<mailto:anima@ietf.org> mailto:anima@ietf.org>>
Subject: RE: [Anima] [Technical Errata Reported] RFC8995 (7263)

Thanks Rufus, we even should have a call today at 17:00 CET - call-in details 
are here 
(https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fanima%2FF2Ojytj9qoxlE4XSjtMwXMf8oFs%2Fdata=05%7C01%7Crufus.buschart%40siemens.com%7C7833dd970f1b4580cfd908dadcdf735a%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638065150467953304%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=y1S2VmOjEyl6pW13kGRnzjCJTBDS%2BAZx22m9TgliFi8%3Dreserved=0<https://mailarchive.ietf.org/arch/msg/anima/F2Ojytj9qoxlE4XSjtMwXMf8oFs/>).

Maybe we could also briefly discuss the difference between "X does Y" versus "X 
MUST do Y" in an RFC, since no-one dared to comment on that yet ;-)

Regards
Esko

-Original Message-
From: Buschart, Rufus 
mailto:rufus.busch...@siemens.com>>
Sent: Monday, December 12, 2022 22:23
To: Michael Richardson mailto:mcr+i...@sandelman.ca>>; 
Esko Dijk mailto:esko.d...@iotconsultancy.nl>>
Cc: RFC Errata System 
mailto:rfc-edi...@rfc-editor.org>>; 
priti...@cisco.com<mailto:priti...@cisco.com>; 
tte+i...@cs.fau.de<mailto:tte+i...@cs.fau.de>; 
michael.h.behrin...@gmail.com<mailto:michael.h.behrin...@gmail.com>; 
kent+i...@watsen.net<mailto:kent+i...@watsen.net>; 
war...@kumari.net<mailto:war...@kumari.net>; 
rwil...@cisco.com<mailto:rwil...@cisco.com>; 
t...@cs.fau.de&l

Re: [Anima] [COSE] Intended IANA registration of "+cose" media type suffix / cBRSKI

[Esko Dijk]

> What about for voucher-request+cose?  Did we settle on anything there?
> I think that I used .vrq, but I don't know if we should standardize that.

The voucher request introduced by RFC 8995 reuses the exact same 
application/voucher-cms+json media type, and filename extension as well (.vcj), 
while adding some syntax and semantics.
Then it forgot to update the IANA media types registry with a link to "[RFC 
8995]".

So what draft-RFC8366-bis and also cBRSKI is doing, is the same approach: 
re-use the media type and the extension (.vch) for the Voucher Request.
Except for the forgetting-the-link bit: section 11.3 in draft-RFC8366-bis fixes 
that!

Multiple file extensions are allowed, so we could add .vrq (besides .vch) to 
the list of extensions in the cBRSKI registration request, if that's useful.

Esko

-Original Message-
From: Michael Richardson  
Sent: Thursday, January 11, 2024 16:22
To: Esko Dijk 
Cc: Orie Steele ; cose ; 
anima@ietf.org
Subject: Re: [COSE] Intended IANA registration of "+cose" media type suffix / 
cBRSKI


Esko Dijk  wrote:
> Each media type that wants to use +cose would need to indicate what
> file extension it wants to use. This could be “.cose” or “.cbor” I
> think if nothing more specific is wanted. For application/voucher+cose,
> it is “.vch”.

What about for voucher-request+cose?  Did we settle on anything there?
I think that I used .vrq, but I don't know if we should standardize that.

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




___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [COSE] Intended IANA registration of "+cose" media type suffix / cBRSKI

[Esko Dijk]

> Will there be a .cose file extension? Or will we still use .cbor?

Each media type that wants to use +cose would need to indicate what file 
extension it wants to use. This could be “.cose” or “.cbor” I think if nothing 
more specific is wanted. For application/voucher+cose, it is “.vch”.
The COSE RFC has defined “.cbor” as the file extension. 
(https://www.rfc-editor.org/rfc/rfc9052.html#section-11.3.1)

> Are there any fragment processing details, that need to be considered?

Currently not. Note that +cbor did define fragment considerations, even where 
cbor itself doesn’t have fragments, see 
https://datatracker.ietf.org/doc/html/rfc8949#section-9.5.
Similar text can be added for +cose.  It would be just saying that currently 
there is no fragment identification but a foo+cose can define its own fragment 
identification if it wants to. We could try to say it shorter than +cbor does.

Esko

From: Orie Steele 
Sent: Thursday, January 11, 2024 14:50
To: Esko Dijk 
Cc: cose ; anima@ietf.org
Subject: Re: [COSE] Intended IANA registration of "+cose" media type suffix / 
cBRSKI

I think both SCITT and W3C Verifiable  Credentials have uses cases that would 
use this.

Will there be a .cose file extension? Or will we still use .cbor?

Are there any fragment processing details, that need to be considered? Such as 
referring to headers, or payload with fragments?

OS


On Thu, Jan 11, 2024, 2:54 AM Esko Dijk 
mailto:esko.d...@iotconsultancy.nl>> wrote:
Hi all,

In our latest cBRSKI draft we have included a request to IANA to register the 
“+cose” media type suffix. This is used in turn to construct the 
“application/voucher+cose” media type. Because some people here in the COSE WG 
may be interested in this; I’m bringing this to your attention and soliciting 
feedback – if any – until January 19th. Details are below.

Motivation: using a +cose suffix was felt to be more specific and appropriate 
than using only the +cbor suffix. Multi-suffix was also considered (+cose+cbor) 
but not pursued because this isn’t formally enabled yet and is under heavy 
discussion. Other COSE-based data formats can also benefit from the +cose 
suffix in the future. It allows much better diagnostic viewing experience of a 
Voucher in future media-type-viewers that know about +cose, compared to using 
+cbor.


Registry: 
https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml



There has been a first round of review by the mediaman WG, which led to an 
updated request.

See: 
https://mailarchive.ietf.org/arch/msg/media-types/Ila6R7g1zGaG4nSYJVUXTR4UkuY/



Registration Template: see I-D document

https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-voucher-23#section-16.5

Best regards
Esko


IoTconsultancy.nl  |  Email/Teams: 
esko.d...@iotconsultancy.nl<mailto:esko.d...@iotconsultancy.nl>




IoTconsultancy.nl  |  Email/Teams: 
esko.d...@iotconsultancy.nl<mailto:esko.d...@iotconsultancy.nl>|   +31 6 
2385 8339

___
COSE mailing list
c...@ietf.org<mailto:c...@ietf.org>
https://www.ietf.org/mailman/listinfo/cose
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] Intended IANA registration of "+cose" media type suffix / cBRSKI

[Esko Dijk]

Hi all,

In our latest cBRSKI draft we have included a request to IANA to register the 
"+cose" media type suffix. This is used in turn to construct the 
"application/voucher+cose" media type. Because some people here in the COSE WG 
may be interested in this; I'm bringing this to your attention and soliciting 
feedback - if any - until January 19th. Details are below.

Motivation: using a +cose suffix was felt to be more specific and appropriate 
than using only the +cbor suffix. Multi-suffix was also considered (+cose+cbor) 
but not pursued because this isn't formally enabled yet and is under heavy 
discussion. Other COSE-based data formats can also benefit from the +cose 
suffix in the future. It allows much better diagnostic viewing experience of a 
Voucher in future media-type-viewers that know about +cose, compared to using 
+cbor.


Registry: 
https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml



There has been a first round of review by the mediaman WG, which led to an 
updated request.

See: 
https://mailarchive.ietf.org/arch/msg/media-types/Ila6R7g1zGaG4nSYJVUXTR4UkuY/



Registration Template: see I-D document

https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-voucher-23#section-16.5

Best regards
Esko


IoTconsultancy.nl  |  Email/Teams: 
esko.d...@iotconsultancy.nl




IoTconsultancy.nl  |  Email/Teams: 
esko.d...@iotconsultancy.nl|   +31 6 
2385 8339

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [IANA #1224432] Errors in the IANA registry contents of "Bootstrapping Remote Secure Key Infrastructures (BRSKI) Parameters"

[Esko Dijk]

Hi ANIMA chairs,

I agree with this erratum too! (disclaimer - I filed it back in 2022.)
Could we please proceed with accepting this item?  IANA cannot act in making 
the correction if we keep it in current state "Reported".

thanks
Esko

-Original Message-
From: Anima  On Behalf Of Michael Richardson
Sent: Wednesday, February 9, 2022 19:16
To: iana-issues-comm...@iana.org; ka...@mit.edu
Cc: draft-ietf-anima-bootstrapping-keyin...@ietf.org; anima@ietf.org
Subject: Re: [Anima] [IANA #1224432] Errors in the IANA registry contents of 
"Bootstrapping Remote Secure Key Infrastructures (BRSKI) Parameters"


Sabrina Tanamal via RT  wrote:
> Hi Michael,

> This note is just to let you know that we've received the following 
report. Please see below.
> We'll update the entries once the errata report has been verified so we
> can list it as an additional reference for the registry.

>> In the following registry: https://www.iana.org/assignments/brski-
>> parameters/brski-parameters.xhtml#pledge-brski-status-telemetry-
>> attributes
>> I found two errors in the registered values “Status” and “Reason”:
>> these should be starting with a lowercase character, so “status” and
>> “reason”. See RFC 8995, CDDL files in Section 5.7 / 5.9.4.

I agree that they should be lower case and that section 8.5 is incorrect when
it registers them as upper-case.

>> Section 8.5 of the RFC 8995 has the wrong entries listed so I have
>> just reported this as an errata to RFC 8995 (https://www.rfc-
>> editor.org/errata/eid6834).

Ben: I agree with this errata.
 Errata ID: 6834

also Errata ID: 6642 should maybe be verified.
 Errata ID: 6648
 Errata ID: 6649

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




___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] I-D Action: draft-ietf-anima-constrained-voucher-23.txt

[Esko Dijk]

Best wishes for 2024 to all!

This new year's version -23 (pity it's not -24... ) wraps up most of the 
remaining open issues. Details of changes can be found in the Section 18 
Changelog.
Two major changes to highlight are:

* Removal of GRASP-related discovery changes - we now informatively point to 
draft-eckert-anima-brski-discovery as a possible future document that may 
address this topic. This follows the IETF 118 discussion outcome.
* Addition of a new content format (application/multipart-core) that can carry 
multiple CA certificates in a simpler CBOR-based container format. With this 
also comes support for more elaborate CA/sub-CA structures (e.g. 2-tier, 
3-tier) that we expect to get more common in the future for IoT.

Best regards
Esko

-Original Message-
From: Anima  On Behalf Of internet-dra...@ietf.org
Sent: Wednesday, January 10, 2024 10:14
To: i-d-annou...@ietf.org
Cc: anima@ietf.org
Subject: [Anima] I-D Action: draft-ietf-anima-constrained-voucher-23.txt

Internet-Draft draft-ietf-anima-constrained-voucher-23.txt is now available.
It is a work item of the Autonomic Networking Integrated Model and Approach
(ANIMA) WG of the IETF.

   Title:   Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI)
   Authors: Michael Richardson
Peter van der Stok
Panos Kampanakis
Esko Dijk
   Name:draft-ietf-anima-constrained-voucher-23.txt
   Pages:   87
   Dates:   2024-01-10

Abstract:

   This document defines the Constrained Bootstrapping Remote Secure Key
   Infrastructure (cBRSKI) protocol, which provides a solution for
   secure zero-touch onboarding of resource-constrained (IoT) devices
   into the network of a domain owner.  This protocol is designed for
   constrained networks, which may have limited data throughput or may
   experience frequent packet loss. cBRSKI is a variant of the BRSKI
   protocol, which uses an artifact signed by the device manufacturer
   called the "voucher" which enables a new device and the owner's
   network to mutually authenticate.  While the BRSKI voucher data is
   encoded in JSON, cBRSKI uses a compact CBOR-encoded voucher.  The
   BRSKI voucher data definition is extended with new data types that
   allow for smaller voucher sizes.  The Enrollment over Secure
   Transport (EST) protocol, used in BRSKI, is replaced with EST-over-
   CoAPS; and HTTPS used in BRSKI is replaced with DTLS-secured CoAP
   (CoAPS).  This document Updates RFC 8995 and RFC 9148.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-anima-constrained-voucher/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-anima-constrained-voucher-23.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-anima-constrained-voucher-23

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] cBRSKI: proposed new format for the EST "CA certificates" response

[Esko Dijk]

Hi all,

Based on earlier discussions in the design team meeting, I'm proposing an 
improvement / fix for cBRSKI that includes 2 main things:


  1.  New (simple) format for the EST-coaps "CA certificates" response:  
existing spec requires PKCS#7 container to distribute multiple CA certs. New 
proposal is CBOR-only; using the application/multipart-core format.
  2.  Updates to all procedures to enable a Pledge/IoT-device to enroll in a 
domain with 2 or 3 tiers of CAs, and be managed in such a domain - including 
EST re-enrollment, change of root-CA/sub-CA/owner, etc.

There was a trade-off here between keeping the Pledge lightweight and enabling 
full participation in a 2-tier/3-tier CAs domain. With an eye on the future, 
the proposal is to go for the full participation, expecting this will become 
common for IoT devices.

See https://github.com/anima-wg/constrained-voucher/pull/291/files
for the new text proposal. Any comments are welcome.

Regards
Esko

IoTconsultancy.nl  |  Email/Teams: esko.d...@iotconsultancy.nl


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Voucher RFC8366-bis: support for other types/encodings of certificates?

[Esko Dijk]

Forgot to mention: this thread is based on an open Github issue - 
https://github.com/anima-wg/constrained-voucher/issues/281 
This checks whether cBRSKI can be extended to new cert formats if those become 
popular. That seems ok, using either option 1 or 2.

> So either way we need to do something now in RFC8366-bis to avoid rolling
> that module again later on.

With option 2, we can adapt the RFC8366-bis YANG descriptions now, to prepare 
for new/other cert and key types in the future.
With option 1, we can just do nothing now but it would require an update of 
RFC8366-bis again for each new cert/key type that gets added.

So option 2 is some work (now). Certain YANG field descriptions need to be 
generalized to allow the (future) new key and cert types.

> Are you interested in it?
> Are you writing code?

For now and the coming year, I don't have any plans to use C509 certs or write 
code for it! If no-one has such plans, we can also decide to go for option 1.

> I was hoping (my head in the sand) you wouldn't bring this up :-)

I was digging in that sand too deep and found something :)  If we treat support 
for a new cert format (in the DTLS handshake, and in the Voucher) as simply a 
"new Voucher format" , we don't have to do anything special for this case.
Nothing on top of the things already defined now in 
draft-eckert-brski-discovery. The "new Voucher format" could even have its own 
media type to distinguish its use of different cert/key encoding.

Esko

-Original Message-
From: Michael Richardson  
Sent: Thursday, December 14, 2023 14:38
To: Esko Dijk ; anima@ietf.org
Subject: Re: [Anima] Voucher RFC8366-bis: support for other types/encodings of 
certificates?


Esko Dijk  wrote:
> How would the voucher / voucher-request best support such new
> certificate formats/types? Two main approaches are possible:

Yeah.
So either way we need to do something now in RFC8366-bis to avoid rolling
that module again later on.

> So with option (2) the existing fields just hold binary data of some
> format, by default it's X509/ASN.1 DER. If the "cert-type" field is
> present it identifies the format of binary data e.g. X509, C509, etc.

> If we do nothing now, we will default to option 1. TBH I'm not even
> sure if option 2 is feasible with current YANG definitions and all the
> legacy around it. But I still wanted to raise this question, just in
> case anyone's interested :-)

Are you interested in it?
Are you writing code?

> PS Also for discovery operations, discovering a Registrar that supports
> a particular (deviating) certificate type X may then be needed. This
> could be viewed as just a different type of Voucher that needs to be
> supported.

I was hoping (my head in the sand) you wouldn't bring this up :-)


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




___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] Voucher RFC8366-bis: support for other types/encodings of certificates?

[Esko Dijk]

Here a question that came up, due to work in COSE WG to define a CBOR-encoded 
version of the X509 certificate: called "C509 certificate", see 
draft-ietf-cose-cbor-encoded-cert-07.

Possibly this new C509 certificate format, or other types may become desirable 
for BRSKI Pledges to use. In particular for constrained BRSKI (cBRSKI), where 
C509 can reduce the size of messages and/or codebase on the Pledge.

How would the voucher / voucher-request best support such new certificate 
formats/types? Two main approaches are possible:


  1.  Define new fields for the new certificate format in the YANG definition. 
So all of the fields that currently hold X509 format are "cloned" to fields for 
the new format: e.g. pinned-domain-cert, proximity-registrar-cert, 
pinned-domain-pubk, etc.
  2.  Re-use the existing fields for the new certificate format.  Add a single 
new field "cert-type" in YANG that has an integer denoting "certificate type". 
The int value could be taken from existing IANA registry 
(link)

So with option (2) the existing fields just hold binary data of some format, by 
default it's X509/ASN.1 DER. If the "cert-type" field is present it identifies 
the format of binary data e.g. X509, C509, etc.

If we do nothing now, we will default to option 1. TBH I'm not even sure if 
option 2 is feasible with current YANG definitions and all the legacy around 
it. But I still wanted to raise this question, just in case anyone's interested 
:-)

PS Also for discovery operations, discovering a Registrar that supports a 
particular (deviating) certificate type X may then be needed. This could be 
viewed as just a different type of Voucher that needs to be supported.

Esko

IoTconsultancy.nl  |  Email/Teams: 
esko.d...@iotconsultancy.nl|   +31 6 
2385 8339

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] I-D Action: draft-ietf-anima-constrained-voucher-22.txt

[Esko Dijk]

> Yes, I think so.

Created an issue for this 
(https://github.com/anima-wg/constrained-voucher/issues/285) and I'll do a PR 
for this.

Esko

-Original Message-
From: Michael Richardson  
Sent: Sunday, November 26, 2023 13:12
To: Esko Dijk ; anima@ietf.org
Subject: Re: [Anima] I-D Action: draft-ietf-anima-constrained-voucher-22.txt


Esko Dijk  wrote:
> Would it be solved by just dropping the claims that we Update / Extend
> 8366bis? Instead we can just reference 8366bis and say we add something
> to that format.  Then we don't need to Update 8366 anymore, because
> 8366bis is already doing this for us.

Yes, I think so.


--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-  *I*LIKE*TRAINS*



___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] I-D Action: draft-ietf-anima-constrained-voucher-22.txt

[Esko Dijk]

> I think that where it says that it updates RFC8366bis, it probably should
> just recap what 8366bis says (and that document should say it).
> I guess that requires further document coordination work.

Indeed, maybe there's no need to Update (in particular: Extend) RFC 8366bis 
since this document isn't RFC yet. And the tags Update / Extend etc are only 
defined in context of updating an existing RFC.
I think the intention was to say that while 8366bis defines the CBOR Voucher 
Data, it doesn't define the COSE signature format. This is introduced only in 
cBRSKI.

Would it be solved by just dropping the claims that we Update / Extend 8366bis? 
Instead we can just reference 8366bis and say we add something to that format.
Then we don't need to Update 8366 anymore, because 8366bis is already doing 
this for us.

Esko

-Original Message-
From: Michael Richardson  
Sent: Thursday, November 23, 2023 20:32
To: Esko Dijk ; anima@ietf.org
Subject: Re: [Anima] I-D Action: draft-ietf-anima-constrained-voucher-22.txt


Esko Dijk  wrote:
> This update reflects the work that was done earlier (August) to
> restructure the content of "cBRSKI". Now the default, simplest flow is
> highlighted and optional extras are moved into separate sections: in
> particular, the extended discovery now in Section 14.  Some content has

Thank you for all the work on this document.

I think that where it says that it updates RFC8366bis, it probably should
just recap what 8366bis says (and that document should say it).
I guess that requires further document coordination work.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-  *I*LIKE*TRAINS*



___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Discovery of renewal server / draft-eckert-anima-brski-discovery / draft-ietf-anima-brski-ae / draft-ietf-anima-brski-prim

[Esko Dijk]

> We put the overhead of supporting all the variations on the Registrar before,

For an implementation this makes sense. But, it could be that a particular 
domain owner doesn't want all methods to be supported, still. E.g. some 
security or policy concerns (whether these are justified or not). Then a method 
may get disabled on the server.
But to let the device retry the same Registrar later on, or try multiple in 
case of error, seems fine to me in general. For renewal, retrying the next day 
or so is quite acceptable - if the renewal is only triggered by date/time of 
the old certificate.

> Not sure why you write proxy/registrar.

What Michael indicates was also my understanding: once the Pledge is onboarded, 
it gains access to the domain's network, and it has no need of any proxy 
anymore.
For cert renewal it should discover directly an EST, or CMP, or , server 
that's capable of renewal. For EST, the server is I think required to offer 
renewal - so any EST server should do.

And because a BRSKI Registrar that supports EST for onboarding (the default), 
will include an EST server,  it is possible for the device to discover "BRSKI 
Registrar" and use this as an EST server.

So options are:

1) discover an EST server - RFC 9148 defines a method using CoAP resource type 
(rt=ace.est.sren), which can be used with multicast CoAP discovery (not ideal 
in mesh networks), or with a Resource Directory. It's not mandatory for a 
server to offer this discovery per 9148.
The cBRSKI draft could, if we want, define more details here, or make it 
REQUIRED for compliant servers to support discovery. Or alternatively we just 
say "go discover a Registrar" (point 2).

2) discover a BRSKI Registrar - the combo of cBRSKI-draft and cJP-draft 
together ought to define this case.

3) address of renewal server could be pushed into the device via a higher-layer 
communication i.e. the application layer.  This "push" could happen at the 
moment that the device is requested to re-enroll itself, in some 
application-specific way.
   There's currently no standard protocol message defined AFAIK to trigger a 
client to start the re-enrollment process.

Esko

-Original Message-
From: Anima  On Behalf Of Michael Richardson
Sent: Thursday, November 23, 2023 20:09
To: Toerless Eckert ; anima@ietf.org
Subject: Re: [Anima] Discovery of renewal server / 
draft-eckert-anima-brski-discovery / draft-ietf-anima-brski-ae / 
draft-ietf-anima-brski-prim


Toerless Eckert  wrote:
> Please also add your thoughts about this to:
> https://github.com/anima-wg/brski-discovery/issues/4 (but discuss here
> first).

okay.

> Question: How do we want to deal with certificate renewal/re-keying ?

Stick head in sand, hope universe winds down before 991231 arrives :-)

> Do we assume by default that any discovered BRSKI (variation)
> proxy/registar is capable to do renewal ? Technically this would not

Not sure why you write proxy/registrar.
It would be strictly the registrar, and there should be no need for a node
(not a pledge anymore) to discover a proxy to renew.

I assume that nodes do EST or they do CMP, and likely not both.
We put the overhead of supporting all the variations on the Registrar before,
and I'm okay with continuing to do that.  A node, upon receiving a 404 or 403
or 5xx when trying to renew using a Registrar that it has discovered ought to 
just
move along to another Registrar.  There could many reasons for the Registrar
to have that renewal method broken, and I think it makes little sense to
optimize the CMP vs EST case while leaving the "disk full" (or SSD ran out of
spares and went read-only) case broken.

> When writing RFC8994, we did consider that not all existing EST servers
> would necessarily support BRSKI, and therefore instead of using
> AN_join_registrar, renewal was recommend to use SRV.est objective.

I'm not entirely sure I agreed with that at the time, but I'm happy with
that.  SRV.cmp would be fine too.

> We
> did not define an equvalent proxy objective though, because already
> enrolled pledges would not need to use a proxy but could always connect
> directly to a registrar.

> Do we ever need renewal to go through a proxy ?

It's probably wrong.
If the node has lost so much network that it's no longer on the ACP (or the
IoT network), then it probably should go through onboarding again.  It might
have moved, or something happened.


--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-  *I*LIKE*TRAINS*



___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] brski-discovery vs constrained BRSKI (was: Re: I-D Action: draft-ietf-anima-constrained-join-proxy-15.txt / draft-eckert-anima-brski-discovery-01 )

[Esko Dijk]

> That's good to hear, and I guess that was one reason to make GRASP treat CBOR 
> as its "native language". 
> And as draft-eckert-anima-grasp-dnssd shows, once you represent DNS info in a 
> CBOR (or JSON) style it 
> becomes very straightforward to parse. I'm not sure that these advantages are 
> widely understood outside ANIMA.

There's some work and discussion in the CBOR WG on this. The focus there is 
mostly on compactness, not necessarily on ease of parsing. 
And no specific focus on DNS-SD services.  See 
https://datatracker.ietf.org/doc/html/draft-lenders-dns-cbor-06

I think draft-eckert-anima-grasp-dnssd is more optimized (in terms of 
size/simplicity) to the use case of DNS-SD service info, while the above draft 
focuses on generic DNS queries/answers.

Esko


-Original Message-
From: Anima  On Behalf Of Brian E Carpenter
Sent: Thursday, November 23, 2023 20:12
To: Michael Richardson ; Toerless Eckert 
; anima@ietf.org
Subject: Re: [Anima] brski-discovery vs constrained BRSKI (was: Re: I-D Action: 
draft-ietf-anima-constrained-join-proxy-15.txt / 
draft-eckert-anima-brski-discovery-01 )

On 24-Nov-23 04:14, Michael Richardson wrote:
> 
> Toerless Eckert  wrote:
>  > I don't see a reason why GRASP should not work well on even further
>  > constrained devices.
> 
> I personally found GRASP way easier to implement in a constrained fashion 
> than mDNS.

That's good to hear, and I guess that was one reason to make GRASP treat CBOR 
as its "native language". And as draft-eckert-anima-grasp-dnssd shows, once you 
represent DNS info in a CBOR (or JSON) style it becomes very straightforward to 
parse. I'm not sure that these advantages are widely understood outside ANIMA.

Brian

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] I-D Action: draft-ietf-anima-constrained-voucher-22.txt

[Esko Dijk]

This update reflects the work that was done earlier (August) to restructure the 
content of "cBRSKI". Now the default, simplest flow is highlighted and optional 
extras are moved into separate sections: in particular, the extended discovery 
now in Section 14.
Some content has been reorganized as well. This version will be used as a base 
to do further text updates, e.g. the discovery related proposal that was made 
at IETF 118.

Current work items are reflected in Github: 
https://github.com/anima-wg/constrained-voucher/issues

Esko

-Original Message-
From: Anima  On Behalf Of internet-dra...@ietf.org
Sent: Tuesday, November 21, 2023 17:54
To: i-d-annou...@ietf.org
Cc: anima@ietf.org
Subject: [Anima] I-D Action: draft-ietf-anima-constrained-voucher-22.txt

Internet-Draft draft-ietf-anima-constrained-voucher-22.txt is now available.
It is a work item of the Autonomic Networking Integrated Model and Approach
(ANIMA) WG of the IETF.

   Title:   Constrained Bootstrapping Remote Secure Key Infrastructure (BRSKI)
   Authors: Michael Richardson
Peter van der Stok
Panos Kampanakis
    Esko Dijk
   Name:draft-ietf-anima-constrained-voucher-22.txt
   Pages:   86
   Dates:   2023-11-21

Abstract:

   This document defines the Constrained Bootstrapping Remote Secure Key
   Infrastructure (Constrained BRSKI) protocol, which provides a
   solution for secure zero-touch bootstrapping of resource-constrained
   (IoT) devices into the network of a domain owner.  This protocol is
   designed for constrained networks, which may have limited data
   throughput or may experience frequent packet loss.  Constrained BRSKI
   is a variant of the BRSKI protocol, which uses an artifact signed by
   the device manufacturer called the "voucher" which enables a new
   device and the owner's network to mutually authenticate.  While the
   BRSKI voucher is typically encoded in JSON, Constrained BRSKI uses a
   compact CBOR-encoded voucher.  The BRSKI voucher definition is
   extended with new data types that allow for smaller voucher sizes.
   The Enrollment over Secure Transport (EST) protocol, used in BRSKI,
   is replaced with EST-over-CoAPS; and HTTPS used in BRSKI is replaced
   with DTLS-secured CoAP (CoAPS).  This document Updates RFC 8366 and
   RFC 8995.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-anima-constrained-voucher/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-anima-constrained-voucher-22.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-anima-constrained-voucher-22

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] I-D Action: draft-ietf-anima-constrained-join-proxy-15.txt

[Esko Dijk]

A first comment / question here: in IETF 118, it was proposed to focus the 
discovery methods for Constrained BRSKI (draft-ietf-anima-constrained-voucher) 
only on a single mechanism and leave further alternatives to future work (like 
GRASP and mDNS).

We didn't specifically discuss this aspect for the Constrained Join Proxy draft 
- do we need to do the same thing here and so take out the GRASP discovery text?
Or are we sufficiently confident the GRASP definition is okay and valuable to 
have already now included in a draft? In that case we may leave it in.

Esko

-Original Message-
From: Anima  On Behalf Of Michael Richardson
Sent: Monday, November 6, 2023 15:24
To: anima@ietf.org
Subject: Re: [Anima] I-D Action: draft-ietf-anima-constrained-join-proxy-15.txt


internet-dra...@ietf.org wrote:
>Title: Join Proxy for Bootstrapping of Constrained Network Elements
> Authors: Michael Richardson Peter van der Stok Panos Kampanakis Name:
> draft-ietf-anima-constrained-join-proxy-15.txt Pages: 26 Dates:
> 2023-11-06

...
> A diff from the previous version is available at:
> 
https://author-tools.ietf.org/iddiff?url2=draft-ietf-anima-constrained-join-proxy-15

This is a repost of the I-D, because it expired.
This version includes partial work on the IoT-Directorate review comments
received in August, and which are still issues:

https://github.com/anima-wg/constrained-join-proxy/issues

So the work is just not done yet.
There are a number of pull requests, some rather old, which I need to clean
up and/or merge:
https://github.com/anima-wg/constrained-join-proxy/pulls

Your comments are of course, very welcome.
It probably the case that there is need for some additional review/text based 
upon the
new conversations about the discovery draft.   It would be great if there are
new eyes reading this document if they notice the mismatches.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-  *I*LIKE*TRAINS*



___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Initial Call for agenda discussion / items ANIMA@IETF118 Prague (was: anima - New Meeting Session Request for IETF 118)

[Esko Dijk]

I'd like to present the update of draft-ietf-anima-constrained-voucher: -22 ; 
and status / remaining open issues.
(This will be published prior to the IETF meeting.)   5 minutes would be ok, 10 
minutes better if we have the time ;)

Esko

-Original Message-
From: Anima  On Behalf Of Fries, Steffen
Sent: Thursday, September 14, 2023 14:58
To: Toerless Eckert ; anima@ietf.org
Cc: anima-cha...@ietf.org; rwil...@cisco.com
Subject: Re: [Anima] Initial Call for agenda discussion / items ANIMA@IETF118 
Prague (was: anima - New Meeting Session Request for IETF 118)

Hi Toreless,

I would like to ask for the following slots in the IETF 118 meeting:

Topic/TitleBRSKI-AE Status Update
Name of Presenter(s) David von Oheimb
Length of time requested  5 min
If applicable: name of draft(s) discussed: draft-ietf-anima-brski-ae-06 
(version 06 to be submitted) 

Topic/TitleJWS-voucher Status Update
Name of Presenter(s)Thomas Werner/ Steffen Fries
Length of time requested  5 min
If applicable: name of draft(s) discussed: draft-ietf-anima-jws-voucher-09

Topic/TitleBRSKI-PRM Status Update
Name of Presenter(s) Steffen Fries
Length of time requested  10 min
If applicable: name of draft(s) discussed: draft-ietf-anima-brski-prm-10 
(version 10 to be submitted)

Best regards
Steffen

> -Original Message-
> From: Anima  On Behalf Of Toerless Eckert
> Sent: Thursday, September 14, 2023 1:12 AM
> To: anima@ietf.org
> Cc: anima-cha...@ietf.org; rwil...@cisco.com
> Subject: [Anima] Initial Call for agenda discussion / items ANIMA@IETF118
> Prague (was: anima - New Meeting Session Request for IETF 118)
> 
> Dear ANIMA WG,
> 
> This time, we wanted to ask for agenda items for ANIMA@IETF118 early
> enough that we can accordingly ask for a fitting slot length. The window for
> requesting WG slots closes on 09-22 23:59 UTC.
> 
> For now, we have requested a one hour slot based on feedback from our AD
> and others who ae trying to ensure that IETF in-person meeting time is spent
> mostly on discussions that can only be had in-person, especially given the 
> ever
> growing number of WGs.
> 
> Given how we are making good working progress with most our adopted
> BRSKI WG items on our weekly online meetings (to the extend they are not on
> back-burner because of serialization/dependencies), we think for those WG
> items one hour will suffice at IETF118, so that is the current request.
> 
> If you have additional work you would like to see discussed, please start
> discuss it on the list, so that we can consider extending the WG meeting time
> request for
> IETF118 as then needed.
> 
> Cheers
>   Toerless - for the chairs
> 
> On Wed, Sep 13, 2023 at 04:05:47PM -0700, IETF Meeting Session Request
> Tool wrote:
> >
> >
> > A new meeting session request has just been submitted by Toerless
> > Eckert, a Chair of the ANIMA Working Group.
> >
> >
> > -
> > Working Group Name: Autonomic Networking Integrated Model and
> Approach
> > Area Name: Operations and Management Area Session Requester: Toerless
> > Eckert
> >
> >
> > Number of Sessions: 1
> > Length of Session(s): 1 Hour
> > Number of Attendees: 40
> > Conflicts to Avoid:
> >  Chair conflict: detnet bier 6man intarea pim v6ops iabopen
> > Technology overlap: emu netconf mboned  Key participant conflict: nmrg
> > opsarea intarea saag
> >
> >
> >
> >
> > Participants who must be present:
> >   Michael Richardson
> >
> > Resources Requested:
> >
> > Special Requests:
> >   China remote attendance friendly time would be lovely (the earlier
> > in the day, the better). One co-chair likely attending remotely
> > -
> >
> 
> --
> ---
> t...@cs.fau.de
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .ietf.org%2Fmailman%2Flistinfo%2Fanima=05%7C01%7Csteffen.fries%
> 40siemens.com%7C610b34f12fc2405a350308dbb4aed160%7C38ae3bcd95
> 794fd4addab42e1495d55a%7C1%7C0%7C638302435211613955%7CUnkn
> own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
> 1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=gE1niRS8cT4rdaPL
> m3lLRiEt7RDmJjZGqb6hvG0yYEw%3D=0

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] BRSKI-AE text proposal: how to signal to a pledge which BRSKI variant(s) with which parameter(s) a registrar supports

[Esko Dijk]

> [stf] One assumption we always had was that the registrar in the 
> infrastructure is the more capable device, meaning that a registrar that 
> supports BRSKI-AE would also support BRSKI contrary to a pledge, which we 
> would assume only supports one of the options. I know, this does not help 
> with old registrars, which get contacted by BRSI-AE pledges.

In Constrained BRSKI we use the assumption "It is assumed that all Registrars 
support all relevant voucher(-request) formats, while the Pledge only supports 
a single format."   (And the MASA naturally supports the format the Pledge 
uses.)
As you say this assumption could be extended also to enrollment protocols. But, 
this seems to have more practical issues - the domain / customer may only 
support a particular enrollment like EST because it's integrated into its 
existing certificate-handling process.
Then, although the Registrar may software-wise support CMP and EST, the CMP 
part may not be configured to be active, by the domain admin. Which means that 
any CMP-only Pledge trying to enroll would still fail.

Logically, there shouldn't even be any CMP-only Pledges coming on-site in that 
case because the customer/installer/admin/... would know in advance that it 
wouldn't work.  But sometimes logistics go wrong :(
Is it acceptable in this case that the CMP-only Pledge tries to enroll but then 
fails (repeatedly) ?

And the reverse could occur also - a site that only supports CMP and not EST. 
In that case if an EST-only "classic" Pledge is added it would also try to 
enroll and fail. 

One thing that could solve both cases is using different service names for 
CMP/EST cases. But this has the downside that it makes the Proxy discovery less 
generic - i.e. a (legacy) Proxy only knowing about "BRSKI-EST" would fail to 
advertise the "BRSKI-CMP" service to Pledges.

Esko

-Original Message-
From: Anima  On Behalf Of Fries, Steffen
Sent: Friday, September 8, 2023 16:27
To: Toerless Eckert ; David von Oheimb 
Cc: Brockhaus, Hendrik ; anima-chairs 
; Michael Richardson ; 
priti...@cisco.com; draft-ietf-anima-brski-ae 
; anima 
Subject: Re: [Anima] BRSKI-AE text proposal: how to signal to a pledge which 
BRSKI variant(s) with which parameter(s) a registrar supports

Hi Toerless,

I put in some further thoughts inline.

Best regards
Steffen

> -Original Message-
> From: Toerless Eckert 
> Sent: Thursday, September 7, 2023 3:32 AM
> Subject: Re: [Anima] BRSKI-AE text proposal: how to signal to a pledge which
> BRSKI variant(s) with which parameter(s) a registrar supports
> 
> Thanks, David
> 
> I have some more fundamental concerns than the discussions that we had this
> week and that you tried to sommarize, so let me try to restate the issue in a
> way that readers with less context detail can hopefully follow.
> 
> In BRSKI, the overall sequence of events is high level:
>1. Pledge discovers (somehow) BRSKI registrar, which is specified to MUST
> support EST.
>2. Pledge connects to registrar, TLS
>2.1 Pledge requests a voucher over the TLS connection.
>2.2 If 2.1 is successful, pledge requests EST enrollment over same TLS
> connection
> 
> Now, with BRSKI-AE, some set of pledges may only support some other
> enrollment protocol, such as CMP instead of EST. So, the above method stays
> the same, except that in 2.2, EST is replaced with e.g.: CMP.
> 
> Now the problem is that for this to work "guaranteed", pledges would need to
> be able to discover a Registrar that supports (one of) the same enrollment
> protocol(s) as the pledge.
> 
> We have started to work on such discovery solutions across the different
> BRSKI extension, including AE, but the authors of BRSKI-AE where trying to
> find the best solution how to make this work best in the absence of such a
> discovery mechanism.
> 
> A) For once, there is the hope that by having such a "fallback" solution (no
> correct discovery of supported enrollment protocol on registrar), that the
> reference to a working discovery solution could become informational only as
> opposed to normative.
> 
> I am not quite clear about whether or not a reference to a discovery solution
> should be normative or information, whether or not we do have some better
> or worse fallback.
[stf] I think having it optionally would be fine and ensure backward 
compatibility

> Practically speaking, i don't believe that a normative reference does 
> necessarily
> help in practical deployments. For example, assume we would specify only a
> GRASP discover in such a reference, and then a deployment can not use
> GRASP and needs another discovery solution anyhow. Aka: a loose linkage
> that is informational could IMHO say "MUST support
> _some_/_whatever_/_you_pick_ discovery, such as " would
> be appropriate in my book, and having e.g.:  be
> informational. But on this point, mileage will vary, so thats a separate 
> question
> we should investigate with folks with IESG experience.
> 
> B) The core issue 

Re: [Anima] title for join proxy document

[Esko Dijk]

I typically assumed the Pledge/joiner would be a constrained device, and also 
the Join Proxy would be a constrained device: in a mesh situation typically a 
Joiner that just successfully joined starts to operate as Join Proxy for any 
future Pledges. 
And these devices would operate in a constrained network.

Here some potential titles to reflect that:

_ Join Proxy for Bootstrapping Protocols in Constrained Networks_

_ Join Proxy for Constrained-Network Bootstrapping Protocols _

_ Join Proxy for Lightweight Bootstrapping Protocols _


These titles do not make a claim about whether the Join Proxy itself is a 
constrained device, or not. That could be said in the intro, that it *could* be 
a constrained device.

Esko

-Original Message-
From: Anima  On Behalf Of Michael Richardson
Sent: Monday, September 4, 2023 19:22
To: anima@ietf.org
Subject: [Anima] title for join proxy document


Russ points out that the title is a slightly mis-leading.
https://github.com/anima-wg/constrained-join-proxy/issues/51

The document is titled:
_Constrained Join Proxy for Bootstrapping Protocols_

  --- abstract
  This document extends the work of Bootstrapping Remote Secure Key
  Infrastructures (BRSKI) by replacing the Circuit-proxy between
  Pledge and Registrar by a stateless/stateful constrained Join
  Proxy. The constrained Join Proxy is a mesh neighbor of the
  Pledge and can relay a DTLS session originating from a Pledge with only 
link-local
  addresses to a Registrar which is not a mesh neighbor of the
  Pledge.

  This document defines a protocol to securely assign a Pledge to a domain,
  represented by a Registrar, using an intermediary node between Pledge and
  Registrar. This intermediary node is known as a "constrained Join
  Proxy". An enrolled Pledge can act as a constrained Join Proxy.

{paragraph two is most definitely wrong, but paragraph one is absolutely 
correct}

Russ is wrong in thinking that the join proxy machine is not constrained; it
may well be, and that's why we want to reduce/eliminate state if possible.
(Or rather, move it into the network and into the Registrar)

However, I stubbed my toe on the title while trying to fix things.

It is the (Constrained Join) Proxy for Bootstrapping Protocols.
Not, the:  (Constrained Join Proxy) for Bootstrapping Protocols_

I thought about instead:
  Stateless Join Proxy for Constrained Bootstrapping Protocols

Or even s/Bootstrapping/Onboarding/
but, actually we document both State and Stateless mechanisms.

Please help me fix the title and from that, the abstract.

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




___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] I-D Action: draft-ietf-anima-brski-cloud-08.txt

[Esko Dijk]

Thanks for making the updates to the text! I did see that the numbering for the 
References section seems to have disappeared; and there is one mention of "MUST 
never" that ought to be "MUST NOT".
Ok for me to conclude WGLC and the draft can now move forward.

Esko

-Original Message-
From: Anima  On Behalf Of Michael Richardson
Sent: Thursday, August 24, 2023 17:38
To: anima@ietf.org
Subject: Re: [Anima] I-D Action: draft-ietf-anima-brski-cloud-08.txt


internet-dra...@ietf.org wrote:
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-anima-brski-cloud-08

This is the result of WGLC review comments from Esko (THANK YOU!)
There are no semantic changes to the document, just edits for consistency.

Is the WGLC finished then?

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




___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Esko: Re: Moving draft-ietf-anima-brski-cloud-06 forward

[Esko Dijk]

> I believe it's better for everybody if this is done by the authors.

But the authors may not see the relevant issues. Only a picky reviewer might 
see them ;-)
Ideally there should be more than 1 WG reviewer that reads everything in detail 
to find the nits.

-Original Message-
From: Brian E Carpenter  
Sent: Wednesday, August 9, 2023 22:40
To: Esko Dijk ; Toerless Eckert ; 
Michael Richardson 
Cc: anima@ietf.org
Subject: Re: [Anima] Esko: Re: Moving draft-ietf-anima-brski-cloud-06 forward

> (we can apply the lazy-fix policy and let IESG find them ;-) )

A bit off topic, but that is *not* the IESG's job. Unfortunately the IESG often 
wastes time on this rather than sending it on to the RFC Editor, whose job it 
is. I believe it's better for everybody if this is done by the authors.

Regards
Brian

On 10-Aug-23 03:33, Esko Dijk wrote:
> I did check just now - the review comments were addressed. I added a few new 
> text issues in the issue tracker #42 to #46  
> (https://github.com/anima-wg/brski-cloud/issues) and a request to change one 
> more item for #32.
> This is based on reading the new text and re-reading the old. These are 
> things I feel that the WG needs to fix before proceeding with the document, 
> to avoid reviewer's confusion further down the line.
> 
> Overall, I also found there's still many typos and word omissions that could 
> be fixed before moving this document forward to IESG. Not sure if that's 
> needed (we can apply the lazy-fix policy and let IESG find them ;-) )
> I could also send a PR with fixes but that might delay the process. Let me 
> know if this PR is desired or not!
> 
> Esko
> 
> -Original Message-
> From: Toerless Eckert 
> Sent: Friday, July 28, 2023 19:50
> To: Esko Dijk 
> Cc: Michael Richardson ; anima@ietf.org
> Subject: Esko: Re: [Anima] Moving draft-ietf-anima-brski-cloud-06 forward
> 
> Esko: I was just checking -07, it looks as if your open review concerns 
> should have been
> successfully answered. Would you mind acknowledging, please ?!
> 
> Thanks
>  Toerless
> 
> On Wed, Jul 26, 2023 at 01:58:22PM -0400, Michael Richardson wrote:
>>
>> Owen Friel \(ofriel\)  wrote:
>>  > Thanks Esko, I just merged a PR to address these:
>>  > https://github.com/anima-wg/brski-cloud/issues/40 Thanks, Owen
>>
>> now posted -07:
>>
>> https://author-tools.ietf.org/iddiff?url1=draft-ietf-anima-brski-cloud-06=draft-ietf-anima-brski-cloud-07=--html
>>
>>
>> --
>> Michael Richardson. o O ( IPv6 IøT consulting )
>> Sandelman Software Works Inc, Ottawa and Worldwide
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Esko: Re: Moving draft-ietf-anima-brski-cloud-06 forward

[Esko Dijk]

I did check just now - the review comments were addressed. I added a few new 
text issues in the issue tracker #42 to #46  
(https://github.com/anima-wg/brski-cloud/issues) and a request to change one 
more item for #32.
This is based on reading the new text and re-reading the old. These are things 
I feel that the WG needs to fix before proceeding with the document, to avoid 
reviewer's confusion further down the line.

Overall, I also found there's still many typos and word omissions that could be 
fixed before moving this document forward to IESG. Not sure if that's needed 
(we can apply the lazy-fix policy and let IESG find them ;-) )
I could also send a PR with fixes but that might delay the process. Let me know 
if this PR is desired or not!

Esko

-Original Message-
From: Toerless Eckert  
Sent: Friday, July 28, 2023 19:50
To: Esko Dijk 
Cc: Michael Richardson ; anima@ietf.org
Subject: Esko: Re: [Anima] Moving draft-ietf-anima-brski-cloud-06 forward

Esko: I was just checking -07, it looks as if your open review concerns should 
have been
successfully answered. Would you mind acknowledging, please ?!

Thanks
Toerless

On Wed, Jul 26, 2023 at 01:58:22PM -0400, Michael Richardson wrote:
> 
> Owen Friel \(ofriel\)  wrote:
> > Thanks Esko, I just merged a PR to address these:
> > https://github.com/anima-wg/brski-cloud/issues/40 Thanks, Owen
> 
> now posted -07:
> 
> https://author-tools.ietf.org/iddiff?url1=draft-ietf-anima-brski-cloud-06=draft-ietf-anima-brski-cloud-07=--html
> 
> 
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] New Version Notification for draft-ietf-anima-constrained-voucher-21.txt

[Esko Dijk]

Actually I did file a formal IANA request already after doing the informal 
mediaman list review.

After some discussion the conclusion was that it would be better to request it 
via an I-D document instead of just the email to IANA.

Another conclusion was that the SSS registration procedure as defined now is 
ambiguous and it was in practice operating as "specification required" over the 
past years.

My plan was also to ignore the MSSS work for now and use only a single suffix.

Esko


From: Carsten Bormann 
Sent: Thursday, July 20, 2023 09:12
To: Michael Richardson 
Cc: Esko Dijk ; Toerless Eckert ; 
anima@ietf.org 
Subject: Re: [Anima] New Version Notification for 
draft-ietf-anima-constrained-voucher-21.txt

On 20. Jul 2023, at 00:57, Michael Richardson  wrote:
>
> Esko Dijk  wrote:
>> * Is application/voucher-cose+cbor a correct name?

Yes.

Whether a coucher+cose would be more desirable, I don’t have an opinion on.

If it is, please do request the registration.
Firing off a request to a random mailing list is not sufficient; iana has to 
know about it.

>> https://github.com/anima-wg/constrained-voucher/issues/264
>-> proposal is to change name to application/voucher+cose and register
>-> '+cose" as a structured syntax suffix.  A request has been informally
>-> approved by mediaman WG; and it was decided to include the formal
>-> request in the draft since that's the best procedure for it.

As a cose WG “member”, I feel it is slightly weird for anima to register that.
But you don’t need a draft, I think; a (correctly!) filled in registration 
template sent to IANA should trigger the expert review.
Just copy Section 11.3.1 of RFC 9052 into the template in Section 6.2 of RFC 
6838, making as few mistakes as possible, and send it in via 
https://www.iana.org/form/protocol-assignment

> Was it actually informally approved? I didn't know.
> https://mailarchive.ietf.org/arch/browse/media-types/?gbt=1=JxzT03Dhe7Nt8cPAfjbDx3WVQRM

The whole nested SSS stuff (let me call it NSSS) is a nice intellectual 
exercise, but I’m not sure it is very relevant.
I think we can ignore NSSS for now.

(I’m sure going to propose using +json+cbor once NSSS is available, as per 
Section 6.2 of RFC 8949 :-)

Grüße, Carsten

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] New Version Notification for draft-ietf-anima-constrained-voucher-21.txt

[Esko Dijk]

Hi Toerless, all,

I won't be joining the IETF meeting this time, correct.

Main open issues to discuss for Constrained BRSKI are

* Is application/voucher-cose+cbor a correct name?  
https://github.com/anima-wg/constrained-voucher/issues/264
 -> proposal is to change name to application/voucher+cose  and register 
'+cose" as a structured syntax suffix.  A request has been informally approved 
by mediaman WG; and it was decided to include the formal request in the draft 
since that's the best procedure for it.

* Proposed simplification and streamlining of Constrained BRSKI  
https://github.com/anima-wg/constrained-voucher/issues/269
 -> proposal is to simplify and streamline the draft per the PR linked to this 
issue. It separates better the default (basics) needed and optional Pledge 
features (like discovering multiple protocols/formats/etc and the RPK variant)

Maybe Michael is available to lead the discussion ... ?

Esko

-Original Message-
From: Toerless Eckert  
Sent: Wednesday, July 19, 2023 03:08
To: Esko Dijk 
Cc: anima@ietf.org
Subject: Re: [Anima] New Version Notification for 
draft-ietf-anima-constrained-voucher-21.txt

Thanks, Esko!

It looks as if you are not registered for IETF117... I think to remember 
something about PTO.

Are the specific issues you would like to be discussed (even in your absence) 
during the WG
meeting, maybe one of the co-authors could lead ?

Cheers
Toerless


On Fri, Jul 07, 2023 at 08:42:34AM +, Esko Dijk wrote:
> Hi all,
> 
> This latest version of draft-ietf-anima-constrained-voucher fixes a couple of 
> minor issues and has editorial improvements.
> There are some open work items that will have a larger impact on the text; 
> but these are not concluded yet so will be integrated into a future version.  
> (Overview here: https://github.com/anima-wg/constrained-voucher/issues)
> 
> Full details of the commits and PRs applied can be found here:
> https://github.com/anima-wg/constrained-voucher/commits/master
> 
> best regards
> Esko
> 
> -Original Message-
> From: internet-dra...@ietf.org  
> Sent: Friday, July 7, 2023 10:36
> To: Esko Dijk ; Michael Richardson 
> ; Panos Kampanakis ; Peter van der 
> Stok 
> Subject: New Version Notification for 
> draft-ietf-anima-constrained-voucher-21.txt
> 
> 
> A new version of I-D, draft-ietf-anima-constrained-voucher-21.txt
> has been successfully submitted by Esko Dijk and posted to the
> IETF repository.
> 
> Name: draft-ietf-anima-constrained-voucher
> Revision: 21
> Title:Constrained Bootstrapping Remote Secure Key 
> Infrastructure (BRSKI)
> Document date:2023-07-07
> Group:anima
> Pages:84
> URL:
> https://www.ietf.org/archive/id/draft-ietf-anima-constrained-voucher-21.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-ietf-anima-constrained-voucher/
> Html:   
> https://www.ietf.org/archive/id/draft-ietf-anima-constrained-voucher-21.html
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-voucher
> Diff:   
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-anima-constrained-voucher-21
> 
> Abstract:
>This document defines the Constrained Bootstrapping Remote Secure Key
>Infrastructure (Constrained BRSKI) protocol, which provides a
>solution for secure zero-touch bootstrapping of resource-constrained
>(IoT) devices into the network of a domain owner.  This protocol is
>designed for constrained networks, which may have limited data
>throughput or may experience frequent packet loss.  Constrained BRSKI
>is a variant of the BRSKI protocol, which uses an artifact signed by
>the device manufacturer called the "voucher" which enables a new
>device and the owner's network to mutually authenticate.  While the
>BRSKI voucher is typically encoded in JSON, Constrained BRSKI uses a
>compact CBOR-encoded voucher.  The BRSKI voucher is extended with new
>data types that allow for smaller voucher sizes.  The Enrollment over
>Secure Transport (EST) protocol, used in BRSKI, is replaced with EST-
>over-CoAPS; and HTTPS used in BRSKI is replaced with CoAPS.  This
>document Updates RFC 8366 and RFC 8995.
> 
>   
> 
> 
> 
> The IETF Secretariat
> 
> 

-- 
---
t...@cs.fau.de

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] New Version Notification for draft-ietf-anima-constrained-voucher-21.txt

[Esko Dijk]

Hi all,

This latest version of draft-ietf-anima-constrained-voucher fixes a couple of 
minor issues and has editorial improvements.
There are some open work items that will have a larger impact on the text; but 
these are not concluded yet so will be integrated into a future version.  
(Overview here: https://github.com/anima-wg/constrained-voucher/issues)

Full details of the commits and PRs applied can be found here:
https://github.com/anima-wg/constrained-voucher/commits/master

best regards
Esko

-Original Message-
From: internet-dra...@ietf.org  
Sent: Friday, July 7, 2023 10:36
To: Esko Dijk ; Michael Richardson 
; Panos Kampanakis ; Peter van der 
Stok 
Subject: New Version Notification for 
draft-ietf-anima-constrained-voucher-21.txt


A new version of I-D, draft-ietf-anima-constrained-voucher-21.txt
has been successfully submitted by Esko Dijk and posted to the
IETF repository.

Name:   draft-ietf-anima-constrained-voucher
Revision:   21
Title:  Constrained Bootstrapping Remote Secure Key Infrastructure 
(BRSKI)
Document date:  2023-07-07
Group:  anima
Pages:  84
URL:
https://www.ietf.org/archive/id/draft-ietf-anima-constrained-voucher-21.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-anima-constrained-voucher/
Html:   
https://www.ietf.org/archive/id/draft-ietf-anima-constrained-voucher-21.html
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-voucher
Diff:   
https://author-tools.ietf.org/iddiff?url2=draft-ietf-anima-constrained-voucher-21

Abstract:
   This document defines the Constrained Bootstrapping Remote Secure Key
   Infrastructure (Constrained BRSKI) protocol, which provides a
   solution for secure zero-touch bootstrapping of resource-constrained
   (IoT) devices into the network of a domain owner.  This protocol is
   designed for constrained networks, which may have limited data
   throughput or may experience frequent packet loss.  Constrained BRSKI
   is a variant of the BRSKI protocol, which uses an artifact signed by
   the device manufacturer called the "voucher" which enables a new
   device and the owner's network to mutually authenticate.  While the
   BRSKI voucher is typically encoded in JSON, Constrained BRSKI uses a
   compact CBOR-encoded voucher.  The BRSKI voucher is extended with new
   data types that allow for smaller voucher sizes.  The Enrollment over
   Secure Transport (EST) protocol, used in BRSKI, is replaced with EST-
   over-CoAPS; and HTTPS used in BRSKI is replaced with CoAPS.  This
   document Updates RFC 8366 and RFC 8995.


  


The IETF Secretariat


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Idea for streamlining of draft-ietf-anima-constrained-voucher

[Esko Dijk]

Hi,

Michael also was somewhat in favor of streamlining but didn't want us to 
rewrite the entire document. That was also not my intention.

I've created a PR with current work in progress/status here: 
https://github.com/anima-wg/constrained-voucher/pull/271/files 

The only pending item here is review the RPK section and check that all the 
required procedures for it are included. In the new streamlined setup, using 
RPK is a distinct variant described in its own section mostly.
Other sections point to it when needed.

Esko

-Original Message-
From: Anima  On Behalf Of William Atwood
Sent: Thursday, June 22, 2023 17:40
To: anima@ietf.org
Subject: Re: [Anima] Idea for streamlining of 
draft-ietf-anima-constrained-voucher

Dear all,

Given that one of my students is about to start a project that will 
model BRSKI and Constrained BRSKI, I am all in favor of "simplify and 
streamline".

   Bill

On 6/22/2023 10:57 AM, Esko Dijk wrote:
> Attention This email originates from outside the concordia.ca domain. // 
> Ce courriel provient de l'extérieur du domaine de concordia.ca
> 
> 
> 
> 
> Hi all,
> 
> Based on our writing and implementation experience so far for 
> draft-ietf-anima-constrained-voucher, I see some opportunity to simplify 
> and streamline the main procedure and its description.
> 
> The idea is to have one main flow description that relies a lot on 
> sensible defaults, and move any “alternatives” or “extras”, or “special 
> cases” to separate sections in the end of the document.
> 
> That should make it more comprehensible for those wanting to implement 
> the basic constrained BRSKI method and also improve interoperability.
> 
> For example quite some CoAP resource discovery things are explained but 
> my implementation doesn’t use it; and it doesn’t seem to add value for 
> the “default” case.
> 
> See https://github.com/anima-wg/constrained-voucher/issues/269 
> <https://github.com/anima-wg/constrained-voucher/issues/269 for Github issue 
> created for this.
> 
> I could create a PR to show how it may look like.
> 
> Any opinions on this?
> 
> Regards
> 
> Esko
> 
> *IoTconsultancy.nl*  |  Email/Teams: esko.d...@iotconsultancy.nl 
> <mailto:esko.d...@iotconsultancy.nl>    |   +31 6 2385 8339
> 
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima

-- 
Dr. J.W. Atwood, Eng. tel:   +1 (514) 848-2424 x3046
Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
Department of Computer Science
and Software Engineering
Concordia University ER 1234  email:william.atw...@concordia.ca
1455 de Maisonneuve Blvd. Westhttp://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] Idea for streamlining of draft-ietf-anima-constrained-voucher

[Esko Dijk]

Hi all,

Based on our writing and implementation experience so far for 
draft-ietf-anima-constrained-voucher, I see some opportunity to simplify and 
streamline the main procedure and its description.
The idea is to have one main flow description that relies a lot on sensible 
defaults, and move any "alternatives" or "extras", or "special cases" to 
separate sections in the end of the document.
That should make it more comprehensible for those wanting to implement the 
basic constrained BRSKI method and also improve interoperability.

For example quite some CoAP resource discovery things are explained but my 
implementation doesn't use it; and it doesn't seem to add value for the 
"default" case.

See https://github.com/anima-wg/constrained-voucher/issues/269 for Github issue 
created for this.
I could create a PR to show how it may look like.

Any opinions on this?

Regards
Esko

IoTconsultancy.nl  |  Email/Teams: 
esko.d...@iotconsultancy.nl|   +31 6 
2385 8339

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Moving draft-ietf-anima-brski-cloud-06 forward

[Esko Dijk]

Hi Sheng, authors,

I checked the new text vs the WGLC issues and confirm that these are resolved.

Because there's new text being added; I've reviewed this as well. Below my 
findings. I would prefer if the WG could fix this as part of the WGLC work.

** Section 3.2
I can't fully follow the logic in Section 3.2 - it's unclear. Below is a 
proposal for improvement. There needs to be reference to [BRSKI] defined codes, 
and a particular code defined for the "owner cannot be determined" case because 
just using any 4xx/5xx code for that at the whim of the registrar implementer 
doesn't make sense to me. (The party implementing the cloud registrar may be 
another party than the one making the pledge code - interoperability plays a 
role here.)

PROPOSED NEW TEXT:
The cloud registrar must determine pledge ownership. Prior to ownership 
determination, the registrar checks the request for correctness and if it is 
unwilling or unable to handle the request, it MUST return a suitable 4xx or 5xx 
error response to the pledge as defined by [BRSKI] and HTTP.
For example, in case of an unknown pledge a 404 is returned, for a malformed 
request 400 is returned, or in case of server overload 503.

If the request is correct and the registrar is able to handle it, but unable to 
determine ownership, then it MUST return a 401 Unauthorized response to the 
pledge. This signals to the Pledge that there is currently no known owner 
domain for it, but that retrying later might resolve this situation.

If the cloud registrar successfully determines ownership, then it MUST take one 
of the following actions:
* return a suitable 4xx or 5xx error response (as defined by [BRSKI] and HTTP) 
to the pledge if the request processing failed for any reason
* redirect the pledge to an owner register via 307 response code
* issue a voucher and return a 200 response code

** Section 3.3 
It seems that a section is missing on the Pledge side handling an "error 
response". For example, it could be just a sentence saying the "usual" HTTP 
error handling defined by [BRSKI] and HTTP applies.
And that for the case of 401 Unauthorized the Pledge MAY retry at a later time.


** Nits
"They operator the Registrar or EST Server"
"which is addresses in part in"

Best regards
Esko

-Original Message-
From: Anima  On Behalf Of Sheng Jiang
Sent: Friday, June 16, 2023 05:17
To: Brian E Carpenter ; Brian Carpenter 
; Toerless Eckert ; Esko Dijk 

Cc: anima-chairs ; anima 
Subject: [Anima] Moving draft-ietf-anima-brski-cloud-06 forward

Hi, Brian, Esko & Toerless,

The authors has submitted a new version draft-ietf-anima-brski-cloud-06. In 
principle, this draft has passed ANIMA WGLC with the condition that your 
editional comments are addressed. Could you check and confirm? After your 
confirmation, the document shepherd and WG chair would like to move it forward.

Regards,


--



Sheng Jiang


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] FW: New Version Notification for draft-mohammed-anima-voucher-security-profile-00.txt

[Esko Dijk]

> I think that there are better ways to do accomplish the configuration, such
> as extending the BRSKI-EST link with new actions.

Indeed letting the owner independently set security policies for the owner's 
own domain sounds useful. Such policies could be sent by the Registrar over the 
same TLS / DTLS connection that is created for the BRSKI-EST, or for the 
standalone EST, protocol. E.g. device gets a policy update every time it gets a 
renewed LDevID.   The policy data can be  a voucher-like document, or a JWT, or 
a CWT, signed by the Domain CA. 

To get the policy data, the BRSKI/EST client could request it using a RESTful 
request.  This has the benefit that we can define it as a building block 
independent from EST itself, while the underlying security and effort and 
standards-text of setting up the TLS connection is shared with EST. I'm 
assuming the protection provided by the TLS connection is useful and wanted in 
this case.

That said, security policies determined by the vendor (through MASA) could also 
be useful for some use cases. The vendor could enforce policies on the use of 
the Pledge for the particular target Domain/customer. E.g. enable some 
features, disable others. Currently that would be encoded in the Voucher in a 
vendor-specific way. Question is if there's a need to standardize this format? 
Or maybe have an informative document showing how to do it is sufficient.  
If we let the domain owner's security policy settings piggy-back on the Voucher 
document, so that all security policies are distributed via one signed 
document, that may be nice and simple but it's less flexible that having 
policies that the domain owner can determine fully independent from the MASA.

Esko


-Original Message-
From: Anima  On Behalf Of Michael Richardson
Sent: Tuesday, May 30, 2023 18:47
To: Srihari Raghavan (srihari) ; anima@ietf.org; jabir 
Mohammed (jamohamm) ; Reda Haddad (rehaddad) 
; Sandesh Rao (sandeshr) 
Subject: Re: [Anima] FW: New Version Notification for 
draft-mohammed-anima-voucher-security-profile-00.txt


Srihari Raghavan (srihari)  wrote:
> Agreed that MASA is the signing authority and the draft is meant to
> convey that the owner can influence the choice by way of parameterized
> inputs to the MASA APIs.  So, owner can be presented with a 'security
> profile selector' input via the MASA external APIs and when the owner
> provides the PDC and the selector input values, MASA can then go ahead
> and create the voucher with appropriate security profile settings
> (after verification and validation) for the device.

okay, that's a entire API from Registrar to MASA which you have to design and
document.  And you mention SZTP, and it doesn't have that link.

I think that there are better ways to do accomplish the configuration, such
as extending the BRSKI-EST link with new actions.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-  *I*LIKE*TRAINS*



___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] Discovering new BRSKI features / options using CoAP discovery

[Esko Dijk]

Hi Toerless, all,

Yesterday in the design team call we discussed that a BRSKI Registrar that 
offers some "new feature" like BRSKI-PRM must be discoverable as such. For 
example a Registrar-Agent may want to discover specifically all Registrars that 
support BRSKI-PRM, or discover all Registrars and be able to see whether they 
support PRM or not.
For DNS-SD discovery, we now have a proposal to use a Boolean flag in the TXT 
record keys to signal a "new feature" like PRM.

Now for CoAP (CoRE Link Format) discovery, ideally we want similar "flags" to 
signal new features, in case needed for the future. (For PRM it doesn't seem 
needed: the Registrar-Agent could use regular DNS-SD discovery plus HTTPS to 
talk to the Registrar. CoAP only comes in when talking to the IoT devices. And 
besides there is no CoAP version of PRM currently defined.)

First to start with the default case of discovering a BRSKI Registrar using a 
query for 'rt=brski*' one or more responses containing the below resource can 
be expected. The full list of resources is not shown in the following examples 
for brevity.

;rt=brski.rv,

Now to this a new feature could be added. If the "new feature" consists of a 
new media type for the Voucher, that the Registrar can support, then using the 
'ct' attribute can be used to signal that. E.g. to signal additional support of 
a type 837, besides the type 836 that is defined as 'standard MUST support' for 
resource type brski.rv , we can have:

;rt=brski.rv;ct="836 837",

If the "new feature" does not change the Voucher media type or encoding, but 
has a distinct procedure that is not fully backwards compatible with standard 
BRSKI then a new resource for it is needed with its distinct resource type (rt) 
, e.g. :

;rt=brski.rv,
;rt=brski.rvx,

This signals that standard BRSKI is supported at /b/rv while the new feature 
with new type 'brski.rvx' here is supported at resource /b/rv2.  The 'x' in 
'rvx' is just a letter picked for the new feature; it could be any letter or 
string.

If the "new feature" can be hosted interoperably at the same resource - for 
example because the data for the new feature is exchanged within the Voucher 
Request and/or Voucher itself - then the same resource could host the standard 
BRSKI and the new feature. This can be signaled using 'rt' as follows:

;rt="brski.rv brski.rvx",

However the Registrar implementer still has the option to not do this but use 
again 2 separate resources in such case, which may be easier for some 
implementation/debugging reasons.

If a Registrar implements some combination of multiple new features then the 
methods of the examples above can be combined.

And yet another option is to define new attributes just like the Boolean flags 
in DNS-SD. CoRE WG aims to set up a IANA registry for this, see 
https://datatracker.ietf.org/doc/html/draft-ietf-core-target-attr-04#name-initial-entries
 for context.
A new Boolean attribute "brski.featname" could for example be registered, to 
denote support of the "new feature". Then the discovery example becomes:

;rt=brski.rv;brski.featname,

So that concludes the overview. All in all there's plenty of flexibility to 
express a particular new feature in the CoAP discovery.

Regards
Esko


IoTconsultancy.nl  |  Email/Teams: esko.d...@iotconsultancy.nl


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] do we need +jose?

[Esko Dijk]

Update to my previous email: as I learnt now the registration of a +suffix in 
the SSS registry doesn't require that the registered name is an existing media 
type name. (Example: +der)
So +jws could be registered with the registration fields pointing to RFC 7515 
"application/jose+json" as the reference.  

It could also be named +josejson or +jose-json then ? Not as nice as +jws but 
at least more relatable to the original media type name.

Esko

-Original Message-----
From: Esko Dijk 
Sent: Wednesday, May 10, 2023 16:38
To: Michael Richardson ; media-ty...@ietf.org; 
anima@ietf.org; j...@ietf.org
Subject: RE: [Anima] do we need +jose?

> should really be doing:
>application/voucher+jws

Because "application/jws" does not seem to be an existing media type, it would 
be strange to use "+jws". 
Looking at draft-ietf-anima-jws-voucher-06: what it really uses is the "JWS 
JSON Serialization" which has the "application/jose+json" media type. This is 
not the "application/jose" type, so it would be strange to use "+jose" as your 
subject suggests.
Now given that we shouldn't use multiple structured syntax suffixes in 
concatenation at this moment, the only option for the suffix media type at this 
moment looks to be "+json".

(Or alternatively we would need a new spec that defines the "application/jws" 
media type - not advisable it seems, adds to confusion.)

So we can have names like e.g.:

 application/voucher-jose+json
 application/voucher-jws+json

In the cases above the "+json" at the end isn't wrong, because it actually is 
JSON.  (For the earlier case of "application/voucher-cms+json" it was wrong as 
you say, because the CMS envelope isn't actually JSON.)

Esko


IoTconsultancy.nl  |  Email/Teams: esko.d...@iotconsultancy.nl 


-Original Message-
From: Anima  On Behalf Of Michael Richardson
Sent: Tuesday, May 9, 2023 20:51
To: media-ty...@ietf.org; anima@ietf.org; j...@ietf.org
Subject: [Anima] do we need +jose?


Hi, https://datatracker.ietf.org/doc/draft-ietf-anima-jws-voucher/
is in WGLC, and
https://datatracker.ietf.org/doc/draft-ietf-anima-brski-prm/ depends upon it.

In anima-jws-voucher, we defined:
https://www.ietf.org/archive/id/draft-ietf-anima-jws-voucher-06.html#name-application-voucher-jwsjson

Type name:  application
Subtype name:  voucher-jws+json

which is in alignment with 
https://www.rfc-editor.org/rfc/rfc8366.html#section-8.3
where we defined:
  Type name:  application
  Subtype name:  voucher-cms+json

probably this was a mistake!  (JSON in a CMS envelope)

I think, based upon discussion about +cose and our other documents, that we
should really be doing:
   application/voucher+jws

While jwt is given as a structured suffix in the IANA registry, jws is not.
I'm not entirely sure if this matters... we are dealing with JWS, not
tokens...

Please advise.  While we have lots of running code (since 2018) for 
voucher-jws, it's a
change we could probably make via Postel Principal.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] do we need +jose?

[Esko Dijk]

> should really be doing:
>application/voucher+jws

Because "application/jws" does not seem to be an existing media type, it would 
be strange to use "+jws". 
Looking at draft-ietf-anima-jws-voucher-06: what it really uses is the "JWS 
JSON Serialization" which has the "application/jose+json" media type. This is 
not the "application/jose" type, so it would be strange to use "+jose" as your 
subject suggests.
Now given that we shouldn't use multiple structured syntax suffixes in 
concatenation at this moment, the only option for the suffix media type at this 
moment looks to be "+json".

(Or alternatively we would need a new spec that defines the "application/jws" 
media type - not advisable it seems, adds to confusion.)

So we can have names like e.g.:

 application/voucher-jose+json
 application/voucher-jws+json

In the cases above the "+json" at the end isn't wrong, because it actually is 
JSON.  (For the earlier case of "application/voucher-cms+json" it was wrong as 
you say, because the CMS envelope isn't actually JSON.)

Esko


IoTconsultancy.nl  |  Email/Teams: esko.d...@iotconsultancy.nl 


-Original Message-
From: Anima  On Behalf Of Michael Richardson
Sent: Tuesday, May 9, 2023 20:51
To: media-ty...@ietf.org; anima@ietf.org; j...@ietf.org
Subject: [Anima] do we need +jose?


Hi, https://datatracker.ietf.org/doc/draft-ietf-anima-jws-voucher/
is in WGLC, and
https://datatracker.ietf.org/doc/draft-ietf-anima-brski-prm/ depends upon it.

In anima-jws-voucher, we defined:
https://www.ietf.org/archive/id/draft-ietf-anima-jws-voucher-06.html#name-application-voucher-jwsjson

Type name:  application
Subtype name:  voucher-jws+json

which is in alignment with 
https://www.rfc-editor.org/rfc/rfc8366.html#section-8.3
where we defined:
  Type name:  application
  Subtype name:  voucher-cms+json

probably this was a mistake!  (JSON in a CMS envelope)

I think, based upon discussion about +cose and our other documents, that we
should really be doing:
   application/voucher+jws

While jwt is given as a structured suffix in the IANA registry, jws is not.
I'm not entirely sure if this matters... we are dealing with JWS, not
tokens...

Please advise.  While we have lots of running code (since 2018) for 
voucher-jws, it's a
change we could probably make via Postel Principal.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] ANIMA: Certificate authentication, BRSKI PRM and RFC8995

[Esko Dijk]

Hi Toerless,

I agree with your analysis here. RFC 2818 does allow to omit the hostname check 
if the client has additional information about the expected identity of the 
server. (Which is in the PRM case, the CA trust anchors of the manufacturer of 
the device - or a set of trusted manufacturers that the commissioning tool 
tusts.)

Also notice that although EST (RFC 7030) mentions RFC 2818, the BRSKI-PRM 
device to be onboarded does not implement EST server so any RFC 7030 
requirements on the server are not really applicable for that BRSKI-PRM device. 
We define a new type of server here (the "Pledge-PRM" TLS server?) with own 
rules. I don't see why it should follow EST server rules here, it's not an EST 
server.

That said, RFC 9110 makes things more restrictive it seems. But it also says in 
4.3 "However, authoritative access is not limited to the identified mechanism." 
which means that other means of authoritative access to a resource/HTTPS server 
, i.e. other than the method defined in section 4.3 , are also foreseen.
So it should be okay to use HTTPS for the BRSKI-PRM use case.

Regards
Esko

-Original Message-
From: Anima  On Behalf Of Toerless Eckert
Sent: Wednesday, April 26, 2023 19:11
To: anima@ietf.org; draft-ietf-anima-...@ietf.org
Cc: draft-t2trg-idevid-considerati...@ietf.org
Subject: [Anima] ANIMA: Certificate authentication, BRSKI PRM and RFC8995

In the process of discussing shepherd review feedback for BRSKI-PRM draft, the
authors brought up arguments relating to their interpretation of requirements
against required TLS server certificate validation by the client.

Let me try to hopefully correctly restate and provide my thoughts,
if i am misrepresenting, please correct me!

Pre:

A pledge has an IDevID and some dynamically assigned IP(v6) address, and no 
domain name.

Claim of the authors

Another device can not build a HTTP over TLS connection to the pledge 
and authenticate the pledge, because of the absence of domain name and 
IP-address
based SubjectAltNames in the certificate - according to RFC2818. RFC2818 is 
required
to be met because BRSKI relies on RFC7030 and RFC7030 requires RFC2818.

My assessment:

I think this is an incorrect reading: I think that any time that a TLS server 
would
identify itself with an IDevID, paragraph 2 of section 3.1 of RFC2818 would be
applicable: The "narrow the scope of acceptable certificates" are those 
certificates
that can be validted against the trust anchors that the client trusts. E.g.: The
trust anchors from the vendor(s) from which the client expects the IDevID to be 
signed.

Furthermore:

I think the very same is also true for BRSKI itself, e.g.: the only 
authentication
that pledges are doing against a registrar is authenticating the certificate 
against
the trust anchor provided in the voucher. There is no additional authentication 
against any type
of additional Subject Name or SubjectAltName that the certificate of a registrar
my carry (dns name or ip address).

draft-t2trg-idevid-considerations

I did not have time to read through this draft, but would that potentially be a 
good
place to reconfirm that one can build a TLS connection to a device that will use
it's IDevID to authenticate itself, and a secure authentication of that device 
as
a TLS server effectively only requires validation of the certificate chain 
against
the trust anchor of the menufacturer for the device - no additional 
verification of
other addresses.

RFC2818 -> RFC9110:

I find these whole HTTP drafts quite confusing:

- RFC2818 was never standards track, but only informational but still uses 
RFC2119 terminology
  (MUST / SHOULD / ...).

- RFC2818 was obsoleted by RFC9110. And RFC9110 is now standards track.

- RFC9110 states in section B.1 that it does not changes anything from RFC2818.
  But then you look at RFC9110 section 4.3.4 and the text is quite different 
from
  RFC2818 section 3.1. In fact, i would claim that RFC9110 is even more WebPKI
  centric written than RFC2818 ("In general, a client MUST verify
  the service identity using the verification process defined in Section 6 of 
[RFC6125].")
  Aka: "In General all certificate validation is WebPKI validation"
  With our non-webPKI uses cases i feel somewhat neglected ;-)

Does this help ?

Cheers
Toerless

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] registration for +cose

[Esko Dijk]

Agree with requesting this registration for COSE. Some remarks on this request:


1. Given the existing names of registrations in the Structured Syntax Suffixes 
registry, the following name would be more appropriate perhaps:

Name: CBOR Object Signing and Encryption (COSE)

2. While STD96 as reference is probably correct, it would be useful to add the 
latest COSE RFC (9052) as well. This is also more in line with the other 
registrations that list RFC numbers. And RFCs are better known than STDs. Or 
maybe this was already intended.

3. The security considerations should point to a section of RFC 9052 (Section 
12), also like other registrations do.

4. Encoding considerations should mention COSE - current text looks like it 
could be a copy/paste bug:

Encoding considerations: COSE is always encoded as CBOR, which is binary

Regards
Esko

-Original Message-
From: Anima  On Behalf Of Michael Richardson
Sent: Friday, April 7, 2023 18:47
To: media-ty...@ietf.org
Cc: anima@ietf.org; c...@ietf.org
Subject: [Anima] registration for +cose


as per RFC6838:

Name: application/cose
+suffix: +cose
References: STD96
Encoding considerations: CBOR is always encoded as binary
Interoperability considerations: None
Fragment identifier considerations: N/A
Security considerations: as per STD96
Contact: IETF COSE WG 
Author/Change controller: IESG

(I was writing an ID for this, then realized that application/cose was
already a thing, and that all we needed was a suffix, which is Expert Review)

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




___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [COSE] [Rats] cose+cbor vs cwt in MIME types

[Esko Dijk]

> So I just don't know what to do, but I think we what have done is wrong.

What we have now is "application/voucher-cose+cbor", which is not wrong I 
think. There's currently no rule saying your media type needs to be named in a 
particular way, there are options to name it.
In this same discussion thread (or parallel thread with same subject) we have 
discussed that "application/voucher+cose" would also be a good name, if we 
register the "+cose" suffix with IANA.

Now the one thing that could be wrong is "application/voucher-cms+json" that is 
registered by RFC 8366. But that work concluded in 2018, so I guess we don't 
want to 'fix' this anymore; a name's just a name.
Reason it may be wrong: the '+json' suffix implies that the most outer layer of 
encoding be JSON. And that's obviously not the case - it is CMS. For example, a 
parser not knowing the full 
"application/voucher-cms+json" media type may see the "+json" so it may fall 
back to JSON decoding of the data, which fails completely because the data is 
binary ASN.1 DER, not JSON.
So it should have been "application/voucher-cms" or 
"application/voucher-json+cms" or so.


>  I don't think that voucher+ysig is meaningful (or accurate) for
> us, because we also COSE sign it, which not every YANG-SID use will do.

True, if we would use "voucher+ysid" then the meaning of "+ysid" needs to be 
formally defined as "CBOR based on a YANG model that uses SIDs for key 
compression, wrapped inside a COSE object".
So "voucher+ysidcose" would be more accurate.
Or "voucher+ysid+cose" in case we apply the rules of the new 
draft-ietf-mediaman-suffixes.

We could organize a 3-day workshop on this topic, I think!  Pity that April 1st 
has just passed :(

Esko

-Original Message-
From: Michael Richardson  
Sent: Tuesday, April 4, 2023 17:06
To: Esko Dijk ; c...@ietf.org; r...@ietf.org; 
anima@ietf.org
Subject: Re: [Anima] [COSE] [Rats] cose+cbor vs cwt in MIME types


Esko Dijk  wrote:
> As you said also the following would be possible today:

> application/voucher+ysid

> if we register 'ysid' as being CBOR-YANG-SID that's included in a COSE
> wrapper. I find this less useful than the first options of '+cbor' or
> '+cose' , it seems too specific.

I'm agnositc because:
1) over COAP it's a single CONTENT-FORMAT, so the size does not matter.
2) over HTTPS, it's a rich network environment, so bytes do not count.

We've been told at this point that we should use as specific a format as
possible.  I don't think that voucher+ysig is meaningful (or accurate) for
us, because we also COSE sign it, which not every YANG-SID use will do.

So I just don't know what to do, but I think we what have done is wrong.

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




___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] Github issues created for BRSKI-cloud WGLC review comments

[Esko Dijk]

Hi Toerless, all,

As requested yesterday I've created Github issues for the WGLC review comments 
on BRSKI-cloud 
(https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-cloud-05).
See https://github.com/anima-wg/brski-cloud/issues.

I added Brian's multiple WGLC comments as a single issue placeholder; if needed 
these can be split in parts.

Due to our recent work on RFC8366-bis a new issue also emerged, whether the 
YANG extensions of BRSKI-cloud should be moved to RFC8366-bis, to avoid the 
YANG related issues of extension/augmentation that we've discussed recently.
I think this would be best to move. The issue is recorded as : 
https://github.com/anima-wg/brski-cloud/issues/34

Regards
Esko

IoTconsultancy.nl  |  Email/Teams: 
esko.d...@iotconsultancy.nl|   +31 6 
2385 8339

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [COSE] [Rats] cose+cbor vs cwt in MIME types

[Esko Dijk]

> So you can read the subtype "eat" and then consider it as +cwt, +cose, +cbor, 
> for an example media type of "application/eat+cbor+cose+cwt"

It looks like in your example the order is reversed; given the existing 
examples defined in draft-ietf-mediaman-suffixes-03 Section 2.1?

Let’s assume it is the reverse, namely “application/eat+cwt+cose+cbor”. Then 
following the Section 2.1 examples a parser would go through these steps for 
example:


  *   Do I know “application/eat+cwt+cose+cbor” ? No.
  *   Do I know “+cbor” ? Yes, decode it as CBOR – ok it’s valid, proceed to 
next stage of the processing pipeline.
  *   Do I know “+cose” ? No. Processing stops here.
  *   End result: I’ll render it in CBOR diagnostic notation.

Another parser might do these steps:


  *   Do I know “application/eat+cwt+cose+cbor” ? No.
  *   Do I know “+cbor” ? Yes, decode it as CBOR – it’s valid, proceed to next 
stage of the processing pipeline.
  *   Do I know “+cose” ? Yes, that’s COSE semantics – decode it – it’s valid, 
and although I can’t verify the signature, go to next stage of the processing 
pipeline.
  *   Do I know “+cwt” ? No, stop here.
  *   End result: display it as a COSE object. Do not trust it as I can’t 
verify the signature.

Yet another parser:


  *   Do I know “application/eat+cwt+cose+cbor” ? No.
  *   Do I know “+cbor” ? Yes, decode it as CBOR – it’s valid, proceed to next 
stage of the processing pipeline.
  *   Do I know “+cose” ? Yes, that’s COSE – decode it – it’s valid, go to next 
stage of the processing pipeline.
  *   Do I know “+cwt” ? Yes, that’s a CWT – now checking that the COSE payload 
is correct CBOR with CWT structure inside – okay.
  *   End result: display it as a CWT.


Using the reverse way "application/eat+cbor+cose+cwt" seems not compatible with 
what’s currently written in draft-ietf-mediaman-suffixes-03 about “pipelines”.
For example, suppose a “CWT decoder” gets this media type first, and it then 
sends “eat+cbor+cose” to the next pipeline stage, that wouldn’t make sense 
since the ‘+cbor’ and ‘+cose’ parts were already decoded as part of ‘+cwt’.

For completeness here the example from the draft "image/svg+xml+gzip":

  *   Do I know "image/svg+xml+gzip" ? No.
  *   Do I know “+gzip” ? Yes, I can unzip the data – that works. Send the data 
to the next pipeline stage.
  *   Do I know “+xml” ? Yes, that’s just XML – can display it.
  *   Do I know “svg” ? No.
  *   End result: display the object in my XML viewer.

(Using here "image/svg+gzip+xml" would lead to incorrect results clearly.)

Esko

From: Orie Steele 
Sent: Tuesday, April 4, 2023 02:09
To: Smith, Ned 
Cc: Laurence Lundblade ; Esko Dijk 
; Michael Richardson ; Thomas 
Fossati ; Thomas Fossati ; cose 
; rats ; anima@ietf.org
Subject: Re: [COSE] [Rats] [Anima] cose+cbor vs cwt in MIME types

Per the JWT BCP, regarding typ.

https://datatracker.ietf.org/doc/html/rfc8725#name-use-explicit-typing

The +jwt suffix goes on the end.

You would need to register +eat as a structured suffix otherwise.

My understanding is that you currently intend to register application/eat as a 
subtype, not a structured suffix (you can do both, see json).

The 116 meeting mentions that while it is the case today that most structured 
suffix are also registered subtypes, this might not be a reliable assumption in 
the future.

The current multiple suffixes draft makes it clear that processing of suffixes 
is right to left (confusing / surprising perhaps).

So you can read the subtype "eat" and then consider it as +cwt, +cose, +cbor, 
for an example media type of "application/eat+cbor+cose+cwt"

As I mentioned before, the multiple suffixes draft might not land... So it 
would be better to avoid multiple plus and follow the conventions from the JWT 
BCP, and avoid registering new or interesting suffixes, given the current 
confusion regarding them.

I'm not saying any of this is correct, just noting what the suffixes draft says 
today, and how it is related to the several +jwt media types that have already 
been registered.

Another interesting case to consider... Data URI of type "eat+jwt+gzip"... 
Since base64 URL encoding can quickly max out QR Codes / NFC or URL limits.

Decompress, verify, parse / validate.

OS


On Mon, Apr 3, 2023, 6:36 PM Smith, Ned 
mailto:ned.sm...@intel.com>> wrote:
> application/eat+cbor+cose+cwt

EAT is a specialization of a CWT or a JWT. What in eat is encoded before the 
cbor (which encodes the token)?

If the conceptual message is identified by a message wrapper 
draft-ftbs-rats-msg-wrap-02 - RATS Conceptual Messages Wrapper 
(ietf.org)<https://datatracker.ietf.org/doc/draft-ftbs-rats-msg-wrap/>, then 
the cbor bytes could be encoded in an cmw array. As in:
`[ “application/cbor+cose+cwt+eat”, bstr ]`

The discussion around cmw hasn’t concluded, but in theory, the array structure 
could be embedded

Re: [Anima] [COSE] [Rats] cose+cbor vs cwt in MIME types

[Esko Dijk]

> I don't understand why it's not application/voucher+cose+cbor.
> The outer encoding is cbor, the next layer is cose.

Well, the reason is clearly that the draft-ietf-mediaman-suffixes is just a 
draft at the moment. Things may change there. We don't want to overhaul our 
draft in this stage or wait until mediaman-suffixes is done, presumably?
So we have to assume for the near future only one suffix has a clearly defined 
semantics.

So it's either

 application/voucher+cbor
 application/voucher+cose(if we register 'cose' in the IANA registry as 
well)

Note that '+cbor' only refers to the outer CBOR encoding, that is, the fact 
that the COSE data is CBOR itself. It doesn't refer to the fact that 'voucher' 
itself is also (again) encoded in a particular form of CBOR.

If mediaman-suffixes in current state would be accepted and become RFC, then it 
could optionally also be:

application/voucher+cose+cbor

(Note: this wouldn't be mandatory, though. All forms are still valid.)

If we want it could be extended to

application/voucher+ysid+cose+cbor

where '+ysid' would indicate it using the CBOR-YANG-SID encoding. This has the 
benefit that a decoder that doesn't know about 'vouchers' but does know about 
CBOR YANG/SID encoding and about COSE, can still represent the information to a 
user in a readable form.

That said, for the constrained bootstrap procedure we are considering there's 
no benefit as such in adding suffixes to the name. And especially not given the 
draft status of multiple suffixes.

As you said also the following would be possible today:

application/voucher+ysid

if we register 'ysid' as being CBOR-YANG-SID that's included in a COSE wrapper. 
I find this less useful than the first options of '+cbor' or '+cose' , it seems 
too specific.

Esko

-Original Message-
From: Anima  On Behalf Of Michael Richardson
Sent: Monday, April 3, 2023 21:10
To: c...@ietf.org; r...@ietf.org; anima@ietf.org
Subject: Re: [Anima] [COSE] [Rats] cose+cbor vs cwt in MIME types


Orie Steele  wrote:
> At IETF 116 this draft was discussed:

> - https://datatracker.ietf.org/doc/draft-ietf-mediaman-suffixes -
> https://youtu.be/BrP1upACJ0c?t=1744

> TLDR; there is work in progress to define multiple suffixes, and how
> they are interpreted.

Right, I read through mediaman-suffixes.
I got the feedback that we should use the most specific type available.

>> Luckily because COSE is just "plain CBOR" itself , we can use the
>> subtype '+cbor'. So having "voucher-cose+cbor" would be fine. Also

I don't understand why it's not application/voucher+cose+cbor.
The outer encoding is cbor, the next layer is cose.

There is the a third layer which is `yang-core`.
(It seems that we ought to call this "ysid"?  or maybe +cst. )


+cwt is also three layers: CBOR, COSE, and then CWT claims inside the signed
part.  So, if we'd call it application/eat+cwt, then we ought also call it
application/voucher+ysid

It seems that we ought to have registered +ysid in RFC9254.
Can we do it in draft-ietf-core-sid-20?





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




___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [Rats] cose+cbor vs cwt in MIME types

[Esko Dijk]

Hi,

As for the questions mentioned on these slides:

1. "Is is '-cose+cbor' or '-cbor+cose'

The registry 
https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml
 lists the subtypes that one have after the '+' sign.
'cbor' is there but 'cose' is not. 'cwt' is also not there.

So for the moment, registering a 'mytype+cose' or 'voucher+cose' or 
'voucher-cbor+cose' is not possible now unless you would also register the 
'+cose' as a subtype.  RFC 9052 did not choose to register the subtype '+cose', 
for whatever reason.

Luckily because COSE is just "plain CBOR" itself , we can use the subtype 
'+cbor'. So having "voucher-cose+cbor" would be fine.Also "voucher+cbor" 
would be equally ok albeit a little bit less informative that it contains COSE.


2. "are they sufficiently different"(this is about 
application/voucher-cose+cbor and application/eat+cwt formats)

The voucher is not a CWT format, e.g. it does not use the standardized CWT 
claims at all. It defines an own format within the constraints of YANG CBOR, 
while CWT does not use any YANG semantics.

(Now converting the constrained Voucher format into a CWT based format would 
certainly be possible; but that's probably not the discussion intended by these 
slides.)

Regards
Esko

PS more detailed info at
https://github.com/anima-wg/constrained-voucher/issues/264
https://github.com/anima-wg/constrained-voucher/issues/263

-Original Message-
From: Anima  On Behalf Of Michael Richardson
Sent: Monday, March 27, 2023 01:19
To: Thomas Fossati ; Thomas Fossati 
; c...@ietf.org; r...@ietf.org; anima@ietf.org
Subject: Re: [Anima] [Rats] cose+cbor vs cwt in MIME types

Michael Richardson  wrote:
> COSE CHAIRS: can we have 5 minutes for this discussion?
> I guess I can make two slides tomorrow and get Thomas to co-author them.

I guess we didn't get any time at COSE.

https://github.com/anima-wg/voucher/blob/main/presentations/ietf116-cose-mime-cwt.pdf

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] I-D Action: draft-ietf-anima-constrained-voucher-20.txt

[Esko Dijk]

This update implements one main change: the included YANG modules for 
constrained versions of the Voucher/Voucher-Request are removed. Instead, the 
modules in draft-ietf-anima-rfc8366bis-07 are now referenced.

Esko

-Original Message-
From: Anima  On Behalf Of internet-dra...@ietf.org
Sent: Monday, March 13, 2023 09:41
To: i-d-annou...@ietf.org
Cc: anima@ietf.org
Subject: [Anima] I-D Action: draft-ietf-anima-constrained-voucher-20.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Autonomic Networking
Integrated Model and Approach (ANIMA) WG of the IETF.

   Title   : Constrained Bootstrapping Remote Secure Key Infrastructure 
(BRSKI)
   Authors : Michael Richardson
 Peter van der Stok
 Panos Kampanakis
 Esko Dijk
   Filename: draft-ietf-anima-constrained-voucher-20.txt
   Pages   : 83
   Date: 2023-03-13

Abstract:
   This document defines the Constrained Bootstrapping Remote Secure Key
   Infrastructure (Constrained BRSKI) protocol, which provides a
   solution for secure zero-touch bootstrapping of resource-constrained
   (IoT) devices into the network of a domain owner.  This protocol is
   designed for constrained networks, which may have limited data
   throughput or may experience frequent packet loss.  Constrained BRSKI
   is a variant of the BRSKI protocol, which uses an artifact signed by
   the device manufacturer called the "voucher" which enables a new
   device and the owner's network to mutually authenticate.  While the
   BRSKI voucher is typically encoded in JSON, Constrained BRSKI uses a
   compact CBOR-encoded voucher.  The BRSKI voucher is extended with new
   data types that allow for smaller voucher sizes.  The Enrollment over
   Secure Transport (EST) protocol, used in BRSKI, is replaced with EST-
   over-CoAPS; and HTTPS used in BRSKI is replaced with CoAPS.  This
   document Updates RFC 8366 and RFC 8995.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-anima-constrained-voucher/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-anima-constrained-voucher-20.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-anima-constrained-voucher-20

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] how should join proxy react to multiple registrars

[Esko Dijk]

It's important for a JP not to switch to a new preferred Registrar in the 
middle of a Pledge "session" (i.e. an active TLS or DTLS connection with 
Registrar).

For a stateful JP, it would be easy to keep state of the selected Registrar: 
e.g. any Pledge packet coming from same link-local IPv6 address and port can be 
identified to belong to the particular "session" and be sent to the same 
Registrar every time.
(This also allows a Pledge to change its LL address in-between 
sessions/attempts, for privacy reasons. Then a next attempt might use a 
different Registrar as determined by JP.)

For a stateless JP, it cannot keep such state per Pledge. What could work there 
is:
1. Select one Registrar and stick to it. Only allow changing to another 
Registrar during a period of inactivity, e.g. no Pledge messages were received 
for some timeout period (> 1 minute?).
2. Select one Registrar out of the N available by a fixed (hash) function that 
maps a LL IPv6 address to an integer 1 ... N . This allows consistent selection 
of a Registrar without keeping any state per Pledge.

We could add a requirement for the JP that it "picks" a single Registrar per 
"session", regardless of how that is implemented. If we don't require this, 
things may start to fail in the multiple-Registrars cases.
Or alternatively, require that only 1 Registrar be deployed.

The exact selection of a Registrar could be up to JP implementation I think. 
E.g. prefer the one with longest TTL, or one that worked before (for a JP 
implementation that can monitor which "sessions" went well or which not.)

Esko

-Original Message-
From: Anima  On Behalf Of Michael Richardson
Sent: Wednesday, January 4, 2023 20:36
To: Brian E Carpenter ; anima@ietf.org
Subject: Re: [Anima] how should join proxy react to multiple registrars


Brian E Carpenter  wrote:
> M_FLOOD includes a TTL.

> "The message MUST contain a time-to-live (ttl) for the validity of the
> contents, given as a positive integer value in milliseconds. There is
> no default; zero indicates an indefinite lifetime."

Sure, so after that time, throw away the announcement.
So the list empties itself without a problem.

> In any case, floods must be ignored after their TTL expires, obviously.
> I see that RFC 8995 specifies the TTL as 18 ms.

> So there's also:

> 5. Pick the one with the longest remaining TTL.

> That should be about the same as #1, but maybe not quite, if we ever
> decided to vary the TTL in future.

Yes, okay, I'll take variation.

We can throw out announcements that don't work, I think.
Let's say one gets a Port Unreachable or No Route to Host.

> Are there any protocol or standard implications?  I don't think so, but I
> wanted to check.


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




___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] I-D Action: draft-ietf-anima-constrained-voucher-19.txt

[Esko Dijk]

Hi all,

This update closes 16 issues that can be found on the GitHub issue tracker, 
using this query : 
https://github.com/anima-wg/constrained-voucher/issues?q=is%3Aissue+is%3Aclosed+closed%3A2022-11-12..2022-12-31

Main change is the inclusion of new examples and new scripts/security-materials 
that were used to generate the examples.
That should fix the issue found (#215) with the signatures in the examples.

Best regards
Esko

-Original Message-
From: Anima  On Behalf Of internet-dra...@ietf.org
Sent: Monday, January 2, 2023 15:54
To: i-d-annou...@ietf.org
Cc: anima@ietf.org
Subject: [Anima] I-D Action: draft-ietf-anima-constrained-voucher-19.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Autonomic Networking Integrated Model and 
Approach WG of the IETF.

Title   : Constrained Bootstrapping Remote Secure Key 
Infrastructure (BRSKI)
Authors : Michael Richardson
  Peter van der Stok
  Panos Kampanakis
  Esko Dijk
  Filename: draft-ietf-anima-constrained-voucher-19.txt
  Pages   : 94
  Date: 2023-01-02

Abstract:
   This document defines the Constrained Bootstrapping Remote Secure Key
   Infrastructure (Constrained BRSKI) protocol, which provides a
   solution for secure zero-touch bootstrapping of resource-constrained
   (IoT) devices into the network of a domain owner.  This protocol is
   designed for constrained networks, which may have limited data
   throughput or may experience frequent packet loss.  Constrained BRSKI
   is a variant of the BRSKI protocol, which uses an artifact signed by
   the device manufacturer called the "voucher" which enables a new
   device and the owner's network to mutually authenticate.  While the
   BRSKI voucher is typically encoded in JSON, Constrained BRSKI defines
   a compact CBOR-encoded voucher.  The BRSKI voucher is extended with
   new data types that allow for smaller voucher sizes.  The Enrollment
   over Secure Transport (EST) protocol, used in BRSKI, is replaced with
   EST-over-CoAPS; and HTTPS used in BRSKI is replaced with CoAPS.  This
   document Updates RFC 8366 and RFC 8995.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-anima-constrained-voucher/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-anima-constrained-voucher-19.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-anima-constrained-voucher-19


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] ANI Autoconfiguration via DNS

[Esko Dijk]

Ok, this clarifies the concept further, thanks.

I see this as useful in a fully distributed ACP, for services to 'find each 
other' and also find nearest instances of particular services. All without 
having necessarily a central node that gets service registrations, keeps a 
database in memory of these, and serves service lookup requests.
(The latter concept of DNS service registration using an SRP Registrar as 
currently defined in the dnssd WG, is still possible - the Registrar itself can 
be advertised as a service in GRASP. But such thing may not be needed in ACP 
context. And it requires using the 'legacy' DNS-SD formats again.)

About using an ASA as a "proxy" to the classic DNS system, i.e. client sends 
GRASP service query and the proxy-ASA does the real DNS query, I had some 
doubts because the client might as well send its DNS queries in 'legacy' format 
directly to the GRASP-advertised DNS server.
But clearly the defined solution would enable both approaches.  So it could 
still be good to have this service encoding in GRASP available as a generic 
tool ; it may evolve over time how ASAs/ACP-nodes would use it in practice.

Regards
Esko
 
-Original Message-
From: Brian E Carpenter  
Sent: Tuesday, December 13, 2022 20:58
To: Esko Dijk ; William Atwood 
; Anima WG 
Subject: Re: [Anima] ANI Autoconfiguration via DNS

On 13-Dec-22 23:53, Esko Dijk wrote:
> Hello Bill,
> 
> You mention "the advantages of using native CBOR encoding".  So this refers 
> to the CBOR encoding of (DNS) service properties, which would avoid parsing 
> of the old DNS format.
> As I understand there's a wish of people to avoid having a DNS data parser in 
> devices in the ACP, since the already-present CBOR parser can then be used 
> instead.
> 
> Now if we would have such DNS-in-CBOR format, it would be more generally 
> useful in IETF and not just in ANIMA. Do you agree?

If it's a 1:1 encoding of DNS format into CBOR, yes, and it sounds like useful 
work in any case.

However, when making a toy implementation of Toerless's proposal when it first 
appeared, I found that it is something different. What he proposes is a great 
simplification of the complexities of DNS-SD, where the semantics are split up 
over SRV,  (or A) and TXT records, all of which need to be parsed to 
extract the semantic content and then merged into a single JSON-like object. 
This complexity is much better done in a single autonomic service agent that 
doesn't need to be in a constrained node. That is the advantage of Toerless's 
proposal and it is really ANIMA scope, IMHO.

Code at 
https://github.com/becarpenter/graspy/blob/master/ASA-examples/GetDNSSD2.py , 
lines 199 through 281. You will see several calls to the DNS resolver and 
analysis of the results;
the client node will just see a single CBOR object (inside a GRASP objective) 
or an error return.

Regards
 Brian
  
> If the format is more generally useful it could be defined in either one of 
> the CBOR, CoRE, or DNSSD WGs.  (Although the latter may not be willing to 
> renew something that's "already good")
> And we need to keep in mind the effort of the CoRE WG (still ongoing 
> draft-ietf-core-href) to define a better encoding of the URI -> the CRI, in 
> CBOR. It isn't trivial to cover all properties of the URI correctly. It takes 
> a lot of effort.
> 
> If we still decide to do this in ANIMA WG context I would just go for the 
> simplest possible subset of DNS-SD that fulfills the use cases and not try to 
> be complete.
> 
> Regards
> Esko
> 
> -Original Message-
> From: Anima  On Behalf Of William Atwood
> Sent: Monday, November 7, 2022 15:56
> To: Anima WG 
> Subject: [Anima] ANI Autoconfiguration via DNS
> 
> Item 08 in the ANIMA agenda for IETF 115.
> 
> draft-eckert-anima-grasp-dnssd presents standards for the data
> structures (GRASP objectives) that will be required to effect
> autoconfiguration of basic services such as syslog, NTP, and DNS, using
> GRASP.
> 
> draft-eckert-anima-services-dns-autoconfig presents standards for
> actually providing these services, using the objectives defined in
> draft-eckert-anima-grasp-dnssd.
> 
> A strong argument is given in section 1 of
> draft-eckert-anima-grasp-dnssd, showing that the reliability and
> security of GRASP, and the advantages of using native CBOR encoding and
> GRASP flooding, justify the effort to define a GRASP-specific approach,
> rather than just using GRASP to carry the packets of the needed services.
> 
> Clearly these services are essential to any running distributed system,
> and standardizing their on-the-wire representation will likely reduce
> potential problems with incompatible software in the future.
> 
> I therefore encourage the WG to adopt these two drafts as Working Group
> documents.
> 
> Bill Atwood
> 
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] ANI Autoconfiguration via DNS

[Esko Dijk]

Hello Bill,

You mention "the advantages of using native CBOR encoding".  So this refers to 
the CBOR encoding of (DNS) service properties, which would avoid parsing of the 
old DNS format. 
As I understand there's a wish of people to avoid having a DNS data parser in 
devices in the ACP, since the already-present CBOR parser can then be used 
instead.

Now if we would have such DNS-in-CBOR format, it would be more generally useful 
in IETF and not just in ANIMA. Do you agree?
If the format is more generally useful it could be defined in either one of the 
CBOR, CoRE, or DNSSD WGs.  (Although the latter may not be willing to renew 
something that's "already good")
And we need to keep in mind the effort of the CoRE WG (still ongoing 
draft-ietf-core-href) to define a better encoding of the URI -> the CRI, in 
CBOR. It isn't trivial to cover all properties of the URI correctly. It takes a 
lot of effort.

If we still decide to do this in ANIMA WG context I would just go for the 
simplest possible subset of DNS-SD that fulfills the use cases and not try to 
be complete.

Regards
Esko

-Original Message-
From: Anima  On Behalf Of William Atwood
Sent: Monday, November 7, 2022 15:56
To: Anima WG 
Subject: [Anima] ANI Autoconfiguration via DNS

Item 08 in the ANIMA agenda for IETF 115.

draft-eckert-anima-grasp-dnssd presents standards for the data 
structures (GRASP objectives) that will be required to effect 
autoconfiguration of basic services such as syslog, NTP, and DNS, using 
GRASP.

draft-eckert-anima-services-dns-autoconfig presents standards for 
actually providing these services, using the objectives defined in 
draft-eckert-anima-grasp-dnssd.

A strong argument is given in section 1 of
draft-eckert-anima-grasp-dnssd, showing that the reliability and 
security of GRASP, and the advantages of using native CBOR encoding and 
GRASP flooding, justify the effort to define a GRASP-specific approach, 
rather than just using GRASP to carry the packets of the needed services.

Clearly these services are essential to any running distributed system, 
and standardizing their on-the-wire representation will likely reduce 
potential problems with incompatible software in the future.

I therefore encourage the WG to adopt these two drafts as Working Group 
documents.

   Bill Atwood

-- 
Dr. J.W. Atwood, Eng. tel:   +1 (514) 848-2424 x3046
Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
Department of Computer Science
and Software Engineering
Concordia University ER 1234  email:william.atw...@concordia.ca
1455 de Maisonneuve Blvd. Westhttp://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [Technical Errata Reported] RFC8995 (7263)

[Esko Dijk]

Thanks Rufus, we even should have a call today at 17:00 CET - call-in details 
are here 
(https://mailarchive.ietf.org/arch/msg/anima/F2Ojytj9qoxlE4XSjtMwXMf8oFs/).

Maybe we could also briefly discuss the difference between "X does Y" versus "X 
MUST do Y" in an RFC, since no-one dared to comment on that yet ;-)

Regards
Esko

-Original Message-
From: Buschart, Rufus  
Sent: Monday, December 12, 2022 22:23
To: Michael Richardson ; Esko Dijk 

Cc: RFC Errata System ; priti...@cisco.com; 
tte+i...@cs.fau.de; michael.h.behrin...@gmail.com; kent+i...@watsen.net; 
war...@kumari.net; rwil...@cisco.com; t...@cs.fau.de; shengji...@bupt.edu.cn; 
anima@ietf.org
Subject: RE: [Anima] [Technical Errata Reported] RFC8995 (7263)

Hello all!

Thank you for working so intensively on my errata. I was invited by one of 
Siemens's representatives in the ANIMA WG to join your call next week. I hope 
I'll be able to make it and would be very happy to work with you on my proposed 
errata.

And btw: I would love to have MUSTs in both paragraphs but didn't dare to 
propose this 

/Rufus



> -Original Message-
> From: Michael Richardson 
> Sent: Monday, 12 December 2022 21:52
> To: Esko Dijk 
> Cc: RFC Errata System ; priti...@cisco.com;
> tte+i...@cs.fau.de; michael.h.behrin...@gmail.com;
> kent+i...@watsen.net; war...@kumari.net; rwil...@cisco.com;
> t...@cs.fau.de; shengji...@bupt.edu.cn; Buschart, Rufus (IT IPS SIP)
> ; anima@ietf.org
> Subject: Re: [Anima] [Technical Errata Reported] RFC8995 (7263)
> 
> 
> Esko Dijk  wrote:
> > The worry I have here is that by the time we get to the document update
> > people may not be around anymore to remember why the 'SHOULD'
> ought to
> > be a 'MUST' and then the wrong change will be made.
> 
> okay.
> 
> Rob Wilton (rwilton)  wrote:
> > If the errata is "Hold for Doc Update" then the RFC editor won't
> > automatically apply the diff.  I'm pretty sure that is only ever done
> > for verified errata.
> 
> so, let's mark it this way for now.
> 
> > There are also notes that can go along with the errata to give further
> > information (e.g., what the proposed long-term resolution is) if that
> > is helpful.
> 
> If have consensus for the next text, then I think the RFC-editor site can do
> the patch process, though, when we mark it as verified.
> 
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [Technical Errata Reported] RFC8995 (7263)

[Esko Dijk]

> Yes, it SHOULD be, "SHOULD be"

And I was saying it MUST be, "MUST be".
The worry I have here is that by the time we get to the document update people 
may not be around anymore to remember why the 'SHOULD' ought to be a 'MUST' and 
then the wrong change will be made.
So better fix the erratum before holding it for doc update. Dismiss it and file 
a new one if needed; I'm happy to propose some text and submit it. But maybe 
that's not the right process here - I don't know how it normally works.

Esko

-Original Message-
From: Michael Richardson  
Sent: Sunday, December 11, 2022 00:27
To: Esko Dijk 
Cc: RFC Errata System ; priti...@cisco.com; 
tte+i...@cs.fau.de; michael.h.behrin...@gmail.com; kent+i...@watsen.net; 
war...@kumari.net; rwil...@cisco.com; t...@cs.fau.de; shengji...@bupt.edu.cn; 
rufus.busch...@siemens.com; anima@ietf.org
Subject: Re: [Anima] [Technical Errata Reported] RFC8995 (7263)

Esko Dijk  wrote:
> The proposed text still needs some work here; I would urge the WG not
> to accept this in current form.  That said, using normative language in
> this specific part certainly helps to clarify the requirements for
> implementers.

So, I agree, but "Hold for document update" means that we can, effectively
update it when we update the document.

Yes, the rfc-editor can/will perform XML substitution for the errata process,
and so we should care a bit about the text proposed, but my take is that it's
better than what we had, and we can tweak this at our leisure.

But... feel free to wordsmith!

> idevid-issuer:  The Issuer value from the pledge IDevID certificate
> SHOULD BE included to ensure unique interpretation of the serial-
> number.
> In the case of a nonceless (offline) voucher-request, an
> appropriate value MUST be configured from the same out-of-band
> source as the serial-number.

Yes, it SHOULD be, "SHOULD be"

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [Technical Errata Reported] RFC8995 (7263)

[Esko Dijk]

Hi all,

The proposed text still needs some work here; I would urge the WG not to accept 
this in current form.  That said, using normative language in this specific 
part certainly helps to clarify the requirements for implementers.

As a side question to all about IETF requirements language - what is the 
difference between "X is included." and "X MUST be included." ?
For many years I have read sentences like "X is included" or "X is set to Y" as 
equivalent to a MUST.  And such sentences are used a lot in RFCs. Surely we 
don't want to replace all of these cases by normative language? But if it helps 
to clarify things for this specific case, then fine to do it. The erratum 
motivation / note was not saying why this particular case needs normative 
language.

A few points:

* corrected text has "SHOULD BE" which isn't RFC 2119 compliant.

* actually, the Registrar MUST include the idevid-issuer field, not intended as 
a "SHOULD". Reason: the Registrar wouldn't know if the MASA would need this 
field or not -- there is no signaling in-protocol by MASA to tell whether it 
wants this field -- so the only thing the Registrar can do is include it to 
cover all cases. There is no reason for the Registrar to exclude it. Or at 
least, I don't know one and no reason is given in the erratum note.

Regards
Esko

-Original Message-
From: Anima  On Behalf Of RFC Errata System
Sent: Friday, December 9, 2022 16:21
To: priti...@cisco.com; mcr+i...@sandelman.ca; tte+i...@cs.fau.de; 
michael.h.behrin...@gmail.com; kent+i...@watsen.net; war...@kumari.net; 
rwil...@cisco.com; t...@cs.fau.de; shengji...@bupt.edu.cn
Cc: rufus.busch...@siemens.com; anima@ietf.org; rfc-edi...@rfc-editor.org
Subject: [Anima] [Technical Errata Reported] RFC8995 (7263)

The following errata report has been submitted for RFC8995,
"Bootstrapping Remote Secure Key Infrastructure (BRSKI)".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7263

--
Type: Technical
Reported by: Rufus Buschart 

Section: 5.5

Original Text
-
idevid-issuer:  The Issuer value from the pledge IDevID certificate
  is included to ensure unique interpretation of the serial-number.
  In the case of a nonceless (offline) voucher-request, an
  appropriate value needs to be configured from the same out-of-band
  source as the serial-number.


Corrected Text
--
idevid-issuer:  The Issuer value from the pledge IDevID certificate
  SHOULD BE included to ensure unique interpretation of the serial-
  number.
  In the case of a nonceless (offline) voucher-request, an
  appropriate value MUST be configured from the same out-of-band
  source as the serial-number.


Notes
-
The current language is no language according to RFC 2119.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC8995 (draft-ietf-anima-bootstrapping-keyinfra-45)
--
Title   : Bootstrapping Remote Secure Key Infrastructure (BRSKI)
Publication Date: May 2021
Author(s)   : M. Pritikin, M. Richardson, T. Eckert, M. Behringer, K. 
Watsen
Category: PROPOSED STANDARD
Source  : Autonomic Networking Integrated Model and Approach
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] Constrained-BRSKI proposed optimization: Pledge doesn't send root CA cert

[Esko Dijk]

All,

At IETF115 I mentioned an open issue for constrained BRSKI is about a proposed 
optimization. Feedback is requested on this!

The idea is that the Pledge does not send the root CA certificate, as part of 
the Client Certificate message of the DTLS handshake with the Registrar.

In TLS/DTLS 1.2 this root CA cert is optionally excluded, as per below text 
from RFC 5246:

  the self-signed certificate that specifies the root
  certificate authority MAY be omitted from the chain, under the
  assumption that the remote end must already possess it in order to
  validate it in any case.

For constrained BRSKI we could RECOMMEND the Pledge to do this, to reduce data 
size on constrained networks and speed up the process.

The assumption on the Registrar is then that either one of these two cases hold:

  1.  Known vendor and/or sales integration: the domain owner Registrar already 
has the vendor’s root CA cert for the product(s) the owner wants to bootstrap. 
This it uses during handshake client verification.
  2.  Unknown vendor and no sales integration: the Registrar can on-the-fly 
identify the Pledge based on the presented IDevID certificate in the handshake, 
and fetch the vendor’s root CA cert by connecting to the MASA server over TLS.

See also Github issue 
https://github.com/anima-wg/constrained-voucher/issues/239.

So if a Pledge vendor sells only under model 1), then excluding the root CA 
cert is always fine.
If a vendor sells under model 2) always or sometimes, then excluding the root 
CA cert is fine under the condition that the TLS connection to the MASA will 
provide the needed root CA cert.  If that MASA TLS connection is authenticated 
otherwise (e.g. something exotic like PSK from a QR code, or using an identity 
from public PKIX hierarchy not related to the Pledge’s root CA) then it implies 
the Pledge MUST include the root CA cert in its Client Certificate message.

Therefore, what we achieve is a substantial savings of over-the-wire data for 
the common cases.

If the proposed solution for model 2) above sounds too restrictive, an 
alternative idea is to define a new HTTPS resource on the MASA server under the 
path “/.well-known/brski/cacerts” which contains all the root CA certs for all 
Pledges that are supported by that MASA. This HTTPS resource is only strictly 
required if the vendor makes Pledges that omit the root CA certificate in the 
handshake.

Regards
Esko
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] WGLC for draft-ietf-anima-brski-cloud-05, ends Nov. 28th, 2022

[Esko Dijk]

Hi all,

Since the WGLC period is now past let me post my viewpoint: the draft is not 
yet ready. Some editorial updates are to be done by the WG and the YANG module 
definition needs fixing.
I will provide my comments as Github PRs in the coming days, which should make 
it easiest to integrate. There I will propose changing "EST Registrar" to "EST 
server".

Regards
Esko

-Original Message-
From: Anima  On Behalf Of Esko Dijk
Sent: Monday, November 21, 2022 10:41
To: Anima WG ; draft-ietf-anima-brski-cl...@ietf.org
Subject: Re: [Anima] WGLC for draft-ietf-anima-brski-cloud-05, ends Nov. 28th, 
2022

Hello all,

I'm reviewing the draft currently and agree it needs at least one more editing 
pass. So far no technical issues came up, only editorial ones and YANG-nits.

To help write up my review comments I do have these questions to the authors:

- should I provide my comments in email, as Github issues, or Github PRs? (any 
preference)

- what is the "EST Registrar"? It is not defined so far. Wouldn't it be better 
to use RFC 8995 terminology of "EST server" ?   So if the cloud Registrar 
supplies the Voucher and that redirects to an owner's EST server, we can call 
that "EST server" or "owner EST server".  It's not a Registrar, so not "EST 
Registrar" or "owner Registrar".The latter term is already used for the 
server that provides a voucher to the pledge.
 (Interesting to consider that the owner's EST server *could* be a Registrar 
i.e. handing out vouchers in theory, even if the 
cloud-Registrar-supporting-pledge already got its voucher from the 
cloud-Registrar.  But let's not say such things in the document to avoid 
complicating it.)

- the YANG contains "RFC : Voucher Profile for Cloud redirected Devices" - 
it seems the name needs updating and there should be an RFC ednote here saying 
the reference is "this RFC". Correct?

- YANG contains this:
 description "Base the constrained voucher upon the regular one";
This looks like a copy/paste leftover from constrained-voucher; correct that it 
should be modified? (Would this also bump the YANG version and date then?)

- YANG description for leaf "est-domain" does not explicitly say the word "EST 
server" which I think it should. So this URI directs to the EST server in the 
owner's domain.

- could YANG support the use case of combining the voucher-constrained  format 
(that extends base voucher) and the voucher-redirected format (from current 
draft) ?  Would that require yet another new YANG module?

Regards
Esko

-Original Message-
From: Anima  On Behalf Of Brian E Carpenter
Sent: Sunday, November 20, 2022 22:27
To: Anima WG 
Subject: Re: [Anima] WGLC for draft-ietf-anima-brski-cloud-05, ends Nov. 28th, 
2022

Hi,

Summary:


This draft is very clear and almost ready, but I think it needs one more 
editing pass. I have some minor substantive comments followed by some nits.

Substantive comments:
=

> Abstract

This is a bit short. I think it should provide a little context for a casual 
reader (what is BRSKI, what is a pledge, what is a registrar).

>  1. Introduction
> 
> Bootstrapping Remote Secure Key Infrastructures [BRSKI] specifies automated 
> bootstrapping of an Autonomic Control Plane.

Not quite. It specifies secure bootstrapping of the individual nodes. It's RFC 
8994 that bootstraps the ACP.

>  2. Architecture
> 
> The high level architecture is illustrated in Figure 1.

I find the "??" in the figure confusing. The Cloud Registrar and the MASA could 
just be shown as adjacent boxes; the explanation in the text is fine.

> TWO CHOICES: 1. Cloud Registrar redirects to Owner Registrar 2. Cloud 
> Registrar returns VOUCHER pinning Owner Register.

That looks ugly as a single pseudo-sentence, and I'm not sure what it means. A 
more complete explanation would be good.

>  2.1. Interested Parties 

I find this section too telegraphic. Needs a bit more grammar...

>  2.2. Network Connectivity
> 
> The assumption is that the pledge already has network connectivity prior to 
> connecting to the cloud registrar. The pledge must have an IP address, 

Should specify that you mean "routeable" IP address, I think. (I suppose it 
could be a ULA in some deployments?)

>  2.3. Pledge Certificate Identity Considerations
> ...
> EST [RFC7030] is not clear on how the CSR Attributes response should be 
> structured, and in particular is not clear on how a server can instruct a 
> client to include specific attribute values in its CSR. 
> [I-D.richardson-lamps-rfc7030-csrattrs] clarifies how a server can use CSR 
> Attributes

I'm not entirely comfortable with this being an Informative reference. Isn't 
this essential for interoperable implementations?

Nits:
=

>  1.2. Target Use C

Re: [Anima] DNS-SD in GRASP - draft-eckert-anima-grasp-dnssd-04

[Esko Dijk]

Hello Brian,

> GRASP is a CBOR-based protocol and the values of GRASP objectives MUST be in 
> CBOR.
Yes, I was also thinking about such a solution. You could define an objective 
'service announcement' and include a CBOR byte string there that encodes one or 
more advertised services in today's DNS(-SD) format. And a pure-GRASP element 
such as distance/range to all these services can be additionally encoded in 
CBOR. Similarly an objective 'service query' is defined, with same CBOR byte 
string encoding the Question(s).

> ... That's a substantial reduction in complexity.
True, for the GRASP node that doesn't have to include the DNS parser. And for 
the programmers of it :)   But another kind of complexity comes in return, that 
is, documents and format definitions in the IETF (specifically now here in the 
ANIMA WG). It creates a mapping of DNS onto CBOR format that is not 100% 
complete. And the documents hint at future extensions to include features of 
DNS to make it more complete, which means more documents, while the basic DNS 
format already has all these things. Both formats may diverge in subtle ways 
that will only emerge later. But I do understand the desire to 'modernize' the 
DNS format; a similar effort is done in CoRE to encode a URI as a CBOR 
structure which avoids a node having to do URI parsing. (It's 'preparsed' so to 
speak.) But it did lead to a lot of discussions, iterations, and unexpected 
semantic problems in that case.

> ... they had no choice, but do we seriously want to force that complexity 
> onto constrained nodes?
Some constrained nodes do include DNS-SD; e.g. in OpenThread the optional DNS 
client has all this and looks like ~10KB compiled on an embedded platform. It's 
still an impressive amount of source code though.
So I'm trying to establish what is the constraint on an ACP-node here, probably 
not flash size, but rather wanting to avoid DNS code complexity which might 
open up opportunities for error and (therefore) potential attacks?

> What the draft does is *centralize* the lookups and the complexity. It gives 
> the distributed clients a central place to do lookups for them.
The draft says "Future work can also define DNS-SD <-> GRASP gateway 
functions.", so a centralized gateway seems not in scope? (Gateway like 
GetDNSSD2.py is implementing ...? )
It also says "Also, the document allows for automatically discovering DNS-SD 
servers." which to me reads as the ACP-node uses GRASP to find a DNS(-SD) 
server and then it can use that server in the classic way. Similar to how you 
discover an NTP time server and then use that server in the classic way.
My strong impression of the draft is that it defines an mDNS-like lookup of 
services, which services can then be used in the way they're supposed to. Any 
node on the ACP could offer a particular service, like NTP, DNS, Radius, etc 
and the distributed discovery then helps to find one or more (nearby) instances 
of a wanted service. That doesn't look centralized to me, but maybe other 
authors could chime in.

> Flooding is a bad idea at that scale. It's a weakness in the GRASP model and 
> is the motivation for work like draft-ietf-anima-grasp-distribution, but we 
> aren't done with that yet.
Indeed this was one of the motivations for the dnssd WG "SRP" protocol, e.g. in 
context of constrained mesh networks with potentially 100s of nodes, to avoid 
the all-to-all communication model of mDNS.
So the draft may emphasize some scalability recommendations, like only 
advertising a few key services needed to bootstrap the system (NTP, logging, 
Radius, central DNS server, ... ) and not that every ACP-node starts 
advertising a bunch of services. (As that wouldn't scale.)

Regards
Esko

-Original Message-
From: Brian E Carpenter  
Sent: Tuesday, November 22, 2022 21:14
To: Esko Dijk ; anima@ietf.org
Cc: Toerless Eckert 
Subject: Re: [Anima] DNS-SD in GRASP - draft-eckert-anima-grasp-dnssd-04

On 22-Nov-22 23:57, Esko Dijk wrote:
> Hi all,
> 
>  From a DNS/DNS-SD background and interest I started looking into 
> draft-eckert-anima-grasp-dnssd-04.  Also saw some earlier list discussion on 
> this topic (GRASP + DNS-SD).
> 
> It looks like the draft mainly aims to provide a “multi-hop mDNS like 
> functionality over an ACP by using GRASP” with unsolicited (flooded) service 
> announcements, plus service queries. That looks quite useful to have (looking 
> at draft-eckert-anima-services-dns-autoconfig-02 for the motivation for this.)
> 
> First question is, why do we want to define a separate GRASP i.e. CBOR format 
> for the DNS(-SD) information? 

That's an easy one. GRASP is a CBOR-based protocol and the values of GRASP 
objectives
MUST be in CBOR. Of course, exactly how the DNS information is respresented in 
CBOR is a matter of design choice. I'll leave Toerless to explain the choice 
that he propo

[Anima] DNS-SD in GRASP - draft-eckert-anima-grasp-dnssd-04

[Esko Dijk]

Hi all,

From a DNS/DNS-SD background and interest I started looking into 
draft-eckert-anima-grasp-dnssd-04.  Also saw some earlier list discussion on 
this topic (GRASP + DNS-SD).

It looks like the draft mainly aims to provide a “multi-hop mDNS like 
functionality over an ACP by using GRASP” with unsolicited (flooded) service 
announcements, plus service queries. That looks quite useful to have (looking 
at draft-eckert-anima-services-dns-autoconfig-02 for the motivation for this.)

First question is, why do we want to define a separate GRASP i.e. CBOR format 
for the DNS(-SD) information? For example in CoRE WG for constrained nodes 
currently the draft draft-ietf-core-dns-over-coap-01 defines the re-use of the 
DNS format and no specific redefinition of this format as CBOR. And this 
intends to work for constrained nodes (like e.g. ACPna?)   So if we still want 
to use a CBOR based format we should have a clear motivation for this. (I 
understood there may be some concerns on code size of the DNS format parser?) 
And ideally in case CoRE WG or another WG does start to define a CBOR-based DNS 
format (there was talk about this at IETF 115, opportunity for even more 
compact representations) then such format would ideally be equal to the one 
carried in GRASP, I think. Otherwise we will have so many different formats!

Re-using the existing DNS formats will save a lot of redefining things, now and 
in the future. If there are worries that some DNS-SD features (like e.g. 
‘_sub’)  are too complex for ACP-nodes then the draft could focus on a 
particular constrained ‘profile’ of DNS-SD that rules out such constructs. So, 
a generic IETF-wide new encoding of DNS-as-CBOR is maybe useful, but doing this 
for GRASP specifically? I have some doubts here.

Second question is, do we need to better motivate in the draft the 100% 
distributed nature of the service discovery mechanism? Since the dnssd WG is 
now moving towards more centralized approaches, avoiding mDNS and avoiding 
multicast/flooding: using Service Registration Protocol (SRP). In this solution 
 there are 1 or a few SRP Registrars to which nodes can register their 
service(s); and DNS clients may discover those services again using (unicast) 
DNS queries to one of the SRP Registrars. Perhaps one motivation is that in the 
bootstrap scenario, no SRP Registrars are defined yet so hence SRP cannot be 
used. And the case of multiple SRP Registrars requires automatic sync’ing 
between Registrars which is complex / not suitable for an ACP. And a single SRP 
Registrar could be possible but is then a single-point-of-failure and nothing 
works if this drops out.

Third question, what if every ACP-node starts flooding some service(s) – is 
that scalable to 100s or 1000s of nodes? Maybe we want to avoid this situation. 
It wasn’t clear to me yet if such use cases are intended. E.g. 
draft-eckert-anima-services-dns-autoconfig-02 mentions “SSH server” as a 
service which is what every ACP-node would have.

Regards
Esko






___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] WGLC for draft-ietf-anima-brski-cloud-05, ends Nov. 28th, 2022

[Esko Dijk]

Hello all,

I'm reviewing the draft currently and agree it needs at least one more editing 
pass. So far no technical issues came up, only editorial ones and YANG-nits.

To help write up my review comments I do have these questions to the authors:

- should I provide my comments in email, as Github issues, or Github PRs? (any 
preference)

- what is the "EST Registrar"? It is not defined so far. Wouldn't it be better 
to use RFC 8995 terminology of "EST server" ?   So if the cloud Registrar 
supplies the Voucher and that redirects to an owner's EST server, we can call 
that "EST server" or "owner EST server".  It's not a Registrar, so not "EST 
Registrar" or "owner Registrar".The latter term is already used for the 
server that provides a voucher to the pledge.
 (Interesting to consider that the owner's EST server *could* be a Registrar 
i.e. handing out vouchers in theory, even if the 
cloud-Registrar-supporting-pledge already got its voucher from the 
cloud-Registrar.  But let's not say such things in the document to avoid 
complicating it.)

- the YANG contains "RFC : Voucher Profile for Cloud redirected Devices" - 
it seems the name needs updating and there should be an RFC ednote here saying 
the reference is "this RFC". Correct?

- YANG contains this:
 description "Base the constrained voucher upon the regular one";
This looks like a copy/paste leftover from constrained-voucher; correct that it 
should be modified? (Would this also bump the YANG version and date then?)

- YANG description for leaf "est-domain" does not explicitly say the word "EST 
server" which I think it should. So this URI directs to the EST server in the 
owner's domain.

- could YANG support the use case of combining the voucher-constrained  format 
(that extends base voucher) and the voucher-redirected format (from current 
draft) ?  Would that require yet another new YANG module?

Regards
Esko

-Original Message-
From: Anima  On Behalf Of Brian E Carpenter
Sent: Sunday, November 20, 2022 22:27
To: Anima WG 
Subject: Re: [Anima] WGLC for draft-ietf-anima-brski-cloud-05, ends Nov. 28th, 
2022

Hi,

Summary:


This draft is very clear and almost ready, but I think it needs one more 
editing pass. I have some minor substantive comments followed by some nits.

Substantive comments:
=

> Abstract

This is a bit short. I think it should provide a little context for a casual 
reader (what is BRSKI, what is a pledge, what is a registrar).

>  1. Introduction
> 
> Bootstrapping Remote Secure Key Infrastructures [BRSKI] specifies automated 
> bootstrapping of an Autonomic Control Plane.

Not quite. It specifies secure bootstrapping of the individual nodes. It's RFC 
8994 that bootstraps the ACP.

>  2. Architecture
> 
> The high level architecture is illustrated in Figure 1.

I find the "??" in the figure confusing. The Cloud Registrar and the MASA could 
just be shown as adjacent boxes; the explanation in the text is fine.

> TWO CHOICES: 1. Cloud Registrar redirects to Owner Registrar 2. Cloud 
> Registrar returns VOUCHER pinning Owner Register.

That looks ugly as a single pseudo-sentence, and I'm not sure what it means. A 
more complete explanation would be good.

>  2.1. Interested Parties 

I find this section too telegraphic. Needs a bit more grammar...

>  2.2. Network Connectivity
> 
> The assumption is that the pledge already has network connectivity prior to 
> connecting to the cloud registrar. The pledge must have an IP address, 

Should specify that you mean "routeable" IP address, I think. (I suppose it 
could be a ULA in some deployments?)

>  2.3. Pledge Certificate Identity Considerations
> ...
> EST [RFC7030] is not clear on how the CSR Attributes response should be 
> structured, and in particular is not clear on how a server can instruct a 
> client to include specific attribute values in its CSR. 
> [I-D.richardson-lamps-rfc7030-csrattrs] clarifies how a server can use CSR 
> Attributes

I'm not entirely comfortable with this being an Informative reference. Isn't 
this essential for interoperable implementations?

Nits:
=

>  1.2. Target Use Cases
> ...
> for many smaller sites (such as teleworkers) no further infrastructure are 
> expected.

s/are/is/

> ...
> While a Cloud Registrar will typically handle all the devices of a particular 
> product line from a particular manufacturer there are no restrictions on how 
> the Cloud Registrar is horizontally (many sites) or vertically (more 
> equipment at one site) scaled.

That sentence is really hard to decode. Please rewrite using more words!

> It is also entirely possible that all devices sold by through a particular 
> VAR 

Please define VAR.

>  1.2.2. Bootstrapping with no Owner Registrar
> ...
> In one use case, an organization has an EST service 

Please define EST.

> The pledge is deployed in the organization's domain, but does not discover a 
> local domain, or owner, registrar. 

Hard to parse. Maybe 

Re: [Anima] 2nd WGLC for draft-ietf-anima-constrained-join-proxy-12, ends September 20th 2022

[Esko Dijk]

For RF bands with legal duty cycle regulations, sure any device using such band 
always has to comply with the duty cycle.
So we could say that's not our specific problem; it holds in general for any 
data sent by the device.

But I do see the point that for duty-cycled RF transmitters there's the added 
challenge in this case that forwarding "untrusted" data traffic eats up the 
hourly data limit that the device has. In that case a device may want to 
throttle depending on how much data it still has left for the coming hour. Or 
it may want to simply apply some preset limit (like 0.2% of channel capacity if 
the RF Tx duty cycle is 1% i.e. 20% of average hourly data budget).  That's up 
to the implementer. 

Esko

-Original Message-
From: Toerless Eckert  
Sent: Thursday, November 3, 2022 11:47
To: Michael Richardson 
Cc: Esko Dijk ; Anima WG 
Subject: Re: [Anima] 2nd WGLC for draft-ietf-anima-constrained-join-proxy-12, 
ends September 20th 2022

On Thu, Nov 03, 2022 at 10:33:47AM +, Michael Richardson wrote:
> > How would you deal with proxies that are on frequencies where the duty 
> cycle
> > is limited by law. For example devices on my 868 home automation 
> network needs to maintain
> > a 1%/hour duty cycle.
> 
> "by law" or by regulation or by protocol?

Pretty sure this would be regulations (aka: civil penalties if you misbehave,
enfroced by whatever the regulatory agency in the country is. I could try to 
look
it up for Germany, where i saw this in the products i am using).

> Your 868 system might be unable to complete onboarding, or maybe it will take
> an hour.

I have to admit i do not even managed to figure out the nominal bitrate best 
case
for he 969 Mhz system ;-) But also the ZWave "Interview" (the system i am using 
in the
USA) is taking several minutes. I can't say this is a good user experience, so 
i am
all for finding best compromise - but challenging.

> > The problem to me seems that under those regulations, badly behaving 
> nodes
> > can force proxy and registrar into exhausting their regulatory limit as
> > well unless either proxy and/or registar do something against that.
> 
> Yes, that's true, and why we want to be able to switch onboarding on/off.

Sure. "Status: Forced to idle - Call 1-800-SORR-YFCC"
;-)

> > It almost feels as if radio networks where there are strict duty-cycle
> > limits are requring per-pledge state on the proxy if the proxy wants to
> > defend itself against the attacking pledge exhausting the proxies own
> > duty-cycle. Unless the proxy function itself stricly operates
> > independent of pledge on a cycle that is below the overal permitted
> > duty-cycle for the proxy.
> 
> Yes, if one has ram and power, a stateful proxy can do a better job of
> defending the network against attacks.  A mains-powered PLC gateway between
> power and 802.15.4 could/should do exactly that.
> (Mind: I saw PLC systems that do Gb/s at networkX two weeks ago...)

Indeed. Building BRSKI for the future we also have to be worried about designing
against obsolete constraints of the past... But i guess LORAWAN would be here 
to say
for long enough for us to worry, right ?!

> > Proxy operations as described in this document are not necessarily 
> sufficient
> > to protect proxy and/or registrar against misbehaving pledges that 
> attack
> > proxy/registar with too much data, especially when using (radio) 
> networks
> > with regulatory limitations on the volume permitted per sender (such as
> > 1% duty-cycle per hour limitatios).
> 
> Yes.  But, let's not boil the ocean.
> It's a PS.  We need to finish it so that we can deploy it so that we can
> learn.  Perfect is the enemy of good enough.

Sure. I just wold love to see us not loosing the insight we're getting here...
wiki / github - where would you think we could best collect them better than
here in email ?

Cheers
Toerless
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP

[Esko Dijk]

> I agree, but I don't see the value in adding bytes to the wire.

+1
To reduce testing effort for adopters of this solution it's best if we do not 
specify/allow other resources than '/'. We haven't identified yet the value of 
allowing other resources (only disadvantages).

Esko

-Original Message-
From: Michael Richardson  
Sent: Wednesday, November 2, 2022 08:07
To: Brian E Carpenter 
Cc: Esko Dijk ; Carsten Bormann ; 
anima@ietf.org; c...@ietf.org
Subject: Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP


Brian E Carpenter  wrote:
> Two comments there:

> 1) It would be trivial to extend the definition of the BRSKI_RJP 
objective by giving
> it a meaningful value field, such as a string defining the URI resource 
name. Like:

> objective-value   =  text  ; URI resource name

I agree, but I don't see the value in adding bytes to the wire.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-



___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP

[Esko Dijk]

Yes it's probably better to call it "path of the resource" or "URI path". 
(Background: In CoAP implementations the term "resource name" is colloquially 
used for the final URI path component. In the RFC 7252 URI composing section 
it's used for the entire URI path + query components.)

Esko

-Original Message-
From: Michael Richardson  
Sent: Wednesday, November 2, 2022 08:08
To: Brian E Carpenter 
Cc: Esko Dijk ; Carsten Bormann ; 
anima@ietf.org; c...@ietf.org
Subject: Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP


{wasn't actually offlist}

Brian E Carpenter  wrote:
> By "URI resource name", do you mean "URI path component"? "Path" seems
> to be the official name for what follows the host in a URI, according
> to RFC3986.

I give up :-)   whatever.

Uri-Path is the name of the CoAP option that I would like permission to omit.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-



___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP

[Esko Dijk]

The Pledge here is not using unsecured CoAP towards the Join Proxy - the Join 
Proxy is using unsecured CoAP towards the "Registrar-Proxy" that is situated on 
a specific port on the Registrar host.
So there should be no big security issues for rogue Pledges. We could of course 
explain in the Security Considerations section that the "Registrar-Proxy" needs 
to (or must) support only one CoAP resource for the Registrar-Proxy 
functionality and not accept requests to arbitrary other resources. Just to be 
complete.

Suppose that a Pledge would try to send unsecured CoAP to a Join Proxy: 
* if sent to the Join Proxy port (i.e. the DTLS port), the Join Proxy would 
just forward this as a data blob as usual and eventually the Registrar will try 
to parse the CoAP message as "DTLS" and fail.
* if sent to any other port, the Join Proxy must discard the data since it is 
not using the proper encryption of the (mesh) network.  The JP only has a port 
"open to the outside world" to relay DTLS data blobs and other ports are not 
open.

On the one hand if we decide to use CoAP for a particular function then we may 
expect implementers need to know CoAP as well and e.g. read RFC 7252. Including 
thinking about security issues of unsecured-CoAP. The benefit or re-use comes 
with that responsibility as well as the CoAP protocol is far more rich/complex 
than what we actually need.
But if we fear that implementers not versed in CoAP are going to mess things 
up, we may want to write some additional guidance. Like how to deal with the 
various options the client may include.

The forward/reverse proxy we tried to explain in 
https://datatracker.ietf.org/doc/html/draft-ietf-core-groupcomm-bis-07#section-3.5
  (in the context of CoAP group communication). No pictures there unfortunately.

Esko

-Original Message-
From: Toerless Eckert  
Sent: Tuesday, November 1, 2022 16:21
To: Michael Richardson 
Cc: Esko Dijk ; anima@ietf.org; c...@ietf.org
Subject: Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP

Our proxy is an application using CoAP. In that respect it is IMHO not a bad
idea to be explicit in what options are and what options are not to be included
in the CoAP headers, and not expect that implementers should/could figure this
all out by themselves. Especially, when there are options whose inclusion and
reaction to could create a security risk.

I guess i do not understand CoAP well enough, but the wy it sounds to me,
unclusion of the Uri option would be a security risk, because it would
allow the Pledge to indicate to the constrained proxy which registrar/proxy to
connect to, right ? Which a pledge shuoldn't be able to know anyhow, but if it
was including it, it could make the proxy select a registrar proxy that it 
shouldn't use.

If we do not document this, how would an implementer be supposed to come to
the conclusion of what E.g.: Esko wrote in his reply, e.g.: that an error
would be raised (which seems what we should do).

Whats even all this terminology - forward/reverse proxy... Is there a simple
picture anyhwere in any of the RFC references explaining this ?

Thanks!
Toerless

On Mon, Oct 31, 2022 at 03:30:09PM +0100, Michael Richardson wrote:
> Toerless Eckert  wrote:
> > Can we make sure that the text does explain why the field is not
> > inclueded, and explain that the packet MUST be rejected if it was
> > included ?
> 
> Why should we reject if it is included?
> 
> > Seems like:
> 
> > Field is not included and would cause rejection of the packet if it was
> > present, because it is inappropriate for the initiator to choose the
> > next hop after the proxy not only because the Pledge would not know it,
> > but because it is also not appropriate for security purposes for the
> > Pledge to choose it.
> 
> > Do i correctly understand this ?
> 
> I don't think it's about the initiator choosing the next proxy.

-- 
---
t...@cs.fau.de
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP

[Esko Dijk]

> Why should we reject if it is included?

The Registrar-Proxy would typically not accept any CoAP forward-proxy request, 
that is, any request containing the Proxy-Uri or Proxy-Scheme Option. 
Instead it would return 5.05 (Proxying Not Supported) error as defined already 
by 7252 Section 5.7.2. 

It doesn't operate as a forward-proxy because we have defined it as a 
reverse-proxy (at least, we have done that per the latest discussion emails.)
In practice a CoAP endpoint of course could operate as both forward and reverse 
proxy, but I don't think we have to say anything about such a situation. (RFC 
7252 should cover any remaining cases and what to do in case the same CoAP 
endpoint is used for multiple purposes.)

Esko

-Original Message-
From: Michael Richardson  
Sent: Monday, October 31, 2022 15:30
To: Toerless Eckert 
Cc: Esko Dijk ; anima@ietf.org; c...@ietf.org
Subject: Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP

Toerless Eckert  wrote:
> Can we make sure that the text does explain why the field is not
> inclueded, and explain that the packet MUST be rejected if it was
> included ?

Why should we reject if it is included?

> Seems like:

> Field is not included and would cause rejection of the packet if it was
> present, because it is inappropriate for the initiator to choose the
> next hop after the proxy not only because the Pledge would not know it,
> but because it is also not appropriate for security purposes for the
> Pledge to choose it.

> Do i correctly understand this ?

I don't think it's about the initiator choosing the next proxy.

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP

[Esko Dijk]

Hi Toerless,

I don't think we have to explain why particular CoAP Options are not included 
in the request - there are many CoAP Options we don't use. And in principle we 
also don't need to motivate our design choices extensively in the draft.
We can just define the positive example of what we do use, as written in the 
current text of the draft. So what we currently use is a "regular" CoAP request 
to the reverse-proxy (i.e. the Registrar-Proxy).  I say "regular" in quotes 
because it is a regular request but to a resource that is a special case in 
CoAP Uri-Path option encoding (the root resource /). 

The Registrar-Proxy indeed selects the "next" destination which is the 
Registrar. (This often called 'next leg' or '2nd leg' in the CoRE WG.)

Esko

-Original Message-
From: Toerless Eckert  
Sent: Thursday, October 27, 2022 19:58
To: Michael Richardson 
Cc: Esko Dijk ; anima@ietf.org; c...@ietf.org
Subject: Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP

Can we make sure that the text does explain why the field is not
inclueded, and explain that the packet MUST be rejected if it was included ?

Seems like:

Field is not included and would cause rejection of the packet if it was
present, because it is inappropriate for the initiator to choose the next hop
after the proxy not only because the Pledge would not know it, but because it is
also not appropriate for security purposes for the Pledge to choose it.

Do i correctly understand this ?

Cheers
Toerless

On Wed, Oct 26, 2022 at 07:38:12PM +0200, Michael Richardson wrote:
> 
> Esko Dijk  wrote:
> > Yes, the assumption is still that a CoAP request made to the root
> > resource (/) is valid and can be encoded by including 0 Uri-Path
> > Options.
> 
> Well, the word from the Oct.12 meeting was that we didn't need it.
> 
> > Since the proposed CoAP message does not contain any Uri-Path
> > option, it should be directed to the root resource. There could also be
> > cases where the Registrar would configure another resource (e.g. /j or
> > /join or whatever) and in such case a Uri-Path option would be needed.
> 
> Okay, but I'd like to not do that :-)
> 
> > I'm not 100% sure if for a resource at the root (/), one Uri-Path
> > Option with 0 length is needed or if 0 Uri-Path Options can be used.
> > Or if both methods would be valid.
> 
> I'm hoping that Carsten or Christian will express an opinion.
> 
> 
> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 



> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima


-- 
---
t...@cs.fau.de
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP

[Esko Dijk]

> > cases where the Registrar would configure another resource (e.g. /j or
>   > /join or whatever) and in such case a Uri-Path option would be needed.
>
> Okay, but I'd like to not do that :-)

Okay, I see your point - let's go for the '/' resource option and see if 
reviewers further down the line are okay with that. I just noticed that when 
GRASP discovery is used (service "BRSKI_RJP") the Join Proxy only discovers IP 
address and port so has to make an assumption on the URI resource name being 
'/'. If any other CoAP resource would be possible as well, then that resource 
name would have to be advertised in GRASP too. We could say that because our 
service is being discovered on a particular port (typically differing from the 
default CoAP port as shown in Section 5.1.1 example) we don't have the issue 
that we would interfere with other resources using name "/".

> So, no Uri-Path option is equivalent to /?
Yes! It's also equivalent to the same URI without the trailing slash, which is 
the format we show in Section 5.1.1.

Regards
Esko


-Original Message-
From: Michael Richardson  
Sent: Wednesday, October 26, 2022 19:39
To: Carsten Bormann 
Cc: Esko Dijk ; anima@ietf.org; c...@ietf.org
Subject: Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP


Carsten Bormann  wrote:
>> I'm not 100% sure if for a resource at the root (/), one Uri-Path
>> Option with 0 length is needed or if 0 Uri-Path Options can be used.
>> Or if both methods would be valid.

> That is a well-known idiosyncracy in the URI format.

> Have a look at: https://www.rfc-editor.org/rfc/rfc7252#section-6.4

> Step 8 treats coap://foo and coap://foo/ in the same way:

>If the value of the  component of |url| is empty or
> consists of a single slash character (U+002F SOLIDUS "/"), then move to
> the next step.

So, no Uri-Path option is equivalent to /?


--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-



___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP

[Esko Dijk]

Yes, the assumption is still that a CoAP request made to the root resource (/) 
is valid and can be encoded by including 0 Uri-Path Options. Since the proposed 
CoAP message does not contain any Uri-Path option, it should be directed to the 
root resource. There could also be cases where the Registrar would configure 
another resource (e.g. /j  or /join or whatever) and in such case a Uri-Path 
option would be needed.

I'm not 100% sure if for a resource at the root (/), one Uri-Path Option with 0 
length is needed or if 0 Uri-Path Options can be used.  Or if both methods 
would be valid.

Esko

-Original Message-
From: Michael Richardson  
Sent: Wednesday, October 26, 2022 16:53
To: Esko Dijk ; anima@ietf.org; c...@ietf.org
Subject: Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP


Esko Dijk  wrote:
>> The Proxy-Scheme option is set to "coap".  Do I even need this?

> I don't think we can use the Proxy-Scheme (or the Proxy-Uri) Option

If we don't need it, then GREAT, that's six bytes we save.


-- 
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-



___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP

[Esko Dijk]

Hi Michael,

>  The Proxy-Scheme option is set to "coap".
> Do I even need this?

I don't think we can use the Proxy-Scheme (or the Proxy-Uri) Option here. The 
reason is that it is meant for a CoAP forward-proxy, that is a proxy that 
receives a CoAP request and creates another fresh/new CoAP request again, based 
on the received request payload and the included Proxy-Uri option or 
alternatively the included Proxy-Scheme option plus other Uri-* options.  But, 
in our case here the proxy does not even create a new CoAP request. Rather, it 
takes the payload bytes only and sends these over UDP to the Registrar's DTLS 
port.  (If the Registrar is a local process, the UDP I mention here is just 
local communication.)

So a CoAP forward proxy seems really not appropriate and it should be a CoAP 
reverse proxy instead. See 5.7.3. of RFC 7252.
Using a reverse proxy means you can just remove the Proxy-Scheme option.

Esko

-Original Message-
From: core  On Behalf Of Michael Richardson
Sent: Monday, October 24, 2022 03:58
To: anima@ietf.org; c...@ietf.org
Subject: [core] ANIMA constrained-join proxy revision to use CoAP


Hi, the -13 version of draft-ietf-anima-constrained-join-proxy is posted now.
Here is the diff:
   
https://www.ietf.org/rfcdiff?url1=draft-ietf-anima-constrained-join-proxy-12=draft-ietf-anima-constrained-join-proxy-13=--html

The -13 is created from a series of pull requests which are not merged, but
he parts where I change the "JPY" to a CoAP header are at:
  https://github.com/anima-wg/constrained-join-proxy/pull/42

Some questions to the CoAP experts.

   The Proxy-Scheme option is set to "coap".

Do I even need this? It costs 6 bytes, I think, assuming that "coap" is a
four byte string, and not code for a enumerated type.  If not, I'd have no
options, and the additional overhead of CoAP vs custom CBOR would be two bytes.

Christian said two weeks ago that we didn't need Uri-Host or Uri-Path
options.  I think that we will be running on a custom port.
(But, RFC9031 thought it needed them. Was that wrong?)

The Registrar's DTLS stack might need to send more than one reply in response
to a single DTLS "POST".  This is buried in the DTLS state machine, and might
be related to DTLS handshake fragmenting headers, or to rekeys, or...
Is that going to be a problem, and is POST still the right method?

Appendix A has some details on the CoAP header, which I'd like a review.
Did I even get it halfway right?

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-



___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Call for agenda items/attendance ANIMA @ IETF 115 / agenda request constrained-voucher

[Esko Dijk]

Title: Status & next steps for draft-ietf-anima-constrained-voucher

Name of Presenter(s): Esko Dijk
Length of time requested: 10-15 mins
Draft: draft-ietf-anima-constrained-voucher

Practical question: besides slides I could also show a live software demo; is 
that okay to do via the MeetEcho screen sharing function?

Regards
Esko

-Original Message-
From: Anima  On Behalf Of Toerless Eckert
Sent: Monday, October 17, 2022 16:40
To: anima@ietf.org; anima-cha...@ietf.org
Subject: [Anima] Call for agenda items/attendance ANIMA @ IETF 115

Dear ANIMA WG

With IETF115 agenda being finalized on friday, ANIMA WG will meet at IETF115 
for one 2 hour slot:
Thursday November 10th, 13:00-15:00 (Session II), Mezzanine 10-11, UTC
(this time TZ is easy, UTC = local! ;-)

Please submit your requests for Agenda items in reply to this email, as soon as 
possible.
official IETF goal is to have agenda available on Octover 26th!

Note that you do not need to have the slides by the time you're asking for the 
slot!

Please send requests to anima-cha...@ietf.org.
Copy anima@ietf.org if you like.

Topic/Title
Name of Presenter(s)
Length of time requested
If applicable: name of draft(s) discussed

Also: Once you have your slides, go to:

  https://datatracker.ietf.org/meeting/115/session/anima

and upload your slides via the "Propose Slides" Button
(pick either of the two slots as you see fit).

Please also remember to (re-)start discussing any non-WG adopted
work also on the anima@ietf.org mailing list to encourage WG
members to read your work and comment!

More details about the IETF 115 will be found at:
https://www.ietf.org/how/meetings/115/
as soon as the agenda requests fill up.

ANIMA WG Chairs, Toerless/Sheng

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] Example where CoAP is used as relay protocol for Join Proxy

[Esko Dijk]

Per the ANIMA/CoRE/IOTops call discussion today, I’m sending the pointers to 
Thread documents and OpenThread source code where CoAP is used as the relay 
protocol (outer layer) of a “Join Proxy” entity.

There’s a Thread white paper here: 
https://www.threadgroup.org/Portals/0/documents/support/CommissioningWhitePaper_658_2.pdf
that mentions the “Joiner Router” function which is similar to Join Proxy.  
It’s unfortunately somewhat out of date, but can be useful to understand the 
context.

In the source code, here is the part where a JP (called JoinerRouter in the 
code) receives a UDP message from the Pledge:
https://github.com/openthread/openthread/blob/main/src/core/meshcop/joiner_router.cpp#L130

This UDP message is CoAPS from the Pledge, and the JP will relay the received 
data within a CoAP message sent to a fixed URI path (named kUriRelayRx):
https://github.com/openthread/openthread/blob/main/src/core/meshcop/joiner_router.cpp#L143
https://github.com/openthread/openthread/blob/main/src/core/meshcop/joiner_router.cpp#L159

Similarly there’s a handler method for incoming CoAP message with particular 
constant path ‘kUriRelayTx’ coming from e.g. a Registrar:
https://github.com/openthread/openthread/blob/main/src/core/meshcop/joiner_router.cpp#L167

The state is extracted from the CoAP message; this state information is not 
encrypted. And then the return UDP (DTLS+coap) payload is sent back to the 
Pledge:
https://github.com/openthread/openthread/blob/main/src/core/meshcop/joiner_router.cpp#L198

regards
Esko

IoTconsultancy.nl  |  Email/Teams: 
esko.d...@iotconsultancy.nl

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] 2nd WGLC for draft-ietf-anima-constrained-join-proxy-12, ends September 20th 2022

[Esko Dijk]

Toerless, thanks for your good input.

> Do you think these are useful numbers ?

The limit on number of mapping states for the stateful proxy sounds okay. The 
ICMP error is useful to signal to a Pledge "try again later, or try another 
proxy/network". Lack of response will signal the same from the Pledge's point 
of view.
Rate-limiting seems also needed on the stateful proxy, for example if one given 
Pledge keeps sending upstream data to the Registrar but the Registrar never 
sends something back it would be unwise to keep on relaying the upstream 
traffic without limits.


> Is it possible to come up with good recommendations on such packet rate 
> limiters ? For example
> 1% of the "uplink" bitrate ? Can you think of mesh networks where this would 
> not
> be a good enough number ? If this (or another number)  makes sense we could 
> suggest
> to add it to the stateless proxy section.

For the stateless proxy, it is hard to determine a good rate limit number. 1% 
is not good because it would slow down the joining process of a genuine Pledge 
to a crawl. Some strategies that could work better:

1. Initially allow a (near) unlimited use of "uplink" bandwidth, to get a fast 
enrollment in the common case. When the relayed traffic persists for some time 
(either by same Pledge or other Pledge, no difference) apply a stricter rate 
limit.
2. Apply a (rough) 'data budget' for upstream traffic to the Registrar. Only if 
sufficient "downstream" traffic comes back from the Registrar to Pledge(s), the 
upstream data is allowed at a high rate. If that's not the case, a strict rate 
limit is applied.
3. Send the radio frames associated to relayed "upstream" traffic with the 
lowest priority.  I.e. have a scheduler with packet priority. I know e.g. 
OpenThread has this to prioritize mesh management-traffic.

A combination of approaches is also possible.
Solution 3 seems easiest to implement, if the mesh network stack already has a 
working priority-based scheduler. But it will probably need to be combined with 
some rate-limit approach too.

So one solution is:
Proxy SHOULD locally schedule the "upstream" IP packets to be sent with lowest 
priority.  And Proxy SHOULD apply a rate limit to "upstream" data volume to be 
approximately equal to the "downstream" data volume (all that's coming back 
from the Registrar).

> If the proxy does not discover a registrar, then of course it can not forward 
> enrolment
> requests. We should at least specify that proxies need to correctly support 
> that
> registrar (announcemenets) are switched on/off. What do you think ?

Yes, the key part here is that when a Proxy once discovers a Registrar it 
cannot assume that this Registrar will be alive on that IP address forever. So 
it needs to rediscover in case the original discovery information expired. If 
rediscovery fails, it will not forward traffic anymore to the old IP address.
This aspect may not be obvious so including that in the security considerations 
sounds good.   (Exact timing out mechanism will depend on the discovery method 
used. DNS-SD may be also an option for a future extension of the draft. )
In the GRASP case it's announcements being switched on/off.  In the CoAP 
discovery case, the Max-Age Option in the response determines for how long the 
result is valid. (Default max-age is 60 secs). The latter may be good to point 
out explicitly as none of the CoAP RFCs mention this use of Max-Age yet; though 
it was raised on the core list and is in draft-lenders-dns-over-coap-04.


> Instead of stopping service announcements (registrar and proxy), i would then 
> love to see the service
> announcements witth some "service status" flag/field. For example "off hours" 
> or the like. Workflow:
> Device to be enrolled has single color LED. You connect it (west coast) to 
> the network, and it would
> indicate "off hours" through eg.: repeating three short blinks. This 
> validates that network connectivity
> works, and that enrolment will proceed once someone switches "BRSKI on" (next 
> morning).
>
> Does that make sense ?

That makes sense, and sounds like possible future work! For now we can just 
rely on discovery and the presence/absence of a service, and its advertised 
lifetime. All of the current discovery methods support that at least.
For CoAP discovery at least some "service availability parameter" could be 
defined in general so that it can be used for any types of services/resources 
advertised.

Regards
Esko

-Original Message-
From: Toerless Eckert  
Sent: Monday, September 26, 2022 21:24
To: Esko Dijk 
Cc: Michael Richardson ; Anima WG ; 
anima-cha...@ietf.org; stokcons 
Subject: Re: [Anima] 2nd WGLC for draft-ietf-anima-constrained-join-proxy-12, 
ends September 20th 2022

Thanks, Esko

inline

Re: [Anima] 2nd WGLC for draft-ietf-anima-constrained-join-proxy-12, ends September 20th 2022 / 6.1.1. Discovery example fix?

[Esko Dijk]

Here another late comment (sorry), on Section 6.1.1:

An EST/Registrar server running at address 2001:db8:0:abcd::52, with
   the JPY process on port 7634, and the stateful Registrar on port 5683
   could reply to a multicast query as follows:

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

  RES: 2.05 Content
  ;rt=brski.rjp,
  ;rt=brski.rv;ct=836,
  ;rt=brski.vs;ct="50 60",
  ;rt=brski.es;ct="50 60",


-->  For completeness the server should also respond with the BRSKI root 
resource, which matches the filter. So:

  RES: 2.05 Content
  ;rt=brski.rjp,
  ;rt=brski,
  ;rt=brski.rv;ct=836,
  ;rt=brski.vs;ct="50 60",
  ;rt=brski.es;ct="50 60",

The motivation why to do this particular query is not so clear in the document. 
I assume the following was intended:

1. JP wanting to find out if stateful JP is supported in this network:   it can 
send this (without the asterisk)
  REQ: GET /.well-known/core?rt=brski
2. JP wanting to find out if stateless JP is supported: 
  REQ: GET /.well-known/core?rt=brski.rjp
3. JP wanting to find out both in a single query:
  REQ: GET /.well-known/core?rt=brski*

In case 1 and 3 the JP may be looking for "rt=brski" in the response. Hence, in 
our example the rt=brski resource must be present. Otherwise, no 
interoperability.
Note that the JP won't care about the details of the /rv, /vs, /es resources. 
It just needs Registrar address and port.

Best regards
Esko

-Original Message-
From: Michael Richardson  
Sent: Wednesday, September 21, 2022 12:31
To: Esko Dijk 
Cc: Anima WG ; anima-cha...@ietf.org; stokcons 

Subject: Re: [Anima] 2nd WGLC for draft-ietf-anima-constrained-join-proxy-12, 
ends September 20th 2022

Okay, thank you. I'll crunch through your comments on Friday.
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] 2nd WGLC for draft-ietf-anima-constrained-join-proxy-12, ends September 20th 2022

[Esko Dijk]

Thanks,

One item I forgot to include which was also on my mind - a security 
consideration. If an autonomous bootstrap method like BRSKI is left "always-on" 
in a mesh network, it means that at any time an off-mesh attacker can contact 
its nearby Join Proxies and flood them with traffic. E.g. using different LL 
addresses to pretend it is multiple Pledges.
This will cause relayed traffic on the mesh, potentially overloading it.

* One solution component is clearly rate-limiting of relayed traffic. But, this 
is not even mentioned in the security considerations. And not in 8995 as far as 
I can tell.
* Another solution component is being able (by an admin) to "turn on" and "turn 
off" the entire option of BRSKI bootstrapping.  This could also be mentioned as 
a security advice: turn it off when not needed i.e. when the operator knows for 
sure there are no new Pledges to be bootstrapped.  The method of "turning 
on/off" could be implementation-specific as we don't define any APIs for 
control of Join Proxies.  The intended behavior of any Join Proxy is then as 
follows:
   1. If BRSKI is "on", respond to discovery requests by Pledges as usual and 
do relay any (DTLS) records they may send to the join-port.
   2. If BRSKI is "off" , don't respond to discovery requests by Pledges and 
don't relay any data sent to the join-port. (Effectively, close it.)

Some networks may have a "BRSKI always on" policy because it's needed for their 
application and for convenience, but for a majority of networks I expect that 
isn't needed.

Maybe such practical security related solutions are already described in other 
documents e.g. 6TiSCH joining or GRASP documents but unfortunately I didn't 
read enough of those documents to know this. If so we can also refer to it as 
security consideration.
For a mesh network, avoiding an outsider to be able to "load" the mesh links 
with random data is especially important.

Regards
Esko

-Original Message-----
From: Michael Richardson  
Sent: Wednesday, September 21, 2022 12:31
To: Esko Dijk 
Cc: Anima WG ; anima-cha...@ietf.org; stokcons 

Subject: Re: [Anima] 2nd WGLC for draft-ietf-anima-constrained-join-proxy-12, 
ends September 20th 2022

Okay, thank you. I'll crunch through your comments on Friday.
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] 2nd WGLC for draft-ietf-anima-constrained-join-proxy-12, ends September 20th 2022

[Esko Dijk]

Hello all,

I read the document again and have provided my comments below. This version 
does not yet look ready to leave our WG, however.  As an example, we have a 
CDDL field name mismatch and Appendix A that doesn't conform to the CDDL. And a 
reference that needs to become normative.
Still the updates that were made since the past review round are quite good.

Best regards
Esko

Review Comments
===

5.2 

A Join Proxy MUST implement both.  A Registrar MUST implement the
   stateful mode and SHOULD implement the Stateless mode.

-> Maybe I missed the discussion on this new statement, sorry! Why can't the 
unconstrained Registrar always implement both modes too? (Code size isn't an 
issue.)
Or do we mean it is always implemented but the operator has to be able to 
disable it for the given network? I supposed the motivation for this 
MUST/SHOULD combination is that we really want a network operator to be able to 
select which mode(s) can be used.
Otherwise, if the Registrar would support both modes as always-available  then 
each Join Proxy could just choose to implement only one mode, saving on 
embedded code size, memory, complexity, etc. Which is also attractive for 
Pledge vendors. But maybe not for the operator.
In short, we don't have to change anything here but some motivation / reasoning 
in the text would be helpful to understand it. 

5.3.1
pledge_content field

-> the field is named "content" in the CDDL, not pledge_content.

6.1.1
The scheme remains coaps
-> Seems not? The scheme is coaps+jpy:// 

The coaps+jpy scheme is registered is defined in Section 9.2, as per
   [RFC7252], Section 6.2
-> the "as per ... " part is unclear. Shouldn't we say that the scheme is 
registered with syntax identical to [RFC7252] Section 6.2 ?  Now it's rather 
fuzzy what is meant.

6.2.1
Discoverable port numbers are
   usually returned for Join Proxy resources in the  of
   the payload (see section 5.1 of [RFC9148]).

-> reference seems wrong - no section 5.1 there? No  mentioned 
also.

7.

In the comparison table, the row "Specification complexity" seems not so 
relevant anymore given that the Join Proxy must implement both modes.
A "Security" row could be useful - in stateful mode, the Join Proxy is more 
vulnerable to resource exhaustion attacks. E.g. attacker uses multiple LL 
addresses and pretends to be N Pledges joining at the same time. 
That seems like a more important consideration for the network operator than 
"Specification complexity".  But if people want to leave it as is, I won't 
object further.

8.

It is also pointed out
   that the encryption in the source is a local matter.  Similarly to
   [RFC8974], the use of AES-CCM [RFC3610] with a 64-bit tag is
   recommended, combined with a sequence number and a replay window.

-> a bit unclear; "the source" - is that the Join Proxy, and is the encryption 
that of the header data? (Not DTLS payload.)  If possible let's name the 
entities here and what is encrypted.

In some installations, layer 2 protection is provided between all
   member pairs of the mesh.  In such an environment encryption of the
   CBOR array is unnecessary because the layer 2 protection already
   provide it.

-> I disagree here. (Or maybe I don’t understand the issue.)   If the JP does 
not encrypt the header data here, then all the (authenticated) mesh nodes on 
the path can read the data and may modify it too. If the JP encrypts the header 
data, these mesh nodes can modify but the JP will detect it. That seems more 
secure so it still helps in this case.  Depends on whether you consider an 
attacker to be possible "on-mesh". Given that malicious programs get delivered 
nowadays in software updates or downloaded scripts, an on-mesh attacker is 
certainly possible.

13.2

[RFC6690]
-> This should be a normative reference. Without it, the discovery (CoAP) can't 
be implemented.

Appendix A

The payload examples do not conform to the CDDL definition.  (They are based on 
the old, pre WG last call format.)



Nits
===

General
-> consistency of capitalization of terms - this is not yet applied. E.g. 
"pledge" vs "Pledge", "JOIN Proxy" vs "Join Proxy" vs "join Proxy" vs 
"Join-Proxy", "CoAP" vs "coap" and perhaps others. This can also be updated in 
the future editing phase of course but to me it looks a bit sloppy if the WG 
doesn't address this. Some other WGs do this at least ;-)

2.

The term "installation network" refers to all devices in the
   installation and the network connections between them.  The term
   "installation IP_address" refers to an address out of the set of
   addresses which are routable over the whole installation network.

-> both terms are never used again in the document. So suggest to remove this 
text - it is not needed.

5.3.1
any kind of of per session
-> typo 'of of'

6.1.1
The coaps+jpy scheme is registered is defined
-> is registered and defined ?

6.1.2
Figure 6: Example of Registrar announcing two services
-> isn't it 3 services 

Re: [Anima] [core] [COSE] empty KID values

[Esko Dijk]

Agree here, the ‘kid’ field includes a hint as to which key to use to verify 
the COSE object.
If the hint is null, or an empty item, and the receiver isn’t able to use that 
as a hint, it can try to identify the key in some other way e.g. based on 
context.
If that’s not possible, then it will just fail the processing.

Specific applications of COSE may pose specific requirements on a ‘kid’ being 
present and what format it should have. In this case, absence of a proper ‘kid’ 
value may lead to an error straight away.

Esko


From: core  On Behalf Of Orie Steele
Sent: Tuesday, July 5, 2022 18:29
To: Michael Richardson 
Cc: anima@ietf.org; cose ; c...@ietf.org
Subject: Re: [core] [COSE] empty KID values

> Should I treat a null/empty kid as if there were no kid field at all,

IMO Yes.

> and then use some other heuristic to find the right verification key

Or just throw an error, if your use case requires `kid`... or would benefit 
from requiring it.

I'd avoid offering to do work to process data where the issuer didn't bother 
doing their job (which is to make your job easier).

Regards,

OS

On Mon, Jul 4, 2022 at 12:29 PM Michael Richardson 
mailto:mcr%2bi...@sandelman.ca>> wrote:

RFC9254-to-be/yang-cbor says:
   Data nodes implemented using a CBOR array, map, byte string, or text
   string can be instantiated but empty. In this case, they are encoded with
   a length of zero.

When encoding/dealing with the COSE Sign0 in
draft-ietf-anima-constrained-voucher, we have some puzzling about what to do
with:

kid: null
or: kid: ""
or: kid: h''

so, two remarks.  First, the kid: field is in the Sign0 structure, not
actually in the YANG-CBOR, so arguably the above comment does *NOT* apply!

My puzzling is about kid.  Should I treat a null/empty kid as if there were
no kid field at all, and then use some other heuristic to find the right
verification key, or should I treat it as a entry null, which must match
a null/""/h'' entry in a database for the key.
Normally, it might be a hash of a public key, so seeing h'xx..xx' would be
reasonable.

I'm curious what COSE people say.
KID is annoyingly use case specific :-(

--
Michael Richardson mailto:mcr%2bi...@sandelman.ca>>   . 
o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide




___
COSE mailing list
c...@ietf.org
https://www.ietf.org/mailman/listinfo/cose


--
ORIE STEELE
Chief Technical Officer
www.transmute.industries

[https://drive.google.com/a/transmute.industries/uc?id=1hbftCJoB5KdeV_kzj4eeyS28V3zS9d9c=download]
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Constrained BRSKI - discovery of Registrar as a security risk ?

[Esko Dijk]

Hi Michael,

Based on your response I've created two proposals:

https://github.com/anima-wg/constrained-join-proxy/issues/33
https://github.com/anima-wg/constrained-voucher/issues/234

regards
Esko

-Original Message-
From: Michael Richardson  
Sent: Thursday, May 19, 2022 15:14
To: Esko Dijk ; anima@ietf.org
Subject: Re: [Anima] Constrained BRSKI - discovery of Registrar as a security 
risk ?


Esko Dijk  wrote:
> There is one particular security aspect for Constrained BRSKI that I
> think has not been discussed so far. It is the following: a device that
> needs to locate the Registrar may do this using discovery.

>   1.  Join Proxy discovers the Registrar
>   2.  Already-enrolled device discovers the  Registrar

> Now there are various discovery protocols that could be used by a
> client, but most of these are not secured i.e. it lacks authentication
> that a discovered Registrar is actually a real, authentic
> Registrar. Any on-network (or on-link, in case of link-local discovery)
> attacker node could claim to be a Registrar.

Just to be clear those reading:  such a device as to be within the L2 domain.
It's not just any drive-by device.  The attacker can't park outside the
factory and do this, they have to at least go through an onboarding process.
They have to be let in.
(Of course, the fastest way "in" may be via some phishing attack against
a desktop computer)

> For case 2 above the
> client can easily authenticate the Registrar once doing its DTLS
> connection to it.
> If it doesn’t check out, the client can try the next
> Registrar in the list.

Agreed.  Should we say something about doing this?

> But for case 1 the Join Proxy doesn’t
> authenticate the Registrar – that would be a task of the Pledge.  So
> the Join Proxy might just pick a ‘malicious’ Registrar instead of the
> real one.

The Join Proxy *could* validate the Registrar in the same was as for case (2).

> For BRSKI + GRASP I understand the risk of a ‘malicious’ Registrar is
> reduced by operation on the autonomic control plane, separate from the
> user plane traffic. Every device that onboards there is
> authenticated. But for Constrained BRSKI use cases where the 6LoWPAN
> Border Routers do *not* join an autonomic control plane, and/or the
> mesh network also doesn’t provide a separated control plane, this risk
> may be non-neglible as I understand it. For example if a small-site
> network uses unprotected Ethernet an attacker could just plug in a
> fake-Registrar device.

Yes, agreed.

> For case 1 if the Join Proxy selects the ‘wrong’ Registrar this can
> then result in a DoS situation, in which the Pledge cannot onboard. So
> it would need to select a new, other Join Proxy with a high risk of
> running into the same problem again. This only causes DoS for the
> Pledge.  Also the Pledge will provisionally accept any Registrar
> (authentication only happens afterwards when it receives the Voucher).
> So in case that the MASA server is applying a TOFU (Trust On First Use)
> policy for Domains it doesn’t know, the Pledge may then become
> onboarded into the wrong (malicious) domain.

Agreed.

> Doing that would lead to a “Pledge hijack” risk. So how should this be
> addressed?

>   1.  Make Registrar discovery more secure in some way so that only
> authentic Registrars are discovered?

Assuming that the Join Proxy has joined the domain, so has the /cacerts,
and the Registrar's anchor can be validated by this trust anchor (highly
recommended, but I don't know if we actually mandate that anywhere), then the
Join Proxy could connect to the Registrar and just validate.
Should we standardize an "echo" method?  CoAP already has that.
The Join Proxy could do a HEAD /cacerts in HTTPS perhaps.

> 2.  Require that a Registrar can
> authenticate in some way to the MASA server ?  (Stronger than
> “RECOMMENDED” as now in 8995)

This falls into whether or not we do TOFU Manufacturers, and I would say no.

> 3.  Enforce operation of Constrained
> BRSKI only on some separate, secured control plane? (E.g. require
> Border Routers to use BRSKI to onboard into an autonomic control plane)

I think that it might be reasonable to suggest that border routers should not
be plugged into an open/easily accessible network.  Pascal might have some
things to say about 6BBR and DETNET here.  But, this could be a Security
Consideration only.

> 4.  We add a note to the Constrained BRSKI security considerations on
> this and leave it up to the implementer?

Let's describe the problem.


--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-



___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] BRSKI-PRM first review comments / remaining review comments

[Esko Dijk]

Hi everyone,

In the past weeks I’ve continued my review and now created more Github issues 
(#22 - #60, see 
https://github.com/anima-wg/anima-brski-prm/issues?q=is%3Aissue+author%3AEskoDijk)
 for items that may require discussion.
Thanks to Steffen and Thomas for starting to resolve these already before I 
manage to announce my own review :)

Overall, the PRM approach looks good & useful although a sort of “reality 
check” would be good to do for using the protocol over low-data links like BLE 
/ NFC. For that I’ve created issue #33 
(https://github.com/anima-wg/anima-brski-prm/issues/33).
Will the waiting times for the operator of the hand-held registrar-agent be 
still roughly acceptable, given the data sizes of the multiple messages that 
need to be exchanged?

When the issues are resolved I can also contribute a Pull Request with some 
readability improvements and nit fixes.

Best regards
Esko


IoTconsultancy.nl  |  Email/Teams: esko.d...@iotconsultancy.nl


From: Anima  On Behalf Of Fries, Steffen
Sent: Thursday, June 9, 2022 08:58
To: Anima@ietf.org
Subject: [Anima] BRSKI-PRM first review comments

Hi all,

We’ve got the first comments from the BRSKI-PRM peer review from Esko. Thanks 
for doing the review.
I’ve included them as issue #16-21 on the anima github 
(https://github.com/anima-wg/anima-brski-prm/issues).
Some of them relate to clarifications of the BRSKI-PRM functionality (e.g., 
usage of nonceless voucher to support offline MASA) and the architectural 
clarifications (e.g., Join Proxy not necessary) They will be addressed in the 
next version of the draft. We will continue using githab to collect the 
comments and also the resolution discussion and provide the information via the 
mailing list.

Best regards
Steffen
--
Steffen Fries
Siemens AG

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] Constrained BRSKI - discovery of Registrar as a security risk ?

[Esko Dijk]

Hello,

There is one particular security aspect for Constrained BRSKI that I think has 
not been discussed so far. It is the following: a device that needs to locate 
the Registrar may do this using discovery. Particular cases:

  1.  Join Proxy discovers the Registrar  (to which to relay DTLS records from 
a Pledge)
  2.  Already-enrolled device discovers the Registrar (to renew its certificate 
using EST, e.g. if it is about to expire)

Now there are various discovery protocols that could be used by a client, but 
most of these are not secured i.e. it lacks authentication that a discovered 
Registrar is actually a real, authentic Registrar. Any on-network (or on-link, 
in case of link-local discovery) attacker node could claim to be a Registrar.
For case 2 above the client can easily authenticate the Registrar once doing 
its DTLS connection to it. If it doesn’t check out, the client can try the next 
Registrar in the list.
But for case 1 the Join Proxy doesn’t authenticate the Registrar – that would 
be a task of the Pledge.  So the Join Proxy might just pick a ‘malicious’ 
Registrar instead of the real one.

For BRSKI + GRASP I understand the risk of a ‘malicious’ Registrar is reduced 
by operation on the autonomic control plane, separate from the user plane 
traffic. Every device that onboards there is authenticated. But for Constrained 
BRSKI use cases where the 6LoWPAN Border Routers do *not* join an autonomic 
control plane, and/or the mesh network also doesn’t provide a separated control 
plane,  this risk may be non-neglible as I understand it. For example if a 
small-site network uses unprotected Ethernet an attacker could just plug in a 
fake-Registrar device.

For case 1 if the Join Proxy selects the ‘wrong’ Registrar this can then result 
in a DoS situation, in which the Pledge cannot onboard. So it would need to 
select a new, other Join Proxy with a high risk of running into the same 
problem again. This only causes DoS for the Pledge.
Also the Pledge will provisionally accept any Registrar (authentication only 
happens afterwards when it receives the Voucher).  So in case that the MASA 
server is applying a TOFU (Trust On First Use) policy for Domains it doesn’t 
know, the Pledge may then become onboarded into the wrong (malicious) domain.

For reference, BRSKI RFC 8995 writes:


   A MASA without any supply-chain integration can simply accept

   registrars without any authentication or on a blind TOFU basis as

   described in Section 
7.4.2.

   ...

   A MASA has the option of not verifying ownership before responding

   with a voucher.  This is expected to be a common operational model

Doing that would lead to a “Pledge hijack” risk. So how should this be 
addressed?

  1.  Make Registrar discovery more secure in some way so that only authentic 
Registrars are discovered?
  2.  Require that a Registrar can authenticate in some way to the MASA server 
?   (Stronger than “RECOMMENDED” as now in 8995)
  3.  Enforce operation of Constrained BRSKI only on some separate, secured 
control plane? (E.g. require Border Routers to use BRSKI to onboard into an 
autonomic control plane)
  4.  We add a note to the Constrained BRSKI security considerations on this 
and leave it up to the implementer?

Regards
Esko

IoTconsultancy.nl  |  Email/Teams: 
esko.d...@iotconsultancy.nl|   +31 6 
2385 8339

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Tsvart last call review of draft-ietf-anima-constrained-join-proxy-10

[Esko Dijk]

Hi Peter, Spencer,

For some more detail on Peter’s ‘No’ answer:

Since the Pledge communicates (link-local) with the Join Proxy using 
DTLS-over-UDP on a network that is likely 6LoWPAN (1280 byte MTU limit) mesh, 
it could happen in theory that the Pledge sends out a DTLS handshake UDP packet 
with a length that brings the carrying IPv6 packet length at 1280.
In this case the DTLS record size is also something close to 1280. (We never 
did the exact calculations.)

This may pose a problem for the stateless Join Proxy that appends a few bytes 
to the DTLS record (to relay it further to the Registrar) so the total length 
of the IPv6 packet sent to Registrar could exceed 1280. (And the Join Proxy is 
still on the mesh network with 1280 byte MTU).
But in any case in the constrained-voucher draft we have written about this:
https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-voucher#section-6.7

So even though we don’t know for sure it is a problem, as we haven’t done the 
calculations in detail, it’s preemptively solved by recommending the Pledge to 
break up the handshake into smaller parts. Then,  the Join Proxy doesn’t need 
to do anything special anymore and it always works.
That also helps with performance on the mesh network due to reduction of 
6LoWPAN fragmentation.

@Spencer do you think the Constrained Join Proxy draft should mention the 
potential issue also?  E.g. a reference to above section 6.7 is easy to make.

Regards
Esko

From: Anima  On Behalf Of Peter van der Stok
Sent: Tuesday, May 17, 2022 10:22
To: Spencer Dawkins 
Cc: tsv-...@ietf.org; anima@ietf.org; 
draft-ietf-anima-constrained-join-proxy@ietf.org; last-c...@ietf.org
Subject: Re: [Anima] Tsvart last call review of 
draft-ietf-anima-constrained-join-proxy-10

Hi Spencer,

thanks for your kind words.

Indeed the answer is no. (at least for the coming 20 years).

Greetings and thanks,

Peter


Spencer Dawkins via Datatracker schreef op 2022-05-17 01:09:
Reviewer: Spencer Dawkins
Review result: Ready

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-...@ietf.org if you reply to or forward this 
review.

This is a well-written specification. My only question - and I expect the
answer will be “no” - is whether there is any concern that sizes of the
resources that are being passed around might exceed the MTU between the pledge
and the registrar, and whether there should be a mention of this possibility in
the specification.

Best,

Spencer

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] FYI: est-coaps registered (was: Re: Discovery of proxy/registrar insufficient (GRASP and) more).

[Esko Dijk]

> > est-coaps and constrained-voucher/brski could have been one document.
>
> Yes. Aurelius said that the other groups like thread, who are working on 
> enrollment
> seemingly haven't started to think about renewal... Maybe thats why nobody 
> brought it
> up (yet).

Is this about discovery of a Registrar and why nobody yet brought up yet how to 
do this? 

Speaking for the OpenThread case at least, it is not because we didn't think 
about renewal. Renewal is done using EST-coaps, triggered either internally (by 
the device itself when its certificate is close to expiry) or by an external 
management tool (that sends a proprietary, secure message to trigger the 
renewal process).
Currently there's an alternative to standardized discovery methods defined - so 
a proprietary unicast method that a mesh device can use to get any additional 
data it needs for network operation. And that includes the Registrar's IP 
address.  We're looking into if that proprietary method can just be replaced by 
DNS-SD unicast query because that feature has been recently added to OpenThread 
(https://openthread.io/reference/group/api-dnssd-server  - it's actually a 
client).

Adding my 2 cents to the discussion: we currently have defined "Constrained 
BRSKI" as really a different protocol from "BRSKI". It is not just about 
running BRSKI over a different transport - it defines a fair amount of 
optimizations, shortcuts etc. to make it more suitable for constrained nodes & 
networks. REST resource names are also different; procedures are deviating, 
etc. So at least we can consider it as a different protocol and assign a 
different service-name.

> > c) Can i circle that argument back to you and ask why we should actually
> > introduce brski.jp/brski.rjp if we already have brski-proxy and 
> brski-registrar ?

For CoRE Link Format discovery, there's a wish to make the names as short as 
possible. And if we consider Constrained BRSKI a different protocol then these 
names can differ too. So it is not just the same as a CoRE representation of a 
DNS(-SD) service.
Also, the brski.rjp is really a different thing from brski-registrar - the 
brski.rjp denotes a server that's able to handle the "JPY" protocol that's 
defined in 5.3 of draft-ietf-anima-constrained-join-proxy. 

Regards
Esko

-Original Message-
From: Anima  On Behalf Of Toerless Eckert
Sent: Sunday, May 8, 2022 19:12
To: Michael Richardson 
Cc: anima@ietf.org
Subject: Re: [Anima] FYI: est-coaps registered (was: Re: Discovery of 
proxy/registrar insufficient (GRASP and) more).

On Sat, May 07, 2022 at 06:32:57PM -0400, Michael Richardson wrote:
> 
> Toerless Eckert  wrote:
> >> I'm not sure that I agree with the name "est-coaps", as I think it's 
> still
> >> "est" with a transport of CoAP/UDP.
> 
> > a) I think you're logically right, but practically we do not have any 
> actual
> > formal service specification agnostic to transport for that abstract 
> EST,
> > such as a TAP-like service interface definition. We only have stuff in
> > rfc9148 and ANIMA cBRSKI draft that reads: "this does the same as XXX
> > in RFC7030/RFC8995".
> 
> I thought in DNS-SD, one would ask for _est._udp.local?

Yes, someone could register service-name "est" for UDP and refer to rfc9148.
That was not my point. My point was that i don't think EST/HTTPs and EST/COAPS
are just one protocol with different underlying transports. Not because
they shouldn't, but just because our specs are too weak to formally make that
claim (IMHO!).

But i am somewhat inconsistent in my arguments here ;-))

> > to see how far one could get with actual code and a set of API functions
> > shared bteween BRSKI/cBRSKI..
> 
> I haven't read that code due to unclear IPR around the patents in Thread.
> 
> > c) Can i circle that argument back to you and ask why we should actually
> > introduce brski.jp/brski.rjp if we already have brski-proxy and 
> brski-registrar ?
> 
> I'm open to any name.

If we can agree on parameters for objective-value and DNS-SD TXT proto= key to
distinguish the different transport/variations, then IMHO it would be nicest
to stick to just brski-proxy and brski-registrar.

> > For unicast, what exactly is then the method to discover the URI of the
> > registrar (across >= 1 L3 hop) ? If there is some mandatory support
> > not only for unicast DNS (requests) but also automatically working
> 
> GRASP SRV.est?

Yes. Except that if we do not adopt my proposed draft(s) that formally introduce
the SRV.* notion, i am not sure how long i want to explicitly explain that name 
choice ;-)

> >> If not for the above, I think that we would not have split RFC9148 out.
> 
> > What do you men with "split out" ?
> 
> est-coaps and constrained-voucher/brski could have been one document.

Yes. Aurelius said that the other groups like thread, who are working on 
enrollment
seemingly haven't started to think about renewal... Maybe thats why 

Re: [Anima] AD review for draft-ietf-anima-constrained-join-proxy-06

[Esko Dijk]

Hi Peter,

Sounds good –could I reverse the order, i.e. look at the diffs in the new I-D 
first and then complain? (I may skip the complaining part if everything looks 
ok ;-) )

Esko

From: Anima  On Behalf Of Peter van der Stok
Sent: Monday, March 21, 2022 10:25
To: Rob Wilton (rwilton) 
Cc: draft-ietf-anima-constrained-join-proxy@ietf.org; anima@ietf.org
Subject: Re: [Anima] AD review for draft-ietf-anima-constrained-join-proxy-06

Hi Rob,

thanks for the review and the encouragements.
Below my reactions on your points.

When you agree with the proposed changes, and nobody else complains, I will 
submit the new I-D at the end of this week.

Greetings,

Peter




Rob Wilton (rwilton) schreef op 2022-03-18 15:44:
Hi,

This is my AD review for draft-ietf-anima-constrained-join-proxy-06.

Thanks for this document.  I found it pleasant to read and only had minor 
comments.

1.
   Abstract:

   This intermediary node is known as a
   "constrained Join Proxy".  An enrolled Pledge can act as a Join
   Proxy.

Is a constrained Join Proxy and Join Proxy the same thing, or is one a subtype 
of the other?  I.e., would it be clearer to say that an enrolled Pledge can act 
as a constrained Join Proxy?

pvds =>
Agree with your suggestion. Terminology reduction is always good.
==>


2. Sec 2.
   The term
   "installation IP_address" refers to the set of addresses which are
   routable over the whole installation network.

Is it referring to the set of addresses, or just one out of the set of 
addresses?

NEW ==>
The term "installation IP_address" refers to an address out of the set of 
addresses which are routable over the whole installation network.
==>


3.  Sec 4.
in an LLN mesh can be

LLN doesn't seem to be defined anywhere.

NEW==>
the Pledge (P), in a Low-Power and Lossy Network (LLN) mesh
 {{RFC7102}} can be more than one hop away from the Registrar (R)
==>

Ignoring Carsten's remark about being badly defined.

4.  Sec 5.1, figure 2.

   IP_P:p_P = Link-local IP address and port of Pledge (DTLS Client)
   IP_R:5684 = Routable IP address and coaps port of Registrar
   IP_Ja:P_J = Link-local IP address and join-port of Join Proxy
   IP_Jb:p_Rb = Routable IP address and client port of Join Proxy

Really just a nit, but I assume that this is a naming scheme here, but I didn't 
find it that intuitive, specifically for differentiating between a link-local 
and routable IP address for the Join Proxy.  E.g., I was wondering if IP_Jl: 
and IP_Jr might be clearer., but I'll leave this entirely to the authors 
discretion.

pvds==>
Thanks, is clearer; changed as suggested in both figures
==>

5. Sec 5.3.

  The
   Registrar replaces the 5th "content" element with the DTLS payload of
   the response message and leaves all other array elements unchanged.

Possibly you could be more explicit that the message is sent back?

NEW==>
After replacing the 5th "content" element with the DTLS payload of the response 
message and leaving all other array elements unchanged, the Registrar returns 
the response message.
==>


6. Sec 5.3

   When additions are added to the array in later versions of this
   protocol, any additional array elements (i.e., not specified by
   current document) MUST be ignored by a receiver if it doesn't know
   these elements.  This approach allows evolution of the protocol while
   maintaining backwards-compatibility.  A version number isn't needed;
   that number is defined by the length of the array.

 So, presumably new elements can be added, but never removed again afterwards?

pvds==>
Yes, I addedd:
NEW==>
 However, this means that message elements are consistently added to earlier 
defined elements to avoid ambiguities.
==>
==>

 7. Sec 6.

   | Ports   | Join Proxy needs   |Join Proxy and Registrar|
   | | discoverable join-port |need discoverable   |
   | || join-ports |
   +-+++

At the point that I read this, I didn't understand why discoverable ports are 
needed for both the Join Proxy and Registrar for the stateless mode.  I think 
that led me to the separate question as to whether it wouldn't make more sense 
to have the section on Discovery before the comparison section.

pvds==>
I see your point and put discovery section before comparison section
==>

8. Sec 7.


   Three discovery cases are discussed: Join Proxy discovers Registrar,
   Pledge discovers Registrar, and Pledge discovers Join Proxy.  Each
   discovery case considers three alternatives: CoAP discovery, GRASP
   discovery, and 6tisch discovery.

When reading this, it wasn't entirely clear to me under what circumstances the 
different discovery mechanisms would be used.  Is it also possible that for 
some networks multiple discovery mechanisms may be available, or would it 
always be the case that only one would be deployed?

NEW==>
Three discovery cases are discussed: Join 

Re: [Anima] Constrained-join-proxy: use of DNS-SD discovery of a Join Proxy

[Esko Dijk]

> I think Michael's point was that *mixing* solutions while running insecurely
> is a bad idea, since it increases the attack surface. (That's also why DULL
> itself only allows a small subset of GRASP operations.)

Ok, agreed. Indeed I was thinking of deployments without DULL/GRASP where 
constrained-BRSKI is used. Then there are other methods of Join Proxy discovery 
as indicated in the join-proxy draft, e.g. by 15.4 beacons or MLE messages 
which I'm most familiar with. 
But CoAP discovery or DNS-SD could be used there in case there's no DULL/GRASP 
support intended. 

The Registrar can be discovered by the Join Proxy in different ways and one of 
these ways may be DNS-SD.

Esko

-Original Message-
From: Brian E Carpenter  
Sent: Friday, December 3, 2021 20:32
To: Esko Dijk ; Michael Richardson 

Cc: anima@ietf.org
Subject: Re: [Anima] Constrained-join-proxy: use of DNS-SD discovery of a Join 
Proxy

On 04-Dec-21 02:54, Esko Dijk wrote:
> Thanks for the input. In constrained-join-proxy-06 both discovery types are 
> mentioned in section 5.1 and the sentence on DNS-SD actually refers to 
> service discovery in general (of either a Join Proxy or a Registrar's 
> join-port for JPY protocol).
> So an implementation could still decide to only allow discovery of the 
> Registrar's join-port and not discovery of the Join Proxy (unprotected/"DULL" 
> side).
> 
> Maybe good to know why mDNS/DNS-SD discovery is a bad idea on the unprotected 
> side?

I think Michael's point was that *mixing* solutions while running insecurely
is a bad idea, since it increases the attack surface. (That's also why DULL
itself only allows a small subset of GRASP operations.)

Brian

> Since we also do e.g. CoAP discovery on the unprotected side. (Is that a bad 
> idea as well?)
> 
> Regards
> Esko
> 
> -Original Message-
> From: Anima  On Behalf Of Brian E Carpenter
> Sent: Thursday, December 2, 2021 20:23
> To: Michael Richardson 
> Cc: anima@ietf.org
> Subject: Re: [Anima] Constrained-join-proxy: use of DNS-SD discovery of a 
> Join Proxy
> 
> On 03-Dec-21 07:01, Michael Richardson wrote:
>>
>>   * While reviewing latest updates; one other issue came up: the draft 
>> (re
>>   * latest in Github) currently mentions DNS-SD as a means for a Pledge 
>> to
>>   * discover a Join Proxy.
>>
>> please note that this discovery occurs on the untrusted ("DULL") side.
>>
>> Brian E Carpenter  wrote:
>>> I think there's another reason for deferring it. We have a pending proposal
>>> in draft-eckert-anima-grasp-dnssd for how DNS-SD will integrate in an
>>> autonomic environment. It seems wise to have more clarity about that before
>>> defining how DNS-SD works for a Join Proxy. The two things may be
>>> completely orthogonal, but that requires a little thought.
>>
>> I don't think we can assume any GRASP or DNS-SD interoperation on the
>> untrusted side.  It's just a bad idea.
> 
> Yes. Probably that merits a MUST NOT in the Security Considerations of
> draft-eckert-anima-grasp-dnssd.
> 
>  Brian
> 
>>
>> As for the Join Proxy discovering the Registrar, that's a different question.
>> We defined GRASP already for that.  If we have a DNS-SD method as well, then
>> that would just be an additional method inside an ACP.
>>
>> --
>> Michael Richardson , Sandelman Software Works
>>-= IPv6 IoT consulting =-
>>
>>
>>
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
> 
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Constrained-join-proxy: use of DNS-SD discovery of a Join Proxy

[Esko Dijk]

Thanks for the input. In constrained-join-proxy-06 both discovery types are 
mentioned in section 5.1 and the sentence on DNS-SD actually refers to service 
discovery in general (of either a Join Proxy or a Registrar's join-port for JPY 
protocol).
So an implementation could still decide to only allow discovery of the 
Registrar's join-port and not discovery of the Join Proxy (unprotected/"DULL" 
side).

Maybe good to know why mDNS/DNS-SD discovery is a bad idea on the unprotected 
side?
Since we also do e.g. CoAP discovery on the unprotected side. (Is that a bad 
idea as well?)

Regards
Esko

-Original Message-
From: Anima  On Behalf Of Brian E Carpenter
Sent: Thursday, December 2, 2021 20:23
To: Michael Richardson 
Cc: anima@ietf.org
Subject: Re: [Anima] Constrained-join-proxy: use of DNS-SD discovery of a Join 
Proxy

On 03-Dec-21 07:01, Michael Richardson wrote:
> 
>  * While reviewing latest updates; one other issue came up: the draft (re
>  * latest in Github) currently mentions DNS-SD as a means for a Pledge to
>  * discover a Join Proxy.
> 
> please note that this discovery occurs on the untrusted ("DULL") side.
> 
> Brian E Carpenter  wrote:
>> I think there's another reason for deferring it. We have a pending proposal
>> in draft-eckert-anima-grasp-dnssd for how DNS-SD will integrate in an
>> autonomic environment. It seems wise to have more clarity about that before
>> defining how DNS-SD works for a Join Proxy. The two things may be
>> completely orthogonal, but that requires a little thought.
> 
> I don't think we can assume any GRASP or DNS-SD interoperation on the
> untrusted side.  It's just a bad idea.

Yes. Probably that merits a MUST NOT in the Security Considerations of
draft-eckert-anima-grasp-dnssd.

Brian

> 
> As for the Join Proxy discovering the Registrar, that's a different question.
> We defined GRASP already for that.  If we have a DNS-SD method as well, then
> that would just be an additional method inside an ACP.
> 
> --
> Michael Richardson , Sandelman Software Works
>   -= IPv6 IoT consulting =-
> 
> 
> 

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] I-D Action: draft-ietf-anima-constrained-join-proxy-05.txt / Section 9 proposed text

[Esko Dijk]

> I don't think that we should make this extensible via IANA registry.
> Any update will mostly have to Amend this document, probably it will have to
> obsolete it.  

I don't have a strong preference here.  Relying on a future follow-up document 
to Amend it, or Obsolete it in a responsible way, seems fine. So we have to 
decide whether to keep the registry or remove it - topic for the call today!

> Of these, I have a slight preference for (2) over (3).
> I don't like (1) at all.

For using the current single-array structure, my preference is (3). Doing (2) 
seems risky from an implementation perspective. In today's Agile SW world, 
people don't consider tomorrow's change so much in today's code. Because 
they're supposed to only consider that in tomorrow's code. But as we know 
today's code isn't always maintained anymore when tomorrow comes ;)
Identifying the particular risk here is left as an exercise to the reader.

> If we really need extensibility, then I would suggest we consider instead:

On your CDDL proposal: using a map here doesn't seem necessary. We need to 
limit the overhead of the JPY message to the absolute minimum - it may be 
transported over 6lowpan links, where the DTLS packet size may be near the 1280 
byte limit. Then there's hardly any space to add more JPY header...
If we really want a clear separation of Header and Content, which isn't the 
case in the current draft, then we could use 2 arrays:

[
[
   ip  : bstr,
   port: int,
   family  : int,
   index   : int
   payload : bstr
],
  payload : bstr
]

Only the embedded array (Header field) is extendible in length.  Doing this 
approach adds only 1 byte to the JPY message size; examples:

[h'FE80C0A801C8', 48551, 6, 0, h'0011']   --- 26 
bytes ; what's currently specified
[[h'FE80C0A801C8', 48551, 6, 0], h'0011'] --- 27 
bytes ; above dual array proposal
[{0:h'FE80C0A801C8', 1:48551, 2:6, 3:0}, h'0011'] --- 31 
bytes ; the smallest possible 'map' approach.

But I'm also ok with a single-array structure if we choose the approach (3) 
i.e. any extensions come *after* the payload element.

Esko

-Original Message-
From: Anima  On Behalf Of Michael Richardson
Sent: Wednesday, December 1, 2021 19:32
To: anima@ietf.org
Subject: Re: [Anima] I-D Action: draft-ietf-anima-constrained-join-proxy-05.txt 
/ Section 9 proposed text


Esko Dijk  wrote:
> Good point; these are not CBOR map keys because it's not a map but an
> array. But still, for an array, the indices could be managed in an IANA
> registry for the JPY protocol. This allows future documents to add new
> map indices to the registry. An alternative is not to create a registry
> at all but just allow an RFC to update the array with 1 or more
> indices. I don't have a preference for one of these solutions.

Arrays are not as easily extensible as maps.
Receivers can't just ignore keys that they don't know.
Fortunately, it's CBOR, so things that the receiver doesn't know about can be
skipped, assuming they implement enough of CBOR.
{Right now, we have bstr, and int.  The enclosing array can be open-coded as
a test for 0x85.  Or processed as an array.  No map, tstr, etc. code needed}

I don't think that we should make this extensible via IANA registry.
Any update will mostly have to Amend this document, probably it will have to
obsolete it.  I don't think we can easily accomodate multiple documents
asking for a code.

There are three ways we can extend this array:
  1) receiver can see that new array has 6+ elements, and then
 can assume the "new" format.  That could involve completely
 changing the order of what is there.

  2) receiver can process first four items as they are, and then
 process the last element as the payload.
 Anything between the fourth element and the payload would be
 ignored in this version, but future versions put new things there.

  3) receiver can process first five items as they are, and new items
 can be placed after the payload, which older receivers are told
 to ignore.

Of these, I have a slight preference for (2) over (3).
I don't like (1) at all.

Just remind other readers:

[
   ip  : bstr,
   port: int,
   family  : int,
   index   : int
   payload : bstr
]

If we really need extensibility, then I would suggest we consider instead:
JPY_message =
[
   details : { ip  : bstr,
   port: int,
   family  : int,
   index   : int },
   payload : bstr
]

{please forgive my poor CDDL here}


--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-



___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] Constrained-join-proxy: how best to define the protocol family number in JPY header?

[Esko Dijk]

(@authors: this is a repeat of a private message to you, but now for on-list 
discussion)

Here one inconsistency I found: the Appendix A example uses IP protocol family 
number 10 for IPv4, while Section 5.3 does not define how the family number is 
chosen; and Section 9.1 defines IPv4 as value 4 and IPv6 as value 6.
So we need to either fix the example, or the Section 5.3 / 9.1 text. Or 
preferably both!

There’s also the option to base the family number upon a long time existing 
IANA registry of protocol families: 
https://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml
In this case we would get 1=IPv4 and 2=IPv6.
(Minor benefit of the existing registry is that also many other protocols as 
shown in the registry could potentially be used. No need to constrain it  to 
only IPv4 and IPv6…)

Best regards
Esko


IoTconsultancy.nl  |  Email/Teams: esko.d...@iotconsultancy.nl


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] Constrained-join-proxy: section 7.1 reference on how to discover a Registrar

[Esko Dijk]

Hello,

Here’s an issue I found in constrained-join-proxy in Section 7.1 regarding 
discovery of a Registrar by the Join Proxy.
It says:

   The discovery of the coaps Registrar, using coap discovery, by the
   Join Proxy follows section 6 of [I-D.ietf-ace-coap-est].

The above seems to be the wrong reference. Because it is about discovering a 
Registrar (as opposed to just “EST server”), I would point to 
draft-constrained-voucher instead: section 6.3 and 6.5.1 of 
draft-ietf-anima-constrained-voucher.
This is very specific to Registrar discovery, also 6.5.1 considers the case of 
a Join Proxy discovering a Registrar, which is a very special case due to the 
below, so it is good to mention 6.5.1 here.

Suppose a stateful Join Proxy discovers the Registrar using query for rt=brski. 
And it finds out the Registrar BRSKI resources are hosted under resource /b on 
port . Then the Proxy will relay all DTLS traffic of the Pledge to the 
Registrar on port  – BUT: the Pledge has no idea that it should be using 
the resource /b/… for BRSKI!  Because it did not do this discovery for 
Registrar resources by itself.   So the only / best thing the Pledge can do is 
to use the well-known resources /.well-known/brski/….  which the Registrar then 
also MUST support on port  and not only on port 5684.  And this is exactly 
what the last paragraph of 6.5.1 tries to clarify.

Regards
Esko


IoTconsultancy.nl  |  Email/Teams: 
esko.d...@iotconsultancy.nl|   +31 6 
2385 8339

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Constrained-join-proxy: use of DNS-SD discovery of a Join Proxy

[Esko Dijk]

Hi Peter,

For me ok to include as well. (If registration is not included, we shouldn’t 
mention DNS-SD discovery, otherwise.)

You can take a look into 
https://datatracker.ietf.org/doc/html/rfc8995#section-8.6  which is a good 
template how the section should be formatted. (E.g. use lowercase, don’t 
include any optional fields, assignee and contact is IESG, etc.)

Esko

From: Anima  On Behalf Of Peter van der Stok
Sent: Wednesday, December 1, 2021 10:14
To: Brian E Carpenter 
Cc: anima@ietf.org
Subject: Re: [Anima] Constrained-join-proxy: use of DNS-SD discovery of a Join 
Proxy

HI Brian,

thanks, your remark is understood.
However, Esko made the right suggestion that a service name must be allocated 
for DNS-SD.
I think that is independent of your protocol draft.
This draft seems the best place to allocate the service names.

My intention is to write a phrase like:

For later discovery of Join Proxy and Registrar server to Join Proxy, using 
DNS-SD or mdns the service names are allocated in section x.x

section x.x

 Service Name: BRSKI-JP

 Transport Protocol(s): UDP

 Assignee: Peter van der Stok

 Contact: Peter van der Stok

 Description: service name of Join Proxy

 Reference [this document]

 Port Number: to be discovered.

 Known Unauthorized: Uses BRSKI porotocol

 Service Name: BRSKI-RJP

 Transport Protocol(s): UDP

 Assignee: Peter van der Stok

 Contact: Peter van der Stok

 Description: service name of Registrar server to Join Proxy

 Reference [this document]

 Port Number: to be discovered.

 Known Unauthorized: Uses BRSKI porotocol
Agreed?

greetings,

Peter


Brian E Carpenter schreef op 2021-11-30 20:42:
On 01-Dec-21 01:55, Esko Dijk wrote:
While reviewing latest updates; one other issue came up: the draft (re latest 
in Github) currently mentions DNS-SD as a means for a Pledge to discover a Join 
Proxy.

But for DNS-SD discovery I believe a service name is needed; see RFC 6763 
Section 7.  But there’s no service name yet defined for a
Join Proxy.

Easiest solution would be to remove the entire DNS-SD sentence and reference.   
I.e. defer this to a future document.


I think there's another reason for deferring it. We have a pending proposal in 
draft-eckert-anima-grasp-dnssd for how DNS-SD will integrate in an autonomic 
environment. It seems wise to have more clarity about that before defining how 
DNS-SD works for a Join Proxy. The two things may be completely orthogonal, but 
that requires a little thought.

Brian



If not removed, we probably need to add a service name registration for
Constrained Join Proxy such that it can advertise its service and port over 
DNS-SD/mDNS correctly.

(Note: the above is unrelated to my earlier remark on requiring a service name 
for the Registrar’s JPY protocol support. This could also
be discovered over DNS-SD/mDNS but would need a separate service name.)

Best regards

Esko

*IoTconsultancy.nl*  |  Email/Teams: 
esko.d...@iotconsultancy.nl<mailto:esko.d...@iotconsultancy.nl> 
<mailto:esko.d...@iotconsultancy.nl<mailto:esko.d...@iotconsultancy.nl>>|
+31 6 2385 8339


___
Anima mailing list
Anima@ietf.org<mailto:Anima@ietf.org>
https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org<mailto:Anima@ietf.org>
https://www.ietf.org/mailman/listinfo/anima
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] Constrained-join-proxy: use of DNS-SD discovery of a Join Proxy

[Esko Dijk]

While reviewing latest updates; one other issue came up: the draft (re latest 
in Github) currently mentions DNS-SD as a means for a Pledge to discover a Join 
Proxy.
But for DNS-SD discovery I believe a service name is needed; see RFC 6763 
Section 7.  But there’s no service name yet defined for a Join Proxy.

Easiest solution would be to remove the entire DNS-SD sentence and reference.   
I.e. defer this to a future document.

If not removed, we probably need to add a service name registration for 
Constrained Join Proxy such that it can advertise its service and port over 
DNS-SD/mDNS correctly.

(Note: the above is unrelated to my earlier remark on requiring a service name 
for the Registrar’s JPY protocol support. This could also be discovered over 
DNS-SD/mDNS but would need a separate service name.)

Best regards
Esko

IoTconsultancy.nl  |  Email/Teams: 
esko.d...@iotconsultancy.nl|   +31 6 
2385 8339

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] checking on advancing draft-ietf-anima-constrained-join-proxy / 'rt' naming

[Esko Dijk]

Apart from the discussion whether the (current) hierarchical naming convention 
is to be used, or any names without hierarchy (because it is allowed for rt), 
there is an additional consideration to make.

If a Pledge wants to use CoAP discovery to discover one of a Constrained Join 
Proxy or Registrar on the link, because typically it would be able to contact 
both (DTLS connection & messages are identical), it would help very much if it 
only has to do a single discovery action for both. And not 2 separate discovery 
actions.

If the Pledge discovers for resources with rt=brski* , this is useful as it 
will find resource "rt=brski" indicating a Registrar and also resources 
"rt=brski.jp" indicating a Constrained Join Proxy. I can pick either one it 
finds. If both are found it may prefer the Registrar directly (rt=brski). 

In my view this naming choice (brski.*) thus makes things more efficient and 
consistent; it is more than just a name.

Regards
Esko

-Original Message-
From: Michael Richardson  
Sent: Wednesday, November 24, 2021 18:49
To: Esko Dijk ; c...@ietf.org
Cc: Sheng Jiang ; anima@ietf.org; Peter van der Stok 

Subject: Re: [Anima] checking on advancing 
draft-ietf-anima-constrained-join-proxy / 'rt' naming


Esko Dijk  wrote:
> I checked the new version against my review comments; and the following
> comment is still open – this is where Peter and me disagree.

understood.
I have no real opinion.

> core.* - CoRE WG types
> ace.* - ACE WG types
> brski.* - ANIMA WG types for BRSKI – not yet in the registry but 
specified in
> draft-constrained-voucher.
> oic.* - any types specified by OCF/OIC
> fa.*  - any types specified by Fairhair Alliance

> Hence my request to comply to this convention, however undocumented it
> is today. Any system architect would agree to that seeing the current
> list.

Can we ask core@ to review and comment then?

original message: 
https://mailarchive.ietf.org/arch/msg/anima/s9yU6LPnV8pE17Ws2xjH2f0mrO0/


--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-



___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] I-D Action: draft-ietf-anima-constrained-join-proxy-05.txt / Section 9 proposed text

[Esko Dijk]

Good point; these are not CBOR map keys because it's not a map but an array. 
But still, for an array, the indices could be managed in an IANA registry for 
the JPY protocol. This allows future documents to add new map indices to the 
registry. An alternative is not to create a registry at all but just allow an 
RFC to update the array with 1 or more indices. I don't have a preference for 
one of these solutions.

In case we go for the registry solution still, the name 'Map index' needs to be 
changed to 'Array index' in the text that I proposed.

For extendibility it would be good to add a sentence in the stateful JPY 
protocol description that any additional array elements (i.e., not specified by 
current document) MUST be ignored by a receiver if it doesn't know these 
elements. This allows evolution of the protocol while maintaining 
backwards-compatibility. And a version number isn't needed; that number is 
defined by the length of the array ;-)

Best regards
Esko

-Original Message-
From: Michael Richardson  
Sent: Wednesday, November 24, 2021 19:00
To: Esko Dijk ; anima@ietf.org; Peter van der Stok 

Subject: Re: [Anima] I-D Action: draft-ietf-anima-constrained-join-proxy-05.txt 
/ Section 9 proposed text


Esko Dijk  wrote:
> Based on my earlier review comments: see below Section 9 proposed text.
> It adds these elements that I think are missing in the current -05
> text. I hope that clarifies it.  Also it refers to an existing IANA
> policy from RFC 8126.

At first, I was all... "how did we miss this".
But, back in section 5.3, JPY_Message was defined as an *array* not a map, so
there are no indexes to manage in an IANA registry.
(Or rather, the indexes are implicit, maybe)

Maybe we can text making this more explicit?


--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-



___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] I-D Action: draft-ietf-anima-constrained-join-proxy-05.txt / Section 9.1 proposed text

[Esko Dijk]

Thanks; the rt names in this PR need to be aligned with the rt names in the 
remainder of this document. Currently, the new names as I proposed are being 
used.
So let's await the outcome of the names choice for this PR.

Esko

-Original Message-
From: Michael Richardson  
Sent: Wednesday, November 24, 2021 19:16
To: Esko Dijk ; anima@ietf.org; Peter van der Stok 

Subject: Re: [Anima] I-D Action: draft-ietf-anima-constrained-join-proxy-05.txt 
/ Section 9.1 proposed text


Esko Dijk  wrote:
> Also based on my review and some ambiguities I noticed in the current
> -05 section 9.1, here is a new text proposal for 9.1 (now renumbered to
> 9.2 based on my previous mail which introduces section 9.1):

now as:
  https://github.com/anima-wg/constrained-join-proxy/pull/8


--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-



___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] I-D Action: draft-ietf-anima-constrained-join-proxy-05.txt / Section 9.1 proposed text

[Esko Dijk]

Hello,

Also based on my review and some ambiguities I noticed in the current -05 
section 9.1, here is a new text proposal for 9.1 (now renumbered to 9.2 based 
on my previous mail which introduces section 9.1):

---
9.2.  Resource Type Attributes registry

   This specification registers new Resource Type (rt=) Link Target
   Attributes in the "Resource Type (rt=) Link Target Attribute Values"
   subregistry under the "Constrained RESTful Environments (CoRE)
   Parameters" registry per the [RFC 6690] procedure.

   Attribute Value: brski.jp
   Description: This BRSKI resource type is used to query and return the 
supported BRSKI (CoAP over DTLS) port of the constrained Join Proxy.
   Reference: [this document]

   Attribute Value: brski.rjp
   Description: This BRSKI resource type is used to query and return the 
supported BRSKI JPY protocol port of the Registrar.
   Reference: [this document]
---

It now uses the right template for the rt registrations. And the descriptions 
per rt make clear which protocol is advertised with the rt, either 
CoAP-over-DTLS, or JPY protocol. 
The naming of the attributes is of course just an example - see the other email 
thread about this.

Esko

-Original Message-
From: Anima  On Behalf Of internet-dra...@ietf.org
Sent: Monday, October 18, 2021 14:12
To: i-d-annou...@ietf.org
Cc: anima@ietf.org
Subject: [Anima] I-D Action: draft-ietf-anima-constrained-join-proxy-05.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Autonomic Networking Integrated Model and 
Approach WG of the IETF.

Title   : Constrained Join Proxy for Bootstrapping Protocols
Authors : Michael Richardson
  Peter van der Stok
  Panos Kampanakis
Filename: draft-ietf-anima-constrained-join-proxy-05.txt
Pages   : 19
Date: 2021-10-18

Abstract:
   This document defines a protocol to securely assign a Pledge to a
   domain, represented by a Registrar, using an intermediary node
   between Pledge and Registrar.  This intermediary node is known as a
   "constrained Join Proxy".

   This document extends the work of [RFC8995] by replacing the Circuit-
   proxy between Pledge and Registrar by a stateless/stateful
   constrained (CoAP) Join Proxy.  It relays join traffic from the
   Pledge to the Registrar.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-anima-constrained-join-proxy/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-join-proxy-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-constrained-join-proxy-05


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] I-D Action: draft-ietf-anima-constrained-join-proxy-05.txt / Section 9 proposed text

[Esko Dijk]

Hello,

Based on my earlier review comments: see below Section 9 proposed text.  It 
adds these elements that I think are missing in the current -05 text. I hope 
that clarifies it.
Also it refers to an existing IANA policy from RFC 8126.

---
9.  IANA Considerations

9.1 Registry for JPY protocol header fields

   This document defines a new IANA registry for map indices of the CBOR
   Map used in the JPY protocol.  The IANA policy for registration of an entry
   in the registry is "IETF Review" as defined by [RFC 8126]. A new registry 
entry
   MUST define the fields Map Index, Name, CBOR Type (referring to [RFC 8949] 
   defined types), and Description.

  The initial contents of the registry are as follows:

  Map Index NameCBOR Type   Description
  = ==  === 

  0 ip  byte string Pledge IPv4/IPv6 link-local 
address (4 or 16 bytes)
  1 portinteger Pledge's UDP port number
  2 family  integer IP address family; IPv4 (value 
4) or IPv6 (value 6)
  3 index   integer Join Proxy network interface 
index/identifier
  4 payload byte string DTLS message payload

---



-Original Message-
From: Anima  On Behalf Of internet-dra...@ietf.org
Sent: Monday, October 18, 2021 14:12
To: i-d-annou...@ietf.org
Cc: anima@ietf.org
Subject: [Anima] I-D Action: draft-ietf-anima-constrained-join-proxy-05.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Autonomic Networking Integrated Model and 
Approach WG of the IETF.

Title   : Constrained Join Proxy for Bootstrapping Protocols
Authors : Michael Richardson
  Peter van der Stok
  Panos Kampanakis
Filename: draft-ietf-anima-constrained-join-proxy-05.txt
Pages   : 19
Date: 2021-10-18

Abstract:
   This document defines a protocol to securely assign a Pledge to a
   domain, represented by a Registrar, using an intermediary node
   between Pledge and Registrar.  This intermediary node is known as a
   "constrained Join Proxy".

   This document extends the work of [RFC8995] by replacing the Circuit-
   proxy between Pledge and Registrar by a stateless/stateful
   constrained (CoAP) Join Proxy.  It relays join traffic from the
   Pledge to the Registrar.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-anima-constrained-join-proxy/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-join-proxy-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-constrained-join-proxy-05


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] checking on advancing draft-ietf-anima-constrained-join-proxy / 'rt' naming

[Esko Dijk]

Hello Sheng, all

I checked the new version against my review comments; and the following comment 
is still open – this is where Peter and me disagree.

> 9.1: the registered resource types (rt) would typically use some
> hierarchy in naming with dots to denote hierarchy. See the current
> entries in the registry:
> https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#rt-link-target-att-value
> For constrained-BRSKI we have defined "brski", "brski.vs", "brski.rv",
> etc.
>
> So to stay with existing conventions we could use such names.  One
> observation is that the Join Proxy in fact offers *all* BRSKI functions
> that the Registrar offers, but then proxied.
>
> -> PvdS Here follows my rant.
> There is no such thing as a convention for rt values.

My point on above is that the convention is that which has been used so far and 
is not written down in any other RFC, draft, document, or policy apart from the 
mere convention – what people register into the CoRE parameters registry ‘rt’ 
attributes.
All rt values so far have used the hierarchy

core.*  - CoRE WG types
ace.* - ACE WG types
brski.* - ANIMA WG types for BRSKI – not yet in the registry but specified in 
draft-constrained-voucher.
oic.* - any types specified by OCF/OIC
fa.* - any types specified by Fairhair Alliance

Hence my request to comply to this convention, however undocumented it is 
today. Any system architect would agree to that seeing the current list.

For the current draft it may be solved by choosing e.g.
rt=brski.jp -   for the Join Proxy’s resource type  (to advertise join 
proxy support to Pledge)
rt=brski.rjp   -   for the Registrar’s Join Proxy port (to advertise 
Registrar’s support for stateless join proxy protocol messages)

I was hoping anyone else in the WG could also comment here to avoid a yes/no 
type discussion.

I’ll also look at the other open comments soon.

best regards
Esko

From: Anima  On Behalf Of Sheng Jiang
Sent: Tuesday, November 16, 2021 11:19
To: anima@ietf.org
Cc: anima-cha...@ietf.org
Subject: [Anima] checking on advancing draft-ietf-anima-constrained-join-proxy


Hi, all,



This is a checking email to the WG collect the opinion whether 
draft-ietf-anima-constrained-join-proxy-05. Following our WGLC on -04 version, 
we asked the IoT directory review. Russ Housley provided it and the authors 
have reported that they addressed the received comments. If anyone has further 
comments, please feel free to raise with details and suggestions. I will start 
my duty as document shepherd next week.



Cheers,



Sheng
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] WGLC for draft-ietf-anima-constrained-join-proxy-04, ends October 14th 2021

[Esko Dijk]

Yes that could certainly be useful! I feel we should ask it after (most of) the 
current review comments are addressed: currently some parts are confusing to a 
reader, and some content is still missing in Sections 8 and 9.

Best regards
Esko


-Original Message-
From: Brian E Carpenter  
Sent: Monday, October 11, 2021 21:38
To: Esko Dijk ; Anima WG ; 
draft-ietf-anima-constrained-join-pr...@ietf.org
Cc: anima-cha...@ietf.org
Subject: Re: [Anima] WGLC for draft-ietf-anima-constrained-join-proxy-04, ends 
October 14th 2021

Esko,

> Also, the document has had little review from the WG so far I could see.

True. Maybe we should also ask for an early review by the Security Area? This 
is a rather specialised topic, and I'm not sure this WG has many people with 
the skills needed for an independent review.

Regards
   Brian Carpenter
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] WGLC for draft-ietf-anima-constrained-join-proxy-04, ends October 14th 2021

[Esko Dijk]

Dear WG, authors, Sheng,

Below my review comments for the draft. Based on this it looks to me not yet 
ready for publication. Also, the document has had little review from the WG so 
far I could see.
But it has clearly improved since my last review and it looks like it could be 
ready on the next iteration.

Regards
Esko


*** Entire document

- Terminology should be made consistent: "Join Proxy", "Join-Proxy", 
"Join_Proxy" - with same capitalization also.
- And also if possible make consistent the wording '"join" port' vs 'join port' 
vs '"Join" port'.
- "cbor" -> "CBOR"

*** Sections 1-6
Nit "togther"
-> together

"The content fields are DTLS encrypted."
-> there is only one content field; make this singular.

Figure 5: "it includes additional IP-addresses" -> rephrase, "additional data 
fields" or so. There's only one ip address inside.

" In particular this section replaces section 4.1 of [RFC8995]."
-> does this mean it formally updates RFC 8995? If so we have to mark this 
draft as "updates RFC 8995" in the header. If not, why not? (Maybe someone in 
the WG can explain this well)


*** Section 7

the 2 steps are both numbered "1."  Step 1. should have a descriptive short 
title also, now it is just called "Two alternatives".
It could be clarified how the Pledge would choose between the two alternatives. 
For example, it typically doesn't know whether case 1a or case 1b applies.  So 
will the Pledge first try 1a? Or first 1b? And if the first attempt fails, try 
the other (1a/1b) ?
Maybe we can say this is left to implementation.  I have a suggestion in 
Section 9.1 (see below) to make this simpler: the Pledge will only discover for 
rt=brski and will find either a true Registrar or a Join Proxy that "appears" 
to be a Registrar even though it isn't itself.
This will make the procedure simpler and is even correct in the rt sense (see 
below 9.1 comments).

In step 2, " Once enrolled, the Join Proxy discovers the join port of the 
Registrar." I'm a bit confused about what "Once enrolled" means here. Once the 
Pledge is enrolled?  Or do we mean once the Join Proxy is enrolled? (Given that 
a Pledge could become Join Proxy after its enrollment.)
I would clarify this to "The Join Proxy discovers the join port of the 
Registrar. The Join Proxy may do this at the moment it needs to relay a DTLS 
message to the Registrar, or it may do this discovery already in advance."

" threa" -> "three"

7.2.1 " The Pledge MUST listen for GRASP M_FLOOD [RFC8990] announcements" -> 
this MUST requirement is only for a Pledge that uses GRASP / ACP. 
We could formulate that in a similar way as in RFC 8995, e.g. "This section is 
normative for uses with an ANIMA ACP."

Nit: I would keep the order of the 3 technologies the same in Section 7.1.* and 
7.2.* . For example always do the subsections in the order as announced in 7.2: 
" coap discovery, 6tisch discovery and GRASP discovery".

7.2.3: text says " Not applicable."   Why would a 6tisch Pledge have no need to 
discovery the Join Proxy? Surely there is something, maybe only sending a 
802.15.4 beacon request or so to get a response from a neighbor Join Proxy?
Maybe briefly explain why not applicable. E.g. in that case how does the Pledge 
know which of multiple networks/Join Proxies to contact.

7.3: title of section seems wrong? In Section 7 we announce the following 3 
cases: 
   Three discovery cases are discussed: Join_proxy discovers Registrar,
   Pledge discovers Registrar, and Pledge discovers Join-proxy.

So I would suggest we have these titles approximately, and set in the right 
order as announced:
7.1 Join proxy discovers Registrar
7.2 Pledge discovers Registrar
7.3 Pledge discovers Join Proxy

7.3.1: "The discoverable port numbers are usually returned for Join Proxy
   resources in the  of the payload (see section 5.1 of
   [I-D.ietf-ace-coap-est])."
-> I don't see href mentioned in Section 5.1. So this statement isn't clear 
enough.  Note that the part between angle brackets, if you mean this, is called 
URI-Reference in Core Link Format. That contains the port number. We can also 
mention
that the string "join-port" in the example above will be the port number.


*** Section 8
" communication is between the Proxy and a known registrar are over the
   already secured portion of the network, so are not visible to
   eavesdropping systems"
-> should be a little bit more specific: only the L2 encryption of the (mesh) 
network protects this traffic, usually with a shared key that has a rather wide 
distribution over many nodes.  There's no DTLS or other one-to-one protection. 
On-network eavesdroppers and attackers can access this header information.

Typo " communicatione" 

" If the communicatione between Join-Proxy and Registrar passed over an
   unsecure network, then an attacker could change the cbor array,
   causing the Pledge to send traffic to another node."
-> true, if the mesh is not L2-secured then an off-mesh attacker could sniff it 

Re: [Anima] RFC 8366 / BRSKI / constrained-voucher: what is encoded in the idevid-issuer field?

[Esko Dijk]

Hi,

> See one example of Authority Key Identifier available at: 
> http://www.pkiglobe.org/aki_ski.htm
> the length of Authority Key Identifier is 20 bytes, also seems it uses text 
> readable format, i.e.,PEM rather than 
> binary encoded format, which aligns with idevid-issuer example (i.e., 
> base64encodedvalue==) in the section 5.2 of RFC8366.

Yes it can be rendered in whatever text format; converted to PEM, or base64 
encoded. Because we use the constrained-Voucher format (of 
draft-ietf-anima-constrained-voucher) we use the pure binary format; see 
"idevid-issuer" in Section 8.1.1 and 8.2.1 and Section 5.1 of RFC 8366. This is 
binary encoded directly using YANG-to-CBOR without further encodings like 
base64. With YANG-to-JSON encoding rules, it is base64 encoded String, and this 
is the Section 5.2 example.

> [Qin]: Do you propose to add more attributes or fields in the AKI? E.g., add 
> cryptography methods, see cryptograph methods example in 
> https://asecuritysite.com/encryption/sigs4
No new attributes, only those already defined in RFC 5280 Section 4.2.1.1. A CA 
generating certificates MAY include the named fields 'authorityCertIssuer' 
and/or 'authorityCertSerialNumber' , in addition to 'keyIdentifier'.  Although 
it is normally not done and not necessary.
So only Option 1 removes these fields 'authorityCertIssuer' and/or 
'authorityCertSerialNumber' ; while Option 2 and 3 keep them in if present.

(Note that the field 'keyIdentifier' is always there, due to the IEEE 801.1AR 
requirements for the IDevID certificate.)

> It seems we will completely remove the “issuer” from authorityKeyIdentifier 
> for some reasons.
The "issuer" / 'authorityCertIssuer' is often not present; but we don't propose 
to remove it if present - Option 2 and 3 keep it in. (Only Option 1 ignores it 
completely keeping only the 'keyIdentifier')
So I don't think there's a concern here.

Regards
Esko

-Original Message-
From: Qin Wu  
Sent: Friday, September 24, 2021 11:44
To: Esko Dijk ; sp...@ietf.org
Cc: anima@ietf.org
Subject: RE: [Anima] RFC 8366 / BRSKI / constrained-voucher: what is encoded in 
the idevid-issuer field?

Hi, Esko:

-邮件原件-
发件人: Esko Dijk [mailto:esko.d...@iotconsultancy.nl] 
发送时间: 2021年9月23日 22:44
收件人: Qin Wu ; sp...@ietf.org
抄送: anima@ietf.org
主题: RE: [Anima] RFC 8366 / BRSKI / constrained-voucher: what is encoded in the 
idevid-issuer field?

Hi,

> [Qin]: Yes, I confuse with the option2 and 3, 1. first, I didn't see 2 
> bytes 04 18 appeared in the below 26 bytes example encoded data 2. 
> Second I think ox18 standard for length of encoded data which is 24 bytes.
> 3. Since the 'SEQUENCE' is included in the encoded data, why not choose 
> option 2?

1. Indeed for Option 3, the idevid-issuer field bstr would contain 26 bytes: 
041830168014D5039FC78A4DC0468760191FD71B1534C2D88428
Option 2 is 24 bytes: 30168014D5039FC78A4DC0468760191FD71B1534C2D88428
Option 1 is 20 bytes: D5039FC78A4DC0468760191FD71B1534C2D88428
[Qin]: Thank for clarification.
See one example of Authority Key Identifier available at: 
http://www.pkiglobe.org/aki_ski.htm
the length of Authority Key Identifier is 20 bytes, also seems it uses text 
readable format, i.e.,PEM rather than binary encoded format, which aligns with 
idevid-issuer example (i.e., base64encodedvalue==) in the section 5.2 of 
RFC8366.

2. Sorry, not quite sure what you meant here! 
[Qin] Thank, I think you clear my confusion on the encoded data format.
In this case the data inside the octet string ('payload') is 24 bytes but it 
could be another value depending on how the CA encodes its Authority Key 
Identifier ext, e.g. how it is hashed / how long the hash is, and what other of 
the optional fields are included in the AKI.
[Qin]: Do you propose to add more attributes or fields in the AKI? E.g., add 
cryptography methods, see cryptograph methods example in 
https://asecuritysite.com/encryption/sigs4 

3. Option 2 and 3 are quite similar I think. In the Constrained-BRSKI draft + 
interop work we have just selected Option 3, though.  This was based on the 
feeling that Option 3 was closest to the present RFC 8366 definition. The size 
was not really an argument here because the field is used always in the 
non-constrained network leg Registrar -> MASA (in Voucher Request) and hardly 
ever used in the constrained network leg (Registrar -> Pledge, in Voucher).
[Qin]: Understood now. I agree with your statement.
In addition, It looks authorityKeyIdentifier=keyid,issuer, the keyed is The Key 
ID of the CA’s cert, the issuer is the subject and the serial number of the 
CA’s cert
One example of X509v3 Authority Key Identifier is:
X509v3 Authority Key Identifier: 
keyid:7E:E5:82:FF:FF:FF:15:96:9B:40:FF:C9:5E:51:FF:69:67:4D:BF:FF
DirName:/C=UK/O=V13/OU=V13/CN=V13 Certificate Authority
serial:8E:FF:A2:1B:74:DD:54:FF
In this example, both DirName and Serial are see

Re: [Anima] RFC 8366 / BRSKI / constrained-voucher: what is encoded in the idevid-issuer field?

[Esko Dijk]

Hi,

> [Qin]: Yes, I confuse with the option2 and 3, 
> 1. first, I didn't see 2 bytes 04 18 appeared in the below 26 bytes example 
> encoded data
> 2. Second I think ox18 standard for length of encoded data which is 24 bytes.
> 3. Since the 'SEQUENCE' is included in the encoded data, why not choose 
> option 2?

1. Indeed for Option 3, the idevid-issuer field bstr would contain 26 bytes: 
041830168014D5039FC78A4DC0468760191FD71B1534C2D88428
Option 2 is 24 bytes: 30168014D5039FC78A4DC0468760191FD71B1534C2D88428
Option 1 is 20 bytes: D5039FC78A4DC0468760191FD71B1534C2D88428

2. Sorry, not quite sure what you meant here! In this case the data inside the 
octet string ('payload') is 24 bytes but it could be another value depending on 
how the CA encodes its Authority Key Identifier ext, e.g. how it is hashed / 
how long the hash is, and what other of the optional fields are included in the 
AKI.

3. Option 2 and 3 are quite similar I think. In the Constrained-BRSKI draft + 
interop work we have just selected Option 3, though.  This was based on the 
feeling that Option 3 was closest to the present RFC 8366 definition. The size 
was not really an argument here because the field is used always in the 
non-constrained network leg Registrar -> MASA (in Voucher Request) and hardly 
ever used in the constrained network leg (Registrar -> Pledge, in Voucher).

Best regards
Esko

-Original Message-
From: Qin Wu  
Sent: Tuesday, September 21, 2021 12:44
To: Esko Dijk ; la...@ietf.org
Cc: anima@ietf.org
Subject: RE: [Anima] RFC 8366 / BRSKI / constrained-voucher: what is encoded in 
the idevid-issuer field?

Hi, Esko:

-邮件原件-
发件人: Anima [mailto:anima-boun...@ietf.org] 代表 Esko Dijk
发送时间: 2021年9月20日 20:48
收件人: Qin Wu ; la...@ietf.org
抄送: anima@ietf.org
主题: Re: [Anima] RFC 8366 / BRSKI / constrained-voucher: what is encoded in the 
idevid-issuer field?

Hello Qin,

> naming of this leaf ' idevid-issuer ' is the root cause for 
> introducing such confusion,

For me the cause of the confusion was the sentence " The Authority Key 
Identifier OCTET STRING (as defined in Section 4.2.1.1 of RFC 5280)".
There is only one OCTET STRING defined in Section 4.2.1.1, which is the 
keyIdentifier field, also named "Key Identifier" in the draft which is not the 
"Authority Key Identifier".
The actual Authority Key Identifier OCTET STRING is defined in Section 4.1 as 
the field " extnValue" which is present in the Authority Key Identifier 
extension, so one needs to look in another section (4.1) for the meant OCTET 
STRING.  The interpretation is still ambiguous between options 2 and 3 even if 
you analyse closely.
[Qin]: Yes, I confuse with the option2 and 3, 
1. first, I didn't see 2 bytes 04 18 appeared in the below 26 bytes example 
encoded data
2. Second I think ox18 standard for length of encoded data which is 24 bytes.
3. Since the 'SEQUENCE' is included in the encoded data, why not choose option 
2?

> whether the voucher artifacts signed by manufacture, needs to closely 
> tie with MASA

For nonceful Vouchers, the MASA would need to sign it or delegate the 
generation and/or signing to a manufacturer's server. (In the latter case there 
is a trust relation and operational interaction, but no close tie necessarily.) 
As long as the signer can be trusted by the Pledge's built-in Trust Anchor, it 
works.
[Qin]:Thank for clarification, if my understanding is correct, the MASA in the 
former case is the third party entity while manufacturer's server in the latter 
case should be deployed together with the device by the same manufacturer.
regards
Esko

-Original Message-
From: Qin Wu 
Sent: Saturday, September 18, 2021 11:41
To: Michael Richardson ; la...@ietf.org
Cc: stokc...@bbhmail.nl; Esko Dijk ; anima@ietf.org
Subject: RE: [Anima] RFC 8366 / BRSKI / constrained-voucher: what is encoded in 
the idevid-issuer field?

I agree with this analysis, it looks the naming of this leaf ' idevid-issuer ' 
is the root cause for introducing such confusion, i.e., easily link 
KeyIdentifier to 'issuer' defined in section 4.1.2.4 of RFC5280.
Also I am wondering whether the voucher artifacts signed by manufacture, needs 
to closely tie with MASA. Maybe this relation can be decoupled as well.

-Qin
-邮件原件-
发件人: Anima [mailto:anima-boun...@ietf.org] 代表 Michael Richardson
发送时间: 2021年9月9日 1:12
收件人: la...@ietf.org
抄送: stokc...@bbhmail.nl; Esko Dijk ; anima@ietf.org
主题: [Anima] RFC 8366 / BRSKI / constrained-voucher: what is encoded in the 
idevid-issuer field?


RFC8366 specifies a idevid-issuer to identify the CA that issued the IDevID.
It says:
  https://www.rfc-editor.org/rfc/rfc8366.html#section-5.3

leaf idevid-issuer {
type binary;
description
  "The Authority Key Identifier OCTET STRING (as defined in
   Section 4.2.1.1 of RFC 5280) from the pledge's IDevID
   certificate.  Optional s