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

[Michael Richardson <[e-mail]>]

Esko Dijk <[e-mail]> 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 <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-