[Iot-directorate] Iotdir reviews of draft-richardson-mud-qrcode-02

[Michael Richardson <[e-mail]>]

This is a public reponses to reviews of draft-richardson-mud-qrcode.
The document is in the ISE queue and has received IOT-Direcorate reviews by
Jaime Jimenez and Marco Tiloca.
An OPSAWG review by Joel has been received, and I include my replies below as well.
I'll post a new revision once I'm sure that I've dealt with all the concerns.

Marco's comments were unicast, but I've saved them at:
  https://www.sandelman.ca/SSW/ietf/mud/qrcode/marco-review-01.txt
Changes from Marco's review are at:
  https://github.com/mcr/mud-qrcode/pull/2

Jaime's comments:
  https://mailarchive.ietf.org/arch/msg/iot-directorate/jB7C-IzhLPAMD-bY-K2I8it9TeE/
Edits from Jaime's review are at:
  https://github.com/mcr/mud-qrcode/pull/3

and my replies are below:

Jaime> When the MAC is not included on the MUD URL then the assumption is that the
Jaime> network administrator is the one with physical access to the devices and
Jaime> can create the relevant policies. This comes with the caveat of what is
Jaime> then the purpose of the QR code if manual configuration is needed anyways.

There are two points to RFC8520 MUD files:
a) it is true, RFC8520 just encodes rules that the network operator could input
   themselves.  If only they knew all the intricate details of the device,
   were well enough trained to input those rules accurately into the variety
   of firewalls and IDS systems they own without error.
   So RFC8520 files remove many opportunities for mistakes.

b) by indirecting through a MUD file hosted by the manufacturer, and signed
   by the manufacturer, the manufacturer of the device has the opportunity to
   fix errors or omissions in the ACLs, as well as communicate other
   meta-data about the device, such as the SBOM info, etc.

Additionally, a person installing devices on a campus network does not need
to be trusted with super-user access to the entire campus ACLs, just with
amending a database of MAC-address -> MUD file mappings in a database.

I have added a section 4, Applicability, which I think maybe will address
your concerns by putting this activity into a better context.
Please see:  https://github.com/mcr/mud-qrcode/pull/3


Jaime> A naive attacker could read the QR code that contains the MAC, change
Jaime> its own MAC to that of the QR code and then impersonate the device
Jaime> effectively blacklisting that MAC address and preventing the actual
Jaime> device from attaching to the network in the future.

I agree that this could be done.
In order to do it, one needs physical access to the network (or ESSID w/credential).
If one has that, one could just listen to the network for broadcasts, and
then do the attack.  802.1x is designed to deal with such things already.

Reviewer: Joel Jaeggli
Review result: Has Nits

    Joel> I reviewed this document on the behalf of the operations and management
    Joel> directorate.

    Joel> While this document is adequately evocative of the risks associated with
    Joel> essentially unsecured information being ingested via QR codes it's fairly
    Joel> unsatisfying with respect to mitigitations offered.
    Joel> this is a much a property
    Joel> of operating in the real world as it is a question of protocol implementation.
    Joel> While this is described as social engineering, it's a more deeply engineered
    Joel> falsehood that extends outside the realm of human decision-making.

okay.

    Joel> If I were to nitpick the described security issues it is that operation of or
    Joel> decision making over a device on the basis of  qr code embedded in a sticker
    Joel> can never provide a degree of certainty that the device is what it says it is
    Joel> that powering the device up and interrogating it's mud profile can achieve,
    Joel> that without some transitive trust property that can be extended to the device
    Joel> on the basis of the security of it's internals (e.g. protected
    Joel> cryptoghric

If I understand you, the sticker has very little value compared to a secured
boot process as being described by RATS, TCG, etc.
I can't disagree with you.... but I'm hearing: "it's not perfect, so don't
even bother"

Yet, I'm pretty sure that millions of devices have actually been deployed
over the past fourty years, building the Internet as we know it.  Yes, some
of them have turned out to be trojans.

    Joel> secrets that the manufacturer or owner have embedded)  that the information
    Joel> embedded in the online formation cannot be trusted to map to that device.  so
    Joel> for example if as part of lifecycle management one decides how to dispose of
    Joel> something broken or unpowered based on a mud profile sticker that information
    Joel> is not trustworthy on the basis of anything other than common sense or external
    Joel> validation. e.g. is this transformer full of dioxin or in fact mineral oil as
    Joel> the documentation behind the sticker claims.

So, I can't say anything about the other contents of the QRcode that RLA.org
wishes to put on the devices.  These might not be stickers, but would likely
be laser etched into the "case". I'm not sure the containers that
transformers live in are called cases, but whatever.    There are indeed many
concerns here.
Should these transformers have IP connectable micro-controllers (perhaps to
tell the operator that the dioxin is leaking...), my goal is simply that a
MUD profile could be associated with these controllers.

 rseadrian> So the point would be (and this applies to stickers randomly
 rseadrian> placed by an attacker as much as it does to anything else) that
 rseadrian> it would be good if the information accessed through the QR code
 rseadrian> was verifiable back to its origin.

MUD files have associated signatures.  This is in RFC8520 section 13:
   https://datatracker.ietf.org/doc/html/rfc8520#section-13

whether or not a MUD controller should trust the resulting file is outside of
the scope of this document.    RFC8520 does not say a lot about who to trust,
although section 16 of that document does say a fair bit about rogue
manufacturers.


Adrian further asked me:

 rseadrian> I decided to get ahead and had another scout through the draft. I
 rseadrian> think I don't quite know what the purpose of the document is. It
 rseadrian> is clear that, if it came out of (e.g.) the OPSAWG then it would
 rseadrian> be the IETF's consensus opinion on how to do QR codes in MUD. But
 rseadrian> in the Independent Stream I think it is one of three things:

 > 1. If it is documenting a specific implementation (which is hinted at by
 > "to allow interoperability") then it should name the implementation so
 > people know what they are interoperating with.

 > 2. If this is documenting a speculative approach, it should be
 > experimental and describe how to assess the experiment.

 > 3. If this is "just" the author's musings about how this might be done,
 > then it should be caveated accordingly as an opinion.

I take your point.
I could add an Implementary Summary to the document if that would helpful,
but the answer is unfortunately... all of the above.

1. There was a specific implementation which we did do as a proof of concept.
   http://www.sandelman.ca/SSW/talks/isoc-ca-multistakeholder4-2018/

2. Based upon experience we gained, we decided that we should have a more
   mainstream QRcode format, and after some research, it was suggested that
   rla.org was the right place to converge to.
   Alas, many other things got in the way of getting this done, some of which
   is the inevitable chicken-and-egg problem.

3. The document is, yes, "musings" about how we think RFC8520 should be done.
   This is being done in an RFC, because like, "IP-over-FOO" documents,
   it seemed best to do this in the IETF.  This is a "MUD-over-RLA" document.

{I think that this proposal is signficantly more concrete (and less
experimental) than many other 100-page Informational RFCs produced by WGs
which wind up going nowhere.}

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [



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