Re: [core] comments on CORECONF drafts in WGLC

[Ivaylo Petrov <[e-mail]>]

Hello Michael,

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

On Tue, Apr 14, 2020 at 12:23 AM Michael Richardson
<[e-mail]> wrote:
>
>
> Ivaylo Petrov <[e-mail]> wrote:
>     >> 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.
>
> It's better.
>
>     > [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 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?

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

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

>
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>

--
Best regards,
Ivaylo