Re: [Iotops] maintain ownership (was: can we create protocols that securely transfer ownership?)

[Michael Richardson <[e-mail]>]

Toerless Eckert <[e-mail]> wrote:
    >> What did the certificate do?  Was this part of an HTTPS management
    >> system, or did it allow it to connect back to some cloud service?

    > I don't know whether or not it was used to connect to the cloud
    > service. I would assume it didn, i should have wiresharked this. It was
    > used for (legal, TiVO permitted ;-) https download of recordings, so
    > the box became logically unusable for the intended purpose (download
    > recordings for watching later on a different device).

    tte> I am saying the IETF is partially to blame because i think we also
    tte> proliferate the notion that certificates have to be renewed
    tte> periodically with maximum usual lifetimes of now i think one year ?
    tte> (was two years)

THIS IS NOT AN IETF POLICY.

    > Whether is a same browser or new tabs (white=internet,
    > black=internet-"anonymous", red="private-network") is IMHO secondary. I
    > do agree though that a browser for a lot of iot management cases could
    > be a lot smaller than an Internet browser, so it would fit itself
    > easier into embedded devices itself and be a lot more reliable and
    > predictable in its page rendering than all the horrenduously complex
    > options-galore W3C has produced for "The Internet TA realm".

I don't see what a use case for a browser in an IoT device.
A fridge with a panel? Sure, but it's probably big enough to an RPI or
Android equivalent OS inside, so it's not really constrained.

    > The iotops charter for example also does not talk about data management
    > for iot devices. This type of security operations would fall into that
    > type of charter point.

Our charter says:

} This includes (but is not limited to):
} - factory provisioning of devices
} - onboarding of devices
} - access control of devices to network resources
} - administrative control of devices
} - software/firmware upgrades
} - isolation/quarantine of devices
} - remediation of broken devices
} - end of life management of devices

I thought that it included backup/restore of configuration explicitely.
The reason that this is important is because is a broken device is replaced,
then you want to be able to transfer the configuration from the broken device
to the new device.
If the device abruptly (blue smokes gets out, being bricked, etc.) then in
order to have the old configuration requires that something back is up
regularly.

Ideally, configuration backup/restore should be independant of device type.
I don't know if YANG/RESTCONF has a generic way to get all things at this
point.  Perhaps it does. AFAIK, there is nothing like snmpwalk in RESTCONF,
but that's effectively what we need.

    >> We don't have Cu (CoAP support)in Firefox anymore, because one can't
    >> write new schemes as extensions due to security architecture changes.

    > Ok, i don't get that.

There was a plugin for firefox called "Cu"
https://github.com/mkovatsc/Copper

It implemented CoAP as a firefox extension.
My understanding is that Firefox changed things when they rewrote things in
Rust. Specifically, an extension can't register a new scheme (i.e. coaps), because
that opened the possibility that an extension would register and override "https".
Clearly, we need some other modular mechanism where we can get CoAP support back.
Copper was AWESOME.  I think that I had an old firefox install just to run
it,, but I don't know where I put that.

    > Somebody more tortured by the variety of iot relevant device to cloud
    > protocols should give an overview of all the stuff that will stay
    > relevant and would be within scope of IETF. I would suspect that
    > https/coap are reall just a smaller subset of what is relevant, so for

For industrial/data-acquisition IoT MQTT is where it's at.
There is a TLS-profile specification for it in ACE, I think.
Critical to using MQTT safely is per-device identity and TLS Client
Authentication, with private keys stored in a hardware TPM.

    >> The delegation voucher provides a history of ownership.  But, that
    >> isn't the device's certificate, it's the manufacturer's statement.  I
    >> don't see how we can use delegated-voucher to augment the LDevID,
    >> except by replacing it.

    > When we discussed BRSKI and change of ownership in the past years it
    > was always mitigated through the MASA and therefore vendor. I think
    > that is an important option. I would like to see the option of being
    > able to do this without any vendor/MASA involvement of course too.

    > I don't think it would be a problem to define suh a process, but i really
    > would prefer we would define those workflows abstract first so they're
    > not stuck in a specific protocol like BRSKI, but could more esily be
    > proliferated across various protocols faster.

Well, I'm not sure I understand what you are saying.
Perhaps you are saying that the Registrar concept needs to be abstracted and
applied to many protocols?

EAP-NOOB and DPP are both manufacturer-free onboarding processes.

EAP-NOOB has an AAA server, which is morally equivalent to a Registrar, but
it does not currently lead to an ownership transfer.
DPP is more nebulous, but the RIPE not-a-BCoP [cf: Good Place, "not a girl"]
tries to outline how it might be made more easily deployable.
  https://www.ripe.net/ripe/mail/archives/iot-wg/2020-October/000537.html

see section _Router-Led DPP Activity_

to make this work, we really need a standard API into the Home Router.
BFF USP/TR-369 has potential, but it's gonna take some running code to make
the profile a little more clear.

I'm completely uncertain if such a Home Router/Smartphone onboarding API
would be in scope or not for IOTOPS.  Is it Operational Practice?


    > aka: for the least difficult to implement "sell-on-ebay" option, you as
    > the outgoing owner could create a bearer token, and send that in email
    > to the ebay buyer and in parallel ship the product. Then the receiving
    > new owner could take ownership. But the vendor should not be able to
    > dis-own the product unless you as the owner explicitly create a
    > bearer-token.  --- just as an example.

We can implement this interaction with delegated-voucher "today"

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide