Re: [Anima] verification of manufacturer in BRSKI

[Michael Richardson <[e-mail]>]

Anoop Kumar Pandey <[e-mail]> wrote:
    > So JRS has all legitimate manufacturers and is procuring pledges from
    > known sources (out of these legitimate manufacturers), then where is
    > the hostility?

There are hostile devices on the network, and there are hostile networks that
might attempt to take over the pledge.  The IDevID protects the network
against hostile pledges, and the voucher protects the pledge against hostile
networks.

There is also the non-malicious situatoin where a pledge simply has multiple
(usually wireless!) networks to which it may join.  The voucher lets the
pledge decide which network will have it.  However, we haven't decided how to
do this for 802.11; in 6tisch we are doing this for 802.15.4.

    > That’s what I was trying to say in my initial mail that given an
    > unknown MI or a collaboration between pledge and MI, can security be
    > established using Automated BRSKI?

If your network's policy is to accept devices from unknown MIs, and the
MI is willing to issue vouchers to unknown domains, then you can be sure
that the connection is good.  By definition the pledge, being built by the
MI, is *always* in collaboration with it.

In ANIMA we do not go into home user situations, but that's due to charter
restrictions, not technology.  We do think that BRSKI can be used to
bootstrap Homenet.  In that situation, one can imagine buying lightbulbs
From Home Depot, and bring them home.  A JRC could run on a phone (or more
likely an app that speaks to a JRC via an API).  Unknown MIs might be
accepted, but why do that when a QR code could be scanned by the phone to
introduce the MI.

    > Also the pledge trusts JRC if JRC is able to pass on the voucher from
    > MASA to pledge. MASA only checks JRC’s certificate. Therefore any JRC
    > having a valid certificate may pass on the voucher from MASA to pledge
    > and become owner of the pledge [case of theft].

Yes, that's the case if the manufacturer does not know (or care) who bought
what.  That's reasonable for quite a number of cases.  Routers are usually
spared by manufacturers by geography, and given <4hr replacement SLAs,
there just isn't time on a Sunday morning at 4am to do any sales paperwork.
What might matter is that the JRC is *a* customer, but it doesn't matter which.

{Such a thing would have really helped me out in quite a number of times,
as I would get woken up at 5am, when the field operative guys can't figure
out why the router with the "export" firmware won't run securely, because it
needs the "cryptographic" firmware, but that license key is not valid for
that device}

    > I believe, BRSKI is a one-time imprinting service to a domain through
    > JRC. Once that is done, any unauthorized access (depending on the
    > vulnerability in the pledge) post EST, may not be stopped.

That's true.
That's not entirely our problem; we do however, by providing the pledge
with an LDevID and certificate trust anchors via EST, support doing very
secure authorization processes later on.  No default passwords, etc.
because no passwords are needed if both ends have certificates they can use.

    > BRSKI, is it one time process?
    > Or during each access to device will it re-run?

One time process.

    > When do we require to re-run this, only on domain-transfer?

On resale, the device should be put through a factory reset to clear
things.  The MASA will have to be willing to issue a new voucher to the
new domain owner.

    > Does it happen automatically whenever a device enters a domain or can
    > it started deliberately?

It is not automatic.
It needs to be deliberate.


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