[Anima] Constrained BRSKI - discovery of Registrar as a security risk ?

[Esko Dijk <[e-mail]>]

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<https://datatracker.ietf.org/doc/html/rfc8995#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: [e-mail]<mailto:[e-mail]>    |   [phone]