Subject: Re: [core] comments on CORECONF drafts in WGLC

From: Ivaylo Petrov <[email-masked]>
Date: Sun, 12 Apr 2020 19:20:37 +0200

Hello Michael,

Thank you for the review and the comments! Please find my answers below
prefixed by [IP]. You can find the resulting diffs at the following link
[1].

Best regards,
Ivaylo

[1]:
https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-core-comi.txt&url2=https://core-wg.github.io/comi/draft-ietf-core-comi.txt

On Mon, Mar 30, 2020 at 6:22 PM Michael Richardson <[email-masked]>
wrote:

>
> Hi, I have read:
>
> — draft-ietf-core-yang-cbor-12
> — draft-ietf-core-sid-11
>
> I have implementation experience, and I've used these in other protocols,
> and
> I strongly agree that they are ready for publication!
>

[IP]: Thank you for your reviews and helping us get them to that state!

I read the COMI document some time ago, and I thought the approach was
> fine.  I do not have any implementation experience, so I have no attempted
> to
> understand the document at that level of detail.
> I would have liked to use COMI directly as part of
> ietf-6tisch-minimal-security's
> CoJP, but we would up creating a bespoke CBOR encoding, which is
> unfortunate.
>
> I suggest that the COMI document include the word "CORECONF" in it's title.
>   -> "CoAP Management Interface (CORECONF)"
> as I think that it is the starting document that leadds to the other three
> documents.  This will make it easier to find in rfc-index.txt.
>

[IP]: That sounds indeed a good way to go forward. Unless someone objects,
I am going to apply this change with the next revision.

>
> The security considerations, and authorization for this system is
> underspecified.  This was ultimately was killed SNMPv2, and led to a
> multi-decade long failure of SNMPv3.
> I suspect that this part will have a difficult time with security ADs.
>

[IP]: I tried to improve this section to some extent. Please let me know if
you have other ideas. Text contribution is always welcomed as well.

I think that a stronger link to ACE, is in order, and an introspective
> interface (using COMI!) into the authorization mechanism would help.
> This could be new work, and I suspect that there are many in t2trg and out
> in
> industry groups like OCF and CHIP that would like to have such a thing, but
> it is a non-trivial amount of work.
>

[IP]: I added an informational link to ACE, which for me seems as one of
the ways authorization can be handled in COMI. Is this what you have in
mind?

> I read draft-ietf-core-yang-library-01 when it was adopted.
> I have *no* expertise on the YANG in this document, and I have no expertise
> building network management systems that would need to this level of
> introspection.
>
> As I understand it, this module provides a constrained version of
> ietf-yang-library, the purpose of both is to describe which modules a
> device
> supports.
>
> I have no experience with introspection of devices like this, even doing
> SNMPv2 going back decades: it either worked or it didn't, usually it
> didn't,
> and one just guessed what the device supported, or read the manual.
>
> I understand the goals here, but I'm not certain, particularly in a
> constrained *network* that there is value in doing this.  I think that I'd
> rather get this information from a URL provided in an RFC8520 (MUD).
> I don't object to it though.
>

[IP]: Thank you for your thoughts on that one! I believe Michel Veillette
would best reply to the pros and cons of using URL in a MUD file vs this
document, but it seems to me that they would still address slightly
different use cases and probably there is value in having both supported.

I wonder if queries against this module could be answered with static
> content generated at compile time, and therefore from "ROM"?
>

[IP]: I would imagine so.

I disagree with the Security Considerations, that knowing the list of
> modules helps the attacker to the extent that it is important to provide
> specific read controls on it.  Attackers already have a copy of the ROM ;-)
> I would say that the entire COMI interface needs authorized read access,
> and
> this module no more than any other module.
>

[IP]: I believe the idea here is that the attacker doesn't necessarily know
which ROM the device is using. Having an easy way to discover that and from
there all the possible vulnerabilities of that device is what we want to
avoid. Otherwise I agree that the entire CoMI interface needs authorized
read access.

> I think that there might be future opportunities to link some of this work
> to
> the SUIT work, to the CoSWID work, and maybe to the RATS work.
>

[IP]: I strongly agree with this, but from all the different IoT security
options, I am currently not sure which ones would be best suited for CoMI
in different situations. Do you have ideas for concrete drafts and use
cases?

--
> Michael Richardson <[email-masked]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 13 Apr 2020 18:23:26 -0400

> you have other ideas. Text contribution is always welcomed as well.

It's better.

    > the ways authorization can be handled in COMI. Is this what you have in

I didn't really understand it the addition.

    > avoid. Otherwise I agree that the entire CoMI interface needs authorized

I believe that the attacker will know exactly what the system under attack
is, and likely knows the ROM version, and probably has a copy of that ROM too.

---

From: Ivaylo Petrov <[email-masked]>
Date: Tue, 14 Apr 2020 08:20:16 +0200

Hello Michael,

Thank you for the new comments! Please find my answers below.

> I didn't really understand it the addition.

[IP]: Apologies, I forgot to include the relevant text. Here it is:

   For secure network management, it is important to restrict access to
   configuration variables only to authorized parties.  CoMI re-uses the
   security mechanisms already available to CoAP, this includes DTLS
   [RFC6347] and OSCORE [RFC8613] for protected access to resources, as
   well as suitable authentication and authorization mechanisms, for
   example those defined in ACE OAuth [I-D.ietf-ace-oauth-authz].

Or maybe you find the new text difficult/impossible to understand?

> is, and likely knows the ROM version, and probably has a copy of that ROM too.

[IP]: In the security considerations the assumption was made that the
attacker does not know what the ROM version is. If the attacker
already knows that and therefore likely has a copy of it, then having
read access to the yang-library interface will not give him leverage,
unless the vulnerability is inside that very component. So without our
assumption, the yang-library interface should be protected similarly
to any other CORECONF interface. With our assumption, on the other
hand, it needs more protection than some other interfaces as, for
example, knowing the time on the system gives leverage to the
attacker, but does not give him a concrete list of exploits, which
identification of the ROM version might give.

Considering those two different cases, we have focused the discussion
on the more severe danger. Let us know if you think this would be
rephrased to include those two cases and discussions about their
significance.

--
Best regards,
Ivaylo